disable l2 cache on kirkwood devices (workaround #658904)
A while back a bug was discovered in u-boot on the kirkwood platform
which prevented modern kernels from booting[0]. Specifically u-boot was
failing to disable the L2 cache which interacts badly with kernels using
CONFIG_ARM_PATCH_PHYS_VIRT. CONFIG_ARM_PATCH_PHYS_VIRT relates to
running a single kernel image on multiple machines and so disabling it
was not really an option.
It's not immediately obvious which kirkwood platforms are effected,
since the only real way to tell is to try it (since the u-boot shipped
by the factory on these boards are many and varied). From the bug
reports we know that Dockstar, Shivaplug, Gruruplug and Dreamplug have
this issue. I've got a QNAP device which I indend to try as soon as I
can solder a serial console together[1].
u-boot has been fixed and the fix is available in Wheezy. However not
all kirkwood platforms have a serial console or a JTAG port so there is
a chance that upgrade will either brick the board (due to a botched
u-boot upgrade) or fail to boot the new kernel with no easy way to
recover (due to a lack of serial console to roll back).
I've just tried injecting the following onto the head of the zImage (in
a similar manner to flash-kernel's set_machine_id function):
# disable l2 caches
devio "wl 0xee3f3f11,4" # mrc 15, 1, r3, cr15, cr1, {0}
devio "wl 0xe3c33501,4" # bic r3, r3, #0x400000
devio "wl 0xee2f3f11,4" # mcr 15, 1, r3, cr15, cr1, {0}
# flush caches
devio "wl 0xe3a03000,4" # mov r3, #0
devio "wl 0xee073f17,4" # mcr 15, 0, r3, cr7, cr7, {0}
This works around the issue on my dreamplug (this is effectively the
same code sequence as what the u-boot fix does).
I can see two ways of distributing this fix. Either a kernel patch gated
on CONFIG_ARCH_KIRKWOOD to some early bit of code or use devio in
flash-kernel + the installer build.
If it's to be flash kernel then I suppose gating on the kernel flavour =
"kirkwood" would be wise, but we could also gate on a per machine basis.
In this case we would also need to duplicate the injection in the
installer build.
My only concern is whether this code sequence is valid on all the
kirkwood platforms which we support. I'd like to assume that the
processors were all similar enough but I don't really know.
Anybody have any thoughts on the best way to go about this or the sanity
of the approach generally?
Ian.
[0]
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658904
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658759
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685713
[1] Not a skill which I am renowned for possessing, so we'll see when
that actually happens ;-)
--
Ian Campbell
Current Noise: Anathema - Lightning Song
any new sendmail hole I have to fix before going on vacations?
-- Seen on #Linux
Reply to: