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 < > > > > > > > > [email protected]> 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. -- _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
