[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices

[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices

[Konstantin Kletschke]

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


-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices

[Konstantin Kletschke]

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

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices

[Tolunay Orkun]

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

[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices

[Konstantin Kletschke]

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

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices

[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...

> 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

[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices

[Konstantin Kletschke]

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

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our business is run on trust.  We trust you will pay in advance.