BeagleBone Black fails to boot with u-boot 2014.07, linux-yocto 3.14.5

BeagleBone Black fails to boot with u-boot 2014.07, linux-yocto 3.14.5

[Maciej Borzecki]

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=2cae5f78ad2982c7ca0c22c085b71a1d2184a1b0 
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.

Re: BeagleBone Black fails to boot with u-boot 2014.07, linux-yocto 3.14.5

[Denys Dmytriyenko]

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.

-- 
Denys


On Tue, Aug 12, 2014 at 03:42:51PM +0200, Maciej Borzecki wrote:
> 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=2cae5f78ad2982c7ca0c22c085b71a1d2184a1b0 
> 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. 
> -- 
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: BeagleBone Black fails to boot with u-boot 2014.07, linux-yocto 3.14.5

[Maciej Borzecki]

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.