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. Which BSPs support u-boot and FDT? I am wondering if those BSPs that run from flash support u-boot and the FDT. > 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. 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. > 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. I am attempting to figure out the SD card's gpart geom. My built u-boot MLO does not boot with S2 pressed. > 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. I am on the road for a week so this effort will slow down. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
