How does it work

[tilator]

Hello,

I have a full NAND dump having SBL and all. EEC etc. has been removed. File size is exactly 128MB after that while the original dump is bigger.

Can this script be used to patch it all by one command or does it take to separate SBL from the rest first, pad them separately using different commands and then concatenating them back together?

[ecsv]

Can this script be used to patch it all by one command or does it take to separate SBL from the rest first, pad them separately using different commands and then concatenating them back together?

This depends on your HW. If it is a HW which uses BCH8 for everything then you can just run the script on the whole file. If it is a HW which uses different algorithm for different regions then you need to split your file, run the script with the different modes against the different files and then just concat the outputs together.

I was lucky and worked mostly on cypress/hawkeye HW with separate NOR for calibration/SBL/u-boot/...,when I needed to prepare the burn files for production - so using BCH8 on the whole NAND file was enough to get the correct result in my case.

And I don't know any details about the HW and the different versions. When I've tried to contact QCA about it, they did just send me my own README file (from this repository) to me.

[tilator]

When I've tried to contact QCA about it, they did just send me my own README file (from this repository) to me.

Maybe they tried to be funny.

My device is Xiaomi CPE having IPQ5018. I suppose sdx55 is the same device.

Can I somehow read the information from the dump itself?

[ecsv]

Can I somehow read the information from the dump itself?

Not 100% sure what information you are searching for. If it is "do i need a different ECC algo for different regions" then you can only do this using the original dump (which didn't had the ECC stripped and is therefore larger than 128 MB). There you could check the ECC bytes and see if they are 7, 8, 13, 14 or 10 bytes long. Depending on this, it is possible to identify the used algorithm.

If you really have only the dump without ECC... then I wouldn't know how to do this. But let us assume that it is a single algorithm (BCH) for the whole flash - which is to all information I could gather is the case for IPQ501x - then you still must make sure that you know if BCH4/BCH8 is selected. This is done using ECC strength selection by the NAND chip.

You can usually also find the ECC strength requirement in the datasheet of the ONFI NAND chip. But rule of thumb seems to be: 2048 page size BCH4 ("4-bit ECC per (512+16)B", OPTION CODE: "18A=4-bit ECC Requirement with standard feature"), 4096 page size BCH8 ("8-bit ECC per (512+32)B", OPTION CODE: "28A=8-bit ECC Requirement with standard feature").

Might I know why you actually need this? Usually, you would only care about this when you are flashing a NAND chip outside of the actual device. In this case, you need to emulate what the NAND controller would have done when it writes to the flash.

[tilator]

I have both whole dump and ECC removed version.

Nand chip seems to be ESMT F50D1G41LB

[ecsv]

Nand chip seems to be ESMT F50D1G41LB

This is an SPI-NAND (spi-qpic-snand.c) flash and not an ONFI-NAND (qcom_nandc.c). I don't know if the former i actually using the same layout and ECC implementations as the qcom-nandc (for which this repo is)

But I can tell you at least that the used algorithm is specified in the devicetree (which you should be able to extract from the original image via binwalk). Search for nand-ecc-strength to see if it is BCH4 or BCH8. If it isn't specified then it should by default BCH4. Because the fallback is always BCH4 and the datasheet requires only 1 bit per 512 (which seems to be rounded up to 4-Bit)

[tilator]

I suppose it has to be BCH4 because the binary has nand-ecc-strength string at least a dozen times but without any value tailing it.

Do you know how it (=u-boot and kernel image) handles a situation where ECC can't correct a fault or if ECC is empty (filled with FF)?

[ecsv]

Do you know how it (=u-boot and kernel image) handles a situation where ECC can't correct a fault or if ECC is empty (filled with FF)?

No, I don't know this for the SPI driver and HW. You can look around qcom_spi_check_error to make sense out of the code in the Linux kernel. For the u-boot part, you can have a look at https://nest-open-source.googlesource.com/manifest_repos/bootloader/+/refs/heads/main/drivers/mtd/nand/qpic_nand.c around qpic_nand_check_read_status. It seems like it would create an -EBADMSG error in case on an incorrect ECC.

But of course, I can't also say for sure what the HW actually does and report for some special "magic" values. But I would assume that it doesn't handle this as magic values and really just uses 0xFF....FF as actual ECC and tries to use it.

I suppose it has to be BCH4 because the binary has nand-ecc-strength string at least a dozen times but without any value tailing it.

If it is from the device tree then the value is binary (u32) encoded. You would need to extract the deviceetree (binwalk -e or dumpimage -T flat_dt .... can help here) and then try to decompile it using dtc -I dtb -O dts -s -o decompiled.dts input.dtb).