[opensuse-arm] AArch64 EFI builds

newer
[opensuse-arm] opensuse cubox-i...

older
[opensuse-arm] U-Boot v2014.07 -...

Alexander Graf

31 Aug 2014 31 Aug '14

16:31

Howdy, I've enabled a new "efi" target for AArch64 image builds. This target takes the default kernel and builds an image with it for SBSA and SBBA compliant AArch64 systems. In a nutshell, it hopefully allows us to have a single image for all AArch64 platforms we care about. To try it out, fetch it from http://download.opensuse.org/ports/aarch64/factory/images/ (a patched kiwi is still building, expect the images to drop out in a few hours - I've verified that the image is built correctly locally) and unless you have real hardware, get yourself a copy of the Foundation model: http://www.arm.com/products/tools/models/fast-models/foundation-model.php and a recent build of uEFI for the Foundation model: http://releases.linaro.org/13.12/components/kernel/uefi-linaro/uefi-bootstra... http://snapshots.linaro.org/components/kernel/linaro-edk2/22/release/uefi_fo... Then you can just run a guest with $ Foundation_v8 \ --image=uefi-bootstrap-el3-foundation.axf \ --no-secure-memory \ --data=uefi_foundation.bin@0xa0000000 \ --block-device=openSUSE*efi*raw For some reason the firmware does not detect the default boot entry of the disk (to be debugged), so you have to manually point it to efi\boot\boota64.efi as boot binary in its menu. Then you should see grub showing up with a proper menu. You can select the entry it tries to start the kernel and then at least for me I get a good bunch of Synchronous Exception at 0x0000000080080210 but all of the groundwork is there for people to play with it now :). Happy ARM hacking! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Show replies by date

Andreas Schwab

31 Aug 31 Aug

17:35

Alexander Graf writes:

...

For some reason the firmware does not detect the default boot entry of the disk (to be debugged), so you have to manually point it to

efi\boot\boota64.efi

That should be bootaa64.efi according to the UEFI specs. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

19:33

On 31.08.14 19:35, Andreas Schwab wrote:

...

Alexander Graf writes:

...
For some reason the firmware does not detect the default boot entry of the disk (to be debugged), so you have to manually point it to

efi\boot\boota64.efi

That should be bootaa64.efi according to the UEFI specs.

Nicely spotted, thanks for fixing. It still doesn't boot though. Also the image can't get built right now in OBS because we're lacking iso8859-1 kernel module support in the x86 vm kernel (which would have to get modprobe'd by the initrd). Adrian, I think we had this problem before, didn't we? How did we fix it? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

21:44

On 31.08.14 21:33, Alexander Graf wrote:

...

On 31.08.14 19:35, Andreas Schwab wrote:

...
Alexander Graf writes:

...
For some reason the firmware does not detect the default boot entry of the disk (to be debugged), so you have to manually point it to

efi\boot\boota64.efi

That should be bootaa64.efi according to the UEFI specs.

Nicely spotted, thanks for fixing. It still doesn't boot though.

Ok, so there are 2 more issues. 1) The serial port needs to be in console=... on the kernel cmdline. The Foundation model models a plsomething with ttyAMA0 (sigh). I added "console=ttyAMA0,115200 console=ttyS0,115200n8 console=tty" to the kernel command line for efi builds. 2) The Linaro EFI blob does not contain a working device tree. If I pass the device tree manually with grub, it works. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Adrian Schröter

1 Sep 1 Sep

07:01

On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:

...

On 31.08.14 19:35, Andreas Schwab wrote:

...
Alexander Graf writes:

...
For some reason the firmware does not detect the default boot entry of the disk (to be debugged), so you have to manually point it to

efi\boot\boota64.efi

That should be bootaa64.efi according to the UEFI specs.

Nicely spotted, thanks for fixing. It still doesn't boot though.

Also the image can't get built right now in OBS because we're lacking iso8859-1 kernel module support in the x86 vm kernel (which would have to get modprobe'd by the initrd).

Adrian, I think we had this problem before, didn't we? How did we fix it?

In old times this dependended on the worker configuration. But meanwhile we can provider own kernel & initrd in our projects to have this configured in a way that lasts :) I suppose you talk about openSUSE:Factory:ARM/images repo for aarch64? There is currently a VMinstall: !kernel-obs-build in prjconf, which enforces to skip to use the own kernel&initrd for inside of openSUSE:Factory:ARM. I have moved this line now, that we use it at least for qemu builds. You may need to trigger a rebuild manually to check if that works. Also check that kernel-obs-build package gets installed before starting the VM. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

07:10

...

Am 01.09.2014 um 09:01 schrieb Adrian Schröter :

On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:

...
On 31.08.14 19:35, Andreas Schwab wrote:

...
Alexander Graf writes:

...
For some reason the firmware does not detect the default boot entry of the disk (to be debugged), so you have to manually point it to

efi\boot\boota64.efi

That should be bootaa64.efi according to the UEFI specs.

Nicely spotted, thanks for fixing. It still doesn't boot though.

Also the image can't get built right now in OBS because we're lacking iso8859-1 kernel module support in the x86 vm kernel (which would have to get modprobe'd by the initrd).

Adrian, I think we had this problem before, didn't we? How did we fix it?

In old times this dependended on the worker configuration.

But meanwhile we can provider own kernel & initrd in our projects to have this configured in a way that lasts :)

I suppose you talk about openSUSE:Factory:ARM/images repo for aarch64?

There is currently a

VMinstall: !kernel-obs-build

in prjconf, which enforces to skip to use the own kernel&initrd for inside of openSUSE:Factory:ARM.

I have moved this line now, that we use it at least for qemu builds.

But wouldn't thag mean that we'd have to have an x86 obs kernel in the aarch64 repo? Alex

...

You may need to trigger a rebuild manually to check if that works.

Also check that kernel-obs-build package gets installed before starting the VM.

--

Adrian Schroeter email: adrian@suse.de

SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Adrian Schröter

07:19

On Montag, 1. September 2014, 09:10:05 wrote Alexander Graf:

...

...
Am 01.09.2014 um 09:01 schrieb Adrian Schröter :

On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:

...
On 31.08.14 19:35, Andreas Schwab wrote:

...
Alexander Graf writes:

...
For some reason the firmware does not detect the default boot entry of the disk (to be debugged), so you have to manually point it to

efi\boot\boota64.efi

That should be bootaa64.efi according to the UEFI specs.

Nicely spotted, thanks for fixing. It still doesn't boot though.

Also the image can't get built right now in OBS because we're lacking iso8859-1 kernel module support in the x86 vm kernel (which would have to get modprobe'd by the initrd).

Adrian, I think we had this problem before, didn't we? How did we fix it?

In old times this dependended on the worker configuration.

But meanwhile we can provider own kernel & initrd in our projects to have this configured in a way that lasts :)

I suppose you talk about openSUSE:Factory:ARM/images repo for aarch64?

There is currently a

VMinstall: !kernel-obs-build

in prjconf, which enforces to skip to use the own kernel&initrd for inside of openSUSE:Factory:ARM.

I have moved this line now, that we use it at least for qemu builds.

But wouldn't thag mean that we'd have to have an x86 obs kernel in the aarch64 repo?

Yes, we need one. You are right, there is currently only an aarch64 one. I have added it now to openSUSE:Factory:ARM/aggregate_for_x86_64 and adapted the prjconf. Should be fine now. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

07:28

...

Am 01.09.2014 um 09:19 schrieb Adrian Schröter :

On Montag, 1. September 2014, 09:10:05 wrote Alexander Graf:

...
...
Am 01.09.2014 um 09:01 schrieb Adrian Schröter :

On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:

...
On 31.08.14 19:35, Andreas Schwab wrote:

...
Alexander Graf writes:

...
For some reason the firmware does not detect the default boot entry of the disk (to be debugged), so you have to manually point it to

efi\boot\boota64.efi

That should be bootaa64.efi according to the UEFI specs.

Nicely spotted, thanks for fixing. It still doesn't boot though.

Also the image can't get built right now in OBS because we're lacking iso8859-1 kernel module support in the x86 vm kernel (which would have to get modprobe'd by the initrd).

Adrian, I think we had this problem before, didn't we? How did we fix it?

In old times this dependended on the worker configuration.

But meanwhile we can provider own kernel & initrd in our projects to have this configured in a way that lasts :)

I suppose you talk about openSUSE:Factory:ARM/images repo for aarch64?

There is currently a

VMinstall: !kernel-obs-build

in prjconf, which enforces to skip to use the own kernel&initrd for inside of openSUSE:Factory:ARM.

I have moved this line now, that we use it at least for qemu builds.

But wouldn't thag mean that we'd have to have an x86 obs kernel in the aarch64 repo?

Yes, we need one. You are right, there is currently only an aarch64 one.

I have added it now to

openSUSE:Factory:ARM/aggregate_for_x86_64

and adapted the prjconf.

Should be fine now.

So how exactly does this ensure that the kernel module in question is loaded on bootup? The only reason that the obs kernel replacement maybe could help things on native builds is that we can install the kernel in the target fs and have udev automatically load modules for it. But our kernel modules on the target fs are aarch64 and won't work. So instead, we have to make sure that the initrd (which is the only 100% native vm phase) loads our nls kernel module manually. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Adrian Schröter

07:34

On Montag, 1. September 2014, 09:28:02 wrote Alexander Graf:

...

...
Am 01.09.2014 um 09:19 schrieb Adrian Schröter :

On Montag, 1. September 2014, 09:10:05 wrote Alexander Graf:

...
...
Am 01.09.2014 um 09:01 schrieb Adrian Schröter :

On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:

...
On 31.08.14 19:35, Andreas Schwab wrote:

...
Alexander Graf writes:

> For some reason the firmware does not detect the default boot entry of > the disk (to be debugged), so you have to manually point it to > > efi\boot\boota64.efi

That should be bootaa64.efi according to the UEFI specs.

Nicely spotted, thanks for fixing. It still doesn't boot though.

Also the image can't get built right now in OBS because we're lacking iso8859-1 kernel module support in the x86 vm kernel (which would have to get modprobe'd by the initrd).

Adrian, I think we had this problem before, didn't we? How did we fix it?

In old times this dependended on the worker configuration.

But meanwhile we can provider own kernel & initrd in our projects to have this configured in a way that lasts :)

I suppose you talk about openSUSE:Factory:ARM/images repo for aarch64?

There is currently a

VMinstall: !kernel-obs-build

in prjconf, which enforces to skip to use the own kernel&initrd for inside of openSUSE:Factory:ARM.

I have moved this line now, that we use it at least for qemu builds.

But wouldn't thag mean that we'd have to have an x86 obs kernel in the aarch64 repo?

Yes, we need one. You are right, there is currently only an aarch64 one.

I have added it now to

openSUSE:Factory:ARM/aggregate_for_x86_64

and adapted the prjconf.

Should be fine now.

So how exactly does this ensure that the kernel module in question is loaded on bootup?

The build script is loading kernel and initrd which got preinstalled as /.build.kernel.kvm and /.build.initrd.kvm

...

The only reason that the obs kernel replacement maybe could help things on native builds is that we can install the kernel in the target fs and have udev automatically load modules for it. But our kernel modules on the target fs are aarch64 and won't work.

Right, but the initrd should bring the right set of kernel modules already with it.

...

So instead, we have to make sure that the initrd (which is the only 100% native vm phase) loads our nls kernel module manually.

yes, that should be the case with initrd from openSUSE:Factory's kernel-obs-build package for x86_64 -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

07:39

...

Am 01.09.2014 um 09:34 schrieb Adrian Schröter :

On Montag, 1. September 2014, 09:28:02 wrote Alexander Graf:

...
...
Am 01.09.2014 um 09:19 schrieb Adrian Schröter :

On Montag, 1. September 2014, 09:10:05 wrote Alexander Graf:

...
...
Am 01.09.2014 um 09:01 schrieb Adrian Schröter :

On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:

...
> On 31.08.14 19:35, Andreas Schwab wrote: > Alexander Graf writes: > >> For some reason the firmware does not detect the default boot entry of >> the disk (to be debugged), so you have to manually point it to >> >> efi\boot\boota64.efi > > That should be bootaa64.efi according to the UEFI specs.

Nicely spotted, thanks for fixing. It still doesn't boot though.

Also the image can't get built right now in OBS because we're lacking iso8859-1 kernel module support in the x86 vm kernel (which would have to get modprobe'd by the initrd).

Adrian, I think we had this problem before, didn't we? How did we fix it?

In old times this dependended on the worker configuration.

But meanwhile we can provider own kernel & initrd in our projects to have this configured in a way that lasts :)

I suppose you talk about openSUSE:Factory:ARM/images repo for aarch64?

There is currently a

VMinstall: !kernel-obs-build

in prjconf, which enforces to skip to use the own kernel&initrd for inside of openSUSE:Factory:ARM.

I have moved this line now, that we use it at least for qemu builds.

But wouldn't thag mean that we'd have to have an x86 obs kernel in the aarch64 repo?

Yes, we need one. You are right, there is currently only an aarch64 one.

I have added it now to

openSUSE:Factory:ARM/aggregate_for_x86_64

and adapted the prjconf.

Should be fine now.

So how exactly does this ensure that the kernel module in question is loaded on bootup?

The build script is loading kernel and initrd which got preinstalled as /.build.kernel.kvm and /.build.initrd.kvm

...
The only reason that the obs kernel replacement maybe could help things on native builds is that we can install the kernel in the target fs and have udev automatically load modules for it. But our kernel modules on the target fs are aarch64 and won't work.

Right, but the initrd should bring the right set of kernel modules already with it.

...
So instead, we have to make sure that the initrd (which is the only 100% native vm phase) loads our nls kernel module manually.

yes, that should be the case with initrd from openSUSE:Factory's kernel-obs-build package for x86_64

Ah, cool :). Let's see how that goes then! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf

2 Sep 2 Sep

22:06

On 01.09.14 09:34, Adrian Schröter wrote:

...

On Montag, 1. September 2014, 09:28:02 wrote Alexander Graf:

...
...
Am 01.09.2014 um 09:19 schrieb Adrian Schröter :

On Montag, 1. September 2014, 09:10:05 wrote Alexander Graf:

...
...
Am 01.09.2014 um 09:01 schrieb Adrian Schröter :

On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:

...
On 31.08.14 19:35, Andreas Schwab wrote: > Alexander Graf writes: > >> For some reason the firmware does not detect the default boot entry of >> the disk (to be debugged), so you have to manually point it to >> >> efi\boot\boota64.efi > > That should be bootaa64.efi according to the UEFI specs.

Nicely spotted, thanks for fixing. It still doesn't boot though.

Also the image can't get built right now in OBS because we're lacking iso8859-1 kernel module support in the x86 vm kernel (which would have to get modprobe'd by the initrd).

Adrian, I think we had this problem before, didn't we? How did we fix it?

In old times this dependended on the worker configuration.

But meanwhile we can provider own kernel & initrd in our projects to have this configured in a way that lasts :)

I suppose you talk about openSUSE:Factory:ARM/images repo for aarch64?

There is currently a

VMinstall: !kernel-obs-build

in prjconf, which enforces to skip to use the own kernel&initrd for inside of openSUSE:Factory:ARM.

I have moved this line now, that we use it at least for qemu builds.

But wouldn't thag mean that we'd have to have an x86 obs kernel in the aarch64 repo?

Yes, we need one. You are right, there is currently only an aarch64 one.

I have added it now to

openSUSE:Factory:ARM/aggregate_for_x86_64

and adapted the prjconf.

Should be fine now.

So how exactly does this ensure that the kernel module in question is loaded on bootup?

The build script is loading kernel and initrd which got preinstalled as /.build.kernel.kvm and /.build.initrd.kvm

...
The only reason that the obs kernel replacement maybe could help things on native builds is that we can install the kernel in the target fs and have udev automatically load modules for it. But our kernel modules on the target fs are aarch64 and won't work.

Right, but the initrd should bring the right set of kernel modules already with it.

So with this setup we now get build failures for kpartx: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:ARM/JeOS-... Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Andreas Schwab

1 Sep 1 Sep