nand_read_bbt: bad block

[toyota]

Hi,
having 2 months old Solo2 with recent OpenPli4.
Couple of weeks ago I found in /var/log/messages errors, regarding detected bad blocks in nand memory. Shall I call for warranty? Asked support on vuplus.com, but haven't got any response yet. Do they support retail customers?

extract from log:
NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
brcmnand brcmnand.0: 256MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, Hamming ECC
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: bad block at 0x000007b20000
nand_read_bbt: bad block at 0x000009480000
nand_read_bbt: bad block at 0x00000d2a0000
nand_read_bbt: bad block at 0x00000fac0000

 

[Matrix10]

ONLY Info

It is in the nature of NAND Flash that a small proportion of the blocks in the device are defective and therefore unusable from the day of manufacture (typically up to 1% is deemed acceptable by the manufacturer). Manufacturers perform thorough testing to identify any potentially bad blocks. When they have been identified, bad blocks are marked with a special marker in the OOB area of the block. This is the Manufacturer's Bad Block Marker (MBBM).

RAM resident BBT
RAM-resident BBTs are volatile and must be recreated every time the system is booted. The process involves scanning each block in the NAND device to check for bad block markers.

The main advantage of this approach is simplicity. This is particularly true for manufacturability, where is is possible for a generic NAND programmer to program pre-prepared images without the need to understand the underlying ECC scheme or any BBT formats.

There are, however, a number of disadavantages. In some cases these disadvantages preclude the use of RAM-resident BBTs.
NAND resident BBT
The use of NAND-Resident BBTs overcomes many of the issues associated with RAM-resident BBTs. For most cases this is the recommended method for recording and tracking bad blocks.

As a NAND-resident BBT is non-volatile, it is preserved across system boots. There should never be any reason to recreate the BBT by scanning the NAND device for bad block markers.

Typically, the BBT requires two bits of storage for each block. The table is stored in the last good block with a backup in the penultimate good block. By default, the last four physical blocks are reserved for BBTs. If there are fewer than two good blocks available in the last four, then the NAND device should be discarded.

In a ideal situation, the BBT should be built and written to Flash before any other data. This is mandatory in cases where it is not possible to use the ECC tags to distinguish between valid programmed ECC data and anMBBM. However, this has implications for manufacturability, as the NAND programmer needs to be taught how to write the BBT, including the relevant ECC scheme.

In some cases, it may be appropriate for the NAND Programmer to skip writing BBTs, and to defer BBT creation to the software drivers when the system is first booted. This avoids the complexities of customising the NAND Programmer, whilst retaining the benefits of using NAND-resident BBTs. This approach is only viable if there is no clash between the ECC layout and the MBBM location, or where ECC tags can be used to avoid ECC data being misinterpreted as a MBBM.

 

[amdsquad]

I don't see any similar input in my log file so if you still have warranty I would try to send it to them to look after it.


Wysłane z mojego iPad przez Tapatalk

 

[Matrix10]

I can see in DUO2 bad blocks

It is more or less normal
Of course if you do not have completely defective nand

Jan 1 01:00:17 vuduo2 user.info kernel: Bad block table found at page 524224, version 0x01
Jan 1 01:00:17 vuduo2 user.info kernel: Bad block table found at page 524160, version 0x01
Jan 1 01:00:17 vuduo2 user.info kernel: nand_read_bbt: bad block at 0x000011840000
Jan 1 01:00:17 vuduo2 user.info kernel: nand_read_bbt: bad block at 0x000023200000
Jan 1 01:00:17 vuduo2 user.info kernel: nand_read_bbt: bad block at 0x000023220000
Jan 1 01:00:17 vuduo2 user.info kernel: nand_read_bbt: bad block at 0x000028960000
Jan 1 01:00:17 vuduo2 user.info kernel: nand_read_bbt: bad block at 0x00003c940000

 

[amdsquad]

I do have relatively new solo2 maybe that's why there is nothing yet.


Wysłane z mojego iPad przez Tapatalk

 

[Matrix10]

I do have relatively new solo2 maybe that's why there is nothing yet.


Wysłane z mojego iPad przez Tapatalk

I do not believe that it has a strong impact new or old
bad block is more a result of the manufacturing process
Of course it is possible to see a few blocks later
But I think that is not anything critical.
I've never had a problem with it in the last ten years with any box.
I have Test images and skins.
Flash images hundreds of times.

 

[jwlalek]

This is what I've found in my log (the mainboard is just 1,5 months old)

Mar 13 15:01:33 vuduo2 user.info kernel: Bad block table found at page 524224, version 0x01
Mar 13 15:01:33 vuduo2 user.info kernel: Bad block table found at page 524160, version 0x01
Mar 13 15:01:33 vuduo2 user.info kernel: nand_read_bbt: bad block at 0x000009640000
Mar 13 15:01:33 vuduo2 user.info kernel: nand_read_bbt: bad block at 0x0000193a0000
Mar 13 15:01:33 vuduo2 user.info kernel: nand_read_bbt: bad block at 0x000039120000

 

[toyota]

ok, thanx all

 

[Jan-Egil Jakobsen]

this is on my Duo2 soon 1 yr old 19 jan 2016
NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB 3,3V 8-bit)
NAND device: 1024MiB, SLC, page size: 2048, OOB size: 64
brcmnand brcmnand.0: 1024MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, Hamming ECC
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
nand_read_bbt: bad block at 0x000002d60000
nand_read_bbt: bad block at 0x00003af00000
nand_read_bbt: bad block at 0x00003c8a0000