[openfirmware] OFW x86 MMU Setup

[Mitch Bradley]

Okay, having reread the LPC FLASH chip manual, I see what is happening.  
(My intuition about LPC FLASH devices is deficient because I took a 
break from doing firmware during the period when Intel was inventing FWH.)

The virtual address range that OFW uses - see pc/virtaddr.fth : 
fw-virt-base , fw-virt-size - overlaps the physical address range that 
LPC FLASH chips use.  I probably would not have picked that virtual 
range had I realized that LPC devices decode more address space than 
they use for the data array.

Address conflicts like this is one of the reasons why virtual=physical 
address assignment is problematic.

(By the way, if you want to see the mapping for a virtual address, do this:
    ok  ffbc0000 map?
That tells you the corresponding physical address.
)

There are two ways around this problem:

a) Move the OFW virtual address range somewhere else, for example 
starting efc0.0000.  Of course that will lead to other possible address 
conflicts.  Hmmm, there is a virtual=physical mapping at efc0.0000 for 
the USB Option Controller.  That mapping should probably be made dynamic.

b) Use the dynamic virtual address allocation technique to map a virtual 
address for the LPC FLASH registers.  The right place to establish that 
mapping would be in the lpcflash driver itself.  You could either create 
the mapping before starting the write operation, and release it 
afterwards, or create the mapping at system startup using a "stand-init" 
routine, or create it on demand.  To create it on demand, you would do 
something like this:

0 value lpc-flash-regs
h# 20.0000 constant /lpc-flash
h# ffbc.0000 constant lpc-flash-regs-phys
: map-lpc-flash-regs  ( -- )
   lpc-flash-regs  0=  if
        /lpc-flash dup  mmu-claim  to lpc-flash-regs
       lpc-flash-regs-phys lpc-flash-regs /lpc-flash  -1 mmu-map
   then
;
: unmap-lpc-flash-regs  ( -- )
   lpc-flash-regs  if
         lpc-flash-regs  /lpc-flash   2dup mmu-unmap  mmu-release
         0 to lpc-flash-regs
   then
;
: ?lpc  ( -- )
    map-lpc-flash-regs
   lpc-flash-regs c@   ( id0 )
   dup 0=  swap h# ff =  or   if
      unmap-lpc-flash-regs
      true  abort" LPC FLASH not present"
   then
   geode-lpc-write-enable
;

...
: lpc-write-enable-block  ( adr -- )
    h# ffff and 2 or  lpc-flash-regs +  0 swap c!
;

Andrea wrote:
>
>
> Mitch Bradley wrote:
>> See http://wiki.laptop.org/go/Forth_Lesson_17
>>
>
> Thanks for the Lesson Mitch!
>
> I successfully enabled MMU but there is still some other problem, I 
> think at lower level that this..
> At address 0xFFAC0000 (physical or virtual it's the same.. I choose 
> phys=virt for ease) I should see my second flash (with IDSEL=1) but I 
> still see the first one (which is not a real LPC flash but an LPC dongle)
>
> It's not a problem of physical address conflict (on LPC bus) due the 
> fact that I can see the right data at system reset (with a JTAG 
> debugger, as previuosly told).
> With the same JTAG debugger, if I break the system when OFW is already 
> initialized, I have the same problem as above (at physical address 
> 0xFFAC0000 I see the LPC dongle memory)
>
> It seems that something at lower software level (some msr setup?) 
> "maps" 0xFFAC0000 somewhere else on LPC bus ('still don't know where.. 
> I will investigate..)
>
> Can you tell me where this kind of mappings (if any, of course) are 
> done in OFW? (I thinks it's not strictly OFW dependent but only 
> platform dependent.. but it will be usefull anyway to know where to 
> look inside OFW for the required changes)
>
> Can you also tell me where the MMU mapping of the first flash 
> (0xFFBC0000) is done? (maybe I can add my mmu initialization in a 
> better place..)
>
> TIA and best regards,
>