ARM page 0 set for page fault

[Sascha Hauer]

Hi Krzysztof,

On Sun, Apr 22, 2012 at 08:38:50PM +0200, Krzysztof Halasa wrote:
> Hi,
> 
> I'm trying to port my old IXP4xx (Intel XScale ARM big-endian mostly)
> patches to the current Barebox. Noticed the page #0 (virtual = physical
> addresses 0 - 0x1FFF, or the first 4 KiB of RAM) is not present:
> 
> commit abcf935e
> Author: Sascha Hauer <s.hauer at pengutronix.de>
> Date:   Sun Aug 7 19:00:56 2011 +0200
> 
>     ARM mmu: use high vectors if possible
> 
>     Using high vectors allows us to map a faulting zero page to
>     catch NULL pointer dereferences.
> 
> Unfortunately this causes "md" (memory dump) etc. to fail (also
> executing Linux kernel fails since the tags are located at 0x100 -
> should I relocate them?).
> 
> Should I do it differently, e.g. access RAM through an alias (IXP4xx has
> RAM aliased all over the place, one could also use MMU tables for this)
> so that the page fault only occurs on internal, not user-visible
> accesses (= users should not be able to access the first virtual page,
> even it they think the do)?

I would prefer the following order of precedence:

- Locate ATAGS to somewhere else. The kernel takes a pointer to ATAGs
  anyway, so this should work.
- Map SDRAM at 0x0 to some other place using the MMU. When the kernel
  then starts with MMU off the ATAGs are where the Kernel expects them
  to be.
- At an #ifdef around the code in mmu.c to make the zero page non
  faulting. Having the zero page faulting is a very useful feature
  though, so I would only go this way if nothing else helps.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |