Samsung CB ("snow"): Chained u-boot worked, now doesn't

[Fat Tire]

So three nights ago I had chained u-boot working on snow (the Samsung chromebook).  24 hours later, after a repo sync and build_packages, it spontaneously stopped working.

I'm looking for anyone with insight.

How I got it to work (three days ago):

1. Followed the first few steps of the developer guide.  Skipping the smaller steps, basically I started w/Ubuntu in a VM.  I installed dependencies, set up git and the repo.  Downloaded source (minilayout), and created/entered the chroot.  Then I did setup_board for "daisy".
   
   
2. Once in the chroot, I did NOT do a full ./build_packages.  I already had an older, booting build of chromeos on an SD card I'd built a few days earlier and I was only interested in replacing partition 2 with the uImage for the chained-u-boot as described here.
   
   
3. So I did this: cros_workon --board=daisy start chromeos-u-boot.  Then, in the u-boot source (~/trunk/src/third_party/u-boot/files), I edited cros/dts/chromeos-exynos.dtsi and include/configs/exynos5250.h b/include/configs/exynos5250.h to change the text base address from 0x43E00000 to  0x42400000 similar to as suggested here.  The branch for this, I believe, is chromeos-v2013.06.
   
   
4. chromeos-bootimage would require a /build/daisy/firmware/u-boot.bl1.bin, which I added like this:

   cd /tmp/

   wget http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/exynos-pre-boot-0.0.2-r9.tbz2

   tar xjvf exynos-pre-boot-0.0.2-r9.tbz2

   cp [forgot the path]/E5250.nbl1.bin to /build/daisy/firmware/u-boot.bl1.bin
   
5. There was also a bug I found in

   /usr/lib64/python2.7/site-packages/bundle_firmware.py -- I needed to add this around line 818 to set self.ecro_fname:

   self.CheckOptions() # add this as the first line of def _BuildBlob()
6. I then did the emerge chromeos-ec chromeos-u-boot chromeos-bootloader.  This filled /build/daisy/firmware with all kinds of goodness, including nv_image-snow.bin which was 4194304 bytes.
   
   
7. I followed the samsung nv_u-boot instructions here for the next few steps, first to extract the U_BOOT file:  dump_fmap -x /build/daisy/firmware/nv_image-snow.bin U_BOOT -- a significantly smaller size.
   
   
8. I determined the starting address for the new uImage like this:
   
   TEXT_START=$(awk '$NF == "__image_copy_start" { printf "0x"$1 }' /build/${BOARD}/firmware/System.map)
   
   This resulted in  0x42400000, which I had previously set above.  (note I had to change from the example, which was searching for "__text_start"-- which didn't appear in my System.map.)
   
   
9. Finally I created the uImage and signed it with the steps suggested:
   
   sudo mkimage \
    -A arm \
    -O linux \
    -T kernel \
    -C none \
    -a "${TEXT_START}" -e "${TEXT_START}" \
    -n "Non-verified u-boot" \
    -d U_BOOT /build/daisy/firmware/nv_uboot-snow.uimage
   
   MY_BINARY=/build/daisy/firmware/nv_uboot-snow.uimage
   
   # Sign the uimage
   echo blah > dummy.txt
   sudo vbutil_kernel \
    --pack /build/daisy/firmware/nv_uboot-snow.kpart \
     --keyblock /usr/share/vboot/devkeys/kernel.keyblock \
     --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
     --version 1 \
     --vmlinuz ${MY_BINARY} \
     --bootloader dummy.txt \
     --config dummy.txt \
     --arch arm
   
   
10. This resulted in a packed file at /build/daisy/firmware/nv_uboot-snow.kpart, which I then copied to partition 2 of the SD card in my VM:
    
    dd if=/build/daisy/firmware/nv_uboot-snow.kpart of=/dev/sdb2
    
    
11. I then turned on the chromebook, popped the SD card in, and hit power.  Entering ^U resulted in a bunch of console text flying by (chained U-Boot running, I'm pretty sure) followed by black (no kernel set up yet, which is fine...)  I played with the config a little to make it NOT automatically try to boot, and I got a prompt, was able to type directly into u-boot's menu ("help, etc.)

All was good at this point!

Then the bad things happened.

1. I repo synced.  (this was Friday, June 14, 2013)
   
   
2. Then decided to rebuild the whole Chromeos SD card image, since I had previously wiped it to do the instructions above.  So I did build_packages --board=daisy, then a few hours later when it finished I did a build_image per the developer guide to make something suitable for an SD card.  As I had done previously, I used image_to_usb to copy the newly built chromeos to the SD card (I'm using a USB SD adapter, if you haven't figured it out) effectively overwriting p2 (the chained u-boot I had previously somehow gotten working).
   
   
3. So I needed to put my u-boot back into p2.  I repeated the above steps to emerge u-boot, ec, and bootimage, create the .kpart, and re-dd it over partition2.
   
   
4. Upon boot, black screen.  The backlight goes off, and stays off.   Nothing happens.
   

That's where I am.  I can NOT for the life of me figure out what happened between Thursday and Friday to suddenly make this process stop working.  I tried backing out all recent changes to u-boot source that may have resulted from the repo sync...to no avail.  Tried other branches.  Tried adjusting the TEXT_START address.  Tried a million things.

Anyone know what the issue might be?

[Doug Anderson]

Fat,

On Sun, Jun 16, 2013 at 6:40 PM, Fat Tire <f4t...@gmail.com> wrote:
> So three nights ago I had chained u-boot working on snow (the Samsung
> chromebook). 24 hours later, after a repo sync and build_packages, it
> spontaneously stopped working.

It's entirely possible that you're doing nothing wrong. I think I
head Vadim and Simon say that ToT U-Boot is currently broken on
exynos5250-snow (the Samsung ARM Chromebook). Perhaps try checking
out the old "cros/chromeos-v2011.12" and see if that works?

+Simon and Vadim to see if they have additional insight.

-Doug

[Vadim Bendebury]

See if this patch makes it work again:

https://gerrit.chromium.org/gerrit/#/c/58790/

--vb

[Fat Tire]

This seems to have done something :)

The (u-boot) console came up, scrolled a bunch of stuff, and I ended up in Google Chrome (color icon, not blue)-- at which point I see "The system was last booted in Developer Mode.  Returning to Normal (Verified) Mode... Upon Completion, the system will reboot."  The progress wheel was spinning, then stopped after about a minute.  I';m guessing this is because u-boot is by default loading the signed chrome kernel on the built-in emmc (?)

I waited 15 minutes, then restarted manually w/o the sd card. The system started "repairing" itself..  a 15 minute process.  I'll let it do that now.

This is back to where I was 3 days ago (minus the returning to Normal mode), so I'd say major progress!  I'll take a look at which kernel it tried to boot and from where and see if I can get it to do a straight boot off the SD-- chromium instead of chrome.  (Since it's part of an unverified boot now).

For anyone else who may be trying to do a chained u-boot, see the instructions at the top of the post.  They appear to work with Vadim's patch.  Thanks Vadim!  (You may also want to have a look at the bug I fixed in Step 5 (usr/lib64/python2.7/site-packages/bundle_firmware.py). Also, if you'd like me to update the official instructions in Appendix A, let me know.

Thanks again!

[Fat Tire]

Well, now that I have u-boot going, I'm trying to figure out why it has trouble starting from an SD card, whether it's in the slot (mmc 1) or via USB adapter (usb).  It gets the same error from u-boot (described below) either way.

As you can see here in this graphic (sorry for the quality, it's a screen capture from a video), it seems to be trying to run via netboot, then 5 seconds later (a timeout I selected) it tries USB.  No device there so it moves to mmc 1, which is where it should boot.

Zooming in a bit, I think it runs:

mmc1_boot -- which sets devnum to 1 then runs

mmc_boot -- which runs

mmc_setup -- which sets up mmc stuff for mmc 1 (and rescan/reinits it)

At this point we should have these variables set:

    devnum = 1

    devtype = mmc

    devname = mmcblk1p

then run_disk_boot_script runs, and this is where I think error #1 is:

        "run_disk_boot_script=" \

                "if fatload ${devtype} ${devnum}:${script_part} " \

                                "${loadaddr} ${script_img}; then " \

                        "source ${loadaddr}; " \

                "fi\0" \

Ignoring ${loadaddr}, it would look like this if it were running.... if fatload mmc 1:c ${loadaddr} /u-boot/boot.scr.uimg then source ${loadaddr};

I think fatload is likely where it's failing the first time, resulting in the "** No Partition Table **" message.

It has some references to get_device_and_partition()   <-- this happens to be the function in disk/part.c that gives the partition error.

So anyhoo, after run_disk_boot_script fails, next it tries the

ext2_boot - which sets some variables, then does an ext2load (to read from partition 3 or 12 I forget) and I bet this is where it fails the second time, getting the 2nd ** No partition Table ** error...

From there it tries mmc 0 (the internal mmc) and the boot continues to load (colorful logo) chrome, but somehow chrom thinks there was damage and does a full system "restore".  Every time I test this.

Anyone know what's going on?  Could this have something to do with a missing/wrong signature somewhere or something when not running in verified boot?  IS the partition schema in a different place when it's running verified?  And will I need signed kernels?

Thanks again in advance...

[Michael Pratt]

I don't believe that booting from SD has been tested on this branch, so it may very well not work.

For testing purposes, it is probably most useful to run commands manually.

At the simplest, you only need to load /boot/vmlinux.uimg from one of the root partitions into memory and boot that to get the kernel executing.  You will need some bootargs to get it to boot completely.

For example, I can boot (from the internal MMC and U-Boot), with the following:

run regen_all    # Generate standard bootargs

setenv bootargs ${bootargs} root=/dev/mmcblk0p3 ro    # Append root device to bootargs

ext2load mmc 0:3 ${loadaddr} /boot/vmlinux.uimg    # Load /boot/vmlinux.uimg from mmc device 0, partition 3 to ${loadaddr}

bootm ${loadaddr}    # Boot image at ${loadaddr} 

You can use the 'mmc' commands to query the card and see what works.  'mmc list' will show the available devices, and 'mmc dev' will select one.  From there use 'mmc part', 'ext2ls', and 'fatls' to see if you can see anything on the card. 

If you cannot get the SD card working, it may be worth trying a USB thumb drive.

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

[Fat Tire]

Wow, michael-- that was SUPER helpful.   I had already been playing with the command line a little, and I just tried those set of commands you suggested--  only replacing mmcblk0p3 with mmcblk1p3...

and... it booted!  I got to the chromium (blue) icon, then it came up to the choose-a-language screen.. then crashed almost instantly... but it worked.  Trying it again now seems to not work so well, but maybe it's a userspace issue (?) or something.. not sure why boot #2 wouldn't work.

But yeah, once I got the command line interactive (by shutting off the auto-attempt to boot to mmc 0), I was able to mess around a bit more and at least once got it to work once.  And now that it's not trying to boot to mmc 0 it's also not making me "fix" my internal install...

This is cool stuff.  I'll play a bit more. Thanks again!

(BTW-- how many kernels are there?  one at p2, another at p4 (?), then the one in rootfs on p3?  Since the kernel I replaced w/uboot was on p2, I'm glad there was that extra one on p3...)

[Fat Tire]

Sorry to reply to myself, but I may have spoken too soon...

I forgot to note you also need to change "ext2load mmc 0:3" to "ext2load mmc 1:3" in Michael's example above to load from SD card instead of the internal mmc.  Doing so results in the same "no partition" message that I was getting before.  Apparently though it does work if you load the kernel that's on the internal mmc tho, at least the first time you try it :)

Michael, if you have any insight as to why it's not finding a partition scheme, I'd be curious about that... Popping the SD card into a laptop DOES mount p3 and I can discover the other partitions with gparted or whatever, so there is a normal partition list there.  I dunno what's special about mmc1 that's different from mmc0 in this regard, unless it's some kind of signature or something that's needed (?).  I also saw there are secondary partition tables, but I'm not clear on what they are, what they do, or if that's even relevant.

I feel like if this partition scheme issue is identified, I bet booting off SD will work without issue.  (Incidentally I tried putting the card in a USB adapter and it had a Bad USB error in the new uboot)

Continuing thanks...!