No subject

is mapped into GPMC space (by setting GPMC_CONFIG7_i<br>
appropriately) then reads and writes to any address in the mapped<br>
region behave like accesses to GPMC_NAND_DATA_i. I have a patch<br>
which implements this mapping for NAND devices; however this<br>
causes a conflict about what should be mapped at address zero on<br>
startup, because:<br>
<br>
(a) at reset GPMC_CONFIG7_i is 0xf40 for CS0 and 0xf00 for CS1..7,<br>
which maps CS0 to address 0. (On the Beagle board this is NAND.)<br>
(b) qemu also wants to map the boot ROM in at address 0<br>
<br>
The TRM isn&#39;t terribly clear (to me :-)) about what happens at address<=
br>
zero on startup (it talks about a &quot;1MB boot space&quot; but doesn&#39;=
t say what<br>
this is or what address it is at or when it stops being in effect...)<br>
<br>
It&#39;s also possible that qemu is wrong about mapping boot rom related<br=
>
things at address zero; we are emulating much of what the hardware&#39;s<br=
>
boot ROM does rather than actually executing it. However I would expect<br>
that there ought to be some real RAM/ROM there for the reset/exception<br>
vectors if nothing else...<br>
<br>
So can anybody tell me what happens on real hardware?<br>
<br>
Thanks in advance<br>
<font color=3D"#888888">-- Peter Maydell<br>
</font></blockquote></div><br>

--0016363109298f2b920490239795--