sunxi: nand: Basic NAND driver for SPL

drivers/mtd/nand/sunxi_nand_spl.c new file +18 -0

+int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
+{
+     void *current_dest;
+     uint32_t count;
+     uint32_t current_count;
+     uint32_t ecc_errors = 0;
+
+     memset(dest, 0x0, size); /* clean destination memory */
+     for (current_dest = dest;
+                     current_dest < (dest + size);
+                     current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
+             nand_read_page(offs, offs
+                             < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
+                            &ecc_errors);
+             count = current_dest - dest;
+
+             if (size - count > CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
+                     current_count = CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;

Quoted 22 lines · Piotr Zierhoffer

drivers/mtd/nand/sunxi_nand_spl.c new file +22 -0

+int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
+{
+     void *current_dest;
+     uint32_t count;
+     uint32_t current_count;
+     uint32_t ecc_errors = 0;
+
+     memset(dest, 0x0, size); /* clean destination memory */
+     for (current_dest = dest;
+                     current_dest < (dest + size);
+                     current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
+             nand_read_page(offs, offs
+                             < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
+                            &ecc_errors);
+             count = current_dest - dest;
+
+             if (size - count > CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
+                     current_count = CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+             else
+                     current_count = size - count;
+
+             memcpy(current_dest,

drivers/mtd/nand/sunxi_nand_spl.c line 351

Quoted 6 lines

drivers/mtd/nand/sunxi_nand_spl.c new file +6 -0

+                    temp_buf,
+                    current_count);
+             offs += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+     }
+     return ecc_errors ? -1 : 0;
+}

No bad block marker handling?

-Scott

Hi,

Quoted 23 lines · Scott Wood

Quoted 22 lines · Piotr Zierhoffer

drivers/mtd/nand/sunxi_nand_spl.c new file +22 -0

+int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
+{
+     void *current_dest;
+     uint32_t count;
+     uint32_t current_count;
+     uint32_t ecc_errors = 0;
+
+     memset(dest, 0x0, size); /* clean destination memory */
+     for (current_dest = dest;
+                     current_dest < (dest + size);
+                     current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
+             nand_read_page(offs, offs
+                             < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
+                            &ecc_errors);
+             count = current_dest - dest;
+
+             if (size - count > CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
+                     current_count = CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+             else
+                     current_count = size - count;
+
+             memcpy(current_dest,

Quoted 8 lines

drivers/mtd/nand/sunxi_nand_spl.c line 351

Quoted 6 lines

drivers/mtd/nand/sunxi_nand_spl.c new file +6 -0

+                    temp_buf,
+                    current_count);
+             offs += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+     }
+     return ecc_errors ? -1 : 0;
+}

No bad block marker handling?

The bootrom does not use bad block marker handling (and allwinner's own FTL does neither for the non boot area, the actually mess up things by writing metadata which looks like classic bad block markers).

What we should do (in a follow up patch) is run some sanity checks (checksum of the image, etc.) and retry at a different offset if that fails. This is also what the bootrom does for loading the SPL itself, it simply tries to read it at a number of fixed addresses at the beginningen of the nand, so we should do the same looking for u-boot.bin at those same addresses (taking into account that u-boot.bin will be written after the SPL).

Hi Hans,

Quoted 35 lines · On Fri, 31 Jul 2015 10:36:43 +0200 Hans de Goede <[email protected]> wrote:

Hi,

Quoted 31 lines · Scott Wood

Quoted 18 lines · Piotr Zierhoffer

drivers/mtd/nand/sunxi_nand_spl.c new file +18 -0

+int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
+{
+     void *current_dest;
+     uint32_t count;
+     uint32_t current_count;
+     uint32_t ecc_errors = 0;
+
+     memset(dest, 0x0, size); /* clean destination memory */
+     for (current_dest = dest;
+                     current_dest < (dest + size);
+                     current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
+             nand_read_page(offs, offs
+                             < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
+                            &ecc_errors);
+             count = current_dest - dest;
+
+             if (size - count > CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
+                     current_count = CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;

drivers/mtd/nand/sunxi_nand_spl.c line 351

Quoted 10 lines

drivers/mtd/nand/sunxi_nand_spl.c new file +10 -0

+             else
+                     current_count = size - count;
+
+             memcpy(current_dest,
+                    temp_buf,
+                    current_count);
+             offs += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+     }
+     return ecc_errors ? -1 : 0;
+}

No bad block marker handling?

Quoted 4 lines

The bootrom does not use bad block marker handling (and allwinner's own FTL does neither for the non boot area, the actually mess up things by writing metadata which looks like classic bad block markers).

Hm, checking for bad block markers (and skipping bad blocks) is always a good thing, even if it does not by itself guarantee that the data stored in there are not corrupted.

Quoted 45 lines · Boris Brezillon

Hi Hans,

Quoted 39 lines · On Fri, 31 Jul 2015 10:36:43 +0200 Hans de Goede <[email protected]> wrote:

Hi,

Quoted 23 lines · Scott Wood

Quoted 22 lines · Piotr Zierhoffer

drivers/mtd/nand/sunxi_nand_spl.c new file +22 -0

+int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
+{
+     void *current_dest;
+     uint32_t count;
+     uint32_t current_count;
+     uint32_t ecc_errors = 0;
+
+     memset(dest, 0x0, size); /* clean destination memory */
+     for (current_dest = dest;
+                     current_dest < (dest + size);
+                     current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
+             nand_read_page(offs, offs
+                             < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
+                            &ecc_errors);
+             count = current_dest - dest;
+
+             if (size - count > CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
+                     current_count = CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+             else
+                     current_count = size - count;
+
+             memcpy(current_dest,

Quoted 8 lines

drivers/mtd/nand/sunxi_nand_spl.c line 351

Quoted 6 lines

drivers/mtd/nand/sunxi_nand_spl.c new file +6 -0

+                    temp_buf,
+                    current_count);
+             offs += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+     }
+     return ecc_errors ? -1 : 0;
+}

No bad block marker handling?

The bootrom does not use bad block marker handling (and allwinner's own FTL does neither for the non boot area, the actually mess up things by writing metadata which looks like classic bad block markers).

Quoted 3 lines

Hm, checking for bad block markers (and skipping bad blocks) is always a good thing, even if it does not by itself guarantee that the data stored in there are not corrupted.

Not on Allwinner hardware. Allwinner tools write data to the nand which looks like bad block markers so skipping blocks which appear marked as bad will inevitably skip valid blocks on many (most ?) Allwinner devices.

Only in the case you soldered a new nand chip yourself and never used Allwinner tools with it will the bad block markers remain valid. This is overall very unlikely so it should not be something SPL handles.

Quoted 45 lines · Boris Brezillon

Hi Hans,

Quoted 39 lines · On Fri, 31 Jul 2015 10:36:43 +0200 Hans de Goede <[email protected]> wrote:

Hi,

Quoted 23 lines · Scott Wood

Quoted 22 lines · Piotr Zierhoffer

drivers/mtd/nand/sunxi_nand_spl.c new file +22 -0

+int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
+{
+     void *current_dest;
+     uint32_t count;
+     uint32_t current_count;
+     uint32_t ecc_errors = 0;
+
+     memset(dest, 0x0, size); /* clean destination memory */
+     for (current_dest = dest;
+                     current_dest < (dest + size);
+                     current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
+             nand_read_page(offs, offs
+                             < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
+                            &ecc_errors);
+             count = current_dest - dest;
+
+             if (size - count > CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
+                     current_count = CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+             else
+                     current_count = size - count;
+
+             memcpy(current_dest,

Quoted 8 lines

drivers/mtd/nand/sunxi_nand_spl.c line 351

Quoted 6 lines

drivers/mtd/nand/sunxi_nand_spl.c new file +6 -0

+                    temp_buf,
+                    current_count);
+             offs += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+     }
+     return ecc_errors ? -1 : 0;
+}

No bad block marker handling?

The bootrom does not use bad block marker handling (and allwinner's own FTL does neither for the non boot area, the actually mess up things by writing metadata which looks like classic bad block markers).

Quoted 3 lines

Hm, checking for bad block markers (and skipping bad blocks) is always a good thing, even if it does not by itself guarantee that the data stored in there are not corrupted.

Not on Allwinner hardware. Allwinner tools write data to the nand which looks like bad block markers so skipping blocks which appear marked as bad will inevitably skip valid blocks on many (most ?) Allwinner devices.

Only in the case you soldered a new nand chip yourself and never used Allwinner tools with it will the bad block markers remain valid. This is overall very unlikely so it should not be something SPL handles.

Hi Michal,

Quoted 47 lines · On Fri, 31 Jul 2015 16:25:00 +0200 Michal Suchanek <[email protected]> wrote:

Quoted 45 lines · Boris Brezillon

Hi Hans,

Quoted 39 lines · On Fri, 31 Jul 2015 10:36:43 +0200 Hans de Goede <[email protected]> wrote:

Hi,

Quoted 23 lines · Scott Wood

Quoted 22 lines · Piotr Zierhoffer

drivers/mtd/nand/sunxi_nand_spl.c new file +22 -0

+int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
+{
+     void *current_dest;
+     uint32_t count;
+     uint32_t current_count;
+     uint32_t ecc_errors = 0;
+
+     memset(dest, 0x0, size); /* clean destination memory */
+     for (current_dest = dest;
+                     current_dest < (dest + size);
+                     current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
+             nand_read_page(offs, offs
+                             < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
+                            &ecc_errors);
+             count = current_dest - dest;
+
+             if (size - count > CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
+                     current_count = CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+             else
+                     current_count = size - count;
+
+             memcpy(current_dest,

Quoted 8 lines

drivers/mtd/nand/sunxi_nand_spl.c line 351

Quoted 6 lines

drivers/mtd/nand/sunxi_nand_spl.c new file +6 -0

+                    temp_buf,
+                    current_count);
+             offs += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+     }
+     return ecc_errors ? -1 : 0;
+}

No bad block marker handling?

The bootrom does not use bad block marker handling (and allwinner's own FTL does neither for the non boot area, the actually mess up things by writing metadata which looks like classic bad block markers).

Quoted 8 lines

Quoted 3 lines

Hm, checking for bad block markers (and skipping bad blocks) is always a good thing, even if it does not by itself guarantee that the data stored in there are not corrupted.

Not on Allwinner hardware. Allwinner tools write data to the nand which looks like bad block markers so skipping blocks which appear marked as bad will inevitably skip valid blocks on many (most ?) Allwinner devices.

First of all, that's not exactly true. The allwinner NAND layer (and probably the tools allowing you to flash a new image) is actually writing the appropriate good block pattern (0xff), but this pattern is then randomized by the hardware randomizer, which makes it look like a bad block (!= 0xff).

The other aspect is, do we really have to support images flashed with this tool? I mean, I'm flashing my images using fel and a standard u-boot, and they generate perfectly valid images with valid bad block markers.

Quoted 5 lines

Only in the case you soldered a new nand chip yourself and never used Allwinner tools with it will the bad block markers remain valid. This is overall very unlikely so it should not be something SPL handles.

Here you're talking about the bad block markers 'corrupted' by the libnand layer (or the flashing tool).
To restore valid bad block markers you just have to launch nand scrub in u-boot.
I'm also thinking about a way to retrieve the real bad blocks even when the NAND has been used with an allwinner kernel (the idea is to first check without the randomizer disabled, and if it does not return 0xff, try to enable the randomizer, then if it still does not return 0xff, it's a real bad block).

But unless we want to support both mainline and non-mainline systems using the same SPL, that aspect is just something that should be handled when your moving from an allwinner image to a mainline one.

Hi Michal,

Quoted 60 lines · On Fri, 31 Jul 2015 16:25:00 +0200 Michal Suchanek <[email protected]> wrote:

Quoted 45 lines · Boris Brezillon

Hi Hans,

Quoted 40 lines · On Fri, 31 Jul 2015 10:36:43 +0200 Hans de Goede <[email protected]> wrote:

Hi,

Quoted 36 lines · Scott Wood

Quoted 23 lines · Piotr Zierhoffer

+int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)

drivers/mtd/nand/sunxi_nand_spl.c new file +10 -0

+{
+     void *current_dest;
+     uint32_t count;
+     uint32_t current_count;
+     uint32_t ecc_errors = 0;
+
+     memset(dest, 0x0, size); /* clean destination memory */
+     for (current_dest = dest;
+                     current_dest < (dest + size);
+                     current_dest += 

CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {

(quoted diff) +2 -0

+             nand_read_page(offs, offs
+                             < 

CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,

drivers/mtd/nand/sunxi_nand_spl.c new file +4 -0

+                            &ecc_errors);
+             count = current_dest - dest;
+
+             if (size - count > 

CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
+ current_count =
CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;

drivers/mtd/nand/sunxi_nand_spl.c line 351

Quoted 10 lines

drivers/mtd/nand/sunxi_nand_spl.c new file +10 -0

+             else
+                     current_count = size - count;
+
+             memcpy(current_dest,
+                    temp_buf,
+                    current_count);
+             offs += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
+     }
+     return ecc_errors ? -1 : 0;
+}

No bad block marker handling?

Quoted 8 lines

Quoted 4 lines

The bootrom does not use bad block marker handling (and allwinner's own FTL does neither for the non boot area, the actually mess up things by writing metadata which looks like classic bad block markers).

Hm, checking for bad block markers (and skipping bad blocks) is always a good thing, even if it does not by itself guarantee that the data stored in there are not corrupted.

Not on Allwinner hardware. Allwinner tools write data to the nand which looks like bad block markers so skipping blocks which appear marked as bad will inevitably skip valid blocks on many (most ?) Allwinner devices.

First of all, that's not exactly true. The allwinner NAND layer (and probably the tools allowing you to flash a new image) is actually writing the appropriate good block pattern (0xff), but this pattern is then randomized by the hardware randomizer, which makes it look like a bad block (!= 0xff).

The other aspect is, do we really have to support images flashed with this tool? I mean, I'm flashing my images using fel and a standard u-boot, and they generate perfectly valid images with valid bad block markers.

Quoted 1 line

Quoted 3 lines

Only in the case you soldered a new nand chip yourself and never used Allwinner tools with it will the bad block markers remain valid. This is overall very unlikely so it should not be something SPL handles.

Here you're talking about the bad block markers 'corrupted' by the libnand layer (or the flashing tool).
To restore valid bad block markers you just have to launch nand scrub in u-boot.

This is a basic driver for the sunxi NAND controller for Allwinner A20. It supports only SPL.

Quoted 2 lines

This is a basic driver for the sunxi NAND controller for Allwinner A20. It supports only SPL.

Can you please elaborate how exactly is this specific only to SPL? Why?

Best regards,
Marek Vasut

Hi Marek

As BROM requires SPL binary size to be limited, we wanted to keep it very minimal.

This driver has no integration with full U-Boot driver structure. What's more, it does not support writing.

It was tested as SPL driver, so that's why I am submitting it as such.

Best regards

Piotr Zierhoffer,
Antmicro Ltd | www.antmicro.com
*Piotr Zierhoffer*
mobile: +48 696 419 606
Antmicro Ltd | www.antmicro.com
Zwierzyniecka 3, 60-813 Poznan, Poland

2015-07-23 16:04 GMT+02:00 Marek Vasut <[email protected]>:

Quoted 8 lines · Piotr Zierhoffer

Quoted 2 lines

This is a basic driver for the sunxi NAND controller for Allwinner A20. It supports only SPL.

Can you please elaborate how exactly is this specific only to SPL? Why?

Best regards,
Marek Vasut

This is a basic driver for the sunxi NAND controller for Allwinner A20. It supports only SPL.

The driver uses DMA for data transfers. It does not support writing.

Changes in v3:
- moved pinmux and clock to board level
- code cleanup with significant size reduction
- renamed the driver file
- renamed constants to match Kconfig convention
- moved defines from .h to .c, and renamed them to be consistent with each other
- removed more magic values
- changed ecc_errors from static to local variable
- other minor changes
- added new options in Kconfig to support different chips
- changed descriptions to comply with patman rules

Changes in v2:
- removed traces of non-SPL-specific code
- moved the driver from boards/sunxi to drivers/mtd/nand
- moved magic values to defines (whenever possible)
- removed unnecesary late initialisation code
- code style changes as suggested for the first patch set:
- changed visibility of some symbols
- renamed unclear variables
- renamed header protector
- changed types of pointer variables
- other minor changes
- removed traces of non-SPL specific code
- renamed defines to be more relevant
- moved Kconfig entry for the driver to drivers/mtd/nand
- reworded Kconfig entry help

Karol Gugala (1):
sunxi: nand: Add pinmux and clock settings for NAND support

Piotr Zierhoffer (3):
sunxi: nand: Add basic sunxi NAND driver for SPL with DMA support
sunxi: nand: Add board configuration options
sunxi: nand: Add information to sunxi that it was run from NAND in SPL

  arch/arm/cpu/armv7/sunxi/board.c              |   4 +
  arch/arm/include/asm/arch-sunxi/clock_sun4i.h |   2 +
  arch/arm/include/asm/arch-sunxi/gpio.h        |   1 +
  board/sunxi/board.c                           |  27 ++
  drivers/mtd/nand/Kconfig                      |  40 +++
  drivers/mtd/nand/Makefile                     |   1 +
  drivers/mtd/nand/sunxi_nand_spl.c             | 353 ++++++++++++++++++++++++++
  include/configs/sunxi-common.h                |  10 +
  8 files changed, 438 insertions(+)

create mode 100644 drivers/mtd/nand/sunxi_nand_spl.c

Hi,

Quoted 3 lines · Piotr Zierhoffer

This is a basic driver for the sunxi NAND controller for Allwinner A20. It supports only SPL.

Quoted 1 line

The driver uses DMA for data transfers. It does not support writing.

Thanks for your work on this.

I've merged patches 1 - 3 in my sunxi-wip branch, and I'll include them in the next u-boot-sunxi pull-req.

Hi Hans,

Quoted 6 lines · On Sat, 1 Aug 2015 14:15:53 +0200 Hans de Goede <[email protected]> wrote:

Hi,

Quoted 3 lines · Piotr Zierhoffer

This is a basic driver for the sunxi NAND controller for Allwinner A20. It supports only SPL.

Quoted 6 lines

Quoted 1 line

The driver uses DMA for data transfers. It does not support writing.

Thanks for your work on this.

I've merged patches 1 - 3 in my sunxi-wip branch, and I'll include them in the next u-boot-sunxi pull-req.

Shouldn't we at least wait for Scoot's approval?

Quoted 15 lines · Boris Brezillon

Hi Hans,

Quoted 10 lines · On Sat, 1 Aug 2015 14:15:53 +0200 Hans de Goede <[email protected]> wrote:

Hi,

Quoted 4 lines · Piotr Zierhoffer

This is a basic driver for the sunxi NAND controller for Allwinner A20. It supports only SPL.

The driver uses DMA for data transfers. It does not support writing.

Thanks for your work on this.

Quoted 4 lines

Quoted 2 lines

I've merged patches 1 - 3 in my sunxi-wip branch, and I'll include them in the next u-boot-sunxi pull-req.

Shouldn't we at least wait for Scoot's approval?

Or Scott's. :-)

ACK

though I'd encourage quickly implementing multiple spl payload locations to work around the breakage of the bad block marker mechanism, as was discussed.

Hi,

Quoted 24 lines · Scott Wood

Quoted 22 lines · Boris Brezillon

Hi Hans,

Quoted 14 lines · On Sat, 1 Aug 2015 14:15:53 +0200 Hans de Goede <[email protected]> wrote:

Hi,

Quoted 5 lines · Piotr Zierhoffer

This is a basic driver for the sunxi NAND controller for Allwinner A20. It supports only SPL.

The driver uses DMA for data transfers. It does not support writing.

Thanks for your work on this.

I've merged patches 1 - 3 in my sunxi-wip branch, and I'll include them in the next u-boot-sunxi pull-req.

Quoted 6 lines

Quoted 1 line

Shouldn't we at least wait for Scoot's approval?

Or Scott's. :-)

ACK

Thanks.

Quoted 3 lines

though I'd encourage quickly implementing multiple spl payload locations to work around the breakage of the bad block marker mechanism, as was discussed.

I agree 100%, I've added note to my sunxi todo list for this. Note I only have this on my todo list as a reminder, since a few other people are actively
working on sunxi nand support I hope that someone else will tackle this.

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

I've merged patches 1 - 3 in my sunxi-wip branch, and I'll include them in the next u-boot-sunxi pull-req.

Shouldn't we at least wait for Scoot's approval?

Quoted 6 lines

Quoted 3 lines

Or Scott's. :-)

ACK

Thanks.

Hi,

I've not done sunxi development for a while. So I need to ask you guys about some details. I hope you don't mind. Please see questions below.

Quoted 9 lines · Piotr Zierhoffer

Quoted 9 lines

Quoted 9 lines

Quoted 5 lines

Quoted 2 lines

I've merged patches 1 - 3 in my sunxi-wip branch, and I'll include them in the next u-boot-sunxi pull-req.

Shouldn't we at least wait for Scoot's approval?

Or Scott's. :-)

Quoted 4 lines

Quoted 4 lines

Quoted 1 line

ACK

Thanks.

Okay, this driver SPL NAND is now integrated in mainline. Great.

But how about NAND support for the main U-Boot (load Linux from NAND etc.)? It seems to be missing. Is somebody working on this?

Whats the current status here?

Quoted 4 lines

Okay, this driver SPL NAND is now integrated in mainline. Great.

But how about NAND support for the main U-Boot (load Linux from NAND etc.)? It seems to be missing. Is somebody working on this?

Yes, see:

https://github.com/NextThingCo/CHIP-u-boot
https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-nand-wip

Quoted 1 line

Whats the current status here?

We want to use the Linux kernel code for the main U-Boot, which is not fully upstream yet (and will likely not be for a while) as it needs per partition config (ecc / scrambler) settings, as well as merging of scrambler support into the upstream kernel first.

We will likely have a u-boot branch with this working soon-ish,

but getting this merged is a different story.

Quoted 4 lines

Yes, see:

https://github.com/NextThingCo/CHIP-u-boot
https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-nand-wip

Thanks.

Quoted 4 lines

Quoted 2 lines

https://github.com/NextThingCo/CHIP-u-boot
https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-nand-wip

Thanks.

I've started on your "sunxi-nand-wip" branch. And noticed that its currently stuck / hangs in nand_onfi_set_features() called via sunxi_nand_chip_init_timings(). I've attached 2 patches now:

One with some whitespace / coding-style fixes and more important a 2nd one that actually fixes some buggy pointer initialization.

I just wanted to share this improvement, even if the driver still does not work correctly. But at least its not crashing that early with this fix.