-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
what is polynomial have to give for broadcom controllers? #1
Comments
The README lists the polynomial used for T=4, N=13: 0x201b. It's not clear whether that is used by all controllers, or indeed in all situations. |
Hi,
Many thanks for your reply,
I'm using t=4 and M =14 and polynomial I use is 0x402b but the ecc data is
not matching with broadcom hardware controller.
You mean shift bye right is not for field order M =14. Is it correct?
Any idea how to match the ecc data with broadcom controller?
I have some ecc data which is generated by broadcom code, but my idea is to
create as open source code. But I don't understand encoding part of
broadcom. If you have any idea please let me know.
That's very much appreciated.
Thanks again for your help
Best regards
Prakash
…On Sat, Apr 11, 2020, 18:29 StrayLightning ***@***.***> wrote:
The README lists the polynomial used for T=4, N=13: 0x201b. It's not clear
whether that is used by all controllers, or indeed in all situations.
For newer controllers, you could try T=4, N=14, and poly 0x5803. But note
that the nibble-shift is not required for N=14 in the situation I've
observed. Again, there is no guarantee that this configuration will work
for what you are trying to achieve.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB5MX7B7AAWTYVGRLV6VXUDRMCLHDANCNFSM4LZMBXVA>
.
|
I'm no expert in BCH or ECC so I can't say for sure, but it worked for me. The 4-bit shift looks like it is necessary with T=4 and an odd M to ensure proper alignment. It's relatively easy to script something that searches the polynomial space and compares the regenerated ECC with that which is present. If you've got a huge flash you could probably just truncate it to get a good idea of which poly is being used. For a 1Gb flash it took, say, half an hour to search on modest hardware. Be aware that if you've dumped the raw contents of your NAND it may include bit errors. But even with a significant number of errors you should still see a spike where the calculated ECC correlates significantly with the stored ECC for a specific poly. Then the problem is whether the raw readout has introduced more errors than can be corrected (4 bits per sector for T=4.) I had significantly more success after dumping the NAND again after I'd found the poly -- possibly EM interference, dodgy wiring, maybe something magical happening in the NAND cells... |
@prakash56755 and me have access to all kinds of Broadcom hardware and flash chips but what looked like an easy task of adding support for has not been successful. The README mentions a linearity check. Over what range should that be done and how? Can you elaborate some more regarding calculating the polynomial? We have access to good ecc data but some hints would be very welcome. And why do you suggest poly 0x5803 ? |
Again, I'm not an expert, I can only advise on what I observed in the one case of SOC and NAND that I looked at. I created a modified version of brcm-nand-bch.c which:
Then create a shell script (or even a 1-liner) to search the polynomial space, passing the polynomial as an argument. All the cases where the poly is invalid will be rejected at the init_bch() call. For most of the remainder of the polys, I would expect it to indicate that every sector is incorrect. In my case I had one poly (0x5803) which reported significantly fewer differences. I did reread the NAND after that point, which resulted in calculated ECC that differed in only a single sector. Crude, I know, but it worked for me. I do plan to upload this code at some point, but I'll be too busy over the next fortnight. |
@StrayLightning ok it all makes sense now I just didn't assume that the hardware ecc/bch implementation and bch lib in this repo would create the same ecc values. Is it possible to get a copy of the code you wrote? |
I was hoping to clean it up and refactor before sharing it, but it's forked to https://github.com/StrayLightning/brcm-nand-bch -- no idea if it'll work for you, but feel free to tidy up, correct it, or point out the flaws. |
cat .out | ./reencode 0x5803 >verify.out So we are all good now and have a strategy that should work on other geometries also. |
Hi! Sorry to hijack this ticket. I have one module with boradcom BCM9583xx that have the nand device below. With the info from the sdk it seems to use this BCH scheme ( >= v5.0: ECC_REQ = ceil(BCH_T * 14/8)) NAND device: Manufacturer ID: 0x98, Chip ID: 0xdc (Toshiba NAND 512MiB 3,3V 8-bit), 512MiB, page size: 2048, OOB size: 64 How to find the oob area layout? And fix the bit errors? |
If the nand controller >= v5.0 then use the code found here: https://github.com/StrayLightning/brcm-nand-bch otherwise you need to modify it so it uses the 6,5 bytes ecc layout that is found in this repository. |
My concern it's about oob area layout, My oob area it like this: FF FF 9A E2 B3 08 5E 02 7F F6 00 2D 85 09 81 08 For a page full of 0 it's like this: FF FF AD 71 A9 1F C9 C9 27 A5 91 F5 EB 49 F8 C1 That is quite different from this repository. What is the size of user oob area used on this repository? |
Total amounts of ecc per page is 64. Each sector/subpage has 16 bytes of ecc data. In your case 2 bytes are allocated for bad block handling. That gives you 14*8=112 bits of ecc data possible. We assume this is still valid ceil(BCH_T * 14/8)). That gives 14/(14/8)=8. BCH_T can thus be 8. This repo mainly uses BCH4. But Broadcom nand controllers can handle bch4,8 and 12. (And 1-bit hamming also). |
We are no sure the polynomial that is found here https://github.com/StrayLightning/brcm-nand-bch is the same for bch8. But you had a good zero test vector that you can use to brute force the ecc parameters. Use https://github.com/StrayLightning/brcm-nand-bch/blob/master/reencode.c with some changes. |
#define BCH_T 4 -> 8 and something that loops over the polynomial. |
Is BCM9583xx arm ? |
Hum... Thanks for the tips! I will work on this! |
Yes cortex A9 |
The poly is very likely 0x5803. And then the following should work. cat .out | ./reencode 0x5803 >verify.out |
We have this tool: |
I created a file of 2048 zero bytes with the above tacked on the end. I built reencode.c with the following changes: #define BCH_T 8 I used poly 0x5803, and it regenerated the ECC with zero differences. So it does look like those are the parameters for your NAND, @Mat-Alm. |
Yes! I also tested and it works fine! Thanks for the help! |
Poly 0x5803 is used on BCM58360 (Sercomm FG1000B.11, ie DT Glasfaser-modem 2), thanks @StrayLightning. For two sectors full of 00, the first one being at the start of the block, I have :
Note that the "user-defined" values are the same as in this repo, but in little endian (so they should be interpreted as 0x1985, 0x2003 and 0x00000008). |
@hwti Thanks for that. I'm somewhat surprised that it produced even vaguely sensible results. It would be nice to finally tidy up these gash programs; I'll need to dig through my notes. |
No description provided.
The text was updated successfully, but these errors were encountered: