[EMAIL PROTECTED] (Eric W. Biederman) writes: > I have converted the ram initialization on the L440GX into > C and have continued my testing. > > So far so good. I can't quite boot linuxBIOS right now > but I haven't tracked any bugs back to using cache as ram > yet.
The good news. I have booted linuxBIOS, on the L440GX. The bad news. I have found a significant instability in the P3 cache as ram code. It works but it suffers from conflict misses when accessing non cached memory. The trivial reproducer is that if I attempt to zero memory to properly setup ECC the bios hangs. It is theoretically possible to work around but until I see a good way to handle this I won't recommend doing this on a P3. It becomes excessively easy to shoot yourself in the foot, and have bugs that come and go with minor tweaks to the code and recompiling. To work around this I tried playing with the CD and NW bits but neither of the ``cache disabled'' combinations that are documented as not dumping the cache kept data in the cache when I enabled them, so I couldn't even run my C code. The Pentium 4 does not suffer from this problem, making it a much friendly platform. > I have not yet actually been executing code out of the > cache as ram area, just using for data storage. That comes > later. I still need to do this but on preliminary test on the P4 everything worked except I couldn't not tear down the cache as ram area from code located in it. What is even more fun on a P4 is to disable caching on your code segment instructions are executed out of order. In particular I have seen serial port writes: CONSOLE_DEBUG_INLINE_TX_CHAR($'h') CONSOLE_DEBUG_INLINE_TX_CHAR($'e') CONSOLE_DEBUG_INLINE_TX_CHAR($'l') CONSOLE_DEBUG_INLINE_TX_CHAR($'l') CONSOLE_DEBUG_INLINE_TX_CHAR($'o') CONSOLE_DEBUG_INLINE_TX_CHAR($'\r') CONSOLE_DEBUG_INLINE_TX_CHAR($'\n') print out something like: olleh Though it was not that predictable... Eric
