[PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
The tool works for me, with imx28 and NAND memory, but the resulting blocks are reported as bad, both by u-boot and the kernel.
This makes it impossible to erase from Linux (for an upgrade without console access, for example -- u-boot can "nand scrub" but linux can't).
pre-filling with 0xff creates a proper boot loader image, but no bad-block marker is there when written to flash.
Signed-off-by: Alessandro Rubini rubini@gnudd.com --- tools/mxsboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 04d86f87a8..8f4018aa56 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -478,7 +478,7 @@ static int mx28_create_nand_image(int infd, int outfd) goto err0; }
- memset(buf, 0, size); + memset(buf, 0xff, size);
fcb = mx28_nand_get_fcb(MAX_BOOTSTREAM_SIZE); if (!fcb) {
Hi Alessandro,
[Adding Marek and Rogan]
On Sun, Dec 3, 2023 at 9:24 PM Alessandro Rubini rubini@gnudd.com wrote:
The tool works for me, with imx28 and NAND memory, but the resulting blocks are reported as bad, both by u-boot and the kernel.
This makes it impossible to erase from Linux (for an upgrade without console access, for example -- u-boot can "nand scrub" but linux can't).
pre-filling with 0xff creates a proper boot loader image, but no bad-block marker is there when written to flash.
Signed-off-by: Alessandro Rubini rubini@gnudd.com
tools/mxsboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 04d86f87a8..8f4018aa56 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -478,7 +478,7 @@ static int mx28_create_nand_image(int infd, int outfd) goto err0; }
memset(buf, 0, size);
memset(buf, 0xff, size);
This makes sense:
Reviewed-by: Fabio Estevam festevam@gmail.com
Thanks
On 12/4/23 02:35, Fabio Estevam wrote:
Hi Alessandro,
[Adding Marek and Rogan]
On Sun, Dec 3, 2023 at 9:24 PM Alessandro Rubini rubini@gnudd.com wrote:
The tool works for me, with imx28 and NAND memory, but the resulting blocks are reported as bad, both by u-boot and the kernel.
This makes it impossible to erase from Linux (for an upgrade without console access, for example -- u-boot can "nand scrub" but linux can't).
pre-filling with 0xff creates a proper boot loader image, but no bad-block marker is there when written to flash.
Signed-off-by: Alessandro Rubini rubini@gnudd.com
Isn't there some kobs-ng or whatever tool it was to properly initialize the NAND on MXS ?
Hello.
pre-filling with 0xff creates a proper boot loader image, but no bad-block marker is there when written to flash.
Isn't there some kobs-ng or whatever tool it was to properly initialize the NAND on MXS ?
I didn't know. I used what u-boot offers, which works for me without vendor tools -- and dare I say I trust u-boot tools more than vendor tools?.
The default environment even has the rule to reflash from any u-boot.nand you manage to put into RAM. The only issue is that u-boot.nand, as created, marks good blocks as bad by prefilling with zeores.
thanks /alessandro
On 12/4/23 09:09, Alessandro Rubini wrote:
Hello.
pre-filling with 0xff creates a proper boot loader image, but no bad-block marker is there when written to flash.
Isn't there some kobs-ng or whatever tool it was to properly initialize the NAND on MXS ?
I didn't know. I used what u-boot offers, which works for me without vendor tools -- and dare I say I trust u-boot tools more than vendor tools?.
The default environment even has the rule to reflash from any u-boot.nand you manage to put into RAM. The only issue is that u-boot.nand, as created, marks good blocks as bad by prefilling with zeores.
But what about the bad block markers , do they get erased when you write this U-Boot image into the NAND ?
I think the vendor tool somehow dealt with it (but it might have depended on some weird stuff in GPMI NAND), I don't think I ever used that tool myself.
But what about the bad block markers , do they get erased when you write this U-Boot image into the NAND ?
The image includes OOB data, because the rom-mandated map is different from normal standards. If OOB is zeroed, blocks appear as bad (correctly!).
By memsetting to 0xff, before filling data structures and checksums, we get a binary that written with "nand write.raw" works properly (the rom is happy with the format and boots) but doesn't mark blocks as bad.
[actually, only the first half-a-meg is with-oob, the trailing part is not, and the image is partly written with "nand write.raw" and partly with "nand write". Hairy things based on hairy vendor choices in hw/rom]
But tools/mxsboot works fine, and saved my day (or more).
thanks /alessandro
On 12/4/23 09:42, Alessandro Rubini wrote:
But what about the bad block markers , do they get erased when you write this U-Boot image into the NAND ?
The image includes OOB data, because the rom-mandated map is different from normal standards. If OOB is zeroed, blocks appear as bad (correctly!).
By memsetting to 0xff, before filling data structures and checksums, we get a binary that written with "nand write.raw" works properly (the rom is happy with the format and boots) but doesn't mark blocks as bad.
Clearly my recollection of the MXS is not what it once was.
Reviewed-by: Marek Vasut marex@denx.de
Thanks !
On Sun, Dec 3, 2023 at 9:24 PM Alessandro Rubini rubini@gnudd.com wrote:
The tool works for me, with imx28 and NAND memory, but the resulting blocks are reported as bad, both by u-boot and the kernel.
This makes it impossible to erase from Linux (for an upgrade without console access, for example -- u-boot can "nand scrub" but linux can't).
pre-filling with 0xff creates a proper boot loader image, but no bad-block marker is there when written to flash.
Signed-off-by: Alessandro Rubini rubini@gnudd.com
Applied to u-boot-imx next, thanks
participants (3)
-
Alessandro Rubini -
Fabio Estevam -
Marek Vasut