OE application Devolopment

I was wondering how the beagleboard/OE community was handling
development of applications under OE for the beagle.

I really like how OE takes a lot of the headaches out of build an
embedded linux system. However from my limited understanding of OE I
can see how it would be easy to patch or add new releases of software
but it seems limited in its abilities as a SDK. Or prehaps more
precisely it feel like it gets in the way when used as a SDK.

I find it hard to think of doing app dev work by patches or having to do
realeases. BTW I am not saing this won't work once the software
stablizes.

It is very possible that I just don't understand OE enough and there is
fairly simple solution.

From asking on IRC (#beagle) I have found out that the SDK build task

doesn't work.

What are some ways that ppl have done application development under OE
with beagle?

Ben Anderson.

I was wondering how the beagleboard/OE community was handling
development of applications under OE for the beagle.

I really like how OE takes a lot of the headaches out of build an
embedded linux system. However from my limited understanding of OE I
can see how it would be easy to patch or add new releases of software
but it seems limited in its abilities as a SDK. Or prehaps more
precisely it feel like it gets in the way when used as a SDK.

Yes, application development isn't an area where OE shines.

I find it hard to think of doing app dev work by patches or having to do
realeases. BTW I am not saing this won't work once the software
stablizes.

It is very possible that I just don't understand OE enough and there is
fairly simple solution.

There is a solution: http://labs.o-hand.com/anjuta-poky-sdk-plugin/

It should be compatible with the toolchains (e.g. meta-toolchain) OE
generates.

>From asking on IRC (#beagle) I have found out that the SDK build task

The issue with gcc 4.3.x has been fixed recently, you can now build
both a native compiler as well as an sdk you can hands to other
people.

doesn't work.

What are some ways that ppl have done application development under OE
with beagle?

I don't do application development at all, so take the above with a
grain of salt.

hope this helps,

Koen

Hi,

Ben Anderson schrieb:

I really like how OE takes a lot of the headaches out of build an
embedded linux system. However from my limited understanding of OE I
can see how it would be easy to patch or add new releases of software
but it seems limited in its abilities as a SDK. Or prehaps more
precisely it feel like it gets in the way when used as a SDK.

right, OE is not intended to be used as a SDK but it is a tool to build your SDK.

From asking on IRC (#beagle) I have found out that the SDK build task

doesn't work.

What are some ways that ppl have done application development under OE
with beagle?

In fact the correct solution would be to build a toolchain (and additional
libraries) using OE and use this for crosscompiling applications for development.
I'll try to build a SDK for bagelboard now. If the sdk compiler is not yet fixed
upstream I might have a fix for that here. We'll know in a few hours once the
build has finished.

Greetings

Florian

Hello all,

What are some ways that ppl have done application development under OE
with beagle?

This is not Beagle dependent.

Develop your application as you would do normally.

Just use the toolchain from the SDK or directly from the cross/ directory.

Use proper makefiles, using $(CC) etc, or use the GNU autoconf if you
feel comfortable with it.

Several ways to do your development/test cycle, different people use
different techniques:

Use a lightweight bitbake file with a modified do_fetch() that simple
copies the sources from your development dir, then builds a package of
it.
Manually copy excutables to the rootfs, NFS helps.

Many of my deploy shell scripts are like this (for applications):

bitbake <mystuff> -c clean
bitbake mystuff
ssh <target> ipkg-cl install <package>

Regards,

I just finished building the SDK and it apears to have worked. I am not
sure what I am suppose to do now.

I see a task-sdk-bare_1.0-r8_armv7a.ipk file but am unsure as to what to
do with it?

Is there any guides online about using the oe sdk-task?

I am fairly comfortable with cross-compiling once I see the tool-chain
but not sure how to get it from the ipk or if that is all of it or ?

I am assuming one will get the build-tools and a set of libs to link
against.

Ben Anderson

I just finished building the SDK and it apears to have worked. I am not
sure what I am suppose to do now.

I see a task-sdk-bare_1.0-r8_armv7a.ipk file but am unsure as to what to
do with it?

Is there any guides online about using the oe sdk-task?

I am fairly comfortable with cross-compiling once I see the tool-chain
but not sure how to get it from the ipk or if that is all of it or ?

I am assuming one will get the build-tools and a set of libs to link
against.

'bitbake meta-toolchain' and look in tmp/deploy/sdk for a tarball.
Extract that to / and look in /usr/local/angstrom/arm.

regards,

Koen

> I just finished building the SDK and it apears to have worked. I am not
> sure what I am suppose to do now.
>
> I see a task-sdk-bare_1.0-r8_armv7a.ipk file but am unsure as to what to
> do with it?
>
> Is there any guides online about using the oe sdk-task?
>
> I am fairly comfortable with cross-compiling once I see the tool-chain
> but not sure how to get it from the ipk or if that is all of it or ?
>
> I am assuming one will get the build-tools and a set of libs to link
> against.

'bitbake meta-toolchain' and look in tmp/deploy/sdk for a tarball.
Extract that to / and look in /usr/local/angstrom/arm.

bitbake mata-toolchain fails on:

gcc-cross-sdk-4.3.1-r5: task do_compile: failed

I think this was the same issue I had before with building the SDK. It
was mentioned several times that this been fixed.

Is there a way I could test the version with the fix?

> > I just finished building the SDK and it apears to have worked. I am not
> > sure what I am suppose to do now.

> > I see a task-sdk-bare_1.0-r8_armv7a.ipk file but am unsure as to what to
> > do with it?

> > Is there any guides online about using the oe sdk-task?

> > I am fairly comfortable with cross-compiling once I see the tool-chain
> > but not sure how to get it from the ipk or if that is all of it or ?

> > I am assuming one will get the build-tools and a set of libs to link
> > against.

> 'bitbake meta-toolchain' and look in tmp/deploy/sdk for a tarball.
> Extract that to / and look in /usr/local/angstrom/arm.

bitbake mata-toolchain fails on:

gcc-cross-sdk-4.3.1-r5: task do_compile: failed

I think this was the same issue I had before with building the SDK. It
was mentioned several times that this been fixed.

Is there a way I could test the version with the fix?

Try updating your OE tree

regards,

Koen

Jason ,

you said that you were able to get an xds510usb jtag working with the beagle board. How did you verify this? Did you connect to both the c64x and the cortex within code composer studio?

Im having some issues connecting to the c64x within ccs with an xds510 w/lv adapter+adaptive clocking, its putting out an error message saying “target cpu clock does not exist”, however i can succesfully connect to the ICEPICK, havent tried the cortex yet… Is there is anything special required on getting the c64x clock up and running?

pete.

Pete,

Please start a new thread when embarking on a new topic. Subject
changes make googlegroups had to navigate.

NOTE: I have not tried C64x connectivity, but I don’t see why it would not

work…

I have got connected to the DSP with the BH 560m (on a different OMAP3 board). By default the DSP is held in reset and you need to enable the DSP functional clock before you can connect to it. In the GEL files that come with CCS for the OMAP3430, there is the following GEL function in the file C:\CCStudio_v3.3\cc\gel\omap3430_cortexA.gel that enables the DSP.

hotmenu IVA22_GEM_startup()

{

/* Enable DSP-ss functional clock (set bit 0) CM_FCLKEN_IVA2*/

((int)0x48004000) |= 0x1;

/* IVA clk is bypassed CORE clock/2 CM_CLKSEL1_PLL_IVA2*/

((int)0x48004040) = (2<<19);

/* Enable IVA2 DPLL (low power mode bybass → 5) CM_CLKEN_PLL_IVA2*/

((int)0x48004004) = (1<<4) | (5<<0);

/* Release DSPMMU reset (clear bit 1) → RM_RSTCTRL_IVA2 */

((int)0x48306050) &= ~(1 << 1);

/* Set DSP boot mode to WaitInDeadLoop → CONTROL_IVA2_BOOTMODE */

((int)0x48002404) = 2;

/* Release DSP from reset (clear bit 0) → RM_RSTCTRL_IVA2 */

((int)0x48306050) &= ~(1 << 0);

GEL_TextOut(“C64x+ release from reset\n”,“result”);

}

Assuming that you have configured CCS for a Blackhawk debugger, then if you open CCS for the Cortex-A8 under the “GEL” menu you will find a menu item called “IVA2200_Startup à IVA22_GEM_Startup” that will call the below function if you click on it and enable the DSP. You should then be able to connect to the DSP.

Nishanth, looking at the GEL file omap3430_cortexA.gel shipped with CSST v2.3 (not looked at v2.4 yet), the above function is empty. So I don’t think that these GEL files will work. It would be good to add this to them :wink:

Cheers

Jon

Assuming that you have configured CCS for a Blackhawk debugger, then if
you open CCS for the Cortex-A8 under the “GEL” menu you will find a menu
item called “IVA2200_Startup → IVA22_GEM_Startup” that will call the
below function if you click on it and enable the DSP. You should then be
able to connect to the DSP.

Just in case this was not clear...I realize that you are using the SD emulators not Blackhawk (I prefer Blackhawk for what it is worth :wink: and there is no reason why you cannot use the same GEL files with the SD510USB. I have used the same GEL files for the SD510USB in the past for the OMAP3 devices. All you need to do is to open CCS Setup and for the Cortex-A8 select the GEL "C:\CCStudio_v3.3\cc\gel\omap3430_cortexA.gel" as your start-up GEL file for the Cortex-A8 (I am assuming that you know how to do this, let me know if you do not). Then you should be able to enable the DSP via the GEL menu as described above using the SD510USB.

Cheers
Jon

jon,

thanks this worked for me.

im now connected to the c64x.

pete.

Jon,