> First question about core. Core for Fiasco.OC used LD_TEXT_ADDR = 0x140000
> in base-foc/src/core/target.inc. In Overo memory locations starting at
> 0x80000000. I think, I need to set LD_TEXT_ADDR = 0x80140000. I added it to
> base-foc/src/core/arm/target.inc but it applied for all ARM targets. How
> can I set it for my Overo target only?

I have to look into this problem more closely. Intuitively, I think it
would be good to have a way for specifying core's virtual address in a
'spec-overo.mk' file.

Ok. I fixed it.

> In our project we use Chestnut43 board for prototype. This board has 4.3”
> LCD 480x272 pixels. I get display configuration for this LCD from Linux
> driver. Display work, picture is drawing, colors are correct. But sometimes
> window drawn with distortion (normal drawing
> http://dl.dropbox.com/u/8558928/pic_1.jpg , distorted:
> http://dl.dropbox.com/u/8558928/pic_2.jpg
> http://dl.dropbox.com/u/8558928/pic_3.jpg ). I can’t solve this yet. Maybe
> I have wrong configuration for display controller.

To me this looks like a typical cache artifact. The syscall bindings of
Fiasco.OC provide several functions for dealing with caches on ARM
platforms (i.e., see 'cache.h'). Those functions are unused by Genode
until now because we haven't experienced such artifacts with the PBXA9
platform or Qemu. Maybe you could investigate if these cache-related
functions are relevant to your problem and if so, how they could be put
to use in a clean way within Genode?

I'll try to investigate this.

> Touchscreen based on ADS7846 chip. I wrote simple driver. How can I do
> calibration implementation? I see several solutions:
> 1. Create new input event for touchscreen. Then driver can to send raw data
> to Nitpicker. Nitpicker translate this data to screen coordinates use
> calibration constants which must be loaded from some application.
> 2. Calibration data must be loaded to the touchscreen driver. But how make
> it correct?
> Maybe you can to offer best solution?

The best would be to keep the concerns separated. So the touch-screen
driver should produce raw data. Otherwise, we would lose information.
Nitpicker, on the other hand, expects input events that are already
calibrated with screen coordinates. Adding calibration support into
nitpicker would make it more complex, which I'd like to avoid.

How about introducing a dedicated input-event-calibration component?
This component would sit in-between the touch screen driver and
nitpicker (this can easily be done using Genode's session-routing
concept). This new component would get it calibration parameters from
its config file, opens an input session (which gets routed to the
touch-screen driver), and, in turn, announcing an input service itself
(providing the calibrated input events). Thinking a bit further, this
component could be implemented entirely generic. Its configuration would
be the parameters of an affine transformation in the form of a matrix.
So this component could then be used for arbitrary transformation of
(absolute) input events. Do you like this idea?

It's good idea. I'll try to impement this component.

> For test platform I wrote simple Qt application. I don’t understand how to
> work resolution dependency. Where need I write all dependencies for
> automatic build my target. I used qt4/run/qt4.run as base for my run
> target. Execution “make run/qt_test” failed with error “cannot stat `bin/
> dejavusans.lib.so'”. Not all libraries was built. If I execute “make

> run/qt4” previously then my qt_test built without error.*

Apparently, your test application is much simpler that the Qt4
application used in qt4.run. It does not need 'dejavusans.lib.so'.
Therefore, the build system did not build this library (dependencies at
work! .-) But in your run script, you still specify the file name
'dejavusans.lib.so' in the list of boot modules that should be put into
the final image. Could you try to just remove this entry?

Yes, all work. Sorry, I hurried to ask this question. I had to understand myself :)