[U-Boot-Users] [PATCH] Fix wrong ID for 28F256P30 in flash.h
Intel was inconsistent in their device IDs for the P30 Strata NOR. The header flash.h has incorrect device IDs for the top- and bottom-mapped versions of the 32 MB chips as a result. It's an easy mistake to make...
--- u-boot.git/include/flash.h 2007-03-12 13:40:31.000000000 -0700 +++ u-boot/include/flash.h 2007-03-12 19:26:25.000000000 -0700 @@ -290,8 +290,8 @@ #define INTEL_ID_28F64P30B 0x881A881A /* 64M = 32K x 255 + 32k x 4 */ #define INTEL_ID_28F128P30T 0x88188818 /* 128M = 64K x 255 + 32k x 4 */ #define INTEL_ID_28F128P30B 0x881B881B /* 128M = 64K x 255 + 32k x 4 */ -#define INTEL_ID_28F256P30T 0x88198819 /* 256M = 128K x 255 + 32k x 4 */ -#define INTEL_ID_28F256P30B 0x881C881C /* 256M = 128K x 255 + 32k x 4 */ +#define INTEL_ID_28F256P30T 0x89198919 /* 256M = 128K x 255 + 32k x 4 */ +#define INTEL_ID_28F256P30B 0x891C891C /* 256M = 128K x 255 + 32k x 4 */
#define INTEL_ID_28F160S3 0x00D000D0 /* 16M = 512K x 32 (64kB x 32) */ #define INTEL_ID_28F320S3 0x00D400D4 /* 32M = 512K x 64 (64kB x 64) */
Pete MacKay wrote:
Intel was inconsistent in their device IDs for the P30 Strata NOR. The header flash.h has incorrect device IDs for the top- and bottom-mapped versions of the 32 MB chips as a result. It's an easy mistake to make...
--- u-boot.git/include/flash.h 2007-03-12 13:40:31.000000000 -0700 +++ u-boot/include/flash.h 2007-03-12 19:26:25.000000000 -0700 @@ -290,8 +290,8 @@ #define INTEL_ID_28F64P30B 0x881A881A /* 64M = 32K x 255 + 32k x 4 */ #define INTEL_ID_28F128P30T 0x88188818 /* 128M = 64K x 255 + 32k x 4 */ #define INTEL_ID_28F128P30B 0x881B881B /* 128M = 64K x 255 + 32k x 4 */ -#define INTEL_ID_28F256P30T 0x88198819 /* 256M = 128K x 255 + 32k x 4 */ -#define INTEL_ID_28F256P30B 0x881C881C /* 256M = 128K x 255 + 32k x 4 */ +#define INTEL_ID_28F256P30T 0x89198919 /* 256M = 128K x 255 + 32k x 4 */ +#define INTEL_ID_28F256P30B 0x891C891C /* 256M = 128K x 255 + 32k x 4 */
#define INTEL_ID_28F160S3 0x00D000D0 /* 16M = 512K x 32 (64kB x 32) */ #define INTEL_ID_28F320S3 0x00D400D4 /* 32M = 512K x 64 (64kB x 64) */
Thanks for the update. However, the CFI driver actually does not use these macro.
Is there a place (custom driver) that this ID was used an caused a problem?
I personally actually want to remove these macros for any device that could be serviced by cfi_flash.c driver.
Tolunay
In message 45F8F52B.9000206@orkun.us you wrote:
I personally actually want to remove these macros for any device that could be serviced by cfi_flash.c driver.
That would break all custom drivers that use these; and there are systems that cannot use the CFI driver because of size restrictions.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 45F8F52B.9000206@orkun.us you wrote:
I personally actually want to remove these macros for any device that could be serviced by cfi_flash.c driver.
That would break all custom drivers that use these; and there are systems that cannot use the CFI driver because of size restrictions.
Best regards,
Wolfgang Denk
Obviously, I would not remove the ones that are in use but I suspect there are some that are not in use after switching to cfi_flash.c.
I think for new flash that is cfi compliant and could be serviced by cfi_flash.c there is no reason to define these macros.
Whenever I have some time, I actually want to improve cfi_flash.c to handle non-cfi flash as well. It will use jedec ids stored in a table so these macros would not be much useful.
Best regards, Tolunay
On Friday 16 March 2007 03:57, Tolunay Orkun wrote:
Obviously, I would not remove the ones that are in use but I suspect there are some that are not in use after switching to cfi_flash.c.
Sure.
I think for new flash that is cfi compliant and could be serviced by cfi_flash.c there is no reason to define these macros.
Whenever I have some time, I actually want to improve cfi_flash.c to handle non-cfi flash as well. It will use jedec ids stored in a table so these macros would not be much useful.
/me crosses his fingers that Tolunay soon will have "some time". ;-)
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
participants (5)
-
Pete MacKay -
Stefan Roese -
Tolunay Orkun -
Tolunay Orkun -
Wolfgang Denk