developer_guide: write the MPU section - #293
Conversation
The section was a placeholder. Covers the SIO3 link and where the per-cam MMIO addresses are listed, the Canon side function names and which cams they are located on, how to find them on a new cam (the assertion strings, InitializeIntercom, the three allocRingBuffer sizes), and the message format with the class and id mapping in known_spells.py. Also states what is not known, since the property mapping can suggest more understanding than we have: we can usually say which property a message carries, and generally cannot say what its bytes mean. That is why qemu-eos replays transcripts rather than generating them. Notes the two MPU parts and that mpu_dump only works on the older one.
|
Hi - I don't recognise your name from the forum or Discord. What's your background dealing with MPU hardware? Some of the information in the commit is useful, but it's nearly all information about software, and section 2 is supposed to be for hardware. Obviously, the developer guide is in early stages and not well structured yet, but my intention was for detailed software information to occur after an introduction to the hardware. Some of the paras in the commit are kind of unrelated. They vaguely relate to MPU, but don't have a good narrative flow for a developer guide. Are these LLM written possibly? They're not as good at keeping track of long range info. Probably for these technical sections, we need more discussion before considering a PR. We'd want to validate any new info, make sure any assertions are correct on listed cams, etc. If you're on the forum or Discord, those are better places than github for detailed discussion. |
2 participants
The MPU section of the developer guide was a placeholder reading "ML relevant
information re MPU goes here." This fills it in from what is already recorded in
the tree.
Covered:
listed (
hw/eos/model_list.cin qemu-eos)with the note that only the 100D is D45
"dwSize < TXBD_DATA_SIZE"assertionstring,
InitializeIntercomleading tompu_recv_cbr, and the threeallocRingBuffersizes, pointing at kitor's notes inplatform/R.180/stubs.Sfor the detailmpu_sendfunctions, and on D45 the addressesare RAM addresses because the code is relocated at boot
known_spells.py0xCCCCCCCCgroup messages, which are the largest in the tables andwhose structure is not worked out
mpu_dumponly works on the older TMP19A43I also tried to be explicit about what is not known, because the ~300 entry
property mapping can suggest more understanding than we have. We can usually say
which property a message carries; we generally cannot say what its bytes mean.
That is the reason qemu-eos replays recorded transcripts instead of generating
messages, and it seemed worth stating in the guide rather than leaving a reader
to infer it.
Everything here comes from comments in the tree, the stub files, and
hw/eos/mpu.c, with the source named in each case so it can be checked orcorrected.
Style
I matched the existing sections rather than introducing anything new:
###headings only (no other section in the guide uses
####), flowing prose ratherthan subsections, escaped underscores, and roughly 95 character lines. The
section is 72 lines, against 41 for EDMAC and 60 for ADTG.
Regenerated with
generate_guide.pyto confirm it renders; the HTML output iscorrect and the escaped underscores and angle brackets come out as intended.
Happy to trim or restructure if it reads as too long for its slot.