VT100 on QEMU?

[Tom Bojsen]

Hi, Joel, Gedare

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

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

/Tom

-----Original Message-----
From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] 
Sent: 19. februar 2013 16:33
To: Tom Bojsen
Cc: rtems-users at rtems.org
Subject: Re: VT100 on QEMU?

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