[meta-fsl-arm PATCH v2 1/3] u-boot-fslc: Update to patches-2013.04's 20130415 snapshot based on 2013.04-rc3

[meta-fsl-arm PATCH v2 1/3] u-boot-fslc: Update to patches-2013.04's 20130415 snapshot based on 2013.04-rc3

[Otavio Salvador]

This updates to U-Boot 2013.04-rc3 based code and changes the U-Boot
target for using in i.MX31PDK as it was changed in this release.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2: None

 conf/machine/imx31pdk.conf                   | 4 ++--
 recipes-bsp/u-boot/u-boot-fslc_2013.04.bb    | 2 +-
 recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/conf/machine/imx31pdk.conf b/conf/machine/imx31pdk.conf
index 9ae6245..def898c 100644
--- a/conf/machine/imx31pdk.conf
+++ b/conf/machine/imx31pdk.conf
@@ -10,10 +10,10 @@ SOC_FAMILY = "mx3:mx31"
 
 GUI_MACHINE_CLASS = "smallscreen"
 
-UBOOT_MAKE_TARGET = "u-boot-nand.bin"
+UBOOT_MAKE_TARGET = "u-boot-with-spl.bin"
 UBOOT_SUFFIX = "bin"
 UBOOT_MACHINE = "mx31pdk_config"
-UBOOT_BINARY = "u-boot-nand.bin"
+UBOOT_BINARY = "u-boot-with-spl.bin"
 
 IMAGE_FSTYPES = "ubi jffs2 tar.bz2"
 MKUBIFS_ARGS = "-m 2048 -e 129024 -c 2030"
diff --git a/recipes-bsp/u-boot/u-boot-fslc_2013.04.bb b/recipes-bsp/u-boot/u-boot-fslc_2013.04.bb
index f339996..e1dc1d2 100644
--- a/recipes-bsp/u-boot/u-boot-fslc_2013.04.bb
+++ b/recipes-bsp/u-boot/u-boot-fslc_2013.04.bb
@@ -10,7 +10,7 @@ PROVIDES += "u-boot"
 
 PV = "v2013.04"
 
-SRCREV = "debad5d6cba77538d183ac947a41f6b88f9498b2"
+SRCREV = "6675aaab17b944867aa13164e50ecdab0884b8b8"
 SRC_URI = "git://github.com/Freescale/u-boot-imx.git"
 
 S = "${WORKDIR}/git"
diff --git a/recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb b/recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb
index 0ef48a2..74b7cc2 100644
--- a/recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb
+++ b/recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb
@@ -5,7 +5,7 @@ SECTION = "bootloader"
 
 PV = "v2013.04"
 
-SRCREV = "debad5d6cba77538d183ac947a41f6b88f9498b2"
+SRCREV = "6675aaab17b944867aa13164e50ecdab0884b8b8"
 SRC_URI = "git://github.com/Freescale/u-boot-imx.git"
 
 S = "${WORKDIR}/git"
-- 
1.8.1

[meta-fsl-arm PATCH v2 2/3] linux-imx.inc: Pass LOADADDRESS to kernel build

[Otavio Salvador]

By default, the kernel uses the known value for the entry address
however we cannot rely on this for having the right value. To
workaround it we should pass LOADADDRESS value to the kernel build
system.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2: None

 recipes-kernel/linux/linux-imx.inc | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/recipes-kernel/linux/linux-imx.inc b/recipes-kernel/linux/linux-imx.inc
index 5fbdfe0..9020f57 100644
--- a/recipes-kernel/linux/linux-imx.inc
+++ b/recipes-kernel/linux/linux-imx.inc
@@ -19,6 +19,10 @@ SRC_URI = "git://git.freescale.com/imx/linux-2.6-imx.git \
 
 S = "${WORKDIR}/git"
 
+# We need to pass it as param since kernel might support more then one
+# machine, with different entry points
+KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
+
 kernel_conf_variable() {
 	CONF_SED_SCRIPT="$CONF_SED_SCRIPT /CONFIG_$1[ =]/d;"
 	if test "$2" = "n"
-- 
1.8.1

[meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Otavio Salvador]

Provides a new linux-fslc.inc file which abstracts the specific
changes for the linux-fslc based kernels. A new variable has been add
to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
kernel install as 'imx-test' is not supported for Linux mainline.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2:
- Reuse linux-imx.inc
- Add linux-fslc.inc

 recipes-kernel/linux/linux-fslc.inc    | 20 ++++++++++++++++++++
 recipes-kernel/linux/linux-fslc_3.8.bb | 25 +------------------------
 recipes-kernel/linux/linux-imx.inc     | 17 +++++++++++------
 3 files changed, 32 insertions(+), 30 deletions(-)
 create mode 100644 recipes-kernel/linux/linux-fslc.inc

diff --git a/recipes-kernel/linux/linux-fslc.inc b/recipes-kernel/linux/linux-fslc.inc
new file mode 100644
index 0000000..6ebf833
--- /dev/null
+++ b/recipes-kernel/linux/linux-fslc.inc
@@ -0,0 +1,20 @@
+# Copyright (C) 2012-2013 O.S. Systems Software LTDA.
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+DESCRIPTION = "Freescale Community mainline based Linux kernel"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
+DEPENDS += "lzop-native"
+PROVIDES = "virtual/kernel linux-mainline"
+
+inherit kernel
+
+require recipes-kernel/linux/linux-imx.inc
+require recipes-kernel/linux/linux-dtb.inc
+
+# Avoid imx-test installation hacks
+IMX_TEST_SUPPORT = "n"
+
+SRC_URI = "git://github.com/Freescale/linux-mainline.git \
+           file://defconfig"
+LOCALVERSION = "-fslc"
diff --git a/recipes-kernel/linux/linux-fslc_3.8.bb b/recipes-kernel/linux/linux-fslc_3.8.bb
index 06f6dfb..68fa8e1 100644
--- a/recipes-kernel/linux/linux-fslc_3.8.bb
+++ b/recipes-kernel/linux/linux-fslc_3.8.bb
@@ -1,15 +1,7 @@
 # Copyright (C) 2012-2013 O.S. Systems Software LTDA.
 # Released under the MIT license (see COPYING.MIT for the terms)
 
-DESCRIPTION = "Linux mainline kernel"
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
-DEPENDS += "lzop-native"
-PROVIDES = "virtual/kernel linux-mainline"
-
-inherit kernel
-
-require recipes-kernel/linux/linux-dtb.inc
+include linux-fslc.inc
 
 PV = "3.8+git${SRCPV}"
 PR = "r5"
@@ -17,19 +9,4 @@ PR = "r5"
 # patches-3.8
 SRCREV = "9674b8d96fca62bc47be48fd857591dcfca874b1"
 
-SRC_URI = "git://github.com/Freescale/linux-mainline.git \
-           \
-           file://defconfig"
-
-S = "${WORKDIR}/git"
-
-do_configure_append () {
-    # Ensure we have a proper GIT hash in kernel version
-    rm ${S}/.scmversion
-}
-
-# We need to pass it as param since kernel might support more then one
-# machine, with different entry points
-EXTRA_OEMAKE += "LOADADDR=${UBOOT_ENTRYPOINT}"
-
 COMPATIBLE_MACHINE = "(mxs|mx3|mx5|mx6)"
diff --git a/recipes-kernel/linux/linux-imx.inc b/recipes-kernel/linux/linux-imx.inc
index 9020f57..6a8eeb8 100644
--- a/recipes-kernel/linux/linux-imx.inc
+++ b/recipes-kernel/linux/linux-imx.inc
@@ -13,6 +13,9 @@ inherit kernel
 LOCALVERSION ?= "+yocto"
 SCMVERSION ?= "y"
 
+# Add imx-test support hacks
+IMX_TEST_SUPPORT ?= "y"
+
 SRC_URI = "git://git.freescale.com/imx/linux-2.6-imx.git \
            file://defconfig \
 "
@@ -51,13 +54,15 @@ do_configure_prepend() {
 
 # install nedded headers for imx-test compilation
 do_install_append() {
-	# bounds.h may be used by a module and is currently missing
-	if [ -d include/generated ]; then
-		cp include/generated/* $kerneldir/include/generated/
-	fi
+	if [ "${IMX_TEST_SUPPORT}" = "y" ]; then
+		# bounds.h may be used by a module and is currently missing
+		if [ -d include/generated ]; then
+			cp include/generated/* $kerneldir/include/generated/
+		fi
 
-	# Host architecture object file
-	rm -f $kerneldir/scripts/kconfig/kxgettext.o
+		# Host architecture object file
+		rm -f $kerneldir/scripts/kconfig/kxgettext.o
+	fi
 }
 
 sysroot_stage_all_append() {
-- 
1.8.1

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Daiane Angolini]

On 04/18/2013 03:59 PM, Otavio Salvador wrote:
> Provides a new linux-fslc.inc file which abstracts the specific
> changes for the linux-fslc based kernels. A new variable has been add
> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
> kernel install as 'imx-test' is not supported for Linux mainline.
>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
I understand what you did, but it's not yet a common place for both 
kernel recipes.

If it is needed for *any* kernel, poky is wrong in not providing this 
for *any* kernel.

If poky is right, we are setting this in the wrong way.

Daiane

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Otavio Salvador]

On Thu, Apr 18, 2013 at 4:51 PM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/18/2013 03:59 PM, Otavio Salvador wrote:
>>
>> Provides a new linux-fslc.inc file which abstracts the specific
>> changes for the linux-fslc based kernels. A new variable has been add
>> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
>> kernel install as 'imx-test' is not supported for Linux mainline.
>>
>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>> ---
>
> I understand what you did, but it's not yet a common place for both kernel
> recipes.
>
> If it is needed for *any* kernel, poky is wrong in not providing this for
> *any* kernel.

Usually kernel would do the right thing but not in our case. Some
entry point are even not in the kernel code from FSL branch.

> If poky is right, we are setting this in the wrong way.

Both seems right. Poky is doing the general assumption, we're doing
what we need specific for the support of the kernels.

--
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: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Fabio Estevam]

On Thu, Apr 18, 2013 at 4:58 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:

> Usually kernel would do the right thing but not in our case. Some

I don't understand. Why 'usually'? In what sense is our case different?

> entry point are even not in the kernel code from FSL branch.

What does it mean?

>
>> If poky is right, we are setting this in the wrong way.
>
> Both seems right. Poky is doing the general assumption, we're doing
> what we need specific for the support of the kernels.

I agree with Daiane here. I am OK with your patch, but I also see it
as workaround.

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Eric Bénard]

Le Thu, 18 Apr 2013 20:46:48 -0300,
Fabio Estevam <festevam@gmail.com> a écrit :

> On Thu, Apr 18, 2013 at 4:58 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
> 
> > Usually kernel would do the right thing but not in our case. Some
> 
> I don't understand. Why 'usually'? In what sense is our case different?
> 
maybe most defconfig support only one machine when those in
meta-fsl-arm support several machines sometimes with different LOADADDR
requirements and thus need the precision to get a working kernel on a
specific platform at compile time.

Eric

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Daiane Angolini]

On 04/18/2013 04:58 PM, Otavio Salvador wrote:
> On Thu, Apr 18, 2013 at 4:51 PM, Daiane Angolini
> <daiane.angolini@freescale.com> wrote:
>> On 04/18/2013 03:59 PM, Otavio Salvador wrote:
>>>
>>> Provides a new linux-fslc.inc file which abstracts the specific
>>> changes for the linux-fslc based kernels. A new variable has been add
>>> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
>>> kernel install as 'imx-test' is not supported for Linux mainline.
>>>
>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>> ---
>>
>> I understand what you did, but it's not yet a common place for both kernel
>> recipes.
>>
>> If it is needed for *any* kernel, poky is wrong in not providing this for
>> *any* kernel.
>
> Usually kernel would do the right thing but not in our case. Some
> entry point are even not in the kernel code from FSL branch.

I would accept this argument if we only faced this problem with FSL kernel.

But, as we faced exactly the same with kernel mainline, I can't accept that.

If kernel mainline is wrong, we must fix it.

Daiane

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Daiane Angolini]

On 04/19/2013 05:03 AM, Eric Bénard wrote:
> Le Thu, 18 Apr 2013 20:46:48 -0300,
> Fabio Estevam <festevam@gmail.com> a écrit :
>
>> On Thu, Apr 18, 2013 at 4:58 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>
>>> Usually kernel would do the right thing but not in our case. Some
>>
>> I don't understand. Why 'usually'? In what sense is our case different?
>>
> maybe most defconfig support only one machine when those in
> meta-fsl-arm support several machines sometimes with different LOADADDR
> requirements and thus need the precision to get a working kernel on a
> specific platform at compile time.

I'm OK to accept the meta-fsl-arm workaround for this LOADADDR error. At 
least until we figure out a better way to properly fix that.

Otavio, what do you think about adding KERNEL_EXTRA_ARGS += 
"LOADADDR=${UBOOT_ENTRYPOINT}" in mxc-base.inc and mxs-base.inc instead?


Daiane

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Otavio Salvador]

On Fri, Apr 19, 2013 at 8:23 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/18/2013 04:58 PM, Otavio Salvador wrote:
>>
>> On Thu, Apr 18, 2013 at 4:51 PM, Daiane Angolini
>> <daiane.angolini@freescale.com> wrote:
>>>
>>> On 04/18/2013 03:59 PM, Otavio Salvador wrote:
>>>>
>>>>
>>>> Provides a new linux-fslc.inc file which abstracts the specific
>>>> changes for the linux-fslc based kernels. A new variable has been add
>>>> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
>>>> kernel install as 'imx-test' is not supported for Linux mainline.
>>>>
>>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>>> ---
>>>
>>>
>>> I understand what you did, but it's not yet a common place for both
>>> kernel
>>> recipes.
>>>
>>> If it is needed for *any* kernel, poky is wrong in not providing this for
>>> *any* kernel.
>>
>>
>> Usually kernel would do the right thing but not in our case. Some
>> entry point are even not in the kernel code from FSL branch.
>
>
> I would accept this argument if we only faced this problem with FSL kernel.
>
> But, as we faced exactly the same with kernel mainline, I can't accept that.
>
> If kernel mainline is wrong, we must fix it.

mainline this is even worse as it is multi SOC vendor so  we do need to pass it.

Eric is right and if you check FSL kernel, it doesn't know the MX6SL
entry point in the makefile, for example.

--
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: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Otavio Salvador]

On Fri, Apr 19, 2013 at 8:26 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/19/2013 05:03 AM, Eric Bénard wrote:
>>
>> Le Thu, 18 Apr 2013 20:46:48 -0300,
>> Fabio Estevam <festevam@gmail.com> a écrit :
>>
>>> On Thu, Apr 18, 2013 at 4:58 PM, Otavio Salvador
>>> <otavio@ossystems.com.br> wrote:
>>>
>>>> Usually kernel would do the right thing but not in our case. Some
>>>
>>>
>>> I don't understand. Why 'usually'? In what sense is our case different?
>>>
>> maybe most defconfig support only one machine when those in
>> meta-fsl-arm support several machines sometimes with different LOADADDR
>> requirements and thus need the precision to get a working kernel on a
>> specific platform at compile time.
>
>
> I'm OK to accept the meta-fsl-arm workaround for this LOADADDR error. At
> least until we figure out a better way to properly fix that.
>
> Otavio, what do you think about adding KERNEL_EXTRA_ARGS +=
> "LOADADDR=${UBOOT_ENTRYPOINT}" in mxc-base.inc and mxs-base.inc instead?

This is even worse IMO as we'd be changing something without being
clear we're doing. This would just make it harder to understand IMO.

--
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: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Eric Bénard]

Hi Daiane,

Le Fri, 19 Apr 2013 08:23:27 -0300,
Daiane Angolini <daiane.angolini@freescale.com> a écrit :

> On 04/18/2013 04:58 PM, Otavio Salvador wrote:
> > On Thu, Apr 18, 2013 at 4:51 PM, Daiane Angolini
> > <daiane.angolini@freescale.com> wrote:
> >> On 04/18/2013 03:59 PM, Otavio Salvador wrote:
> >>>
> >>> Provides a new linux-fslc.inc file which abstracts the specific
> >>> changes for the linux-fslc based kernels. A new variable has been add
> >>> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
> >>> kernel install as 'imx-test' is not supported for Linux mainline.
> >>>
> >>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> >>> ---
> >>
> >> I understand what you did, but it's not yet a common place for both kernel
> >> recipes.
> >>
> >> If it is needed for *any* kernel, poky is wrong in not providing this for
> >> *any* kernel.
> >
> > Usually kernel would do the right thing but not in our case. Some
> > entry point are even not in the kernel code from FSL branch.
> 
> I would accept this argument if we only faced this problem with FSL kernel.
> 
> But, as we faced exactly the same with kernel mainline, I can't accept that.
> 
> If kernel mainline is wrong, we must fix it.
> 
when compiling manually a mainline kernel out of OE, you may have to do
the same thing if the .config includes several platforms which have a
different LOADADDR (example : i.MX51 where RAM is at 0x90000000 and
i.MX53 where it is at 0x70000000). That's not a bug that's the
consequence of having different architectures enabled at the same time
in the same defconfig.

Eric

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Fabio Estevam]

On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:

> maybe most defconfig support only one machine when those in
> meta-fsl-arm support several machines sometimes with different LOADADDR
> requirements and thus need the precision to get a working kernel on a
> specific platform at compile time.

Sure, understood. So if we always build uImage as "make uImage
LOADADDR=0xxxxx" then it will always work. No matter if you are in a
single machine defconfig or on a multiple machine defconfig.

What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
our layer. Why can't poke just always pass
LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
then it does the usual "make uImage" method.

We could call it OUR_UBOOT_ENTRYPOINT instead and use this
OUR_UBOOT_ENTRYPOINT in our layer, no?

Or maybe in the next release we could just switch to zImage and no
need to worry about such things ;-)

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Daiane Angolini]

On 04/19/2013 09:10 AM, Eric Bénard wrote:
> Hi Daiane,
>
> Le Fri, 19 Apr 2013 08:23:27 -0300,
> Daiane Angolini <daiane.angolini@freescale.com> a écrit :
>
>> On 04/18/2013 04:58 PM, Otavio Salvador wrote:
>>> On Thu, Apr 18, 2013 at 4:51 PM, Daiane Angolini
>>> <daiane.angolini@freescale.com> wrote:
>>>> On 04/18/2013 03:59 PM, Otavio Salvador wrote:
>>>>>
>>>>> Provides a new linux-fslc.inc file which abstracts the specific
>>>>> changes for the linux-fslc based kernels. A new variable has been add
>>>>> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
>>>>> kernel install as 'imx-test' is not supported for Linux mainline.
>>>>>
>>>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>>>> ---
>>>>
>>>> I understand what you did, but it's not yet a common place for both kernel
>>>> recipes.
>>>>
>>>> If it is needed for *any* kernel, poky is wrong in not providing this for
>>>> *any* kernel.
>>>
>>> Usually kernel would do the right thing but not in our case. Some
>>> entry point are even not in the kernel code from FSL branch.
>>
>> I would accept this argument if we only faced this problem with FSL kernel.
>>
>> But, as we faced exactly the same with kernel mainline, I can't accept that.
>>
>> If kernel mainline is wrong, we must fix it.
>>
> when compiling manually a mainline kernel out of OE, you may have to do
> the same thing if the .config includes several platforms which have a
> different LOADADDR (example : i.MX51 where RAM is at 0x90000000 and
> i.MX53 where it is at 0x70000000). That's not a bug that's the
> consequence of having different architectures enabled at the same time
> in the same defconfig.

Which only ensure that FSL kernel is not wrong the same way mainline is 
not wrong.



-- 
Daiane

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Eric Bénard]

Hi Fabio,

Le Fri, 19 Apr 2013 09:26:30 -0300,
Fabio Estevam <festevam@gmail.com> a écrit :

> On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:
> 
> > maybe most defconfig support only one machine when those in
> > meta-fsl-arm support several machines sometimes with different LOADADDR
> > requirements and thus need the precision to get a working kernel on a
> > specific platform at compile time.
> 
> Sure, understood. So if we always build uImage as "make uImage
> LOADADDR=0xxxxx" then it will always work. No matter if you are in a
> single machine defconfig or on a multiple machine defconfig.
> 
> What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
> poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
> our layer. Why can't poke just always pass
> LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
> then it does the usual "make uImage" method.
> 
because if you look at kernel.bbclass, it's only using
UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
in 
do_uboot_mkimage() {}
which is executed once the kernel is compiled :
addtask uboot_mkimage before do_install after do_compile

So the uImage is generated once the kernel is compiled (without using
make uImage).

So the LOADADDR need is specific to some platforms and not generic
at the oe-core level.

Eric

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Daiane Angolini]

On 04/19/2013 09:26 AM, Fabio Estevam wrote:
> On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:
>
>> maybe most defconfig support only one machine when those in
>> meta-fsl-arm support several machines sometimes with different LOADADDR
>> requirements and thus need the precision to get a working kernel on a
>> specific platform at compile time.
>
> Sure, understood. So if we always build uImage as "make uImage
> LOADADDR=0xxxxx" then it will always work. No matter if you are in a
> single machine defconfig or on a multiple machine defconfig.
>
> What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
> poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
> our layer. Why can't poke just always pass
> LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
> then it does the usual "make uImage" method.
>
> We could call it OUR_UBOOT_ENTRYPOINT instead and use this
> OUR_UBOOT_ENTRYPOINT in our layer, no?

Thanks Fabio.

I make your words mine.

-- 
Daiane

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Otavio Salvador]

On Fri, Apr 19, 2013 at 9:26 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:
>
>> maybe most defconfig support only one machine when those in
>> meta-fsl-arm support several machines sometimes with different LOADADDR
>> requirements and thus need the precision to get a working kernel on a
>> specific platform at compile time.
>
> Sure, understood. So if we always build uImage as "make uImage
> LOADADDR=0xxxxx" then it will always work. No matter if you are in a
> single machine defconfig or on a multiple machine defconfig.
>
> What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
> poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
> our layer. Why can't poke just always pass
> LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
> then it does the usual "make uImage" method.

It'd not be need if we had KEEPUIMAGE as 'no' Yocto would generate it
without the workaround but we'd end generation two images.

> We could call it OUR_UBOOT_ENTRYPOINT instead and use this
> OUR_UBOOT_ENTRYPOINT in our layer, no?
>
> Or maybe in the next release we could just switch to zImage and no
> need to worry about such things ;-)

Yes, this would be an option as well ;-)

--
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: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Daiane Angolini]

On 04/19/2013 09:36 AM, Eric Bénard wrote:
> Hi Fabio,
>
> Le Fri, 19 Apr 2013 09:26:30 -0300,
> Fabio Estevam <festevam@gmail.com> a écrit :
>
>> On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:
>>
>>> maybe most defconfig support only one machine when those in
>>> meta-fsl-arm support several machines sometimes with different LOADADDR
>>> requirements and thus need the precision to get a working kernel on a
>>> specific platform at compile time.
>>
>> Sure, understood. So if we always build uImage as "make uImage
>> LOADADDR=0xxxxx" then it will always work. No matter if you are in a
>> single machine defconfig or on a multiple machine defconfig.
>>
>> What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
>> poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
>> our layer. Why can't poke just always pass
>> LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
>> then it does the usual "make uImage" method.
>>
> because if you look at kernel.bbclass, it's only using
> UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
> in
> do_uboot_mkimage() {}
> which is executed once the kernel is compiled :
> addtask uboot_mkimage before do_install after do_compile
>

And, if you follow what happens when our kernel is built, you will see 
that uboot_mkimage is never called


Daiane

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Otavio Salvador]

On Fri, Apr 19, 2013 at 9:38 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/19/2013 09:36 AM, Eric Bénard wrote:
>>
>> Hi Fabio,
>>
>> Le Fri, 19 Apr 2013 09:26:30 -0300,
>> Fabio Estevam <festevam@gmail.com> a écrit :
>>
>>> On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:
>>>
>>>> maybe most defconfig support only one machine when those in
>>>> meta-fsl-arm support several machines sometimes with different LOADADDR
>>>> requirements and thus need the precision to get a working kernel on a
>>>> specific platform at compile time.
>>>
>>>
>>> Sure, understood. So if we always build uImage as "make uImage
>>> LOADADDR=0xxxxx" then it will always work. No matter if you are in a
>>> single machine defconfig or on a multiple machine defconfig.
>>>
>>> What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
>>> poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
>>> our layer. Why can't poke just always pass
>>> LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
>>> then it does the usual "make uImage" method.
>>>
>> because if you look at kernel.bbclass, it's only using
>> UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
>> in
>> do_uboot_mkimage() {}
>> which is executed once the kernel is compiled :
>> addtask uboot_mkimage before do_install after do_compile
>>
>
> And, if you follow what happens when our kernel is built, you will see that
> uboot_mkimage is never called

As I said, because KEEPUIMAGE is 'yes' so it is supposed to keep the
uImage generated during kernel build.

--
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: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Daiane Angolini]

On 04/19/2013 09:41 AM, Otavio Salvador wrote:

> As I said, because KEEPUIMAGE is 'yes' so it is supposed to keep the
> uImage generated during kernel build.


So, I think the conclusion is that the patch was ACKED.


Daiane

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Otavio Salvador]

On Fri, Apr 19, 2013 at 10:25 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/19/2013 09:41 AM, Otavio Salvador wrote:
>
>> As I said, because KEEPUIMAGE is 'yes' so it is supposed to keep the
>> uImage generated during kernel build.
>
>
>
> So, I think the conclusion is that the patch was ACKED.

Applied.

--
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: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Daiane Angolini]

On 04/19/2013 10:33 AM, Otavio Salvador wrote:
> On Fri, Apr 19, 2013 at 10:25 AM, Daiane Angolini
> <daiane.angolini@freescale.com> wrote:
>> On 04/19/2013 09:41 AM, Otavio Salvador wrote:
>>
>>> As I said, because KEEPUIMAGE is 'yes' so it is supposed to keep the
>>> uImage generated during kernel build.
>>
>>
>>
>> So, I think the conclusion is that the patch was ACKED.
>
> Applied.

now imx6slevk kernel is loaded. (board is booting now)


Daiane

Re: [meta-fsl-arm PATCH v2 3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

[Otavio Salvador]

On Fri, Apr 19, 2013 at 10:45 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/19/2013 10:33 AM, Otavio Salvador wrote:
>>
>> On Fri, Apr 19, 2013 at 10:25 AM, Daiane Angolini
>> <daiane.angolini@freescale.com> wrote:
>>>
>>> On 04/19/2013 09:41 AM, Otavio Salvador wrote:
>>>
>>>> As I said, because KEEPUIMAGE is 'yes' so it is supposed to keep the
>>>> uImage generated during kernel build.
>>>
>>>
>>>
>>>
>>> So, I think the conclusion is that the patch was ACKED.
>>
>>
>> Applied.
>
>
> now imx6slevk kernel is loaded. (board is booting now)

Finally! :-D

\m/

--
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