[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices
Hi!
cfi_flash.c handles intel k3 devices not correct, they power up with all sectors locked. Similair to flash_unlock_seq for amd devices, there must exist a flash_unlock_seq_intelk3 to do this for intel devices.
--- u-boot-1.1.2/drivers/cfi_flash.c 2004-12-18 23:35:45.000000000 +0100 +++ u-boot-1.1.2-imx1/drivers/cfi_flash.c 2005-05-12 15:59:06.000000000 +0200 @@ -111,6 +111,9 @@ #define AMD_ADDR_START 0x555 #define AMD_ADDR_ACK 0x2AA
+#define INTEL_CMD_UNLOCK_START 0x60 +#define INTEL_CMD_UNLOCK_ACK 0xD0 + #define FLASH_OFFSET_CFI 0x55 #define FLASH_OFFSET_CFI_RESP 0x10 #define FLASH_OFFSET_PRIMARY_VENDOR 0x13 @@ -180,6 +183,7 @@ static void flash_make_cmd (flash_info_t * info, uchar cmd, void *cmdbuf); static void flash_write_cmd (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static void flash_unlock_seq (flash_info_t * info, flash_sect_t sect); +static void flash_unlock_seq_intelk3 (flash_info_t * info, flash_sect_t sect); static int flash_isequal (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static int flash_isset (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static int flash_toggle (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); @@ -239,7 +243,6 @@ } #endif
- /*----------------------------------------------------------------------- * read a character at a port width address */ @@ -397,6 +400,7 @@ switch (info->vendor) { case CFI_CMDSET_INTEL_STANDARD: case CFI_CMDSET_INTEL_EXTENDED: + flash_unlock_seq_intelk3 (info, sect); flash_write_cmd (info, sect, 0, FLASH_CMD_CLEAR_STATUS); flash_write_cmd (info, sect, 0, FLASH_CMD_BLOCK_ERASE); flash_write_cmd (info, sect, 0, FLASH_CMD_ERASE_CONFIRM); @@ -858,6 +862,12 @@ flash_write_cmd (info, sect, AMD_ADDR_ACK, AMD_CMD_UNLOCK_ACK); }
+static void flash_unlock_seq_intelk3 (flash_info_t * info, flash_sect_t sect) +{ + flash_write_cmd (info, sect, 0, INTEL_CMD_UNLOCK_START); + flash_write_cmd (info, sect, 0, INTEL_CMD_UNLOCK_ACK); +} + /*----------------------------------------------------------------------- */ static int flash_isequal (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd)
May be there must be added an "if" to filter intel k3 devices only, can somebody confirm this?
Regards, Konsti
Stop!
Damn, also the flinfo format Problem still exists in 1.1.2! For example: http://sourceforge.net/mailarchive/message.php?msg_id=11432237
--- u-boot-1.1.2/drivers/cfi_flash.c 2004-12-18 23:35:45.000000000 +0100 +++ u-boot-1.1.2-imx1/drivers/cfi_flash.c 2005-05-12 15:59:06.000000000 +0200 @@ -111,6 +111,9 @@ #define AMD_ADDR_START 0x555 #define AMD_ADDR_ACK 0x2AA
+#define INTEL_CMD_UNLOCK_START 0x60 +#define INTEL_CMD_UNLOCK_ACK 0xD0 + #define FLASH_OFFSET_CFI 0x55 #define FLASH_OFFSET_CFI_RESP 0x10 #define FLASH_OFFSET_PRIMARY_VENDOR 0x13 @@ -180,6 +183,7 @@ static void flash_make_cmd (flash_info_t * info, uchar cmd, void *cmdbuf); static void flash_write_cmd (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static void flash_unlock_seq (flash_info_t * info, flash_sect_t sect); +static void flash_unlock_seq_intelk3 (flash_info_t * info, flash_sect_t sect); static int flash_isequal (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static int flash_isset (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static int flash_toggle (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); @@ -239,7 +243,6 @@ } #endif
- /*----------------------------------------------------------------------- * read a character at a port width address */ @@ -397,6 +400,7 @@ switch (info->vendor) { case CFI_CMDSET_INTEL_STANDARD: case CFI_CMDSET_INTEL_EXTENDED: + flash_unlock_seq_intelk3 (info, sect); flash_write_cmd (info, sect, 0, FLASH_CMD_CLEAR_STATUS); flash_write_cmd (info, sect, 0, FLASH_CMD_BLOCK_ERASE); flash_write_cmd (info, sect, 0, FLASH_CMD_ERASE_CONFIRM); @@ -483,7 +487,7 @@ if ((i % 5) == 0) printf ("\n "); printf (" %08lX%s", - info->start[i], info->protect[i] ? " (RO) " : " "); + info->start[i], info->protect[i] ? " (RO) " : " "); #endif } putc ('\n'); @@ -858,6 +862,12 @@ flash_write_cmd (info, sect, AMD_ADDR_ACK, AMD_CMD_UNLOCK_ACK); }
+static void flash_unlock_seq_intelk3 (flash_info_t * info, flash_sect_t sect) +{ + flash_write_cmd (info, sect, 0, INTEL_CMD_UNLOCK_START); + flash_write_cmd (info, sect, 0, INTEL_CMD_UNLOCK_ACK); +} + /*----------------------------------------------------------------------- */ static int flash_isequal (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd)
Konsti
In message 20050512144510.GA4397@synertronixx3 you wrote:
Damn, also the flinfo format Problem still exists in 1.1.2! For example: http://sourceforge.net/mailarchive/message.php?msg_id=11432237
--- u-boot-1.1.2/drivers/cfi_flash.c 2004-12-18 23:35:45.000000000 +0100 +++ u-boot-1.1.2-imx1/drivers/cfi_flash.c 2005-05-12 15:59:06.000000000 +0200
Rejected. See my previous message.
Best regards,
Wolfgang Denk
Konstantin Kletschke wrote:
Hi!
cfi_flash.c handles intel k3 devices not correct, they power up with all sectors locked. Similair to flash_unlock_seq for amd devices, there must exist a flash_unlock_seq_intelk3 to do this for intel devices.
Why do you need this? Can't you just use "protect off" command to unlock the sectors you need to write? I think issuing automatic unlock commands prior to write/erase is against the sprit of protection.
Best regards, Tolunay
Am 2005-05-12 11:15 -0500 schrieb Tolunay Orkun:
Why do you need this?
When intel k3 chips power up, they are locked ba hardware and the sequence must be issued to unlock to be able to erase something.
On a first look I put it among the AMD flash_unlock_seq function, which does something similair I thought.
Can't you just use "protect off" command to unlock the sectors you need to write?
Well, sounds also reasonable. But am I blind? Where is the code, which unprotects something, when "protect off x:y-z" is issued? I agree, an Automatic unlocking is... But I still need this "protect off x:y-z" with my provided code, the chip comes up with all sectors (RO) stillm and they _are_ (RO). Only after manual "protect off x:y-z" I can erase something. Before I could _nothing_ write to the chip. Well, I could but nothing happened. Kinda hardware locked.
Konsti
Konstantin Kletschke wrote:
Only after manual "protect off x:y-z" I can erase something.
That is the idea. It is supposed to work this way as far as I understand. Don't change this behavior...
Before I could _nothing_ write to the chip. Well, I could but nothing happened. Kinda hardware locked.
If you have not done already, I think you should enable hardware (real) flash protection (CFG_FLASH_PROTECTION) in your board config file.
Upon boot do you see all sectors reported (RO) if you use flinfo command?
If not, you should look at the initialization of flash_info[].protect[] within flash_get_size() which is called from flash_init().
If this array is not initialized properly, U-Boot might attempt to erase a locked sector/block incorrectly instead of bailing out nicely. I think "saveenv" would have trouble as well. If this is the case, perhaps, FLASH_OFFSET_PROTECT and FLASH_STATUS_PROTECT is not appropriate for your type of flash and you should work on a solution for this instead.
Regards, Tolunay
Am 2005-05-12 17:13 -0500 schrieb Tolunay Orkun:
Konstantin Kletschke wrote:
Only after manual "protect off x:y-z" I can erase something.
That is the idea. It is supposed to work this way as far as I understand. Don't change this behavior...
It is not changed. But I will check that.
If you have not done already, I think you should enable hardware (real) flash protection (CFG_FLASH_PROTECTION) in your board config file.
I saw that option and will take a closer look at it.
Upon boot do you see all sectors reported (RO) if you use flinfo command?
Yes
Konsti
participants (3)
-
Konstantin Kletschke -
Tolunay Orkun -
Wolfgang Denk