Thanks for sharing your experience. On Tue, Apr 16, 2019 at 9:54 PM Chris Johns <chr...@rtems.org> wrote:
> 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. Totally agree. The FSBL is definitely considered part of our ROM. > > - 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`? Yes, that makes good sense. I should've thought of that already, so thanks for the reminder :) > - 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. Yeah, that's a possibility. Whether we can get the image validation and selection logic done in the scripting system or in their application layer, Its yet another programming environment to support. The most attractive part of chain-loading from a ROM RTEMS to a field-programmable RTEMS is the uniformity of the development environment. Another option is to use RTEMS dlopen(), and restrict the scope of our field updates. A minimal ROM image would have enough logic in the kernel to load the filesystem and enumerate the available application packages, both the safe-mode backup image and reprogrammable images, and dlopen() the appropriate one based on our update policy. This is probably the highest-risk / lowest-development-cost path we could take, where the risk is increased by locking us into a particular kernel image. Its made worse by the fact that we're using RTEMS v5 as our base on the assumption that a stable release will come out before our product launch. If that release doesn't happen, then the initial units will be shipping off of some unreleased SHA instead of a fully stabilized release, or we can backport our application to 4.11.3. That isn't particularly attractive either, since v5 has some fixes that v4.11 doesn't have, but maybe we can backport those as well. My actionable question for you is: How likely is a stable v5 series release in the next 6 months, where "likely" is measured by things like "we are making it a priority" and/or "we have funding to do so"? Not trying to make any demands of your team; I'm just trying to make an informed decision. Thanks, -- Jonathan Brandmeyer _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
