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@...1...> Date: Thu, 16 Feb 2012 12:09:11 To: genode-main@lists.sourceforge.net Reply-To: Genode OS Framework Mailing List <genode-main@...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:
- 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