Yocto U-Boot and uEnv.txt Searching

[Kenny Koller]

I recently began learning Yocto/Poky and built Beaglebone Black artifacts using the pyro branch. I configured things such that uEnv.txt, u-boot.img, MLO, and zImage are on a bootable FAT32 partition. eMMC was erased. It boots fine.

I also did some reading of the AM335x reference manual where I learned that the primary program loader (PPL in ROM) can identify FAT12/16/32 partitions and load MLO from there but a raw mode also exists where no filesystem is needed at all for MLO and U-Boot.

I found this write-up regarding a BBB partition scheme 2.0. It looks to me as if the PPL for OMAP3 on supported the FAT technique and that OMAP4 because supporting the raw mode.

Regarding uEnv.txt: I am seeing these files in several places:

Are these cumulative in the sense that each one found overrides / adds information or does it stop with the first hit?

Is this searching a generic thing in U-Boot or specific to Beaglebone?

If there are differences in searching for this file what is the history of U-Boot for Beaglebone? Does the Yocto version use code that evolved from AM335x support from TI? Or was that adopted from this community when Yocto began using the hardware as a reference?

Is there a document that explains the use of the various uEnv.txt as used by the partition scheme 2.0?

Regarding FAT v. raw mode: Since the PPL for the AM335 supports both why change to the 2.0 strategy? What is the advantage?

Thanks.

[Robert Nelson]

On Fri, Jul 7, 2017 at 9:58 PM, Kenny Koller
<ke...@understoryweather.com> wrote:
>
> I recently began learning Yocto/Poky and built Beaglebone Black artifacts
> using the pyro branch. I configured things such that uEnv.txt, u-boot.img,
> MLO, and zImage are on a bootable FAT32 partition. eMMC was erased. It boots
> fine.
>
> I also did some reading of the AM335x reference manual where I learned that
> the primary program loader (PPL in ROM) can identify FAT12/16/32 partitions
> and load MLO from there but a raw mode also exists where no filesystem is
> needed at all for MLO and U-Boot.
>
> I found this write-up regarding a BBB partition scheme 2.0. It looks to me
> as if the PPL for OMAP3 on supported the FAT technique and that OMAP4
> because supporting the raw mode.
>
> Regarding uEnv.txt: I am seeing these files in several places:
>
> Are these cumulative in the sense that each one found overrides / adds
> information or does it stop with the first hit?

This was done for "awhile" to support old factory programmed eMMC's.
Now days we don't enable the:

/uEnv.txt -> /boot/uEnv.txt

jump anymore.. Specially with U-Boot overlays

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

where we "need" the latest version of u-boot at all times..

> Is this searching a generic thing in U-Boot or specific to Beaglebone?

the generic version is called "distro_default" in u-boot

>
> If there are differences in searching for this file what is the history of
> U-Boot for Beaglebone? Does the Yocto version use code that evolved from
> AM335x support from TI? Or was that adopted from this community when Yocto
> began using the hardware as a reference?

We use mainline, Yocto uses mainline.. We are shipping u-boot
v2017.07-rc3 (released this last week), our patchset has been in
development since v2013. Generic parts are upstream, some parts have
generic interfaces upstream, but we just keep our version for
backwards compatibly.

https://github.com/eewiki/u-boot-patches/blob/master/v2017.07-rc3/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

https://github.com/eewiki/u-boot-patches/blob/master/v2017.07-rc3/0002-U-Boot-BeagleBone-Cape-Manager.patch

>
> Is there a document that explains the use of the various uEnv.txt as used by
> the partition scheme 2.0?

that elinux page you found..

> Regarding FAT v. raw mode: Since the PPL for the AM335 supports both why
> change to the 2.0 strategy? What is the advantage?

It started simple: 'defend' the rootfs/image from new users.

When you have MLO/u-boot.img in a fat partition the end user has easy
access too.. they tend do "delete" things they do not understand.
Then they call the seller asking "why" it no longer boots. Moving
from Fat to raw mode, has made the image much more reliable to end
user probing..

Regards,

--
Robert Nelson
https://rcn-ee.com/