Hi Norman,
Thanks for the fast response.
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:
- 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 :)