Hi Peter, Are you past this? If not it might be easier to give me a call. If you miss a response from me its best to also copy my r-woodru...@ti.com email address (given my environment setup few mails age there much).
Where are you at in the world? I can verbally explain via phone more quickly. "Physical" zero on OMAP3/4 is not available to you. A mask ROM chip select will decode this region first. Additionally there is a hardware firewall which will limit access to some parts of the low region. So if you dump you will only get aborts from user/system mode. Only secure mode (in trustzone) can read. "Virtual" zero is yours to play with but traditionally its best to keep this to a bus error (abort) to catch NULL deference errors. IIRC you can place the physical addresses for GPMC as you like. There is a base address and a mask (which sets size). Mapping just needs to ensure no overlap happens between all the chip selects. A NAND device is just a port plus some control registers. So you only should need a small mapping to cover it. Your mapping just needs to start up the min size at a boundary aligned to that. I had had laid out mappings for some boards in the past. The ports I sampled just patterned matched my first work. Today I'm not sure for boards you are looking at. I do recall wondering long back if the resource allocation of physical space for GPMC should grow to be more PCI'ish where something like u-boot or the kernel dynamically maps regions instead of static maps. I opted to not do this then because of time and the fact many devices are ports with small size requirements, therefore a simple default would cover most cases. Regards, Richard W. On Mon, Sep 6, 2010 at 11:14 AM, Peter Maydell <peter.mayd...@linaro.org>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? > > Thanks in advance > -- Peter Maydell >
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
