flash driver doesn't response

bridged with qnx.bsp

flash driver doesn't response

Postby Jacek Rudnicki » Mon Jan 31, 2005 12:08 pm

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
Jacek Rudnicki
 

Re: flash driver doesn't response

Postby Dave Green » Mon Jan 31, 2005 1:54 pm

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
Dave Green
 

Re: flash driver doesn't response

Postby Dave Green » Mon Jan 31, 2005 2:58 pm

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
Dave Green
 

Re: flash driver doesn't response

Postby Jacek Rudnicki » Mon Jan 31, 2005 2:59 pm

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
Jacek Rudnicki
 

Re: flash driver doesn't response

Postby Jacek Rudnicki » Tue Feb 01, 2005 7:36 am

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.
Jacek Rudnicki
 

Re: flash driver doesn't response

Postby Dave Green » Tue Feb 01, 2005 1:46 pm

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
Dave Green
 

Re: flash driver doesn't response

Postby Jacek Rudnicki » Wed Feb 02, 2005 9:57 am

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
Jacek Rudnicki
 

Re: flash driver doesn't response

Postby Jacek Rudnicki » Wed Feb 02, 2005 12:25 pm

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=63*64*1024; 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
Jacek Rudnicki
 

Re: flash driver doesn't response

Postby Dave Green » Wed Feb 02, 2005 2:09 pm

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
Dave Green
 


Return to qnx.bsp

Who is online

Users browsing this forum: No registered users and 0 guests

cron