Hi,
I am trying to use a basic initramfs containing a 32bit busybox when booting the LSK built for arm64 on the ARM FVP.
The initramfs I am using works fine on the arm32 kernel running on 32bit model.
It unpacks ok on the 64 bit model but in init/main.c it tries to run the /init script I get an ENOENT error returned from sys_access
ret = sys_access((const char __user *) ramdisk_execute_command, 0);
/init does exist in the initramfs...
Anyone got any ideas for what the problem is?
Mark
On Wed, Jan 29, 2014 at 11:01:33AM +0000, Mark Hambleton wrote:
I am trying to use a basic initramfs containing a 32bit busybox when booting the LSK built for arm64 on the ARM FVP.
The initramfs I am using works fine on the arm32 kernel running on 32bit model.
It unpacks ok on the 64 bit model but in init/main.c it tries to run the /init script I get an ENOENT error returned from sys_access
ret = sys_access((const char __user *) ramdisk_execute_command, 0);
/init does exist in the initramfs...
Anyone got any ideas for what the problem is?
I just tried using the initramfs that should be going into the 14.01 release at:
http://releases.linaro.org/14.01/openembedded/images/minimal-initramfs-armv7...
which works for me on the 4x4 fast model with the initramfs built into the kernel. How did you supply your initramfs and verify that it unpacks OK?
Anyone got any ideas for what the problem is?
I just tried using the initramfs that should be going into the 14.01 release at: http://releases.linaro.org/14.01/openembedded/images/minimal-initramfs-armv7... which works for me on the 4x4 fast model with the initramfs built into the kernel.
Ok, so I just tried that initramfs and get
"Failed to execute /init"
And then a panic.
Do you have something special on the kernel command line for that initramfs that points somewhere other than /init?
How did you supply your initramfs and verify that it unpacks OK?
The initramfs is supplied either via UEFI or UBOOT (yes UBOOT) at addr=88000000 size=4f340b, the kernel finds this manages to decompress (verified by single stepping in DS-5), uboot/uefi set the initrd-start and initrd-end in the chosen node so the kernel knows where to look, that all seems to work.
I have an openembedded initrd that I supply in the same way which works fine, its just huge... hence the desire to move to a really simple initramfs.
Mark
On Wed, Jan 29, 2014 at 03:40:36PM +0000, Mark Hambleton wrote:
Do you have something special on the kernel command line for that initramfs that points somewhere other than /init?
No, my kernel command line has no reference to initramfs at all - I've not changed it at all to start using one.
How did you supply your initramfs and verify that it unpacks OK?
The initramfs is supplied either via UEFI or UBOOT (yes UBOOT) at addr=88000000 size=4f340b, the kernel finds this manages to decompress (verified by single stepping in DS-5), uboot/uefi set the initrd-start and initrd-end in the chosen node so the kernel knows where to look, that all seems to work.
How do you do that? I don't know how to configure UEFI and Google isn't turning up anything quickly.
I have an openembedded initrd that I supply in the same way which works fine, its just huge... hence the desire to move to a really simple initramfs.
The Linaro image above is OE based too so it's unlikely to be that... Can you try building the image in (CONFIG_INITRAMFS_SOURCE)?
How did you supply your initramfs and verify that it unpacks OK?
The initramfs is supplied either via UEFI or UBOOT (yes UBOOT) at addr=88000000 size=4f340b, the kernel finds this manages to decompress (verified by single stepping in DS-5), uboot/uefi set the initrd-start and initrd-end in the chosen node so the kernel knows where to look, that all seems to work.
How do you do that? I don't know how to configure UEFI and Google isn't turning up anything quickly.
I modified : ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
- gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"console=ttyAMA0 earlyprintk=pl011,0x1c090000 debug user_debug=31 loglevel=9 root=/dev/vda2" + gArmPlatformTokenSpaceGuid.PcdDefaultBootInitrdPath|L"VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/ramdisk.img" + gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"console=ttyAMA0 earlyprintk=pl011,0x1c090000 debug user_debug=31 loglevel=9"
Your ramdisk then needs to be in the directory you launch the fastmodel from.
I guess you are still passing root=/dev/vda2 in... I will try that with UEFI.
I have an openembedded initrd that I supply in the same way which works fine, its just huge... hence the desire to move to a really simple initramfs.
The Linaro image above is OE based too so it's unlikely to be that... Can you try building the image in (CONFIG_INITRAMFS_SOURCE)?
Yep, have tried that before... same problem that it can't find /init.
I am running a slightly older LSK which could explain this, but I haven't seen any likely fixes go in.
Mark
On Wed, Jan 29, 2014 at 04:25:34PM +0000, Mark Hambleton wrote:
How do you do that? I don't know how to configure UEFI and Google isn't turning up anything quickly.
I modified : ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
I don't appear to have a file by that name on my system or even the directory, where should this come from?
Ah sorry, that is part of the UEFI source code...
https://git.linaro.org/uefi/linaro-edk2.git/blob/refs/heads/master:/ArmPlatf...
We build everything from source.
Mark
-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: 29 January 2014 16:54 To: Mark Hambleton Cc: linaro-kernel@lists.linaro.org Subject: Re: initramfs on arm64 (LSK) issues on fastmodels
* PGP Signed by an unknown key
On Wed, Jan 29, 2014 at 04:25:34PM +0000, Mark Hambleton wrote:
How do you do that? I don't know how to configure UEFI and Google isn't turning up anything quickly.
I modified : ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
I don't appear to have a file by that name on my system or even the directory, where should this come from?
* Unknown Key * 0x7EA229BD
On Wed, Jan 29, 2014 at 04:56:15PM +0000, Mark Hambleton wrote:
Ah sorry, that is part of the UEFI source code...
https://git.linaro.org/uefi/linaro-edk2.git/blob/refs/heads/master:/ArmPlatf...
We build everything from source.
OK, I'll have a go at building that. The UEFI guys aren't terribly enthusiastic about the LinuxLoader stuff though you do say it's also failing with u-boot so... It'd definitely be interesting to know what happens if you build the initrd in, that would narrow it down to something to do with the bootloader handoff if it works.
The lack of complaints from the kernel about either failed decompression or cpio unpacking is certainly odd...
On 01/30/2014 12:56 AM, Mark Hambleton wrote:
Ah sorry, that is part of the UEFI source code...
https://git.linaro.org/uefi/linaro-edk2.git/blob/refs/heads/master:/ArmPlatf...
We build everything from source.
hi, Mark,
Do you mind to give more detailed reproduce steps or fire a bug LSK on https://bugs.launchpad.net/linaro-stable-kernel/+bugs
Mark
-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: 29 January 2014 16:54 To: Mark Hambleton Cc: linaro-kernel@lists.linaro.org Subject: Re: initramfs on arm64 (LSK) issues on fastmodels
- PGP Signed by an unknown key
On Wed, Jan 29, 2014 at 04:25:34PM +0000, Mark Hambleton wrote:
How do you do that? I don't know how to configure UEFI and Google isn't turning up anything quickly.
I modified : ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
I don't appear to have a file by that name on my system or even the directory, where should this come from?
- Unknown Key
- 0x7EA229BD
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
Do you mind to give more detailed reproduce steps or fire a bug LSK on https://bugs.launchpad.net/linaro-stable-kernel/+bugs
I want to do an update to the Jan-14 LSK first, this may just auto-magically go away.
Mark
On Thu, Jan 30, 2014 at 10:18:34AM +0000, Mark Hambleton wrote:
Do you mind to give more detailed reproduce steps or fire a bug LSK on https://bugs.launchpad.net/linaro-stable-kernel/+bugs
I want to do an update to the Jan-14 LSK first, this may just auto-magically go away.
The current code will be the release, I'm just waiting for final test results before tagging it - the tag should be there later today.
So I just tried my current set up with the head of lsk-android and still get the boot failure.
Tried then building in as INITRAMFS_SOURCE and see this in the kernel log:
[ 22.541380] Trying to unpack rootfs image as initramfs... [ 24.752456] Freeing initrd memory: 5068K (ffffffc007b0c000 - ffffffc007fff000)
(this is using the initramfs you sent the link to earlier Mark)
Then I get this:
[ 25.603992] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
And a generic set of walkbacks from the stop IPI.
Mark
On Thu, Jan 30, 2014 at 11:44:05AM +0000, Mark Hambleton wrote:
So I just tried my current set up with the head of lsk-android and still get the boot failure.
Tried then building in as INITRAMFS_SOURCE and see this in the kernel log:
[ 22.541380] Trying to unpack rootfs image as initramfs... [ 24.752456] Freeing initrd memory: 5068K (ffffffc007b0c000 - ffffffc007fff000)
(this is using the initramfs you sent the link to earlier Mark)
Then I get this:
[ 25.603992] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
And a generic set of walkbacks from the stop IPI.
Could you provide the full log please? It looks like init has decided to exit for some reason... I was using the vanilla LSK when I tested, just going to try with Android.
I've attached the kernel config I'm using for my tests.
On Thu, Jan 30, 2014 at 12:02:12PM +0000, Mark Brown wrote:
Could you provide the full log please? It looks like init has decided to exit for some reason... I was using the vanilla LSK when I tested, just going to try with Android.
I've attached the kernel config I'm using for my tests.
The Android kernel also works for me. The fast model I'm using is version 0.8.5202 and I've attached the .config.
Will get the full kernel logs to you, can you send me the command you use to run the model?
Thanks,
Mark
-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: 30 January 2014 12:02 To: Mark Hambleton Cc: Alex Shi; linaro-kernel@lists.linaro.org Subject: Re: initramfs on arm64 (LSK) issues on fastmodels
* PGP Signed by an unknown key
On Thu, Jan 30, 2014 at 11:44:05AM +0000, Mark Hambleton wrote:
So I just tried my current set up with the head of lsk-android and still get the boot failure.
Tried then building in as INITRAMFS_SOURCE and see this in the kernel log:
[ 22.541380] Trying to unpack rootfs image as initramfs... [ 24.752456] Freeing initrd memory: 5068K (ffffffc007b0c000 - ffffffc007fff000)
(this is using the initramfs you sent the link to earlier Mark)
Then I get this:
[ 25.603992] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
And a generic set of walkbacks from the stop IPI.
Could you provide the full log please? It looks like init has decided to exit for some reason... I was using the vanilla LSK when I tested, just going to try with Android.
I've attached the kernel config I'm using for my tests.
* Unknown Key * 0x7EA229BD
On Thu, Jan 30, 2014 at 12:48:51PM +0000, Mark Hambleton wrote:
Will get the full kernel logs to you, can you send me the command you use to run the model?
I'm using:
~/models/FVP_Base_Cortex-A57-A53x14/models/Linux64_GCC-4.1/FVP_Base_Cortex-A57x4-A53x4 -C pctl.startup=0.0.0.0 -C bp.secure_memory=0 -C cache_state_modelled=1 -C bp.pl011_uart0.untimed_fifos=1 -C bp.secureflashloader.fname=bl1.bin -C bp.flashloader0.fname=uefi_fvp-base.bin -C bp.virtioblockdevice.image_path=sd.img
Ok, so 2 differences here:
~/models/FVP_Base_Cortex-A57-A53x14/models/Linux64_GCC-4.1/FVP_Base_Cortex-A57x4-A53x4
You are using a 64bit build of the model, I use a 32bit build from day to day. I found there are problems with the virtioblock device when run on 32bit models... maybe this is another case... I will check.
bp.virtioblockdevice.image_path=sd.img
What is the sd.img you are passing in? (hopefully that isn't the rootfs)
Mark
On Thu, Jan 30, 2014 at 12:54:47PM +0000, Mark Hambleton wrote:
bp.virtioblockdevice.image_path=sd.img
What is the sd.img you are passing in? (hopefully that isn't the rootfs)
It's a Linaro OE rootfs - when I boot with the Linaro initramfs it's not being mounted though (the prompts are different and I can replace it with an empty file to identical effect).
So, using LSK head and your .config I can boot that initramfs....
Now going off to see what it different in the .configs
Mark
On Thu, Jan 30, 2014 at 02:28:36PM +0000, Mark Hambleton wrote:
So, using LSK head and your .config I can boot that initramfs....
Now going off to see what it different in the .configs
OK, good - that's progress. Feel free to send your .config as well and we can try checking too.
I think I have found it...
I can now boot with the uncompressed initramfs, compressed is still a problem but looks to be resolved by the rebase (waiting on your 1-14 label for that).
These were missing: +CONFIG_COMPAT=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_SIZE=65536
I tried with COMPAT yesterday but the combination of that and BLK_DEV_RAM seems to have fixed the problem.
Thanks for your help!
Mark
On Thu, Jan 30, 2014 at 04:43:11PM +0000, Mark Hambleton wrote:
I can now boot with the uncompressed initramfs, compressed is still a problem but looks to be resolved by the rebase (waiting on your 1-14 label for that).
The tags went up earlier this afternoon - lsk-14.01 and lsk-android-14.01.
These were missing: +CONFIG_COMPAT=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_SIZE=65536
I tried with COMPAT yesterday but the combination of that and BLK_DEV_RAM seems to have fixed the problem.
Hrm, that suggests that the image is an initrd rather than an initramfs?
linaro-kernel@lists.linaro.org