Banani pi bpi-r4 problem with bad blocks

aLiArLa · May 16, 2025, 2:57pm

Hello, I hope you can help me. I'm desperate and I don't know what to do anymore. My bpi-r4 router stopped working and as it wouldn't boot I tried to reconfigure it again from the nand. Nothing worked and every time I tried it was getting worse and worse. I followed the procedure from your official website again:

When I run the command mtd erase /dev/mtd0 from the SD card and its official image, I get this warning:

I tried to reinstall the bootloader, recovery, etc. Nothing worked. From the emmc partition I can't boot. From the installation menu I get this:

    ( ( ( OpenWrt ) ) )  [SD card]       U-Boot 2024.10-OpenWrt-r28597-04256
  1. Run default boot command.
  2. Boot system via TFTP.
  3. Boot production system from SD card.
  4. Boot recovery system from SD card.
  5. Load production system via TFTP then write to SD card.
  6. Load recovery system via TFTP then write to SD card.
  7. Install bootloader, recovery and production to NAND.
  8. Reboot.
  9. Reset all settings to factory defaults.
  0. Exit

Press UP/DOWN to move, ENTER to select, ESC to quit
'spi-nand0' is now active device

spi-nand0
- device: spi_nand@0
- parent: spi@1100a000
- driver: spi_nand
- type: NAND flash
- block size: 0x20000 bytes
- page size: 0x800 bytes
- OOB size: 64 bytes
- OOB available: 24 bytes
- 0x000000000000-0x000008000000 : "spi-nand0"
  - 0x000000000000-0x000000200000 : "bl2"
  - 0x000000200000-0x000008000000 : "ubi"
  Erasing 0x00000000 ... 0x07dfffff (1008 eraseblock(s))
  Skipping bad block at 0x051c0000
  Skipping bad block at 0x051e0000
  Skipping bad block at 0x05200000
  Skipping bad block at 0x05220000
  Skipping bad block at 0x05240000
  Skipping bad block at 0x05260000
  Skipping bad block at 0x060e0000
  Skipping bad block at 0x06240000
  Skipping bad block at 0x06280000
  ubi0: default fastmap pool size: 50
  ubi0: default fastmap WL pool size: 25
  ubi0: attaching mtd2
  ubi0: scanning is finished
  ubi0: empty MTD device detected
  ubi0: attached mtd2 (name "ubi", size 126 MiB)
  ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
  ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
  ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
  ubi0: good PEBs: 999, bad PEBs: 9, corrupted PEBs: 0
  ubi0: user volume: 0, internal volumes: 1, max. volumes count: 128
  ubi0: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 0
  ubi0: available PEBs: 982, total reserved PEBs: 17, PEBs reserved for bad PEB handling: 11

MMC read: dev # 0, block # 90112, count 1024 ... 1024 blocks read: OK
Erasing 0x00000000 ... 0x001fffff (16 eraseblock(s))
Writing 524288 byte(s) (256 page(s)) at offset 0x00000000
Writing 524288 byte(s) (256 page(s)) at offset 0x00080000
Writing 524288 byte(s) (256 page(s)) at offset 0x00100000
Writing 524288 byte(s) (256 page(s)) at offset 0x00180000

MMC read: dev # 0, block # 92160, count 4096 ... 4096 blocks read: OK
Creating static volume fip of size 2097152
2097152 bytes written to volume fip
Creating dynamic volume ubootenv of size 1048576
Creating dynamic volume ubootenv2 of size 1048576

MMC read: dev # 0, block # 24576, count 256 ... 256 blocks read: OK

MMC read: dev # 0, block # 131072, count 256 ... 256 blocks read: OK

MMC read: dev # 0, block # 131072, count 414680 ... 414680 blocks read: OK

Checking Image at 50000000 ...

FIT image found
FIT description: ARM64 OpenWrt FIT (Flattened Image Tree)
Image 0 (kernel-1)
Description: ARM64 OpenWrt Linux-6.6.86
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x50001000
Data Size: 6808841 Bytes = 6.5 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x46000000
Entry Point: 0x46000000
Hash algo: crc32
Hash value: 595e82fe
Hash algo: sha1
Hash value: faba4646e7c881654687688c7e530a0940722bfc
Image 1 (fdt-1)
Description: ARM64 OpenWrt bananapi_bpi-r4 device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x50680000
Data Size: 48459 Bytes = 47.3 KiB
Architecture: AArch64
Load Address: 0x45f00000
Hash algo: crc32
Hash value: c4a7bb86
Hash algo: sha1
Hash value: 432fdc044fc25d62fbb2f29d53fd6cdab954c282
Image 2 (fdt-mt7988a-bananapi-bpi-r4-emmc)
Description: ARM64 OpenWrt bananapi_bpi-r4 device tree overlay mt7988a-bananapi-bpi-r4-emmc
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x5068c000
Data Size: 1546 Bytes = 1.5 KiB
Architecture: AArch64
Hash algo: crc32
Hash value: 809404dd
Hash algo: sha1
Hash value: f5315166f38bb1d9fdd6707c00ff3f91b87fa38f
Image 3 (fdt-mt7988a-bananapi-bpi-r4-rtc)
Description: ARM64 OpenWrt bananapi_bpi-r4 device tree overlay mt7988a-bananapi-bpi-r4-rtc
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x5068d000
Data Size: 285 Bytes = 285 Bytes
Architecture: AArch64
Hash algo: crc32
Hash value: 9e869883
Hash algo: sha1
Hash value: 343be366c4680b8d5f970ece19ea9970b91e5aad
Image 4 (fdt-mt7988a-bananapi-bpi-r4-sd)
Description: ARM64 OpenWrt bananapi_bpi-r4 device tree overlay mt7988a-bananapi-bpi-r4-sd
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x5068e000
Data Size: 1474 Bytes = 1.4 KiB
Architecture: AArch64
Hash algo: crc32
Hash value: 992dc95a
Hash algo: sha1
Hash value: d8c80e86d46ccac204bdcf81feb9ca2802402042
Image 5 (fdt-mt7988a-bananapi-bpi-r4-wifi-mt7996a)
Description: ARM64 OpenWrt bananapi_bpi-r4 device tree overlay mt7988a-bananapi-bpi-r4-wifi-mt7996a
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x5068f000
Data Size: 2289 Bytes = 2.2 KiB
Architecture: AArch64
Hash algo: crc32
Hash value: ee6079f2
Hash algo: sha1
Hash value: bbc22a8adc1c3224b7049acd410ad5fc0e60ac4f
Image 6 (rootfs-1)
Description: ARM64 OpenWrt bananapi_bpi-r4 rootfs
Type: Filesystem Image
Compression: uncompressed
Data Start: 0x50690000
Data Size: 205434880 Bytes = 195.9 MiB
Hash algo: crc32
Hash value: db983515
Hash algo: sha1
Hash value: d7c9e2da9ed6221ed30d3cac25b04d631b5823b4
Default Configuration: 'config-mt7988a-bananapi-bpi-r4'
Configuration 0 (config-mt7988a-bananapi-bpi-r4)
Description: OpenWrt bananapi_bpi-r4
Kernel: kernel-1
FDT: fdt-1
Loadables: rootfs-1
Configuration 1 (mt7988a-bananapi-bpi-r4-emmc)
Description: OpenWrt bananapi_bpi-r4 overlay mt7988a-bananapi-bpi-r4-emmc
Kernel: unavailable
FDT: fdt-mt7988a-bananapi-bpi-r4-emmc
Configuration 2 (mt7988a-bananapi-bpi-r4-rtc)
Description: OpenWrt bananapi_bpi-r4 overlay mt7988a-bananapi-bpi-r4-rtc
Kernel: unavailable
FDT: fdt-mt7988a-bananapi-bpi-r4-rtc
Configuration 3 (mt7988a-bananapi-bpi-r4-sd)
Description: OpenWrt bananapi_bpi-r4 overlay mt7988a-bananapi-bpi-r4-sd
Kernel: unavailable
FDT: fdt-mt7988a-bananapi-bpi-r4-sd
Configuration 4 (mt7988a-bananapi-bpi-r4-wifi-mt7996a)
Description: OpenWrt bananapi_bpi-r4 overlay mt7988a-bananapi-bpi-r4-wifi-mt7996a
Kernel: unavailable
FDT: fdt-mt7988a-bananapi-bpi-r4-wifi-mt7996a

Checking hash(es) for FIT Image at 50000000 ...

Hash(es) for Image 0 (kernel-1): crc32+ sha1+
Hash(es) for Image 1 (fdt-1): crc32+ sha1+
Hash(es) for Image 2 (fdt-mt7988a-bananapi-bpi-r4-emmc): crc32+ sha1+
Hash(es) for Image 3 (fdt-mt7988a-bananapi-bpi-r4-rtc): crc32+ sha1+
Hash(es) for Image 4 (fdt-mt7988a-bananapi-bpi-r4-sd): crc32+ sha1+
Hash(es) for Image 5 (fdt-mt7988a-bananapi-bpi-r4-wifi-mt7996a): crc32+ sha1+
Hash(es) for Image 6 (rootfs-1): crc32+ sha1+
Creating dynamic volume fit of size 212316160
ubi0 error: ubi_create_volume: not enough PEBs, only 947 available
ubi0 error: ubi_create_volume: cannot create volume 3, error -28
Press ENTER to return to menu

The fact that it detects faulty blocks does not give me confidence. Is it fixable or should I try to get a warranty?

sfx2000 · May 17, 2025, 12:21am

I just wonder if this is all related to things like the OKD issue over the the RT3200 thread, along with other random MediaTek devices...

They all tend to center on badblock detection...

@psherman - dangowrt is probably the right person to look into this, but I'm not seeing a way to reach out to him on the forum here...

psherman · May 17, 2025, 12:37am

Yeah, no account here, from what I can tell. Probably GitHub or wherever else they have a presence.

aLiArLa · May 18, 2025, 8:47am

HIs, thanks you for replying. At the moment I have sent a message to the supplier informing them of the problems with the bad blocks. The bad blocks cannot be repaired and I am concerned that it could go further.
Currently I managed to reinstall boot and openwrt on the nand and emmc memory but I am worried that over time it will become more damaged.

elder_tinkerer · May 18, 2025, 2:06pm

It's @daniel.

psherman · May 18, 2025, 2:23pm

Apologies. I didn’t know. Thanks for the pointer!!

sfx2000 · May 18, 2025, 11:54pm

@elder_tinkerer - Good to know - anyways, there's been a lot of smoke around MTK chipsets and badblock reporting - the Belkin RT3200 devices have been impacted quite a bit around similar issues, and I've seen issues reported on some of the GL-Inet MTK Filogic boards with similar issues.

Now that we're seeing this on BPI-R4, it's just more gas on that fire, whatever it might be - I'm not saying they're all related from a root-cause perspective, but outcomes do seem similar...

@daniel - any thoughts here?

sfx2000 · May 19, 2025, 2:32am

Looks like another MTK issue here with badblock...

aLiArLa · May 19, 2025, 7:54am

I have reported it to the seller for the moment. He has asked me for the complete logs and I have sent them to him. I will let you know what he says

daniel · May 19, 2025, 2:03pm

That's quite a lot of bad blocks for a supposedly new flash chip, and if I were you I'd ask for replacement hardware.

@sfx2000 The issues we have on MT7622 (Berlin RT3200) were related to a software problem in MediaTek's ARM TrustedFirmware-A and the slightly exotic SPI-NAND controller handling ECC in the SoC which got a BCH ECC engine originally intended for parallel NAND flash (instead of using the built-in ECC capabilities of the SPI -NAND flash chip). The problem was that correctable bit-flips wrongly resulted in fatal errors.

With MT7986 and newer this became obsolete, all board manufacturers use the ECC capabilities of the flash chip itself instead of the SoC's BCH engine (which is still present but considered deprecated/unsupported hardware).

Now what we are seeing here are actual bad blocks reported by the flash chip itself, so that's simply a broken flash chip and got nothing to do with MediaTek's SoC (which, in this case, provides just a generic SPI host controller to connect the SPI-NAND flash chip).

The fact that even the pre-loaded firmware of BananaPi/SinoVoip also reports the exact same errors, both in Linux and U-Boot, also clearly hints to a hardware problem with the flash chip.

daniel · May 19, 2025, 2:06pm

This looks like you are trying to flash a firmware (from the microSD card) which is way to big to fit on the flash -- even if there weren't any bad blocks. Try using the sdcard image from download.openwrt.org instead.

aLiArLa · May 19, 2025, 2:26pm

Hi, first of all thank you very much for your interest in my problem. As you say, I tried with a smaller firmware and it worked fine. That doesn't mean that, as you say, as it is a new board, it is not normal to have so many bad blocks.
I'm dealing with the problem with the manufacturer (although he told me it's a software problem), now I have to prove it's hardware

sfx2000 · May 20, 2025, 2:06am

That's a lot of bad blocks in sequence...

aLiArLa · May 20, 2025, 8:21am

Hi, I update info on what the seller has told me. I copy-paste from his message:

According to international regulations, NAND is allowed to have bad blocks as long as it is within the specification range.

If it exceeds the number written in the following specification sheet, it is hardware failure and can be returned to the factory for replacement.

Please use the command nmbm nmbm0 bad in uboot to check the number of bad blocks on the nand.

1、If there are more than 20 bad blocks, I can replace it for you.

2、If you find it troublesome, you can use mtd write to burn, which will bypass bad blocks.

Like this:

best regards

*I have tried different versions of u-boot and none of them have the nmbm command.

*update 2: have found some other commands that I think might work. According to the attached screenshot, I have 9 bad blocks but according to the screenshot, I think it can only handle up to 11 bad blocks

daniel · May 20, 2025, 12:41pm

Permitting up to 20 bad blocks (20 out of 1024 ~ 2%) from factory seems a lot, but if that's how Winbond defines that the chip is "ok" there probably isn't much you can do about it.

Regarding nmbm: That's a proprietary, MediaTek-specific legacy bad block management system. We try to avoid it in OpenWrt as UBI as much more suitable for this task. So in OpenWrt-built U-Boot we generally use UBI instead, while on some devices for which we try to remain compatible with the stock/vendor bootloader we do support NMBM (and BMT, and BMTv2, which are the previous iterations of MediaTek's exotic attempts to manage bad blocks on NAND chips) in Linux.

UBI tells you that it could handle 11 more on top of those 9, as the 9 were already there when creating the UBI structure. So that's not a problem.

aLiArLa · May 20, 2025, 3:03pm

Ok now I understand, I thought I only had 2 margins left and not 11 more. The seller has also given me the option to process the warranty to return the board. That's what I will do.