• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 311 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Suggestions on combining the TI SDK and the Graphics SDK

Mike Worster
Expert 1575 points

I'm using ti-sdk-am335x-evm-07.00.00.00 and the associated Graphics_SDK_5_01_01_01 to do my work. The steps are to build the TI SDK 07 first, then extract, setup, and build the Graphics SDK. I'm assuming it was done this way to save time/space for those not interested in the Graphical content in their builds... however, I'd really like to just do a single build and be done with all the content.

Are there any difficulties or issues I'll run into if I go to combine the two builds? Has anyone done this before? Any advice for me?

  • 0
    TI__Guru*** 125430 points
    Maybe you should create a top level make target, e.g. "make linux_and_graphics" which does one then the other. Or is that what you're suggesting?
  • 0 in reply to Brad Griffis
    Expert 1575 points

    I've considered that, or doing a script that kicks off one Make then the other.. but I'd rather update the <ti-sdk-root>/board_support/linux_.../Makefile to just build the pvrsrvkm.ko, omaplfb.ko, and bufferclass_ti.ko directly, so that all the kernel objects are built together at the same time.

    IMO it makes sense to build them with the other .ko's and internal to the board_support/linux directory, encapsulating all the kernel work together.

  • 0 in reply to Mike Worster
    TI__Guru*** 125430 points

    The SDK integrates many components: u-boot, kernel, graphics, Qt, plus many other utilities that are bundled into the file system.  The graphics hardware (i.e. the SGX530) and the software originate from Imagination Technologies.  We receive a deliverable from Imagination specific to their GPU.  That software is then tweaked a bit for TI processors and is re-released as the Graphics SDK.  The Graphics SDK then becomes one of many items integrated into our Linux SDK.  In my opinion, it makes the most sense to keep it separate since it is its own independent deliverable.  In other words, you could potentially grab a different version of the Graphics SDK and use it with your software (though I don't recommend that in general).

    So even though the Graphics SDK is closely related to the kernel (i.e. one of its outputs is a kernel driver!), it is not in fact "part" of the kernel.  So in my opinion this should not be built as part of the kernel.

    I'm not exactly sure what problem you're trying to solve.  Personally I don't see any benefit to what you're trying to do.  On the contrary, it seems like that could make it harder to use a different Graphics SDK if you tie that into the kernel build.

    By the way, I don't recommend calling multiple makefiles from a script.  If one of the makefiles encounters an error you don't see it because the next makefile gets called immediately which hides the error.  Either that, or you have to check the return of every call and exit the script in case a makefile returns an error.  I find it easier and more natural to just write a top level makefile that calls down into the other makefiles.  That way it will automatically stop if a makefile hits an error.

  • 0 in reply to Brad Griffis
    Expert 1575 points

    Brad Griffis said:

    I'm not exactly sure what problem you're trying to solve.  Personally I don't see any benefit to what you're trying to do.  On the contrary, it seems like that could make it harder to use a different Graphics SDK if you tie that into the kernel build.

    Basically, we converted the BSP provided by you, TI, to our board. Once that was done we handed it off to another team (internal) to convert from the Makefile system so a, company mandated, OpenEmbedded build system. The BSP didn't seem to have any issues, but when we asked them to do the same for the Graphics SDK then a bunch of problems have come up.
     
    Instead of spinning my wheels and waiting for whatever the issues are to be fixed, if I could find a way to built the Graphics SDK content into the kernel build system, then I could hand that single package off and it could be built just like they are today; thus moving me forward.
     
    Seems like, even though the content is different, that the builds should be able to be run in succession (the kernel objects moved to the kernel build, the OpenGL content built afterwards).

    Brad Griffis said:

    By the way, I don't recommend calling multiple makefiles from a script.  If one of the makefiles encounters an error you don't see it because the next makefile gets called immediately which hides the error.  Either that, or you have to check the return of every call and exit the script in case a makefile returns an error. 

     
    Yeah, I normally make my scripts do just they, kick off the first build, check the results, then move on to the next. It's a fair point however that it would be easier to just have a Makefile structure.
  • 0 in reply to Mike Worster
    TI__Guru*** 125430 points

    Thanks for the explanation.  Personally, I would probably try to figure out what's wrong in the OpenEmbedded build flow.