oxidecomputer / oxidecomputer/hubris

Look at coalescing adjacent peripheral address ranges to save descriptors

Open
#2,008 2 comments 0 reactions 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.