Hi Otavio,
On 09/19/2012 04:51 PM, Otavio Salvador wrote:
On Wed, Sep 19, 2012 at 8:40 PM, Eric Nelson
<eric.nel...@boundarydevices.com> wrote:
On 09/19/2012 11:22 AM, Otavio Salvador wrote:
On Wed, Sep 19, 2012 at 3:08 PM, Robert Nelson<robertcnel...@gmail.com>
wrote:
On Wed, Sep 19, 2012 at 1:00 PM, Otavio Salvador
<ota...@ossystems.com.br> wrote:
On Wed, Sep 19, 2012 at 2:57 PM, Robert Nelson<robertcnel...@gmail.com>
wrote:
On Wed, Sep 19, 2012 at 10:13 AM, Otavio Salvador
<ota...@ossystems.com.br> wrote:
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.
Signed-off-by: Otavio Salvador<ota...@ossystems.com.br>
---
include/configs/mx6qsabrelite.h | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/configs/mx6qsabrelite.h
b/include/configs/mx6qsabrelite.h
index 72d0154..0d5fd40 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -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.
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.
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.
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
