New meta-cubox layer

New meta-cubox layer

[Carlos Rafael Giani]

Hello,

I have created a BSP layer for the SolidRun Cubox platform. Informations about this device can be found athttp://solid-run.com/cubox  .
The layer itself is hosted athttps://github.com/dv1/meta-cubox  .

This layer introduces a new machine, new tunes for the CuBox' Marvell PJ4 processor, in addition to the platform specific recipes for hardware video acceleration and EGL,OpenGL ES,OpenVG support. Both hardfp and softfp are supported.
The 3D accelerator and the hardware accelerated video engine (called vMeta) require some closed source components. The recipes pick the right ones depending on whether softpfp or hardfp is used.

It also copies the generated uImage into the rootfs (as expected by the bootloader), and autogenerates a boot.scr out of an included boot script using uboot-mkimage.
The resulting tarball is extracted on an SD card, and the device can be booted.

A new xorg driver and a customized xorg.conf are included.

I'm open to feedback, patches, suggestions.

Thanks

Re: New meta-cubox layer

[Khem Raj]

On Apr 3, 2013, at 9:50 AM, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:

> Hello,
> 
> I have created a BSP layer for the SolidRun Cubox platform. Informations about this device can be found athttp://solid-run.com/cubox  .
> The layer itself is hosted athttps://github.com/dv1/meta-cubox  .
> 
> This layer introduces a new machine, new tunes for the CuBox' Marvell PJ4 processor, in addition to the platform specific recipes for hardware video acceleration and EGL,OpenGL ES,OpenVG support. Both hardfp and softfp are supported.
> The 3D accelerator and the hardware accelerated video engine (called vMeta) require some closed source components. The recipes pick the right ones depending on whether softpfp or hardfp is used.
> 
> It also copies the generated uImage into the rootfs (as expected by the bootloader), and autogenerates a boot.scr out of an included boot script using uboot-mkimage.
> The resulting tarball is extracted on an SD card, and the device can be booted.
> 
> A new xorg driver and a customized xorg.conf are included.
> 
> I'm open to feedback, patches, suggestions.


Carlos

Thanks for doing this. Please add this to layer index here http://layers.openembedded.org/layerindex/

> 
> Thanks
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: New meta-cubox layer

[Burton, Ross]

On 3 April 2013 17:50, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:
> I have created a BSP layer for the SolidRun Cubox platform. Informations
> about this device can be found athttp://solid-run.com/cubox  .

Nice.  More importantly, how can I get one in the UK. :)

Ross

Re: New meta-cubox layer

[Carlos Rafael Giani]

On 2013-04-03 20:05, Burton, Ross wrote:
> On 3 April 2013 17:50, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:
>> I have created a BSP layer for the SolidRun Cubox platform. Informations
>> about this device can be found athttp://solid-run.com/cubox  .
> Nice.  More importantly, how can I get one in the UK. :)
>
> Ross
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Well, I have been told that New IT is a good source: 
https://www.newit.co.uk/shop/proddetail.php?prod=CuBox

Re: New meta-cubox layer

[Carlos Rafael Giani]

On 2013-04-03 19:52, Khem Raj wrote:
> On Apr 3, 2013, at 9:50 AM, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:
>
>> Hello,
>>
>> I have created a BSP layer for the SolidRun Cubox platform. Informations about this device can be found athttp://solid-run.com/cubox  .
>> The layer itself is hosted athttps://github.com/dv1/meta-cubox  .
>>
>> This layer introduces a new machine, new tunes for the CuBox' Marvell PJ4 processor, in addition to the platform specific recipes for hardware video acceleration and EGL,OpenGL ES,OpenVG support. Both hardfp and softfp are supported.
>> The 3D accelerator and the hardware accelerated video engine (called vMeta) require some closed source components. The recipes pick the right ones depending on whether softpfp or hardfp is used.
>>
>> It also copies the generated uImage into the rootfs (as expected by the bootloader), and autogenerates a boot.scr out of an included boot script using uboot-mkimage.
>> The resulting tarball is extracted on an SD card, and the device can be booted.
>>
>> A new xorg driver and a customized xorg.conf are included.
>>
>> I'm open to feedback, patches, suggestions.
>
> Carlos
>
> Thanks for doing this. Please add this to layer index here http://layers.openembedded.org/layerindex/
>
>

Hello,

it is added.

Carlos

Re: New meta-cubox layer

[Burton, Ross]

On 3 April 2013 19:11, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:
> Well, I have been told that New IT is a good source:
> https://www.newit.co.uk/shop/proddetail.php?prod=CuBox

So it is, thanks!

Ross

Re: New meta-cubox layer

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 03-04-13 18:50, Carlos Rafael Giani schreef:
> Hello,
> 
> I have created a BSP layer for the SolidRun Cubox platform. Informations
> about this device can be found athttp://solid-run.com/cubox  . The layer
> itself is hosted athttps://github.com/dv1/meta-cubox  .

So how is this different from https://github.com/naguirre/meta-cubox ?

> 
> This layer introduces a new machine, new tunes for the CuBox' Marvell
> PJ4 processor, in addition to the platform specific recipes for hardware
> video acceleration and EGL,OpenGL ES,OpenVG support. Both hardfp and
> softfp are supported. The 3D accelerator and the hardware accelerated
> video engine (called vMeta) require some closed source components. The
> recipes pick the right ones depending on whether softpfp or hardfp is
> used.
> 
> It also copies the generated uImage into the rootfs (as expected by the 
> bootloader), and autogenerates a boot.scr out of an included boot script
> using uboot-mkimage. The resulting tarball is extracted on an SD card,
> and the device can be booted.
> 
> A new xorg driver and a customized xorg.conf are included.
> 
> I'm open to feedback, patches, suggestions.

Just like https://github.com/naguirre/meta-cubox you're mixing DISTRO policy
in the machine files by setting the tuning to hardfloat. Don't do that. If
you want hardfloat, set that in your distro config, not in your machine config.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFRXHc0MkyGM64RGpERAmezAJwPD4r3W/6qY5wnDCY2xh6hQTGGDQCeK5sL
h33NDHBAlEs2TyV+B6ajj5I=
=F+fa
-----END PGP SIGNATURE-----

Re: New meta-cubox layer

[Carlos Rafael Giani]

On 2013-04-03 20:38, Koen Kooi wrote:
> So how is this different from https://github.com/naguirre/meta-cubox ?

I am in contact with the author of that layer. My work started as a fork 
of that, since the layer did not work for me, but since I anyway was 
changing pretty much all of it from the ground up, I decided to start my 
own. Now, covers more features of the CuBox, and supports both soft- and 
hardfp in all recipes.

>
> Just like https://github.com/naguirre/meta-cubox you're mixing DISTRO 
> policy in the machine files by setting the tuning to hardfloat. Don't 
> do that. If you want hardfloat, set that in your distro config, not in 
> your machine config.

Do I understand it correctly that I should drop "marvellpj4hf" from 
https://github.com/dv1/meta-cubox/blob/master/conf/machine/include/tune-marvell-pj4.inc 
, or at least not set it as DEFAULTTUNE, not even with the ?= operation, 
and just use "marvellpj4" instead ? Because it is the distros decision 
to add the "callconvention-hard" feature?

The reason I ask that is because when I was writing the tune, I stumbled 
upon 
https://github.com/openembedded/oe-core/blob/master/meta/conf/machine/include/arm/arch-armv7a.inc 
, which includes armv7a, armv7ahf . This confuses me. Why is it OK there 
to mix in the callconvention?

Finally, is there a way to give a distro a "hint" about what is 
preferred for a machine (soft/hardfp)? One that the distro is free to 
ignore or respect?

Re: New meta-cubox layer

[Philip Balister]

On 04/03/2013 02:38 PM, Koen Kooi wrote:
> Op 03-04-13 18:50, Carlos Rafael Giani schreef:
> 
> Just like https://github.com/naguirre/meta-cubox you're mixing
> DISTRO policy in the machine files by setting the tuning to
> hardfloat. Don't do that. If you want hardfloat, set that in your
> distro config, not in your machine config.
> 

This keeps coming up, but I do not see an answer that works for people
creating BSP's that work with just oe-core and a BSP layer.

How are we supposed to set TUNE parameters for this case? And yes,
this case *must* produce useful output.

Philip


> 
> 
> _______________________________________________ Openembedded-devel
> mailing list Openembedded-devel@lists.openembedded.org 
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> 
> 

Re: New meta-cubox layer

[Koen Kooi]

Op 3 apr. 2013 om 21:34 heeft Philip Balister <philip@balister.org> het volgende geschreven:

> On 04/03/2013 02:38 PM, Koen Kooi wrote:
>> Op 03-04-13 18:50, Carlos Rafael Giani schreef:
>> 
>> Just like https://github.com/naguirre/meta-cubox you're mixing
>> DISTRO policy in the machine files by setting the tuning to
>> hardfloat. Don't do that. If you want hardfloat, set that in your
>> distro config, not in your machine config.
> 
> This keeps coming up, but I do not see an answer that works for people
> creating BSP's that work with just oe-core and a BSP layer.
> 
> How are we supposed to set TUNE parameters for this case? And yes,
> this case *must* produce useful output.

Local.conf



> 
> Philip
> 
> 
>> 
>> 
>> _______________________________________________ Openembedded-devel
>> mailing list Openembedded-devel@lists.openembedded.org 
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>> 
>> 
>> 

Re: New meta-cubox layer

[Philip Balister]

On 04/03/2013 03:57 PM, Koen Kooi wrote:
> 
> 
> Op 3 apr. 2013 om 21:34 heeft Philip Balister <philip@balister.org> het volgende geschreven:
> 
>> On 04/03/2013 02:38 PM, Koen Kooi wrote:
>>> Op 03-04-13 18:50, Carlos Rafael Giani schreef:
>>>
>>> Just like https://github.com/naguirre/meta-cubox you're mixing
>>> DISTRO policy in the machine files by setting the tuning to
>>> hardfloat. Don't do that. If you want hardfloat, set that in your
>>> distro config, not in your machine config.
>>
>> This keeps coming up, but I do not see an answer that works for people
>> creating BSP's that work with just oe-core and a BSP layer.
>>
>> How are we supposed to set TUNE parameters for this case? And yes,
>> this case *must* produce useful output.
> 
> Local.conf

Fail. This means BSP providers are depending on users to do the right thing.

The BSP should be able to say what it wants and a distro layer needs to
override the BSP choice for distributions providing binaries for
multiple machines.

Philip


> 
> 
> 
>>
>> Philip
>>
>>
>>>
>>>
>>> _______________________________________________ Openembedded-devel
>>> mailing list Openembedded-devel@lists.openembedded.org 
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>>>
>>>
> 
> 

Re: New meta-cubox layer

[Koen Kooi]

Op 3 apr. 2013, om 22:07 heeft Philip Balister <philip@balister.org> het volgende geschreven:

> On 04/03/2013 03:57 PM, Koen Kooi wrote:
>> 
>> 
>> Op 3 apr. 2013 om 21:34 heeft Philip Balister <philip@balister.org> het volgende geschreven:
>> 
>>> On 04/03/2013 02:38 PM, Koen Kooi wrote:
>>>> Op 03-04-13 18:50, Carlos Rafael Giani schreef:
>>>> 
>>>> Just like https://github.com/naguirre/meta-cubox you're mixing
>>>> DISTRO policy in the machine files by setting the tuning to
>>>> hardfloat. Don't do that. If you want hardfloat, set that in your
>>>> distro config, not in your machine config.
>>> 
>>> This keeps coming up, but I do not see an answer that works for people
>>> creating BSP's that work with just oe-core and a BSP layer.
>>> 
>>> How are we supposed to set TUNE parameters for this case? And yes,
>>> this case *must* produce useful output.
>> 
>> Local.conf
> 
> Fail. This means BSP providers are depending on users to do the right thing.

"The right thing"? Is forcing RPM package management "the right thing"? Is moving DEPLOY_DIR "the right thing"?

> The BSP should be able to say what it wants

For MACHINE settings yes, for DISTRO settings, no

> and a distro layer needs to
> override the BSP choice for distributions providing binaries for
> multiple machines.

DISTRO settings in a BSP violates the Yocto Compatible rules as well as the established OE rules, I don't see why that should get changed.

In this specific case, a BSP can set COMPATIBLE_HOST on the recipes that need to be hardfloat.

In OE classic we had an ABI flag to set this globally, in OE-core the powers that be force us to set a tune per machine in the DISTRO config. The price of progress I guess.


> 
> Philip
> 
> 
>> 
>> 
>> 
>>> 
>>> Philip
>>> 
>>> 
>>>> 
>>>> 
>>>> _______________________________________________ Openembedded-devel
>>>> mailing list Openembedded-devel@lists.openembedded.org 
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>> 
>>>> 
>>>> 
>> 
>> 

Re: New meta-cubox layer

[Carlos Rafael Giani]

Okay, I think I see the problem now. DEFAULTTUNES should not be set by 
the machine config. So, removing it
and fixing the README accordingly takes care of that. People who for 
example want hardfp then
set DEFAULTTUNE ?= "marvellpj4hf" in their local.conf . Is this correct?

On 2013-04-03 22:19, Koen Kooi wrote:
>
>>> Local.conf
>> Fail. This means BSP providers are depending on users to do the right thing.
> "The right thing"? Is forcing RPM package management "the right thing"? Is moving DEPLOY_DIR "the right thing"?
>
>> The BSP should be able to say what it wants
> For MACHINE settings yes, for DISTRO settings, no
>
>> and a distro layer needs to
>> override the BSP choice for distributions providing binaries for
>> multiple machines.
> DISTRO settings in a BSP violates the Yocto Compatible rules as well as the established OE rules, I don't see why that should get changed.
>
> In this specific case, a BSP can set COMPATIBLE_HOST on the recipes that need to be hardfloat.
>
> In OE classic we had an ABI flag to set this globally, in OE-core the powers that be force us to set a tune per machine in the DISTRO config. The price of progress I guess.
>
>

Re: New meta-cubox layer

[Otavio Salvador]

On Wed, Apr 3, 2013 at 4:34 PM, Philip Balister <philip@balister.org> wrote:
> On 04/03/2013 02:38 PM, Koen Kooi wrote:
>> Op 03-04-13 18:50, Carlos Rafael Giani schreef:
>>
>> Just like https://github.com/naguirre/meta-cubox you're mixing
>> DISTRO policy in the machine files by setting the tuning to
>> hardfloat. Don't do that. If you want hardfloat, set that in your
>> distro config, not in your machine config.
>>
>
> This keeps coming up, but I do not see an answer that works for people
> creating BSP's that work with just oe-core and a BSP layer.
>
> How are we supposed to set TUNE parameters for this case? And yes,
> this case *must* produce useful output.

I don't think TUNE is a distro thing. It is indeed a board setting and
I expect every board to have a good know TUNE setting.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: New meta-cubox layer

[Otavio Salvador]

On Wed, Apr 3, 2013 at 5:49 PM, Carlos Rafael Giani
<dv@pseudoterminal.org> wrote:
> Okay, I think I see the problem now. DEFAULTTUNES should not be set by the
> machine config. So, removing it
> and fixing the README accordingly takes care of that. People who for example
> want hardfp then
> set DEFAULTTUNE ?= "marvellpj4hf" in their local.conf . Is this correct?

You may provide a machine variant with has this set; so it will build
a machine with this enabled.

Koen, would you be happy with it?

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: New meta-cubox layer

[Khem Raj]

On Apr 3, 2013, at 2:45 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:

> On Wed, Apr 3, 2013 at 5:49 PM, Carlos Rafael Giani
> <dv@pseudoterminal.org> wrote:
>> Okay, I think I see the problem now. DEFAULTTUNES should not be set by the
>> machine config. So, removing it
>> and fixing the README accordingly takes care of that. People who for example
>> want hardfp then
>> set DEFAULTTUNE ?= "marvellpj4hf" in their local.conf . Is this correct?
> 
> You may provide a machine variant with has this set; so it will build
> a machine with this enabled. 

I would say no. Weather to choose Hard float or not is more of a capability that machine exposes
but distro decided the policy see how its done in angstrom for beagle board and beagle bone

> 
> Koen, would you be happy with it?
> 
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: New meta-cubox layer

[Carlos Rafael Giani]

On 2013-04-04 00:21, Khem Raj wrote:
> On Apr 3, 2013, at 2:45 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>
>> On Wed, Apr 3, 2013 at 5:49 PM, Carlos Rafael Giani
>> <dv@pseudoterminal.org> wrote:
>>> Okay, I think I see the problem now. DEFAULTTUNES should not be set by the
>>> machine config. So, removing it
>>> and fixing the README accordingly takes care of that. People who for example
>>> want hardfp then
>>> set DEFAULTTUNE ?= "marvellpj4hf" in their local.conf . Is this correct?
>> You may provide a machine variant with has this set; so it will build
>> a machine with this enabled.
> I would say no. Weather to choose Hard float or not is more of a capability that machine exposes
> but distro decided the policy see how its done in angstrom for beagle board and beagle bone
>

You mean this file? 
https://github.com/Angstrom-distribution/meta-angstrom/blob/master/conf/distro/include/arm-defaults.inc

Re: New meta-cubox layer

[Martin Jansa]

Yes that looks correct, you can also find this thread
http://patches.openembedded.org/patch/37055/ interesting (better on other
archive, but linuxtogo is down now).

Unfortunately that RFC was rejected, so DISTROs have to hardcode list of
supported MACHINEs and their defaulttunes, SHR does the same in:
https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-shr/conf/distro/include/defaulttunes.inc


On Thu, Apr 4, 2013 at 12:29 AM, Carlos Rafael Giani
<dv@pseudoterminal.org>wrote:

> On 2013-04-04 00:21, Khem Raj wrote:
>
>> On Apr 3, 2013, at 2:45 PM, Otavio Salvador <otavio@ossystems.com.br>
>> wrote:
>>
>>  On Wed, Apr 3, 2013 at 5:49 PM, Carlos Rafael Giani
>>> <dv@pseudoterminal.org> wrote:
>>>
>>>> Okay, I think I see the problem now. DEFAULTTUNES should not be set by
>>>> the
>>>> machine config. So, removing it
>>>> and fixing the README accordingly takes care of that. People who for
>>>> example
>>>> want hardfp then
>>>> set DEFAULTTUNE ?= "marvellpj4hf" in their local.conf . Is this correct?
>>>>
>>> You may provide a machine variant with has this set; so it will build
>>> a machine with this enabled.
>>>
>> I would say no. Weather to choose Hard float or not is more of a
>> capability that machine exposes
>> but distro decided the policy see how its done in angstrom for beagle
>> board and beagle bone
>>
>>
> You mean this file? https://github.com/Angstrom-**
> distribution/meta-angstrom/**blob/master/conf/distro/**
> include/arm-defaults.inc<https://github.com/Angstrom-distribution/meta-angstrom/blob/master/conf/distro/include/arm-defaults.inc>
>
> ______________________________**_________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.**openembedded.org<Openembedded-devel@lists.openembedded.org>
> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-devel<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel>
>

Re: New meta-cubox layer

[Carlos Rafael Giani]

On 2013-04-04 00:40, Martin Jansa wrote:
> Yes that looks correct, you can also find this thread
> http://patches.openembedded.org/patch/37055/ interesting (better on other
> archive, but linuxtogo is down now).
>
> Unfortunately that RFC was rejected, so DISTROs have to hardcode list of
> supported MACHINEs and their defaulttunes, SHR does the same in:
> https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-shr/conf/distro/include/defaulttunes.inc
>
>
> On Thu, Apr 4, 2013 at 12:29 AM, Carlos Rafael Giani
> <dv@pseudoterminal.org>wrote:
>
>

Okay, I removed DEFAULTTUNE from the machine conf and updated the readme.

Re: New meta-cubox layer

[Philip Balister]

On 04/03/2013 05:43 PM, Otavio Salvador wrote:
> On Wed, Apr 3, 2013 at 4:34 PM, Philip Balister <philip@balister.org> wrote:
>> On 04/03/2013 02:38 PM, Koen Kooi wrote:
>>> Op 03-04-13 18:50, Carlos Rafael Giani schreef:
>>>
>>> Just like https://github.com/naguirre/meta-cubox you're mixing
>>> DISTRO policy in the machine files by setting the tuning to
>>> hardfloat. Don't do that. If you want hardfloat, set that in your
>>> distro config, not in your machine config.
>>>
>>
>> This keeps coming up, but I do not see an answer that works for people
>> creating BSP's that work with just oe-core and a BSP layer.
>>
>> How are we supposed to set TUNE parameters for this case? And yes,
>> this case *must* produce useful output.
> 
> I don't think TUNE is a distro thing. It is indeed a board setting and
> I expect every board to have a good know TUNE setting.

The problem is if you are building for several machines, you may want to
force the same tune settings for several machines that are different
from what the BSP owner "declared" the default to be. Otherwise all
packages become per machine.

Philip

> 
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 
> 

Re: New meta-cubox layer

[Koen Kooi]

Op 3 apr. 2013, om 23:43 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:

> On Wed, Apr 3, 2013 at 4:34 PM, Philip Balister <philip@balister.org> wrote:
>> On 04/03/2013 02:38 PM, Koen Kooi wrote:
>>> Op 03-04-13 18:50, Carlos Rafael Giani schreef:
>>> 
>>> Just like https://github.com/naguirre/meta-cubox you're mixing
>>> DISTRO policy in the machine files by setting the tuning to
>>> hardfloat. Don't do that. If you want hardfloat, set that in your
>>> distro config, not in your machine config.
>>> 
>> 
>> This keeps coming up, but I do not see an answer that works for people
>> creating BSP's that work with just oe-core and a BSP layer.
>> 
>> How are we supposed to set TUNE parameters for this case? And yes,
>> this case *must* produce useful output.
> 
> I don't think TUNE is a distro thing. It is indeed a board setting and
> I expect every board to have a good know TUNE setting.

In OE classic it was called ARM_FLOAT_ABI, which shows it's a DISTRO thing. And furthermore, there is no real world performance difference between the default (softfp) and hardfloat. 

Re: New meta-cubox layer

[Koen Kooi]

Op 4 apr. 2013, om 00:52 heeft Philip Balister <philip@balister.org> het volgende geschreven:

> On 04/03/2013 05:43 PM, Otavio Salvador wrote:
>> On Wed, Apr 3, 2013 at 4:34 PM, Philip Balister <philip@balister.org> wrote:
>>> On 04/03/2013 02:38 PM, Koen Kooi wrote:
>>>> Op 03-04-13 18:50, Carlos Rafael Giani schreef:
>>>> 
>>>> Just like https://github.com/naguirre/meta-cubox you're mixing
>>>> DISTRO policy in the machine files by setting the tuning to
>>>> hardfloat. Don't do that. If you want hardfloat, set that in your
>>>> distro config, not in your machine config.
>>>> 
>>> 
>>> This keeps coming up, but I do not see an answer that works for people
>>> creating BSP's that work with just oe-core and a BSP layer.
>>> 
>>> How are we supposed to set TUNE parameters for this case? And yes,
>>> this case *must* produce useful output.
>> 
>> I don't think TUNE is a distro thing. It is indeed a board setting and
>> I expect every board to have a good know TUNE setting.
> 
> The problem is if you are building for several machines, you may want to
> force the same tune settings for several machines that are different
> from what the BSP owner "declared" the default to be. Otherwise all
> packages become per machine.

Let's not call it 'tune' settings, let's call it what it is: floatingpoint ABI.

Let's look at this sitation: I have 2 marvell armada 510 based boards, a cubox and a spherebox. I build bash for both machines, but the bash ipk from the one doesn't run on the other. That's a great first experience when using the BSP, existing software for that SoC doesn't work anymore.

> 
> Philip
> 
>> 
>> --
>> Otavio Salvador                             O.S. Systems
>> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
>> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
>> 
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>> 
>> 

Re: New meta-cubox layer

[Henning Heinold]

On Wed, Apr 03, 2013 at 06:50:46PM +0200, Carlos Rafael Giani wrote:
> Hello,
> 
> I have created a BSP layer for the SolidRun Cubox platform. Informations about this device can be found athttp://solid-run.com/cubox  .
> The layer itself is hosted athttps://github.com/dv1/meta-cubox  .
> 
> This layer introduces a new machine, new tunes for the CuBox' Marvell PJ4 processor, in addition to the platform specific recipes for hardware video acceleration and EGL,OpenGL ES,OpenVG support. Both hardfp and softfp are supported.
> The 3D accelerator and the hardware accelerated video engine (called vMeta) require some closed source components. The recipes pick the right ones depending on whether softpfp or hardfp is used.
> 
> It also copies the generated uImage into the rootfs (as expected by the bootloader), and autogenerates a boot.scr out of an included boot script using uboot-mkimage.
> The resulting tarball is extracted on an SD card, and the device can be booted.
> 
> A new xorg driver and a customized xorg.conf are included.
> 
> I'm open to feedback, patches, suggestions.
> 
> Thanks

Hi,

nice work, but I wonder why the u-boot needs a boot.scr. Is it that old or can you switch it over to uEnv.txt so it is easier for people
to change kernel cmdline and other u-boot config stuff.

Bye Henning

Re: New meta-cubox layer

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 03-04-13 21:04, Carlos Rafael Giani schreef:
> On 2013-04-03 20:38, Koen Kooi wrote:
>> So how is this different from https://github.com/naguirre/meta-cubox ?
> 
> I am in contact with the author of that layer. My work started as a fork
> of that, since the layer did not work for me, but since I anyway was
> changing pretty much all of it from the ground up, I decided to start my
> own. Now, covers more features of the CuBox, and supports both soft- and
> hardfp in all recipes.
> 
>> 
>> Just like https://github.com/naguirre/meta-cubox you're mixing DISTRO
>> policy in the machine files by setting the tuning to hardfloat. Don't
>> do that. If you want hardfloat, set that in your distro config, not in
>> your machine config.
> 
> Do I understand it correctly that I should drop "marvellpj4hf" from 
> https://github.com/dv1/meta-cubox/blob/master/conf/machine/include/tune-marvell-pj4.inc
>
> 
, or at least not set it as DEFAULTTUNE, not even with the ?= operation, and
> just use "marvellpj4" instead ? Because it is the distros decision to add
> the "callconvention-hard" feature?

Exactly!

> The reason I ask that is because when I was writing the tune, I stumbled
> upon 
> https://github.com/openembedded/oe-core/blob/master/meta/conf/machine/include/arm/arch-armv7a.inc
>
> 
, which includes armv7a, armv7ahf . This confuses me. Why is it OK there to
> mix in the callconvention?

It isn't, that file just lists all the permutiations available.

> Finally, is there a way to give a distro a "hint" about what is preferred
> for a machine (soft/hardfp)? One that the distro is free to ignore or
> respect?

There isn't, apart from a note in the README of your BSP.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFRXUucMkyGM64RGpERAlQFAKCpia9xhA+ldV8AdpH2F3GWAkptQwCgsCcd
2Tz5vaOMU9oX93XPNmAZE/E=
=fR8B
-----END PGP SIGNATURE-----

Re: New meta-cubox layer

[Carlos Rafael Giani]

On 04/04/2013 09:32 AM, Henning Heinold wrote:
> Hi,
>
> nice work, but I wonder why the u-boot needs a boot.scr. Is it that old or can you switch it over to uEnv.txt so it is easier for people
> to change kernel cmdline and other u-boot config stuff.
>
> Bye Henning
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

I agree this would be very useful. But with the CuBox, U-Boot is stored 
in internal flash, and is not read from the SD/MMC card, or hard drive, 
etc. To use an updated version, one has to flash it manually. This is 
also why U-Boot is not mentioned in the machine config.