Stuck between u-boot and chrome os non-dev mode

938 views
Skip to first unread message

newbie_osdev

unread,
Mar 11, 2013, 12:13:16 AM3/11/13
to chromiu...@chromium.org

I am stuck!

I have chromium kernel and rootfs in mmcblk0p2 and 3, ubuntu kernel and rootfs in mmcblk0p6 and p7.

I chainbooted a u-boot ( am completely new to it) from mmcblk0p4 ( cgpt prio high)

( The reason i did this was, i thought booting default chrome would get me to dev mode and i can
still change the partition priority - but now this wouldn happen)

I get to u-boot prompt and as i learn to load one of the other kernels, i get address alignment errors.

I try to get back to my ubuntu partition but am stuck!!

If i do a default boot - bootm on u-boot, i get into chrome but not in developer mode, I have turned off
OS verification but still no use. Hence I am not able to get into my ubuntu partition at all.

Is there someway I can skip entering the u-boot and enter chrome in developer mode and
then i can change the partition priority?

or pass some parameter from u-boot to boot chrome kernel in developer mode?

if yes how??

Mike Frysinger

unread,
Mar 11, 2013, 11:34:02 AM3/11/13
to newbie_osdev, chromium-os-dev
On Mon, Mar 11, 2013 at 12:13 AM, newbie_osdev <arthys...@gmail.com> wrote:
> Is there someway I can skip entering the u-boot and enter chrome in
> developer mode and
> then i can change the partition priority?

i think the only thing you can do is boot an SD card. so
build+install a ChromiumOS build onto that, and boot it (CTRL+U). of
course, this assumes you enabled USB boot last time you were in
ChromeOS.

if CTRL+U doesn't work, then i think the only thing you can do is go
through recovery. pretty sure that'll wipe & re-install your entire
disk.
-mike

Arthy Sundaram

unread,
Mar 11, 2013, 2:21:13 PM3/11/13
to Mike Frysinger, chromium-os-dev
Thank you, I did the recovery overnight. Now the ubuntu kernel wouldn't load
and I get no space left on device - ( all installations in the internal sdd card)
I am just trying to bring up the ChrUbuntu up.

Now do I have to repeat the whole stuff again?

Che-liang Chiou

unread,
Mar 14, 2013, 2:50:02 PM3/14/13
to newbie_osdev, Chromium OS dev
If you build your own firmware image, such as emerge-${BOARD}
chromeos-bootimage, you should have GBB flags set to
"force-dev-switch-on", which enables developer mode by default. You
may check your firmware image with:

# Read firmware image on the target machine
flashrom -r bios.bin

# Read GBB flags
gbb_utility -g --flags bios.bin
flags: 0x00000039

# List of GBB flags
cros_bundle_firmware --gbb-flags-list
Available GBB flags: Hex
force-dev-boot-legacy 80
dev-screen-short-delay 01
force-dev-switch-on 08
load-option-roms 02
enable-alternate-os 04
force-dev-boot-usb 10
enter-triggers-tonorm 40
disable-fw-rollback-check 20

But I guess you are not running a vboot firmware? Anyway, type
"vboot_twostop" on U-Boot command prompt. It is the main entry point
of vboot firmware.

Che-Liang
> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>
>
>

newbie_osdev

unread,
Mar 18, 2013, 5:04:54 PM3/18/13
to chromiu...@chromium.org
Thank you

I didnt build my own firmware. I was trying to boot my own kernel image with ubuntu rootfs.

Now  I did a factory reset and have both chromeos and ubuntu 12 running fine.

I chainbooted u-boot from usb inorder prevent mishap like last time.

This is where I am - my goal is to boot the u-buntu installed in part6-7 from the non verified u-boot prompt

I compiled boot.scr for KERN C  and ROOT C (mmcblk0p6 and p7) and placed it in /u-boot/ in ubuntu root fs (/dev/mmcblk0p7)

on u-boot prompt

setenv bootargs console=tty1,115200 rootfstype=ext4 root=/dev/mmcblk0p7 rootwait rw lsm.module_locking=0
setenv kernelpart 6
setenv rootpart 7
setenv script_part 7
setenv script_img /u-boot/boot-C.scr.uimg
setenv cros_bootfile /boot/vmlinuz.3.4.0

run mmc0_boot
Unable to use mmc0:7 for fatload
mmc0(part 0 ) is current device
...
...
ERROR: v7_dlcache_inval_range - start address is not aligned - 0xbda3d508
ERROR: v7_dlcache_inval_range - stop address is not aligned - 0xbda3d708

Unable to use mmc 0:7 for fatload
Loading file /boot/vmlinuz.img from mmc device 0:7 (ROOT-C)

STuck there! doesn't proceed

Took the pre-built u-boot from http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/using-nv-u-boot-on-the-samsung-arm-chromebook

I am new to u-boot itself, I did these from bits and pieces of info online.

Please help

Che-liang Chiou

unread,
Mar 19, 2013, 7:44:37 PM3/19/13
to newbie_osdev, Chromium OS dev
Hi,

The nv-u-boot stuff you are looking at is a hack that is a kind of
bizarre mix of x86 and ARM jargons. It could be confusing sometimes.

The ${script_img} is assumed to be placed in EFI System partition,
which is a FAT file system. This should be why your "fatload" above
failed. But this should not be a problem because you manually set
kernelpart and rootpart already.

Then your U-Boot tried to load kernel from mmc device 0:7, which looks
right, but the kernel path looks wrong (/boot/vmlinuz.img instead of
/boot/vmlinuz.3.4.0). This might be the reason why it got stuck (but I
cannot be sure, as some of the logs were omitted).

Anyway, based on your log, it might be stuck at one of the three points:
1. Load kernel command "ext2load ..." (but it is unlikely to be stuck
here though)
2. Boot kernel command "bootm ${loadaddr}", might be here because it
loaded the wrong kernel in step 1.
3. Kernel got stuck? Did you see the "Uncompressing Linux... done,
booting the kernel." message?

Could you check where it got stuck?

Regards,
Che-Liang

Arthy Sundaram

unread,
Mar 19, 2013, 8:03:36 PM3/19/13
to Che-liang Chiou, Chromium OS dev
Hi Thanks for getting back.
Yes I got what you mean, I placed the script img in mmcblk0p12 and the fatload error was gone.

I wanted to boot the ubuntu kernel. The /boot/ in the ubuntu rootfs had vmlinuz-3.4.0
but no vmlinuz.img hence I replaced the cros_bootfile with this.

I am confused by so many names zImage, vmlinuz, vmlinux and vmlinuz.uimg, it all seems to
be the same? because even /boot/vmlinuz seems to be a symbolic link to vmlinuz-3.4.0 in chromepartition.

w.r.t u-booting this is the exact output

mmc_init error 0 time 62474
mmc0(part 0) is current device
mmc_init err 0 time 63007
ERROR:v7_dcache_inval_range - start address not aligned
ERROR:v7_dcache_inval_range - stop address not aligned...
reading /u-boot/boot-C.scr.uimg
ERROR:v7...
...
..
110 bytes read
Executing script at address ${loadaddr}
Loading file "/boot/vmlinuz-3.4.0 from mmc device 0:7 (ROOT-C)

That's it hangs I wish I saw some proceeded that far to uncompress the kernel.. but no..
the ${loadaddr} is 4200000 and is used in many places to load the kernel to -
is the script being overwritten by some sort by the kernel itself?
not sure if am making sense

Che-liang Chiou

unread,
Mar 19, 2013, 8:50:31 PM3/19/13
to Arthy Sundaram, Chromium OS dev
Then it looks like U-Boot did get stuck in 'ext2load ...'. That's strange.

Could you try:
mmc rescan
ext2load mmc 0:7 ${loadaddr} ${cros_bootfile}
And see if this hangs?

Could you check if your vmlinuz-3.4.0 is uImage format? (or FIT image
if your ubuntu uses device tree?)
$ mkimage -l vmlinuz-3.4.0
(mkimage is distributed with U-Boot)

loadaddr is U-Boot's environment variable for the default load address
(different on each boards).

*.uimg is suffix for U-Boot uImage format.
zimage is zimage format.

Arthy Sundaram

unread,
Mar 19, 2013, 9:15:37 PM3/19/13
to Che-liang Chiou, Chromium OS dev
1. It hangs.
                  The partition 7 is in ext4 format is it the reason?
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

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..

Che-liang Chiou

unread,
Mar 19, 2013, 10:04:50 PM3/19/13
to Arthy Sundaram, Chromium OS dev
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.

newbie_osdev

unread,
Mar 20, 2013, 1:45:12 AM3/20/13
to chromiu...@chromium.org
Hi

I couldn't solve this problem this way.
Did a direct mmc read and it worked.
Thank you.


Che-liang Chiou

unread,
Mar 20, 2013, 2:15:17 AM3/20/13
to newbie_osdev, Chromium OS dev
Great!

'direct mmc read' you mean you put vmlinuz-3.4.0 in KERN-C or some
fixed position?
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages