1000+ "Bad EC magic in block" notifications on NAND boot

Banana Pi Router design BPI-R4/BPI-R4 Pro(MT7988)
1

Hi, After flashing the NAND drive with a native OpenWRT image, I get a long list of complaints about Bad EC magic blocks. Just over a thousand blocks appear to be bad.

NOTICE:  SPI_NAND Detected ID 0xef
NOTICE:  Page size 2048, Block size 131072, size 268435456
NOTICE:  UBI: scanning [0x200000 - 0x10000000] ...
NOTICE:  UBI: Bad EC magic in block 1008 ffffffff
      .
      .
      .
NOTICE:  UBI: Bad EC magic in block 2010 ffffffff
No size specified -> Using max size (22474752)

I find this disturbing to be sure. But truthfully I’m not sure what it means:

  • Is the NAND damaged?
  • Was there a problem with the flashing process?
  • Is 1000 bad blocks a drop in the bucket, and so nothing to worry about?

Of note, dmesg seems to report PEBs are all good.

root@OpenWrt:~# dmesg | grep bad
[    1.677758] ubi0: good PEBs: 1008, bad PEBs: 0, corrupted PEBs: 0
[    1.699391] ubi0: available PEBs: 0, total reserved PEBs: 1008, PEBs reserved for bad PEB handling:

Can anyone shed some light on these messages?

Many thanks,

2

Afaik this should come only once when ubi is not completely initialized.init is done on first linux boot,but uboot is first and try to read invalid blocks. After reboot uboot should be clean too.

3

Hmmm. I get the same message on every boot.

I re-flashed the drive and the message still comes up on each boot.

This is the relevant output from the NAND flash installer (second install),

'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:          128 bytes
  - OOB available:     56 bytes
  - 0x000000000000-0x000010000000 : "spi-nand0"
	 - 0x000000000000-0x000000200000 : "bl2"
	 - 0x000000200000-0x000008000000 : "ubi"
Erasing 0x00000000 ... 0x07dfffff (1008 eraseblock(s))
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: 1008, bad PEBs: 0, 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: 962, total reserved PEBs: 46, PEBs reserved for bad PEB handling: 40
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 # 24576, count 29711 ... 29711 blocks read: OK

And here are some possibly relevant details from the booted system,

root@OpenWrt:~# lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
mtdblock0      31:0    0    2M  1 disk 
mtdblock1      31:1    0  126M  0 disk 
mmcblk0       179:0    0  7.3G  0 disk 
├─mmcblk0p1   179:1    0  512K  0 part 
├─mmcblk0p2   179:2    0    2M  0 part 
├─mmcblk0p3   179:3    0    4M  0 part 
├─mmcblk0p4   179:4    0   32M  0 part 
├─mmcblk0p5   179:5    0  448M  0 part 
└─mmcblk0p128 259:0    0    4M  0 part 
mmcblk0boot0  179:8    0    4M  1 disk 
mmcblk0boot1  179:16   0    4M  1 disk 
ubiblock0_4   254:0    0 21.3M  0 disk 
fit0          259:1    0 15.6M  1 disk /rom

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00200000 00020000 "bl2"
mtd1: 07e00000 00020000 "ubi"

I mean, I’m totally new to flash drives, but the sizes checkout with the BananaPi NAND specs.

Still these warnings are unsettling.

4

Then i guess the size of nand for r4pro is not correct in linux and so init does not fill all blocks with valid data.

Which exact image / code do you use?

5

Indeed @frank-w looks like the NOTICE is from ATF which knows it is 256GB.

NOTICE: UBI: scanning [0x200000 - 0x10000000] … N

U-Boot and linux both have 128GB

0x000000200000-0x000008000000 : “ubi”

mtd1: 07e00000 00020000 “ubi”

6

R4pro has double the nand size as R4

Maybe image stil uses r4 dts in linux (uboot isn’t important for this but should match too). Init is done in linux.

7

It would depend also on the size that U-boot has here for the ubi partition when flashing this image. If it is only 128GB, it would explain the errors …

8

This corrupted NAND error, along with other errors I’ve detected with OpenWrt, has been reported by me to the Banana Pi team privately. Here is their response; I am waiting for it.

They even have a video demonstrating all the boot failures caused by the corrupted NAND, plus other problems with the OpenWRT INA2xx sensor.

Dear friend,

We have conveyed your feedback to our engineering team. They will schedule time to reproduce the issue you described and will prepare relevant operation instructions for you.

Please rest assured that we are working on this. We kindly ask for your patience and thank you for your understanding.

Best regards,

Mia

--------------Original Message-------------- Sent: May 10, 2026 (Sunday) 7:29 PM To: “Li Yuyan” [email protected]; CC: “Sales” [email protected]; “Klaus Chen” [email protected]

9

Afaik there is no such sensor in hardware. It is only defined in software (bpi/mtk dts) but not soldered and so give a error on bootup that it is not found/responding.

10

Hi, Just getting back to my computer. Thanks for the responses.

@frank-w For the record it’s a BPR4 (not the Pro)

@Xiaomi_ax3600 Please let me know how your support call works out.

11

Ok,this sorted out the issue i’ve seen. You should see in linux the ubi initialization. Please post this part of bootlog please. I guess somehow this is not correct. Mtd definition in uboot and linux regarding the ubi should match,maybe start of ubi is different. Wonder why your ubi size in linux is only 21MB

12

Arm Trusted Firmware thinks your Nand is 256GB.

Does the 8GB R4 have a larger Nand?

13

When I remove power and immediately reapply it (fast power cycle), I get this error:

text
F0: 102B 0000
FA: 1042 0000
FA: 1042 0000 [0200]
F9: 1041 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 380E 5012
F5: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0600 0041 [0000]
G0: 1190 0000
EC: 0000 0000 [3000]
MK: 0000 0000 [0000]
T0: 0000 01F3 [0101]
Jump to BL

NOTICE:  BL2: v2.10.0   (release):OpenWrt v2024.01.17~bacca82a-3 (mt7988-sdmmc-comb)
NOTICE:  BL2: Built : 03:09:13, Jun 17 2025
NOTICE:  WDT: Cold boot
NOTICE:  WDT: disabled
NOTICE:  CPU: MT7988
NOTICE:  EMI: DDR4 4BG mode
NOTICE:  EMI: Using DDR unknown settings
NOTICE:  EMI: Detected DRAM size: 8192 MB
NOTICE:  EMI: complex R/W mem test passed
ERROR:   MSDC: CRC error occured while reading data with cmd=18, arg=0x3400
ERROR:   BL2: Failed to load image id 3 (-2)
This shows:

The CRC error occurs in BL2, before U-Boot even loads

The problem is related to MMC bus instability during early boot

When the WiFi card is ON during this phase, it causes interference on the MMC bus

Evidence 2 – The workaround (works 100% of the time) This is the procedure that works every time:

Power off the router completely (disconnect power cable)

With the WiFi card set to OFF, apply power

Wait for the U-Boot menu to appear

At this moment (or even a few seconds later, as the kernel is loading), turn the WiFi card ON

I have recorded a video demonstrating this procedure. I will send it to you separately.

What happens after this:

:white_check_mark: The BE14 WiFi card is detected and works perfectly

:white_check_mark: You can reboot via SSH or the web interface and the WiFi card remains detected

What happens if you remove power completely and start with WiFi ON:

:x: The WiFi card is NOT detected

What this proves: :white_check_mark: The hardware is fully functional :white_check_mark: The issue is software / boot timing :white_check_mark: The fix requires a patch in U-Boot or a delay in the PCIe / MMC initialization

What I need from you: An official patch for U-Boot to solve this problem permanently

Or, at minimum, official documentation of this workaround for users until a proper fix is released

I have recorded a full video showing:

The CRC error on fast power cycle

The OFF→ON workaround (including that it works even if you turn WiFi ON a few seconds later, not exactly at the menu)

The successful boot with WiFi detected and working

Subject: Reproducible mt7996e probe -11 on original NAND image —

Hello Mia / Klaus / 李玉燕,

Update: after keeping the router powered off for ~3 hours, I tested again using the original NAND image you provided (no changes). and insert it again.

Here are the key boot log lines showing the failure (mt7996e patch timeouts and probe -11):

[ 56.165611] mt7996e 0000:01:00.0: Message 00000007 (seq 12) timeout
[ 76.645602] mt7996e 0000:01:00.0: Message 00000007 (seq 13) timeout
[ 97.131852] mt7996e 0000:01:00.0: Failed to start patch
[ 158.571764] mt7996e 0000:01:00.0: Failed to release patch semaphore
[ 159.460364] mt7996e: probe of 0000:01:00.0 failed with error -11
[ 159.004909] Trying to free already-free IRQ 104

be14000

Here is the NAND corruption error I see:

text root@OpenWrt:~# fdisk -l Disk /dev/ubiblock0_4: 100.02 MiB, 104882176 bytes, 204848 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optical): 512 bytes / 512 bytes

Disk /dev/mtdblock0: 2 MiB, 2097152 bytes, 4096 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optical): 512 bytes / 512 bytes

Disk /dev/mtdblock1: 4 MiB, 4194304 bytes, 8192 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optical): 512 bytes / 512 bytes

Disk /dev/mtdblock2: 250 MiB, 262144000 bytes, 512000 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optical): 512 bytes / 512 bytes

Disk /dev/mtdblock3: 256 MiB, 268435456 bytes, 524288 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optical): 512 bytes / 512 bytes The backup GPT table is corrupt, but the primary appears OK, so that will be used. The backup GPT table is not on the end of the device.

Disk /dev/mmcblk0: 58.3 GiB, 62599987200 bytes, 122265600 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optical): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 5452574F-2211-4433-5566-778899AABB00

Device Start End Sectors Size Type /dev/mmcblk0p1 34 8191 8158 4M Linux filesystem /dev/mmcblk0p2 8192 9215 1024 512K Linux filesystem /dev/mmcblk0p3 9216 13311 4096 2M Linux filesystem /dev/mmcblk0p4 13312 21503 8192 4M EFI System /dev/mmcblk0p5 24576 286719 262144 128M EFI System /dev/mmcblk0p6 286720 327679 40960 20M EFI System /dev/mmcblk0p7 327680 1245183 917504 448M unknown

Disk /dev/fit0: 93.38 MiB, 97914880 bytes, 191240 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optical): 512 bytes / 512 bytes

Disk /dev/fitrw: 347.99 MiB, 364892160 bytes, 712680 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optical): 512 bytes / 512 bytes

Disk /dev/sda: 59.48 GiB, 63864569856 bytes, 124735488 sectors Disk model: STORAGE DEVICE Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optical): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x38da4a7d

Device Boot Start End Sectors Size Id Type /dev/sda1 2048 124735487 124733440 59.5G 83 Linux

李玉燕 Archivos adjuntos vie, 8 may, 12:04 (hace 12 días) para mí, Sales, Klaus Chen

Dear friend,

Additionally, there is another issue regarding a WiFi software timeout. We still need some time to test it and will get back to you then.

Best regards, Mia

Banana PI original Developer & Manufacturer

Mia Li SINOVOIP CO.,LIMITED BANANAPI TECH LIMITED

Tel.: +86 755-2647-5332 |Mob: +86 15018467241
Email: [email protected] www.banana-pi.com www.banana-pi.org www.sinovoip.com.cn
BPI Wiki page: Banana Pi Main Page | BananaPi Docs (banana-pi.org) Shenzhen Address:3F, Block B,Digital Bldg. Garden City, No.1079 Nanhai Avenue, Shekou, Nanshan District , Shenzhen, Guangdong , China Dongguan Address:7/F, Rongyi Building, NO.5 Information Rd., Songshan Lake High-tech Industrianl Park, Dongguan 地址： 东莞市松山湖技术产业开发区信息路5号融易大厦七楼701室

14

Sorry, I’m not from bananapi, just a hobby enthousiast.

15

Good morning @ericwoud . I accidentally tagged you; it wasn’t meant for you. I apologize.

Have a good day.

16

It may help to lower the frequency of MMC in ATF.

17

Good morning. If you’d like to collaborate, my repositories are available to you; there are no rules in place.

Thank you for your help.

18

Thanks, but I do not use openwrt.

19

Good afternoon, could you tell me what you use and let me try one of your images? I’ve always used OpenWrt.

I’m eager to discover new things.

Thanks

20

ArchLinuxARM, but I haven’t got a R4pro to test any image. I think it won’t work yet, until I get one and iron out the bugs. But mostly it is the amount of time I have available, that I haven’t moved.on to R4pro.