[opensuse-arm] AArch64 EFI builds
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
Alexander Graf <agraf@suse.de> 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
On 31.08.14 19:35, Andreas Schwab wrote:
Alexander Graf <agraf@suse.de> 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
On 31.08.14 21:33, Alexander Graf wrote:
On 31.08.14 19:35, Andreas Schwab wrote:
Alexander Graf <agraf@suse.de> 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
On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:
On 31.08.14 19:35, Andreas Schwab wrote:
Alexander Graf <agraf@suse.de> 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
Am 01.09.2014 um 09:01 schrieb Adrian Schröter <adrian@suse.de>:
On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:
On 31.08.14 19:35, Andreas Schwab wrote:
Alexander Graf <agraf@suse.de> 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
On Montag, 1. September 2014, 09:10:05 wrote Alexander Graf:
Am 01.09.2014 um 09:01 schrieb Adrian Schröter <adrian@suse.de>:
On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:
On 31.08.14 19:35, Andreas Schwab wrote:
Alexander Graf <agraf@suse.de> 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
Am 01.09.2014 um 09:19 schrieb Adrian Schröter <adrian@suse.de>:
On Montag, 1. September 2014, 09:10:05 wrote Alexander Graf:
Am 01.09.2014 um 09:01 schrieb Adrian Schröter <adrian@suse.de>:
On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:
On 31.08.14 19:35, Andreas Schwab wrote:
Alexander Graf <agraf@suse.de> 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
On Montag, 1. September 2014, 09:28:02 wrote Alexander Graf:
Am 01.09.2014 um 09:19 schrieb Adrian Schröter <adrian@suse.de>:
On Montag, 1. September 2014, 09:10:05 wrote Alexander Graf:
Am 01.09.2014 um 09:01 schrieb Adrian Schröter <adrian@suse.de>:
On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:
On 31.08.14 19:35, Andreas Schwab wrote:
Alexander Graf <agraf@suse.de> 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
Am 01.09.2014 um 09:34 schrieb Adrian Schröter <adrian@suse.de>:
On Montag, 1. September 2014, 09:28:02 wrote Alexander Graf:
Am 01.09.2014 um 09:19 schrieb Adrian Schröter <adrian@suse.de>:
On Montag, 1. September 2014, 09:10:05 wrote Alexander Graf:
Am 01.09.2014 um 09:01 schrieb Adrian Schröter <adrian@suse.de>:
On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:
> On 31.08.14 19:35, Andreas Schwab wrote: > Alexander Graf <agraf@suse.de> 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
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 <adrian@suse.de>:
On Montag, 1. September 2014, 09:10:05 wrote Alexander Graf:
Am 01.09.2014 um 09:01 schrieb Adrian Schröter <adrian@suse.de>:
On Sonntag, 31. August 2014, 21:33:02 wrote Alexander Graf:
On 31.08.14 19:35, Andreas Schwab wrote: > Alexander Graf <agraf@suse.de> 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
Adrian Schröter <adrian@suse.de> writes:
I have added it now to
openSUSE:Factory:ARM/aggregate_for_x86_64
and adapted the prjconf.
Should be fine now.
That doesn't appear to work, kernel-obs-build is still missing in both standard/aarch64 and standard/armv6l. 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
On Montag, 1. September 2014, 13:47:19 wrote Andreas Schwab:
Adrian Schröter <adrian@suse.de> writes:
I have added it now to
openSUSE:Factory:ARM/aggregate_for_x86_64
and adapted the prjconf.
Should be fine now.
That doesn't appear to work, kernel-obs-build is still missing in both standard/aarch64 and standard/armv6l.
I have not changed it for native builds, only for qemu repo. If you want it also for native builds, you need to build a proper kernel-obs-build package providing the right set of kernel modules first. -- 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 <adrian@suse.de> writes:
On Montag, 1. September 2014, 13:47:19 wrote Andreas Schwab:
Adrian Schröter <adrian@suse.de> writes:
I have added it now to
openSUSE:Factory:ARM/aggregate_for_x86_64
and adapted the prjconf.
Should be fine now.
That doesn't appear to work, kernel-obs-build is still missing in both standard/aarch64 and standard/armv6l.
I have not changed it for native builds, only for qemu repo.
There are no native builds, and the qemu repo is unused. 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
Adrian Schröter <adrian@suse.de> writes:
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.
I've readded VMinstall: !kernel-obs-build for armv7l. This is needed to override the prjconf setting from oS:Factory. 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
On Montag, 1. September 2014, 10:59:15 wrote Andreas Schwab:
Adrian Schröter <adrian@suse.de> writes:
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.
I've readded VMinstall: !kernel-obs-build for armv7l. This is needed to override the prjconf setting from oS:Factory.
also for qemu builds? -- 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 <adrian@suse.de> writes:
On Montag, 1. September 2014, 10:59:15 wrote Andreas Schwab:
Adrian Schröter <adrian@suse.de> writes:
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.
I've readded VMinstall: !kernel-obs-build for armv7l. This is needed to override the prjconf setting from oS:Factory.
also for qemu builds?
armv7l is building natively (my first attempt at fixing it was wrong, but it should be correct now). Note that all armv6l build are currently failing due to missing kernel-obs-build. 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
participants (3)
-
Adrian Schröter -
Alexander Graf -
Andreas Schwab