flash driver doesn't response

QNX Newsgroups (Archives) qnx.bsp
1

Hi,

Our target board has 4MB BootFlash (Intel 28F320C3T) device.
I started my development from “artesyn” source.

After some modifications driver starts, creates socket but
any flashctl operation like erase, format,… fails at the
“intel_read_status.c: 29 program protect error” function.

What can be a reason of that behaviour?
On what should I give attention to?

Here is a some additional info from my terminal session:

devf-mip -vvvvvvvv &

53255 running devf-mip

calloc /src/lib/fs-flash/start.c, 59: 0x80

calloc /src/lib/fs-flash/start.c, 96: 0x40
calloc /src/lib/fs-flash/start.c, 128: 0x30
calloc /src/lib/fs-flash/start.c, 152: 0x48
calloc /src/lib/fs-flash/start.c, 167: 0x98
devf: fs0 socket mip

trying device width = 1

devf: bus width = 1
devf: trying chip inter = 1
devf: bus width = 2
devf: trying chip inter = 2
devf: bus width = 4
devf: trying chip inter = 4
devf: bus width = 8
devf: trying chip inter = 8

trying device width = 2

devf: bus width = 2
devf: trying chip inter = 1
query string = QRY
devf: chip total = 1
devf: bus width = 2
devf: chip interleave = 1
calloc /src/lib/fs-flash/array_alloc.c, 41: 0x1c
calloc /src/lib/fs-flash/array_alloc.c, 45: 0x100
calloc /src/lib/fs-flash/array_alloc.c, 49: 0x80
calloc /src/lib/fs-flash/array_alloc.c, 51: 0x40
calloc /src/lib/fs-flash/array_alloc.c, 55: 0x40
calloc /src/lib/fs-flash/array_alloc.c, 59: 0x100
malloc /src/lib/fs-flash/array_alloc.c, 61: 0x900
devf: fs0 array CFI U: 40 S: 010000
malloc /src/lib/fs-flash/array_attach.c, 59: 0x10
calloc /src/lib/fs-flash/array_attach.c, 70: 0x80
calloc /src/lib/fs-flash/array_attach.c, 71: 0x80
calloc /src/lib/fs-flash/array_attach.c, 75: 0x98
calloc /src/lib/fs-flash/array_attach.c, 79: 0x30
calloc /src/lib/fs-flash/array_attach.c, 80: 0x30
devf: fs0p0 raw U: 40
53255 exited with status 0

els /dev

console fs0p0 fs0 tty
slog hd0t77 hd0 pipe
ser2 ser1 shmem mem
zero text null

flashctl -p/dev/fs0p0 -v -l2M -e -f -n/ -m

Erasing device /dev/fs0p0
…/…/intel/intel_read_status.c: 29 program protect error
DCMD_F3S_ERASE failed (errno 5)
flashctl: erase failed

flashctl -p/dev/fs0p0 -v -l2M -f -n/ -m

Formatting device /dev/fs0p0
…/…/intel/intel_read_status.c: 29 program protect error
…/…/intel/intel_read_status.c: 29 program protect error
devf: fs0p0 bad H[00] P[00] # 000014 (3)
DCMD_F3S_FORMAT failed (errno 5)
flashctl: format failed


Regards,
Jacek

2

The default state of Intel 28xxxC3 flash is to have all blocks
locked when the device is powered up. To be able to erase, format,
or otherwise write to the flash, you must first unlock either the
blocks you want to write to, or the entire flash.

ex.

flashctl -p/dev/fs0 -A (unlock entire flash array)

or

flashctl -p/dev/fs0 -U -o2M -l1M (unlock from 2M to 3M)




Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:

Hi,

Our target board has 4MB BootFlash (Intel 28F320C3T) device.
I started my development from “artesyn” source.

After some modifications driver starts, creates socket but
any flashctl operation like erase, format,… fails at the
“intel_read_status.c: 29 program protect error” function.

What can be a reason of that behaviour?
On what should I give attention to?

Here is a some additional info from my terminal session:

devf-mip -vvvvvvvv &

53255 running devf-mip

calloc /src/lib/fs-flash/start.c, 59: 0x80

calloc /src/lib/fs-flash/start.c, 96: 0x40
calloc /src/lib/fs-flash/start.c, 128: 0x30
calloc /src/lib/fs-flash/start.c, 152: 0x48
calloc /src/lib/fs-flash/start.c, 167: 0x98
devf: fs0 socket mip

trying device width = 1

devf: bus width = 1
devf: trying chip inter = 1
devf: bus width = 2
devf: trying chip inter = 2
devf: bus width = 4
devf: trying chip inter = 4
devf: bus width = 8
devf: trying chip inter = 8

trying device width = 2

devf: bus width = 2
devf: trying chip inter = 1
query string = QRY
devf: chip total = 1
devf: bus width = 2
devf: chip interleave = 1
calloc /src/lib/fs-flash/array_alloc.c, 41: 0x1c
calloc /src/lib/fs-flash/array_alloc.c, 45: 0x100
calloc /src/lib/fs-flash/array_alloc.c, 49: 0x80
calloc /src/lib/fs-flash/array_alloc.c, 51: 0x40
calloc /src/lib/fs-flash/array_alloc.c, 55: 0x40
calloc /src/lib/fs-flash/array_alloc.c, 59: 0x100
malloc /src/lib/fs-flash/array_alloc.c, 61: 0x900
devf: fs0 array CFI U: 40 S: 010000
malloc /src/lib/fs-flash/array_attach.c, 59: 0x10
calloc /src/lib/fs-flash/array_attach.c, 70: 0x80
calloc /src/lib/fs-flash/array_attach.c, 71: 0x80
calloc /src/lib/fs-flash/array_attach.c, 75: 0x98
calloc /src/lib/fs-flash/array_attach.c, 79: 0x30
calloc /src/lib/fs-flash/array_attach.c, 80: 0x30
devf: fs0p0 raw U: 40
53255 exited with status 0

els /dev

console fs0p0 fs0 tty
slog hd0t77 hd0 pipe
ser2 ser1 shmem mem
zero text null

flashctl -p/dev/fs0p0 -v -l2M -e -f -n/ -m

Erasing device /dev/fs0p0
…/…/intel/intel_read_status.c: 29 program protect error
DCMD_F3S_ERASE failed (errno 5)
flashctl: erase failed

flashctl -p/dev/fs0p0 -v -l2M -f -n/ -m

Formatting device /dev/fs0p0
…/…/intel/intel_read_status.c: 29 program protect error
…/…/intel/intel_read_status.c: 29 program protect error
devf: fs0p0 bad H[00] P[00] # 000014 (3)
DCMD_F3S_FORMAT failed (errno 5)
flashctl: format failed



Regards,
Jacek

–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

3

Jacek,

In this case, it’s possible that there may be additional
hardware protection in place, such as a GPIO pin tied to
the #WP pin, for example, which is preventing the flash
from being unlocked. You may need to check your board
schematics to determine what needs to be done to write-enable
the flash, and then insert that code into the f3s_*_open()
routine of your flash driver code.



Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:

Hi Dave,

unfortunately but even unlock operation doesn’t work.

The default state of Intel 28xxxC3 flash is to have all blocks
locked when the device is powered up. To be able to erase, format,
or otherwise write to the flash, you must first unlock either the
blocks you want to write to, or the entire flash.

ex.

flashctl -p/dev/fs0 -A (unlock entire flash array)

flashctl -p/dev/fs0 -A -vvvvvvvvvvvvvvvv

Unlocking entire device /dev/fs0
DCMD_F3S_UNLOCKALL failed (errno 25)
flashctl: unlock failed

or

flashctl -p/dev/fs0 -U -o2M -l1M (unlock from 2M to 3M)

flashctl -p/dev/fs0 -U -o2M -l1M -vvvvvvvvvvv

Unlocking device /dev/fs0
offset = 200000,limit = 300000
DCMD_F3S_UNLOCK failed (errno 25)
flashctl: unlock failed



Regards,
Jacek

–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

4

Hi Dave,

unfortunately but even unlock operation doesn’t work.

The default state of Intel 28xxxC3 flash is to have all blocks
locked when the device is powered up. To be able to erase, format,
or otherwise write to the flash, you must first unlock either the
blocks you want to write to, or the entire flash.

ex.

flashctl -p/dev/fs0 -A (unlock entire flash array)

flashctl -p/dev/fs0 -A -vvvvvvvvvvvvvvvv

Unlocking entire device /dev/fs0
DCMD_F3S_UNLOCKALL failed (errno 25)
flashctl: unlock failed

or

flashctl -p/dev/fs0 -U -o2M -l1M (unlock from 2M to 3M)

flashctl -p/dev/fs0 -U -o2M -l1M -vvvvvvvvvvv

Unlocking device /dev/fs0
offset = 200000,limit = 300000
DCMD_F3S_UNLOCK failed (errno 25)
flashctl: unlock failed


Regards,
Jacek

5

Dave,

there is a hardware configuration switch on the board
and Boot Flash Write is set to enabled.

I don’t have any problem with flash programming by
using JTAG debugger and 3rd party software.

Very interesting is fact that driver fails even when I perform
software unlock operation of entire flash array.

Regards,
Jacek

In this case, it’s possible that there may be additional
hardware protection in place, such as a GPIO pin tied to
the #WP pin, for example, which is preventing the flash
from being unlocked. You may need to check your board
schematics to determine what needs to be done to write-enable
the flash, and then insert that code into the f3s_*_open()
routine of your flash driver code.

6

Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:

Dave,

there is a hardware configuration switch on the board
and Boot Flash Write is set to enabled.

I don’t have any problem with flash programming by
using JTAG debugger and 3rd party software.

Very interesting is fact that driver fails even when I perform
software unlock operation of entire flash array.

Actually, it’s the unlock operation itself that’s failing.
At this point, I’d suggest manually putting code into your
open() routine, to unlock the blocks yourself. Based on
the previous output, it looks like you have a single Intel
flash chip, 16 bits wide, 64k block size, with 0x40 blocks,
for a total of 4M, correct? I’d suggest something like the
following in your f3s_mip_open.c:

uintptr_t tmp;

tmp = mmap_device_io(0x400000, socket->address);

out16(tmp, 0xff); // start in read array mode

for(i=0; i < (4 * 1024 * 1024); i += (64*1024) ) {
out16(tmp + i, 0x60); // config setup
out16(tmp + i, 0xd0); // unlock block
}

out16(tmp, 0xff); // back to read array mode




Regards,
Jacek

In this case, it’s possible that there may be additional
hardware protection in place, such as a GPIO pin tied to
the #WP pin, for example, which is preventing the flash
from being unlocked. You may need to check your board
schematics to determine what needs to be done to write-enable
the flash, and then insert that code into the f3s_*_open()
routine of your flash driver code.

–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

7

Dave,

there is a hardware configuration switch on the board
and Boot Flash Write is set to enabled.

I don’t have any problem with flash programming by
using JTAG debugger and 3rd party software.

Very interesting is fact that driver fails even when I perform
software unlock operation of entire flash array.

Actually, it’s the unlock operation itself that’s failing.

I meant unlock from my 3’rd party software after the
OS image programming.

At this point, I’d suggest manually putting code into your
open() routine, to unlock the blocks yourself. Based on
the previous output, it looks like you have a single Intel
flash chip, 16 bits wide, 64k block size, with 0x40 blocks,
for a total of 4M, correct?

I have a single Intel flash chip, 16 bit wide, 64k block size
organized as follows:

0xffc00000–0xfffeffff 0x10000
0xffff0000–0xffffffff 0x02000

total = 4M.

I’d suggest something like the
following in your f3s_mip_open.c:

uintptr_t tmp;

tmp = mmap_device_io(0x400000, socket->address);

out16(tmp, 0xff); // start in read array mode

for(i=0; i < (4 * 1024 * 1024); i += (64*1024) ) {
out16(tmp + i, 0x60); // config setup
out16(tmp + i, 0xd0); // unlock block
}

out16(tmp, 0xff); // back to read array mode

I will test this soon…
…but I’m wondering why I must do once again unlock
operation from flash driver (OS level)?

Thank’s,
Jacek

Regards,
Jacek

In this case, it’s possible that there may be additional
hardware protection in place, such as a GPIO pin tied to
the #WP pin, for example, which is preventing the flash
from being unlocked. You may need to check your board
schematics to determine what needs to be done to write-enable
the flash, and then insert that code into the f3s_*_open()
routine of your flash driver code.


\

David Green (> dgreen@qnx.com> )
QNX Software Systems Ltd.
http://www.qnx.com

8

Actually, it’s the unlock operation itself that’s failing. At this point,
I’d suggest manually putting code into your
open() routine, to unlock the blocks yourself. Based on
the previous output, it looks like you have a single Intel flash chip, 16
bits wide, 64k block size, with 0x40 blocks, for a total of 4M, correct?
I’d suggest something like the
following in your f3s_mip_open.c:

uintptr_t tmp;

tmp = mmap_device_io(0x400000, socket->address);

out16(tmp, 0xff); // start in read array mode

for(i=0; i < (4 * 1024 * 1024); i += (64*1024) ) {
out16(tmp + i, 0x60); // config setup
out16(tmp + i, 0xd0); // unlock block
}

out16(tmp, 0xff); // back to read array mode

For my flash chip organization I did:

tmp = mmap_device_io(0x400000, socket->address);

out16(tmp, 0xff); // start in read array mode


for(i=0; i < (63 * 64 * 1024); i += (64*1024) ) { //63 blocks 64k

out16(tmp + i, 0x60); // config setup

out16(tmp + i, 0xd0); // unlock block

}


for(i=63641024; i < (4 * 1024 * 1024); i += (8*1024) ) { //8 blocks 8k

out16(tmp + i, 0x60); // config setup

out16(tmp + i, 0xd0); // unlock block

}

out16(tmp, 0xff); // back to read array mod

After this I was able to perform erase operation:

flashctl -p/dev/fs0p0 -l1M -e -vvvvv &

Erasing device /dev/fs0p0
offset = 0,limit = 100000
…

but I still got some problems during format/write activity:

flashctl -p/dev/fs0p0 -l1M -e -f -n / -m -vvvv &

Erasing device /dev/fs0p0
offset = 0,limit = 100000
…
Formatting device /dev/fs0p0
…/…/intel/iCFI_write.c: 222 program verify error
devf: fs0p0 bad H[00] P[00] # 000014 (3)
DCMD_F3S_FORMAT failed (errno 5)
flashctl: format failed


When I changed write flash declaration routine

from “f3s_iCFI_write” to “f3s_i28f008_write”

(in the f3s_mip_main.c file) then everything is working fine.



Thank you for nice trick Dave,

Jacek

9

Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:

[snip]

When I changed write flash declaration routine

from “f3s_iCFI_write” to “f3s_i28f008_write”

(in the f3s_mip_main.c file) then everything is working fine.

Yes, that’s another quirk about the 28fxxC3 flash; although it
is CFI flash, it doesn’t support buffered writes, so you must use
the i28f008_write routine…



Thank you for nice trick Dave,



Jacek

Glad it’s working.

–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com