On 2015-09-17 09:00, Karanbir Singh wrote:

On 16/09/15 15:16, Gordan Bobic wrote:

...

Hi,

I am toying with the idea of getting a Gigabyte MP30-AR0 board (despite the insanely exorbitant price tag). Has anyone got the aarch64 CentOS working on one of those? Any special instructions?

Also, if I get the ISO, is it bootable on aarch64? Does the installer work? Or does the image have to be used like on 32-bit ARM?

I believe the Gigabyte folks are on this list..

If they are, I'd love to hear their input, especially on the subject of why their UK resellers are unable to get hold of and quote price and availability on this board, while I can in fact get it from France and Luxembourg (which I dislike doing because it makes any possible warranty claims expensive and time consuming even without language barrier issues).

Gordan

On 2015-09-22 00:18, Jim Perrin wrote:

On 09/16/2015 07:16 AM, Gordan Bobic wrote:

...

Hi,

I am toying with the idea of getting a Gigabyte MP30-AR0 board (despite the insanely exorbitant price tag). Has anyone got the aarch64 CentOS working on one of those? Any special instructions?

Also, if I get the ISO, is it bootable on aarch64? Does the installer work? Or does the image have to be used like on 32-bit ARM?

This board is based on the APM xgene, which we've used and tested fairly heavily. It *should* just work out of the box.

Good to know. Now if only I could get one in UK...

Gordan,

There were some quirks with CentOS 7.1, but this should be working perfectly fine with latest CentOS 7.2 aarch64 release.

-Phong

-----Original Message----- From: arm-dev-bounces@centos.org [mailto:arm-dev-bounces@centos.org] On Behalf Of Gordan Bobic Sent: Friday, February 19, 2016 5:00 PM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] Gigabyte MP30-AR0

These appear to finally be available in UK now: https://www.xcase.co.uk/gigabyte-server-boards/gigabyte-mp30-ar0-with-applie...

Unfortunately, things don't work right out of the box: https://www.mail-archive.com/users@lists.redsleeve.org/msg01274.html

Has anyone got CentOS installer working with this board? £600 is an awful lot to spend on a paper weight.

Gordan

On 2015-09-22 00:18, Jim Perrin wrote:

On 09/16/2015 07:16 AM, Gordan Bobic wrote:

...

Hi,

I am toying with the idea of getting a Gigabyte MP30-AR0 board (despite the insanely exorbitant price tag). Has anyone got the aarch64 CentOS working on one of those? Any special instructions?

Also, if I get the ISO, is it bootable on aarch64? Does the installer work? Or does the image have to be used like on 32-bit ARM?

This board is based on the APM xgene, which we've used and tested fairly heavily. It *should* just work out of the box.

_______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev

In theory, you just need to convert CentOS vmlinuz to uImage, then do U-boot boot using the dtb and CentOS initrd.img; but somehow it hangs on me. I'll need to dig into it further.

I am not aware that it was shipped only with U-boot. If you want to try with UEFI, take it from my dropbox

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.tar....

mp30ar0_tianocore_media.img: burn to SPI NOR if you want to replace U-boot permanently

But if you want to chain boot from the existing U-boot, # setenv num_cores 1 # reset

# setenv load_tianocore 'tftp 0x4002000000 ${user_dir}/mp30ar0_tianocore_ubt.fd;tftp 0x1d000000 ${user_dir}/mp30ar0_tianocore_sec_ubt.fd' # setenv run_tianocore 'go 0x1d000000' # run load_tianocore run_tianocore

To install CentOS 7.2, the fastest would be to take http://mirror.centos.org/altarch/7.2.1511/isos/aarch64/CentOS-7-aarch64-Ever...

and image it on a USB drive ~8GB dd if=CentOS-7-aarch64-Everything.iso of=/dev/sdX bs=1M

Insert the USB drive to the board, + boot tianocore to prompt + select Shell (it should display a list of storage FS0, FS1, FS2, etc. and note the USB) + type FS0: (or FS1: if that does not work) + type EFI\BOOT\BOOTAA64.EFI

and this should bring you to the CentOS installer prompt.

-----Original Message----- From: arm-dev-bounces@centos.org [mailto:arm-dev-bounces@centos.org] On Behalf Of Gordan Bobic Sent: Friday, February 19, 2016 6:12 PM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] Gigabyte MP30-AR0

On 2016-02-19 10:57, Phong Vo wrote:

Gordan,

There were some quirks with CentOS 7.1, but this should be working perfectly fine with latest CentOS 7.2 aarch64 release.

The board appears to ship with u-boot rather than UEFI firmware. Does the image work with u-boot?

-----Original Message----- From: arm-dev-bounces@centos.org [mailto:arm-dev-bounces@centos.org] On Behalf Of Gordan Bobic Sent: Friday, February 19, 2016 5:00 PM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] Gigabyte MP30-AR0

These appear to finally be available in UK now: https://www.xcase.co.uk/gigabyte-server-boards/gigabyte-mp30-ar0-with-applie...

Unfortunately, things don't work right out of the box: https://www.mail-archive.com/users@lists.redsleeve.org/msg01274.html

Has anyone got CentOS installer working with this board? £600 is an awful lot to spend on a paper weight.

Gordan

On 2015-09-22 00:18, Jim Perrin wrote:

...

On 09/16/2015 07:16 AM, Gordan Bobic wrote:

...

Hi,

I am toying with the idea of getting a Gigabyte MP30-AR0 board (despite the insanely exorbitant price tag). Has anyone got the aarch64 CentOS working on one of those? Any special instructions?

Also, if I get the ISO, is it bootable on aarch64? Does the installer work? Or does the image have to be used like on 32-bit ARM?

This board is based on the APM xgene, which we've used and tested fairly heavily. It *should* just work out of the box.

---

Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev

_______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev

Hi,

I've just subscribe to the list to contribute to this thread.

I tried the instructions at https://lists.centos.org/pipermail/arm-dev/2016-February/001623.html without success. The session below appears to result in the board hanging;

[START SESSION]

Hit any key to stop autoboot: 0 MP30AR0# setenv num_cores 1 MP30AR0# setenv load_tianocore 'tftp 0x4002000000 mp30/mp30ar0_tianocore_ubt.fd; tftp 0x1d000000 mp30/mp30ar0_tianocore_sec_ubt.fd' MP30AR0# setenv run_tianocore 'go 0x1d000000' MP30AR0# run load_tianocore run_tianocore Port0 is down Using eth0 device TFTP from server 192.168.1.12; our IP address is 192.168.1.120 Filename 'mp30/mp30ar0_tianocore_ubt.fd'. Load address: 0x4002000000 Loading: ################################################################# ############################################################# 3.2 MiB/s done Bytes transferred = 1835008 (1c0000 hex) Using eth0 device TFTP from server 192.168.1.12; our IP address is 192.168.1.120 Filename 'mp30/mp30ar0_tianocore_sec_ubt.fd'. Load address: 0x1d000000 Loading: ################## 2.9 MiB/s done Bytes transferred = 262144 (40000 hex) ## Starting application at 0x1D000000 ...

X-Gene Mp30ar0 Board Boot firmware (version 1.20.03 built at 18:22:28 on Jan 26 2016)

[END SESSION]

Nothing appears on either the serial or vga after this. For completeness I also did a 'reset' after 'setenv num_cores 1' though I didn't get the point. The result is exactly the same.

Any other pointers greatly appreciated.

On 22/02/2016 05:02, Phong Vo wrote:

Hi,

The mp30ar0 U-boot has some special memory mapping to accommodate 32-bit DMA. Please download the tar ball again - I've updated the tianocore UHP for this.

Ok, your changes have enabled the board's u-boot to chainload EFI which is great, many thanks.

The installer though did not install a bootable kernel. It overwrote the original onboard kernel thus preventing the board booting to it's default 'OpenLinux'. The kernel that the installer installed appears to fail due to bad CRC. So, with no disks connected or sdcard inserted I get ......

ramdisk_self=run usb_init; run sf_read_ramdisk && run ram_self SF: 0:0 probed ................................................................................ ................................................................................ ................................................................................ ................ SF: flash read success (16777216 bytes @ 0x1000000) List of available devices: vga 80000002 S.O serial 80000003 SIO stdin stdout stderr usbkbd0 80000001 SI. ## Booting kernel from Legacy Image at 82000000 ... Image Name: Linux-LE Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 13828112 Bytes = 13.2 MiB Load Address: 00080000 Entry Point: 00080000 Verifying Checksum ... Bad Data CRC ERROR: can't get kernel image!

...... instead of booting to onboard OpenLinux. No great loss I guess :) Obviously, what should have happened at this point after the install is booting centos on disk.

Booting with the provided Ubuntu image on sdcard still works. I think there are recovery instructions somewhere in the docs so I might be able to recover the original kernel. If not, anybody any idea how to burn the kernel from the sdcard to this board or better still, how to get a working centos kernel?

Cheers,

On 22/02/2016 11:50, Gordan Bobic wrote:

It seems a little odd that the installer would put the kernel somewhere other than the target installation disk.

I agree but the board no longer boots.

Having UEFI on-board I can understand, but shouldn't the boot sequence in this case be:

1. u-boot (on-board)
2. UEFI (wherever u-boot can fetch it from)
3. grub (off the UEFI FAT partition on the target disk)
4. Kernel (/boot partition)

Perhaps it should be.

Is there a good reason for deviating from this?

To be honest, I don't know. To quote the manual, "The system wills entry OpenLinux automatically if no any boot devices exist. (ex. SD card/USB memory stick/SATA hard disk)" and that was the case prior to my attempt to install centos.

I'm not bothered about not being able to boot into OpenLinux. I'll try a few more things.

On 2016-02-22 14:26, Michael Howard wrote:

On 22/02/2016 11:50, Gordan Bobic wrote:

...

It seems a little odd that the installer would put the kernel somewhere other than the target installation disk. Having UEFI on-board I can understand, but shouldn't the boot sequence in this case be:

1. u-boot (on-board)
2. UEFI (wherever u-boot can fetch it from)
3. grub (off the UEFI FAT partition on the target disk)
4. Kernel (/boot partition)

Is there a good reason for deviating from this?

Ok, reinstalling the original u-boot resolves the onboard kernel issue, that is, the board now boots to OpenLinux again when no other devices are attached. So the 'Applied Micro Linux 3.12.0 (aarch64)' kernel is part of their (Gigabyte's) u-boot image.

Right, so now that UEFI is working, it seems the next thing to do is to get grub2 loading from UEFI. From there on it should be trivial to get a sensible kernel booting.

I do find it baffling that the installer that requires UEFI would do something so fundamentally different in terms of configuring the boot process compared to the x86 method of doing it.

Hmm... I wonder... Did you create a 250MB FAT partition on the disk of type EF00 (GPT), for the UEFI boot loader part (the stuff that ends up in /boot/efi)?

Gordan

On 2016-02-22 15:30, Michael Howard wrote:

On 22/02/2016 14:42, Gordan Bobic wrote:

...

On 2016-02-22 14:26, Michael Howard wrote:

...

On 22/02/2016 11:50, Gordan Bobic wrote:

...

It seems a little odd that the installer would put the kernel somewhere other than the target installation disk. Having UEFI on-board I can understand, but shouldn't the boot sequence in this case be:

1. u-boot (on-board)
2. UEFI (wherever u-boot can fetch it from)
3. grub (off the UEFI FAT partition on the target disk)
4. Kernel (/boot partition)

Is there a good reason for deviating from this?

Ok, reinstalling the original u-boot resolves the onboard kernel issue, that is, the board now boots to OpenLinux again when no other devices are attached. So the 'Applied Micro Linux 3.12.0 (aarch64)' kernel is part of their (Gigabyte's) u-boot image.

Right, so now that UEFI is working, it seems the next thing to do is to get grub2 loading from UEFI. From there on it should be trivial to get a sensible kernel booting.

Ok, some strangeness happening here. It seems it wasn't the centos installer that caused the issue of the board not booting to OpenLinux afterall. Having reinstalled u-boot and confirmed the board booted to OpenLinux, I chainloaded UEFI once more (using the instructions from Phong Vo) in order to try manually booting centos. I couldn't immediately see how to do that so I reset the board and now back to non booting board. Go figure.

...

I do find it baffling that the installer that requires UEFI would do something so fundamentally different in terms of configuring the boot process compared to the x86 method of doing it.

I guess it doesn't afterall.

...

Hmm... I wonder... Did you create a 250MB FAT partition on the disk of type EF00 (GPT), for the UEFI boot loader part (the stuff that ends up in /boot/efi)?

Well, this installer is completely new to me. At the opening screen of the text install I had to select various aspects of the install before it would let me proceed. One of which is the selection of the install disc and how it should be partitioned. I changed from LVM to basic partitioning and an efi partition was reported to have been created. Once the install began, there was no requirement for further user interaction.

Hang on, you mean the installer in this case is text based anaconda, rather than GUI?

Gordan

On 2016-02-22 16:37, Michael Howard wrote:

On 22/02/2016 15:36, Gordan Bobic wrote:

...

On 2016-02-22 15:30, Michael Howard wrote:

...

On 22/02/2016 14:42, Gordan Bobic wrote:

...

On 2016-02-22 14:26, Michael Howard wrote:

...

On 22/02/2016 11:50, Gordan Bobic wrote:

...

It seems a little odd that the installer would put the kernel somewhere other than the target installation disk. Having UEFI on-board I can understand, but shouldn't the boot sequence in this case be:

1. u-boot (on-board)
2. UEFI (wherever u-boot can fetch it from)
3. grub (off the UEFI FAT partition on the target disk)
4. Kernel (/boot partition)

Is there a good reason for deviating from this?

Ok, reinstalling the original u-boot resolves the onboard kernel issue, that is, the board now boots to OpenLinux again when no other devices are attached. So the 'Applied Micro Linux 3.12.0 (aarch64)' kernel is part of their (Gigabyte's) u-boot image.

Right, so now that UEFI is working, it seems the next thing to do is to get grub2 loading from UEFI. From there on it should be trivial to get a sensible kernel booting.

Ok, some strangeness happening here. It seems it wasn't the centos installer that caused the issue of the board not booting to OpenLinux afterall. Having reinstalled u-boot and confirmed the board booted to OpenLinux, I chainloaded UEFI once more (using the instructions from Phong Vo) in order to try manually booting centos. I couldn't immediately see how to do that so I reset the board and now back to non booting board. Go figure.

...

I do find it baffling that the installer that requires UEFI would do something so fundamentally different in terms of configuring the boot process compared to the x86 method of doing it.

I guess it doesn't afterall.

...

Hmm... I wonder... Did you create a 250MB FAT partition on the disk of type EF00 (GPT), for the UEFI boot loader part (the stuff that ends up in /boot/efi)?

Well, this installer is completely new to me. At the opening screen of the text install I had to select various aspects of the install before it would let me proceed. One of which is the selection of the install disc and how it should be partitioned. I changed from LVM to basic partitioning and an efi partition was reported to have been created. Once the install began, there was no requirement for further user interaction.

Hang on, you mean the installer in this case is text based anaconda, rather than GUI?

Yes, that's correct. The installer has problems with network also, in that it doesn't find a 'link up' on any port. Hence it won't start vnc installer either.

As mentioned, my accusation about the installer overwriting the onboard kernel was way off mark, although something (chainloading EFI?) does.

The irony of that is killing me right now: https://lists.fedoraproject.org/pipermail/users/2013-February/431095.html

It is a long thread, but it does make for an entertaining (if also at times depressing) read.

Dumbing down and crippling the text installer was a retarded idea back when it was done in F11 (and it filtered down into EL6). History seemingly hasn't shown it to be any less retarded than it seemed to many of us back then.

Anyway, the install does in fact succeed, which is great. I probably should have stuck with the LVM partitioning scheme but hey ho, I can re run things now that I know UEFI is working.

So, I have a minimal CentOS install with 4.2.0-0.21.el7.aarch64 kernel. Great start, thanks to all.

There is no networking so I need to get the installer to recognise the nics at install time.

So installer produces a bootable system, complete with a working kernel? Does it use grub2 or does it do some magic to boot the kernel straight from UEFI?

Gordan

On 2016-02-22 16:57, Michael Howard wrote:

On 22/02/2016 16:47, Gordan Bobic wrote:

...

...

Anyway, the install does in fact succeed, which is great. I probably should have stuck with the LVM partitioning scheme but hey ho, I can re run things now that I know UEFI is working.

So, I have a minimal CentOS install with 4.2.0-0.21.el7.aarch64 kernel. Great start, thanks to all.

There is no networking so I need to get the installer to recognise the nics at install time.

So installer produces a bootable system, complete with a working kernel?

Yes, and no. It produces a bootable kernel.

Right, but how does that kernel get booted? u-boot -> kernel ? u-boot -> UEFI -> kernel ? u-boot -> UEFI -> grub2 -> kernel ?

...

Does it use grub2 or does it do some magic to boot the kernel straight from UEFI?

I haven't had the nerve to attempt to bun UEFI to SPI-NOR permanently,

Oh, I wasn't suggesting that. I cannot think of a good reason to burn UEFI into SPI-NOR vs. chain-loading it from u-boot, since the boot cascade is automatable.

so following the install (and any subsequent ones) I've loaded it from u-boot manually and then booted directly from UEFI from there. I can of course automate that I suppose.

Right, so post-install the boot process is: u-boot -> UEFI -> kernel ?

No grub2 involved?

The reason I am specifically asking about grub is because grub2 knows how to load the kernel and initramfs off ZFS, and I would prefer to not have to keep /boot on ext4 (even if /boot/efi has to be FAT - because UEFI).

Gordan

On 2016-02-22 17:29, Michael Howard wrote:

On 22/02/2016 17:04, Gordan Bobic wrote:

...

On 2016-02-22 16:57, Michael Howard wrote:

...

On 22/02/2016 16:47, Gordan Bobic wrote:

...

...

Anyway, the install does in fact succeed, which is great. I probably should have stuck with the LVM partitioning scheme but hey ho, I can re run things now that I know UEFI is working.

So, I have a minimal CentOS install with 4.2.0-0.21.el7.aarch64 kernel. Great start, thanks to all.

There is no networking so I need to get the installer to recognise the nics at install time.

So installer produces a bootable system, complete with a working kernel?

Yes, and no. It produces a bootable kernel.

Right, but how does that kernel get booted? u-boot -> kernel ? u-boot -> UEFI -> kernel ? u-boot -> UEFI -> grub2 -> kernel ?

...

...

Does it use grub2 or does it do some magic to boot the kernel straight from UEFI?

I haven't had the nerve to attempt to bun UEFI to SPI-NOR permanently,

Oh, I wasn't suggesting that. I cannot think of a good reason to burn UEFI into SPI-NOR vs. chain-loading it from u-boot, since the boot cascade is automatable.

...

so following the install (and any subsequent ones) I've loaded it from u-boot manually and then booted directly from UEFI from there. I can of course automate that I suppose.

Right, so post-install the boot process is: u-boot -> UEFI -> kernel ?

Yes.

Sweet! Now I just have to try to scrape together enough to get me one of those cometh pay day. :-D

...

No grub2 involved?

No.

I'll see if I can do something about that when mine arrives. It would be nice to have it working the same way x86 UEFI works.

On a semi-related note, is it possible to mount an armv5tel or armv7hl image, and chroot into it? Does that work? Or is aarch64 not binary backward compatible with 32-bit ARM binaries like x86-64 is?

Gordan

On 22/02/2016 20:08, Gordan Bobic wrote:

On 2016-02-22 17:29, Michael Howard wrote:

...

On 22/02/2016 17:04, Gordan Bobic wrote:

...

On 2016-02-22 16:57, Michael Howard wrote:

...

On 22/02/2016 16:47, Gordan Bobic wrote:

...

...

Anyway, the install does in fact succeed, which is great. I probably should have stuck with the LVM partitioning scheme but hey ho, I can re run things now that I know UEFI is working.

So, I have a minimal CentOS install with 4.2.0-0.21.el7.aarch64 kernel. Great start, thanks to all.

There is no networking so I need to get the installer to recognise the nics at install time.

So installer produces a bootable system, complete with a working kernel?

Yes, and no. It produces a bootable kernel.

Right, but how does that kernel get booted? u-boot -> kernel ? u-boot -> UEFI -> kernel ? u-boot -> UEFI -> grub2 -> kernel ?

...

...

Does it use grub2 or does it do some magic to boot the kernel straight from UEFI?

I haven't had the nerve to attempt to bun UEFI to SPI-NOR permanently,

Oh, I wasn't suggesting that. I cannot think of a good reason to burn UEFI into SPI-NOR vs. chain-loading it from u-boot, since the boot cascade is automatable.

...

so following the install (and any subsequent ones) I've loaded it from u-boot manually and then booted directly from UEFI from there. I can of course automate that I suppose.

Right, so post-install the boot process is: u-boot -> UEFI -> kernel ?

Yes.

Sweet! Now I just have to try to scrape together enough to get me one of those cometh pay day. :-D

...

...

No grub2 involved?

No.

I'll see if I can do something about that when mine arrives. It would be nice to have it working the same way x86 UEFI works.

With my pre-occupation with having no networking, I gave you some bum info. Grub2 is indeed involved.

Cheers,

I see that CentOS installer somehow does not detect network, so it gives text-based installation. However, once installation is finished, check your /etc/sysconfig/network-scripts/ifcfg-eth0 (or something similar).

Make sure BOOTPROTO=dhcp ONBOOT=y

Change ONBOOT to y and reboot should get network working.

-Phong

-----Original Message----- From: arm-dev-bounces@centos.org [mailto:arm-dev-bounces@centos.org] On Behalf Of Gordan Bobic Sent: Tuesday, February 23, 2016 6:54 PM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] Gigabyte MP30-AR0

On 2016-02-23 11:47, Michael Howard wrote:

On 22/02/2016 20:08, Gordan Bobic wrote:

...

On 2016-02-22 17:29, Michael Howard wrote:

...

On 22/02/2016 17:04, Gordan Bobic wrote:

...

On 2016-02-22 16:57, Michael Howard wrote:

...

On 22/02/2016 16:47, Gordan Bobic wrote:

...

> Anyway, the install does in fact succeed, which is great. I > probably > should have stuck with the LVM partitioning scheme but hey ho, I > can > re run things now that I know UEFI is working. > > So, I have a minimal CentOS install with 4.2.0-0.21.el7.aarch64 > kernel. Great start, thanks to all. > > There is no networking so I need to get the installer to > recognise the > nics at install time.

So installer produces a bootable system, complete with a working kernel?

Yes, and no. It produces a bootable kernel.

Right, but how does that kernel get booted? u-boot -> kernel ? u-boot -> UEFI -> kernel ? u-boot -> UEFI -> grub2 -> kernel ?

...

...

Does it use grub2 or does it do some magic to boot the kernel straight from UEFI?

I haven't had the nerve to attempt to bun UEFI to SPI-NOR permanently,

Oh, I wasn't suggesting that. I cannot think of a good reason to burn UEFI into SPI-NOR vs. chain-loading it from u-boot, since the boot cascade is automatable.

...

so following the install (and any subsequent ones) I've loaded it from u-boot manually and then booted directly from UEFI from there. I can of course automate that I suppose.

Right, so post-install the boot process is: u-boot -> UEFI -> kernel ?

Yes.

Sweet! Now I just have to try to scrape together enough to get me one of those cometh pay day. :-D

...

...

No grub2 involved?

No.

I'll see if I can do something about that when mine arrives. It would be nice to have it working the same way x86 UEFI works.

With my pre-occupation with having no networking, I gave you some bum info.

Oh... No NIC driver? Or something else missing?

Grub2 is indeed involved.

Oh, awesome, so it works just like x86 UEFI, then. That is excellent news indeed. :)

Many thanks.

Gordan _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev

Thanks, Mike.

I never used the graphical installer before, but adding ip=dhcp to the grub command line does the trick then.

-Phong

-----Original Message----- From: arm-dev-bounces@centos.org [mailto:arm-dev-bounces@centos.org] On Behalf Of Michael Howard Sent: Tuesday, February 23, 2016 7:15 PM To: arm-dev@centos.org Subject: Re: [Arm-dev] Gigabyte MP30-AR0

On 23/02/2016 11:58, Phong Vo wrote:

I see that CentOS installer somehow does not detect network, so it gives text-based installation. However, once installation is finished, check your /etc/sysconfig/network-scripts/ifcfg-eth0 (or something similar).

Make sure BOOTPROTO=dhcp ONBOOT=y

Change ONBOOT to y and reboot should get network working.

Hi,

Yes, I did that but it was still no go. The problem with the installed system was that I hadn't set the hardware address in UEFI (set MAC0 xx:xx:xx:xx:xx:xx), after that networking worked.

The installer still didn't detect a connection on any of the nics, though I could assign an ip manually at the shell. Editing grub command line before running the installer cured that issue.

Cheers,

On 2016-02-23 12:07, Michael Howard wrote:

On 23/02/2016 11:53, Gordan Bobic wrote:

...

On 2016-02-23 11:47, Michael Howard wrote:

...

On 22/02/2016 20:08, Gordan Bobic wrote:

...

On 2016-02-22 17:29, Michael Howard wrote:

...

On 22/02/2016 17:04, Gordan Bobic wrote:

...

On 2016-02-22 16:57, Michael Howard wrote: > On 22/02/2016 16:47, Gordan Bobic wrote: > >>> Anyway, the install does in fact succeed, which is great. I >>> probably >>> should have stuck with the LVM partitioning scheme but hey ho, >>> I can >>> re run things now that I know UEFI is working. >>> >>> So, I have a minimal CentOS install with 4.2.0-0.21.el7.aarch64 >>> kernel. Great start, thanks to all. >>> >>> There is no networking so I need to get the installer to >>> recognise the >>> nics at install time. >> >> So installer produces a bootable system, complete with a working >> kernel? > > Yes, and no. It produces a bootable kernel.

Right, but how does that kernel get booted? u-boot -> kernel ? u-boot -> UEFI -> kernel ? u-boot -> UEFI -> grub2 -> kernel ?

>> Does it use grub2 or does it do some magic to boot the kernel >> straight >> from UEFI? >> > > I haven't had the nerve to attempt to bun UEFI to SPI-NOR > permanently,

Oh, I wasn't suggesting that. I cannot think of a good reason to burn UEFI into SPI-NOR vs. chain-loading it from u-boot, since the boot cascade is automatable.

> so following the install (and any subsequent ones) I've loaded it > from > u-boot manually and then booted directly from UEFI from there. I > can > of course automate that I suppose.

Right, so post-install the boot process is: u-boot -> UEFI -> kernel ?

Yes.

Sweet! Now I just have to try to scrape together enough to get me one of those cometh pay day. :-D

...

...

No grub2 involved?

No.

I'll see if I can do something about that when mine arrives. It would be nice to have it working the same way x86 UEFI works.

With my pre-occupation with having no networking, I gave you some bum info.

Oh... No NIC driver? Or something else missing?

No, not a driver issue. On my first install the installer just wouldn't accept that the nic(s) were indeed connected. After the install the system recognised that eth0, eth1 & eth2 existed but they each had a hardware address of ff:ff:ff:ff:ff:ff and no ip address. To resolve that I needed to set the hardware addresses in UEFI and they then shone through. They were correctly set in u-boot.

The installer still wouldn't accept the nic(s) were connected even when set in UEFI. I could assign an ip using the installer shell on [F2] but by then the installer had given up on vnc.

No VGA framebuffer support gets detected by the installer?

In the end, I edited the grub command line and appended ip, netmask, gateway and vnc, after which I got a gui install over vnc. Don't yet know if X11 works on the installed system, I haven't tried.

I see, so is the installer running over serial console or VGA/USB console?

Gordan

You'll be able to get a graphical interface on some cards that don't require POSTing by the EFI "BIOS". Cards that do require this (eg on x86) contain EFI ROM code compiled for x86 that won't be run on ARM (this is being fixed). But the Tianocore on that board isn't setup to do a graphical console anyway even if that works. So this is why you won't get graphics until after boot when the installer starts - if you have a card that can self-initialize. That's many modern ones but not always "some random play card I had left lying around" that folks often use when testing.

Marcin in the Fedora community has many good points on his blog around cards he has tested.

Jon.

On 2016-02-29 16:27, Phong Vo wrote:

This board has a VGA component belonging to the AST2400 BMC (but connected to the SoC PCIe). VGA console should be working fine with the installer up to Linux. Graphical interface is working but would require a little fix to the xorg mode setting driver to correctly detect the PCI ID of the VGA device. Talking about this, which path should we take to get this fix to the Xorg driver?

A link to a patch would be really handy. Shame to not have a working Xorg driver while it is being upstreamed.

Gordan

On 22/02/2016 20:08, Gordan Bobic wrote:

On 2016-02-22 17:29, Michael Howard wrote:

...

On 22/02/2016 17:04, Gordan Bobic wrote:

...

On 2016-02-22 16:57, Michael Howard wrote:

...

On 22/02/2016 16:47, Gordan Bobic wrote:

...

...

Anyway, the install does in fact succeed, which is great. I probably should have stuck with the LVM partitioning scheme but hey ho, I can re run things now that I know UEFI is working.

So, I have a minimal CentOS install with 4.2.0-0.21.el7.aarch64 kernel. Great start, thanks to all.

There is no networking so I need to get the installer to recognise the nics at install time.

So installer produces a bootable system, complete with a working kernel?

Yes, and no. It produces a bootable kernel.

Right, but how does that kernel get booted? u-boot -> kernel ? u-boot -> UEFI -> kernel ? u-boot -> UEFI -> grub2 -> kernel ?

...

...

Does it use grub2 or does it do some magic to boot the kernel straight from UEFI?

I haven't had the nerve to attempt to bun UEFI to SPI-NOR permanently,

Oh, I wasn't suggesting that. I cannot think of a good reason to burn UEFI into SPI-NOR vs. chain-loading it from u-boot, since the boot cascade is automatable.

...

so following the install (and any subsequent ones) I've loaded it from u-boot manually and then booted directly from UEFI from there. I can of course automate that I suppose.

Right, so post-install the boot process is: u-boot -> UEFI -> kernel ?

Yes.

Sweet! Now I just have to try to scrape together enough to get me one of those cometh pay day. :-D

...

...

No grub2 involved?

No.

I'll see if I can do something about that when mine arrives. It would be nice to have it working the same way x86 UEFI works.

On a semi-related note, is it possible to mount an armv5tel or armv7hl image, and chroot into it? Does that work? Or is aarch64 not binary backward compatible with 32-bit ARM binaries like x86-64 is?

Just to let you know, I can't get this to work. aarch64 is supposed to be binary compatible, with the correct libraries installed, but I'm thinking the cpu isn't.

All I get is 'cannot execute binary file: Exec format error', regardless of what I try.

Cheers, Mike.

Indeed. The architecture contains a 32-bit backward compatible component (that is optional in 64-bit ARM servers[0], but included in the one that you are using) and it is technically possible to install the libraries side by side. However the upstream that Cent is using is intentionally engineered never to support that case. It sounds harsh now, but there is no 32-bit server legacy, we have 32-bit VMs, you could build a 32-bit container if you really wanted, and in a couple of years we will all be wondering why we ever cared about 32-bit in the first place on ARM servers.

Jon.

[0] That was my doing. It is time to move on from 32-bit and not create a legacy, dragging everyone's power/performance efficiency down having to implement expensive 32-bit backward compatibility that people don't actually need. Recompile the software and move forward.

On 2016-02-29 15:51, Jim Perrin wrote:

On 02/29/2016 09:20 AM, Michael Howard wrote:

...

...

On a semi-related note, is it possible to mount an armv5tel or armv7hl image, and chroot into it? Does that work? Or is aarch64 not binary backward compatible with 32-bit ARM binaries like x86-64 is?

Just to let you know, I can't get this to work. aarch64 is supposed to be binary compatible, with the correct libraries installed, but I'm thinking the cpu isn't.

All I get is 'cannot execute binary file: Exec format error', regardless of what I try.

This isn't expected to work currently, no.

How come? I seem to recall that Nvidia until recently (if they aren't _still_ doing it) shipped their Tegra K1 and X1 images with aarch64 kernels and armv7hl userspace, which means that this should work just fine.

So in this case, what gives? Why does running armv5tel in a chroot not work with aarch64 kernel?

Gordan

On 01/03/2016 22:26, Richard W.M. Jones wrote:

On Mon, Feb 29, 2016 at 03:20:03PM +0000, Michael Howard wrote:

...

Just to let you know, I can't get this to work. aarch64 is supposed to be binary compatible, with the correct libraries installed, but I'm thinking the cpu isn't.

All I get is 'cannot execute binary file: Exec format error', regardless of what I try.

As I understand it the problem is page size - 64K was chosen by Red Hat for aarch64, where as 4K is the norm on armv7.

Anyway, you can run a 32 bit VM and it works well -- in fact a lot faster than regular 32 bit armv7 hardware.

Yes, with CONFIG_ARM64_4K_PAGES=y and CONFIG_COMPAT=y, 32 bit binaries run fine.

On 13/03/16 09:20, Gordan Bobic wrote:

Is there a driver to access IPMI internally without connecting to the BMC over the network?

# ipmitool sensor Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory Get Device ID command failed Unable to open SDR for reading

It works over the network, though: # ipmitool -I lanplus -H 192.168.2.43 -U admin -P password sensor CPU0_TEMP | 78.000 | degrees C | ok | na | 0.000 | 5.000 | 100.000 | 105.000 | na DIMM_P0_A0 | na | degrees C | na | na | 0.000 | 5.000 | 75.000 | 80.000 | na DIMM_P0_A1 | na | degrees C | na | na | 0.000 | 5.000 | 75.000 | 80.000 | na DIMM_P0_B0 | 36.000 | degrees C | ok | na | 0.000 | 5.000 | 75.000 | 80.000 | na DIMM_P0_B1 | na | degrees C | na | na | 0.000 | 5.000 | 75.000 | 80.000 | na DIMM_P0_C0 | 40.000 | degrees C | ok | na | 0.000 | 5.000 | 75.000 | 80.000 | na DIMM_P0_C1 | na | degrees C | na | na | 0.000 | 5.000 | 75.000 | 80.000 | na DIMM_P0_D0 | 40.000 | degrees C | ok | na | 0.000 | 5.000 | 75.000 | 80.000 | na DIMM_P0_D1 | na | degrees C | na | na | 0.000 | 5.000 | 75.000 | 80.000 | na P12V | 12.064 | Volts | ok | na | 10.324 | 10.788 | 13.224 | 13.688 | na P5V | 5.037 | Volts | ok | na | 4.290 | 4.507 | 5.495 | 5.688 | na P3V3 | 3.302 | Volts | ok | na | 2.828 | 2.970 | 3.618 | 3.760 | na P5V_STBY | 5.061 | Volts | ok | na | 4.290 | 4.507 | 5.495 | 5.688 | na P_VBAT | 3.074 | Volts | ok | na | 2.581 | 2.697 | na | na | na P_VCCP | 0.980 | Volts | ok | na | 0.421 | 0.451 | 1.431 | 1.509 | na P_1V2_HUB | 1.205 | Volts | ok | na | 1.029 | 1.078 | 1.323 | 1.372 | na P_VDDQ_AB | 1.499 | Volts | ok | na | 1.284 | 1.343 | 1.656 | 1.715 | na P_VDDQ_CD | 1.509 | Volts | ok | na | 1.284 | 1.343 | 1.656 | 1.715 | na P_0V9_VDD | 0.960 | Volts | ok | na | 0.774 | 0.813 | 0.990 | 1.029 | na P_1V5_VDD | 1.509 | Volts | ok | na | 1.284 | 1.352 | 1.646 | 1.705 | na P_2V5_VDD | 2.517 | Volts | ok | na | 2.154 | 2.251 | 2.747 | 2.856 | na P_1V8_VDD | 1.813 | Volts | ok | na | 1.548 | 1.627 | 1.980 | 2.048 | na CPU0_FAN | 6100.000 | RPM | ok | na | 600.000 | 800.000 | na | na | na SYS_FAN1 | 900.000 | RPM | ok | na | 600.000 | 800.000 | na | na | na SYS_FAN2 | 1400.000 | RPM | ok | na | 600.000 | 800.000 | na | na | na SYS_FAN3 | na | RPM | na | na | 600.000 | 800.000 | na | na | na SYS_FAN4 | na | RPM | na | na | 600.000 | 800.000 | na | na | na CPU0 | 0x0 | discrete | 0x8080| na | na | na | na | na | na MB_TEMP1 | 39.000 | degrees C | ok | na | 0.000 | 5.000 | 55.000 | 60.000 | na MB_TEMP2 | 34.000 | degrees C | ok | na | 0.000 | 5.000 | 55.000 | 60.000 | na MB_TEMP3 | 29.000 | degrees C | ok | na | 0.000 | 5.000 | 55.000 | 60.000 | na SEL | 0x0 | discrete | 0x0080| na | na | na | na | na | na

There is one obvious error in the output: DIMM_P0_A0 | na | degrees C | na | na | 0.000 | 5.000 | 75.000 | 80.000 | na

There is a DIMM definitely in that slot, but it doesn't have a temperature reading. It's the exact same part and batch as the other 3, so I'd expect there to be a number there. Firmware bug?

And to answer my own question, yes, it's a firmware bug. Updating the BMC firmware downloadable from the Gigabyte site to 3.56 (board shipped with 3.14) fixes the sensor reading on DIMM_P0_A0.

Gordan

On 2016-03-14 15:00, Gordan Bobic wrote:

On 2016-03-01 22:32, Michael Howard wrote:

...

On 01/03/2016 22:26, Richard W.M. Jones wrote:

...

On Mon, Feb 29, 2016 at 03:20:03PM +0000, Michael Howard wrote:

...

Just to let you know, I can't get this to work. aarch64 is supposed to be binary compatible, with the correct libraries installed, but I'm thinking the cpu isn't.

All I get is 'cannot execute binary file: Exec format error', regardless of what I try.

As I understand it the problem is page size - 64K was chosen by Red Hat for aarch64, where as 4K is the norm on armv7.

Anyway, you can run a 32 bit VM and it works well -- in fact a lot faster than regular 32 bit armv7 hardware.

Yes, with CONFIG_ARM64_4K_PAGES=y and CONFIG_COMPAT=y, 32 bit binaries run fine.

I built a kernel with these options enabled, but chrooting into an armv5tel subtree segfaults immediately. :-(

# grep -E "CONFIG_COMPAT=|CONFIG_ARM64_4K_PAGES=" /boot/config-4.4.5 CONFIG_ARM64_4K_PAGES=y CONFIG_COMPAT=y

# chroot /orcone/docker/rsel6/ Segmentation fault

The chroot is armv5tel soft-float, which I think should work. Oddly, I see no mention of a segfault in dmesg or in /var/log/messages on the host...

# strace chroot /orcone/docker/media/ execve("/sbin/chroot", ["chroot", "/orcone/docker/media/"], [/* 18 vars */]) = 0 brk(0) = 0x153eb000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98108000 faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=23876, ...}) = 0 mmap(NULL, 23876, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f98102000 close(3) = 0 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\270\r\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1801536, ...}) = 0 mmap(NULL, 1528796, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f97f66000 mprotect(0x7f980c2000, 65536, PROT_NONE) = 0 mmap(0x7f980d2000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c000) = 0x7f980d2000 mmap(0x7f980d8000, 13276, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f980d8000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98101000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98100000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f980ff000 mprotect(0x7f980d2000, 16384, PROT_READ) = 0 mprotect(0x41f000, 4096, PROT_READ) = 0 mprotect(0x7f9810b000, 4096, PROT_READ) = 0 munmap(0x7f98102000, 23876) = 0 brk(0) = 0x153eb000 brk(0x1540c000) = 0x1540c000 brk(0) = 0x1540c000 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=109669264, ...}) = 0 mmap(NULL, 109669264, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f916cf000 close(3) = 0 chroot("/orcone/docker/media/") = 0 chdir("/") = 0 execve("/bin/bash", ["/bin/bash", "-i"], [/* 18 vars */]) = -1053305918634065933 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +++ killed by SIGSEGV +++ Segmentation fault

What am I doing differently?

Just to make sure we are as much on the same page as possible, here is the minimal chroot I am trying: http://ftp.redsleeve.org/pub/el6-staging/rootfs/rsel6-minimal.tar.xz

Built from the latest RedSleeve 6 binaries using: yum --installroot=/some/path install @core

Can you extract that into an empty folder and chroot into it from your aarch64 CentOS 7 install? Does it work for you or does it segfault?

If it works for you, any chance you could post your kernel config somewhere? It's the only thing I can think of that could plausibly be causeing the discrepancy (I am on 4.4.5 and IIRC you were on 4.5rc).

Gordan

On 2016-03-14 17:13, Michael Howard wrote:

On 14/03/2016 16:56, Gordan Bobic wrote:

...

On 2016-03-14 15:00, Gordan Bobic wrote:

...

On 2016-03-01 22:32, Michael Howard wrote:

...

On 01/03/2016 22:26, Richard W.M. Jones wrote:

...

On Mon, Feb 29, 2016 at 03:20:03PM +0000, Michael Howard wrote:

...

Just to let you know, I can't get this to work. aarch64 is supposed to be binary compatible, with the correct libraries installed, but I'm thinking the cpu isn't.

All I get is 'cannot execute binary file: Exec format error', regardless of what I try.

As I understand it the problem is page size - 64K was chosen by Red Hat for aarch64, where as 4K is the norm on armv7.

Anyway, you can run a 32 bit VM and it works well -- in fact a lot faster than regular 32 bit armv7 hardware.

Yes, with CONFIG_ARM64_4K_PAGES=y and CONFIG_COMPAT=y, 32 bit binaries run fine.

I built a kernel with these options enabled, but chrooting into an armv5tel subtree segfaults immediately. :-(

# grep -E "CONFIG_COMPAT=|CONFIG_ARM64_4K_PAGES=" /boot/config-4.4.5 CONFIG_ARM64_4K_PAGES=y CONFIG_COMPAT=y

# chroot /orcone/docker/rsel6/ Segmentation fault

The chroot is armv5tel soft-float, which I think should work. Oddly, I see no mention of a segfault in dmesg or in /var/log/messages on the host...

# strace chroot /orcone/docker/media/ execve("/sbin/chroot", ["chroot", "/orcone/docker/media/"], [/* 18 vars */]) = 0 brk(0) = 0x153eb000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98108000 faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=23876, ...}) = 0 mmap(NULL, 23876, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f98102000 close(3) = 0 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\270\r\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1801536, ...}) = 0 mmap(NULL, 1528796, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f97f66000 mprotect(0x7f980c2000, 65536, PROT_NONE) = 0 mmap(0x7f980d2000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c000) = 0x7f980d2000 mmap(0x7f980d8000, 13276, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f980d8000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98101000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98100000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f980ff000 mprotect(0x7f980d2000, 16384, PROT_READ) = 0 mprotect(0x41f000, 4096, PROT_READ) = 0 mprotect(0x7f9810b000, 4096, PROT_READ) = 0 munmap(0x7f98102000, 23876) = 0 brk(0) = 0x153eb000 brk(0x1540c000) = 0x1540c000 brk(0) = 0x1540c000 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=109669264, ...}) = 0 mmap(NULL, 109669264, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f916cf000 close(3) = 0 chroot("/orcone/docker/media/") = 0 chdir("/") = 0 execve("/bin/bash", ["/bin/bash", "-i"], [/* 18 vars */]) = -1053305918634065933 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +++ killed by SIGSEGV +++ Segmentation fault

What am I doing differently?

Just to make sure we are as much on the same page as possible, here is the minimal chroot I am trying: http://ftp.redsleeve.org/pub/el6-staging/rootfs/rsel6-minimal.tar.xz

Built from the latest RedSleeve 6 binaries using: yum --installroot=/some/path install @core

Can you extract that into an empty folder and chroot into it from your aarch64 CentOS 7 install? Does it work for you or does it segfault?

If it works for you, any chance you could post your kernel config somewhere? It's the only thing I can think of that could plausibly be causeing the discrepancy (I am on 4.4.5 and IIRC you were on 4.5rc).

Downloading now but it will be a couple of hours before I can check it out.

Thanks, most appreciated. You may want to re-download, as I literally just replaced with tar ball with a more compressed version. If that happened during your download, what you get may end up being corrupted (check whether it matches the md5 checksum).

Gordan

On 2016-03-14 21:41, Michael Howard wrote:

On 14/03/2016 17:16, Gordan Bobic wrote:

...

On 2016-03-14 17:13, Michael Howard wrote:

...

On 14/03/2016 16:56, Gordan Bobic wrote:

...

On 2016-03-14 15:00, Gordan Bobic wrote:

...

On 2016-03-01 22:32, Michael Howard wrote:

...

On 01/03/2016 22:26, Richard W.M. Jones wrote: > On Mon, Feb 29, 2016 at 03:20:03PM +0000, Michael Howard wrote: >> Just to let you know, I can't get this to work. aarch64 is >> supposed >> to be binary compatible, with the correct libraries installed, >> but >> I'm thinking the cpu isn't. >> >> All I get is 'cannot execute binary file: Exec format error', >> regardless of what I try. > As I understand it the problem is page size - 64K was chosen by > Red Hat for aarch64, where as 4K is the norm on armv7. > > Anyway, you can run a 32 bit VM and it works well -- in fact a > lot > faster than regular 32 bit armv7 hardware. >

Yes, with CONFIG_ARM64_4K_PAGES=y and CONFIG_COMPAT=y, 32 bit binaries run fine.

I built a kernel with these options enabled, but chrooting into an armv5tel subtree segfaults immediately. :-(

# grep -E "CONFIG_COMPAT=|CONFIG_ARM64_4K_PAGES=" /boot/config-4.4.5 CONFIG_ARM64_4K_PAGES=y CONFIG_COMPAT=y

# chroot /orcone/docker/rsel6/ Segmentation fault

The chroot is armv5tel soft-float, which I think should work. Oddly, I see no mention of a segfault in dmesg or in /var/log/messages on the host...

# strace chroot /orcone/docker/media/ execve("/sbin/chroot", ["chroot", "/orcone/docker/media/"], [/* 18 vars */]) = 0 brk(0) = 0x153eb000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98108000 faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=23876, ...}) = 0 mmap(NULL, 23876, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f98102000 close(3) = 0 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\270\r\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1801536, ...}) = 0 mmap(NULL, 1528796, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f97f66000 mprotect(0x7f980c2000, 65536, PROT_NONE) = 0 mmap(0x7f980d2000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c000) = 0x7f980d2000 mmap(0x7f980d8000, 13276, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f980d8000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98101000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98100000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f980ff000 mprotect(0x7f980d2000, 16384, PROT_READ) = 0 mprotect(0x41f000, 4096, PROT_READ) = 0 mprotect(0x7f9810b000, 4096, PROT_READ) = 0 munmap(0x7f98102000, 23876) = 0 brk(0) = 0x153eb000 brk(0x1540c000) = 0x1540c000 brk(0) = 0x1540c000 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=109669264, ...}) = 0 mmap(NULL, 109669264, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f916cf000 close(3) = 0 chroot("/orcone/docker/media/") = 0 chdir("/") = 0 execve("/bin/bash", ["/bin/bash", "-i"], [/* 18 vars */]) = -1053305918634065933 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +++ killed by SIGSEGV +++ Segmentation fault

What am I doing differently?

Just to make sure we are as much on the same page as possible, here is the minimal chroot I am trying: http://ftp.redsleeve.org/pub/el6-staging/rootfs/rsel6-minimal.tar.xz

Built from the latest RedSleeve 6 binaries using: yum --installroot=/some/path install @core

Can you extract that into an empty folder and chroot into it from your aarch64 CentOS 7 install? Does it work for you or does it segfault?

If it works for you, any chance you could post your kernel config somewhere? It's the only thing I can think of that could plausibly be causeing the discrepancy (I am on 4.4.5 and IIRC you were on 4.5rc).

Downloading now but it will be a couple of hours before I can check it out.

Thanks, most appreciated. You may want to re-download, as I literally just replaced with tar ball with a more compressed version. If that happened during your download, what you get may end up being corrupted (check whether it matches the md5 checksum).

I did re-download, just in case. It all works here as expected.

[root@mp30 ~]# chroot ~/CHROOT2 [root@mp30 ~]# echo "nameserver 192.168.1.2" > /etc/resolv.conf [root@mp30 /]# yum search linux base | 3.8 kB 00:00 updates | 3.0 kB 00:00 ============================== N/S Matched: linux ============================== libselinux.armv5tel : SELinux library and simple utilities libselinux-utils.armv5tel : SELinux libselinux utilies python-linux-procfs.noarch : Linux /proc abstraction classes selinux-policy.noarch : SELinux policy configuration selinux-policy-doc.noarch : SELinux policy documentation selinux-policy-minimum.noarch : SELinux minimum base policy selinux-policy-mls.noarch : SELinux mls base policy selinux- SELinux policy compiler epel-release.noarch : Extra Packages for Enterprise Linux repository : configuration filesystem.armv5tel : The basic directory layout for a Linux system iptables.armv5tel : Tools for managing Linux kernel packet filtering : capabilities libsemanage.armv5tel : SELinux binary policy manipulation library libsepol.armv5tel : SELinux binary policy manipulation library man-pages.noarch : Man (manual) pages from the Linux Documentation Project man-pages-cs.noarch : Czech man pages from the Linux Documentation Project man-pages-es.noarch : Spanish man pages from the Linux Documentation Project man-pages-fr.noarch : French version of the Linux man-pages man-pages-it.noarch : Italian man (manual) pages from the Linux Documentation : Project man-pages-pl.noarch : Polish man pages from the Linux Documentation Project man-pages-ru.noarch : Russian man pages from the Linux Documentation Project man-pages-uk.noarch : Ukrainian man pages from the Linux Documentation Project policycoreutils.armv5tel : SELinux policy core utilities redhat-bookmarks.noarch : Red Hat Enterprise Linux bookmarks redhat-indexhtml.noarch : Browser default start page for Red Hat Enterprise : Linux redsleeve-release.armv5tel : Red Sleeve Enterprise Linux release file rhel-guest-image-6.noarch : Red Hat Enterprise Linux Guest Images util-linux-ng.armv5tel : A collection of basic system utilities

Name and summary matches only, use "search all" for everything. [root@mp30 /]# exit [root@mp30 ~]#

That is most puzzling. Any chance you could please post your kernel config file (pastebin it or similar)? I'd like to try to build one exactly the same and see if I can get it working.

Many thanks.

Gordan

On 2016-03-14 22:14, Michael Howard wrote:

On 14/03/2016 21:47, Gordan Bobic wrote:

...

On 2016-03-14 21:41, Michael Howard wrote:

...

On 14/03/2016 17:16, Gordan Bobic wrote:

...

On 2016-03-14 17:13, Michael Howard wrote:

...

On 14/03/2016 16:56, Gordan Bobic wrote:

...

On 2016-03-14 15:00, Gordan Bobic wrote: > On 2016-03-01 22:32, Michael Howard wrote: >> On 01/03/2016 22:26, Richard W.M. Jones wrote: >>> On Mon, Feb 29, 2016 at 03:20:03PM +0000, Michael Howard wrote: >>>> Just to let you know, I can't get this to work. aarch64 is >>>> supposed >>>> to be binary compatible, with the correct libraries installed, >>>> but >>>> I'm thinking the cpu isn't. >>>> >>>> All I get is 'cannot execute binary file: Exec format error', >>>> regardless of what I try. >>> As I understand it the problem is page size - 64K was chosen by >>> Red Hat for aarch64, where as 4K is the norm on armv7. >>> >>> Anyway, you can run a 32 bit VM and it works well -- in fact a >>> lot >>> faster than regular 32 bit armv7 hardware. >>> >> >> Yes, with CONFIG_ARM64_4K_PAGES=y and CONFIG_COMPAT=y, 32 bit >> binaries run fine. > > I built a kernel with these options enabled, but chrooting into > an > armv5tel subtree segfaults immediately. :-( > > # grep -E "CONFIG_COMPAT=|CONFIG_ARM64_4K_PAGES=" > /boot/config-4.4.5 > CONFIG_ARM64_4K_PAGES=y > CONFIG_COMPAT=y > > # chroot /orcone/docker/rsel6/ > Segmentation fault > > The chroot is armv5tel soft-float, which I think should work. > Oddly, I see no mention of a segfault in dmesg or in > /var/log/messages > on the host... > > # strace chroot /orcone/docker/media/ > execve("/sbin/chroot", ["chroot", "/orcone/docker/media/"], [/* > 18 vars */]) = 0 > brk(0) = 0x153eb000 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, > 0) = 0x7f98108000 > faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No > such > file or directory) > openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 > fstat(3, {st_mode=S_IFREG|0644, st_size=23876, ...}) = 0 > mmap(NULL, 23876, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f98102000 > close(3) = 0 > openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 > read(3, > "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\270\r\2\0\0\0\0\0"..., > 832) = 832 > fstat(3, {st_mode=S_IFREG|0755, st_size=1801536, ...}) = 0 > mmap(NULL, 1528796, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_DENYWRITE, 3, > 0) = 0x7f97f66000 > mprotect(0x7f980c2000, 65536, PROT_NONE) = 0 > mmap(0x7f980d2000, 24576, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c000) = 0x7f980d2000 > mmap(0x7f980d8000, 13276, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f980d8000 > close(3) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, > 0) = 0x7f98101000 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, > 0) = 0x7f98100000 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, > 0) = 0x7f980ff000 > mprotect(0x7f980d2000, 16384, PROT_READ) = 0 > mprotect(0x41f000, 4096, PROT_READ) = 0 > mprotect(0x7f9810b000, 4096, PROT_READ) = 0 > munmap(0x7f98102000, 23876) = 0 > brk(0) = 0x153eb000 > brk(0x1540c000) = 0x1540c000 > brk(0) = 0x1540c000 > openat(AT_FDCWD, "/usr/lib/locale/locale-archive", > O_RDONLY|O_CLOEXEC) = 3 > fstat(3, {st_mode=S_IFREG|0644, st_size=109669264, ...}) = 0 > mmap(NULL, 109669264, PROT_READ, MAP_PRIVATE, 3, 0) = > 0x7f916cf000 > close(3) = 0 > chroot("/orcone/docker/media/") = 0 > chdir("/") = 0 > execve("/bin/bash", ["/bin/bash", "-i"], [/* 18 vars */]) = > -1053305918634065933 > --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- > +++ killed by SIGSEGV +++ > Segmentation fault > > > What am I doing differently?

Just to make sure we are as much on the same page as possible, here is the minimal chroot I am trying: http://ftp.redsleeve.org/pub/el6-staging/rootfs/rsel6-minimal.tar.xz

Built from the latest RedSleeve 6 binaries using: yum --installroot=/some/path install @core

Can you extract that into an empty folder and chroot into it from your aarch64 CentOS 7 install? Does it work for you or does it segfault?

If it works for you, any chance you could post your kernel config somewhere? It's the only thing I can think of that could plausibly be causeing the discrepancy (I am on 4.4.5 and IIRC you were on 4.5rc).

Downloading now but it will be a couple of hours before I can check it out.

Thanks, most appreciated. You may want to re-download, as I literally just replaced with tar ball with a more compressed version. If that happened during your download, what you get may end up being corrupted (check whether it matches the md5 checksum).

I did re-download, just in case. It all works here as expected.

[root@mp30 ~]# chroot ~/CHROOT2 [root@mp30 ~]# echo "nameserver 192.168.1.2" > /etc/resolv.conf [root@mp30 /]# yum search linux base | 3.8 kB 00:00 updates | 3.0 kB 00:00 ============================== N/S Matched: linux ============================== libselinux.armv5tel : SELinux library and simple utilities libselinux-utils.armv5tel : SELinux libselinux utilies python-linux-procfs.noarch : Linux /proc abstraction classes selinux-policy.noarch : SELinux policy configuration selinux-policy-doc.noarch : SELinux policy documentation selinux-policy-minimum.noarch : SELinux minimum base policy selinux-policy-mls.noarch : SELinux mls base policy selinux- SELinux policy compiler epel-release.noarch : Extra Packages for Enterprise Linux repository : configuration filesystem.armv5tel : The basic directory layout for a Linux system iptables.armv5tel : Tools for managing Linux kernel packet filtering : capabilities libsemanage.armv5tel : SELinux binary policy manipulation library libsepol.armv5tel : SELinux binary policy manipulation library man-pages.noarch : Man (manual) pages from the Linux Documentation Project man-pages-cs.noarch : Czech man pages from the Linux Documentation Project man-pages-es.noarch : Spanish man pages from the Linux Documentation Project man-pages-fr.noarch : French version of the Linux man-pages man-pages-it.noarch : Italian man (manual) pages from the Linux Documentation : Project man-pages-pl.noarch : Polish man pages from the Linux Documentation Project man-pages-ru.noarch : Russian man pages from the Linux Documentation Project man-pages-uk.noarch : Ukrainian man pages from the Linux Documentation Project policycoreutils.armv5tel : SELinux policy core utilities redhat-bookmarks.noarch : Red Hat Enterprise Linux bookmarks redhat-indexhtml.noarch : Browser default start page for Red Hat Enterprise : Linux redsleeve-release.armv5tel : Red Sleeve Enterprise Linux release file rhel-guest-image-6.noarch : Red Hat Enterprise Linux Guest Images util-linux-ng.armv5tel : A collection of basic system utilities

Name and summary matches only, use "search all" for everything. [root@mp30 /]# exit [root@mp30 ~]#

That is most puzzling. Any chance you could please post your kernel config file (pastebin it or similar)? I'd like to try to build one exactly the same and see if I can get it working.

No problem;

http://pastebin.com/4mrgmNGv

If all else fails (don't see why it should) I can put up the binary and modules so you can triple check. I didn't build an RPM as I came across a packaging problem, an aarch64/UTS_MACHINE issue I believe and I had no idea how to solve it nor could I spend any real time investigating it.

Thanks for this. I'm building a new kernel with your config now. Hoping to report success in the morning. :)

Gordan

On 2016-03-14 22:58, Gordan Bobic wrote:

On 2016-03-14 22:25, Gordan Bobic wrote:

...

On 2016-03-14 22:14, Michael Howard wrote:

...

On 14/03/2016 21:47, Gordan Bobic wrote:

...

On 2016-03-14 21:41, Michael Howard wrote:

...

On 14/03/2016 17:16, Gordan Bobic wrote:

...

On 2016-03-14 17:13, Michael Howard wrote: > On 14/03/2016 16:56, Gordan Bobic wrote: >> On 2016-03-14 15:00, Gordan Bobic wrote: >>> On 2016-03-01 22:32, Michael Howard wrote: >>>> On 01/03/2016 22:26, Richard W.M. Jones wrote: >>>>> On Mon, Feb 29, 2016 at 03:20:03PM +0000, Michael Howard >>>>> wrote: >>>>>> Just to let you know, I can't get this to work. aarch64 is >>>>>> supposed >>>>>> to be binary compatible, with the correct libraries >>>>>> installed, but >>>>>> I'm thinking the cpu isn't. >>>>>> >>>>>> All I get is 'cannot execute binary file: Exec format >>>>>> error', >>>>>> regardless of what I try. >>>>> As I understand it the problem is page size - 64K was chosen >>>>> by >>>>> Red Hat for aarch64, where as 4K is the norm on armv7. >>>>> >>>>> Anyway, you can run a 32 bit VM and it works well -- in fact >>>>> a lot >>>>> faster than regular 32 bit armv7 hardware. >>>>> >>>> >>>> Yes, with CONFIG_ARM64_4K_PAGES=y and CONFIG_COMPAT=y, 32 bit >>>> binaries run fine. >>> >>> I built a kernel with these options enabled, but chrooting into >>> an >>> armv5tel subtree segfaults immediately. :-( >>> >>> # grep -E "CONFIG_COMPAT=|CONFIG_ARM64_4K_PAGES=" >>> /boot/config-4.4.5 >>> CONFIG_ARM64_4K_PAGES=y >>> CONFIG_COMPAT=y >>> >>> # chroot /orcone/docker/rsel6/ >>> Segmentation fault >>> >>> The chroot is armv5tel soft-float, which I think should work. >>> Oddly, I see no mention of a segfault in dmesg or in >>> /var/log/messages >>> on the host... >>> >>> # strace chroot /orcone/docker/media/ >>> execve("/sbin/chroot", ["chroot", "/orcone/docker/media/"], [/* >>> 18 vars */]) = 0 >>> brk(0) = 0x153eb000 >>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_ANONYMOUS, -1, >>> 0) = 0x7f98108000 >>> faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No >>> such >>> file or directory) >>> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 >>> fstat(3, {st_mode=S_IFREG|0644, st_size=23876, ...}) = 0 >>> mmap(NULL, 23876, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f98102000 >>> close(3) = 0 >>> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 >>> read(3, >>> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\270\r\2\0\0\0\0\0"..., >>> 832) = 832 >>> fstat(3, {st_mode=S_IFREG|0755, st_size=1801536, ...}) = 0 >>> mmap(NULL, 1528796, PROT_READ|PROT_EXEC, >>> MAP_PRIVATE|MAP_DENYWRITE, 3, >>> 0) = 0x7f97f66000 >>> mprotect(0x7f980c2000, 65536, PROT_NONE) = 0 >>> mmap(0x7f980d2000, 24576, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c000) = >>> 0x7f980d2000 >>> mmap(0x7f980d8000, 13276, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f980d8000 >>> close(3) = 0 >>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_ANONYMOUS, -1, >>> 0) = 0x7f98101000 >>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_ANONYMOUS, -1, >>> 0) = 0x7f98100000 >>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_ANONYMOUS, -1, >>> 0) = 0x7f980ff000 >>> mprotect(0x7f980d2000, 16384, PROT_READ) = 0 >>> mprotect(0x41f000, 4096, PROT_READ) = 0 >>> mprotect(0x7f9810b000, 4096, PROT_READ) = 0 >>> munmap(0x7f98102000, 23876) = 0 >>> brk(0) = 0x153eb000 >>> brk(0x1540c000) = 0x1540c000 >>> brk(0) = 0x1540c000 >>> openat(AT_FDCWD, "/usr/lib/locale/locale-archive", >>> O_RDONLY|O_CLOEXEC) = 3 >>> fstat(3, {st_mode=S_IFREG|0644, st_size=109669264, ...}) = 0 >>> mmap(NULL, 109669264, PROT_READ, MAP_PRIVATE, 3, 0) = >>> 0x7f916cf000 >>> close(3) = 0 >>> chroot("/orcone/docker/media/") = 0 >>> chdir("/") = 0 >>> execve("/bin/bash", ["/bin/bash", "-i"], [/* 18 vars */]) = >>> -1053305918634065933 >>> --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} >>> --- >>> +++ killed by SIGSEGV +++ >>> Segmentation fault >>> >>> >>> What am I doing differently? >> >> Just to make sure we are as much on the same page as possible, >> here >> is the minimal chroot I am trying: >> http://ftp.redsleeve.org/pub/el6-staging/rootfs/rsel6-minimal.tar.xz >> >> Built from the latest RedSleeve 6 binaries using: >> yum --installroot=/some/path install @core >> >> Can you extract that into an empty folder and chroot into it >> from your aarch64 CentOS 7 install? Does it work for you or >> does it segfault? >> >> If it works for you, any chance you could post your kernel >> config somewhere? It's the only thing I can think of that >> could plausibly be causeing the discrepancy (I am on 4.4.5 >> and IIRC you were on 4.5rc). > > Downloading now but it will be a couple of hours before I can > check it out.

Thanks, most appreciated. You may want to re-download, as I literally just replaced with tar ball with a more compressed version. If that happened during your download, what you get may end up being corrupted (check whether it matches the md5 checksum).

I did re-download, just in case. It all works here as expected.

[root@mp30 ~]# chroot ~/CHROOT2 [root@mp30 ~]# echo "nameserver 192.168.1.2" > /etc/resolv.conf [root@mp30 /]# yum search linux base | 3.8 kB 00:00 updates | 3.0 kB 00:00 ============================== N/S Matched: linux ============================== libselinux.armv5tel : SELinux library and simple utilities libselinux-utils.armv5tel : SELinux libselinux utilies python-linux-procfs.noarch : Linux /proc abstraction classes selinux-policy.noarch : SELinux policy configuration selinux-policy-doc.noarch : SELinux policy documentation selinux-policy-minimum.noarch : SELinux minimum base policy selinux-policy-mls.noarch : SELinux mls base policy selinux- SELinux policy compiler epel-release.noarch : Extra Packages for Enterprise Linux repository : configuration filesystem.armv5tel : The basic directory layout for a Linux system iptables.armv5tel : Tools for managing Linux kernel packet filtering : capabilities libsemanage.armv5tel : SELinux binary policy manipulation library libsepol.armv5tel : SELinux binary policy manipulation library man-pages.noarch : Man (manual) pages from the Linux Documentation Project man-pages-cs.noarch : Czech man pages from the Linux Documentation Project man-pages-es.noarch : Spanish man pages from the Linux Documentation Project man-pages-fr.noarch : French version of the Linux man-pages man-pages-it.noarch : Italian man (manual) pages from the Linux Documentation : Project man-pages-pl.noarch : Polish man pages from the Linux Documentation Project man-pages-ru.noarch : Russian man pages from the Linux Documentation Project man-pages-uk.noarch : Ukrainian man pages from the Linux Documentation Project policycoreutils.armv5tel : SELinux policy core utilities redhat-bookmarks.noarch : Red Hat Enterprise Linux bookmarks redhat-indexhtml.noarch : Browser default start page for Red Hat Enterprise : Linux redsleeve-release.armv5tel : Red Sleeve Enterprise Linux release file rhel-guest-image-6.noarch : Red Hat Enterprise Linux Guest Images util-linux-ng.armv5tel : A collection of basic system utilities

Name and summary matches only, use "search all" for everything. [root@mp30 /]# exit [root@mp30 ~]#

That is most puzzling. Any chance you could please post your kernel config file (pastebin it or similar)? I'd like to try to build one exactly the same and see if I can get it working.

No problem;

http://pastebin.com/4mrgmNGv

If all else fails (don't see why it should) I can put up the binary and modules so you can triple check. I didn't build an RPM as I came across a packaging problem, an aarch64/UTS_MACHINE issue I believe and I had no idea how to solve it nor could I spend any real time investigating it.

Thanks for this. I'm building a new kernel with your config now. Hoping to report success in the morning. :)

I forgot how fast this thing builds the kernel. :) I'm happy to say that 4.5.0 release kernel works fine, and I can run chroots!

Thanks for your help Michael, I really appreciate it.

Now to see if I can make the same thing work with the LT 4.4.x kernel...

Using that same config with 4.4.5 (make oldconfig, take all defaults) also works. There must have been an extra config option that I missed the first time around.

Gordan

On 2016-03-14 22:14, Michael Howard wrote:

I didn't build an RPM as I came across a packaging problem, an aarch64/UTS_MACHINE issue I believe and I had no idea how to solve it nor could I spend any real time investigating it.

I have put together some kernel rpms: http://ftp.redsleeve.org/pub/misc/aarch64/

On 2016-03-17 08:05, Michael Howard wrote:

On 17/03/2016 01:24, Gordan Bobic wrote:

...

On 2016-03-14 22:14, Michael Howard wrote:

...

I didn't build an RPM as I came across a packaging problem, an aarch64/UTS_MACHINE issue I believe and I had no idea how to solve it nor could I spend any real time investigating it.

I have put together some kernel rpms: http://ftp.redsleeve.org/pub/misc/aarch64/

Cool. Did you have any problems? make rpm-pkg failed for me at packaging stage, with an error something like;

scripts/Makefile.fwinst:43: *** mixed implicit and static pattern rules. Stop. make[2]: *** [_modinst_post] Error 2

Yes, I get the same error if I use kernel's built in rpm making support.

The src.rpm at the path above is derived from my modified x86-64 3.18.x LT kernel package, which is in turn derived from elrepo's mainline kernel .spec file.

Gordan

On 17/03/16 08:05, Michael Howard wrote:

On 17/03/2016 01:24, Gordan Bobic wrote:

...

On 2016-03-14 22:14, Michael Howard wrote:

...

I didn't build an RPM as I came across a packaging problem, an aarch64/UTS_MACHINE issue I believe and I had no idea how to solve it nor could I spend any real time investigating it.

I have put together some kernel rpms: http://ftp.redsleeve.org/pub/misc/aarch64/

Cool. Did you have any problems? make rpm-pkg failed for me at packaging stage, with an error something like;

|scripts/Makefile.fwinst:43: *** mixed implicit and static pattern rules. Stop. make[2]: *** [_modinst_post] Error 2|

Speaking of the kernel, I seem to be having a problem. On the kernel above, if I modprobe different SATA/SAS drivers, I get an immediate kernel lock-up for which the only cure is the hard-reset (I can only complete the boot if blacklist the drivers with the PCIe SATA card installed).

But here's the weird part - the CentOS 4.2.0 kernel doesn't have this problem. So I'm wondering if the CentOS kernel has patches that specifically address this, or whether this is an upstream bug, either a regression since 4.2.x or a bug that manifests when using 4KB memory pages.

I have thus far reproduced this with a SIL3132 2-port SATA card and a 3ware 9650SE-16ML 16-port SAS card. I don't have any other SATA controllers handy to test with.

Do you happen to have any SATA/SAS controllers you could try (or have tried) with your kernel on this board?

Gordan

On 19/03/16 11:59, Michael Howard wrote:

On 19/03/2016 09:21, Gordan Bobic wrote:

...

On 17/03/16 08:05, Michael Howard wrote:

...

On 17/03/2016 01:24, Gordan Bobic wrote:

...

On 2016-03-14 22:14, Michael Howard wrote:

...

I didn't build an RPM as I came across a packaging problem, an aarch64/UTS_MACHINE issue I believe and I had no idea how to solve it nor could I spend any real time investigating it.

I have put together some kernel rpms: http://ftp.redsleeve.org/pub/misc/aarch64/

Cool. Did you have any problems? make rpm-pkg failed for me at packaging stage, with an error something like;

|scripts/Makefile.fwinst:43: *** mixed implicit and static pattern rules. Stop. make[2]: *** [_modinst_post] Error 2|

Speaking of the kernel, I seem to be having a problem. On the kernel above, if I modprobe different SATA/SAS drivers, I get an immediate kernel lock-up for which the only cure is the hard-reset (I can only complete the boot if blacklist the drivers with the PCIe SATA card installed).

But here's the weird part - the CentOS 4.2.0 kernel doesn't have this problem. So I'm wondering if the CentOS kernel has patches that specifically address this, or whether this is an upstream bug, either a regression since 4.2.x or a bug that manifests when using 4KB memory pages.

I have thus far reproduced this with a SIL3132 2-port SATA card and a 3ware 9650SE-16ML 16-port SAS card. I don't have any other SATA controllers handy to test with.

Do you happen to have any SATA/SAS controllers you could try (or have tried) with your kernel on this board?

I'll take a look later today, when I can get at some cards but I can confirm similar results with a Perc H800 fitted (don't ask),

Nothing _to_ ask - seems perfectly reasonable to me to have some big fat SAS cards in this machine. My own plans for this box include filling it up with a boatload of disks. :-)

the kernel panics on boot but doesn't with the original kernel.

Is this with your 4.5.x kernel?

I wonder if running with 4KB pages breaks some assumption about DMA alignment or something along those lines. Which would bring up an interesting question - whether picking 64KB pages in the CentOS kernel a fluke or a bodge...

Gordan

On 2016-03-15 18:32, Richard W.M. Jones wrote:

On Mon, Mar 14, 2016 at 03:00:35PM +0000, Gordan Bobic wrote:

...

On 2016-03-01 22:32, Michael Howard wrote:

...

On 01/03/2016 22:26, Richard W.M. Jones wrote:

...

On Mon, Feb 29, 2016 at 03:20:03PM +0000, Michael Howard wrote:

...

Just to let you know, I can't get this to work. aarch64 is supposed to be binary compatible, with the correct libraries installed, but I'm thinking the cpu isn't.

All I get is 'cannot execute binary file: Exec format error', regardless of what I try.

As I understand it the problem is page size - 64K was chosen by Red Hat for aarch64, where as 4K is the norm on armv7.

Anyway, you can run a 32 bit VM and it works well -- in fact a lot faster than regular 32 bit armv7 hardware.

Yes, with CONFIG_ARM64_4K_PAGES=y and CONFIG_COMPAT=y, 32 bit binaries run fine.

I built a kernel with these options enabled, but chrooting into an armv5tel subtree segfaults immediately. :-(

I may be missing some context here, but is there some reason not to just use a VM?

Performance for one.

It's more predictable because you'll be running the same kernel that the 32 bit environment is expecting.

The aarch64 environment seems no less predictable with a kernel defaulting to 4K pages. There are also other reasons, for example I want to run ZFS on the host and don't want to have to re-export the shares to guests via a network file system.

Also it will (or should) work without you needing to compile your own host kernel.

Well, as far as the host kernel is concerned:

1) I already posted a link with a selection of posts from Linus himself explaining at some length why using large default pages is a bad idea at the best of times (and for all other cases where bigger pages do give us that 3% speed-up we can use hugepages directly instead).

2) The kernel that ships is deprecated and was never a LT kernel (4.2).

So switching to the next LT kernel better configured for practically any task seems advantageous in every way.

I now have docker happily running armv5tel guests.

Gordan

On 2016-03-15 22:12, Richard W.M. Jones wrote:

On Tue, Mar 15, 2016 at 07:49:22PM +0000, Gordan Bobic wrote:

...

On 2016-03-15 18:32, Richard W.M. Jones wrote:

...

I may be missing some context here, but is there some reason not to just use a VM?

Performance for one.

Can you precisely quantify that?

On ARM? No, haven't tried it yet. On x86-64? Between 30% and 40% on a concurrent load saturating the CPU. Measured with different hypervisors (KVM, Xen and ESXi) and different generations of Intel CPUs from Core2 to Westmere Xeons. The results are reproducible on different loads, from a simple parallel kernel compile to a parallel read-only replay of MySQL general log.

Here are some old results on Core2 class hardware: https://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/

Unfortunately, later version of both hypervisors and hardware (I last ran similar tests using MySQL last year), exhibit the exact same performance degradation.

To reproduce: 1) 1 host, 1 VM 2) Give the VM all CPU cores available on the host 3) Run test with double the number of threads as there are CPU cores 4) If you are running the kernel compile test, put the sources on tmpfs (yes, you'll need a suitable amount of RAM) to avoid any I/O bottlenecking

...

...

It's more predictable because you'll be running the same kernel that the 32 bit environment is expecting.

The aarch64 environment seems no less predictable with a kernel defaulting to 4K pages.

It's more predictable for the 32 bit guest, because the guest will have exactly the kernel it expects, not some random kernel and a chroot.

Given it's an EL6 armv5tel guest, I dare say there is no reasonable expectation of any particular kernel from the guest userspace. Sadly, in the ARM world until very recently, the kernel that ships with the device has often been the only option.

The only kernel/userspace compatibility issue I have encountered was on the EL7 ARM port where a recent kernel is required specifically because systemd has done away with firmware loader helpers, and kernels before a certain version weren't up to the task of loading the firmware unassisted. But that's about it. I have a whole stack of ARM devices running rag-tag kernels they shipped with but with my own userspace.

...

There are also other reasons, for example I want to run ZFS on the host and don't want to have to re-export the shares to guests via a network file system.

...

...

Also it will (or should) work without you needing to compile your own host kernel.

Well, as far as the host kernel is concerned:

1. I already posted a link with a selection of posts from Linus

himself explaining at some length why using large default pages is a bad idea at the best of times (and for all other cases where bigger pages do give us that 3% speed-up we can use hugepages directly instead).

2. The kernel that ships is deprecated and was never a LT kernel

(4.2).

So switching to the next LT kernel better configured for practically any task seems advantageous in every way.

I think RHELSA 7.3 will have a 4.5 kernel. Of course "LT" kernels aren't really relevant for Red Hat, because we spend huge amounts of money supporting our kernels long term.

Let's not go there: https://bugzilla.redhat.com/show_bug.cgi?id=773107

Gordan

On 2016-03-16 11:58, Richard W.M. Jones wrote:

On Tue, Mar 15, 2016 at 10:49:14PM +0000, Gordan Bobic wrote:

...

On 2016-03-15 22:12, Richard W.M. Jones wrote:

...

On Tue, Mar 15, 2016 at 07:49:22PM +0000, Gordan Bobic wrote:

...

On 2016-03-15 18:32, Richard W.M. Jones wrote:

...

I may be missing some context here, but is there some reason not to just use a VM?

Performance for one.

Can you precisely quantify that?

On ARM? No, haven't tried it yet. On x86-64? Between 30% and 40% on a concurrent load saturating the CPU. Measured with different hypervisors (KVM, Xen and ESXi) and different generations of Intel CPUs from Core2 to Westmere Xeons. The results are reproducible on different loads, from a simple parallel kernel compile to a parallel read-only replay of MySQL general log.

You must be doing something very wrong if you see such a huge slowdown with KVM. Red Hat has a team that tracks performance and looks for regressions between releases. You shouldn't see more than a 5% slowdown, except in rare and exceptional corner cases, or if it's configured wrong.

Did you try the test as I mentioned and measure and observe the results for yourself? It would be more productive to compare empirically measured numbers with empirically masured numbers rather than empirically measured numbers with marketing brochure contents. And/or saying that the user is "holding it wrong".

Hard to say what - perhaps not using virtio,

Virtio shouldn't be a factor when the entire process is running in RAM on tmpfs and never touches disk or network I/O.

or not using the right <cpu> model, or maybe overprovisioning.

I never over-provision. The VM has exactly the number of cores the host has, and the host ran no other CPU consuming tasks in any of the tests, other than the hypervisor.

...

Here are some old results on Core2 class hardware: https://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/

I can't comment on VMware, nor on results from 4 years ago.

As I mentioned, the results are very repeatable on much more recent hardware and software stacks. Happy to re-run it again on EL7 on my dual socket Westmere this wekend and share the results, but I don't expect things to have changed significantly.

...

Unfortunately, later version of both hypervisors and hardware (I last ran similar tests using MySQL last year), exhibit the exact same performance degradation.

To reproduce:

1. 1 host, 1 VM
2. Give the VM all CPU cores available on the host
3. Run test with double the number of threads as there are CPU cores

So the problem is overprovisioning.

If you under-provision then you are reducing the number of CPU cores available to the VM compared to what it would have on bare metal. This counts as overhead however you spin it (and it doesn't actually change the overall results for the better).

And nV=nP isn't overprovisioning (or underprovisioning).

This is one of the reasons why some very large installations run on a "bare metal cloud" concept (they spin up physical machines rather than virtual ones).

...

...

I think RHELSA 7.3 will have a 4.5 kernel. Of course "LT" kernels aren't really relevant for Red Hat, because we spend huge amounts of money supporting our kernels long term.

Let's not go there: https://bugzilla.redhat.com/show_bug.cgi?id=773107

We don't support self-compiled kernels, for fairly obvious reasons.

The problem here is that it also extends to ignoring patches that fix what are pretty obvious mis-patch bugs that by pure luck alone don't trigger failures on the specific configuration used. You'd think that at least "make allyesconfig", "make allmodconfig" and "make allnoconfig" would be tested to pass after heavily patching the kernel. In the case of that particular bug, IIRC, "make allnoconfig" would have picked up the FTBFS. When one provides a patch that fixes the problem, it is difficult to not be left disappointed about the care about the quality of the code when it gets brushed aside like that. It's one of the reasons I stopped bothering filing distro level bug reports and have switched to running mainline kernels on many of my deployments.

Gordan

On 02/03/2016 09:58, Gordan Bobic wrote:

On 2016-03-01 22:26, Richard W.M. Jones wrote:

...

On Mon, Feb 29, 2016 at 03:20:03PM +0000, Michael Howard wrote:

...

Just to let you know, I can't get this to work. aarch64 is supposed to be binary compatible, with the correct libraries installed, but I'm thinking the cpu isn't.

All I get is 'cannot execute binary file: Exec format error', regardless of what I try.

As I understand it the problem is page size - 64K was chosen by Red Hat for aarch64, where as 4K is the norm on armv7.

I shall leave this link here without further comment, regarding using pages that are bigger than 4KB: http://yarchive.net/comp/linux/page_sizes.html

Yes, I read that before I reconfigured the kernel, it makes interesting reading.

My needs require me to run 32 bit binaries on my mp30-ar0 (at least in the short to medium term) so I'll use my modified kernel and 4KB pages.

On 22/02/16 05:02, Phong Vo wrote:

Hi,

The mp30ar0 U-boot has some special memory mapping to accommodate 32-bit DMA. Please download the tar ball again - I've updated the tianocore UHP for this.

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta r.xz

Updated instruction for U-boot chain loading: MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1 MP30AR0# save; reset

I just did this part and it seems to have semi-bricked the board. It gets as far as: === U-Boot 2013.04 (Jun 02 2015 - 10:54:10)ooREV: 1.15.01-F05 ( uart0 ) ===

and it just stops.

That seems a bit odd from just changing one variable and adding another, I didn't think those were supposed to be read until after the boot interruption prompt.

On to unbricking procedure I go...

On 12/03/2016 12:36, Gordan Bobic wrote:

On 12/03/16 12:04, Gordan Bobic wrote:

...

On 22/02/16 05:02, Phong Vo wrote:

...

Hi,

The mp30ar0 U-boot has some special memory mapping to accommodate 32-bit DMA. Please download the tar ball again - I've updated the tianocore UHP for this.

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta

r.xz

Updated instruction for U-boot chain loading: MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1 MP30AR0# save; reset

I just did this part and it seems to have semi-bricked the board. It gets as far as: === U-Boot 2013.04 (Jun 02 2015 - 10:54:10)ooREV: 1.15.01-F05 ( uart0 ) ===

and it just stops.

That seems a bit odd from just changing one variable and adding another, I didn't think those were supposed to be read until after the boot interruption prompt.

On to unbricking procedure I go...

Which gets stuck at the exct same point during the boot, only this time it looks like u-boot is a little newer:

=== U-Boot 2013.04-mp30ar0_sw_1.18.04 (Sep 02 2015 - 16:38:06) REV: F06b ( uart0 ) ===

Also tried clearing the CMOS, which made no difference.

Yes, there is a newer u-boot than that shipped. I have used both but I don't remember any advantages with the newer one.

I had an issue whereby I was using the serial console, but had a usb keyboard attached the the MP30 , and the output diverted to the VGA output. Very odd. Hook up a monitor if you haven't done so, just to check.

On 12/03/16 12:48, Michael Howard wrote:

On 12/03/2016 12:36, Gordan Bobic wrote:

...

On 12/03/16 12:04, Gordan Bobic wrote:

...

On 22/02/16 05:02, Phong Vo wrote:

...

Hi,

The mp30ar0 U-boot has some special memory mapping to accommodate 32-bit DMA. Please download the tar ball again - I've updated the tianocore UHP for this.

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta

r.xz

Updated instruction for U-boot chain loading: MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1 MP30AR0# save; reset

I just did this part and it seems to have semi-bricked the board. It gets as far as: === U-Boot 2013.04 (Jun 02 2015 - 10:54:10)ooREV: 1.15.01-F05 ( uart0 ) ===

and it just stops.

As mentioned in one of my other posts , check the vga output or serial output if you are using vga. You have actually only changed one variable, DDRBASE2G would have already been set.

I checked, and DDRBASE2G wasn't defined.

I don't suppose you managed to get "serial over LAN" working on the BMC? Getting to the actual serial console over ILO is... as unintuitive as it is undocumented...

Gordan

On 12/03/2016 13:07, Gordan Bobic wrote:

On 12/03/16 12:48, Michael Howard wrote:

...

On 12/03/2016 12:36, Gordan Bobic wrote:

...

On 12/03/16 12:04, Gordan Bobic wrote:

...

On 22/02/16 05:02, Phong Vo wrote:

...

Hi,

The mp30ar0 U-boot has some special memory mapping to accommodate 32-bit DMA. Please download the tar ball again - I've updated the tianocore UHP for this.

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta

r.xz

Updated instruction for U-boot chain loading: MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1 MP30AR0# save; reset

I just did this part and it seems to have semi-bricked the board. It gets as far as: === U-Boot 2013.04 (Jun 02 2015 - 10:54:10)ooREV: 1.15.01-F05 ( uart0 ) ===

and it just stops.

As mentioned in one of my other posts , check the vga output or serial output if you are using vga. You have actually only changed one variable, DDRBASE2G would have already been set.

I checked, and DDRBASE2G wasn't defined.

I don't suppose you managed to get "serial over LAN" working on the BMC? Getting to the actual serial console over ILO is... as unintuitive as it is undocumented...

Ok, tried SOL and that works here. I used;

ipmitool -I lanplus -H 192.168.1.81 -U admin -P password sol activate

On 12/03/2016 13:36, Gordan Bobic wrote:

On 12/03/16 13:27, Michael Howard wrote:

...

On 12/03/2016 13:07, Gordan Bobic wrote:

...

On 12/03/16 12:48, Michael Howard wrote:

...

On 12/03/2016 12:36, Gordan Bobic wrote:

...

On 12/03/16 12:04, Gordan Bobic wrote:

...

On 22/02/16 05:02, Phong Vo wrote: > Hi, > > The mp30ar0 U-boot has some special memory mapping to accommodate > 32-bit > DMA. > Please download the tar ball again - I've updated the tianocore > UHP for > this. > > https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta > > > > > r.xz > > Updated instruction for U-boot chain loading: > MP30AR0# setenv num_cores 1 > MP30AR0# setenv DDRBASE2G 1 > MP30AR0# save; reset

I just did this part and it seems to have semi-bricked the board. It gets as far as: === U-Boot 2013.04 (Jun 02 2015 - 10:54:10)ooREV: 1.15.01-F05 ( uart0 ) ===

and it just stops.

As mentioned in one of my other posts , check the vga output or serial output if you are using vga. You have actually only changed one variable, DDRBASE2G would have already been set.

I checked, and DDRBASE2G wasn't defined.

I don't suppose you managed to get "serial over LAN" working on the BMC? Getting to the actual serial console over ILO is... as unintuitive as it is undocumented...

Ok, tried SOL and that works here. I used;

ipmitool -I lanplus -H 192.168.1.81 -U admin -P password sol activate

You, sir, are awesome. :) Not to mention right - for some reason u-boot did indeed decide to go to serial only with no VGA.

What setting is used to control that?

To be honest, I don't know. I've had the box next to me while I've been 'playing' and out of habit tend to use the serial console cos that's what was traditionally available on arm devices. I only discovered the 'switch' from vga/serial by accident having left the usb keyboard plugged in. I did notice that with both (serial & vga) hooked up, not all output appears on vga whilst it does on serial, hence I stuck to serial. I can live without the penguin.

On 12/03/2016 15:17, Gordan Bobic wrote:

On 12/03/16 13:44, Michael Howard wrote:

...

On 12/03/2016 13:36, Gordan Bobic wrote:

...

On 12/03/16 13:27, Michael Howard wrote:

...

On 12/03/2016 13:07, Gordan Bobic wrote:

...

On 12/03/16 12:48, Michael Howard wrote:

...

On 12/03/2016 12:36, Gordan Bobic wrote: > On 12/03/16 12:04, Gordan Bobic wrote: >> On 22/02/16 05:02, Phong Vo wrote: >>> Hi, >>> >>> The mp30ar0 U-boot has some special memory mapping to accommodate >>> 32-bit >>> DMA. >>> Please download the tar ball again - I've updated the tianocore >>> UHP for >>> this. >>> >>> https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta >>> >>> >>> >>> >>> >>> r.xz >>> >>> Updated instruction for U-boot chain loading: >>> MP30AR0# setenv num_cores 1 >>> MP30AR0# setenv DDRBASE2G 1 >>> MP30AR0# save; reset >> >> I just did this part and it seems to have semi-bricked the >> board. It >> gets as far as: >> === >> U-Boot 2013.04 (Jun 02 2015 - 10:54:10)ooREV: 1.15.01-F05 ( >> uart0 ) >> === >> >> and it just stops. >> As mentioned in one of my other posts , check the vga output or serial output if you are using vga. You have actually only changed one variable, DDRBASE2G would have already been set.

I checked, and DDRBASE2G wasn't defined.

I don't suppose you managed to get "serial over LAN" working on the BMC? Getting to the actual serial console over ILO is... as unintuitive as it is undocumented...

Ok, tried SOL and that works here. I used;

ipmitool -I lanplus -H 192.168.1.81 -U admin -P password sol activate

You, sir, are awesome. :) Not to mention right - for some reason u-boot did indeed decide to go to serial only with no VGA.

What setting is used to control that?

To be honest, I don't know. I've had the box next to me while I've been 'playing' and out of habit tend to use the serial console cos that's what was traditionally available on arm devices. I only discovered the 'switch' from vga/serial by accident having left the usb keyboard plugged in. I did notice that with both (serial & vga) hooked up, not all output appears on vga whilst it does on serial, hence I stuck to serial. I can live without the penguin.

Yes, so can I, and VGA out comes back to life once UEFI loads. Also, unce UEFI loads, the remote network console via the Java client starts to work, too.

Disappointingly, the fact that u-boot seems to arbitrarily decide to stop using local console, does seem to make it's usefulness rather diminished as the first stage boot-loader. :-(

But yay, I have it working! :)

Now to put Tianocore files onto the UEFI partition...

Yes, better than mmc or tftp :)

On 22/02/16 05:02, Phong Vo wrote:

Hi,

The mp30ar0 U-boot has some special memory mapping to accommodate 32-bit DMA. Please download the tar ball again - I've updated the tianocore UHP for this.

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta r.xz

Updated instruction for U-boot chain loading: MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1 MP30AR0# save; reset

MP30AR0# setenv load_tianocore 'tftp 0x82000000 ${user_dir}/mp30ar0_tianocore_ubt.fd; tftp 0x1d000000 ${user_dir}/mp30ar0_tianocore_sec_ubt.fd' MP30AR0# setenv run_tianocore 'go 0x1d000000' MP30AR0# run load_tianocore run_tianocore

OK, I got this far now, with some minor changes (loading Tianocore off USB until I can complete the install and put the files on the UEFI FAT disk partition. My modified incantations are:

MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1

MP30AR0# setenv load_tianocore ' fatload usb 0:1 0x82000000 mp30ar0_tianocore_ubt.fd; fatload usb 0:1 0x1d000000 mp30ar0_tianocore_sec_ubt.fd;'

MP30AR0# setenv run_tianocore 'go 0x1d000000' MP30AR0# save; reset

then after it reboots:

MP30AR0# usb reset MP30AR0# run load_tianocore run_tianocore

reading mp30ar0_tianocore_ubt.fd 1835008 bytes read in 569 ms (3.1 MiB/s) reading mp30ar0_tianocore_sec_ubt.fd 262144 bytes read in 218 ms (1.1 MiB/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

*** (Note: Boot stops there for long enough to be concerning. Give it a minute and it will eventually get further.) ***

Eventually that will get you to the bit blow as Phong mentioned previously:

Welcome banner should show something similar to below

TianoCore 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.20.04.00 2016/02/18) TPC: disable AVS: support SOC: 950 mV The default boot selection will start in 5 seconds

[1] Shell [2] Boot Manager [3] Reboot [4] Shutdown

Make sure the install DVD is inserted, pick 1, and type in:

FS1:\EFI\BOOT\BOOTAA64.EFI

The installer will do the rest, with the exception of figuring out the NIC MAC addresses. 3 NICs show up as having ethernet address of ff:ff:ff:ff:ff:ff, even though they are set correctly in u-boot.

I seem to recall that Michael had the same problem.

Gordan

Gordan

On 12/03/16 14:53, Michael Howard wrote:

On 12/03/2016 14:32, Gordan Bobic wrote:

...

On 22/02/16 05:02, Phong Vo wrote:

...

Hi,

The mp30ar0 U-boot has some special memory mapping to accommodate 32-bit DMA. Please download the tar ball again - I've updated the tianocore UHP for this.

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta

r.xz

Updated instruction for U-boot chain loading: MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1 MP30AR0# save; reset

MP30AR0# setenv load_tianocore 'tftp 0x82000000 ${user_dir}/mp30ar0_tianocore_ubt.fd; tftp 0x1d000000 ${user_dir}/mp30ar0_tianocore_sec_ubt.fd' MP30AR0# setenv run_tianocore 'go 0x1d000000' MP30AR0# run load_tianocore run_tianocore

OK, I got this far now, with some minor changes (loading Tianocore off USB until I can complete the install and put the files on the UEFI FAT disk partition. My modified incantations are:

MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1

MP30AR0# setenv load_tianocore ' fatload usb 0:1 0x82000000 mp30ar0_tianocore_ubt.fd; fatload usb 0:1 0x1d000000 mp30ar0_tianocore_sec_ubt.fd;'

MP30AR0# setenv run_tianocore 'go 0x1d000000' MP30AR0# save; reset

then after it reboots:

MP30AR0# usb reset MP30AR0# run load_tianocore run_tianocore

reading mp30ar0_tianocore_ubt.fd 1835008 bytes read in 569 ms (3.1 MiB/s) reading mp30ar0_tianocore_sec_ubt.fd 262144 bytes read in 218 ms (1.1 MiB/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

---

(Note: Boot stops there for long enough to be concerning. Give it a minute and it will eventually get further.)

---

Eventually that will get you to the bit blow as Phong mentioned previously:

...

Welcome banner should show something similar to below

TianoCore 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.20.04.00 2016/02/18) TPC: disable AVS: support SOC: 950 mV The default boot selection will start in 5 seconds

[1] Shell [2] Boot Manager [3] Reboot [4] Shutdown

Make sure the install DVD is inserted, pick 1, and type in:

FS1:\EFI\BOOT\BOOTAA64.EFI

The installer will do the rest, with the exception of figuring out the NIC MAC addresses. 3 NICs show up as having ethernet address of ff:ff:ff:ff:ff:ff, even though they are set correctly in u-boot.

At the Shell prompt, set MAC0 xx:xx:xx:xx:xx:xx & set MAC1 xx:xx:xx:xx:xx:xx

but this was insufficient for the Centos installer to get an ip even after a reboot. What I did was change the kernel command line at the grub menu to include ip, netmask and to request vnc.

Yes, I went back through the thread and re-read about that bit. What worked for me is adding "ip=dhcp" to the kernel boot parameters. There are actually 4 NICs on this board, so I just added all 4 (MAC0-MAC3).

Gordan

On 12/03/16 15:19, Michael Howard wrote:

On 12/03/2016 15:14, Gordan Bobic wrote:

...

On 12/03/16 14:53, Michael Howard wrote:

...

On 12/03/2016 14:32, Gordan Bobic wrote:

...

On 22/02/16 05:02, Phong Vo wrote:

...

Hi,

The mp30ar0 U-boot has some special memory mapping to accommodate 32-bit DMA. Please download the tar ball again - I've updated the tianocore UHP for this.

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta

r.xz

Updated instruction for U-boot chain loading: MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1 MP30AR0# save; reset

MP30AR0# setenv load_tianocore 'tftp 0x82000000 ${user_dir}/mp30ar0_tianocore_ubt.fd; tftp 0x1d000000 ${user_dir}/mp30ar0_tianocore_sec_ubt.fd' MP30AR0# setenv run_tianocore 'go 0x1d000000' MP30AR0# run load_tianocore run_tianocore

OK, I got this far now, with some minor changes (loading Tianocore off USB until I can complete the install and put the files on the UEFI FAT disk partition. My modified incantations are:

MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1

MP30AR0# setenv load_tianocore ' fatload usb 0:1 0x82000000 mp30ar0_tianocore_ubt.fd; fatload usb 0:1 0x1d000000 mp30ar0_tianocore_sec_ubt.fd;'

MP30AR0# setenv run_tianocore 'go 0x1d000000' MP30AR0# save; reset

then after it reboots:

MP30AR0# usb reset MP30AR0# run load_tianocore run_tianocore

reading mp30ar0_tianocore_ubt.fd 1835008 bytes read in 569 ms (3.1 MiB/s) reading mp30ar0_tianocore_sec_ubt.fd 262144 bytes read in 218 ms (1.1 MiB/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

---

(Note: Boot stops there for long enough to be concerning. Give it a minute and it will eventually get further.)

---

Eventually that will get you to the bit blow as Phong mentioned previously:

...

Welcome banner should show something similar to below

TianoCore 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.20.04.00 2016/02/18) TPC: disable AVS: support SOC: 950 mV The default boot selection will start in 5 seconds

[1] Shell [2] Boot Manager [3] Reboot [4] Shutdown

Make sure the install DVD is inserted, pick 1, and type in:

FS1:\EFI\BOOT\BOOTAA64.EFI

The installer will do the rest, with the exception of figuring out the NIC MAC addresses. 3 NICs show up as having ethernet address of ff:ff:ff:ff:ff:ff, even though they are set correctly in u-boot.

At the Shell prompt, set MAC0 xx:xx:xx:xx:xx:xx & set MAC1 xx:xx:xx:xx:xx:xx

but this was insufficient for the Centos installer to get an ip even after a reboot. What I did was change the kernel command line at the grub menu to include ip, netmask and to request vnc.

Yes, I went back through the thread and re-read about that bit. What worked for me is adding "ip=dhcp" to the kernel boot parameters. There are actually 4 NICs on this board, so I just added all 4 (MAC0-MAC3).

Yes, ip=dhcp is also good. Actually there are 5 nics :) Not sure why the installer only sees 3, unless the the third one it sees is the BMC interface, which you wouldn't normally expect.

Both the installer and the installed system see 3. eth0 and eth1 are definitely the two gigabit ports.

eth3 is definitely not the BMC (different MAC address, I just checked). So eth3 is one of the SFP ports. Which makes me wonder why the 2nd SFP port isn't showing up.

Gordan

On 12/03/2016 15:52, Gordan Bobic wrote:

On 12/03/16 15:19, Michael Howard wrote:

...

On 12/03/2016 15:14, Gordan Bobic wrote:

...

On 12/03/16 14:53, Michael Howard wrote:

...

On 12/03/2016 14:32, Gordan Bobic wrote:

...

On 22/02/16 05:02, Phong Vo wrote:

...

Hi,

The mp30ar0 U-boot has some special memory mapping to accommodate 32-bit DMA. Please download the tar ball again - I've updated the tianocore UHP for this.

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta

r.xz

Updated instruction for U-boot chain loading: MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1 MP30AR0# save; reset

MP30AR0# setenv load_tianocore 'tftp 0x82000000 ${user_dir}/mp30ar0_tianocore_ubt.fd; tftp 0x1d000000 ${user_dir}/mp30ar0_tianocore_sec_ubt.fd' MP30AR0# setenv run_tianocore 'go 0x1d000000' MP30AR0# run load_tianocore run_tianocore

OK, I got this far now, with some minor changes (loading Tianocore off USB until I can complete the install and put the files on the UEFI FAT disk partition. My modified incantations are:

MP30AR0# setenv num_cores 1 MP30AR0# setenv DDRBASE2G 1

MP30AR0# setenv load_tianocore ' fatload usb 0:1 0x82000000 mp30ar0_tianocore_ubt.fd; fatload usb 0:1 0x1d000000 mp30ar0_tianocore_sec_ubt.fd;'

MP30AR0# setenv run_tianocore 'go 0x1d000000' MP30AR0# save; reset

then after it reboots:

MP30AR0# usb reset MP30AR0# run load_tianocore run_tianocore

reading mp30ar0_tianocore_ubt.fd 1835008 bytes read in 569 ms (3.1 MiB/s) reading mp30ar0_tianocore_sec_ubt.fd 262144 bytes read in 218 ms (1.1 MiB/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

---

(Note: Boot stops there for long enough to be concerning. Give it a minute and it will eventually get further.)

---

Eventually that will get you to the bit blow as Phong mentioned previously:

...

Welcome banner should show something similar to below

TianoCore 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.20.04.00 2016/02/18) TPC: disable AVS: support SOC: 950 mV The default boot selection will start in 5 seconds

[1] Shell [2] Boot Manager [3] Reboot [4] Shutdown

Make sure the install DVD is inserted, pick 1, and type in:

FS1:\EFI\BOOT\BOOTAA64.EFI

The installer will do the rest, with the exception of figuring out the NIC MAC addresses. 3 NICs show up as having ethernet address of ff:ff:ff:ff:ff:ff, even though they are set correctly in u-boot.

At the Shell prompt, set MAC0 xx:xx:xx:xx:xx:xx & set MAC1 xx:xx:xx:xx:xx:xx

but this was insufficient for the Centos installer to get an ip even after a reboot. What I did was change the kernel command line at the grub menu to include ip, netmask and to request vnc.

Yes, I went back through the thread and re-read about that bit. What worked for me is adding "ip=dhcp" to the kernel boot parameters. There are actually 4 NICs on this board, so I just added all 4 (MAC0-MAC3).

Yes, ip=dhcp is also good. Actually there are 5 nics :) Not sure why the installer only sees 3, unless the the third one it sees is the BMC interface, which you wouldn't normally expect.

Both the installer and the installed system see 3. eth0 and eth1 are definitely the two gigabit ports.

eth3 is definitely not the BMC (different MAC address, I just checked). So eth3 is one of the SFP ports. Which makes me wonder why the 2nd SFP port isn't showing up.

The physical label on the port header will tell you which 10Gb port it is. On my modified 4.5.0-rc6 I do see 4 nics but the fourth is bogus as the hwaddr is nothing like and I can't physically test at the mo. I don't think there is support yet for the second 10Gb nic.

On 12/03/2016 16:42, Gordan Bobic wrote:

On 12/03/16 16:31, Michael Howard wrote:

...

On 12/03/2016 15:52, Gordan Bobic wrote:

...

On 12/03/16 15:19, Michael Howard wrote:

...

On 12/03/2016 15:14, Gordan Bobic wrote:

...

On 12/03/16 14:53, Michael Howard wrote:

...

On 12/03/2016 14:32, Gordan Bobic wrote: > On 22/02/16 05:02, Phong Vo wrote: >> Hi, >> >> The mp30ar0 U-boot has some special memory mapping to accommodate >> 32-bit >> DMA. >> Please download the tar ball again - I've updated the tianocore >> UHP >> for >> this. >> >> https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta >> >> >> >> >> r.xz >> >> Updated instruction for U-boot chain loading: >> MP30AR0# setenv num_cores 1 >> MP30AR0# setenv DDRBASE2G 1 >> MP30AR0# save; reset >> >> MP30AR0# setenv load_tianocore 'tftp 0x82000000 >> ${user_dir}/mp30ar0_tianocore_ubt.fd; tftp 0x1d000000 >> ${user_dir}/mp30ar0_tianocore_sec_ubt.fd' >> MP30AR0# setenv run_tianocore 'go 0x1d000000' >> MP30AR0# run load_tianocore run_tianocore > > OK, I got this far now, with some minor changes (loading Tianocore > off > USB until I can complete the install and put the files on the UEFI > FAT disk partition. My modified incantations are: > > MP30AR0# setenv num_cores 1 > MP30AR0# setenv DDRBASE2G 1 > > MP30AR0# setenv load_tianocore ' > fatload usb 0:1 0x82000000 mp30ar0_tianocore_ubt.fd; > fatload usb 0:1 0x1d000000 mp30ar0_tianocore_sec_ubt.fd;' > > MP30AR0# setenv run_tianocore 'go 0x1d000000' > MP30AR0# save; reset > > then after it reboots: > > MP30AR0# usb reset > MP30AR0# run load_tianocore run_tianocore > > reading mp30ar0_tianocore_ubt.fd > 1835008 bytes read in 569 ms (3.1 MiB/s) > reading mp30ar0_tianocore_sec_ubt.fd > 262144 bytes read in 218 ms (1.1 MiB/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 > > *** > (Note: Boot stops there for long enough to be concerning. Give it a > minute and it will eventually get further.) > *** > > Eventually that will get you to the bit blow as Phong mentioned > previously: > >> Welcome banner should show something similar to below >> >> TianoCore 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.20.04.00 2016/02/18) >> TPC: disable >> AVS: support >> SOC: 950 mV >> The default boot selection will start in 5 seconds > [1] Shell > [2] Boot Manager > [3] Reboot > [4] Shutdown > > Make sure the install DVD is inserted, pick 1, and type in: > > FS1:\EFI\BOOT\BOOTAA64.EFI > > The installer will do the rest, with the exception of figuring out > the > NIC MAC addresses. 3 NICs show up as having ethernet address of > ff:ff:ff:ff:ff:ff, even though they are set correctly in u-boot. > At the Shell prompt, set MAC0 xx:xx:xx:xx:xx:xx & set MAC1 xx:xx:xx:xx:xx:xx

but this was insufficient for the Centos installer to get an ip even after a reboot. What I did was change the kernel command line at the grub menu to include ip, netmask and to request vnc.

Yes, I went back through the thread and re-read about that bit. What worked for me is adding "ip=dhcp" to the kernel boot parameters. There are actually 4 NICs on this board, so I just added all 4 (MAC0-MAC3).

Yes, ip=dhcp is also good. Actually there are 5 nics :) Not sure why the installer only sees 3, unless the the third one it sees is the BMC interface, which you wouldn't normally expect.

Both the installer and the installed system see 3. eth0 and eth1 are definitely the two gigabit ports.

eth3 is definitely not the BMC (different MAC address, I just checked). So eth3 is one of the SFP ports. Which makes me wonder why the 2nd SFP port isn't showing up.

The physical label on the port header will tell you which 10Gb port it is.

ethtool shows eth0 and eth1 are 1G, and eth2 is 10G, which is in line with what I mentioned earlier.

Yeah, I meant from the sticky label on the port header of the board, you'll know which physical port was being identified, in case you can't physically check which port is working.

...

On my modified 4.5.0-rc6 I do see 4 nics but the fourth is bogus as the hwaddr is nothing like and I can't physically test at the mo. I don't think there is support yet for the second 10Gb nic.

So mainline 4.5.0 works without needing extra patches?

Yes.

What config did you use? The one from the CentOS kernel (with make oldconfig or similar)?

Yes, I started with the original config, accepting all defaults, then made the changes I neeeded/wanted.

I take it 4.1.x (most recent LT) is out of the question.

I doubt it's 'out of the question'.

As I said earlier, I can't physically test my 10G ports at the mo and the mac address of eth3 is wildly out. However, ethtool does report (the same as eth2);

# ethtool eth3 Settings for eth3: Supported ports: [ FIBRE ] Supported link modes: 10000baseT/Full Supported pause frame use: No Supports auto-negotiation: No Advertised link modes: 10000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: No Speed: 10000Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: internal Auto-negotiation: off Link detected: no

so maybe it's just a mis reported mac address.

Bump. It seems the kernel binary rpm doesn't match the availability of the sources for it. I can find no src.rpm matching the binary, and the CentOS git doesn't seem to include this version: https://git.centos.org/summary/rpms!kernel-aarch64

Can you please provide the full src.rpm used to build the kernel-4.2.0-0.26.el7.1.aarch64 package?

Many thanks.

Gordan

On 13/03/16 07:32, Gordan Bobic wrote:

On 12/03/16 17:12, Michael Howard wrote:

...

On 12/03/2016 16:42, Gordan Bobic wrote:

...

On 12/03/16 16:31, Michael Howard wrote:

...

...

...

On my modified 4.5.0-rc6 I do see 4 nics but the fourth is bogus as the hwaddr is nothing like and I can't physically test at the mo. I don't think there is support yet for the second 10Gb nic.

So mainline 4.5.0 works without needing extra patches?

Yes.

...

What config did you use? The one from the CentOS kernel (with make oldconfig or similar)?

Yes, I started with the original config, accepting all defaults, then made the changes I neeeded/wanted.

...

I take it 4.1.x (most recent LT) is out of the question.

I doubt it's 'out of the question'.

So I just looked at the CentOS git here: https://git.centos.org/summary/rpms!kernel-aarch64

The SPEC file shows: %define rpmversion 4.2.0 %define pkgrelease 0.21.el7

But: $ rpm -qa | grep kernel-4 kernel-4.2.0-0.26.el7.1.aarch64 $ uname -r 4.2.0-0.26.el7.1.aarch64

So where is the branch containing the latest 4.2.0-0.26.el7?

Also, I only see one patch: linux-kernel-test.patch

Is that really it? No special patches required to make the X-Gene work fully?

Another thing to consider is that 4.2.x is long EOL-ed (4.3.x is also EOL-ed now).

Michael, did you build your 4.5.x kernel as an rpm or standalone? Are there any special steps required other than "make all", copying the DTBs to /boot/dtb-<kernel version> and dracut-ing a new initrd?

Gordan _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev

On 12/03/16 17:12, Michael Howard wrote:

On 12/03/2016 16:42, Gordan Bobic wrote:

...

On 12/03/16 16:31, Michael Howard wrote:

...

...

On my modified 4.5.0-rc6 I do see 4 nics but the fourth is bogus as the hwaddr is nothing like and I can't physically test at the mo. I don't think there is support yet for the second 10Gb nic.

So mainline 4.5.0 works without needing extra patches?

Yes.

I just build 4.4.5, and that works without any extra patches, too. Impressive. This is starting to get close to x86 as far as the lack of hoop jumping goes.

...

What config did you use? The one from the CentOS kernel (with make oldconfig or similar)?

Yes, I started with the original config, accepting all defaults, then made the changes I neeeded/wanted.

Worked for me, too.

As I said earlier, I can't physically test my 10G ports at the mo and the mac address of eth3 is wildly out. However, ethtool does report (the same as eth2);

# ethtool eth3 Settings for eth3: Supported ports: [ FIBRE ] Supported link modes: 10000baseT/Full Supported pause frame use: No Supports auto-negotiation: No Advertised link modes: 10000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: No Speed: 10000Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: internal Auto-negotiation: off Link detected: no

so maybe it's just a mis reported mac address.

I'm also seeing the extra NIC with 4.4.5, but as you also described, the reported MAC address is wrong.

I wasn't intending to use the fibre ports anyway, though.

Gordan

On Sat, Feb 20, 2016 at 11:06:08AM +0700, Phong Vo wrote:

In theory, you just need to convert CentOS vmlinuz to uImage, then do U-boot boot using the dtb and CentOS initrd.img; but somehow it hangs on me. I'll need to dig into it further.

I am not aware that it was shipped only with U-boot. If you want to try with UEFI, take it from my dropbox

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.tar....

mp30ar0_tianocore_media.img: burn to SPI NOR if you want to replace U-boot permanently

Has anyone tried this step ^^ (replacing u-boot permanently)?

I'm not too keen to brick an $800 board. Is it reversible?

Rich.

There should be no issue of replacing U-boot in SPI nor with the mp30ar0 Tianocore version. But you need to use the mp30ar0_tianocore_media.img I provide, not the one supplied with the Mustang board. It was likely the person burn the wrong BIOS on the board!

You can burn the Tianocore image from U-boot using TFTP. Please check and setup your U-boot variables:

media_addr_r=0x4001000000 media_img=mp30ar0_tianocore_media.img spi_load=tftp ${media_addr_r} ${user_dir}/${media_img} spi_update=sf probe 0; sf erase 0x0 ${filesize}; sf write ${media_addr_r} 0x0 ${filesize}

# run spi_load <== Make sure it is successful # run spi_update # reset

If there is any issue, it's still recoverable using SD card.

-Phong

-----Original Message----- From: arm-dev-bounces@centos.org [mailto:arm-dev-bounces@centos.org] On Behalf Of Michael Howard Sent: Friday, March 04, 2016 9:05 PM To: arm-dev@centos.org Subject: Re: [Arm-dev] Gigabyte MP30-AR0

On 04/03/2016 11:47, Richard W.M. Jones wrote:

On Sat, Feb 20, 2016 at 11:06:08AM +0700, Phong Vo wrote:

...

In theory, you just need to convert CentOS vmlinuz to uImage, then do

U-boot

...

boot using the dtb and CentOS initrd.img; but somehow it hangs on me. I'll need to dig into it further.

I am not aware that it was shipped only with U-boot. If you want to try

with

...

UEFI, take it from my dropbox

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta r.xz

...

mp30ar0_tianocore_media.img: burn to SPI NOR if you want to replace

U-boot

...

permanently

Has anyone tried this step ^^ (replacing u-boot permanently)?

I'm not too keen to brick an $800 board. Is it reversible?

No, not tried it, don't see the point of risking it at the mo. Somebody did brick their board (https://lists.centos.org/pipermail/arm-dev/2016-February/001622.html) and for me, I just chainload tianocore from u-boot via tftp.

On Sat, Mar 05, 2016 at 10:26:25AM +0700, Phong Vo wrote:

There should be no issue of replacing U-boot in SPI nor with the mp30ar0 Tianocore version. But you need to use the mp30ar0_tianocore_media.img I provide, not the one supplied with the Mustang board. It was likely the person burn the wrong BIOS on the board!

You can burn the Tianocore image from U-boot using TFTP. Please check and setup your U-boot variables:

media_addr_r=0x4001000000 media_img=mp30ar0_tianocore_media.img spi_load=tftp ${media_addr_r} ${user_dir}/${media_img} spi_update=sf probe 0; sf erase 0x0 ${filesize}; sf write ${media_addr_r} 0x0 ${filesize}

# run spi_load <== Make sure it is successful # run spi_update # reset

If there is any issue, it's still recoverable using SD card.

As a warning to anyone else, that bricked mine.

Rich.

On Sat, Mar 05, 2016 at 11:12:00AM +0000, Michael Howard wrote:

On 05/03/2016 11:06, Richard W.M. Jones wrote:

...

On Sat, Mar 05, 2016 at 10:26:25AM +0700, Phong Vo wrote:

...

There should be no issue of replacing U-boot in SPI nor with the mp30ar0 Tianocore version. But you need to use the mp30ar0_tianocore_media.img I provide, not the one supplied with the Mustang board. It was likely the person burn the wrong BIOS on the board!

You can burn the Tianocore image from U-boot using TFTP. Please check and setup your U-boot variables:

media_addr_r=0x4001000000 media_img=mp30ar0_tianocore_media.img spi_load=tftp ${media_addr_r} ${user_dir}/${media_img} spi_update=sf probe 0; sf erase 0x0 ${filesize}; sf write ${media_addr_r} 0x0 ${filesize}

# run spi_load <== Make sure it is successful # run spi_update # reset

If there is any issue, it's still recoverable using SD card.

As a warning to anyone else, that bricked mine.

Since your post yesterday? Did u-boot chainload UEFI ok prior to attempting the permanent change?

Chainloading UEFI worked (albeit tedious and slow and requiring a network connection).

I wanted to permanently get rid of u-boot because I want to see if we can turn these boards into real (SBSA/SBBR) server hardware that can run RHEL.

I'm just going through the SD card recovery procedure now -- section 2.7 of the Software Reference Guide. Will report back ...

Rich.

On 05/03/16 11:22, Richard W.M. Jones wrote:

On Sat, Mar 05, 2016 at 11:12:00AM +0000, Michael Howard wrote:

...

On 05/03/2016 11:06, Richard W.M. Jones wrote:

...

On Sat, Mar 05, 2016 at 10:26:25AM +0700, Phong Vo wrote:

...

There should be no issue of replacing U-boot in SPI nor with the mp30ar0 Tianocore version. But you need to use the mp30ar0_tianocore_media.img I provide, not the one supplied with the Mustang board. It was likely the person burn the wrong BIOS on the board!

You can burn the Tianocore image from U-boot using TFTP. Please check and setup your U-boot variables:

media_addr_r=0x4001000000 media_img=mp30ar0_tianocore_media.img spi_load=tftp ${media_addr_r} ${user_dir}/${media_img} spi_update=sf probe 0; sf erase 0x0 ${filesize}; sf write ${media_addr_r} 0x0 ${filesize}

# run spi_load <== Make sure it is successful # run spi_update # reset

If there is any issue, it's still recoverable using SD card.

As a warning to anyone else, that bricked mine.

Since your post yesterday? Did u-boot chainload UEFI ok prior to attempting the permanent change?

Chainloading UEFI worked (albeit tedious and slow and requiring a network connection).

Can you not chainload off local media? For example, a FAT partition is needed for UEFI anyway, so is there a good reason it isn't possible to put the UEFI image onto that partition (or any other partition that u-boot can read) and chain load it from there? If so, I am struggling to think of a reason why anybody would want to be booting UEFI straight from the ROM instead of u-boot. I might save a couple of seconds off the boot time, but u-boot is far more flexible and powerful than UEFI.

I wanted to permanently get rid of u-boot because I want to see if we can turn these boards into real (SBSA/SBBR) server hardware that can run RHEL.

Would putting UEFI image for chainloading onto the SD card not fulfill this requirement without the loss of flexibility incurred by losing the 1st stage u-boot loader?

I'm just going through the SD card recovery procedure now -- section 2.7 of the Software Reference Guide. Will report back ...

I hope it works out, please let us know.

Gordan

On 05/03/16 12:00, Richard W.M. Jones wrote:

On Sat, Mar 05, 2016 at 11:57:11AM +0000, Gordan Bobic wrote:

...

On 05/03/16 11:22, Richard W.M. Jones wrote:

...

I wanted to permanently get rid of u-boot because I want to see if we can turn these boards into real (SBSA/SBBR) server hardware that can run RHEL.

Would putting UEFI image for chainloading onto the SD card not fulfill this requirement without the loss of flexibility incurred by losing the 1st stage u-boot loader?

I'd really just like SBSA hardware without complications. If we can get that I'll purchase dozens of these boards for OpenStack development. If not, I'll be recommending Huskyboards :-)

From what little I can find on the spec, it really doesn't look like the Huskyboard is anywhere nowhere even near the same league as the Gigabyte board. Not standard *TX form factor, one DIMM slot on the underside of the board, IIRC, non-standard power input connector. It's as awful a hack-job as most of the ARM dev kits.

OTOH, the MP30-AR0 is standard Micro-ATX in every way, and can take up to 128GB of RAM (it's a bit surreal of amazing to suddenly go from bashing my head against the limits of tiny memory on ARM bords to one that I can just fill up with 128GB of RAM I have lying around!).

Softiron Overdrive 3000 comes close in terms of spec, but unlike the Gigabyte, I cannot just click it into the shopping cart, hand over my payment details and expect it to be in my hands 48 hours later. And it is probably more expensive than even MP30-AR0.

Gordan

On 05/03/16 12:27, Richard W.M. Jones wrote:

On Sat, Mar 05, 2016 at 12:14:54PM +0000, Gordan Bobic wrote:

...

On 05/03/16 12:00, Richard W.M. Jones wrote:

...

On Sat, Mar 05, 2016 at 11:57:11AM +0000, Gordan Bobic wrote:

...

On 05/03/16 11:22, Richard W.M. Jones wrote:

...

I wanted to permanently get rid of u-boot because I want to see if we can turn these boards into real (SBSA/SBBR) server hardware that can run RHEL.

Would putting UEFI image for chainloading onto the SD card not fulfill this requirement without the loss of flexibility incurred by losing the 1st stage u-boot loader?

I'd really just like SBSA hardware without complications. If we can get that I'll purchase dozens of these boards for OpenStack development. If not, I'll be recommending Huskyboards :-)

From what little I can find on the spec, it really doesn't look like the Huskyboard is anywhere nowhere even near the same league as the Gigabyte board. Not standard *TX form factor, one DIMM slot on the underside of the board, IIRC, non-standard power input connector. It's as awful a hack-job as most of the ARM dev kits.

"hack-job" is a bit severe. The Huskyboard is a development board, not a server board. It has two SO-DIMM slots, so I guess it should take 8 or 16 GB of laptop memory, which is fine for our development needs. Not something you'd want in a production server of course.

The point being that you are comparing a dev board to a server board. It's a bit like comparing the Taj Mahal in India to Taj Mahal the indian restaurant.

It will also have SBSA out of the box, so it'll just run RHEL (and, one day, Windows). It has a nicer processor - the AMD Seattle.

Just out of interest, what is better about the AMD Seattle CPU compared to the X-Gene on the Gigabyte board?

It's also half the price of the Gigabyte.

It's all relative. Half the price of the Gigabyte is still outrageously expensive for what it is. At least with the Gigabyte you can argue that to put together an equivalent Xeon system would cost you at least as much.

...

OTOH, the MP30-AR0 is standard Micro-ATX in every way, and can take up to 128GB of RAM (it's a bit surreal of amazing to suddenly go from bashing my head against the limits of tiny memory on ARM bords to one that I can just fill up with 128GB of RAM I have lying around!).

Believe me, I'm appreciating the 32 GB in this Gigabyte board, and may upgrade it to 64 GB. Previously I had only 16 GB in any ARM system (Mustang) which is usable, but a bit tight when you're doing lots of virt.

My main motivation for this is for a build farm machine. Rebuilding a whole distro even on something like a Chromebook 2 takes forever. Not to mention the pain when the original release of my distro was built on a few {Sheeva|Dream}Plugs. In 128GB of RAM I could just have the whole mock build process go 8-at-a-time with /var/lib/mock on tmpfs and still manage to build LibreOffice.

Gordan

On 05/03/16 13:11, Richard W.M. Jones wrote:

On Sat, Mar 05, 2016 at 12:39:02PM +0000, Gordan Bobic wrote:

...

Just out of interest, what is better about the AMD Seattle CPU compared to the X-Gene on the Gigabyte board?

A57 cores. Memory bandwidth is slightly faster too.

I cannot claim to have investigated the differences between A57 and X-Gene in great detail but from the quick overview table here: https://en.wikipedia.org/wiki/Comparison_of_ARMv8-A_cores it looks like if anything the X-Gene is likely to be faster given it has a L3 on-chip cache which A57 doesn't seem to.

Gordan

On Sat, Mar 05, 2016 at 10:26:25AM +0700, Phong Vo wrote:

There should be no issue of replacing U-boot in SPI nor with the mp30ar0 Tianocore version. But you need to use the mp30ar0_tianocore_media.img I provide, not the one supplied with the Mustang board. It was likely the person burn the wrong BIOS on the board!

You can burn the Tianocore image from U-boot using TFTP. Please check and setup your U-boot variables:

media_addr_r=0x4001000000 media_img=mp30ar0_tianocore_media.img spi_load=tftp ${media_addr_r} ${user_dir}/${media_img} spi_update=sf probe 0; sf erase 0x0 ${filesize}; sf write ${media_addr_r} 0x0 ${filesize}

To be absolutely clear, the above are not u-boot commands? You have to use setenv and quote the parameters?

Second question: In the tarball you previously posted, the .img file is called 'mp30ar0_media.img' (not 'mp30ar0_tianocore_media.img'). Is that correct or is there a newer version somewhere?

Third question: How do I set the MAC address in this TianoCore? RHEL booted up with MAC 00:00:00:00:00:00 which meant nothing else worked of course.

Rich.

# run spi_load <== Make sure it is successful # run spi_update # reset

If there is any issue, it's still recoverable using SD card.

-Phong

-----Original Message----- From: arm-dev-bounces@centos.org [mailto:arm-dev-bounces@centos.org] On Behalf Of Michael Howard Sent: Friday, March 04, 2016 9:05 PM To: arm-dev@centos.org Subject: Re: [Arm-dev] Gigabyte MP30-AR0

On 04/03/2016 11:47, Richard W.M. Jones wrote:

...

On Sat, Feb 20, 2016 at 11:06:08AM +0700, Phong Vo wrote:

...

In theory, you just need to convert CentOS vmlinuz to uImage, then do

U-boot

...

...

boot using the dtb and CentOS initrd.img; but somehow it hangs on me. I'll need to dig into it further.

I am not aware that it was shipped only with U-boot. If you want to try

with

...

...

UEFI, take it from my dropbox

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.ta r.xz

...

...

mp30ar0_tianocore_media.img: burn to SPI NOR if you want to replace

U-boot

...

...

permanently

Has anyone tried this step ^^ (replacing u-boot permanently)?

I'm not too keen to brick an $800 board. Is it reversible?

No, not tried it, don't see the point of risking it at the mo. Somebody did brick their board (https://lists.centos.org/pipermail/arm-dev/2016-February/001622.html) and for me, I just chainload tianocore from u-boot via tftp.

-- Mike Howard

---

Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev

On 05/03/16 11:56, Richard W.M. Jones wrote:

On Sat, Mar 05, 2016 at 10:26:25AM +0700, Phong Vo wrote:

...

There should be no issue of replacing U-boot in SPI nor with the mp30ar0 Tianocore version. But you need to use the mp30ar0_tianocore_media.img I provide, not the one supplied with the Mustang board. It was likely the person burn the wrong BIOS on the board!

You can burn the Tianocore image from U-boot using TFTP. Please check and setup your U-boot variables:

media_addr_r=0x4001000000 media_img=mp30ar0_tianocore_media.img spi_load=tftp ${media_addr_r} ${user_dir}/${media_img} spi_update=sf probe 0; sf erase 0x0 ${filesize}; sf write ${media_addr_r} 0x0 ${filesize}

To be absolutely clear, the above are not u-boot commands? You have to use setenv and quote the parameters?

The above looks like a subset of what printenv returns in u-boot. To set it the equivalent incantation would be:

setenv media_addr_r '0x4001000000' setenv media_img 'mp30ar0_tianocore_media.img' setenb spi_load=tftp '${media_addr_r} ${user_dir}/${media_img}' setenv spi_update=sf 'probe 0; sf erase 0x0 ${filesize}; sf write ${media_addr_r} 0x0 ${filesize}'

Apologies for the extra linebreak on the last line due to MUA wrapping the lines.

Second question: In the tarball you previously posted, the .img file is called 'mp30ar0_media.img' (not 'mp30ar0_tianocore_media.img'). Is that correct or is there a newer version somewhere?

Third question: How do I set the MAC address in this TianoCore? RHEL booted up with MAC 00:00:00:00:00:00 which meant nothing else worked of course.

Michael raised this issue earlier. Even though the MAC addresses are set correctly in u-boot, it looks like the kernel doesn't pick it up.

Gordan

On Mon, Mar 07, 2016 at 04:58:57PM +0700, Phong Vo wrote:

...

The above looks like a subset of what printenv returns in u-boot. To set it the equivalent incantation would be:

...

setenv media_addr_r '0x4001000000' setenv media_img 'mp30ar0_tianocore_media.img' setenb spi_load=tftp '${media_addr_r} ${user_dir}/${media_img}' setenv spi_update=sf 'probe 0; sf erase 0x0 ${filesize}; sf write

${media_addr_r} 0x0 ${filesize}'

Just a note that it's likely that these env variables are already there, except for media_img. In which case, you just need to

setenv media_img 'mp30ar0_tianocore_media.img'

Can I check I have the right version of this file? I have a file with a different name:

$ ls -l mp30ar0_media.img -rw-r--r--. 1 root root 620032 Mar 5 10:57 mp30ar0_media.img $ md5sum mp30ar0_media.img 7d31c9b9dd40b791adf92067ed2a236a mp30ar0_media.img

Rich.

On Tue, Mar 08, 2016 at 09:34:10AM +0700, Phong Vo wrote:

Sorry, that was not the right file.

Please download again

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.tar....

You should find mp30ar0_tianocore_media.img

# md5sum mp30ar0_tianocore_media.img 0bd49584eb7bedb513d0b1c545eee6ce mp30ar0_tianocore_media.img

Thanks. I can confirm that I was able to successfully and permanently flash Tianocore UEFI to the Gigabyte board using the above image.

The procedure was as outlined before, but I'm going to summarise it again so it's in one place:

(1) Download and unpack mp30ar0_tianocore_binaries.tar.xz from the link above. Verify mp30ar0_tianocore_media.img has the correct MD5 checksum.

(2) Place mp30ar0_tianocore_media.img on a TFTP server so it is available as `mp30ar0/mp30ar0_tianocore_media.img'

(3) Interrupt u-boot boot sequence, and run the following commands:

setenv ipaddr xx.xx.xx.xx # server's own IP address setenv serverip yy.yy.yy.yy # IP address of TFTP server setenv media_img mp30ar0_tianocore_media.img run spi_load # check this command succeeds run spi_update reset

Rich.

On Sat, Mar 05, 2016 at 12:15:54PM +0000, Michael Howard wrote:

Once in the UEFI shell, use 'set MAC0 xx:xx:xx:xx:xx:xx' and 'set MAC1 xx:xx:xx:xx:xx:xx'

Thanks - that worked. Although note for anyone trying to follow these instructions, I had to reboot after setting MAC0 before the installer would "see" the change.

Finally, I'm in a VNC-based RHELSA 7.2 install.

Rich.

On Sat, Mar 05, 2016 at 01:42:08PM +0000, Michael Howard wrote:

On 05/03/2016 13:38, Richard W.M. Jones wrote:

...

On Sat, Mar 05, 2016 at 12:15:54PM +0000, Michael Howard wrote:

...

Once in the UEFI shell, use 'set MAC0 xx:xx:xx:xx:xx:xx' and 'set MAC1 xx:xx:xx:xx:xx:xx'

Thanks - that worked. Although note for anyone trying to follow these instructions, I had to reboot after setting MAC0 before the installer would "see" the change.

Even that didn't help with the Centos installer, I had to edit the kernel command line and add ip details there.

Does CentOS also require acpi=off on the command line? RHELSA 7.2 certainly requires it, which may indicate that the TianoCore binary has missing or incomplete ACPI tables.

Rich.

On 05/03/2016 03:26, Phong Vo wrote:

There should be no issue of replacing U-boot in SPI nor with the mp30ar0 Tianocore version. But you need to use the mp30ar0_tianocore_media.img I provide, not the one supplied with the Mustang board. It was likely the person burn the wrong BIOS on the board!

You can burn the Tianocore image from U-boot using TFTP. Please check and setup your U-boot variables:

media_addr_r=0x4001000000 media_img=mp30ar0_tianocore_media.img spi_load=tftp ${media_addr_r} ${user_dir}/${media_img} spi_update=sf probe 0; sf erase 0x0 ${filesize}; sf write ${media_addr_r} 0x0 ${filesize}

# run spi_load <== Make sure it is successful # run spi_update # reset

If there is any issue, it's still recoverable using SD card.

-Phong

Hi,

I know this is a very old thread but is there any source available for the image above or for mp30ar0_tianocore_sec_ubt.fd/mp30ar0_tianocore_ubt.fd?

The reason I ask is that I'm attempting to get the SDCARD slot working with recent kernels and the only way I can get it to work is booting directly from the original u-boot environment using the original devicetree blob. However, booting that way I end up with only one core.

Booting as above with 'num_cores' set to 8 causes a hang late on.

Cheers, Mike.

On Fri, Mar 04, 2016 at 02:05:08PM +0000, Michael Howard wrote:

On 04/03/2016 11:47, Richard W.M. Jones wrote:

...

On Sat, Feb 20, 2016 at 11:06:08AM +0700, Phong Vo wrote:

...

In theory, you just need to convert CentOS vmlinuz to uImage, then do U-boot boot using the dtb and CentOS initrd.img; but somehow it hangs on me. I'll need to dig into it further.

I am not aware that it was shipped only with U-boot. If you want to try with UEFI, take it from my dropbox

https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_binaries.tar....

mp30ar0_tianocore_media.img: burn to SPI NOR if you want to replace U-boot permanently

Has anyone tried this step ^^ (replacing u-boot permanently)?

I'm not too keen to brick an $800 board. Is it reversible?

No, not tried it, don't see the point of risking it at the mo. Somebody did brick their board (https://lists.centos.org/pipermail/arm-dev/2016-February/001622.html) and for me, I just chainload tianocore from u-boot via tftp.

Indeed - that was me! Fun times. I'm all up & running on CentOS 7.2 now, though, thanks to the help of you fine folks on here.

One thing I did change was to not boot via TFTP since I'd rather not have booting dependent on network availability. Instead I'm loading via SD. It was pretty straight forward but, in case anyone else is interested, I replaced the load_tianocore variable like so (assuming dev 0, part 1):

setenv load_tianocore 'fatload mmc 0:1 0x82000000 mp30ar0_tianocore_ubt.fd; fatload mmc 0:1 0x1d000000 mp30ar0_tianocore_sec_ubt.fd'

Stoked. Thanks again, guys!