Building Genode for Gumstix Overo platform

[Ivan Loskutov]

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:
> > 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20120216/e16d81f4/attachment.html>