[meta-ti] BeagleBone Black fails to boot with u-boot 2014.07, linux-yocto 3.14.5

Wed Aug 13 05:51:05 PDT 2014

On Tuesday 12 of August 2014 11:40:54 Denys Dmytriyenko wrote:
> The bug report you are mentioning is not related to this issue, most
> probably. The manifestation is exactly the same - it just doesn't boot. But
> that can be caused by million other things... And yes, the fix was already
> pending upstream when I applied it to 2013.07 version in OE-Core. So
> 2014.07 already has it.
> 
> Now, as of the issue at hand - late last year, early this year, all
> platforms in U-boot have switched from uImage to zImage, as a default
> format. So, 2013.07 used uImage and 2014.07 expects zImage.
> 
> Looks like you are mixing layers badly. So, you are getting machine config
> from Poky/meta-yocto, instead of meta-ti, because you are building kernel in
> uImage format and not zImage. But then you are building newer U-boot from
> meta-ti. But not the kernel from meta-ti...
> 
> Ways to fix it (from easy to hard):
> 
> 1. Decide whether you want beaglebone from meta-yocto or from meta-ti and
> use the correct layer alone w/o mixing them.
> 
> 2. If you are mixing layers, use all the components from the same layer -
> machine config, bootloader, kernel. If there are 2 layers defining the same
> machine (e.g. the case of beaglebone.conf provided by meta-yocto and
> meta-ti), the one that is mentioned first in the bblayers.conf wins.
> Machine config usually defines things like preferred bootloader, kernel
> versions, load addresses and image formats.
> 
> 3. If for some of the reasons one of the components gets picked up from a
> wrong layer (u-boot from meta-ti instead of oe-core/meta-yocto), make sure
> to add additional PREFERRED_PROVIDER and/or PREFERRED_VERSION accordingly.
> 
> 4. If you are adventurous and know what you are doing, you can mix and match
> layers as well as components, making sure all the parameters like image
> formats, addresses, etc. do match. My guess it should be possible to do so
> by setting KERNEL_IMAGETYPE to zImage, if you want to use latest U-boot
> from meta-ti, while keeping kernel from meta-yocto. Maybe some other
> tweaks...
> 
> Good luck and let me know if you have more questions.

Thanks for suggestions. I've removed meta-ti from bblayers and done a clean 
build of core-image-minimal + kernel-devicetree in IMAGE_INSTALL_append. 
Unfortunately with the same effect.

What is the order in which load addresses are used? It seems that the address 
embedded in uboot header takes precedence before default uboot environment 
setting. Running `bitbake -e linux-yocto` produces this:

# $UBOOT_ENTRYPOINT [3 operations]
#   set /home/mborzecki/yocto/heads/poky/meta-yocto-
bsp/conf/machine/beaglebone.conf:34
#     "0x80008000"
#   set /home/mborzecki/yocto/heads/poky/meta/conf/documentation.conf:432
#     [doc] "Specifies the entry point for the U-Boot image."
#   set? /home/mborzecki/yocto/heads/poky/meta/classes/kernel.bbclass:66
#     "20008000"
# computed:
#   "0x80008000"
UBOOT_ENTRYPOINT="0x80008000"
...
# $UBOOT_LOADADDRESS [3 operations]
#   set /home/mborzecki/yocto/heads/poky/meta-yocto-
bsp/conf/machine/beaglebone.conf:35
#     "0x80008000"
#   set /home/mborzecki/yocto/heads/poky/meta/conf/documentation.conf:433
#     [doc] "Specifies the load address for the U-Boot image."
#   set? /home/mborzecki/yocto/heads/poky/meta/classes/kernel.bbclass:67
#     "${UBOOT_ENTRYPOINT}"
# computed:
#   "0x80008000"
UBOOT_LOADADDRESS="0x80008000"

Then UBOOT_ENTRYPOINT is passed as LOADADDR in KERNEL_EXTRA_ARGS where it ends 
up in uboot header.

Setting this in local.conf produces a bootable image:
UBOOT_LOADADDRESS_beaglebone = "0x82000000"
UBOOT_ENTRYPOINT_beaglebone = "0x82000000"

/proc/iomem has this:
  80008000-809e33ef : Kernel code
  80a60000-80b9fc07 : Kernel data

> 
> > Hi all,
> > 
> > I'm having trouble booting BBB with current meta-ti
> > (f7b1140774e6c8c8aecde41388d40d9d407df6ff). The problem looks similar to
> > this bug report:
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6165
> > 
> > Console output is as follows:
> > Booting from mmc ...
> > ## Booting kernel from Legacy Image at 80007fc0 ...
> > 
> >    Image Name:   Linux-3.14.5-yocto-standard
> >    Image Type:   ARM Linux Kernel Image (uncompressed)
> >    Data Size:    5098048 Bytes = 4.9 MiB
> >    Load Address: 80008000
> >    Entry Point:  80008000
> >    Verifying Checksum ... OK
> > 
> > ## Flattened Device Tree blob at 80f80000
> > 
> >    Booting using the fdt blob at 0x80f80000
> >    XIP Kernel Image ... OK
> > 
> > OK
> > 
> >    Using Device Tree in place at 80f80000, end 80f8a207
> > 
> > Starting kernel ...
> > 
> > 
> > The original issue with kernel overlapping fdt was fixed with this patch
> > to
> > OE-core:
> > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2cae5f78ad2982c7
> > ca0c22c085b71a1d2184a1b0 However, current meta-ti contains u-boot in
> > version 2014.07, overriding 2013.07 from poky master. I'm assuming that
> > the patch eventually made it into denx tree.
> > 
> > Another problem is that uImage contains the following info:
> > Image Name:   Linux-3.14.5-yocto-standard
> > Created:      Mon Aug 11 16:59:42 2014
> > Image Type:   ARM Linux Kernel Image (uncompressed)
> > Data Size:    5098048 Bytes = 4978.56 kB = 4.86 MB
> > Load Address: 80008000
> > Entry Point:  80008000
> > 
> > I'm not sure what is the order in which the addresses are applied. Is it
> > kernel -> default env -> uEnv.txt?
> > 
> > Adding uEnv.txt with these contents fixes the problem:
> > loadaddr=0x82000000
> > kernel_addr_r=0x82000000
> > fdtaddr=0x88000000
> > fdt_addr_r=0x88000000
> > rdaddr=0x88080000
> > ramdisk_addr_r=0x88080000
> > bootm_size=0x10000000
> > 
> > Please advise how to fix it without falling back to uEnv.

-- 

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. 