[meta-ti] BeagleBone Black , u-boot, and zImage

[Maciej Borzecki]

On Friday 22 of August 2014 23:24:20 Denys Dmytriyenko wrote:
> On Mon, Aug 18, 2014 at 04:45:16PM +0200, Maciej Borzecki wrote:
> > On Monday 18 of August 2014 10:16:14 Denys Dmytriyenko wrote:
> > > On Mon, Aug 18, 2014 at 09:34:58AM -0300, Diego Sueiro wrote:
> > > > On Mon, Aug 18, 2014 at 9:28 AM, Maciej Borzecki <
> > > > 
> > > > maciej.borzecki at open-rnd.pl> wrote:
> > > > > Rough guess, but it looks like a default u-boot from eMMC. Try
> > > > > following
> > > > > official instruction to make it boot off SD card:
> > > > > https://www.yoctoproject.org/downloads/bsps/daisy16/beaglebone
> > > > 
> > > > This should do the trick:
> > > > "Pressing the USER/BOOT button when powering on will temporarily
> > > > change
> > > > the
> > > > boot order".
> > > 
> > > The USER button may sometimes be tricky, as it preserves the state
> > > across
> > > reboots. So, if you already booted off of eMMC, holding the button and
> > > rebooting won't work - you'd have to unplug the power to completely turn
> > > it
> > > down and then power it up, while pressing the USER button. Making eMMC
> > > non-bootable is more reliable in many cases...
> > 
> > Silly question, is there any requirement that partition block count must
> > be
> > even for boot partition?
> > 
> > For instance, I'm not able to boot using this partition layout, keep
> > getting CCC on serial console:
> > 
> > Device         Boot     Start       End Blocks  Id System
> > /dev/mmcblk0p1 *         2048     22526  10239+  c W95 FAT32 (LBA)
> > /dev/mmcblk0p2          22528    116735  47104  83 Linux
> > 
> > This one, almost works (u-boot runs, init fails mounting rootfs):
> > evice         Boot     Start       End Blocks  Id System
> > /dev/mmcblk0p1 *         2048     22527  10240   c W95 FAT32 (LBA)
> > /dev/mmcblk0p2          22528    116735  47104  83 Linux
> 
> Have you tried the latest update to u-boot-ti-staging? There were couple
> fixes related to FAT and SD handling.

I tried these, but the problem was elsewhere. After some digging I found that 
there are some intricacies to the boot process.

First of all, the CCCC sequence appears the boot ROM is attempting to load a 
bootloader from UART. This would imply that attempts to locate a bootloader 
failed. In case of BBB this would mean that MLO (?) was not located neither on 
eMMC no SD (I'm guessing the checks are done in sequence eMMC -> SD -> UART).

There's some clue about this behavior here:
http://e2e.ti.com/support/embedded/starterware/f/790/t/210768.aspx

Then, there was an error in wic partition generating code that ended up 
stealing a single sector from the first partition to compensate for bytes lost 
to MBR. The code always subtracted from partition size, by never made up for 
this. Eventually, the partition that was initially even in size sector-wise, 
ended up with an odd size. This apparently is a problem for OMAPs, see the 
links below (not BBB exactly but still an OMAP CPU):

http://comments.gmane.org/gmane.comp.embedded.pandaboard/2790
https://groups.google.com/forum/#!topic/beagleboard/ro5k5r4Cuq4

There's very little info on the subject. Either what happened here is a very 
special case, or everyone knows about these intricacies, in which case, shame 
on me :) Yet, the partitions were perfectly valid for fdisk/parted not to 
complain, and kernel to mount them.

Since wic only generates partition in at least 1MB size, removing the code 
stealing single sectors was enough for the image to become correct.

The fix is already in master-next: 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=e67d59c6fab33a3ae38ff2375189dc5235995492

I guess that eventually some sanity checking code would be useful, just to 
verify that some basic alignment constrains for particular platform is met.

-- 

Maciej Borzęcki 
Senior Software Engineer Open-RnD Sp. z o.o. 
www.open-rnd.pl, Facebook, Twitter 
mobile: +48 telefon, fax: +48 42 657 9079 

Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem lub 
poufne informacje i została wysłana wyłącznie do wiadomości i użytku osób, do 
których została zaadresowana. Jeśli wiadomość została otrzymana przypadkowo 
zabrania się jej kopiowania lub rozsyłania do osób trzecich. W takim przypadku 
uprasza się o natychmiastowe zniszczenie wiadomości oraz poinformowanie 
nadawcy o zaistniałej sytuacji za pomocą wiadomości zwrotnej. Dziękujemy. 

This message, including any attachments hereto, may contain privileged or 
confidential information and is sent solely for the attention and use of the 
intended addressee(s). If you are not an intended addressee, you may neither 
use this message nor copy or deliver it to anyone. In such case, you should 
immediately destroy this message and kindly notify the sender by reply email. 
Thank you.