On Mon, 08 Jun 2015 10:41:28 +0200 Roy Spliet r.spliet@ultimaker.com wrote:
Hello Michal,
Op 08-06-15 om 10:34 schreef Michal Suchanek:
On 8 June 2015 at 10:11, Roy Spliet r.spliet@ultimaker.com wrote:
Hello Scott et al.,
Op 06-06-15 om 00:02 schreef Scott Wood:
On Fri, 2015-06-05 at 13:52 +0200, Roy Spliet wrote:
From: yassin yassinjaffer@gmail.com
Signed-off-by: Roy Spliet r.spliet@ultimaker.com
drivers/mtd/nand/Makefile | 2 +- drivers/mtd/nand/nand_timings.c | 252 ++++++++++++++++++++++++++++++++++++++++ include/linux/mtd/nand.h | 3 + 3 files changed, 256 insertions(+), 1 deletion(-) create mode 100644 drivers/mtd/nand/nand_timings.c
This code comes from Linux and yet I see no acknowledgement of that, much less a statement of which version of Linux this was pulled from.
Correct, my apologies as I should have clarified that "work by Boris Brezillon" does not mean "upsteam work". The code comes from Boris' github tree[1] and contains work that was not yet brought upstream, yet is required for NAND on sunxi to work.
It would probably be better to handle this as part of a general sync with the Linux mtd code.
Ideally yes, but. In upstream Linux MTD we have a few issues to address as shown by Boris' patch-set, most importantly:
- NAND chip timings (patch 1 to 3)
- Randomisation support (patch 6)
- Per-partition settings for ECC and randomisation (left out of my RFC,
highly desirable but not strictly required for U-boot booting)
Hello,
as I understand it the ECC and randomisation settings for the bootloader part of the nand are suboptimal or unusable for ubifs so if u-boot SPL is to read the u-boot binary and later u-boot the kernel from an ubifs volume it has to support non-uniform settings. Alternatively the bootloader part can be extended to contain partitions for u-boot binary and kernel image written to raw partition without filesystem much like what Andriod usually does.
SPL does not read U-boot from UBI. The SPL driver is separate, much smaller and only reads in the same way BROM does. U-boot itself is not bound by the limitations imposed by BROM, which means proper randomisation and ECC settings can be used for "the UBI partition".
Yep, I agree with Roy here: we shouldn't use the BROM config except for the SPL partition. Defining the same randomizer seed for all the pages in a given block is pretty much useless since it won't prevent the reproducible pattern issue, which is one of the cause of excessive bitblits in MLC NANDs. The same goes for the ECC config used by the BROM, because in some cases it might prevent using the whole page (ECC config is stronger than required, and thus ECC bytes take more than what's available in the OOB area).