-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/02/2013 10:56 AM, Gupta, Pekon wrote:
On 08/29/2013 01:26 PM, Gupta, Pekon wrote:
[snip]
I think we should move the selected message to a debug().
Second part of string "nand: selected OMAP_ECC_BCH8_CODE_HW" was specifically added in board_nand_init() because currently there is no way to identify the ECC scheme being used in u-boot. Unless digging into source code and reviewing board file. And many time end-users face ECC scheme mis-match between u-boot and linux when flashing kernel and file-system from u-boot. Thus this print helps in identifying the ECC scheme being used from logs. So, please keep this print "nand: selected <ecc-scheme>" .. ?
I'd rather not as we should have left the mis-match problems in the past. We don't generally offer commands to switch ECC schemes as everyone is using the same now. When we do need to offer switching for legacy reasons that's when we should say what we're on.
I think we should not deprecate the 'ecc_switching_utility', bcoz there are multiple scenarios even in newer devices where it is useful..
Example-1: using built-in NAND devices
[snip]
The ROM already needs to handle this mode and simply go with "on die ECC" and we need to mirror this behaviour.
Example-2: upgrading ECC on legacy devices There are many users with devices in production, who would like to upgrade to newer ECC schemes (like BCH16), only when these drivers are stable. Such users depend on u-boot to switch newer ECC schemes (like BCH16) and then re-flash upgraded kernel and file-systems on remote machines. In such cases also 'ecc_switching_utility' is helpful.
But they've got a problem today, which is that the ROM demands BCH16 already, so they have to use BCH16 or not be booting from NAND.
Though I don't want to be stubborn here.. But if your plan is to completely remove 'ecc_switching_utility' support then I would move back to V2 version of this patch, where ecc scheme is selected by #CONFIGS, so that only that code footprint gets optimized.
Please let me know, which way to go forward..
- [Patch V2 xx] where ECC selection is via #CONFIGS
- [Patch V3 xx] where ECC selection can be done via software (ecc_switching_utility) Incase you opt for [V3], my humble request is to keep above prints and not to convert them into 'debug' (please) :-)
We need to do run-time detection of what ecc mode is to be used. We don't want to expose the 'nandecc' type command we have on OMAP3 without a real case (and I don't count ones that can be constructed as an example on beaglebone + capes, but I do count real hardware designs).
- -- Tom