omap3 startup memory map
richard.woodruff at linaro.org
Mon Sep 13 13:54:07 BST 2010
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 at 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
"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)
"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.
On Mon, Sep 6, 2010 at 11:14 AM, Peter Maydell <peter.maydell at 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:
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linaro-dev