[U-Boot] [PATCH 3/3 V2] ARM: mxs: Fix NAND FCB flashing
Marek Vasut
marex at denx.de
Sat May 24 12:57:01 CEST 2014
On Wednesday, May 21, 2014 at 04:08:09 PM, jkrause wrote:
> I was wondering about the following warnings while bootings linux
> 3.15.0-rc5:
>
> [ 0.998885] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xd1
> [ 1.005485] nand: Toshiba NAND 128MiB 3,3V 8-bit
> [ 1.010165] nand: 128MiB, SLC, page size: 2048, OOB size: 64
> [ 1.016176] Scanning device for bad blocks
> [ 1.022444] Bad eraseblock 1 at 0x000000020000
> [ 1.027444] Bad eraseblock 2 at 0x000000040000
> [ 1.032612] Bad eraseblock 3 at 0x000000060000
>
> I noticed that these are the FCB pages for the NAND boot. Google found me
> this old thread. Nevertheless, I applied the patch on our custom i.MX28
> board and the warnings disappeared.
Yeah, but sometimes this patch made my board unbootable and I didn't have time
to investigate further. That is why it was never applied, to prevent that.
> But I still have some questions and remarks:
>
>
> Marek Vasut-3 wrote
>
> > Fix the method of flashing FCB blocks into NAND. The new env
> > writes all four FCB blocks and also does not scrub such a big
> > part of the NAND. This fixed complains about busted NAND blocks
> > in Linux.
> >
> > + "update_nand_write_fcb=" \
> > + "setenv i ${update_nand_count} ; " \
> > + "setenv update_nand_offset 0x0 ; " \
> > + "setexpr update_nand_step " \
> > + "${update_nand_stride} * ${nand_writesize} ; " \
> > + "while test ${i} -gt 0 ; do " \
> > + "echo ${update_nand_offset} ; " \
> > + "nand scrub -y ${update_nand_offset} " \
> > + "${nand_erasesize} ; " \
> > + "nand write.raw ${loadaddr} " \
> > + "${update_nand_offset} " \
> > + "${update_nand_stride} ; " \
>
> Why not just write a page (which contains the FCB) instead of the whole
> stride?
Feel free to roll V3 of the patch.
> There is also a problem about scrubbing of size 128K (which is the erase
> size) and writing 128K (which is the size of a search area with 64 pages).
> This works for the default settings (fuses not blown) of search stride =
> 1*64 and search count = 4. But if the fuses is blown and stride = 2*64 and
> count = 2 it will scrub 128K and write 256K (size of 128 pages). So the
> second half of the search area is not erased before writing.
Yes, we only support the default factory configuration. There are ways to tweak
the code to use different geometries, but that was to my knowledge never even
tested.
> Marek Vasut-3 wrote
>
> > "update_nand_full=" /* Update FCB, DBBT and FW */ \
> >
> > "if tftp ${update_nand_full_filename} ; then " \
> > "run update_nand_get_fcb_size ; " \
> >
> > - "nand scrub -y 0x0 ${filesize} ; " \
> > - "nand write.raw ${loadaddr} 0x0 ${fcb_sz} ; " \
> > + "run update_nand_write_fcb ; " \
> >
> > "setexpr update_off ${loadaddr} + ${update_nand_fcb} ; " \
> > "setexpr update_sz ${filesize} - ${update_nand_fcb} ; " \
> > "nand write ${update_off} ${update_nand_fcb} ${update_sz} ; " \
>
> Running update_nand_write_fcb erases and writes the FCB search area. The
> remaining bytes of the u-boot.nand file are writting before erasing the
> corresponding NAND flash bytes. I added something like this before:
>
> "setexpr update_off ${loadaddr} + ${update_nand_fcb} ; " \
> "setexpr update_sz ${filesize} - ${update_nand_fcb} ; " \
> + "nand erase ${update_nand_fcb} ${update_sz}; " \
> "nand write ${update_off} ${update_nand_fcb} ${update_sz} ; " \
>
> Is there any reason why this patch is not applied to the u-boot-imx repo?
Yes, see above. Feel free to submit V3 with detailed changelog and I can try if
it still breaks my platforms.
More information about the U-Boot
mailing list