Send release power-down (0xAB) instruction, to revive flash, that might be in power-down state #2130

2024-12-08T17:01:17-06:00

matsobdev commented

2024-12-08 17:01:17 -06:00

(Migrated from github.com)

It fixes #2111 of RP2350, by adding 0xAB instruction before communicating with flash device, ex. when restarting from flash by powman. Flash might be put in power-down state before and will only respond to 0xAB.

It fixes #2111 of RP2350, by adding `0xAB` instruction before communicating with flash device, ex. when restarting from flash by `powman`. Flash might be put in power-down state before and will only respond to `0xAB`.

Wren6991 (Migrated from github.com) reviewed

2024-12-08 17:01:17 -06:00

lurch commented

2024-12-08 17:13:49 -06:00

(Migrated from github.com)

Should this be gated behind a #ifdef setting, since I guess this will only be needed by executables that have explicitly powered-down the flash?

Should this be gated behind a `#ifdef` setting, since I guess this will only be needed by executables that have explicitly powered-down the flash?

matsobdev commented

2024-12-09 13:54:18 -06:00

(Migrated from github.com)

Sounds like a right direction. Is there a naming scheme to follow?

lurch commented

2024-12-09 18:08:28 -06:00

(Migrated from github.com)

Sounds like a right direction. Is there a naming scheme to follow?

Naming scheme is generally PICO_SOME_THING - see section 5.1 of https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf for a big list of examples 🙂

> Sounds like a right direction. Is there a naming scheme to follow? Naming scheme is generally `PICO_SOME_THING` - see section 5.1 of https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf for a big list of examples :slightly_smiling_face:

lurch (Migrated from github.com) reviewed

2025-01-22 09:29:00 -06:00

src/rp2040/boot_stage2/boot2_at25sf128a.S

It's probably fine to just add this #define directly (to the end of the #define CMD_... lines below), without wrapping it in an #if guard?

It's probably fine to just add this `#define` directly (to the end of the `#define CMD_...` lines below), without wrapping it in an `#if` guard?

matsobdev commented

2025-01-22 09:29:26 -06:00

(Migrated from github.com)

I've updated it, extended to RP2040, but now it is not picking up PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN :D I'll work on it.

I've updated it, extended to RP2040, but now it is not picking up `PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN` :D I'll work on it.

matsobdev (Migrated from github.com) reviewed

2025-01-22 09:31:20 -06:00

src/rp2040/boot_stage2/boot2_at25sf128a.S

I'd agree. I guess, it will be safe.

lurch (Migrated from github.com) reviewed

2025-01-22 09:50:45 -06:00

src/rp2040/boot_stage2/include/boot_stage2/config.h

				`@ -11,6 +11,11 @@`

Given that this is a boolean value, perhaps the "enable/disable" is implicit, and so "Release the flash device from power-down state during boot stage 2" would be an easier-to-read description?

matsobdev commented

2025-01-22 16:22:58 -06:00

(Migrated from github.com)

Now I know, why PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN was unreachable. Since there are two artefacts (if I wrap my head around it right way) built and boot stage 2 is the one of them, then it requires its own target_compile_definitions:

target_compile_definitions(bs2_default PRIVATE
	PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN=1
	)
target_compile_definitions(my_program PRIVATE
	PICO_EMBED_XIP_SETUP=1
	)

Maybe very beginning of chapter 5. of https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf requires then a word about bs2_default?

PS. boot2_at25sf128a and boot2_w25q080.S of RP2040 are now 252 bytes in size.

Now I know, why `PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN` was unreachable. Since there are two artefacts (if I wrap my head around it right way) built and boot stage 2 is the one of them, then it requires its own `target_compile_definitions`: ``` target_compile_definitions(bs2_default PRIVATE PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN=1 ) target_compile_definitions(my_program PRIVATE PICO_EMBED_XIP_SETUP=1 ) ``` Maybe very beginning of chapter 5. of https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf requires then a word about `bs2_default`? PS. `boot2_at25sf128a` and `boot2_w25q080.S` of RP2040 are now 252 bytes in size.

matsobdev (Migrated from github.com) reviewed

2025-01-22 16:24:25 -06:00

src/rp2040/boot_stage2/include/boot_stage2/config.h

				`@ -11,6 +11,11 @@`

I agree.

lurch commented

2025-01-22 19:01:21 -06:00

(Migrated from github.com)

It doesn't have much documentation yet, but PICO_EMBED_XIP_SETUP is also mentioned in a few other issues and PRs.

It doesn't have much [documentation](https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf) yet, but `PICO_EMBED_XIP_SETUP` is also mentioned in a few other [issues](https://github.com/search?q=repo%3Araspberrypi%2Fpico-sdk+PICO_EMBED_XIP_SETUP&type=issues) and [PRs](https://github.com/search?q=repo%3Araspberrypi%2Fpico-sdk+PICO_EMBED_XIP_SETUP&type=pullrequests).

matsobdev commented

2025-01-22 19:32:15 -06:00

(Migrated from github.com)

Yes, PICO_EMBED_XIP_SETUP is a key to get boot stage 2 on RP2350, where it might benefit the most from that 10 uA, but I was thinking about:

target_compile_definitions(bs2_default PRIVATE
	PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN=1
	)

since PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN will be accessible only, when target(ing)_compile_definitions of bs2_default. Root my_program, for basicly user's code won't reach that and PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN is useless then.

Yes, `PICO_EMBED_XIP_SETUP` is a key to get boot stage 2 on RP2350, where it might benefit the most from that 10 uA, but I was thinking about: ``` target_compile_definitions(bs2_default PRIVATE PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN=1 ) ``` since `PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN` will be accessible only, when `target(ing)_compile_definitions` of `bs2_default`. Root `my_program`, for basicly user's code won't reach that and `PICO_BOOT_STAGE2_FLASH_RELEASE_POWERDOWN` is useless then.

This pull request has changes conflicting with the target branch.

src/rp2040/boot_stage2/include/boot_stage2/config.h
src/rp2350/boot_stage2/include/boot_stage2/config.h

View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Merge commit title

Merge pull request 'Send release power-down (0xAB) instruction, to revive flash, that might be in power-down state' (#2130) from matsobdev/master into develop

Merge commit body

Reviewed-on: https://git.richey.dev/gh-raspberrypi/pico-sdk/pulls/2130

Merge pull request 'Send release power-down (0xAB) instruction, to revive flash, that might be in power-down state' (#2130) from matsobdev/master into develop

Reviewed-on: https://git.richey.dev/gh-raspberrypi/pico-sdk/pulls/2130

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin 'matsobdev/master:matsobdev/master'

git switch 'matsobdev/master'

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch 'develop'

git merge --no-ff 'matsobdev/master'

git switch 'matsobdev/master'

git rebase 'develop'

git switch 'develop'

git merge --ff-only 'matsobdev/master'

git switch 'matsobdev/master'

git rebase 'develop'

git switch 'develop'

git merge --no-ff 'matsobdev/master'

git switch 'develop'

git merge --squash 'matsobdev/master'