Hello Hans,
Op 08-06-15 om 15:16 schreef Hans de Goede:
Hi Roy,
On 08-06-15 10:38, Roy Spliet wrote:
Hello Michal,
Op 07-06-15 om 18:48 schreef Michal Suchanek:
Hello,
On 5 June 2015 at 13:52, Roy Spliet <r.spl...@ultimaker.com> wrote:
Based on the default layout of the android image used at least on
Olimex Lime
Signed-off-by: Roy Spliet <r.spl...@ultimaker.com>
---
include/configs/sunxi-common.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/configs/sunxi-common.h
b/include/configs/sunxi-common.h
index ec28c40..b38f2f5 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
#define BOOT_TARGET_DEVICES_USB(func)
#endif
+#ifdef CONFIG_NAND
+#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
+#else
+#define BOOT_TARGET_DEVICES_NAND(func)
+#endif
+
#define BOOT_TARGET_DEVICES(func) \
BOOT_TARGET_DEVICES_MMC(func) \
+ BOOT_TARGET_DEVICES_NAND(func) \
BOOT_TARGET_DEVICES_SCSI(func) \
BOOT_TARGET_DEVICES_USB(func) \
func(PXE, pxe, na) \
@@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
MEM_LAYOUT_ENV_SETTINGS \
"fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
"console=ttyS0,115200\0" \
+ "mtdids=nand0=mtd2\0" \
+ "mtdparts=mtdparts=mtd2:0xffc00000@0x400000(nand0_main)\0" \
BOOTENV
From what I heard the nand boot partition size should be specified in
nand pages rather than bytes because the boot rom loads a fixed number
of pages and just uses the start of each page regardless of page size.
Although I believe you have the facts mostly right, they do not apply
in this situation.
What you are looking for is the partition definition for U-boot. At
this point the boot
rom (BROM) is no longer active and thus it's inner workings are
mostly irrelevant.
The NAND partition lay-out for the boards I have seen (various Olimex
+ Cubietruck..)
are as follows:
0-2MB U-Boot-SPL + U-Boot
2-4MB U-Boot SPL + U-Boot (for recovery)
4MB+ Main file system
The mtdparts env variable defines only the main file system because
that's the only
place with relevant files for U-Boot.
This said: I have replaced the default file system with a "custom"
UBI FS containing
just a boot and a rootfs partition. I am unsure whether these
defaults apply for the
Android image that ships with the Olimex boards. But then again: that
image also
ships with a boot-loader, so do we care?
I did not find any document regarding the nand boot partition layout
so I would like to see some input from somebody familiar with the
driver.
While it is fine for testing to hand-edit the environment the final
nand support should have
1) way to express the boot partition size in nand pages
2) way to make the main partition start at the end of boot partition
and extend to the end of the flash
This should probably also go to Linux.
Linux can define partitions in the device tree. I'd prefer to carry
this approach to U-boot,
but current U-Boot has the partitioning part of the MTD code hacked
away and replaced by
custom mtdparts code without OF support. Doing this proper requires
getting rid of the
latter, which will likely break a lot of legacy. So as far as I
agree, I have to warn that is
a longer-term project, extended further by the ongoing (justified)
discussion we are having
regarding the MTD partitioning code in upstream Linux that may or may
not lead to parts
of the framework being re-architected.
Last time I discussed this with some kernel people, they pointed me to
the fact that
the kernel actually parses partition info provided by u-boot through
the u-boot mtdparts
command, and that that is the preferred way to pass partition info to
the kernel, so rather
then adding dts partition info to u-boot we would need to teach the
existing kernel mtdpart
code to deal with separate ecc / random setting and maybe use a list
of hardcoded
partitition names for which to use the brom compatible settings. These
are all things
which we need to figure out on the kernel side, it would be good to
get a discussion
started on this with the kernel mtd people.
I am unaware of the kernel developers' preferences, but [1] shows that
the kernel
gained OF (DTS) partition parsing in 2008. We do need to teach the
kernel (and U-Boot)
the trick of parsing mtd partitions, but with ARM/Linaro pushing DTS as
the preferred way
to describe hardware we might have to consider this a separate
discussion point.
Note that we will also need to have a u-boot env partition somewhare
either at the
nandpart level, or as a ubi volume, assuming the u-boot env code can
deal with
ubi volumes (we are in the full u-boot environment when reading the env.)
Thanks, this is a relevant addition and something that needs investigation.
Unfortunately I can probably not pull this wagon too much further, given
I am about to continue my career in academics starting next month. I'd
be happy to
think along and start the discussion, but I might not be around long
enough to work
much on the implementation.
Yours,
Roy
Regards,
Hans
Roy
Thanks
Michal
--
IMAGINE IT >> MAKE IT
Meet us online at Twitter <http://twitter.com/ultimaker>, Facebook
<http://facebook.com/ultimaker>, Google+ <http://google.com/+Ultimaker>
www.ultimaker.com
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
