Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Gigabyte MP30-AR1
246 views
Skip to first unread message
Phil Endecott
Sep 9, 2016, 2:10:02 PM9/9/16
to
Dear Experts,
I've splashed out and bought myself a Gigabyte MP30-AR1. This is
a "server" board with an Applied Micro X-Gene processor.
There are various reports of people installing distributions including
Debian on the previous MP30-AR0. The difference between the -AR0 and
the -AR1 is that mine ships with UEFI, while the earlier board shipped
with U-Boot. I think that apart from that the boards are identical.
So far my attempts at installing Debian have not been successful.
I have, however, managed to install CentOS! So there is hope. In
each case I've put an ISO image onto a flash drive; UEFI has detected
this and presented it in its boot menu. Then GRUB runs successfully,
but it seems to fail to start the installer's kernel; with the current
strech/sid installer mini.iso
(http://ftp.debian.org/debian/dists/sid/main/installer-arm64/current/images/netboot/mini.iso)
I get:
EFI stub: Booting Linux Kernel...
ConvertPages: Incompatible memory types
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
OSBootEvent = Success
L3c Cache: 8MB
One possibility is that I just need to supply a suitable console=
argument to the installer kernel command line; this seemed to help in
some of the -AR0 installation reports. I've tried various things but
none of them help. Maybe I just don't know what the installer kernel
thinks the serial port is called.
Another thought is related to device tree blobs. I see that the ISO
image contains DTBs for various boards, including the X-Gene Mustang,
but not for this board. How are device trees supposed to work with
UEFI? Does the ISO image have to provide it?
Or perhaps there is something else I've overlooked. What do you suggest?
(Where do the experts on X-Gene and UEFI etc. hang out?) Perhaps it
would be easiest to debootstrap from CentOS!
Cheers, Phil.
I've splashed out and bought myself a Gigabyte MP30-AR1. This is
a "server" board with an Applied Micro X-Gene processor.
There are various reports of people installing distributions including
Debian on the previous MP30-AR0. The difference between the -AR0 and
the -AR1 is that mine ships with UEFI, while the earlier board shipped
with U-Boot. I think that apart from that the boards are identical.
So far my attempts at installing Debian have not been successful.
I have, however, managed to install CentOS! So there is hope. In
each case I've put an ISO image onto a flash drive; UEFI has detected
this and presented it in its boot menu. Then GRUB runs successfully,
but it seems to fail to start the installer's kernel; with the current
strech/sid installer mini.iso
(http://ftp.debian.org/debian/dists/sid/main/installer-arm64/current/images/netboot/mini.iso)
I get:
EFI stub: Booting Linux Kernel...
ConvertPages: Incompatible memory types
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
OSBootEvent = Success
L3c Cache: 8MB
One possibility is that I just need to supply a suitable console=
argument to the installer kernel command line; this seemed to help in
some of the -AR0 installation reports. I've tried various things but
none of them help. Maybe I just don't know what the installer kernel
thinks the serial port is called.
Another thought is related to device tree blobs. I see that the ISO
image contains DTBs for various boards, including the X-Gene Mustang,
but not for this board. How are device trees supposed to work with
UEFI? Does the ISO image have to provide it?
Or perhaps there is something else I've overlooked. What do you suggest?
(Where do the experts on X-Gene and UEFI etc. hang out?) Perhaps it
would be easiest to debootstrap from CentOS!
Cheers, Phil.
Lennart Sorensen
Sep 9, 2016, 2:50:02 PM9/9/16
to
On Fri, Sep 09, 2016 at 06:29:02PM +0100, Phil Endecott wrote:
> Dear Experts,
>
> I've splashed out and bought myself a Gigabyte MP30-AR1. This is
> a "server" board with an Applied Micro X-Gene processor.
>
> There are various reports of people installing distributions including
> Debian on the previous MP30-AR0. The difference between the -AR0 and
> the -AR1 is that mine ships with UEFI, while the earlier board shipped
> with U-Boot. I think that apart from that the boards are identical.
>
> So far my attempts at installing Debian have not been successful.
> I have, however, managed to install CentOS! So there is hope. In
> each case I've put an ISO image onto a flash drive; UEFI has detected
> this and presented it in its boot menu. Then GRUB runs successfully,
> but it seems to fail to start the installer's kernel; with the current
> strech/sid installer mini.iso (http://ftp.debian.org/debian/dists/sid/main/installer-arm64/current/images/netboot/mini.iso)
> I get:
>
> EFI stub: Booting Linux Kernel...
> ConvertPages: Incompatible memory types
> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> OSBootEvent = Success
> L3c Cache: 8MB
My understanding is that UEFI on arm can provide either a FDT or ACPI
> Dear Experts,
>
> I've splashed out and bought myself a Gigabyte MP30-AR1. This is
> a "server" board with an Applied Micro X-Gene processor.
>
> There are various reports of people installing distributions including
> Debian on the previous MP30-AR0. The difference between the -AR0 and
> the -AR1 is that mine ships with UEFI, while the earlier board shipped
> with U-Boot. I think that apart from that the boards are identical.
>
> So far my attempts at installing Debian have not been successful.
> I have, however, managed to install CentOS! So there is hope. In
> each case I've put an ISO image onto a flash drive; UEFI has detected
> this and presented it in its boot menu. Then GRUB runs successfully,
> but it seems to fail to start the installer's kernel; with the current
> strech/sid installer mini.iso (http://ftp.debian.org/debian/dists/sid/main/installer-arm64/current/images/netboot/mini.iso)
> I get:
>
> EFI stub: Booting Linux Kernel...
> ConvertPages: Incompatible memory types
> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> OSBootEvent = Success
> L3c Cache: 8MB
(Doing both means ACPI is used and FDT ignored). So that message about
using the DTB from the config table sounds like the kernel found the FDT
(flattened device tree).
I must admit I am not sure if those message are from UEFI, the boot
loader, or the kernel. I haven't checked if Debian's arm64 installer
is supposed to work with UEFI yet. The ports page seems to indicate it
does on at least some machines.
> One possibility is that I just need to supply a suitable console=
> argument to the installer kernel command line; this seemed to help in
> some of the -AR0 installation reports. I've tried various things but
> none of them help. Maybe I just don't know what the installer kernel
> thinks the serial port is called.
it what /proc/cmdline says the console is? Or check dmseg.
> Another thought is related to device tree blobs. I see that the ISO
> image contains DTBs for various boards, including the X-Gene Mustang,
> but not for this board. How are device trees supposed to work with
> UEFI? Does the ISO image have to provide it?
> Or perhaps there is something else I've overlooked. What do you suggest?
> (Where do the experts on X-Gene and UEFI etc. hang out?) Perhaps it
> would be easiest to debootstrap from CentOS!
--
Len Sorensen
Michael Howard
Sep 9, 2016, 3:40:02 PM9/9/16
to
On 09/09/2016 18:29, Phil Endecott wrote:
> Dear Experts,
>
> I've splashed out and bought myself a Gigabyte MP30-AR1. This is
> a "server" board with an Applied Micro X-Gene processor.
>
> There are various reports of people installing distributions including
> Debian on the previous MP30-AR0. The difference between the -AR0 and
> the -AR1 is that mine ships with UEFI, while the earlier board shipped
> with U-Boot. I think that apart from that the boards are identical.
>
> So far my attempts at installing Debian have not been successful.
> I have, however, managed to install CentOS! So there is hope. In
> each case I've put an ISO image onto a flash drive; UEFI has detected
> this and presented it in its boot menu. Then GRUB runs successfully,
> but it seems to fail to start the installer's kernel; with the current
> strech/sid installer mini.iso
> (http://ftp.debian.org/debian/dists/sid/main/installer-arm64/current/images/netboot/mini.iso)
> I get:
>
> EFI stub: Booting Linux Kernel...
> ConvertPages: Incompatible memory types
> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> OSBootEvent = Success
> L3c Cache: 8MB
You have checked the vga output haven't you? This board uses vga port
> Dear Experts,
>
> I've splashed out and bought myself a Gigabyte MP30-AR1. This is
> a "server" board with an Applied Micro X-Gene processor.
>
> There are various reports of people installing distributions including
> Debian on the previous MP30-AR0. The difference between the -AR0 and
> the -AR1 is that mine ships with UEFI, while the earlier board shipped
> with U-Boot. I think that apart from that the boards are identical.
>
> So far my attempts at installing Debian have not been successful.
> I have, however, managed to install CentOS! So there is hope. In
> each case I've put an ISO image onto a flash drive; UEFI has detected
> this and presented it in its boot menu. Then GRUB runs successfully,
> but it seems to fail to start the installer's kernel; with the current
> strech/sid installer mini.iso
> (http://ftp.debian.org/debian/dists/sid/main/installer-arm64/current/images/netboot/mini.iso)
> I get:
>
> EFI stub: Booting Linux Kernel...
> ConvertPages: Incompatible memory types
> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> OSBootEvent = Success
> L3c Cache: 8MB
primarily (by default) in my experience.
Mike.
--
Mike Howard
Lancashire
England
Phil Endecott
Sep 9, 2016, 10:40:03 PM9/9/16
to
Thanks for your replies.
Yes I'm observing both serial and VGA outputs.
Ronald Maas shared this earlycon magic:
earlycon=uart8250,mmio32,0x1c020000
and now I can see how the Debian installer kernel fails:
EFI stub: Booting Linux Kernel...
ConvertPages: Incompatible memory types
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
OSBootEvent = Success
L3c Cache: 8MB
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.6.0-1-arm64
(debian...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian
5.4.0-4) ) #1 SMP Debian 4.6.2-2 (2016-06-25)
[ 0.000000] Boot CPU: AArch64 Processor [500f0001]
[ 0.000000] earlycon: uart8250 at MMIO32 0x000000001c020000 (options '')
[ 0.000000] bootconsole [uart8250] enabled
[ 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] Moving initrd from [4079b0f000-407ac457c3] to [7e0ac9000-7e1bff7c3]
[ 0.000000] Unhandled fault: synchronous external abort (0x96000010) at 0xffffffbffe63e078
[ 0.000000] Internal error: : 96000010 [#1] SMP
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-arm64 #1
Debian 4.6.2-2
[ 0.000000] Hardware name: Gigabyte X-Gene MP30-AR0 board (DT)
[ 0.000000] task: ffffff8008b88800 ti: ffffff8008b78000 task.ti: ffffff8008b78000
[ 0.000000] PC is at __memcpy+0x100/0x180
[ 0.000000] LR is at copy_from_early_mem+0x6c/0x94
etc.
I suspect that the "ConvertPages: Incompatible memory types" (which comes
from UEFI) may be the fundamental issue, but I'm not certain.
I've tried various different Debian installer images with the same result;
I'll look at what Linaro / Ubuntu / etc. have next. (Suggestions?)
More important question - where are the people who understand this stuff?
Debian-EFI? Linaro? APM? Gigabyte?
Thanks, Phil.
Yes I'm observing both serial and VGA outputs.
Ronald Maas shared this earlycon magic:
earlycon=uart8250,mmio32,0x1c020000
and now I can see how the Debian installer kernel fails:
EFI stub: Booting Linux Kernel...
ConvertPages: Incompatible memory types
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
OSBootEvent = Success
L3c Cache: 8MB
[ 0.000000] Linux version 4.6.0-1-arm64
(debian...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian
5.4.0-4) ) #1 SMP Debian 4.6.2-2 (2016-06-25)
[ 0.000000] Boot CPU: AArch64 Processor [500f0001]
[ 0.000000] earlycon: uart8250 at MMIO32 0x000000001c020000 (options '')
[ 0.000000] bootconsole [uart8250] enabled
[ 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] Moving initrd from [4079b0f000-407ac457c3] to [7e0ac9000-7e1bff7c3]
[ 0.000000] Unhandled fault: synchronous external abort (0x96000010) at 0xffffffbffe63e078
[ 0.000000] Internal error: : 96000010 [#1] SMP
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-arm64 #1
Debian 4.6.2-2
[ 0.000000] Hardware name: Gigabyte X-Gene MP30-AR0 board (DT)
[ 0.000000] task: ffffff8008b88800 ti: ffffff8008b78000 task.ti: ffffff8008b78000
[ 0.000000] PC is at __memcpy+0x100/0x180
[ 0.000000] LR is at copy_from_early_mem+0x6c/0x94
etc.
I suspect that the "ConvertPages: Incompatible memory types" (which comes
from UEFI) may be the fundamental issue, but I'm not certain.
I've tried various different Debian installer images with the same result;
I'll look at what Linaro / Ubuntu / etc. have next. (Suggestions?)
More important question - where are the people who understand this stuff?
Debian-EFI? Linaro? APM? Gigabyte?
Thanks, Phil.
Wookey
Sep 9, 2016, 11:30:02 PM9/9/16
to
On 2016-09-10 03:16 +0100, Phil Endecott wrote:
> I've tried various different Debian installer images with the same result;
> I'll look at what Linaro / Ubuntu / etc. have next. (Suggestions?)
>
> More important question - where are the people who understand this stuff?
> Debian-EFI? Linaro? APM? Gigabyte?
This list is a pretty good start. We have plenty of debian and UEFI
> I've tried various different Debian installer images with the same result;
> I'll look at what Linaro / Ubuntu / etc. have next. (Suggestions?)
>
> More important question - where are the people who understand this stuff?
> Debian-EFI? Linaro? APM? Gigabyte?
expertise here. No-one I know actually has one of these boards (except
you now, and some guy as Fosdem who said that he had got one working).
We are quite keen to get to the bottom of what needs to change in the
Debian kernel/installer to have this machine supported.
I don't actually know where the experts on this specific board are. I guess
there must be someone at Gigabyte who knows. But if the centos kernel
works then that's a Clue <TM>.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Michael Howard
Sep 10, 2016, 2:30:01 AM9/10/16
to
On 10/09/2016 03:16, Phil Endecott wrote:
> Thanks for your replies.
>
> Yes I'm observing both serial and VGA outputs.
>
Speaking for the AR0 version, the debian installer failed for that too,
> Thanks for your replies.
>
> Yes I'm observing both serial and VGA outputs.
>
though I did install debian using the netboot vmlinux & initrd.gz from
u-boot. I then used the centos kernel (as the debian installer failed to
provide a working one) etc to boot the debian install and built my own
kernel and added the EFI boot entry manually using efibootmgr.
On the AR1, you could try interrupting the EFI boot and run
bootnetaa64.efi manually, just in case EFI is trying to boot something
else, to see if that works or gives you more help.
Cheers,
Mike.
--
Mike Howard
Hector Oron
Sep 12, 2016, 3:10:02 AM9/12/16
to
Hello,
2016-09-09 19:29 GMT+02:00 Phil Endecott <spam_from_...@chezphil.org>:
> EFI stub: Booting Linux Kernel...
> ConvertPages: Incompatible memory types
> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> EFI stub: Using DTB from configuration table
Which BMC firmware are you using? AFAIK there is a broken DTB in the
manufacturer's firmware therefore using ACPI boot is recommended,
however it is not supported until 4.7 kernel series, and then you'll
find #834505 (TL,DR; needs to enable ACPI and relocate initramfs
within first 32GB of RAM address space). Given all that machine should
boot. Then I had issues which I have been unable to investigate yet
when finding the storage disk to install the rootfs.
> EFI stub: Exiting boot services and installing virtual address map...
> OSBootEvent = Success
> L3c Cache: 8MB
Regards,
-- Hector Oron
2016-09-09 19:29 GMT+02:00 Phil Endecott <spam_from_...@chezphil.org>:
> EFI stub: Booting Linux Kernel...
> ConvertPages: Incompatible memory types
> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> EFI stub: Using DTB from configuration table
manufacturer's firmware therefore using ACPI boot is recommended,
however it is not supported until 4.7 kernel series, and then you'll
find #834505 (TL,DR; needs to enable ACPI and relocate initramfs
within first 32GB of RAM address space). Given all that machine should
boot. Then I had issues which I have been unable to investigate yet
when finding the storage disk to install the rootfs.
> EFI stub: Exiting boot services and installing virtual address map...
> OSBootEvent = Success
> L3c Cache: 8MB
-- Hector Oron
Wookey
Sep 12, 2016, 9:50:01 AM9/12/16
to
On 2016-09-12 09:03 +0200, Hector Oron wrote:
> Hello,
>
> 2016-09-09 19:29 GMT+02:00 Phil Endecott <spam_from_...@chezphil.org>:
>
> > EFI stub: Booting Linux Kernel...
> > ConvertPages: Incompatible memory types
> > EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> > EFI stub: Using DTB from configuration table
>
> Which BMC firmware are you using? AFAIK there is a broken DTB in the
> manufacturer's firmware therefore using ACPI boot is recommended,
> however it is not supported until 4.7 kernel series, and then you'll
> find #834505 (TL,DR; needs to enable ACPI and relocate initramfs
> within first 32GB of RAM address space).
To expand on this a little. EUFI provides both DTB and ACPI if both
> Hello,
>
> 2016-09-09 19:29 GMT+02:00 Phil Endecott <spam_from_...@chezphil.org>:
>
> > EFI stub: Booting Linux Kernel...
> > ConvertPages: Incompatible memory types
> > EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> > EFI stub: Using DTB from configuration table
>
> Which BMC firmware are you using? AFAIK there is a broken DTB in the
> manufacturer's firmware therefore using ACPI boot is recommended,
> however it is not supported until 4.7 kernel series, and then you'll
> find #834505 (TL,DR; needs to enable ACPI and relocate initramfs
> within first 32GB of RAM address space).
are present. In this case the ACPI info is 'more correct' than the DTB
info, but the kernel will prefer to use DTB info if it is present.
Centos may be choosing to explicitly prefer the ACPI in their kernel?
You can test this (on a 4.7 series kernel) by doing acpi=force on the
kernel boot command line. Does doing that make it boot phil? If so
then that suggests that the above is indeed the issue.
If that is the problem, then the underlying issue here is a
combination of the manufacturer providing a duff DTB and the
preference of ARM kernel (people) for DTB over ACPI.
Phil Endecott
Sep 12, 2016, 10:20:02 AM9/12/16
to
Hi Hector,
Thanks for your reply.
Hector Oron wrote:
> Which BMC firmware are you using? AFAIK there is a broken DTB in the
> manufacturer's firmware
I replaced the shipped UEFI firmware (version D03 I think) with version
F01 from
http://b2b.gigabyte.com/products/product-page.aspx?pid=5912#bios .
Any idea if that is supposed to fix the DTB? There doesn't seem to be
a changelog :-(
Do you think that the broken DTB would explain the issue I was seeing?
(I don't think you mean BMC firmware, but if you do I've not updated
that - and I've now managed to brick the BMC by attempting to change it
to "shared network" mode, which seems not to work on this hardware.
Hopefully I will eventually find some way to reset it back to dedicated
network mode...)
> therefore using ACPI boot is recommended,
> however it is not supported until 4.7 kernel series, and then you'll
> find #834505 (TL,DR; needs to enable ACPI and relocate initramfs
> within first 32GB of RAM address space). Given all that machine should
> boot.
Ha OK, I was vaguely aware that there was a setting for ACPI or device tree
and I was going to try changing it - but maybe there isn't much hope!
Hector, is it you that has been getting the board mentioned in that bug
working? What's the easiest way for me to duplicate what you've done?
Cheers, Phil.
Thanks for your reply.
Hector Oron wrote:
> Which BMC firmware are you using? AFAIK there is a broken DTB in the
> manufacturer's firmware
F01 from
http://b2b.gigabyte.com/products/product-page.aspx?pid=5912#bios .
Any idea if that is supposed to fix the DTB? There doesn't seem to be
a changelog :-(
Do you think that the broken DTB would explain the issue I was seeing?
(I don't think you mean BMC firmware, but if you do I've not updated
that - and I've now managed to brick the BMC by attempting to change it
to "shared network" mode, which seems not to work on this hardware.
Hopefully I will eventually find some way to reset it back to dedicated
network mode...)
> therefore using ACPI boot is recommended,
> however it is not supported until 4.7 kernel series, and then you'll
> find #834505 (TL,DR; needs to enable ACPI and relocate initramfs
> within first 32GB of RAM address space). Given all that machine should
> boot.
and I was going to try changing it - but maybe there isn't much hope!
Hector, is it you that has been getting the board mentioned in that bug
working? What's the easiest way for me to duplicate what you've done?
Cheers, Phil.
Lennart Sorensen
Sep 12, 2016, 11:20:03 AM9/12/16
to
has 4.7 kernel. Hmm, no, just checked, they are 4.6 still. Too bad.
--
Len Sorensen
Phil Endecott
Sep 12, 2016, 1:10:04 PM9/12/16
to
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:
> using ACPI boot is recommended,
> however it is not supported until 4.7 kernel series
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 4.2.0-0.27.el7.1.aarch64
(mock...@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
[ 0.000000] EFI v2.40 by American Megatrends
[ 0.000000] efi: ACPI 2.0=0x807ff43000 ESRT=0x807e161e18 SMBIOS 3.0=0x807e161c18
[ 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: 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.
(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.)
Cheers, Phil.
Lennart Sorensen
Sep 12, 2016, 2:20:02 PM9/12/16
to
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
> (mock...@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.
> 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
> (mock...@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
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.)
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
Michael Howard
Sep 12, 2016, 2:30:02 PM9/12/16
to
On 12/09/2016 17:47, Phil Endecott wrote:
> So that's a 4.2 kernel which seems to be using ACPI.
> Presumably this is backported, or something.
>
The sig-altarch7-aarch64 branch from
> So that's a 4.2 kernel which seems to be using ACPI.
> Presumably this is backported, or something.
>
'https://git.centos.org/summary/sig-altarch!kernel.git'
--
Mike Howard
Phil Endecott
Sep 12, 2016, 3:10:03 PM9/12/16
to
mostly it seems to be loading its own modules, which often have DEBUG
in their names. And that's all after the BMC has booted. I'm curious
to know what MP30-AR0 users see.
Cheers, Phil.
Phil Endecott
Sep 12, 2016, 3:40:04 PM9/12/16
to
The Ubuntu mini.iso installer from here:
http://ports.ubuntu.com/ubuntu-ports/dists/yakkety/main/installer-arm64/current/images/netboot/
also works, with a 4.4.0 kernel:
[ 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.4.0-9136-generic
(buildd@bos01-arm64-004) (gcc version 5.4.1 20160803 (Ubuntu/Linaro
5.4.1-1ubuntu2) ) #55-Ubuntu SMP Fri Aug 26 05:58:05 UTC 2016 (Ubuntu
4.4.0-9136.55-generic 4.4.16)
(options '')
[ 0.000000] bootconsole [uart0] enabled
[ 0.083487] ACPI: Interpreter disabled.
It must be using the device tree and surviving whatever bugs it has.
If this seems to work I may keep this kernel and try to convert the base
filesystem from Ubuntu to Debian; that should be easy, right??!
Maybe one of you experts can guess how the Debian and Ubuntu installers
and/or kernels differ that cause the Debian ones to fail for me, despite
being newer. I was wondering if GRUB might have some influence.
Cheers, Phil.
http://ports.ubuntu.com/ubuntu-ports/dists/yakkety/main/installer-arm64/current/images/netboot/
also works, with a 4.4.0 kernel:
[ 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
(buildd@bos01-arm64-004) (gcc version 5.4.1 20160803 (Ubuntu/Linaro
5.4.1-1ubuntu2) ) #55-Ubuntu SMP Fri Aug 26 05:58:05 UTC 2016 (Ubuntu
4.4.0-9136.55-generic 4.4.16)
[ 0.000000] Boot CPU: AArch64 Processor [500f0001]
[ 0.000000] earlycon: Early serial console at MMIO32 0x1c020000
(options '')
[ 0.000000] bootconsole [uart0] enabled
[ 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
ACPI is disabled:
[ 0.000000] EFI v2.40 by American Megatrends
[ 0.000000] efi: ACPI 2.0=0x807ff43000 ESRT=0x807e161e18 SMBIOS 3.0=0x807e161c18
[ 0.083487] ACPI: Interpreter disabled.
It must be using the device tree and surviving whatever bugs it has.
If this seems to work I may keep this kernel and try to convert the base
filesystem from Ubuntu to Debian; that should be easy, right??!
Maybe one of you experts can guess how the Debian and Ubuntu installers
and/or kernels differ that cause the Debian ones to fail for me, despite
being newer. I was wondering if GRUB might have some influence.
Cheers, Phil.
Wookey
Sep 12, 2016, 4:10:02 PM9/12/16
to
On 2016-09-12 19:41 +0100, Phil Endecott wrote:
> The Ubuntu mini.iso installer from here:
>
> http://ports.ubuntu.com/ubuntu-ports/dists/yakkety/main/installer-arm64/current/images/netboot/
>
> also works, with a 4.4.0 kernel:
> The Ubuntu mini.iso installer from here:
>
> http://ports.ubuntu.com/ubuntu-ports/dists/yakkety/main/installer-arm64/current/images/netboot/
>
> also works, with a 4.4.0 kernel:
> ACPI is disabled:
>
> [ 0.083487] ACPI: Interpreter disabled.
>
> It must be using the device tree and surviving whatever bugs it has.
Interesting. Phil, could I persuade you to file a bug against
>
> [ 0.083487] ACPI: Interpreter disabled.
>
> It must be using the device tree and surviving whatever bugs it has.
debian-installer with the info and logs you have collected (or just
the mails in this thread). It just helps avoid this issue getting lost.
> If this seems to work I may keep this kernel and try to convert the base
> filesystem from Ubuntu to Debian; that should be easy, right??!
can be quite hard to tell when you've actually expunged al the
ubuntuness :-)
Check /etc/debian-version /etc/os-release and /etc/dpkg/origins/debian
all have debian info rather than ubuntu info them get debian versions
of all the packages dpkg -l reports, then apt install --reinstall them
all (or use dpkg -i to ram them in). I have done this before (on
arm64) and it worked. You may need some --force-* to get it to play.
Michael Howard
Sep 12, 2016, 4:40:02 PM9/12/16
to
a centos kernel, or a redhat kernel. or a fedora kernel) and friends.
Then, you can build your own debian kernel. Much easier.
>
> Maybe one of you experts can guess how the Debian and Ubuntu installers
> and/or kernels differ that cause the Debian ones to fail for me, despite
> being newer. I was wondering if GRUB might have some influence.
>
>
the AR0 board either. Debian are a bit behind the curve on these server
boards.
Mike.
--
Mike Howard
Lennart Sorensen
Sep 12, 2016, 5:00:02 PM9/12/16
to
On Mon, Sep 12, 2016 at 09:33:12PM +0100, Michael Howard wrote:
> As mentioned in an earlier post, the debian installer didn't work with the
> AR0 board either. Debian are a bit behind the curve on these server boards.
Could be interesting to compare the /boot/config file for the ubuntu
> As mentioned in an earlier post, the debian installer didn't work with the
> AR0 board either. Debian are a bit behind the curve on these server boards.
and debian kernels, and even the Centos one for that matter.
--
Len Sorensen
Michael Howard
Sep 12, 2016, 5:10:02 PM9/12/16
to
patching (on the centos side at least) and even though I have built my
own debian kernel using their config as a base, it doesn't, for example,
see the internal MMC card (unless I stick to their 4.2 source). This I
believe is down to acpi/pci magic amongst other things.
Gigabyte provided a Ubuntu kernel & rootfs for the AR0 variant (no
source though, despite my requests) but it is basic and old.
Mike.
--
Mike Howard
Ian Campbell
Sep 13, 2016, 3:30:02 AM9/13/16
to
On Mon, 2016-09-12 at 14:45 +0100, Wookey wrote:
> Centos may be choosing to explicitly prefer the ACPI in their kernel?
Given the downstream relationship with RHEL (who certainly do so in the
> Centos may be choosing to explicitly prefer the ACPI in their kernel?
preview releases) I'd offer good odds that this was the case.
Ian.
Michael Howard
Sep 13, 2016, 4:40:02 AM9/13/16
to
Here is the serial output from my MP30-AR0 to the point of reaching the
grub screen. If you want kernel output, let me know.
#############
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.09.13 09:20:38
=~=~=~=~=~=~=~=~=~=~=~=
U-Boot 2013.04-mp30ar0_sw_1.18.04 (Sep 02 2015 - 16:38:06) REV: F06b (
uart0 )
CPU0: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
32 KB ICACHE, 32 KB DCACHE
SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
Boot from SPI-NOR
Slimpro FW:
Ver: 2.4 (build 01.18.04.00 2015/08/13)
TPC: disabled
AVS: supported (margin: -0mV)
RST: supported
PWROFF: supported
PMD: 970 mV
SOC: 950 mV
Board: GIGABYTE MP30AR0 - AppliedMicro APM883408-xNA24SPT Customer Board
I2C: ready
DRAM: PHY calibrating ... PHY calibrating
... PHY calibrating ... PHY
calibrating ... ECC init
................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................ **************** ................
64 GiB @ 1333MHz
Non-contiguous multiple bank memory detected:
DDR region[0]: 0x0080000000 - 0x0fffffffff
DDR region[1]: 0x8000000000 - 0x807fffffff
SF: Detected MX25L25635F with page size 64 KiB, total 32 MiB
MMC: X-Gene SD/SDIO/eMMC: 0
PCIE0: (RC) link down
PCIE2: (RC) X1 GEN-1 link up
PCIE3: (RC) link down
00:00.0 - 10e8:e004 - Bridge device
01:00.0 - 1a03:1150 - Bridge device
02:00.0 - 1a03:2000 - Display controller
Video: ASPEED VGA Card (1a03, 2000) found @(2:0:0)
Mode: 1024x768x32 48kHz 60Hz
In: serial
Out: serial
Err: serial
CPUs: 00000001
Net: eth0
USB0: scanning bus 0 for devices... XHCI: WARN: Didn't find a matching TT
3 USB Device(s) found
USB1: scanning bus 1 for devices... 4 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
XHCI: ep 0x1 - rounding interval to 128 microframes
XHCI-ERR: xhci_submit_async_int !
Hit any key to stop autoboot: 5 4 3 2 1 0
reading mp30ar0_tianocore_ubt.fd
1835008 bytes read in 1165 ms (1.5 MiB/s)
reading mp30ar0_tianocore_sec_ubt.fd
262144 bytes read in 1011 ms (252.9 KiB/s)
## Starting application at 0x1D000000 ...
X-Gene Mp30ar0 Board
Boot firmware (version 1.20.03-uhp built at 11:18:31 on Feb 22 2016)
PROGRESS CODE: V3020003 I0
PROGRESS CODE: V3020002 I0
PROGRESS CODE: V3020003 I0
PROGRESS CODE: V3020002 I0
PROGRESS CODE: V3020003 I0
PROGRESS CODE: V3020002 I0
PROGRESS CODE: V3020003 I0
PROGRESS CODE: V3021001 I0
[2J [01;01H [=3h [2J [01;01H [2J [01;01H [=3h [2J [01;01H [2J [01;01H [=3h [2J [01;01H [2J [01;01H [=3h [2J [01;01HTianoCore
1.20.03-uhp UEFI 2.4.0 Feb 22 2016 11:17:26
CPU: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
32 KB ICACHE, 32 KB DCACHE
SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
Board: X-Gene Mp30ar0 Board
Slimpro FW:
Ver: 2.4 (build 01.18.04.00 2015/08/13)
TPC: disable
AVS: support
PMD: 970 mV
SOC: 950 mV
The default boot selection will start in 5 seconds 4
seconds 3 seconds 2 seconds 1 second
#############
Mike.
--
Mike Howard
Hector Oron
Sep 13, 2016, 6:00:02 AM9/13/16
to
Hello Phil,
2016-09-12 15:58 GMT+02:00 Phil Endecott <spam_from_...@chezphil.org>:
>> Which BMC firmware are you using? AFAIK there is a broken DTB in the
>> manufacturer's firmware
>
>
> I replaced the shipped UEFI firmware (version D03 I think) with version
> F01 from http://b2b.gigabyte.com/products/product-page.aspx?pid=5912#bios .
> Any idea if that is supposed to fix the DTB? There doesn't seem to be
> a changelog :-(
I got D7b, which I was told it fixed it, but testing it, it did not
solve my problems.
>> therefore using ACPI boot is recommended,
>> however it is not supported until 4.7 kernel series, and then you'll
>> find #834505 (TL,DR; needs to enable ACPI and relocate initramfs
>> within first 32GB of RAM address space). Given all that machine should
>> boot.
>
>
> Ha OK, I was vaguely aware that there was a setting for ACPI or device tree
> and I was going to try changing it - but maybe there isn't much hope!
Debian kernel does not build ACPI on arm64... I have recently pushed a
change for that that sets
CONFIG_ACPI=y on arm64.
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=94622c610668a7e3eb504198b440d90bbab937a1
However, there is still one more issue when relocating initramfs and that needs
CONFIG_ARM64_VA_BITS_48=y
but I am told that breaks userland, so it might need to be reverted.
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=259c7457747fc27f974f96bc405dce17a28121ff
> Hector, is it you that has been getting the board mentioned in that bug
> working? What's the easiest way for me to duplicate what you've done?
Build a kernel with ACPI and VA_BITS_48 enabled, build d-i mini.iso
with that kernel. Boot device passing:
console=115200n8,ttyS0 earlycon acpi=force.
Yes, other distros kernel seem to work, at least I am told there
should be no issues with CentOS (using ACPI). I have not tried Ubuntu,
but using their kernel might be fastest way to install the board.
Regards,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
2016-09-12 15:58 GMT+02:00 Phil Endecott <spam_from_...@chezphil.org>:
>> Which BMC firmware are you using? AFAIK there is a broken DTB in the
>> manufacturer's firmware
>
>
> I replaced the shipped UEFI firmware (version D03 I think) with version
> F01 from http://b2b.gigabyte.com/products/product-page.aspx?pid=5912#bios .
> Any idea if that is supposed to fix the DTB? There doesn't seem to be
> a changelog :-(
solve my problems.
>> therefore using ACPI boot is recommended,
>> however it is not supported until 4.7 kernel series, and then you'll
>> find #834505 (TL,DR; needs to enable ACPI and relocate initramfs
>> within first 32GB of RAM address space). Given all that machine should
>> boot.
>
>
> Ha OK, I was vaguely aware that there was a setting for ACPI or device tree
> and I was going to try changing it - but maybe there isn't much hope!
change for that that sets
CONFIG_ACPI=y on arm64.
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=94622c610668a7e3eb504198b440d90bbab937a1
However, there is still one more issue when relocating initramfs and that needs
CONFIG_ARM64_VA_BITS_48=y
but I am told that breaks userland, so it might need to be reverted.
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=259c7457747fc27f974f96bc405dce17a28121ff
> Hector, is it you that has been getting the board mentioned in that bug
> working? What's the easiest way for me to duplicate what you've done?
with that kernel. Boot device passing:
console=115200n8,ttyS0 earlycon acpi=force.
Yes, other distros kernel seem to work, at least I am told there
should be no issues with CentOS (using ACPI). I have not tried Ubuntu,
but using their kernel might be fastest way to install the board.
Regards,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Lennart Sorensen
Sep 13, 2016, 11:00:03 AM9/13/16
to
On Tue, Sep 13, 2016 at 11:58:30AM +0200, Hector Oron wrote:
> However, there is still one more issue when relocating initramfs and that needs
> CONFIG_ARM64_VA_BITS_48=y
> but I am told that breaks userland, so it might need to be reverted.
Well it "breaks" code that was wrong by design to begin with. It seems
> However, there is still one more issue when relocating initramfs and that needs
> CONFIG_ARM64_VA_BITS_48=y
> but I am told that breaks userland, so it might need to be reverted.
it is being worked on to fix that.
You would think after running into trouble so many times over the decades
people would have stopped doing flags in the top bits of pointers by now,
but no, some people just can't leave those "unused" bits alone.
--
Len Sorensen
Phil Endecott
Sep 13, 2016, 4:40:02 PM9/13/16
to
Wookey wrote:
> Phil, could I persuade you to file a bug against debian-installer
Done; bug #837715
> Phil, could I persuade you to file a bug against debian-installer
It sounds as if Hector knows what needs to be done and is working
on it. I'm able to test things on this board if that will help, at
least for the next few weeks. It might get "too important to fiddle
with" after that. Though I might buy a spare one.
Cheers, Phil.
0 new messages