Hi Alexander,
Sorry, I have not studied the whole source code yet, but I have the impression that after mapping memory via attaching mmio dataspace via rm reading registers by the pointer and via Register c++ template class gives different results. I had the trouble - my I2C driver from uboot didn't work when I just mapped the memory, but Ivan Loskutov has reworked it to use the Register class and it worked from now on.
maybe the trouble was related to the bug report we discussed yesterday? See:
http://sourceforge.net/mailarchive/forum.php?thread_name=506D7D02.2040904%40...
(you will have to click on "Attachments: Message as HTML" of the first message)
Could you tell if I'm digging in the correct direction? I think both IO memory and buffers must be mapped uncached, unbuffered via arm mmu, but, again, I've not yet read all the code of genode and fiasco.
You are definitely on the right track!
If you're interested, here is what I suggest (and want to do later), but I'm planning to write a more detailed blog entry later and keep you updated.
- replacing most panda stuff with omap4 name
(i.e., move headers from include/board/panda to include/cpu/omap4)
That's a good idea. Maybe we could even think about introducing another indirection 'soc'. ARMv7 is a 'cpu', OMAP4 is a 'soc', Pandaboard is a 'board'.
- Implementing abstractions for various device classes (like, gpio,
voltage regulator, led in linux, but in C++)
I agree. The corresponding session interfaces implemented by Ivan are a good start. So far, we haven't included them in our upstream tree because there was no pull request or topic in our issue tracker to discuss it. If you are interested, I would appreciate you opening a new topic for each device class. So we can take the discussion over there.
- splitting dde kit's common stuff (lx_emul, platform) and usb driver.
Ideally, it should be easy to add new drivers to the makefile and build each linux driver as a standalone binary
That is completely in line with our intentions. We planned to split those parts into reusable pieces as soon as we reach a certain diversity of drivers within dde_linux. Maybe, we are just reaching this point now? ;-)
Cheers Norman