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:
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,