Dear OFW Gurus,
I (think I) am stuck in MMU setup on a Geode LX based board.
I've added a second LPC flash on it (IDSEL=1) but cannot access it (eg. to read manufacturer and device ID) due "page fault" error:
ok FFAC0000 rw@ Page Fault ok
While I can access IDSEL=0 flash:
ok FFBC0000 rw@ . ffff \BTW: manuf. and device ID have no mean here (this is not a real LPC flash..) ok
I can access this range of memory when CPU is just out of reset (with a JTAG interface), so hardware should be ok.
Any clue in how to add the required range on MMU map for my platform in OFW? (if this is the source of the fault of course)
TIA and best regards,
See http://wiki.laptop.org/go/Forth_Lesson_17
Andrea wrote:
Dear OFW Gurus,
I (think I) am stuck in MMU setup on a Geode LX based board.
I've added a second LPC flash on it (IDSEL=1) but cannot access it (eg. to read manufacturer and device ID) due "page fault" error:
ok FFAC0000 rw@ Page Fault ok
While I can access IDSEL=0 flash:
ok FFBC0000 rw@ . ffff \BTW: manuf. and device ID have no mean here (this is not a real LPC flash..) ok
I can access this range of memory when CPU is just out of reset (with a JTAG interface), so hardware should be ok.
Any clue in how to add the required range on MMU map for my platform in OFW? (if this is the source of the fault of course)
TIA and best regards,
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,
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)
The MSR setup is done in two places: lxdevel/romreset.bth lines 89-103 lxdevel/msrinit.fth - table at beginning of file, routine to process that table at line 262
The MSRs setup in romreset.bth is necessary for early startup, to get the memory working. The rest of them can be deferred until later.
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..)
I'm not sure. I thought the LPC FLASH was at fff0.0000.
TIA and best regards,
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)
The MSR setup is done in two places: lxdevel/romreset.bth lines 89-103 lxdevel/msrinit.fth - table at beginning of file, routine to process that table at line 262
The MSRs setup in romreset.bth is necessary for early startup, to get the memory working. The rest of them can be deferred until later.
Yes, it should be in msrinit.fth because the "problem" appear as soon as I call set-msrs (after stop and "interacting" the OFW boot sequence, of course). romreset.bth should not be the problem here, because I step inside it and, at the end of its assembly, everything still look fine
I still cannot find the right msr.. I think you know the Geode/CS5535 architecture better than me, any clue about which one should be? (our mrsinit is the same as lxdevel at the moment)
TIA,
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,
Mitch Bradley wrote:
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. [snip]
Thanks for the clear explanation Mitch. I tried to use dynamic virtual address allocation but I have the same problem, which (IMHO) is a confirmation that the trick is at lower lever than virtual addressing.
Thanks anyway & best regards,
openfirmware@openfirmware.info
-
Andrea -
Mitch Bradley