fw_printenv offsets

<< < (2/4) > >>

e-squizo:
Quote from: e-squizo on March 13, 2010, 06:19:28 AM

With these values, I was able both to read and write values from uBoot's environment on an older plug.


DO NOT TRY TO WRITE TO YOUR ENVIRONMENT WITH DEBIAN'S FW_SETENV

If you are lucky, it will fail. If you are unlucky, it will mess up your environment's CRC. fw_printenv will be completely happy about it, but u-boot will reset to the default environment on your next boot, probably messing up your boot process. It's not bad enough to brick your plug, but you will need to re-set the environment to your liking.

I'm trying to figure out what is going wrong here: two different plugs, with identical u-boot versions, produce very different results, and that is plain weird. To make matters worse, the code in fw_printenv is ugly as hell, so I'm still trying to figure out why u-boot and fw_{print,set}env compute different CRCs for the same environment.

e-squizo:
Quote from: e-squizo on March 13, 2010, 03:36:06 PM

I'm still trying to figure out why u-boot and fw_{print,set}env compute different CRCs for the same environment.


In the meantime, I found out that fw_printenv is computing crc32 correctly. So it seems that u-boot does not use crc32 but another checksum algorithm?

pingtoo:
Quote from: e-squizo on March 13, 2010, 06:12:14 PM

Quote from: e-squizo on March 13, 2010, 03:36:06 PM

I'm still trying to figure out why u-boot and fw_{print,set}env compute different CRCs for the same environment.


In the meantime, I found out that fw_printenv is computing crc32 correctly. So it seems that u-boot does not use crc32 but another checksum algorithm?


I think it is crc7, I check u-boot code.

e-squizo:
Quote from: pingtoo on March 13, 2010, 10:05:16 PM

I think it is crc7, I check u-boot code.


I seriously doubt it: I couldn't find even a reference to crc7 in the u-boot source code.

Yet, we are getting closer!

The reason why fw_printenv computes a different CRC than u-boot is because they are operating on different data, because of read errors due to using the wrong ECC mechanism. From what I can read in another thread http://plugcomputer.org/plugforum/index.php?topic=117.msg654#msg654, the problem is that u-boot handles the NAND with 4-bit ECC, while Linux tries to handle it with 1-bit ECC, because the latter seems to be more reasonable for the specific type of NAND used in the Sheevaplug (don't ask me why: I'm basically rephrasing te contents of that post, I am only beginning to understand how this whole NAND business works). This ECC information seems to be stored inside some out-of-band (OOB) data that the NAND memory sets aside for each block.

Fortunately, there is a solution: the package mtd-utils has handy utilities such as nanddump and nandwrite that allow us to do I/O to the NAND in raw mode, bypassing the kernel's ECC logic and enabling access to the OOB data, which is normally hidden from the user. With this utilities, we can dump of the environment's contents, edit it to our hearts content, then write it back.

The only problem: when we write it back, we need to do so with 4-bit ECC, so u-boot will be able to read it. I haven't found a way to tell nandwrite that it should write with 4-bit ECC (it only has a flag to turn ECC on or off), but maybe it's there, and I'm too dumb to find it. Even if it's not there, we can still compute the whole ECC thing by ourselves in the user side, and write the data back with pre-computed ECC and all in raw mode, which nandwrite supports.

The only problem now is that I still haven't found any reference on how this 4-bit ECC is supposed to be computed and stored, but as soon as we get that sorted out, we should be good to go.

e-squizo:
I have confirmed the suspicion that the CRC mismatch is due to ECC, so we should be a very small distance away from a solution. However, I can't seem to find any reference about which ECC is used, nor how it is encoded in the NAND's 64-byte OOB sector. There's a file called drivers/mtd/nand/nand_ecc.c within u-boot sources, but from what little I could gather from the comments, it seems to be a 1-bit ECC, not the 4-bit ECC we are looking for.

If anyone knows about how to compute and encode the OOB data, I'm sure we could have a working solution within hours.

Navigation

[0] Message Index

[#] Next page

[*] Previous page