Building Genode for Gumstix Overo platform

Norman Feske norman.feske at ...1...
Mon Mar 12 14:45:46 CET 2012

Hi Vasily,

> This is absolutely correct. I made some experiments and solved part of
> problem with l4_cache_clean_data().
> I putted it to refresh(int x, int y, int w, int h)  ((
> os/src/server/nitpicker/genode/ +441 ))
> and anytime, when i called nitpicker->frame buffer()->refresh() i got
> very good image. (But in my tests i used hardcoded pointer to data
> with pixels, because pixels[] inside np_test and local_addr was a
> different )
> But, while i dragged image i got again noise on image. if i stopped (i
> guess refresh happend after stop) and i have again clear image. So,
> Norman, can You please put cache_clean_data to the right place inside
> nitpicker for flushing cache pixels on every pixels writing?

great! I think, however, that nitpicker's refresh function is the wrong
place where to put the cache-flushing code. This function gets called
each time a nitpicker client tells nitpicker about changes in the
client-specific pixel buffer. But you want to do the cache-flushing even
in the event that the client just moves any of its views w/o changing
any buffer content.

I think the cache flushing would be more appropriate to do in the
framebuffer driver's refresh function. (i.e.,
os/src/drivers/framebuffer/omap3fb/ line 345) This function is
called each time nitpicker changes pixels on screen. I suspect that
putting the cache-flushing code to this place is even more
straight-forward because the knowledge about the addresses to flush is
right there. Could you give it a try?

Once you get it working, it would be nice if you push your branch to
some public location (GitHub) so that I can have a look. The remaining
challenge on my side is to find a way to add the cache-flushing facility
in such a way that the driver retains its independence from the kernel
interface. Certainly, a new API is needed for that.


More information about the users mailing list