Hello Yassin,
Op 08-06-15 om 12:48 schreef Yassin:
Hi Roy
Thank you for working on this, I would like to suggest if you could implement
separate control commands to switch ECC and Randomisation modes per partitions.
I know this is not the best approach but it will provide more controls.
Thanks for the suggestion. However, for now I do not see the immediate
need for this in U-boot. U-boot should really only care about one thing:
load Linux. Therefore, the only partition it needs to be able to read is
whatever partition is used for storing boot data on. And if we only care
about one NAND partition, we don't need per-partition settings.
I agree that it would be nice to have eventually, but I think this
problem first needs to be solved in Linux properly. Then in U-boot we
can sync MTD up with Linux and we get the support we need "for free".
I'd personally recommend to take this approach over now first hacking up
all sorts of new commands in U-boot, as the latter will create more
problems with syncing up MTD and doing the right thing on the longer run.
Yours,
Roy
On 8 Jun 2015, at 7:11 pm, Roy Spliet <r.spl...@ultimaker.com> wrote:
Dear Michal,
Op 08-06-15 om 10:54 schreef Michal Suchanek:
On 8 June 2015 at 10:38, Roy Spliet <r.spl...@ultimaker.com> 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
OK, so 0-2 MB has to be read (at least in part) by brom to load the
SPL so it must be in the format brom understands. The part containing
the SPL which is read by brom has certain number of pages. The u-boot
part can contain whatever we define.
2-4MB U-Boot SPL + U-Boot (for recovery)
4MB+ Main file system
The main filesystem has to be in format suitable for UBIFS. It has to
follow u-boot part possibly with some space in between.
If support for non-uniform flash format is not available then there
are basically two options:
1) SPL supports brom format and u-boot binary is part of boot
partition. SPL can read/write itself and u-boot and u-boot can
read/write the main partition
2) SPL and u-boot support the main partition format. While u-boot is
written to the boot partition its pages are written in the format
suitable for ubifs. This will get hairy when you want to actually
write u-boot and SPL.
The problem with counting the partition sizes in bytes is obvious -
whatever you do the brom reads predefined number of pages from the
start of the nand to load the SPL and unless you know maximum page
size of every nand ever made that is compatible with Allwinner brom
you cannot tell what is even the maximum size of this part in bytes.]
The solution already implemented now and carried to Hans' tree is 1)
with the size of SPL aligned to 8KB blocks (the largest of the page sizes
attempted). The modes tried by BROM are listed in [1]. SPL currently
tries only a single mode whose params are defined in sunxi-common.h,
but this is likely to change to a "brute-force" approach to resemble
BROM in the near future.
Yours,
Roy
Thanks
Michal
[1] https://linux-sunxi.org/NAND
--
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
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
