Search



Designed by:

Google Summer of Code 2010 - porting RTEMS on Milkymist SoC
Ethernet driver works ! PDF Print E-mail
Written by Yann Sionneau   
Friday, 23 July 2010 11:52

Hi again :)

This is great news guys, the Ethernet driver is now able to send and receive Ethernet frames :)

That's basically all we need an Ethernet driver to be able to do !

Multicast isn't implemented, statistics about number of rx and tx framed, errors and collisions are not either yet !

But it does work under qemu and on real hardware on the Milkymist One board :)

I have done a simple sample application that configures the network interface of RTEMS with these settings :

IP address statically set : 192.168.101.100

netmask : 255.255.255.0

Default gateway : 192.168.101.254

So i start the network and just send an UDP packet to 4.2.2.1:1234 with "toto" as payload :)

FYI RTEMS is using the BSD network stack which works really well and has similar functionality than Linux's one. It even has the same "packet structure" idea in order not to copy data over and over when passing a packet from a network stack layer to another (BSD uses struct mbuff and Linux uses struct skbuff)

So the code of the sample looks like that :

char string[] = "toto"; // The string we want to send over the network to 4.2.2.1:1234

struct sockaddr_in farAddr;

int sock, ret;

rtems_bsdnet_initialize_network(); // initializes network stack, network driver and set ip address, default gateway and such

sock = socket(AF_INET, SOCK_DGRAM, 0);

if (sock == -1)

perror("socket:");

else

printf("socket:OK\n");

memset(&farAddr, 0, sizeof farAddr);

farAddr.sin_addr.s_addr = htonl(inet_addr("4.2.2.1"));

farAddr.sin_port = htons(1234);

farAddr.sin_family = AF_INET;

ret = sendto(sock, string, strlen(string), 0, (struct sockaddr *)&farAddr, sizeof farAddr); // we send the UDP packet to 4.2.2.1:1234

if (ret == -1)

perror("sendto:");

else

printf("sendto:OK\n");

 

This code is very portable since it uses socket API over BSD network stack, it can run on Linux or BSD (or even MAC OS i guess ...)

The only thing that you would have to remove is the rtems_bsdnet_initialize_network(); since it's not usually the application's job to set-up the network configuration :)

Here is a wireshark capture screenshot of the networking sample application i just described :

Have fun !

Last Updated on Friday, 23 July 2010 12:13
 
Framebuffer driver works in triple buffered mode PDF Print E-mail
Written by Yann Sionneau   
Friday, 23 July 2010 11:29

Hi folks !

The Framebuffer driver is now able to work in triple buffered mode in order to provide anti-flickering !

That's good news, but i have even better !

The framebuffer has been tested with a more complex program than just showing monochroms : the graphic toolkit for embedded systems Genode-FX has been successfully run on top of the framebuffer driver with RTEMS in single buffered mode :)

Here is a screenshot of Genode-FX running on qemu-lm32 :

Genode-FX graphic toolkit for embedded systems running on RTEMS in qemu-lm32

I add that it works too on the Milkymist One board :)

By default the driver uses single buffered mode, you can switch to triple buffered mode using an ioctl.

Here is a piece of exemple code to show how to use the framebuffer :

int fb;

struct fb_fix_screeninfo fb_fix;

unsigned short int *screen; // a pointer to the framebuffer memory area

fb = open("/dev/fb", O_RDWR); // We open the framebuffer

ioctl(fb, FBIOSETBUFFERMODE, FB_TRIPLE_BUFFERED); // we switch to triple buffered mode (optional)

ioctl(fb, FBIOGET_FSCREENINFO, &fb_fix);

screen = (unsigned short int *)fb_fix.smem_start; // Here we assign the memory address to our pointer

screen[50 * 640 + 50] = 0xffff; // We set the pixel (x;y) = (50;50) to white

ioctl(fb, FBIOSWAPBUFFERS); // We swap the buffers when we have finished to draw the next frame

and we can go on, repeat this pattern, getting the new address of the framebuffer (yes because we swapped, it changed !) and writting again then swapping :)

Have fun !

Last Updated on Friday, 23 July 2010 11:47
 
Framebuffer driver of Milkymist for RTEMS works ! PDF Print E-mail
Written by Yann Sionneau   
Monday, 05 July 2010 01:31

Hi again folks !

A short post on my blog just to say that i have written the framebuffer driver of Milkymist SoC for RTEMS.

I did a small sample framebuffer testsuit to check that the framebuffer driver was really functional and it indeed confirmed that the driver is working :)

This program only writes red pixels in the framebuffer, resulting in showing a totally red screen in lm32-qemu !

The driver is operating in single buffer mode for now, so using it right now may result in flicker since the changes in the buffer are directly made to the frontbuffer which is scanned at 60 Hz by the Milkymist SoC VGA IP core. So a change in the framebuffer can (and will most of the time) happen while the screen is refreshing, for exemple in the middle of the screen refreshing and only half of the screen would be updated, and we would have to wait another refreshing to have the full screen updated with the new framebuffer. This wait time (during 0.016 seconds) is actually seen by the eyes and makes what we call "flicker effect".

This driver will be improved to add support for double and triple buffering to have a totally flicker-free experience with RTEMS on Milkymist :)

That's all for now, stay tuned ;)


PS : RTEMS repository is not anymore hosted on the Milkymist github account, if you are searching for the driver please see the first link of this article.

If you are searching for the testsuite please download my source archive from the GSoC google web page : http://code.google.com/p/google-summer-of-code-2010-rtems/downloads/list

Last Updated on Wednesday, 23 November 2011 22:34
 
RTEMS runs on Milkymist ! PDF Print E-mail
Written by Yann Sionneau   
Saturday, 03 July 2010 15:19

Hi !

It's been a while since I last posted on my blog about my GSoC... and I apologize for it !

I have made some progress in the port of RTEMS to the Milkymist System-on-Chip :)

Thanks to Sebastien Bourdeauducq (alias lekernel) who took the time to work with me on June the 19th I managed to write the Clock, Timer, UART and Console driver for Milkymist SoC !

We went through some problems understanding the autotools crapwares used to configure and build RTEMS and lost some time with the bootstraping of the entire source tree because we didn't knew at the beginning that we could just bootstrap the working directory !

But anyway, now my Development Environment is all set-up and I am more aware of how RTEMS BSP (board support package) development works !

Because reading the documentation is one thing ... actual coding is another !

So finally we managed to get the hello and ticker RTEMS sample programs to run both on the REAL hardware (on the ML401 dev board) and on the lm32-qemu simulator emulating the Milkymist SoC using the parameter '-M milkymist' on command line ! :)

Which is really great news, the port is at last being born !

The hello sample testsuit is a really basic program which just needs the console driver (which uses the uart driver) and has for unique task to print some text over the serial console as a classic "Hello World" would do :)

The ticker sample testsuit (init.c , tasks.c) does a little more, it tests the timer driver by launching 3 tasks (the equivalent of POSIX threads in term of RTEMS API) simultaneously.

These tasks are named "TA1" , "TA2" and "TA3".

Each task enters an infinite loop which prints the time of the day and suspends itself and reschedule itself to run respectively 5, 10 and 15 seconds later.

So finally each task is running independently from the others, and prints a message with current time each 5 seconds for TA1, 10 seconds for TA2 and 15 seconds for TA3.

This tests the timer for two reasons :

 

  • The rtems_task_wake_after() function needs the timer to reschedule the task at desired time.
  • The RTEMS internal scheduler needs the timer to do the scheduling between the different tasks, accounting the different time slices given to each tasks.

Click on "Read more..." to see screenshots of those tests running !

Last Updated on Saturday, 03 July 2010 18:49
 
GSoC 2010 welcome/gift package arrived ! PDF Print E-mail
Written by Yann Sionneau   
Friday, 18 June 2010 20:47

Hi !

I have just received my welcome/gift package from Google for the GSoC (Google Summer of Code) 2010 :)

Here some pictures of the content of the Fedex package :

 

  • A letter with informations about the Google Credit Card
  • A Google plastic ball pen
  • Two Google Summer of Code 2010 stickers, one of wich is shiny :)
  • A nice Google Summer of Code 2010 Notebook (to use in combination with the plastic ball pen i guess ;))
  • A very nice and custom transparent Google Credit Card (VISA)

Click on "Read more..." to see the pictures i have taken of the content of the Fedex package :)

 

Last Updated on Saturday, 03 July 2010 15:08
 
Let's start Google Summer of Code 2010 ! PDF Print E-mail
Written by Yann Sionneau   
Monday, 24 May 2010 15:03

This is the first article of a long series, here i will post news about my Google Summer of Code 2010 during which i will work on porting the RTOS (Real-Time Operating System) RTEMS (Real-Time Executive for Multiprocessor Systems) on the Milkymist SoC (System-on-Chip).

I will commit my work on a new BSP (Board Support Package) for the LatticeMico32 (lm32) architecture on my git repository : http://github.com/fallen/rtems-milkymist

If you have any questions, do not hesitate to send me an email at yann at minet dot net.

I can be reached on #rtems and #milkymist on Freenode, and i may post some intels about the project on my twitter ( https://twitter.com/yannsionneau ) you may follow if you are interested.

That's all for now folks ! I will keep you posted about my work on this interesting project :)

See ya soon !

Last Updated on Monday, 24 May 2010 15:16