BBB u-boot

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

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.

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

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