Possible issue on a Fritz 7530 TC58NVG0S3HTA00 variant

[mjw99]

I am not sure if here is correct place to log this or whether to use the OpenWrt issue tracker. Feel free to close it if it is the incorrect
place.

1. With a FRITZ!BOX 7530 and following the install guide here:

(Note, one is using the snapshot versions in all steps; hence I am using the latest FritzBox-4040-UBOOT )

2. It fails to boot. Connecting a serial terminal, the following is seen

....SNIP.....

(AVM) EVA Revision: 1.11835 89cbcf9c
(C) Copyright 2018 AVM Date: Mar  4 2022 Time: 11:09:07 (0) 3 0x0-0x46409

[NAND:] 128MB TOSHIBA 2048 Pagesize 128k Blocksize 1024 Blocks HW
[SYSTEM:] CortexA9 

Eva_AVM >.....
Using Device Tree Blob of SubRevision 2 


U-Boot 2012.07 [local,r22344-ca330cac92] (Mar 21 2023 - 00:11:18)

smem ram ptable found: ver: 1 len: 3
DRAM:  256 MiB
machid : 0x8010001
cdp: SMEM init failed
Maximum malloc length: 512 KBytes
mem_malloc_start/brk/end: 0x84140000/84140000/84200000
Relocation offset: 0
NAND:  Not an ONFI device
ONFI probe failed
ID = 1580f198
Vendor = 98
Device = f1
=================================
Fixup for Toshiba TC58NVG0S3HTA00
=================================
SF: Unsupported manufacturer ff
ipq_spi: SPI Flash not found (bus/cs/speed/mode) = (0/0/48000000/0)
128 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
name         : offset   size    
0:SBL1       : 00000000 00080000
0:MIBIB      : 00080000 00080000
0:QSEE       : 00100000 00080000
0:QSEE_B     : 00180000 00080000
0:APPSBL_B   : 00200000 00040000
0:APPSBL     : 00240000 00040000
machid: 8010001
Net:   Configure GPIOSRead 1024 bytes from 02bd800
maca pointer invalid: ffffffff
MAC0 addr:0:3:7f:ba:db:ad
PHY ID1: 0x4d
PHY ID2: 0xd0b1
ipq40xx_ess_sw_init done
eth0
Hit any key to stop autoboot:  0 
Creating 1 MTD partitions on "nand1":
0x01300000-0x08000000 : "mtd=4"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: max. sequence number:       2618
UBI warning: print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, reserved 5, need 8
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -12
UBI init error 12
eth0 PHY0 Down Speed :10 Half duplex
eth0 PHY1 Down Speed :10 Half duplex
eth0 PHY2 Down Speed :10 Half duplex
......etc.....

Also, I am not sure if this may be relevant as well

[blocktrron]

Can you post a photo of the board, especially of the NAND chip?

In case the camera quality is not sufficient to identify the part-number, please also write the markings found on the NANd flash chip.

[mjw99]

[andyboeh]

Is this before or after the installation of the OpenWrt snapshot?
Did you compile U-Boot yourself or did you use the version available in OpenWrt's snapshot directory?

The output you get is only from U-Boot while the linked commit (revert) refers to the Linux kernel. Fact is, the patch that was reverted screwed up proper detection of well-behaving flash chips.

[mjw99]

Thanks for looking at this

Is this before or after the installation of the OpenWrt snapshot?
After

Did you compile U-Boot yourself or did you use the version available in OpenWrt's snapshot directory?
I used the one in OpenWrt's snapshot directory

[andyboeh]

Hm, the patches for the NAND are still included in OpenWrt (the one that was reverted upstream). Compare that to the symptoms I had in #7
Can you check if the MAC address is correct? Without the fixup, the MAC address on my box was reported incorrectly.

[mjw99]

Sorry for the delay in this. The MAC address is incorrect:

Net:   Configure GPIOSRead 1024 bytes from 02bd800
maca pointer invalid: ffffffff
MAC0 addr:0:3:7f:ba:db:ad
PHY ID1: 0x4d
PHY ID2: 0xd0b1
ipq40xx_ess_sw_init done
eth0

I have also tried this again with 23.05.0-rc4/ ( all binaries taken from https://downloads.openwrt.org/releases/23.05.0-rc4/targets/ipq40xx/generic/ and https://downloads.openwrt.org/releases/23.05.0-rc4/targets/ipq40xx/generic/u-boot-fritz7530/ ) but I am still seeing the same.

Interestingly, the avm_fritzbox-7530-initramfs-uImage.itb dmesg reports this:

[    1.225046] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xf1
[    1.225498] nand: Toshiba TC58NVG0S3HTA00 1G 3.3V 8-bit
[    1.232142] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
[    1.237185] 11 fixed-partitions partitions found on MTD device qcom_nand.0
[    1.244692] Creating 11 MTD partitions on "qcom_nand.0":
[    1.251677] 0x000000000000-0x000000080000 : "SBL1"
[    1.258425] 0x000000080000-0x000000100000 : "MIBIB"
[    1.262749] 0x000000100000-0x000000180000 : "QSEE"
[    1.267664] 0x000000180000-0x0000001c0000 : "CDT"
[    1.272128] 0x0000001c0000-0x000000240000 : "QSEE_B"
[    1.277158] 0x000000240000-0x000000280000 : "urlader0"
[    1.281970] 0x000000280000-0x0000002c0000 : "urlader1"
[    1.287003] 0x0000002c0000-0x000000b00000 : "nand-tffs"
[    1.299880] 0x000000b00000-0x000000f00000 : "uboot0"
[    1.304460] 0x000000f00000-0x000001300000 : "uboot1"
[    1.309089] 0x000001300000-0x000008000000 : "ubi"

[mjw99]

OK, I have had some success; the main problem has been the number of badblocks on the NAND, i.e.

UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: max. sequence number:       2618
UBI warning: print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, reserved 5, need 8
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -12

There was also a similar discussion here about this: https://forum.openwrt.org/t/avm-fritzbox-7520-openwrt-snapshot/157950/4

Looking at the AVM bootloader, via serial, this is also reflected there:

Not an ONFI device
Building bad block table from 0 to 1024 of max blocks 1024
[nand_block_is_bad]<block 0x3420000 not valid>
bad block found at address 03420000, setting entry 1
[nand_block_is_bad]<block 0x3460000 not valid>
bad block found at address 03460000, setting entry 2
[nand_block_is_bad]<block 0x34A0000 not valid>
bad block found at address 034A0000, setting entry 3
[nand_block_is_bad]<block 0x34C0000 not valid>
bad block found at address 034C0000, setting entry 4
[nand_block_is_bad]<block 0x3560000 not valid>
bad block found at address 03560000, setting entry 5
[nand_block_is_bad]<block 0x4120000 not valid>
bad block found at address 04120000, setting entry 6
[nand_block_is_bad]<block 0x4140000 not valid>
bad block found at address 04140000, setting entry 7
[nand_block_is_bad]<block 0x4160000 not valid>
bad block found at address 04160000, setting entry 8
[nand_block_is_bad]<block 0x4240000 not valid>
bad block found at address 04240000, setting entry 9
[nand_block_is_bad]<block 0x4280000 not valid>
bad block found at address 04280000, setting entry A
[nand_block_is_bad]<block 0x42C0000 not valid>
bad block found at address 042C0000, setting entry B
[nand_block_is_bad]<block 0x46E0000 not valid>
bad block found at address 046E0000, setting entry C
[nand_block_is_bad]<block 0x4760000 not valid>
bad block found at address 04760000, setting entry D
[nand_block_is_bad]<block 0x6000000 not valid>
bad block found at address 06000000, setting entry E

(AVM) EVA Revision: 1.11835 89cbcf9c
(C) Copyright 2018 AVM Date: Mar  4 2022 Time: 11:09:07 (0) 3 0x0-0x46409

It is difficult to comprehend why there are so many badblocks on a brand new unit.

From this point onwards, I used all binaries from https://downloads.openwrt.org/releases/23.05.0/targets/ipq40xx/generic/ since it was finally populated last night.

Initially, from u-boot, I tried the reset these badblocks:

nand scrub.part ubi

This had limited joy, since the badblocks reappeared during the UBI volume creation.

Next, after booting the OpenWRT ram image via TFTP and running the sysupgrade, and then rebooting again. The current state of the UBI was:

root@(none):/# ubinfo -d 0
ubi0
Volumes count:                           3
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     858 (108945408 bytes, 103.8 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       14
Count of reserved physical eraseblocks:  6
Current maximum erase counter value:     6
Minimum input/output unit size:          2048 bytes
Character device major/minor:            245:0
Present volumes:                         0, 1, 2


root@OpenWrt:/# ubinfo -d 0 -n 0
Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        25 LEBs (3174400 bytes, 3.0 MiB)
State:       OK
Name:        kernel
Character device major/minor: 245:1

root@OpenWrt:/# ubinfo -d 0 -n 1
Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        34 LEBs (4317184 bytes, 4.1 MiB)
State:       OK
Name:        rootfs
Character device major/minor: 245:2

root@OpenWrt:/# ubinfo -d 0 -n 2
Volume ID:   2 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        789 LEBs (100184064 bytes, 95.5 MiB)
State:       OK
Name:        rootfs_data
Character device major/minor: 245:3

Next, I resized the number 2 ubi volume, i.e. rootfs_data

ubirsvol /dev/ubi0 -n 2 -s 60184064

This worked, at the expense of some disk space. The router now boots OpenWrt from the NAND and works. I did attempt the value of 80184064 to the above command initially, but this also failed.

Thanks again for all your help on this David and Andy; I think this issue can be closed.