boards/qemu-arm: Add support for lm3s6965evb board for testing in qemu-system-arm

[jnohlgard]

lm3s6965evb and lm3s811evb are both Cortex-M3 based and supported as emulated machines in QEMU. Adding support for these boards will let us run unittests etc on virtual Cortex-M3 hardware inside Travis/Strider to catch any ARM Cortex specific issues. e.g. tests on the scheduler code, syscalls, memory allocation, anything not tied to a particular vendor..

[phiros]

Porting this would definitely be beneficial. However, I've a lot to do right now
with the CI system. Might take a few weeks until I can port this (I hope I can do it earlier)

BTW: this would also offer us the chance to test network related stuff on a emulated platform
which is much closer to a "real" board than native.

[latsku]

I will just leave this link here. http://gnuarmeclipse.github.io/qemu/
I haven't tested that at all, but the projects seems to fit more than perfectly on this one.

[kousu]

I have a very niche question.

qemu-doc.texi says that lm3s6965evb offers these peripherals:

• Timers, UARTs, ADC, I@math{^2}C and SSI interfaces.
• OSRAM Pictiva 128x64 OLED with SSD0323 controller connected via SSI.

I found this datasheet which sounds like it should be the same device ("LM3S6965 Evaluation Board" == toupper("lm3s6965") + "evb") and contains a lot of similar features, though it lists the OLED as 128x96 instead of 128x64; and there's also this datasheet which covers the microcontroller at the core of the board itself.

The docs mentions that there is ethernet and USB hardware available. Ethernet and USB would be super useful to have access to for testing cross-compiled ARM code, but I can't figure out how, and I'm suspecting it's not even possible at this point.

Are these devices just missing from qemu's emulation?

[jnohlgard]

@kousu The FT2232 USB to UART is used as a debugger interface on the real development board, to make it easier to connect with a PC, it should not be necessary to emulate this in qemu. The ethernet module is part of the MCU though, so if it is missing in qemu I assume it is only because nobody has implemented it yet.
You should be able to configure qemu to let you use the UART directly on the virtual board as a terminal. At least this is what is done on other qemu targets, e.g. qemu-system-ppc64. I have not looked into this particular target.

[kousu]

@gebart thank you! That is very helpful! I realize this is out of your purview a bit, thanks for taking the time to help me out :)

[jnohlgard]

@kousu no problem! Tell us if you have any progress in emulating RIOT on cortex m

[nghiaducnt]

@gebart I have just learned RIOT OS with QEMU's lm3s6964evb recently. Basically, the RIOT OS works well with QEMU. However, to work with advanced features(like timer or networking) QEMU's Stellaris needs some fixes. Here is my work https://nghiaducvn.wordpress.com/. When GPTimer and Ethernet device is ready, it is really awesome to see and experiencing networking applications over TAP devices.

[jcarrano]

@nghiaducnt I just read your blog post. Pretty awesome! Having qemu support with networking would improve our testing process a lot.

I would suggest that you do not wait to have the GPTimer and Ethernet working to make a PR. Instead, PR the basic board support as soon as you think it is good enough, and keep on working on the more advance functionality while we review it. This way you will have something to show and hopefully spark interest amongst the RIOT community.

[nghiaducnt]

@jcarrano my original intention was just to have basic features. However, it grew more and more interesting when it came as a whole system, just could not stop to solve the problem. With QEMU, it is easy for me to penetrate the system. Just like GPTimer's device driver or injecting unusual network traffic to verify network stack(then security), sometimes I saw the system unresponsive but I couldn't dive deep to find the reason(QEMU was not in debug mode at that time). My next experiment, I would add/fix the simulation of clock/random number generator/security IP block in QEMU. I would like to see RIOT can support well network application with security features. I will keep you guys posted.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.