gregm wrote:
> Thats great until you don't have a PC BIOS to do it

Wait a minute, all I'm saying is that I think cache/mmu configuration should be done by the BSP code, not the application code.
Since the original question had to do with application code which happened to be running on pc386 bsp, (oops, "i386," see below) I think the answer was accurate and relevant.
Unless I've misunderstood, I don't think you are advocating that application code take over configuring the mmu.

> What happens when you want your bsp to work on an 
> x86 box with a broken or non-existant bios?

I would say that if the BIOS is broken, then the platform is not a PC, and the pc386 BSP is not appropriate for that platform.  If you encounter that case, you would need a BSP which was similar to pc386, but handled the hardware setup explicitly, and had replacements for the PCI configuration functionality provided by the 32 bit BIOS extensions on modern hardware.

Again, I don't really think that is relevant to the question of whether application code should be able to read memory mapped hardware registers.
You should be able to read memory mapped hardware registers, and unless your BSP is broken, you should not have to worry about hardware registers being cached by the processor.

However, after looking back at the original email, I see that I jumped to the conclusion that the question was being asked of the pc386 BSP, when actually the original question only stated i386 target.
If the target is in fact not a full PC architecture machine, then Eric's admonition of verifying MMU setup is appropriate.

-- Chris Caudle


