ODROID-C1 support

ODROID-C1 support

[Christian Ege]

Hello,

I've created a BSP Layer for the ODROID-C1 and other Amlogic based
devices like the Wetek.Play

https://github.com/linux-meson/meta-amlogic

regards,
Christian

Re: ODROID-C1 support

[Trevor Woerner]

Hi Christian,

Sorry, I missed your announcement before replying to Armin's post about
the -xu3! I was reading through my backlog of Yocto mailing list emails
and hadn't made it to my OE backlog yet ;-)

I hope we can all pull together some sort of common amlogic/odroid
layer(s) together.

Best regards,
    Trevor



On 05/05/15 11:40, Christian Ege wrote:
> Hello,
>
> I've created a BSP Layer for the ODROID-C1 and other Amlogic based
> devices like the Wetek.Play
>
> https://github.com/linux-meson/meta-amlogic
>
> regards,
> Christian

Re: ODROID-C1 support

[Trevor Woerner]

Hi Christian,

On 05/05/15 11:40, Christian Ege wrote:
> I've created a BSP Layer for the ODROID-C1 and other Amlogic based
> devices like the Wetek.Play
>
> https://github.com/linux-meson/meta-amlogic

Thanks! I've been playing with your layer. For the most part it's going
well. I've noticed a small glitch, however, and I'm not 100% sure how to
fix it (otherwise I would have just sent you a github pull request).

If I have your layer added to the BBLAYERS mix but I'm _not_ building
for "odroidc1" (or "wetekplay", I assume) then I get an error because
the build system can't find the amlsetfb.sh file. You have two
"amlsetfb.sh" files, one for the odroidc1 and one for the wetekplay
which you've added to recipes-core/initscripts/odroidc1 and
recipes-core/initscripts/wetekplay. If the MACHINE is odroidc1 then the
recipes-core/initscripts/odroidc1/amsetfb.sh file is found, otherwise it
is not.

I can work around this issue by adding a MACHINE-specific override to
your initscripts_1.%.bbappend:

-SRC_URI_append = " file://amlsetfb.sh \
+SRC_URI_append_odroidc1 = " file://amlsetfb.sh \

but I'm guessing another override would be required for the wetekplay as
well.

Why would someone include your layer and not build for odroidc1 or
wetekplay? Sometimes that's what people do ;-) (look at Angstrom, for
example). Besides, a BSP layer should be able to play nicely with other
layers even when its machines aren't being used :-)

Re: ODROID-C1 support

[Christian Ege]

Hi Trevor,
> Hi Christian,
> 
> On 05/05/15 11:40, Christian Ege wrote:
>> I've created a BSP Layer for the ODROID-C1 and other Amlogic based
>> devices like the Wetek.Play
>>
>> https://github.com/linux-meson/meta-amlogic
> 
> Thanks! I've been playing with your layer. For the most part it's going
> well. I've noticed a small glitch, however, and I'm not 100% sure how to
> fix it (otherwise I would have just sent you a github pull request).
Maybe the easiest Part would be not to bbappend initscripts and just add
an own reecipe for amlsetfb. Within this recipe I can use
COMPATIBLE_MACHINE.

I guess if I am using  COMPATIBLE_MACHINE in the
initscripts_1.%.bbappend will cause to not build initscripts for any
other machine. :)

> If I have your layer added to the BBLAYERS mix but I'm _not_ building
> for "odroidc1" (or "wetekplay", I assume) then I get an error because
> the build system can't find the amlsetfb.sh file. You have two
> "amlsetfb.sh" files, one for the odroidc1 and one for the wetekplay
> which you've added to recipes-core/initscripts/odroidc1 and
> recipes-core/initscripts/wetekplay. If the MACHINE is odroidc1 then the
> recipes-core/initscripts/odroidc1/amsetfb.sh file is found, otherwise it
> is not.
> 
> I can work around this issue by adding a MACHINE-specific override to
> your initscripts_1.%.bbappend:
> 
> -SRC_URI_append = " file://amlsetfb.sh \
> +SRC_URI_append_odroidc1 = " file://amlsetfb.sh \
> 
> but I'm guessing another override would be required for the wetekplay as
> well.
> 
> Why would someone include your layer and not build for odroidc1 or
> wetekplay? Sometimes that's what people do ;-) (look at Angstrom, for
> example). Besides, a BSP layer should be able to play nicely with other
> layers even when its machines aren't being used :-)

Yes I know people do strange things :)


Regards,
Christian

Re: ODROID-C1 support

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]


> On May 21, 2015, at 11:26 AM, Trevor Woerner <twoerner@gmail.com> wrote:
> 
> Hi Christian,
> 
> On 05/05/15 11:40, Christian Ege wrote:
>> I've created a BSP Layer for the ODROID-C1 and other Amlogic based
>> devices like the Wetek.Play
>> 
>> https://github.com/linux-meson/meta-amlogic
> 
> Thanks! I've been playing with your layer. For the most part it's going
> well. I've noticed a small glitch, however, and I'm not 100% sure how to
> fix it (otherwise I would have just sent you a github pull request).
> 
> If I have your layer added to the BBLAYERS mix but I'm _not_ building
> for "odroidc1" (or "wetekplay", I assume) then I get an error because
> the build system can't find the amlsetfb.sh file. You have two
> "amlsetfb.sh" files, one for the odroidc1 and one for the wetekplay
> which you've added to recipes-core/initscripts/odroidc1 and
> recipes-core/initscripts/wetekplay. If the MACHINE is odroidc1 then the
> recipes-core/initscripts/odroidc1/amsetfb.sh file is found, otherwise it
> is not.
> 
> I can work around this issue by adding a MACHINE-specific override to
> your initscripts_1.%.bbappend:
> 
> -SRC_URI_append = " file://amlsetfb.sh \
> +SRC_URI_append_odroidc1 = " file://amlsetfb.sh \
> 
> but I'm guessing another override would be required for the wetekplay as
> well.
> 
> Why would someone include your layer and not build for odroidc1 or
> wetekplay? Sometimes that's what people do ;-) (look at Angstrom, for
> example). Besides, a BSP layer should be able to play nicely with other
> layers even when its machines aren't being used :-)

This is very much desirable, in todays times. In angstrom e.g. we want to generalize feeds across
many machines for arm especially, so we can share common feeds across multiple armv7a machines
so BSP maintainers have to start thinking that their BSP layer will be put along with other BSP layers
and they not change common components mindlessly to fit for just one given machine.

secondly more and more end users especially big companies have more than 1 machine tied into their useless
so its desirable for them to use one distro across all the product lines and hence a requirement to have
BSP layers play well with each others.

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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: ODROID-C1 support

[Trevor Woerner]

On 05/21/15 17:18, Khem Raj wrote:
>> On May 21, 2015, at 11:26 AM, Trevor Woerner <twoerner@gmail.com> wrote:
>>
>>
>> Why would someone include your layer and not build for odroidc1 or
>> wetekplay? Sometimes that's what people do ;-) (look at Angstrom, for
>> example). Besides, a BSP layer should be able to play nicely with other
>> layers even when its machines aren't being used :-)
> This is very much desirable, in todays times. In angstrom e.g. we want to generalize feeds across
> many machines for arm especially, so we can share common feeds across multiple armv7a machines
> so BSP maintainers have to start thinking that their BSP layer will be put along with other BSP layers
> and they not change common components mindlessly to fit for just one given machine.
>
> secondly more and more end users especially big companies have more than 1 machine tied into their useless
> so its desirable for them to use one distro across all the product lines and hence a requirement to have
> BSP layers play well with each others.

Shouldn't this be true of distro layers as well?

Simply included meta-angstrom in conf/bblayers.conf causes one's DISTRO
to be set to angstrom, even if they select poky in conf/local.conf.

Re: ODROID-C1 support

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]


> On May 22, 2015, at 4:15 PM, Trevor Woerner <twoerner@gmail.com> wrote:
> 
> On 05/21/15 17:18, Khem Raj wrote:
>>> On May 21, 2015, at 11:26 AM, Trevor Woerner <twoerner@gmail.com> wrote:
>>> 
>>> 
>>> Why would someone include your layer and not build for odroidc1 or
>>> wetekplay? Sometimes that's what people do ;-) (look at Angstrom, for
>>> example). Besides, a BSP layer should be able to play nicely with other
>>> layers even when its machines aren't being used :-)
>> This is very much desirable, in todays times. In angstrom e.g. we want to generalize feeds across
>> many machines for arm especially, so we can share common feeds across multiple armv7a machines
>> so BSP maintainers have to start thinking that their BSP layer will be put along with other BSP layers
>> and they not change common components mindlessly to fit for just one given machine.
>> 
>> secondly more and more end users especially big companies have more than 1 machine tied into their useless
>> so its desirable for them to use one distro across all the product lines and hence a requirement to have
>> BSP layers play well with each others.
> 
> Shouldn't this be true of distro layers as well?

May be but its not a practical requirement.
Remember OE is a framework to build embedded Linux distributions, we can have multiple machines
supported for a given OE based distribution so thats a usual case, distribution is the global set of policies
under which your build then works. Now if you have two distribution layers then they may impose certain policies
that may be in conflict.

> 
> Simply included meta-angstrom in conf/bblayers.conf causes one's DISTRO
> to be set to angstrom, even if they select poky in conf/local.conf.
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]