mtd: gpmi: issue with raw access support

[Boris Brezillon]

Hi,

On Mon, 25 Jan 2016 15:53:23 -0600
Han Xu <xhnjupt at gmail.com> wrote:

> Hi Boris,
> 
> There is an issue on Kernel 4.1 with your gpmi raw access support
> patch. I can understand with your implementation all data are stored
> in BCH layout, even without HW ECC. But for NAND boot function on i.MX
> family, it requires to write BOOT CONFIGURATION DATA at the beginning
> of NAND chip, so ROM code could understand how to configure BCH
> register to read data with proper ECC handling.
> 
> All these BOOT CONFIURATION DATA must be written with proper ROM
> defined format, including data layout, parity checking algorithm( NOT
> BCH ECC for some platforms). A user-space tool, named kobs-ng was
> provided to generate all necessary data, and it called the mtd raw
> functions to write the UNFORMATTED data to NAND chip.

Yes, I had the same problem, actually I made 2 patches for kobs-ng
(I'll send them in reply to this email), but since the project seemed to
be unmaintained, I didn't submit it.

> 
> With the new patch, all NAND boot function on kernel 4.1 failed since
> ROM couldn't read the proper configuration. To solve the issue, I am
> planning to export a switch in debugfs to let the user applications to
> choose raw access mode, unformatted mode or BCH layout one, while I
> got stuck.

Hm, providing two different set of raw access functions is a bad idea
IMO. If we had a per-partition configuration infrastructure that could
be done, but so far we don't have that.

> 
> The problem is how could I dynamically change the raw functions from
> the new ones you provided to the default ones in nand_base. It more or
> less a hacking either getting the pointer of functions
> nand_read_page_raw /nand_write_page_raw or copy-pasting the implement
> of these two functions to gpmi layer. So I was wondering if you have
> any better idea for this issue? Thanks.

I recommend to patch kobs-ng, and let him reorganize the data to make
the ROM firmware happy. That's what I did in my patches, but IIRC, I
only took the "aligned ECC bytes" case into consideration, and this is
not necessarily true depending on the ECC config, so you'll have to
rework my patches to address that.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com