Building Genode for Gumstix Overo platform

[Stefan Kalkowski]

Hi Michael,

On 16.02.2012 14:07, Michael Grunditz wrote:
> Hi
> 
> I am also porting Genode to a new ARM board. Right now I am stuck with libc. It just halts with abort() as soon as it initiates. I cannot use GDB at this stage. Is there any other way of debuging this ? Adding prints to libc doesnt work since this problem is when libc init starts.

that sounds like you're getting an exception at that point.

If you're using the Fiasco.OC kernel together with Genode you can of
course use it's included kernel-debugger, which is quiet feature-rich.
You can invoke it by hand via the serial line by pressing escape, or you
put a 'enter_kdebug("WAIT")' snippet at appropriate places of your code
resp. libc initialization. Therefore you've to include the following before:

  namespace Fiasco {
  #include <l4/sys/kdebug.h>
  }

I fear the kernel-debugger's usage isn't that self-explanatory, but you
can start playing around after looking at the help-screen via '?'.
Something often useful is dumping the stacktrace of a thread via 'bt'.
To get meaningful symbols instead of plain addresses there is a small
tool in 'base-foc/contrib/kernel/fiasco/tool/backtrace'.

Hope that helps
Regards
Stefan

> 
> Michael
> Sent with Blackberry
> 
> -----Original Message-----
> From: Norman Feske <norman.feske at ...1...>
> Date: Thu, 16 Feb 2012 12:09:11 
> To: <genode-main at lists.sourceforge.net>
> Reply-To: Genode OS Framework Mailing List <genode-main at ...98....net>
> Subject: Re: Building Genode for Gumstix Overo platform
> 
> Hi Ivan,
> 
>> I tried to build Genode for Gumstix Overo platform. I added new build
>> target foc_overo and implemented framebuffer and touchscreen drivers. I
>> added my changes to my fork on Github https://github.com/iloskutov/genode
> 
> I have already noticed your fork yesterday. That is an impressive and
> quite unexpected line of work! :-)
> 
>> 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.
> 
>> 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?
> 
>> 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?
> 
>> 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?
> 
> Again, congrats for your amazing work!
> 
> Cheers
> Norman
> 

-- 
Stefan Kalkowski
Genode Labs

http://www.genode-labs.com/ · http://genode.org/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth