On Tue, Mar 19, 2013 at 6:15 PM, Arthy Sundaram <
arthys...@gmail.com> wrote:
> 1. It hangs.
> The partition 7 is in ext4 format is it the reason?
I don't know. This could be the reason. In theory an ext2load should
be able to read stuff from an ext4 file system just fine. But ChromeOS
U-boot was branched from v2011.12 and the mainline has ext4 now; so
even if it's actually a bug, I suppose it would not be fixed.
A workaround is to put your kernel in EFI System partition, and patch
include/configs/chromeos.h to load from there:
diff --git a/include/configs/chromeos.h b/include/configs/chromeos.h
index 73e77d6..649e7b7 100644
--- a/include/configs/chromeos.h
+++ b/include/configs/chromeos.h
@@ -157,7 +157,7 @@
\
"ext2_boot=" \
"run regen_ext2_bootargs; " \
- "if ext2load ${devtype} ${devnum}:${rootpart} " \
+ "if fatload ${devtype} ${devnum}:${script_part} " \
"${loadaddr} ${cros_bootfile}; then " \
"if test ${kernaddr} != \"\"; then "\
"echo \"Using bundled kernel\"; "\
But then it would not be upgraded if your ubuntu upgrades the kernel
in the rootfs.
Or you could patch your U-Boot with ext4. This should not be very hard.
> 2. I think it is the uImage of the ChrUbuntu 12 the script that was used to
> install doesnt have
> the FIT image generation
> (mkimage -f kernel.its kernel.itb which is normally done for FIT generation)
> They just vboot sign it and dd it to the partition 7.
>
> This is the output however -
> mkimage: Bad Magic number: vmlinuz-3.4.0 is no valid image
> Image Type: Davinci UBL Boot Image
> UBL magic:
> Entry Point: ee109f10
> nr of pages:
> start block : e1b0a005
> start page : 0a13b493
I see. Thanks for checking this. This should not be our problem. Our
problem is that U-Boot seems to have trouble with ext4.
> 3. here load addr is 0x42000000 since both kernel and boot scr are loaded on
> the same
> address i was wondering if there's something to beware of..
This is okay. script_img is loaded to loadaddr and immediately
sourced. So overwriting it with kernel image later is fine.