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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
