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-woodruff2@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.maydell@linaro.orgwrote:

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