I’m not sure if I understood your answer. I might have been unclear in my
description.
I now understand that it is not as easy as I suggested (just a change of 3
lines). I assumed that the setting was the smallest possible erase block. I did
not realize that it also defines the only erase block size. Thank your for
pointing that out to me. I have only a limited understanding of your source
code. I probably had something in mind that is currently not implemented.
My use case for example is a firmware that is 65kB in size. According to your
numbers that now takes two erase cycles of 64kB each. I would suggest to do
only one cycle of 64kB and another cycle of 4kB. 2x64kB = 2x150ms = 300ms;
1x64kB+1x4kB = 150ms + 50ms = 200ms. The suggested variant would be 100ms or
1/3 faster.
The other issue is that my firmware uses the flash space behind the firmware.
With the current scheme 63kB behind the firmware are erased with every
programming. With the new scheme only 3kB would be erased alongside a firmware
update. To be able to modify the data the firmware already has to align it to
sector borders. So the 3kB will be lost anyway. But the additional 60kB could
become better usable with this change.
I don’t understand why such a feature needs to be rolled out to all devices. I
would assume that some devices only have one kind of sector. After implementing
this feature the device information needs to be updated. The information about
the big and little sectors needs to be added. If we keep all existing devices
in the “has only one sector size” category then those devices would not get
affected. With careful testing, device by device, we could then add more
devices to the “has two sector sizes” group.
I can understand if you don’t want such a big change for such a limited use
case.
---
**[tickets:#437] Wrong sector size for w25q16jv / RP2040 pico**
**Status:** new
**Milestone:** 0.11.0
**Created:** Sun Sep 29, 2024 05:57 AM UTC by JustAnother1
**Last Updated:** Sun Sep 29, 2024 09:09 AM UTC
**Owner:** nobody
in line 305 of src/flash/nor/rp2040.c (current git) there is this comment:
~~~
/*
The RP2040 Boot ROM provides a _flash_range_erase() API call documented
in Section 2.8.3.1.3:
https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf
and the particular source code for said Boot ROM function can be found
here:
https://github.com/raspberrypi/pico-bootrom/blob/master/bootrom/program_flash_generic.c
In theory, the function algorithm provides for erasing both a smaller
"sector" (4096 bytes) and
an optional larger "block" (size and command provided in args).
*/
~~~
I have verified the erase function from the boot rom of the RP2040. That is the
same function openocd uses here. And I found that it is able to erase a 4096
byte sector. So the comment is right.
I wrote something before and after and in a sector and then called
_flash_range_erase() from the boot-rom to erase the one 4096 bytes sized sector
and only the bytes in the sector have been erased. The data before and after
were still there. So erasing 4096 bytes is not theory anymore.
I therefore think that line 55 in src/flash/nor/rp2040.c and line 123 (129?)
in src/flash/nor/spi.c should be changed. They specify the sector size to
0x10000 (64k) and should be 1000(4k)
What else can I do to get this change merged, or is there a reason not to do
this?
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
