VT100 on QEMU?

Gedare Bloom gedare at rtems.org
Tue Feb 19 15:12:46 UTC 2013


If you would like to submit the work I would be inclined to push for
getting it into the rtems.git repo. I think that the "unix" bsp is a
useful way for a tight development loop, as you demonstrated with your
timing samples. This is basically a "system call emulation" mode for
RTEMS.

On Tue, Feb 19, 2013 at 7:00 AM, Tom Bojsen <Tom.Bojsen at man.eu> wrote:
> Just to clarify the unix bsp part.
>
> We have ported the Unix BSP from 4.9.6 into 4.11. We did, however, change it so that it works as a normal bsp/cpu, which means that it is compiling with a rtems enabled gcc (i386-rtems4.11-gcc), and uses the rtems supplied newlib. This means that there are no changes to the rtems code and that it will use everything that rtems provides (including pthread, filesystem, etc). For the very few places where we needed access to the host, e.g. the timer signal for system tick, we do a dlopen/dlsym to get the functions from the host. Network (TAP device) and flash (memory mapped file) is also implemented with host calls.
>
> The reason for doing it, is that our application developers needed a very simple setup that can run their code, and they did not like a QEMU setup. Since the result is a normal linux executable, it can be debugged with a standard GDB/IDE. As a extra bonus we can increase the system tick, so running our unittest is very fast. For the same set of tests we get: Unix bsp = 12s, Qemu (i386) = 14 min, Nios2 = 43 min.
>
> Br Tom
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users




More information about the users mailing list