BBB u-boot

[Chris Johns]

On 24/09/2017 18:21, Christian Mauderer wrote:
> 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.

The check could be a weak function a BSP supplies and validate the address and
the default call return OK to any address. This lets those BSPs that want too
add a check and so become more user friendly.

Which BSPs support u-boot and FDT? I am wondering if those BSPs that run from
flash support u-boot and the FDT.

> 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.

We do not need a common format, we can ask the BSP to answer the question. For
the Zynq and BBB the answer is a simple RAM address check.

> 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.

I disagree. The Beaglebone is used as a IoT device and I feel we need to make an
effort to handle things like this cleanly with an indication there is an error.
I think we can do better than leaving it as undefined behaviour. I found the
crash low level and complex stretching across two open source projects. A new
user would be lost.

On the topic of configure options, they are a wart on RTEMS. We currently have
582 separate RTEMS_BSPOPTS_SET calls. Can anyone point me to a definitive
document of these setting? How many work, how many are broken, how many are
tested? The `--help` support does not work and never has unless you specifically
invoke a BSP's configure command, again too complicated as I suspect few people
know this. Can I as a core developer make changes to any of them, rename or
remove them? I do not know and so I have no idea how to maintain them. I just
ignore them or work around them. I see the options as a low overhead niche
solution to solve specific user problems however a liability to the project to
maintain as there use has grown. I am close to a flat rejection of patches
containing any new configure options. We all need to find a better solution. For
example I suspect a number of these options could be handled by weak calls or
even FDT settings. I see either as maintainable and better.

Back on topic. :)

If the Beaglebone needs an FDT to support libbsd we need to have the
functionality enabled by default and if no FDT is provided libbsd should provide
a suitable error.

> 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.

Yes if the pointer is valid, ie the need for the check.

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

Yes, any BSP using u-boot would benefit from being able to do this but I am not
sure how this is done on all platforms. If we could ask u-boot for a version the
BSP could decide if a specific release or later is needed. The BBB could do with
this check.

> 
>>
>> 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.
> 

ugen0.3: <Texas Instruments AM335x USB> at usbus0
urndis0 on uhub1
urndis0: <Texas Instruments AM335x USB, class 2/0, rev 2.00/0.00, addr 2> on usbus0
ue0: <USB Ethernet> on urndis0

Works. This is a nice feature.

>>
>>>>
>>>> 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.

Yes, Ben added them when he first did the port. The scripts seems Linux centric.
I suspect the code in question is in his repo.

I am attempting to figure out the SD card's gpart geom. My built u-boot MLO does
not boot with S2 pressed.

> 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.

I agree and then we removed them from the source tree. I am slowly collecting
the pieces of information needed.

I am on the road for a week so this effort will slow down.

Chris