My current source tree is linux 2.2.2 + rmk5 + linux-2.2.2-philb-990301
It appears that philb changes arch/arm/mm/proc-sa110.S and associated files
which removes references to DOM_KERNELDOMAIN (from ../lib/genconsdata.c).
However, I don't understand what the sa110 changes are in order to propagate
them into proc-arm6,7.S, and remove the offending:
teq r0, #0
moveq r0, #DOM_KERNELDOMAIN
movne r0, #DOM_USERDOMAIN
However, I'm not sure why I need to get the MMU stuff for an ARM7 when I have
a StrongARM in my RiscPC. I suspect that really the config stuff needs to
ask three questions:
What architecture are you compiling for? [RiscPC here]
What is the minimum CPU required to run? [eg ARM6 or StrongARM]
Tune for which CPU?
For a distribution kernel you'd answer RiscPC,ARM6,StrongARM on the assumption
that most people have StrongARMs, but some only have ARM6, so you'd like it to
run on everything, but run fastest on StrongARM.
And when I build my personal kernel I'd like to say RiscPC,StrongARM,StrongARM
and get 64 bit multiplies, sign extending byte loads and other StrongARM
instructions, with arch/arm/Makefile clever enough to realise that it'll
have to tell gcc to prevent generation of LDRH and STRH.
Currently it seems that both PhilB and Russell's work arounds to cope with
*****y Acorn's card basically generate ARM7 kernels. Am I missing much
performance not getting the armv4 instructions?
(Can gcc already do -march=armv4 with another -m to stop LDRH/STRH?)
Is this an optimal way of doing things? Or have I missed something?
Nick
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
