Yocto Embedded Linux

[Stephan van Kampen]

For a project we are using a yocto embedded linux bsp and are deciding to use the commercially licensed ugfx library for this.
Has somebody succeeded in integrating the ugfx library within a openembedded recipe using the preferred layered makefile approach?

At this moment I created a customized yocto-gcc.mk file. I manged to build the demo application.
The first time always results in a segmentation fault at the beginning of the application, after that I can start it normally (also other ugfx applications).

Perhaps it would be great to have default support for Yocto, as this is more or less the standard embedded linux environment nowadays.

 

[Joel Bodenmann]

Did you try to debug to figure out where the segmentation fault origins from? It will most likely be due to an issue in the GOS abstraction as everything else is high-level code that builds on top of that.

[Stephan van Kampen]

The segmentation fault happens at: vmt->postinit(pd); (gdriverRegister) in gdriver.c when initializing framebuffer display. The second time it is no problem. I think it has something to do with initial content of some memory buffers.

I just followed the demo with the following content: see attachment

 

 

Makefile

[Stephan van Kampen]

I found the cause:

The call ioctl(fb, FBIOGET_FSCREENINFO, &fb_fix) in board_framebuffer.h sets initially the wrong line-length (fb-fix.line-length). The first time the call returns 640 for the line-length, the second time 1280. This has effect in the memory allocated for the framebuffer. It tries to write to memory which is not allocated, resulting in a segmentation fault.

So the question is: Why does ioctl(fb, FBIOGET_FSCREENINFO, &fb_fix) returns different values?

For now I can work around this to fix the screen size and not let the board init retrieve its settings.

[Joel Bodenmann]

If I understand you correctly the return value of the ioctl() function call is different from your observation. Could you check the value of fb-fix.line-length before passing it to the ioctl() function?

Also, I am bit surprised that you mentioned multiple calls to the framebuffer driver initialization. I don't have all the code in my mind but that seems a bit fishy - are you using two displays?