Flash NAND with bad blocks

Hello,

I am posting here as somebody proposed this on the OpenWrt forum, please tell me if it's not the right place.

I would like to install OpenWrt on an NSA310. The installation instructions are to first flash a newer U-Boot version, set the proper environment variables, then flash the firmware image through these commands:

usb reset
fatload usb 0 0x2000000 nsa310.bin
nand erase.part ubi
nand write 0x2000000 ubi 0x600000

But looking through the boot log of the original firmware of the device, I see that there are 2 bad NAND blocks, and I would like to know if this flashing procedure can handle them in a safe way. I don't know enough about the low level details, so I do not know if the bad blocks info is stored in the NAND directly or somewhere at a higher filesystem level.
(also, I do not actually find these "nand" commands through the U-Boot documentation that I could find)

Thanks for any info!

kent_c,

> Hello,
>
> I am posting here as somebody proposed this on the
> OpenWrt forum, please tell me if it's not the
> right place.
>

That's OK. If you are going to flash my released u-boot then for sure it is the right place. But even you are flashing other u-boot, I will help.


> I would like to install OpenWrt on an NSA310. The
> installation instructions are to first flash a
> newer U-Boot version,

You meant flashing this u-boot?

uboot.2017.07-tld-1.nsa310.kwb

> set the proper environment
> variables, then flash the firmware image through
> these commands:
>

> usb reset
> fatload usb 0 0x2000000 nsa310.bin
> nand erase.part ubi
> nand write 0x2000000 ubi 0x600000
>

> But looking through the boot log of the original
> firmware of the device, I see that there are 2 bad
> NAND blocks,

I need to see that info in boot log.

> and I would like to know if this
> flashing procedure can handle them in a safe way.
> I don't know enough about the low level details,
> so I do not know if the bad blocks info is stored
> in the NAND directly or somewhere at a higher
> filesystem level.
> (also, I do not actually find these "nand"
> commands through the U-Boot documentation that I
> could find)
>

Sounds like you want to flash u-boot in serial console. Can you log into stock OS, or Dedbian on this box? If you can't log into any Linux system on this box, then serial console flashing is OK (it's easier to flash new u-boot in Linux).

Power up, interrupt serial console, and

printenv
nand bad
mtdparts

And please post this serial console log here.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi, and thanks for answering!

Yes, the plan is to flash U-Boot via the serial console. I can currently log into the stock OS via both the serial console and telnet.
I am not sure about the source of the OpenWrt-provided U-Boot,...

The mtdparts is not implemented in the stock U-Boot, but the partitions can be seen in the kernel boot arguments and the kernel log.

NSA310>> printenv
bootargs=console=ttyS0,115200 mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) root=/dev/nfs rw init=/init
bootcmd=nand read.e 0x2000000 $(kernel_addr) 0xA00000; bootm 0x2000000
bootdelay=2
baudrate=115200
loads_echo=0
eth1addr=00:19:CB:00:51:82
ipaddr=10.4.50.165
serverip=10.4.50.5
rootpath=/mnt/ARM_FS/
netmask=255.255.255.0
nandEcc=1bit
MODEL_ID=A203
PRODUCT_NAME=NSA-310
FEATURE_BIT=00
CONTRY_TYPE=FF
VENDOR_NAME=ZyXEL Communications Corp.
run_diag=yes
ethaddr=xx:xx:xx:xx:xx:xx
stdin=serial
stdout=serial
stderr=serial
console=console=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x7f00000@0x100000(root)
mainlineLinux=no
CASset=min
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
ethprime=egiga1
netbsd_en=no
vxworks_en=no
bootargs_root=root=/dev/nfs rw
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
disaMvPnp=no
ethmtu=1500
eth1mtu=1500
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
usb0Mode=host
yuk_ethaddr=00:00:00:EE:51:81
hddPowerCtrl=no
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
enaAutoRecovery=yes
kernel_addr=0xc80000
pcieTune=no
ethact=egiga1

NSA310>> nand bad

Device 0 bad blocks:
  00e80000
  033a0000

And what I think is the relevant part of the boot log, please tell me if this is not enough:

         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_ 
| | | |___|  _ \ / _ \ / _ \| __| 
| |_| |___| |_) | (_) | (_) | |_ 
 \___/    |____/ \___/ \___/ \__| 
 ** MARVELL BOARD: RD-88F6281A LE 

U-Boot 1.1.4 (Jun  8 2011 - 18:48:37) Marvell version: 3.4.19

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFEE0

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz 

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB 
DRAM Total size 256MB  16bit width
Addresses 10M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (10M - 7M): Done
NAND:128 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
Kernel address is 0xc80000.

Streaming disabled 
Write allocate disabled

Module 0 is RGMII
Module 1 is TDM

USB 0: host mode
PEX 0: PCI Express Root Complex Interface
PEX interface detected Link X1
Net:   egiga0, egiga1 [PRIME]
Hit any key to stop autoboot:  0 

NAND read: device 0 offset 0xc80000, size 0xa00000

Bad block at 0xe80000 in erase block from 0xe80000 will be skipped
Reading data from 0x169f800 -- 100% complete.
 10485760 bytes read: OK
## Booting image at 02000000 ...
   Image Name:   Linux-2.6.31.8
   Created:      2016-03-11   9:35:37 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5696716 Bytes =  5.4 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux............................................................................................................................................................................................................................................................................ done, booting the kernel.
Linux version 2.6.31.8 (root@BuildMachine) (gcc version 4.3.2 (sdk3.3-ct-ng-1.4.1) ) #2 Fri Mar 11 17:35:20 CST 2016
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Feroceon-KW
Using UBoot passing parameters structure
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 65024
Kernel command line: console=ttyS0,115200 mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) root=/dev/nfs rw init=/init
PID hash table entries: 1024 (order: 10, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256MB = 256MB total
Memory: 244992KB available (5304K code, 300K data, 2804K init, 0K highmem)
.......
CPU Interface
-------------
SDRAM_CS0 ....base 00000000, size 256MB 
SDRAM_CS1 ....disable
SDRAM_CS2 ....disable
SDRAM_CS3 ....disable
PEX0_MEM ....base e0000000, size 128MB 
PEX0_IO ....base f2000000, size   1MB 
PEX1_MEM ....no such
PEX1_IO ....no such
INTER_REGS ....base f1000000, size   1MB 
NFLASH_CS ....base fa000000, size   2MB 
SPI_CS ....base f4000000, size  16MB 
BOOT_ROM_CS ....no such
DEV_BOOTCS ....no such
CRYPT_ENG ....base f0000000, size   2MB 

  Marvell Development Board (LSP Version KW_LSP_5.1.3_patch18)-- RD-88F6281A  Soc: 88F6281 A1 LE
........
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
........
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 116 at 0x000000e80000
Bad eraseblock 413 at 0x0000033a0000
9 cmdlinepart partitions found on MTD device nand_mtd
Using command line partition definition
Creating 9 MTD partitions on "nand_mtd":
0x000000000000-0x000000100000 : "uboot"
0x000000100000-0x000000180000 : "uboot_env"
0x000000180000-0x000000200000 : "key_store"
0x000000200000-0x000000280000 : "info"
0x000000280000-0x000000c80000 : "etc"
0x000000c80000-0x000001680000 : "kernel_1"
0x000001680000-0x000004640000 : "rootfs1"
0x000004640000-0x000005040000 : "kernel_2"
0x000005040000-0x000008000000 : "rootfs2"
........
*** Stage 2: Prepare the root file system ***
Mount system partition...
yaffs: dev is 32505862 name is "mtdblock6" ro
yaffs: passed flags ""
/dev/sda1 /zyxel/mnt/sysdisk ext2 ro,relatime,errors=continue 0 0
0
Boot from disk
Checksum of sysdisk.img : c196092a6409259bb076b47ed4e62236
Checksum from INFO  : c196092a6409259bb076b47ed4e62236
Checksum pass!
Mount system disk image ...
yaffs: dev is 32505860 name is "mtdblock4" rw
yaffs: passed flags ""
/etc/zyxel/conf exist..
Start rcS2 of ZyXEL style

kent_c,

> Yes, the plan is to flash U-Boot via the serial
> console. I can currently log into the stock OS via
> both the serial console and telnet.
> I am not sure about the source of the
> OpenWrt-provided U-Boot,...
>

If you can log into stock OS, then you can flash new u-boot image uboot.2017.07-tld-1.nsa310.mtd0.kwb in there. It is easier.

Stock dmesg

Bad eraseblock 116 at 0x000000e80000
Bad eraseblock 413 at 0x0000033a0000

These 2 bad blocks are way out of mtd0 (the 1st 1MB, i.e. blocks 0 to 7), which is where the new u-boot and its envs will be.

Stock dmesg

9 cmdlinepart partitions found on MTD device nand_mtd
Using command line partition definition
Creating 9 MTD partitions on "nand_mtd":
0x000000000000-0x000000100000 : "uboot"

So you can follow the instruction in the u-boot released thread and flash it in stock OS shell.

Right up front in Section A, you will also need to download the flashing binaries (stock OS does not have them).

Quote

A. Flashing Instruction:


Installation is the same for each u-Boot image, the instruction below is written to include all boxes. So choose the platform name that you are installing for, and copy/paste the appropriate commands.

If you are running kernel that do not provide mtd-utils and uboot-tools (fw_setenv, fw_printenv, flash_erase, nandwrite), you can download the NAND and U-Boot tools binaries here in this thread.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 02/03/2019 09:23PM by bodhi.

I also looked now at the actual addresses of those 2 bad blocks. They are both far outside of bootloader's area, that's good, so I'm confident to try an install.

But I still have my original concern: what happens when I try to install a Linux system after the bootloader? With my pretty limited understanding, I see two main ways of doing this:
1. Flash a pre-made image directly, like I had in mind. I do not know the exact effect of the last 2 commands from my original post and whether the bad blocks would still be recognized afterwards.
2. Like the tutorial at http://projects.doozan.com/debian, by running fdisk, then creating filesystems, then copying over the files.

What would be a safe way for the installation?

kent_c,


> But I still have my original concern: what happens
> when I try to install a Linux system after the
> bootloader?

After the new u-boot is installed, you can install OpenWrt in NAND, or install Debian on USB. As long as you're not touching mtd0, it is safe to do any thing you want.

> 1. Flash a pre-made image directly, like I had in
> mind. I do not know the exact effect of the last 2
> commands from my original post and whether the bad
> blocks would still be recognized afterwards.

Since I'm not seeing the entire OpenWrt installation procedure here, I can only advise in general terms.

Generally speaking, when you format the ubi partition, UBIFS will manage the bad blocks correctly. And at a lower level, NAND driver also manages and skips the bad blocks properly. That is the reason why a good installtion procedure always has some empty area at the end of a NAND partition (to account for skipped bad blocks).

So suppose your ubi partition is 120MB, an image that resides in that partition should be a little less, eg. 115MB. When you write the 115MB image, it will take more than 115MB if there are bad blocks in the middle.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi, thank you for the info!
I plan to go ahead with OpenWrt, for now at least, as I'm more familiar with it (their installation procedure is at https://openwrt.org/toh/zyxel/nsa310b).

In any case, reading these forums, I can see that I am lucky with this device, as there is always a way to bring it back to life in case of problems, and the serial booting is a very nice feature.
And I plan to read some more about the low level details of flash memory.

I'm coming back to say thank you again for the help!
In the meanwhile I flashed the new U-Boot and saw that the native commands recognize the bad blocks, so everything is ok in the end.

Also the new system is running fine now. By the way, it was an unpleasant surprise to see that on the stock Zyxel firmware the password files under /etc were world-readable, so I'm glad to have switched from that.