[PATCH] nativesdk-packagegroup-sdk-host: add nativesdk-u-boot-mkimage

[PATCH] nativesdk-packagegroup-sdk-host: add nativesdk-u-boot-mkimage

[Javier Viguera]

Add the 'mkimage' host tool to the toolchains generated with 'bitbake
meta-toolchain' or with 'bitbake -c populate_sdk <image>'.

This allows to use the standalone toolchain to build kernel images of
type uImage (with u-boot header)

Signed-off-by: Javier Viguera <javier.viguera@digi.com>
---
 meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index 0c6a530be6f9..ab68e2ffd3a7 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -24,6 +24,7 @@ RDEPENDS_${PN} = "\
     nativesdk-makedevs \
     nativesdk-smartpm \
     nativesdk-postinst-intercept \
+    nativesdk-u-boot-mkimage \
     "
 
 RDEPENDS_${PN}_darwin = "\

Re: [PATCH] nativesdk-packagegroup-sdk-host: add nativesdk-u-boot-mkimage

[Burton, Ross]

On 2 October 2014 09:06, Javier Viguera <javier.viguera@digi.com> wrote:
> Add the 'mkimage' host tool to the toolchains generated with 'bitbake
> meta-toolchain' or with 'bitbake -c populate_sdk <image>'.

But not all BSPs uses u-boot.  Having the bootloader tooling makes
sense, but it needs to be the right tooling.

Ross

Re: [PATCH] nativesdk-packagegroup-sdk-host: add nativesdk-u-boot-mkimage

[Viguera, Javier]

> -----Original Message-----
> From: Burton, Ross [mailto:ross.burton@intel.com]
> 
> On 2 October 2014 09:06, Javier Viguera <javier.viguera@digi.com>
> wrote:
> > Add the 'mkimage' host tool to the toolchains generated with 'bitbake
> > meta-toolchain' or with 'bitbake -c populate_sdk <image>'.
> 
> But not all BSPs uses u-boot.  Having the bootloader tooling makes
> sense, but it needs to be the right tooling.


Hi Ross,

I was not targeting any specific BSP. I was just using a generic toolchain created with poky. My steps:

1. Clone Poky (or oe-core)
2. Created a generic project and configure for 'qemuarm' (MACHINE=qemuarm changed in local.conf)
3. bitbake meta-toolchain

With this toolchain you can build zImage kernel images but not uImage. Sure the uImage is to be used with u-boot, but I see the value of having a generic ARM toolchain and that still allows me to create uImage files. The mkimage binary adds about 80 KB in a 273 MB toolchain (doesn't seem too much).

-- jviguera

Re: [PATCH] nativesdk-packagegroup-sdk-host: add nativesdk-u-boot-mkimage

[Burton, Ross]

On 2 October 2014 15:34, Viguera, Javier <Javier.Viguera@digi.com> wrote:
> Hi Ross,
>
> I was not targeting any specific BSP. I was just using a generic toolchain created with poky. My steps:
>
> 1. Clone Poky (or oe-core)
> 2. Created a generic project and configure for 'qemuarm' (MACHINE=qemuarm changed in local.conf)
> 3. bitbake meta-toolchain
>
> With this toolchain you can build zImage kernel images but not uImage. Sure the uImage is to be used with u-boot, but I see the value of having a generic ARM toolchain and that still allows me to create uImage files. The mkimage binary adds about 80 KB in a 273 MB toolchain (doesn't seem too much).

If we're adding u-boot to the SDK then we should add every bootloader.
But why install grub for a PPC SDK?  This is why I suggested adding
the right bootloader for each machine.

Ross

Re: [PATCH] nativesdk-packagegroup-sdk-host: add nativesdk-u-boot-mkimage

[Viguera, Javier]

> -----Original Message-----
> From: Burton, Ross [mailto:ross.burton@intel.com]
> 
> If we're adding u-boot to the SDK then we should add every bootloader.
> But why install grub for a PPC SDK?  This is why I suggested adding
> the right bootloader for each machine.

Hi Ross,

Not sure if I follow you. Are you suggesting adding this in a bbappend inside a BSP layer instead of oe-core?

Or something like the following would be suitable for oe-core?:

RDEPENDS_${PN}_append_arm = " nativesdk-u-boot-mkimage"

This seems strange to me as I don't know if all ARM machines use u-boot as bootloader. How do I restrict this per-machine?

Notice that strictly speaking this is not "adding u-boot to the SDK". It's a host tool that allows to create kernel images suitable for u-boot. But not only that, it also allows for example to create FIT (Flattened Image Tree) images. I seem to remember there was a patch lately to add support for FIT images to oe-core.

-- jviguera

Re: [PATCH] nativesdk-packagegroup-sdk-host: add nativesdk-u-boot-mkimage

[Otavio Salvador]

On Thu, Oct 2, 2014 at 1:51 PM, Viguera, Javier <Javier.Viguera@digi.com> wrote:
>
>
>> -----Original Message-----
>> From: Burton, Ross [mailto:ross.burton@intel.com]
>>
>> If we're adding u-boot to the SDK then we should add every bootloader.
>> But why install grub for a PPC SDK?  This is why I suggested adding
>> the right bootloader for each machine.
>
> Hi Ross,
>
> Not sure if I follow you. Are you suggesting adding this in a bbappend inside a BSP layer instead of oe-core?
>
> Or something like the following would be suitable for oe-core?:
>
> RDEPENDS_${PN}_append_arm = " nativesdk-u-boot-mkimage"
>
> This seems strange to me as I don't know if all ARM machines use u-boot as bootloader. How do I restrict this per-machine?
>
> Notice that strictly speaking this is not "adding u-boot to the SDK". It's a host tool that allows to create kernel images suitable for u-boot. But not only that, it also allows for example to create FIT (Flattened Image Tree) images. I seem to remember there was a patch lately to add support for FIT images to oe-core.

Ross concern is because we shouldn't force mkimage in every SDK. If
someone is using barebox, or grub, it shouldn't be added.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] nativesdk-packagegroup-sdk-host: add nativesdk-u-boot-mkimage

[Viguera, Javier]

> -----Original Message-----
> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
> Ross concern is because we shouldn't force mkimage in every SDK. If
> someone is using barebox, or grub, it shouldn't be added.

Hi Otavio,

I understand what the concern is, what I don't see yet is how to address this *practically*. I put some questions in my previous e-mail, do you have any hints?

I see there is a nativesdk-packagegroup-sdk-host.bbappend in *meta-fsl-arm* that unconditionally adds some tools to the toolchain (elftosb, mxsldr). If my previous patch is not accepted in oe-core, are you willing to accept the same patch in this bbappend in meta-fsl-arm?

-- 
Javier Viguera
Software Engineer
Digi International® Spain S.A.U.

Re: [PATCH] nativesdk-packagegroup-sdk-host: add nativesdk-u-boot-mkimage

[Otavio Salvador]

On Fri, Oct 3, 2014 at 3:59 AM, Viguera, Javier <Javier.Viguera@digi.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
>> Ross concern is because we shouldn't force mkimage in every SDK. If
>> someone is using barebox, or grub, it shouldn't be added.
>
> Hi Otavio,
>
> I understand what the concern is, what I don't see yet is how to address this *practically*. I put some questions in my previous e-mail, do you have any hints?

Check this:

http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/48084

> I see there is a nativesdk-packagegroup-sdk-host.bbappend in *meta-fsl-arm* that unconditionally adds some tools to the toolchain (elftosb, mxsldr). If my previous patch is not accepted in oe-core, are you willing to accept the same patch in this bbappend in meta-fsl-arm?

Yes; we can work out something there.

The proposal I sent above had no much interest and people didn't
comment much. I still intend to look at it but I been with no free
time lately.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750