Adding linux-omap to CC
On 10 Sep 06, Peter Maydell wrote:
Hi. I have a question about what the memory map of the TI OMAP3 (35xx) looks like on startup, which I'm hoping somebody here can answer. (Steve, Richard: you're on the CC: because Loic suggested that you would be good people to ask.)
I'm currently looking at a bug in qemu: https://bugs.launchpad.net/qemu-maemo/+bug/628471 where we hang on bootup. That happens because the qemu implementation of NAND attached to the omap GPMC doesn't try to map anything into the memory space (it only does this for NOR devices).
From reading the OMAP35xx TRM I believe that when a NAND device is mapped into GPMC space (by setting GPMC_CONFIG7_i appropriately) then reads and writes to any address in the mapped region behave like accesses to GPMC_NAND_DATA_i. I have a patch which implements this mapping for NAND devices; however this causes a conflict about what should be mapped at address zero on startup, because:
(a) at reset GPMC_CONFIG7_i is 0xf40 for CS0 and 0xf00 for CS1..7, which maps CS0 to address 0. (On the Beagle board this is NAND.) (b) qemu also wants to map the boot ROM in at address 0
The TRM isn't terribly clear (to me :-)) about what happens at address zero on startup (it talks about a "1MB boot space" but doesn't say what this is or what address it is at or when it stops being in effect...)
It's also possible that qemu is wrong about mapping boot rom related things at address zero; we are emulating much of what the hardware's boot ROM does rather than actually executing it. However I would expect that there ought to be some real RAM/ROM there for the reset/exception vectors if nothing else...
So can anybody tell me what happens on real hardware?
-- Peter Maydell