On 20/4/19 1:12 am, Jonathan Brandmeyer wrote:
> Thanks for sharing your experience.
>
> On Tue, Apr 16, 2019 at 9:54 PM Chris Johns 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.
A u-boot image made with mkimage will have a checksum so validation is there at
that level. I use some form of scripts to control the app boot selection.
I have also used a checksum file for all release package files and validate each
file listed before allowing the "app" mode to start. If a file does not validate
the app enters a fall back mode that allows upgrading. A release is a collection
files in a release directory and at start up a symlink is made from '/active' to
the mounted release path.
> The most attractive part of chain-loading from a ROM RTEMS to a
> field-programmable RTEMS is the uniformity of the development
> environment.
Hmmm but is "simpler is better" more important at the low level and boot time?
> 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.
Yes this could be made to work if your kernel is golden and stable. You will
still need to sort out a way to upgrade the kernel.
> 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.
Yes, it is a factor that needs to be considered.
The other issue is libdl needs gdb support to provide seemless debugging. This
is present in the RTEMS libdl code but the patch for gdb needs to dusted off,
moved to the latest gdb and retested. I cannot say when this will happen but it
is something we need.
> 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.
I think RTEMS 5 is production ready. We have some final things to complete which
are in the corners of the project and do not attract funding so they tend to sit
and get worked on unfunded. Unfunded time for core developers is mostly
available spare personal time and that is variable.
What is the time frame for your 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.
I recommend 5 but I understand your wish to work with releases.
> 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.
I would like to see RTEMS 5 released within 6 months. We have 5 new tickets and
51 assigned [1]. A number can be moved to a future release. Ticket #3532 [2] is
the one I need a bunch of days to sort out so the release source is complete for
all hosts. Without this the release is broken.
Chris
[1] https://devel.rtems.org/milestone/5.1
[2] https://devel.rtems.org/ticket/3532
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
