oxidecomputer / oxidecomputer/hubris
Look at coalescing adjacent peripheral address ranges to save descriptors
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 3.6k
- Forks
- 239
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 23
Description
Cliff said:
FYI, to keep region count down (which is less critical on v8M but still), IOCON, PINT, and two currently-unused-but-relevant-looking blocks (GINT0/1) are adjacent. So you could merge them into one block at 0x4000_1000 with length 0x4000.
Ben:
It's not obvious from the data that the pint region can be combined. Maybe a close reading of the data sheet would make that clear, but it would be nice to be more explicit. If we had a hint in the chips file
that it was ok to combine regions with discontinuous addresses, then we could make it automatic if a single task used adjacent regions or such marked regions.
In chips/lpc55/chip.toml, the regions are:
bootrom 0x03000000..0x03010000 gap=0x3cff0000
syscon 0x40000000..0x40001000 is adjacent to
iocon 0x40001000..0x40002000 gap=0x00002000
pint 0x40004000..0x40005000 gap=0x00001000
inputmux 0x40006000..0x40007000 gap=0x0000c000
anactrl 0x40013000..0x40014000 gap=0x0000c000
pmc 0x40020000..0x40021000 gap=0x00013000
flash_controller 0x40034000..0x40035000 gap=0x00005000
rng 0x4003a000..0x4003b000 gap=0x0004b000
flexcomm0 0x40086000..0x40087000 gap=0x00002000
flexcomm3 0x40089000..0x4008a000 is adjacent to
flexcomm4 0x4008a000..0x4008b000 gap=0x00001000
gpio 0x4008c000..0x4008e484 gap=0x00007b7c
flexcomm5 0x40096000..0x40097000 gap=0x00008000
flexcomm8 0x4009f000..0x400a0000 gap=0x00004000
hash_crypt 0x400a4000..0x400a5000 gap=0x0005c200
dice_spmeasure 0x40101200..0x40101a00 is adjacent to
dice_rng 0x40101a00..0x40101b00 gap=0x0fefe500
secure_syscon 0x50000000..0x50001000 gap=0x00033000
secure_flash_controller 0x50034000..0x50035000
If there were no intervening active addresses, or if those addresses were just
mirrors of the regions' primary addresses, then they could be marked ok to combine.
Maybe this:
[iocon] address = 0x40001000 size = 4096 combine_ok = ["pint"] [pint] address = 0x4000_4000 size = 0x1000 interrupts = { irq0 = 4, irq1 = 5, irq2 = 6, irq3 = 7, irq4 = 32, irq5 = 33, irq6 = 34, irq7 = 35 } combine_ok = ["iocon"]
Or we could document that the address span is just a repeat of registers or no-op/not-faulting/not-dangerous and drive the logic from that.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with chips/lpc55/chip.toml and the LPC55 data sheet, focusing on the adjacent IOCON, PINT, GINT0/1, FLEXCOMM, and DICE regions. Determine whether intervening addresses are inactive or mirrors, then decide whether an explicit combine_ok hint or documented address-span rule is appropriate. Done means the combining behavior and its safety conditions are explicitly defined.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- embedded-iot
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100