ARM, MMU and IO space mapping

[Robert Jarzmik]

Sascha Hauer <s.hauer at pengutronix.de> writes:

> Hmmm...
>
> I just made your patches work on my pcm027 board (If you haven't fixed
> the serial driver already: now I have patches for this). Without MMU
> everything is fine. With MMU I had to disable the zero page because
> otherwise the cfi flash driver will bail out with a NULL pointer deref.
> With this I noticed that when I start barebox from U-Boot that the
> driver does not recognize the flash.

I don't understand how that works. As the zero page is remapped onto the vectors
memory, how can a driver access the NOR chip ?

My understanding is that barebox makes a flat 1:1 mapping, and then replaces
the first section with a 2 levels translation, where :
 - the first 4096 bytes are mapped onto the malloc'd vectors
 - the remaining 1MBytes-4096Bytes are still in a flat 1:1 mapping

If that is correct, you loose your ability to access address space 0x00000000 -
0x00001000. How can you use the CFI after that ?

And as a consequence, I'm a bit afraid that my disk-on-chip, having it's memory
mapped to 0x0 - 0x2000, will be difficult to convert ... I must think of a way
in there.

> 		@ Data cache might be active.
> 		@ Be sure to flush kernel binary out of the cache,
> 		@ whatever state it is, before it is turned off.
> 		@ This is done by fetching through currently executed
> 		@ memory to be sure we hit the same cache.
> 		bic	r2, pc, #0x1f
> 		add	r3, r2, #0x10000	@ 64 kb is quite enough...
> 1:		ldr	r0, [r2], #32
> 		teq	r2, r3
> 		bne	1b
> 		mcr	p15, 0, r0, c7, c10, 4	@ drain WB
> 		mcr	p15, 0, r0, c7, c7, 0	@ flush I & D caches
>
> 		@ disabling MMU and caches
> 		mrc	p15, 0, r0, c1, c0, 0	@ read control reg
> 		bic	r0, r0, #0x05		@ clear DC, MMU
> 		bic	r0, r0, #0x1000		@ clear Icache
> 		mcr	p15, 0, r0, c1, c0, 0
>
> I don't know what's going on here.

I don't know either. All I see is that the datacache is filled so that stale
values are flushed out, and then it's flushed again through normal coproc
operations.
Note that there's an erratum in the XScale series that says that turning off the
cache leaves "dirty bits" set, and reenabling it later might cause havoc. That
would be a good reason for UBoot the read the 64kb before turning off the MMU,
wouldn't it ?

Moreover, another erratum says that the "mcr" disabling the MMU should be in the
first word of a cache line. If not, the ARM core _could_ be hung depending on
timings ... Errata are such fun :)

-- 
Robert