Jump to content
Stephan van Kampen

Yocto Embedded Linux

Recommended Posts

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.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×