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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
