Revisit cache/uncache workaround in fio-ml.c

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 50 forks source link

Revisit cache/uncache workaround in fio-ml.c #50

Open reticulatedpines opened 2 years ago

reticulatedpines commented 2 years ago

CONFIG_MEM_2GB cams don't have enough virtual address space to use the old cache/uncache scheme.

Is the workaround in fio-ml.c appropriate? Is it performant? Is there a better way of mapping between these types of address?

kitor commented 2 years ago

As found out, this applies to D8 in general. M50 with 1GB has the same error: See e0089224 R180 or e012312c on M50.110 (used by both FSUBlockRead and FSUBlockWrite:

if (addr < 0xE0000000) {
    status = IsUncacheableMemory(addr);
    if ((status != 0) || ... ) {
       //normal path
    }
    fmt = "Please Designate Uncacheable Addr!!!!!!";
  }

where IsUncacheableMemory asserts if address is above 0xBFFFFFFF and returns logic value if address is below 0x40000000 or not.

reticulatedpines commented 1 year ago

This ticket probably becomes:

check cache / uncache logic from roms on each digic gen
document cache / uncache behaviour per gen (maybe in source, next to CACHE / UNCACHE macros?)
ensure cache / uncache logic in ML is correct per gen
check modules to make sure they don't depend on per gen behaviour, since modules are supposed to be cam independent. Thus, modules cannot: use CACHE/UNCACHE macros, or bit twiddle 0x4000.0000 directly, or use hard-coded addresses.

reticulatedpines commented 1 year ago

Also see IS_ROM_PTR