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?
>
> 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. 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.
>
> If you press the S2-Switch during power-up (a reset isn't enough; it has
> to be a power cycle), 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 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.
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.
Regards
Christian
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
