BBB u-boot

Sun Sep 24 08:21:25 UTC 2017

Am 24.09.2017 um 06:40 schrieb Chris Johns:
> On 24/9/17 12:33 am, Christian Mauderer wrote:
>>
>>
>> Am 23.09.2017 um 16:17 schrieb Christian Mauderer:
>>> Am 22.09.2017 um 08:28 schrieb Chris Johns:
>>>> On 22/09/2017 16:13, Sichen Zhao wrote:
>>>>> Can you please tell me which version of u-boot you used?
>>>>> My version is old: U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 
>>>>> 13:23:54)
>>>>
>>>> I built git://git.denx.de/u-boot.git master and I think commit
>>>> 8a1c44271c55961fb70fb6177f9c02fdb05287c5. Looking at the trace in a little more
>>>> detail I see `U-Boot 2013.04-dirty (Jul 10 2013 - 14:02:53)` which seems wrong.
>>>> I am now confused.
>>>>
>>>> My uEnv.txt is being read from the mmc ...
>>>>
>>>> ] gpio: pin 53 (gpio 53) value is 1
>>>> ] mmc0 is current device
>>>> ] micro SD card found
>>>> ] mmc0 is current device
>>>> ] gpio: pin 54 (gpio 54) value is 1
>>>> ] SD/MMC found on device 0
>>>> ] reading uEnv.txt
>>>> ] 182 bytes read in 3 ms (58.6 KiB/s)
>>>> ] Loaded environment from uEnv.txt
>>>>
>>>> That is how I am controlling the boot. Could I be booting from the on-chip flash?
>>>>
>>>> Chris
>>>
>>> Hello Chris,
>>>
>>> first of all: I don't think that the problem depends on the U-Boot
>>> version. It sounds more like a problem due to the missing FDT. Maybe
>>> there is a check missing whether the register that should contain the
>>> FDT address is set correctly?
> 
> I think we need a couple of checks. The first is a valid pointer that sits
> within the target's define RAM. Then we need to check the FDT is valid. I have
> code to test the FDT has a valid magic number I have not pushed as I need to
> first test it works and I have not got that point.

Yesterday I thought that checks might could be a good idea. But I have
thought a little about that point: There is no guarantee that the FDT is
load into the RAM. It could also be in some Flash or theoretically in
any memory mapped storage media. The start up code is common for most
(all?) ARM BSPs. I don't think that there is some common memory map for
all of them. So there is more or less no possibility to check for a
valid pointer.

Instead, it might would be a better idea to fix the configure option
"BSP_START_COPY_FDT_FROM_U_BOOT" so that it is actually possible to
disable it during the configure call. With that option, it would be
possible to build a BSP with or without FDT support. If it is build with
FDT support but U-Boot doesn't provide a FDT, an undefined behaviour
looks OK for me. It's no intended use case.

A check for a valid fdt_magic in the bsp_fdt_copy would be good. With
that it would be possible to start a BSP with FDT without a FDT by
passing a valid pointer to some invalid magic.

The check for the U-Boot API signature like in the FreeBSD code could be
some other nice feature.

> 
> The FreeBSD has this check for uboot ...
> 
> https://github.com/freebsd/freebsd/blob/master/sys/boot/uboot/common/main.c#L386
> 
> ... to make sure there is a valid call signature. It does seem to be a good idea
> to have some sanity check. I cannot see what u-boot image type FreeBSD uses and
> so how it is called.
> 
>>>
>>> Regarding the point which U-Boot is booted: The boot process on the
>>> Beagle Bone is a little odd. I'm still not 100% sure about it. Basically
>>> it seems roughly about the following:
>>>
>>> If you don't press the S2-Switch during power-up a first U-Boot ("U-Boot
>>> SPL") is read from the boot sector of the on-board eMMC.
> 
> Yes this is how it works. If the TI device is like the Zynq the boot mode pins
> will only be sampled on power up.
> 
>> It loads a
>>> second U-Boot from the active partition of the eMMC. The second U-Boot
>>> checks a number of sources to boot from. I think that depends a little
>>> on the version of the U-Boot environment on the eMMC. My BBB (with a
>>> U-Boot 2014.04-00014-g47880f5) tries to read the uEnv.txt from the
>>> SD-Card and parses it if the file is available. If not it boots some
>>> default from the internal eMMC.
> 
> This is what my older version is doing. I incorrectly assumed it was loading
> from the SD card which was silly on my part.
> 
>>> If you press the S2-Switch during power-up (a reset isn't enough; it has
>>> to be a power cycle), 
> 
> This seems common to ARM devices.
> 
>>> the controller tries to boot from the SD-Card. If
>>> you have a "U-Boot SPL" in the boot sector there, it will use this U-Boot.
> 
> I seem to remember being told about a USB flash update tool. This is it:
> 
> https://github.com/ungureanuvladvictor/BBBlfs
> 
> Interesting to see the ROM code supports an RNDIS interface.

The first part of this article provides some information on the boot order:

https://www.twam.info/hardware/beaglebone-black/u-boot-on-beaglebone-black

With S2 pressed and no microSD, you should reach the USB loader.

> 
>>>
>>> I think I've read somewhere that it is possible to mark the internal
>>> partition as "not active" so that the U-Boot SPL of the eMMC directly
>>> starts the U-Boot from an active partition on the SD-Card instead. But I
>>> never tried or tested that.
>>>
>>> Regards
>>>
>>> Christian
>>>
>>
>> And some thoughts to the problem: If I remember correctly, Sichen had a
>> patch that added the necessary files to the script that creates a
>> SD-Card image. But there had been some license issues (the flattened
>> device tree sources are GPL) and therefore it didn't get merged. But the
>> patch that adds FDT-Support has been merged. Therefore there is an
>> inconsistency.
> 
> I think making an SD image should be kept outside of the kernel tree. It places
> to many demands on user's hosts to just build a kernel and getting it all to
> work on all hosts is lots of work. The wiki is the place to add this type of
> detail for users.
> 

The script seems to be there about as long as the BSP itself. It depends
on some tools that are not build in the master branch of the RSB (like
mcopy, newfs_msdos, ...) and on an existing U-Boot Image which is also
not build on RSB master. So it really doesn't work on all hosts. It is
more or less an extended README. Regardless whether it is moved to the
wiki or not, it should be updated.

>>
>> Maybe it would be a good idea to set the
>> "BSP_START_COPY_FDT_FROM_U_BOOT" option in the BSPs configure.ac to 0
>> till someone finds a solution for the image generation? I would expect
>> that this would allow a rtems type image or a linux type image without
>> fdt to run again.
> 
> I think the configuration is valid, I think we need to improve how we have it.
> We should not crash.
> 
> Chris
> 