Unix BSP (was: VT100 on QEMU?)

[Chris Johns]

Tom Bojsen wrote:
>
> Yes, we can publish it. You probably want to hear about the limitations first though :-)
>

Please do publish your work. All simulations come with some limitations 
and if merged into the project others will be able to add, extend and 
improve.

> - We are using the i386-rtems4.11 compiler as a cross compiler, because it is able to generate linux executables. There are no modification to this toolchain (I have a minor patch, but I don't think it is required). Since we are using the i386 compiler, rtems insist on using the i386 cpu, so we have added an option to configure (--with-rtems-cpu=<CPU>) so we can force rtems to compile for the unix cpu. There are a few places that this had to be added.

Using the same arch compiler makes sense. Could a Linux (or other OS) on 
a different architecture be usable, eg arm (Raspberry Pi) ?

> - Using the i386-rtems compiler only works on Linux. I'm not sure what it would take to create a cygwin or mingw rtems compiler that can generate native executables.

Unix is good to start with. We should attempt to use POSIX and standards 
to limit the dependence on Linux and look to all Unix systems. Cygwin is 
POSIX while MinGW is a special case and I suggest is is left as a wait 
and see.

> - We used a host timer signal to simulate the system tick as in the original version, but found that some IDEs using gdb had problems debugging it (gdb standlone had no problems), so we ended up generating the system tick in the idle function with a delay. It is not an issue for us, so we didn't look further into it.
> - We don't use the rtems network stack, so it is disabled but I tried yesterday to enable it and there are a some driver files (e.g. if_fxp.c) that don't compile, it should be easily solvable though.
> - Using dlopen/dlsym to load host functions makes the executable call malloc before rtems is ready. I solved it, but I had to copy the implementation of malloc, free, calloc and realloc to the bsp. There are better ways to do this, but it would require small changes to the rtems source code.
> - I hacked on the original cpu and bsp code, and removed part that we don't use or I didn't understand, so something useful may be missing :-)
>
> In general we find the bsp very useful for testing our code and maybe others would think the same.

I like this approach and with the performance times you stated I can see 
the test suite running quickly.

Chris