[Buildroot] [PATCH 1 of 2] Introduction of Amlogic platform to buildroot

[Buildroot] [PATCH 1 of 2] Introduction of Amlogic platform to buildroot

[Stanislav Vasic]

[Buildroot] [PATCH 2 of 2] Introduction of Amlogic platform to buildroot

[Stanislav Vasic]

[Buildroot] [PATCH 1 of 2] Introduction of Amlogic platform to buildroot

[Thomas Petazzoni]

Dear Stanislav Vasic,

On Sat, 2 Nov 2013 15:34:18 +0000 (UTC), Stanislav Vasic wrote:
> From 5d941e3307401d261b817a3aa40fe75894050419 Mon Sep 17 00:00:00 2001
> From: Stanislav Vasic <svlasic@gmail.com>
> Date: Sat, 2 Nov 2013 14:52:14 +0100
> Subject: [PATCH] Re-add Linaro 2013.04 toolchain
> 
> Linaro 2013.04 toolchain is dependency for Amlogic platform
> because none of current Amlogic kernels are failing to boot
> when compiled with GCC higher than 4.7
> ---
>  toolchain/toolchain-external/Config.in             | 21 +++++++++++++++++
> ++++
>  toolchain/toolchain-external/toolchain-external.mk |  4 ++++
>  2 files changed, 25 insertions(+)

Your entire patch is severely line-wrapped, making it unusable. Can you
use 'git send-email' to send your patches instead?

See
http://buildroot.org/downloads/manual/manual.html#submitting-patches
for details.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2 of 2] Introduction of Amlogic platform to buildroot

[Thomas Petazzoni]

Dear Stanislav Vasic,

On Sat, 2 Nov 2013 15:35:00 +0000 (UTC), Stanislav Vasic wrote:
> From 674615f2986c928cadd122377bbb4254192f5923 Mon Sep 17 00:00:00 2001
> From: Stanislav Vasic <svlasic@gmail.com>
> Date: Sat, 2 Nov 2013 16:07:38 +0100
> Subject: [PATCH] Introduce Amlogic MX platform to buildroot
> 
> Target platform options submenu added, currently used
> only for setting up proper configuration of buildroot
> for Amlogic MX platform.

I'm afraid, but we don't want to have per-SoC options in Buildroot. We
have discussed this in the past, and there are way too many ARM SoC to
make this reasonable. Why is this patch needed at all?

For all other ARM platforms, the user simply has to choose the
appropriate ARM core (Cortex-A8, Cortex-A9, Cortex-A15, etc.), and
that's it. We also provide default configurations (see the configs/
directory) for various well-known hardware platforms, and those
configurations correctly define which ARM core should be used.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2 of 2] Introduction of Amlogic platform to buildroot

[Stanislav Vasic]

On Sat, 02 Nov 2013 16:54:59 +0100, Thomas Petazzoni wrote:

> Dear Stanislav Vasic,
> 
> On Sat, 2 Nov 2013 15:35:00 +0000 (UTC), Stanislav Vasic wrote:
>> From 674615f2986c928cadd122377bbb4254192f5923 Mon Sep 17 00:00:00 2001
>> From: Stanislav Vasic <svlasic@gmail.com>
>> Date: Sat, 2 Nov 2013 16:07:38 +0100 Subject: [PATCH] Introduce Amlogic
>> MX platform to buildroot
>> 
>> Target platform options submenu added, currently used only for setting
>> up proper configuration of buildroot for Amlogic MX platform.
> 
> I'm afraid, but we don't want to have per-SoC options in Buildroot. We
> have discussed this in the past, and there are way too many ARM SoC to
> make this reasonable. Why is this patch needed at all?

Hi,

That is what I was told yesterday (about adding it). Amlogic buildroot is 
too complicated and it's used mainly for running XBMC on top of buildroot. 
I agree there are too many things (such as non-standard opengl drivers, 
Amlogic property a/v libraries...).

Patch is needed so we know we're building for Amlogic SoC, and for other 
packages to know which eg. opengl or a/v libs to include in build.

> For all other ARM platforms, the user simply has to choose the
> appropriate ARM core (Cortex-A8, Cortex-A9, Cortex-A15, etc.), and
> that's it. We also provide default configurations (see the configs/
> directory) for various well-known hardware platforms, and those
> configurations correctly define which ARM core should be used.

See above, at this point it's not so simple for Amlogic.

> Best regards,
> 
> Thomas

Regards,
Stan

[Buildroot] [PATCH 2 of 2] Introduction of Amlogic platform to buildroot

[Thomas Petazzoni]

Dear Stanislav Vasic,

On Sat, 2 Nov 2013 16:10:16 +0000 (UTC), Stanislav Vasic wrote:

> That is what I was told yesterday (about adding it). Amlogic buildroot is 
> too complicated and it's used mainly for running XBMC on top of buildroot. 
> I agree there are too many things (such as non-standard opengl drivers, 
> Amlogic property a/v libraries...).

That's not a problem. We already have a number of packages with OpenGL
drivers for specific platforms:

 package/freescale-imx/gpu-viv-bin-mx6q/ (for i.MX6)
 package/rpi-userland/ (for Rasberry Pi)
 package/sunxi-mali/ (for Allwinner)
 package/ti-gfx/ (for TI OMAP)

> Patch is needed so we know we're building for Amlogic SoC, and for other 
> packages to know which eg. opengl or a/v libs to include in build.

Just do it the way we do it for all of the platforms mentioned above:
add a package in Buildroot, and make it depend on BR2_arm. This way it
will only be visible on ARM platforms, and from this point, users are
expected to know which OpenGL implementation they need for their
platform.

We are also considering adding "demo" defconfigs in Buildroot so that
users could easily find a configuration that enables OpenGL for a given
platform.

> > For all other ARM platforms, the user simply has to choose the
> > appropriate ARM core (Cortex-A8, Cortex-A9, Cortex-A15, etc.), and
> > that's it. We also provide default configurations (see the configs/
> > directory) for various well-known hardware platforms, and those
> > configurations correctly define which ARM core should be used.
> 
> See above, at this point it's not so simple for Amlogic.

See above. Amlogic is not exceptional: it's just like several other
SoCs we already support in Buildroot :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2 of 2] Introduction of Amlogic platform to buildroot

[Stanislav Vasic]

On Sat, 02 Nov 2013 17:20:23 +0100, Thomas Petazzoni wrote:

> Dear Stanislav Vasic,
> 
> On Sat, 2 Nov 2013 16:10:16 +0000 (UTC), Stanislav Vasic wrote:
> 
>> That is what I was told yesterday (about adding it). Amlogic buildroot
>> is too complicated and it's used mainly for running XBMC on top of
>> buildroot.
>> I agree there are too many things (such as non-standard opengl drivers,
>> Amlogic property a/v libraries...).
> 
> That's not a problem. We already have a number of packages with OpenGL
> drivers for specific platforms:
> 
>  package/freescale-imx/gpu-viv-bin-mx6q/ (for i.MX6)
>  package/rpi-userland/ (for Rasberry Pi) package/sunxi-mali/ (for
>  Allwinner) package/ti-gfx/ (for TI OMAP)
> 
>> Patch is needed so we know we're building for Amlogic SoC, and for
>> other packages to know which eg. opengl or a/v libs to include in
>> build.
> 
> Just do it the way we do it for all of the platforms mentioned above:
> add a package in Buildroot, and make it depend on BR2_arm. This way it
> will only be visible on ARM platforms, and from this point, users are
> expected to know which OpenGL implementation they need for their
> platform.
> 
> We are also considering adding "demo" defconfigs in Buildroot so that
> users could easily find a configuration that enables OpenGL for a given
> platform.
> 
>> > For all other ARM platforms, the user simply has to choose the
>> > appropriate ARM core (Cortex-A8, Cortex-A9, Cortex-A15, etc.), and
>> > that's it. We also provide default configurations (see the configs/
>> > directory) for various well-known hardware platforms, and those
>> > configurations correctly define which ARM core should be used.
>> 
>> See above, at this point it's not so simple for Amlogic.
> 
> See above. Amlogic is not exceptional: it's just like several other SoCs
> we already support in Buildroot :-)
> 
> Best regards,
> 
> Thomas

Hi,

I see your point. At the moment I don't have time to toy with it because 
lot of work, but if noone else is interested in doing such a thing, I'll 
do it but don't have any ETA on this one.

I did not follow since yesterday, but if not available, I can submit 
patch of extracting Linaro's gconv libs and copying it to target (option 
in toolchain configuration).

This patch works for all Linaros (oldest tested is 2012.03).

Regards,
Stan