VT100 on QEMU?

[Joel Sherrill]

Well then .. just to clarify.. can you submit it? :)

We killed it because it wasn't using newlib, you wen't able
to use file systems or the RTEMS TCP/IP stack and it just
didn't leave much usefulness for debugging.

--joel

On 2/19/2013 6:00 AM, Tom Bojsen 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


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985