reticulatedpines / magiclantern_simplified

A Git based version of Magic Lantern, for those unwilling or unable to work using Mercurial. The vast majority of branches have been removed, with those thought to be important brought in individually and merged.
GNU General Public License v2.0
142 stars 47 forks source link

Audit for constants that should be edmac_mmio structs #129

Open reticulatedpines opened 5 months ago

reticulatedpines commented 5 months ago

Multiple files use hardcoded addresses that relate to EDmac MMIO usage (e.g. raw.c, edmac.c, io_trace.c). These typically (always?) start with 0xC0FX_XXXX, both Digic 4 and 5 use this range. D6 and up put at least some in the 0xd00X_XXXX range. Sometimes the purpose of these have been confirmed to be the same, with the same offset from a changed base.

See changes around RAW_LV_EDMAC to RAW_LV_EDMAC_CHANNEL_ADDR for the earliest example of refactoring. These can be hard to find, because there is no specified type and offsets into the struct are sometimes given as base + offset but sometimes used directly, e.g. #define RAW_PHOTO_EDMAC 0xc0f04008 - this is a reference to ram_addr field in struct edmac_mmio (see edmac.h).

For the record, I am not responsible for this monstrous design decision.

It must be fixed for modern cams to work at all. Accessing incorrect MMIO devices can of course be very dangerous.

We mostly get away with this for now because EngDrvOut() is a nop in function_overrides.c, and modern cams have so few features that they rarely hit code using MMIO registers. They do hit some though.

Early audit + fix work can add guards to MMIO usage so it errors on compile for D678X cams. This finds the most urgent areas and stops accidental problems in the future, for currently unused code.

reticulatedpines commented 5 months ago

Probably all uses of edmac_get_base() will want converting.