BBB u-boot

Mon Sep 25 07:39:20 UTC 2017

Am 25.09.2017 um 01:26 schrieb 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.

Sounds OK. It allows a check if it is possible to create one and does
nothing if not.

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

Currently only three or four. Potentially all boards that run U-Boot
which is much more. Most likely about every board that is delivered with
a Linux.

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

A better config system would be great. It's only the same problem like
always: No one has the time and budget to do it properly. And mixing a
number of new solutions isn't really a good idea too. We would need a
documented preferred solution for options. But that is another topic and
should be discussed as such. No one would find the discussion in this
thread. ;-)

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

Shouldn't the check for the correct address already trigger a warning in
the BSP? We also have one BSP that uses FDT directly and BBB could do so
too in the future. That would remove some hard coded addresses.

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

Not really Linux centric. Most of the tools that are used there are
FreeBSD tools or some other ones but installed into the RTEMS prefix.
All of them are build on a branch of RSB that is created by Ben.
Alternatively you can build them manually.

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

Ben's script might is a good starting point for finding that geometry.

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

Great.

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

Regards

Christian

-- 
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.