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
