Re: Gigabyte MP30-AR1
On Mon, Sep 12, 2016 at 05:47:34PM +0100, Phil Endecott wrote:
> Hector Oron wrote:
> >using ACPI boot is recommended,
> >however it is not supported until 4.7 kernel series
>
> I've had a look at what CentOS does:
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Initializing cgroup subsys cpuset
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Initializing cgroup subsys cpuacct
> [ 0.000000] Linux version 4.2.0-0.27.el7.1.aarch64
> (mockbuild@apmb0.centos.lab) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4)
> (GCC) ) #1 SMP Tue Mar 22 15:55:54 CDT 2016
> [ 0.000000] CPU: AArch64 Processor [500f0001] revision 1
> [ 0.000000] Detected PIPT I-cache on CPU0
> [ 0.000000] efi: Getting EFI parameters from FDT:
> [ 0.000000] EFI v2.40 by American Megatrends
> [ 0.000000] efi: ACPI 2.0=0x807ff43000 ESRT=0x807e161e18 SMBIOS 3.0=0x807e161c18
> [ 0.000000] Reserving 2048MB of memory at 30720MB for crashkernel
It steals 2GB of ram for the crashkernel? That seems greedy.
> [ 0.000000] cma: Reserved 512 MiB at 0x00000000c0000000
> [ 0.000000] ACPI: Early table checksum verification disabled
> [ 0.000000] ACPI: RSDP 0x000000807FF43000 000024 (v02 ALASKA)
> [ 0.000000] ACPI: XSDT 0x000000807FF43028 000074 (v01 ALASKA A M I
> 01072009 AMI 00010013)
> [ 0.000000] ACPI: FACP 0x000000807FF430A0 00010C (v05 ALASKA A M I
> 01072009 AMI 00010013)
> [ 0.000000] ACPI: DSDT 0x000000807FF431B0 0054A2 (v05 ALASKA A M I
> 00000001 INTL 20130517)
> [ 0.000000] ACPI: GTDT 0x000000807FF48658 0000E0 (v01 ALASKA A M I
> 00000001 AMI 00010013)
> [ 0.000000] ACPI: MCFG 0x000000807FF48738 00007C (v01 APM XGENE
> 00000001 AMI 00010013)
> [ 0.000000] ACPI: FIDT 0x000000807FF487B8 00009C (v01 ALASKA A M I
> 01072009 AMI 00010013)
> [ 0.000000] ACPI: SPMI 0x000000807FF48858 000041 (v05 ALASKA A M I
> 00000000 AMI. 00000000)
> [ 0.000000] ACPI: APIC 0x000000807FF488A0 0002A4 (v03 APM XGENE
> 00000003 01000013)
> [ 0.000000] ACPI: SSDT 0x000000807FF48B48 000078 (v02 REDHAT MACADDRS
> 00000001 01000013)
> [ 0.000000] ACPI: SSDT 0x000000807FF48BC0 000032 (v02 REDHAT UARTCLKS
> 00000001 01000013)
> [ 0.000000] ACPI: SPCR 0x000000807FF48BF8 000050 (v02 A M I APTIO V
> 01072009 AMI. 0005000B)
> [ 0.000000] ACPI: BGRT 0x000000807FF48C48 000038 (v01 ALASKA A M I
> 01072009 AMI 00010013)
>
> Lots more mentions of ACPI:
>
> dmesg | grep ACPI
>
>
> [ 0.000000] efi: ACPI 2.0=0x807ff43000 ESRT=0x807e161e18 SMBIOS 3.0=0x807e161c18
> [ 0.000000] ACPI: Early table checksum verification disabled
> [ 0.000000] ACPI: RSDP 0x000000807FF43000 000024 (v02 ALASKA)
> [ 0.000000] ACPI: XSDT 0x000000807FF43028 000074 (v01 ALASKA A M I
> 01072009 AMI 00010013)
> [ 0.000000] ACPI: FACP 0x000000807FF430A0 00010C (v05 ALASKA A M I
> 01072009 AMI 00010013)
> [ 0.000000] ACPI: DSDT 0x000000807FF431B0 0054A2 (v05 ALASKA A M I
> 00000001 INTL 20130517)
> [ 0.000000] ACPI: GTDT 0x000000807FF48658 0000E0 (v01 ALASKA A M I
> 00000001 AMI 00010013)
> [ 0.000000] ACPI: MCFG 0x000000807FF48738 00007C (v01 APM XGENE
> 00000001 AMI 00010013)
> [ 0.000000] ACPI: FIDT 0x000000807FF487B8 00009C (v01 ALASKA A M I
> 01072009 AMI 00010013)
> [ 0.000000] ACPI: SPMI 0x000000807FF48858 000041 (v05 ALASKA A M I
> 00000000 AMI. 00000000)
> [ 0.000000] ACPI: APIC 0x000000807FF488A0 0002A4 (v03 APM XGENE
> 00000003 01000013)
> [ 0.000000] ACPI: SSDT 0x000000807FF48B48 000078 (v02 REDHAT MACADDRS
> 00000001 01000013)
> [ 0.000000] ACPI: SSDT 0x000000807FF48BC0 000032 (v02 REDHAT UARTCLKS
> 00000001 01000013)
> [ 0.000000] ACPI: SPCR 0x000000807FF48BF8 000050 (v02 A M I APTIO V
> 01072009 AMI. 0005000B)
> [ 0.000000] ACPI: BGRT 0x000000807FF48C48 000038 (v01 ALASKA A M I
> 01072009 AMI 00010013)
> [ 0.000000] psci: is not implemented in ACPI.
> [ 0.000000] smp_parking_protocol_cpu_init: ACPI parked addr=80009000
> [ 0.000000] smp_parking_protocol_cpu_init: ACPI parked addr=8000a000
> [ 0.000000] smp_parking_protocol_cpu_init: ACPI parked addr=8000b000
> [ 0.000000] smp_parking_protocol_cpu_init: ACPI parked addr=8000c000
> [ 0.000000] smp_parking_protocol_cpu_init: ACPI parked addr=8000d000
> [ 0.000000] smp_parking_protocol_cpu_init: ACPI parked addr=8000e000
> [ 0.000000] smp_parking_protocol_cpu_init: ACPI parked addr=8000f000
> [ 0.000138] ACPI: Core revision 20150619
> [ 0.004761] ACPI: All ACPI Tables successfully acquired
> [ 0.028062] ACPI: bus type PCI registered
> [ 0.028066] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> [ 0.028071] ACPI: IORT: Failed to get table, AE_NOT_FOUND
> [ 0.054416] ACPI: Added _OSI(Module Device)
> [ 0.054421] ACPI: Added _OSI(Processor Device)
> [ 0.054423] ACPI: Added _OSI(3.0 _SCP Extensions)
> [ 0.054425] ACPI: Added _OSI(Processor Aggregator Device)
> [ 0.063243] ACPI: Interpreter enabled
> [ 0.063248] ACPI: Using GIC for interrupt routing
> [ 0.066112] ACPI: Power Resource [SCVR] (off)
> [ 0.073650] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
> [ 0.073996] ACPI: IORT: can't find node related to PCI host bridge
> [segment 0]
> [ 0.074400] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-ff])
> [ 0.074713] ACPI: IORT: can't find node related to PCI host bridge
> [segment 2]
> [ 0.075874] ACPI: PCI Root Bridge [PCI3] (domain 0003 [bus 00-ff])
> [ 0.076185] ACPI: IORT: can't find node related to PCI host bridge
> [segment 3]
> [ 0.077314] ACPI: bus type USB registered
> [ 0.091582] pnp: PnP ACPI init
> [ 0.092129] pnp: PnP ACPI: found 0 devices
> [ 0.482140] ACPI: SPCR serial device: 0x1c021000 (options: 115200)
> [ 0.482220] ACPI: SPCR serial console: \_SB_.AHBC.URT1 (0x1c021000)
> [ 1.772602] mmc0: SDHCI controller on ACPI [APMC0D0C:00] using PIO
>
> So that's a 4.2 kernel which seems to be using ACPI.
> Presumably this is backported, or something.
Well Redhat often backports things. I suspect grepping for device tree
or dtb or whichever you saw with the Debian kernel finds nothing.
> (BTW, note "EFI v2.40 by American Megatrends". I think that the people
> who've installed UEFI on their MP30-AR0 boards (which shipped with only
> U-Boot) have installed the open-source TianoCore. This is presumably
> something different. Its predominant characteristic for me is how
> extraordinarily slow it is; it takes 3 minutes from powering on to
> showing the Gigabyte logo, and another minute to show a boot logo. It's
> as if it's interpreting x86 code, or running from a serial ROM, or
> something.)
For a server that isn't that unusual. They often run very extensive
power on diagnostics. I think one of the IBM power servers I have dealt
with took 2 minutes from connecting power before you could even press
the power button, and then it took several minutes before the firmware
interface appeared after you hit the button. x86 servers often take
several minutes too.
--
Len Sorensen
Reply to: