linguini1 opened a new pull request, #17102: URL: https://github.com/apache/nuttx/pull/17102
## Summary This PR contains two commits: 1. A basic implementation of mailbox API with some helpers for accessing properties implemented. Uses busy-wait due to documentation challenges with mailbox API. 2. Added autoled implementation for the Pi4B. Status LED is used as NuttX start indicator, while power LED is used for panic/assert indication. ## Impact This BCM2711 mailbox API is a base implementation which currently allows some important properties to be read (such as MAC address, CPU temperature, etc.). It has the necessary internals to be extended with more features (i.e setting power domains, clock frequencies, etc.) as necessary. This allows other parts of the RPi4B to be used (EMMC2 is my goal next). The autoled implementation is simply included in this PR as a visual of the testing that was performed (and because now I can finally interact with the on-board LEDs). It allows users of the Pi4B to get a clear visual indication of when NuttX has booted and also when anything causes an assertion failure/panic. ## Testing I tested all of the implemented mailbox functions to ensure that data was returned correctly (i.e. CPU temperature made sense). Here is an excerpt of the logs from testing the power domain statuses, where 11 was meant to fail with an error because that power domain does not exist. ``` NuttShell (NSH) NuttX-12.10.0 nsh> - Ready to Boot Primary CPU - Boot from EL2 - Boot from EL1 Turning off POWER LED...OS Initialize Turning on POWER LED... Power 0: on Power 1: off Power 2: off Power 3: off Power 4: off Power 5: off Power 6: off Power 7: off Power 8: off Power 9: off Power 10: off Couldn't get power status 11: -22 Power 11: off ``` I also tested the autoled implementation. After the proprietary boot process, NuttX takes control of the LEDs and turns off the POWER LED while turning on the STATUS LED. I rigged the `hello` example to include a `DEBUGASSERT(false)` statement in it, so when I ran it I could verify that the POWER LED comes on to indicate a failed assert. These are the logs from that: ``` NuttShell (NSH) NuttX-12.10.0 nsh> hello dump_assert_info: Current Version: NuttX 12.10.0 2190b8c614-dirty Sep 27 204 dump_assert_info: Assertion failed (_Bool)0 && "Panic here": at file: hello_8 up_dump_register: stack = 0x4d1fe0 up_dump_register: x0: 0x4d1fe0 x1: 0x1 up_dump_register: x2: 0x0 x3: 0x1 up_dump_register: x4: 0x0 x5: 0x7fffffffffffffff up_dump_register: x6: 0x7fffffffffffffff x7: 0x4df5c0 up_dump_register: x8: 0x0 x9: 0x0 up_dump_register: x10: 0x0 x11: 0xf up_dump_register: x12: 0x0 x13: 0x0 up_dump_register: x14: 0x0 x15: 0x0 up_dump_register: x16: 0x3 x17: 0x0 up_dump_register: x18: 0x0 x19: 0x4dd0e0 up_dump_register: x20: 0x4bfd3a x21: 0x4bfd53 up_dump_register: x22: 0x4d1fe0 x23: 0x4d1fe0 up_dump_register: x24: 0x4d1000 x25: 0x0 up_dump_register: x26: 0x6 x27: 0x2a up_dump_register: x28: 0x0 x29: 0x0 up_dump_register: x30: 0x4824c0 up_dump_register: up_dump_register: STATUS Registers: up_dump_register: SPSR: 0x5 up_dump_register: ELR: 0x484668 up_dump_register: SP_EL0: 0x0 up_dump_register: SP_ELX: 0x4df550 up_dump_register: EXE_DEPTH: 0x0 up_dump_register: SCTLR_EL1: 0x30d0180d Hello, World!! nsh> ``` After boot, before running hello: <img width="681" height="905" alt="image" src="https://github.com/user-attachments/assets/b356bb8f-802a-46f9-948f-f5e88c7fd91e"; /> After boot, after running hello: <img width="681" height="905" alt="image" src="https://github.com/user-attachments/assets/157607af-1ce2-4de7-a6dc-2e58544b983c"; /> I should note that after implementing this busy-wait version of the API, I wanted to move to an IRQ implementation with block read/writes. Unfortunately I couldn't seem to get the IRQ to trigger, and this is blocking me from implementing other features, so I decided to forgo that option. I may revisit this later, but I don't think the speed-up will matter at all. What would be beneficial is allowing multiple requests to be issued by multiple threads simultaneously. However, the mailbox isn't guaranteed to return responses in the same order it received the requests, so that would require more infrastructure in this API. For now I've also decided to forgo that option since this is blocking other features and the implementation would not be trivial. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
