Developing with RTEMS on the host

[Russell Haley]

On Fri, Jun 2, 2017 at 3:12 PM, Denis Obrezkov <denisobrezkov at gmail.com> wrote:
> 2017-06-03 0:55 GMT+03:00 Steven Grunza <steven.grunza at gmail.com>:
>>
>> Why avoid frequent ROM writing?  Most of the systems on which I have
>> worked that would be suitable for RTEMS saved the code in Flash memory -
>> most of them used on-board Flash.  Can you describe the hardware a little?
>> CPU, memory, etc?
>>
>> To run from NFS it seems like there would need to be some code on-board to
>> get a bootloader started so that networking was available to access the NFS
>> shared file and download it to RAM, then jump to it.

In FreeBSD I have used u-boot to achieve this for an ARM board (imx53
and imx6). I used TFTP to load the kernel and execute it at a specific
memory address, and then NFS to mount the root file system. If memory
serves I created a partition table with 1MB at the front and then a
fat32 partition. I dd u-boot to the SD Card (leaving a couple of
sectors at the front for the partition table) and then wrote the
env.txt file to the MSDOS partition. Possibly you could use TFTP to
grab the executables and run them. If u-boot can't load RTEMS, perhaps
you could write a small second/third stage boot loader? In FreeBSD
they have something called ubldr that works as a shim between uboot
and the kernel that understands UFS and ZFS.

However, Barebox would be a FAR better choice for this. Looking at the
documentation it supports NFS out of the gate. I have used it in
simple configurations and it is superior to u-boot because it uses
shell like scripts and has a single point for all board support
packages (as compared to u-boot that has been forked all over the
place). It also supports multiple architectures and is super duper
easy to build if you're running GNU/Linux (has some Linux dependencies
in the build system).

http://www.barebox.org/

For what it's worth...

Russ