Initial P4 support tracking issue

[MabezDev]

Whilst we don't intend to do a full chip bring-up until the mass production version is released, we would like to get a minimal chip bring-up to aid future developments.

• PAC support
  • We have a PAC already in esp-pacs, will require patching I'm sure but at least for now we can probably consider this subtask complete
• Linker and required soc module features
• Tooling(?)
  • Add new chip detect magic value, ability to read chip revision for ESP32-P4 espflash#686
  • Initial ESP32-P4 support probe-rs/probe-rs#2047
• Uart driver - Add basic esp32p4 support #2466
• HIL runner

[jessebraham]

I again have a very basic application running on device, calling only esp_println::println!().

There is a caveat to this, in that the application works on the v1.0 devkit but neither the v1.1 not v1.2 version; I have some ideas with regards to this, but will require more experimentation. At least for the time being, I'm able to move forward using the old devkit.

Unfortunately I think getting a UART example running will take a bit more time than expected, as there is quite tight coupling between the interrupt support and various drivers. Given that the ESP32-P4 uses yet another interrupt controller (CLIC) this will take some time to sort out. Hoping to have a hacky PoC by end of week or early next week, though.

I will continue to update this issue as I make progress.

[bjoernQ]

I remember we had interrupts and gpio working in January or February already

[jessebraham]

I remember we had interrupts and gpio working in January or February already

Yes but there have been a number of changes to the HAL since January, and it's not as simple as copy-pasting the previous code in unfortunately. I do not think this will take a ton of time to be clear, but it will take some time to understand the changes which have been made and adapt the previous implementation to match.

[playfulFence]

Working on this right now. I'm not sure how far I'll get, but at least I want to adapt all the changes to the current state of a driver.

PS: Civilized people call it "rebase" directly actually 😅

[jessebraham]

@playfulFence Is the P4 HIL runner in a functional state? Can we tick off that task?

[bugadani]

Define functional, we have a raspberry that boots. We don't have anything on it, let alone flashing support in probe-rs or GHA workflows in this repo. What's the definition of done of that checkbox?

[jessebraham]

Define functional, we have a raspberry that boots. We don't have anything on it, let alone flashing support in probe-rs or GHA workflows in this repo. What's the definition of done of that checkbox?

Given that there is a separate task for tooling (which links to the probe-rs issue), I think just having the runner set up physically and having the GitHub runner configured is adequate. My understanding was that these steps have been completed, but perhaps I'm mistaken.

[MabezDev]

Dropping this back to the current milestone, there's a chance we can complete it in time, but if not we'll reassess what to do in the next planning meeting.

[MabezDev]

@playfulFence has been working hard to get interrupt support working. It's nearly there, and works correctly without vectoring the CPU interrupts (this is the RISCV interrupt controller vectoring, different from vectoring the peripheral interrupts). The P4 is quite different to the other esp's and requires a number of changes in esp-riscv-rt (based on esp-idf, we didn't actually get this working just yet).

I think we'll want to revisit this support once #2390 has landed, as upstream riscv-rt has better support for this and we should be directing our efforts there anyway.

We'll leave the PR open #2466 as draft, and we can occasionally rebase if anyone would like to try out running some pure Rust code on an early P4 devkit.