Skip to content
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.

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

Add ESP32-P4 support #2063

Closed
wants to merge 5 commits into from
Closed

Add ESP32-P4 support #2063

wants to merge 5 commits into from

Conversation

orsolic
Copy link

@orsolic orsolic commented Jan 25, 2025

Here is commit with start of support for ESP32-P4.

I have started working on flashing support but I need to shelve that plan for the time being.
I am pushing the things which seems to work - patch is rough, but more will hopefully come later.

Tested with BMA and ESP-prog (FT2232H) on FreeBSD with Waveshare ESP32-P4 board with flashed IDF example.

Works:

  • JTAG scan
  • attach to target
  • run program
  • reset
  • hardware breakpoint
  • continue
  • printing of var in SRAM
>>> p var
$4 = 123
>>> p &var
$5 = (uint32_t *) 0x4ff26334
>>> x /d 0x4ff26334
0x4ff26334:     123
  • changing value of var:
>>> set var var = 100
>>> p var
$8 = 100
>>> x /d 0x4ff26334
0x4ff26334:     100

What doesn't work:

  • software breakpoint (needs flash support)
  • stepping
  • single instruction stepping

Tested on BMA, after jtag_scan:
ID code 0x00012c25: ESP32-P4
ID code 0x00012c25: ESP32-P4
RISC-V debug v0.13/v1.0 DMI
RISC-V debug v0.13 DM
Skipping hart 0 -> Unavailable
RISC-V debug v0.13/v1.0 DMI
According to the RISC-V debug specification, DM must be turned on before
accessing DM registers (like reading version of DM).
This fixes attaching to target
Copy link
Member

@dragonmux dragonmux left a comment

Choose a reason for hiding this comment

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

This looks interesting - there are some issues though, particular involving repeated scans within a session. Please see our review notes for details.

/* workaround for ESP32-P4 which has 2 different ir_value */
if ((idcode == 0x12c25) && (previous_idx == idx))
idx++;
previous_idx = idx;
Copy link
Member

Choose a reason for hiding this comment

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

Do please note that this will only work for a single scan - the next run through will break. This is because previous_idx is static and so only initialised once on program start and is unable to be reset to 0.

It might be better to make the previous index used a return parameter to this function stored as a local in the calling context, this way it can be properly reinitialised on each new scan.

Copy link
Author

Choose a reason for hiding this comment

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

It works for multiple scans - first scan:
jtag_device_get_quirks() returning idx: 40
jtag_device_get_quirks() returning idx: 41

Second scan:
jtag_device_get_quirks() returning idx: 40
jtag_device_get_quirks() returning idx: 41

If it isn't static it will fail on the 1st scan:
jtag_device_get_quirks() returning idx: 40
jtag_device_get_quirks() returning idx: 40
jtag_scan: IR does not match the expected value, bailing out

src/target/jtag_scan.c Outdated Show resolved Hide resolved
src/target/riscv_debug.c Outdated Show resolved Hide resolved
src/target/riscv_debug.c Outdated Show resolved Hide resolved
src/target/riscv_debug.c Outdated Show resolved Hide resolved
src/target/jtag_devs.c Outdated Show resolved Hide resolved
@dragonmux dragonmux added this to the v2.1 release milestone Jan 26, 2025
@dragonmux dragonmux added the New Target New debug target label Jan 26, 2025
@orsolic
Copy link
Author

orsolic commented Jan 27, 2025

Thanks for the review!
I've force pushed the updated changes.

@orsolic orsolic closed this Jan 27, 2025
@orsolic orsolic deleted the esp32p4 branch January 27, 2025 20:41
@orsolic
Copy link
Author

orsolic commented Jan 27, 2025

I've accidentally pushed the wrong branch (the one with included FreeBSD build fix), then deleted it, which caused this PR to be closed, and now I can't reopen it.
Can you reopen it? Or, should I create a new PR?

@esden
Copy link
Member

esden commented Jan 27, 2025

The problem is that you deleted the branch on your repository, so this PR does not have anything to reference to. I think you will have to open a new pull request.

@orsolic orsolic mentioned this pull request Jan 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
New Target New debug target
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants