Skip to contentSkip to conversation

mx53loco: Change default environment to cope with OE changes

PATCH Superseded Otavio Salvador 3 participants 13 messages Sep 19, 2012 – Sep 20, 2012

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/3 mx53loco: Change default environment to cope with OE changes

OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot.

---
 include/configs/mx53loco.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
include/configs/mx53loco.h +2 -2
index 8cbaf08..fcd6b44 100644
@@ -120,8 +120,8 @@
 	"script=boot.scr\0" \
 	"uimage=uImage\0" \
 	"mmcdev=0\0" \
-	"mmcpart=2\0" \
-	"mmcroot=/dev/mmcblk0p3 rw\0" \
+	"mmcpart=1\0" \
+	"mmcroot=/dev/mmcblk0p2 rw\0" \
 	"mmcrootfstype=ext3 rootwait\0" \
 	"mmcargs=setenv bootargs console=ttymxc0,${baudrate} " \
 		"root=${mmcroot} " \
Signature · 1 line
1.7.10.4
#1 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot.

---
 include/configs/mx6qsabrelite.h |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
include/configs/mx6qsabrelite.h +3 -5
index 72d0154..0d5fd40 100644
@@ -141,12 +141,10 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
        "script=boot.scr\0" \
        "uimage=uImage\0" \
-	"console=ttymxc1\0" \
-	"fdt_high=0xffffffff\0"	  \
-	"initrd_high=0xffffffff\0" \
+       "console=ttymxc1\0" \
        "mmcdev=0\0" \
-       "mmcpart=2\0" \
-       "mmcroot=/dev/mmcblk0p3 rootwait rw\0" \
+       "mmcpart=1\0" \
+       "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
        "mmcargs=setenv bootargs console=${console},${baudrate} " \
 	       "root=${mmcroot}\0" \
        "loadbootscript=" \
Signature · 1 line
1.7.10.4
#2 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

Quoted 14 lines · Otavio Salvador

OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot.

---
 include/configs/mx6qsabrelite.h |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
include/configs/mx6qsabrelite.h +0 -0
index 72d0154..0d5fd40 100644

include/configs/mx6qsabrelite.h line 146

Quoted 6 lines
include/configs/mx6qsabrelite.h +0 -3
@@ -141,12 +141,10 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
        "script=boot.scr\0" \
        "uimage=uImage\0" \
-       "console=ttymxc1\0" \
-       "fdt_high=0xffffffff\0"   \
-       "initrd_high=0xffffffff\0" \

Your going to need fdt_high/initrd_high for when using linux device tree's...

Regards,

Signature · 2 lines
Robert Nelson
http://www.rcn-ee.com/
#3 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

Quoted 11 lines · Robert Nelson
Quoted 9 lines · Otavio Salvador

OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot.

---
 include/configs/mx6qsabrelite.h |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
Quoted 13 lines

include/configs/mx6qsabrelite.h line 146

Quoted 11 lines
include/configs/mx6qsabrelite.h +0 -3
index 72d0154..0d5fd40 100644
@@ -141,12 +141,10 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
        "script=boot.scr\0" \
        "uimage=uImage\0" \
-       "console=ttymxc1\0" \
-       "fdt_high=0xffffffff\0"   \
-       "initrd_high=0xffffffff\0" \

Your going to need fdt_high/initrd_high for when using linux device tree's...

I am not against keeping it but it is not used right now.

Fabio, do you prefer me to keep it or remove?

Signature · 3 lines
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
#4 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

Quoted 26 lines · Otavio Salvador
Quoted 11 lines · Robert Nelson
Quoted 9 lines · Otavio Salvador

OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot.

---
 include/configs/mx6qsabrelite.h |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
Quoted 13 lines

include/configs/mx6qsabrelite.h line 146

Quoted 11 lines
include/configs/mx6qsabrelite.h +0 -3
index 72d0154..0d5fd40 100644
@@ -141,12 +141,10 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
        "script=boot.scr\0" \
        "uimage=uImage\0" \
-       "console=ttymxc1\0" \
-       "fdt_high=0xffffffff\0"   \
-       "initrd_high=0xffffffff\0" \

Your going to need fdt_high/initrd_high for when using linux device tree's...

Quoted 1 line

I am not against keeping it but it is not used right now.

It may not be used in openembedded, but device tree is the only option for a pure mainline kernel for this board, so it's needed. ;)

Regards,

Signature · 2 lines
Robert Nelson
http://www.rcn-ee.com/
#5 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

Quoted 28 lines · Robert Nelson
Quoted 26 lines · Otavio Salvador
Quoted 24 lines · Robert Nelson
Quoted 14 lines · Otavio Salvador

OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot.

---
 include/configs/mx6qsabrelite.h |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
include/configs/mx6qsabrelite.h +0 -0
index 72d0154..0d5fd40 100644

include/configs/mx6qsabrelite.h line 146

Quoted 6 lines
include/configs/mx6qsabrelite.h +0 -3
@@ -141,12 +141,10 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
        "script=boot.scr\0" \
        "uimage=uImage\0" \
-       "console=ttymxc1\0" \
-       "fdt_high=0xffffffff\0"   \
-       "initrd_high=0xffffffff\0" \

Your going to need fdt_high/initrd_high for when using linux device tree's...

Quoted 4 lines
Quoted 1 line

I am not against keeping it but it is not used right now.

It may not be used in openembedded, but device tree is the only option for a pure mainline kernel for this board, so it's needed. ;)

No problem, I can rebase and remove this change.

Signature · 3 lines
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
#6 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

Quoted 29 lines · Otavio Salvador
Quoted 28 lines · Robert Nelson
Quoted 26 lines · Otavio Salvador
Quoted 24 lines · Robert Nelson
Quoted 14 lines · Otavio Salvador

OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot.

---
  include/configs/mx6qsabrelite.h |    8 +++-----
  1 file changed, 3 insertions(+), 5 deletions(-)
include/configs/mx6qsabrelite.h +0 -0
index 72d0154..0d5fd40 100644

include/configs/mx6qsabrelite.h line 146

Quoted 6 lines
include/configs/mx6qsabrelite.h +0 -3
@@ -141,12 +141,10 @@
  #define CONFIG_EXTRA_ENV_SETTINGS \
         "script=boot.scr\0" \
         "uimage=uImage\0" \
-       "console=ttymxc1\0" \
-       "fdt_high=0xffffffff\0"   \
-       "initrd_high=0xffffffff\0" \

Your going to need fdt_high/initrd_high for when using linux device tree's...

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

I am not against keeping it but it is not used right now.

It may not be used in openembedded, but device tree is the only option for a pure mainline kernel for this board, so it's needed. ;)

No problem, I can rebase and remove this change.

Hi Otavio,

It seems that this path of trying to configure the "right" set of default options seems like a bit of a goose chase.

Isn't using 'mkenvimage' in OE a better route? That way, the environment can change with the userspace decision.

Regards,

Eric

#7 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

Quoted 48 lines · Eric Nelson
Quoted 47 lines · Otavio Salvador
Quoted 42 lines · Robert Nelson
Quoted 34 lines · Otavio Salvador
Quoted 13 lines · Robert Nelson
Quoted 10 lines · Otavio Salvador

OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot.

---
  include/configs/mx6qsabrelite.h |    8 +++-----
  1 file changed, 3 insertions(+), 5 deletions(-)
Quoted 16 lines

include/configs/mx6qsabrelite.h line 146

Quoted 12 lines
include/configs/mx6qsabrelite.h +0 -3
index 72d0154..0d5fd40 100644
@@ -141,12 +141,10 @@
  #define CONFIG_EXTRA_ENV_SETTINGS \
         "script=boot.scr\0" \
         "uimage=uImage\0" \
-       "console=ttymxc1\0" \
-       "fdt_high=0xffffffff\0"   \
-       "initrd_high=0xffffffff\0" \

Your going to need fdt_high/initrd_high for when using linux device tree's...

Quoted 1 line

I am not against keeping it but it is not used right now.

It may not be used in openembedded, but device tree is the only option for a pure mainline kernel for this board, so it's needed. ;)

Quoted 7 lines
Quoted 2 lines

No problem, I can rebase and remove this change.

Hi Otavio,

It seems that this path of trying to configure the "right" set of default options seems like a bit of a goose chase.

I sort of agree; do you use 2 or 3 partitions in this case?

Quoted 2 lines

Isn't using 'mkenvimage' in OE a better route? That way, the environment can change with the userspace decision.

In fact in OE we have a patch for it. Usually we don't call mkenvimage for it but I like the idea to add this feature there later.

Signature · 3 lines
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
#8 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

Hi Otavio,

Quoted 53 lines · Otavio Salvador
Quoted 51 lines · Eric Nelson
Quoted 49 lines · Otavio Salvador
Quoted 37 lines · Robert Nelson
Quoted 34 lines · Otavio Salvador
Quoted 29 lines · Robert Nelson
Quoted 16 lines · Otavio Salvador

OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot.

---
   include/configs/mx6qsabrelite.h |    8 +++-----
   1 file changed, 3 insertions(+), 5 deletions(-)
include/configs/mx6qsabrelite.h +0 -0
index 72d0154..0d5fd40 100644

include/configs/mx6qsabrelite.h line 146

Quoted 6 lines
include/configs/mx6qsabrelite.h +0 -3
@@ -141,12 +141,10 @@
   #define CONFIG_EXTRA_ENV_SETTINGS \
          "script=boot.scr\0" \
          "uimage=uImage\0" \
-       "console=ttymxc1\0" \
-       "fdt_high=0xffffffff\0"   \
-       "initrd_high=0xffffffff\0" \

Your going to need fdt_high/initrd_high for when using linux device tree's...

Quoted 5 lines
Quoted 1 line

I am not against keeping it but it is not used right now.

It may not be used in openembedded, but device tree is the only option for a pure mainline kernel for this board, so it's needed. ;)

No problem, I can rebase and remove this change.

Quoted 7 lines
Quoted 4 lines

Hi Otavio,

It seems that this path of trying to configure the "right" set of default options seems like a bit of a goose chase.

I sort of agree; do you use 2 or 3 partitions in this case?

Or 1 or 9?

I'm actually not kidding here. The current Freescale Android image (R13.4-Beta) actually does want 9 partitions for a bunch of stuff like a 'recovery' partition, a 'vendor' partition, etc.

Or even 0? Windows users have been known to use SD cards straight out of the box with no partition table.

In short, this is something that can't be solved in the general case, so I think it's best for the main-line U-Boot code to not try and provide policy, only functionality.

To that end, we've tried to standardize on something simple: the presence of a file named '6q_bootscript' on one of the SD cards that can handle these sorts of userspace details:
http://boundarydevices.com/u-boot-conventions-for-i-mx6-nitrogen6x-and-sabrelite/

This allows all of the userspace bits to go into the userspace filesystem, but still allows machine-specific like the type of display connected to be saved in the environment.

Using this approach, you can load kernel(s) or RAM disks from anywhere that U-Boot can reach without re-compiling U-Boot.

Quoted 6 lines
Quoted 2 lines

Isn't using 'mkenvimage' in OE a better route? That way, the environment can change with the userspace decision.

In fact in OE we have a patch for it. Usually we don't call mkenvimage for it but I like the idea to add this feature there later.

The best part of doing it in OE is that the same commit should be able to update both the environment variables (or boot script) and the parts which depend on it (like creation of the filesystem image(s)).

Regards,

Eric

#9 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

Quoted 10 lines · Eric Nelson
Quoted 2 lines · Otavio Salvador

I sort of agree; do you use 2 or 3 partitions in this case?

Or 1 or 9?

I'm actually not kidding here. The current Freescale Android image (R13.4-Beta) actually does want 9 partitions for a bunch of stuff like a 'recovery' partition, a 'vendor' partition, etc.

Quoted 6 lines

Or even 0? Windows users have been known to use SD cards straight out of the box with no partition table.

In short, this is something that can't be solved in the general case, so I think it's best for the main-line U-Boot code to not try and provide policy, only functionality.

I agree; but mainline could have defaults that works at least for usual U-Boot hacker. That's why I asked how many you use.

Quoted 4 lines

To that end, we've tried to standardize on something simple: the presence of a file named '6q_bootscript' on one of the SD cards that can handle these sorts of userspace details:

Quoted 8 lines

http://boundarydevices.com/u-boot-conventions-for-i-mx6-nitrogen6x-and-sabrelite/

This allows all of the userspace bits to go into the userspace filesystem, but still allows machine-specific like the type of display connected to be saved in the environment.

Using this approach, you can load kernel(s) or RAM disks from anywhere that U-Boot can reach without re-compiling U-Boot.

This is indeed nice.

Quoted 10 lines
Quoted 6 lines
Quoted 3 lines

Isn't using 'mkenvimage' in OE a better route? That way, the environment can
change with the userspace decision.

In fact in OE we have a patch for it. Usually we don't call mkenvimage for it but I like the idea to add this feature there later.

The best part of doing it in OE is that the same commit should be able to update both the environment variables (or boot script) and the parts which depend on it (like creation of the filesystem image(s)).

Yes; I will work in a generic way for it in OE ... I like the idea and also see the added value for the flexibility.

After MX23 I will focus on this ;-) (or Marek kills me :P)

This doesn't solve the question:

Better to have 2 or 3 partition layout by default in mainline?

Signature · 3 lines
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
#10 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

Hi Octavio,

Quoted 48 lines · Otavio Salvador
Quoted 10 lines · Eric Nelson
Quoted 2 lines · Otavio Salvador

I sort of agree; do you use 2 or 3 partitions in this case?

Or 1 or 9?

I'm actually not kidding here. The current Freescale Android image (R13.4-Beta) actually does want 9 partitions for a bunch of stuff like a 'recovery' partition, a 'vendor' partition, etc.

Quoted 6 lines

Or even 0? Windows users have been known to use SD cards straight out of the box with no partition table.

In short, this is something that can't be solved in the general case, so I think it's best for the main-line U-Boot code to not try and provide policy, only functionality.

I agree; but mainline could have defaults that works at least for usual U-Boot hacker. That's why I asked how many you use.

Quoted 4 lines

To that end, we've tried to standardize on something simple: the presence of a file named '6q_bootscript' on one of the SD cards that can handle these sorts of userspace details:

Quoted 8 lines

http://boundarydevices.com/u-boot-conventions-for-i-mx6-nitrogen6x-and-sabrelite/

This allows all of the userspace bits to go into the userspace filesystem, but still allows machine-specific like the type of display connected to be saved in the environment.

Using this approach, you can load kernel(s) or RAM disks from anywhere that U-Boot can reach without re-compiling U-Boot.

This is indeed nice.

Quoted 10 lines
Quoted 6 lines
Quoted 3 lines

Isn't using 'mkenvimage' in OE a better route? That way, the environment can
change with the userspace decision.

In fact in OE we have a patch for it. Usually we don't call mkenvimage for it but I like the idea to add this feature there later.

The best part of doing it in OE is that the same commit should be able to update both the environment variables (or boot script) and the parts which depend on it (like creation of the filesystem image(s)).

Quoted 9 lines

Yes; I will work in a generic way for it in OE ... I like the idea and also see the added value for the flexibility.

After MX23 I will focus on this ;-) (or Marek kills me :P)

This doesn't solve the question:

Better to have 2 or 3 partition layout by default in mainline?

I suspect that this question isn't for me, since I'm not sure which userspace(s) we're targeting.

Heck, I didn't know that OE was still kicking... I kinda had the impression that Yocto had taken it over ;)

Regards,

Eric

#11 lore raw

PATCH 2/3 mx6qsabrelite: Change default environment to cope with OE changes

Quoted 15 lines · Eric Nelson
Quoted 14 lines · Otavio Salvador
Quoted 4 lines · Eric Nelson

The best part of doing it in OE is that the same commit should be able to update both the environment variables (or boot script) and the parts which depend
on it (like creation of the filesystem image(s)).

Yes; I will work in a generic way for it in OE ... I like the idea and also see the added value for the flexibility.

After MX23 I will focus on this ;-) (or Marek kills me :P)

This doesn't solve the question:

Quoted 8 lines
Quoted 2 lines

Better to have 2 or 3 partition layout by default in mainline?

I suspect that this question isn't for me, since I'm not sure which userspace(s) we're targeting.

Heck, I didn't know that OE was still kicking... I kinda had the impression that Yocto had taken it over ;)

Yocto is an unbrealla project which has OE-Core and bitbake plus meta-yocto merged in Poky. The markering is all done for Yocto but OE is live there ;-)

Signature · 3 lines
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
#12 lore raw

PATCH 3/3 mx6qsabresd: Change default environment to cope with OE changes

In reply to Otavio Salvador

OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot.

---
 include/configs/mx6qsabresd.h |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)
include/configs/mx6qsabresd.h +2 -4
index 448ce28..793427a 100644
@@ -74,11 +74,9 @@
 	"script=boot.scr\0" \
 	"uimage=uImage\0" \
 	"console=ttymxc0\0" \
-	"fdt_high=0xffffffff\0"	  \
-	"initrd_high=0xffffffff\0" \
 	"mmcdev=0\0" \
-	"mmcpart=2\0" \
-	"mmcroot=/dev/mmcblk0p3 rootwait rw\0" \
+	"mmcpart=1\0" \
+	"mmcroot=/dev/mmcblk1p2 rootwait rw\0" \
 	"mmcargs=setenv bootargs console=${console},${baudrate} " \
 		"root=${mmcroot}\0" \
 	"loadbootscript=" \
Signature · 1 line
1.7.10.4