Skip to content

drivers: flash: rpi_pico: Modifications to support rp2350 #86292

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+81 −180
Open

drivers: flash: rpi_pico: Modifications to support rp2350 #86292

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions boards/raspberrypi/rpi_pico2/rpi_pico2.dtsi
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@
chosen {
zephyr,sram = &sram0;
zephyr,flash = &flash0;
zephyr,flash-controller = &qmi;
zephyr,console = &uart0;
zephyr,shell-uart = &uart0;
zephyr,code-partition = &code_partition;
Expand Down
212 changes: 34 additions & 178 deletions drivers/flash/flash_rpi_pico.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,187 +13,35 @@
#include <zephyr/drivers/flash.h>
#include <zephyr/logging/log.h>
#include <zephyr/irq.h>
#include <zephyr/toolchain.h>

#include <hardware/flash.h>
#include <hardware/regs/io_qspi.h>
#include <hardware/regs/pads_qspi.h>
#include <hardware/structs/ssi.h>
#include <hardware/structs/xip_ctrl.h>
#include <hardware/resets.h>
#include <pico/bootrom.h>

LOG_MODULE_REGISTER(flash_rpi_pico, CONFIG_FLASH_LOG_LEVEL);

#define DT_DRV_COMPAT raspberrypi_pico_flash_controller

#define PAGE_SIZE 256
#define PAGE_SIZE 256
#define SECTOR_SIZE DT_PROP(DT_CHOSEN(zephyr_flash), erase_block_size)
#define ERASE_VALUE 0xff
#define FLASH_SIZE KB(CONFIG_FLASH_SIZE)
#define FLASH_BASE CONFIG_FLASH_BASE_ADDRESS
#define SSI_BASE_ADDRESS DT_REG_ADDR(DT_CHOSEN(zephyr_flash_controller))
#define FLASH_SIZE KB(CONFIG_FLASH_SIZE)
#define FLASH_BASE CONFIG_FLASH_BASE_ADDRESS
Comment on lines +23 to +27
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as elsewhere, let's keep linting/whitespace change in a separate commit from changes that affect the logic of the code.


static const struct flash_parameters flash_rpi_parameters = {
.write_block_size = 1,
.erase_value = ERASE_VALUE,
};

/**
* Low level flash functions are based on:
* github.com/raspberrypi/pico-bootrom/blob/master/bootrom/program_flash_generic.c
* and
* github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/hardware_flash/flash.c
*/

#define FLASHCMD_PAGE_PROGRAM 0x02
#define FLASHCMD_READ_STATUS 0x05
#define FLASHCMD_WRITE_ENABLE 0x06
#define BOOT2_SIZE_WORDS 64

enum outover {
OUTOVER_NORMAL = 0,
OUTOVER_INVERT,
OUTOVER_LOW,
OUTOVER_HIGH
};

static ssi_hw_t *const ssi = (ssi_hw_t *)SSI_BASE_ADDRESS;
static uint32_t boot2_copyout[BOOT2_SIZE_WORDS];
static bool boot2_copyout_valid;
static uint8_t flash_ram_buffer[PAGE_SIZE];

static void __no_inline_not_in_flash_func(flash_init_boot2_copyout)(void)
{
if (boot2_copyout_valid) {
return;
}
for (int i = 0; i < BOOT2_SIZE_WORDS; ++i) {
boot2_copyout[i] = ((uint32_t *)FLASH_BASE)[i];
}
__compiler_memory_barrier();
boot2_copyout_valid = true;
}

static void __no_inline_not_in_flash_func(flash_enable_xip_via_boot2)(void)
{
((void (*)(void))((uint32_t)boot2_copyout+1))();
}

void __no_inline_not_in_flash_func(flash_cs_force)(enum outover over)
{
io_rw_32 *reg = (io_rw_32 *) (IO_QSPI_BASE + IO_QSPI_GPIO_QSPI_SS_CTRL_OFFSET);
*reg = (*reg & ~IO_QSPI_GPIO_QSPI_SS_CTRL_OUTOVER_BITS)
| (over << IO_QSPI_GPIO_QSPI_SS_CTRL_OUTOVER_LSB);
(void) *reg;
}

int __no_inline_not_in_flash_func(flash_was_aborted)()
{
return *(io_rw_32 *) (IO_QSPI_BASE + IO_QSPI_GPIO_QSPI_SD1_CTRL_OFFSET)
& IO_QSPI_GPIO_QSPI_SD1_CTRL_INOVER_BITS;
}

void __no_inline_not_in_flash_func(flash_put_get)(const uint8_t *tx, uint8_t *rx, size_t count,
size_t rx_skip)
{
const uint max_in_flight = 16 - 2;
size_t tx_count = count;
size_t rx_count = count;
bool did_something;
uint32_t tx_level;
uint32_t rx_level;
uint8_t rxbyte;

while (tx_count || rx_skip || rx_count) {
tx_level = ssi_hw->txflr;
rx_level = ssi_hw->rxflr;
did_something = false;
if (tx_count && tx_level + rx_level < max_in_flight) {
ssi->dr0 = (uint32_t) (tx ? *tx++ : 0);
--tx_count;
did_something = true;
}
if (rx_level) {
rxbyte = ssi->dr0;
did_something = true;
if (rx_skip) {
--rx_skip;
} else {
if (rx) {
*rx++ = rxbyte;
}
--rx_count;
}
}

if (!did_something && __builtin_expect(flash_was_aborted(), 0)) {
break;
}
}
flash_cs_force(OUTOVER_HIGH);
}

void __no_inline_not_in_flash_func(flash_put_get_wrapper)(uint8_t cmd, const uint8_t *tx,
uint8_t *rx, size_t count)
{
flash_cs_force(OUTOVER_LOW);
ssi->dr0 = cmd;
flash_put_get(tx, rx, count, 1);
}

static ALWAYS_INLINE void flash_put_cmd_addr(uint8_t cmd, uint32_t addr)
{
flash_cs_force(OUTOVER_LOW);
addr |= cmd << 24;
for (int i = 0; i < 4; ++i) {
ssi->dr0 = addr >> 24;
addr <<= 8;
}
}

void __no_inline_not_in_flash_func(flash_write_partial_internal)(uint32_t addr, const uint8_t *data,
size_t size)
{
uint8_t status_reg;

flash_put_get_wrapper(FLASHCMD_WRITE_ENABLE, NULL, NULL, 0);
flash_put_cmd_addr(FLASHCMD_PAGE_PROGRAM, addr);
flash_put_get(data, NULL, size, 4);

do {
flash_put_get_wrapper(FLASHCMD_READ_STATUS, NULL, &status_reg, 1);
} while (status_reg & 0x1 && !flash_was_aborted());
}

void __no_inline_not_in_flash_func(flash_write_partial)(uint32_t flash_offs, const uint8_t *data,
size_t count)
{
rom_connect_internal_flash_fn connect_internal_flash = (rom_connect_internal_flash_fn)
rom_func_lookup_inline(ROM_FUNC_CONNECT_INTERNAL_FLASH);
rom_flash_exit_xip_fn exit_xip = (rom_flash_exit_xip_fn)
rom_func_lookup_inline(ROM_FUNC_FLASH_EXIT_XIP);
rom_flash_flush_cache_fn flush_cache = (rom_flash_flush_cache_fn)
rom_func_lookup_inline(ROM_FUNC_FLASH_FLUSH_CACHE);

flash_init_boot2_copyout();

__compiler_memory_barrier();

connect_internal_flash();
exit_xip();
flash_write_partial_internal(flash_offs, data, count);
flush_cache();
flash_enable_xip_via_boot2();
}

static bool is_valid_range(off_t offset, uint32_t size)
{
return (offset >= 0) && ((offset + size) <= FLASH_SIZE);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should have issue added to Zephyr as it is not overflow safe.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you elaborate, please? An issue concerning this function in the current code?

}

static int flash_rpi_read(const struct device *dev, off_t offset, void *data, size_t size)
{
ARG_UNUSED(dev);

Comment on lines +43 to +44
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good change, but I would prefer if it was in a separate commit as it is not required for adding support in the new driver.

if (size == 0) {
return 0;
}
Expand All @@ -210,43 +58,51 @@ static int flash_rpi_read(const struct device *dev, off_t offset, void *data, si

static int flash_rpi_write(const struct device *dev, off_t offset, const void *data, size_t size)
{
uint32_t key;
size_t bytes_to_write;
uint8_t *data_pointer = (uint8_t *)data;
ARG_UNUSED(dev);

const uint8_t *data_pointer = (const uint8_t *)data;
Comment on lines +61 to +63
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Local definitions should go to the top of function if possible. Switch these around.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before the ARG_UNUSED(), correct?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Just do not touch lines that do not really need touching. Leave the style as it was.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Local definitions should go to the top of function if possible. Switch these around.

I disagree. C99 has been a thing for a long time. I feel like variable scope should be reduced where possible.
That said, I'd also prefer not to see these things done in the same commit as it makes it difficult for reviewers to split out what's required vs what's tidying up/refactoring work.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is really not a hill I wanna die on.

That's perfectly reasonable. The key point is "reduce variable scope" is a distinct logical change, so should be in a separate commit (if you want to do it).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is scope reduction:

int i = 0;
if (something) {
    // only place where i is needed
}

to

if (something) {
    int i;
    // only place where i is needed
}

Moved definition is on the same scope it is just not visible above definition. Where declarations end up is a matter of style, nevertheless it avoids mess where you have to move definition up, if you want to use the variable earlier when doing code changes, at which point you may end up accidentally shadowing other variable, which has been defined in internal scope.
In short, when you keep variables in the top of the scope you avoid:

  1. moving definitions during development
  2. accidental shadowing.
  3. more changes then needed because of 1) and 2).

Anyway, not my unit, I just need to keep flash working according to API. @soburi your call, btw, can re-assign the PR to you?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I'll bite:

  1. moving definitions during development

Yup

  1. accidental shadowing.

I'm pretty sure -Wshadow is setup for gcc, clang and friends. so we avoid this with warning: declaration of 'foo' shadows a previous local [-Wshadow].

  1. more changes then needed because of 1) and 2).

A good list needs three things ;-).

Copy link
Member

@soburi soburi Apr 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@de-nordic

In terms of practical benefits, I don't think there's any problem as this is checked with -Wshadow.
I take the position that "it is preferable to follow existing custom unless there is a particularly significant benefit",
but this is also a matter of stylistic preference, so I think the current code is acceptable.

The 2012 revision of MISRA-C removed the reference to declarations at the top, so I think this in itself should be treated as a matter of preference.

@soburi your call, btw, can re-assign the PR to you?

I assigned myself as the assignee.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. accidental shadowing.

I'm pretty sure -Wshadow is setup for gcc, clang and friends. so we avoid this with warning: declaration of 'foo' shadows a previous local [-Wshadow].

They have many other switches too.

And you will, probably, have to rename the variable, after you get the warning, in entire internal scope, because there is a fair chance that the internal scope variable is a temporary thing that has nothing in common or does not affect the external scope variable nor is affected by it. So basically the cost of change is left on the next victim to touch the code. Anyway, not my unit, not my problem.

  1. more changes then needed because of 1) and 2).

A good list needs three things ;-).

I think five, but I run out of ideas after two, as you can tell by the number three.


if (size == 0) {
return 0;
}

if (!is_valid_range(offset, size)) {
LOG_ERR("Write range exceeds the flash boundaries. Offset=%#lx, Size=%u",
offset, size);
LOG_ERR("Write range exceeds the flash boundaries. Offset=%#lx, Size=%u", offset,
size);
return -EINVAL;
}

key = irq_lock();
uint32_t key = irq_lock();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why moving the definition from the top? Seems that this is unrelated change.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll roll this back.


if ((offset & (PAGE_SIZE - 1)) > 0) {
bytes_to_write = MIN(PAGE_SIZE - (offset & (PAGE_SIZE - 1)), size);
memcpy(flash_ram_buffer, data_pointer, bytes_to_write);
flash_write_partial(offset, flash_ram_buffer, bytes_to_write);
off_t offset_within_page = offset & (PAGE_SIZE - 1);

if (offset_within_page > 0) {
off_t page_offset = offset & ~(PAGE_SIZE - 1);
size_t bytes_to_write = MIN(PAGE_SIZE - offset_within_page, size);
Comment on lines +80 to +81
Copy link
Member

@soburi soburi Apr 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If placing declarations here, please add const if you can.


memcpy(flash_ram_buffer, (uint8_t *)(CONFIG_FLASH_BASE_ADDRESS + page_offset),
PAGE_SIZE);
memcpy(flash_ram_buffer + offset_within_page, data_pointer, bytes_to_write);
flash_range_program(page_offset, flash_ram_buffer, PAGE_SIZE);
data_pointer += bytes_to_write;
size -= bytes_to_write;
offset += bytes_to_write;
}

while (size >= PAGE_SIZE) {
bytes_to_write = PAGE_SIZE;
size_t bytes_to_write = PAGE_SIZE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto.

memcpy(flash_ram_buffer, data_pointer, bytes_to_write);
flash_range_program(offset, flash_ram_buffer, bytes_to_write);
flash_range_program(offset, flash_ram_buffer, PAGE_SIZE);
data_pointer += bytes_to_write;
size -= bytes_to_write;
offset += bytes_to_write;
}

if (size > 0) {
memcpy(flash_ram_buffer, data_pointer, size);
flash_write_partial(offset, flash_ram_buffer, size);
memcpy(flash_ram_buffer + size,
(uint8_t *)(CONFIG_FLASH_BASE_ADDRESS + offset + size), PAGE_SIZE - size);
flash_range_program(offset, flash_ram_buffer, PAGE_SIZE);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think this is correct; the driver sets write_block_size = 1, which means that user can write anything from 1-256. If user now will attempt to write single bytes from, whatever the leftover size was, to the end of page, in their code, then the user will end up re-writing the page N times, where N can be in range [1,PAGE_SIZE - 1].

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this would happen but from what I read in the datasheets it should be safe as you can "overwrite" a flash location with the same value without it having a side effect on the flash cell. I agree that in case of writing single bytes, this will be inefficient, but this is the trade-off for using the flash_range_program() ROM function.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it is not generally ok to overwrite nor memory with, even with the same value, without erase.
There are memories that have limits for how many times you can do such writes.
Datasheets often does not mention such limit, and NOR is not, usually, affected by hammering, like DRAM, nor over-program, like NAND, but if this driver is supposed to work with memories that do not work well with different memories, then it can not do over-write.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this should be a no-op on cell level and the electrical stress is caused by a) erasing and b) writing 1 -> 0, I understand your concerns and I cannot demonstrate it for every flash available.

I guess in that form it is therefore not viable. RP2350 mainline flash support has to wait then until someone successfully implements a qmi driver, which would be the proper thing to do anyway.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this should be a no-op on cell level and the electrical stress is caused by a) erasing and b) writing 1 -> 0, I understand your concerns and I cannot demonstrate it for every flash available.

I know that SoC NOR often have these limitations specified, I also remember long time ago reading datasheet, for NOR, where there was per write word value and per erase page (so you could rewrite bits in erase page something like ~80 times). I can not find such info in specs anymore, so maybe the tech got the issue fixed and it does not matter anymore?

The lack of overwrite, though, allows to support devices without erase but with the same set of commands, like SPI MRAM, RRAM or FRAM devices - these devices will take endurance reduced by overwrites.

I guess in that form it is therefore not viable. RP2350 mainline flash support has to wait then until someone successfully implements a qmi driver, which would be the proper thing to do anyway.

I do not get this, as my knowledge of rp2350 is very limited, there was that flash_write_partial used, wasn't it supposed to do non page write?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can we weasel out of this before we can get the correct driver running?

Maybe we should take the write-block-size from DTS definition and issue compile time warning that this driver will do overwrites and may not be optimal for devices that can not withstand that?

This way user may change the write-block-size (from the default PAGE_SIZE), in DTS, knowing what device has been connected to that controller and that there will be no issue, but the decision will be on user.

And to be completely on page with you here: soc-nv-flash represents here external NOR device the RP peripheral takes care of so that it looks like internal flash?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And to be completely on page with you here: soc-nv-flash represents here external NOR device the RP peripheral takes care of so that it looks like internal flash?

Yes, correct. RP2040 and RP2350 don't have internal flash, they use an external SPI NOR. The upcoming RP2354 has internal flash, but the implementation detail is, that it is a multi-die package with an W25Q16 integrated into it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@soburi @yonsch Any thoughts on this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The data sheet for the W25Q16JV actually used in Pico states:

https://docs.rs-online.com/068a/0900766b81622f8d.pdf

In some cases, less than 256 bytes (a
partial page) can be programmed without having any effect on other bytes within the same page. One
condition to perform a partial page program is that the number of clocks cannot exceed the remaining page
length. If more than 256 bytes are sent to the device the addressing will wrap to the beginning of the page
and overwrite previously sent data.

There is no doubt that it is desirable to implement partial rewrites appropriately.

Ideally, I think it would be ideal to move forward with adding this support to the pico-sdk side. (raspberrypi/pico-sdk#1169)

At the very least, I think it would be unacceptable to remove the implementation of partial writing in RP2040, as it would be a degradation.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do not look at specific part, because it can be replaced, but the driver is generic thing for rp2040 flash support rather then device beyond it.

}

irq_unlock(key);
Expand All @@ -256,25 +112,25 @@ static int flash_rpi_write(const struct device *dev, off_t offset, const void *d

static int flash_rpi_erase(const struct device *dev, off_t offset, size_t size)
{
uint32_t key;
ARG_UNUSED(dev);

if (size == 0) {
return 0;
}

if (!is_valid_range(offset, size)) {
LOG_ERR("Erase range exceeds the flash boundaries. Offset=%#lx, Size=%u",
offset, size);
LOG_ERR("Erase range exceeds the flash boundaries. Offset=%#lx, Size=%u", offset,
size);
return -EINVAL;
}

if ((offset % SECTOR_SIZE) || (size % SECTOR_SIZE)) {
LOG_ERR("Erase range is not a multiple of the sector size. Offset=%#lx, Size=%u",
offset, size);
offset, size);
return -EINVAL;
}

key = irq_lock();
uint32_t key = irq_lock();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unneeded change.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll roll this back.


flash_range_erase(offset, size);

Expand All @@ -298,7 +154,7 @@ static const struct flash_pages_layout flash_rpi_pages_layout = {
};

void flash_rpi_page_layout(const struct device *dev, const struct flash_pages_layout **layout,
size_t *layout_size)
size_t *layout_size)
{
*layout = &flash_rpi_pages_layout;
*layout_size = 1;
Expand All @@ -316,5 +172,5 @@ static DEVICE_API(flash, flash_rpi_driver_api) = {
#endif /* CONFIG_FLASH_PAGE_LAYOUT */
};

DEVICE_DT_INST_DEFINE(0, NULL, NULL, NULL, NULL, POST_KERNEL,
CONFIG_FLASH_INIT_PRIORITY, &flash_rpi_driver_api);
DEVICE_DT_INST_DEFINE(0, NULL, NULL, NULL, NULL, POST_KERNEL, CONFIG_FLASH_INIT_PRIORITY,
&flash_rpi_driver_api);
4 changes: 2 additions & 2 deletions dts/arm/raspberrypi/rpi_pico/rp2350.dtsi
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -192,7 +192,7 @@

qmi: flash-controller@400d0000 {
compatible = "raspberrypi,pico-flash-controller";
reg = <0x400d0000 0xfc>;
reg = <0x400d0000 0x54>;

#address-cells = <1>;
#size-cells = <1>;
Expand All @@ -202,7 +202,7 @@
write-block-size = <1>;
erase-block-size = <DT_SIZE_K(4)>;
};
status = "disabled";
status = "okay";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that "okay" is the implicit default, so this can be removed.

};

reset: reset-controller@40020000 {
Expand Down
22 changes: 22 additions & 0 deletions tests/drivers/flash/common/boards/rpi_pico.overlay
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
/*
* Copyright (c) 2024 Manuel Aebischer
*
* SPDX-License-Identifier: Apache-2.0
*/

/delete-node/ &code_partition;

&flash0 {
partitions {
code_partition: partition@100 {
label = "code-partition";
reg = <0x100 (DT_SIZE_M(2) - 0x100)>;
read-only;
};

storage_partition: partition@20000 {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Pico only has 2MB of storage. Is this partitioning correct?

label = "storage-partition";
reg = <0x20000 (DT_SIZE_M(2))>;
};
};
};
22 changes: 22 additions & 0 deletions tests/drivers/flash/common/boards/rpi_pico2_m33.overlay
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
/*
* Copyright (c) 2024 Manuel Aebischer
*
* SPDX-License-Identifier: Apache-2.0
*/

/delete-node/ &code_partition;

&flash0 {
partitions {
code_partition: partition@100 {
label = "code-partition";
reg = <0x100 (DT_SIZE_M(2) - 0x100)>;
read-only;
};

storage_partition: partition@20000 {
label = "storage-partition";
reg = <0x20000 (DT_SIZE_M(2))>;
};
};
};