On 17/4/19 2:38 am, Jonathan Brandmeyer wrote: > I'm interested in using RTEMS as both a featureful bootloader and as > my application environment. Is there a straightforward way to use > RTEMS as a bootloader itself? > > In principle, the following seems like it should work: > - Provide a bootloader BSP that links RTEMS into an address range that > is non-overlapping with the application's load range > - Provide a standard ELF loader from ... somewhere? Maybe I can > borrow some of the RTEMS loader logic to do this? Maybe the Xilinx > FSBL can be adapted to the purpose?
I recommend the FSBL in flash not be touched unless the hardware is in a manufacturing environment where it can be recovered by JTAG if the board is bricked. I also recommend not placing any bitfiles in the FSBL. A lot of the FSBL from Xilinx is governed by a requirement to boot a PL based ePCI interface. To do this the FSBL needs to be loaded and run, a bitfile loaded from flash and a PCI device made ready to enumerate within 100msecs. A bitfile in the FSBL means an update in the bitfile requires updating the FSBL and that could brick the board. I have the app and bitfile joined and not the bitfile and FSBL. The FSBL code from Xilinx has golden images and other features but I do not use them and it does not know how to load from an YAFFS file system. > - Jump to the ELF's entry point. ELF is more complicated to load, a binary image is much easier. Why not just load a binary image created using `objdump`? > One of the things I'm uncertain about is whether or not the Zynq BSP's > startup logic is idempotent. Is there some startup logic that is not > safe to run twice? I do not do this so I do not know what the answer is. > This is something of an X/Y problem. The real problem I'm trying to > solve is to provide a safe-mode ROM software image alongside the > field-programmable software image, where the ROM is capable of > receiving updates to the field-programmable image. When my team > sketched out the concept, it seemed like the most reliable way to do > this was for the FSBL to unconditionally load the safe-mode image, and > that the safe-mode image would chain-load into the appropriate > application image. But if RTEMS support for chain-loading in this way > isn't adequate, then the FSBL will have to conditionally load either > the safe-mode or application image. I understand the problem space and what you are attempting to do. In applications for clients on a Zynq I use a custom FSBL to manage this. I take the lower section of the QSPI flash and call it the factory image, say 2M or 4M. I then partition this section starting from 0 with the FSBL area followed by a table. The table defines the remaining content of the factory image. I then load into the factory flash area an unsecured compressed bitfile image, the binary image of the executable, and a compressed tar file containing a default file system image. The table has an entry to each file and a checksum. The remainder of the flash is a JFFS2 file system. I use jffs-boot [1] to locate files in the FSBL. Note: - When a factory executable boots there may be no valid FFS so you need to create it and populate it. This is the reason the bitfile etc are in the table. - Bitfiles are loaded by RTEMS from the file system or factory table. > Chain-loading is attractive due to some implementation details of the > flash layout on our project. I'd rather not go through the process of > porting and embedding YAFFS into the FSBL if I can avoid it. U-boot contains YAFFS [2]. Maybe you can see how it does it or you could chain from the FSBL to a 2nd stage loader, ie u-boot, and then RTEMS from the YAFFS. Chris [1] https://ftp.rtems.org/pub/rtems/people/chrisj/jffs2-boot/ [2] https://github.com/u-boot/u-boot/tree/master/fs/yaffs2 _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
