Developing with RTEMS on the host

[Russell Haley]

Sorry for the top post. My understanding is that the license is only applicable to the bootloader code. As there is no linking to the ‎rtems code, it is a non issue unless you modify the bootloader itself. 

Fwiw
Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Chris Johns
Sent: Saturday, June 3, 2017 7:44 PM
To: Russell Haley; Denis Obrezkov
Cc: rtems-users at rtems.org
Subject: Re: Developing with RTEMS on the host

On 3/6/17 9:37 am, Russell Haley wrote:
> 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?

I use uboot and TFTP with the Microzed. I have found the u-boot support for the
networking PHY on the Microzed a little suspect where it can fail to initialise
and needs a power cycle. I suppose I could fix it if I really cared.

I also use JTAG downloading directly into the RAM. As a bonus I also get a debugger.

> In FreeBSD
> they have something called ubldr that works as a shim between uboot
> and the kernel that understands UFS and ZFS.

Nice.

I see a need for custom server of some type to help control the downloading for
testing. One of the complications when testing is being able to download one of
500+ test executables. I have wondered about some python code running as a
server that is controlled by the testing framework that tracks the executable
being tested.

> 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...
> 

Interesting. It is a shame the license is GPL and so raising the compliance
overheads for RTEMS users.

Chris