Bug#658759: disable l2 cache on kirkwood devices (workaround #658904)
Hi Ian, On Aug 30, 2012, Ian Campbell wrote: 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): [...] 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. Sorry I missed this before. That sounds like an excellent idea for a kernel patch. A kind user on the linux-arm-kernel@ list[1] recently mentioned he'd be willing to test patches, if you need a guinea pig, and I assume once a patch is written and tested it should be possible to get useful feedback from the list. Thanks, Jonathan [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/185621/focus=185879 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120911060940.GA2124@mannheim-rule.local
Bug#658759: disable l2 cache on kirkwood devices (workaround #658904)
On Mon, 2012-09-10 at 23:09 -0700, Jonathan Nieder wrote: Hi Ian, On Aug 30, 2012, Ian Campbell wrote: 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): [...] 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. Sorry I missed this before. That sounds like an excellent idea for a kernel patch. A kind user on the linux-arm-kernel@ list[1] recently mentioned he'd be willing to test patches, if you need a guinea pig, and I assume once a patch is written and tested it should be possible to get useful feedback from the list. My main concern with doing this on the kernel side is that it will eventually fall foul of the attempts to reduce everything to a single kernel image, since the code will necessarily be quite kirkwood specific and run very early on. Martin's testing of di on ARM[0] suggests this issue isn't all that widespread, which lead me to conclude that the risk of making a change like this (either in the kernel or the installer/flash-kernel) for Wheezy was not worth the chance of breaking some other kirkwood device. Ian. [0] https://lists.debian.org/debian-boot/2012/09/msg00052.html -- Ian Campbell Current Noise: Crowbar - To Build A Mountain Sex is like air. It's only a big deal if you can't get any. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1347355043.5305.137.ca...@zakaz.uk.xensource.com
Bug#658759: disable l2 cache on kirkwood devices (workaround #658904)
Ian Campbell wrote: My main concern with doing this on the kernel side is that it will eventually fall foul of the attempts to reduce everything to a single kernel image, since the code will necessarily be quite kirkwood specific and run very early on. Is it possible to do something reasonable if the extra features register is read first? (Please forgive my ignorance.) Martin's testing of di on ARM[0] suggests this issue isn't all that widespread, which lead me to conclude that the risk of making a change like this (either in the kernel or the installer/flash-kernel) for Wheezy was not worth the chance of breaking some other kirkwood device. I think that's ok --- the change would be valuable upstream anyway, and it can filter into mainline and wheezy whenever it has had an appropriate amount of testing. Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120911105734.GA2356@mannheim-rule.local
Bug#658759: disable l2 cache on kirkwood devices (workaround #658904)
On Tue, 2012-09-11 at 03:57 -0700, Jonathan Nieder wrote: Ian Campbell wrote: My main concern with doing this on the kernel side is that it will eventually fall foul of the attempts to reduce everything to a single kernel image, since the code will necessarily be quite kirkwood specific and run very early on. Is it possible to do something reasonable if the extra features register is read first? (Please forgive my ignorance.) I'm afraid I don't know either. Is this extra features register ARM architectural or specific to the Kirkwood devices? I think the cache control registers are implementation defined, so this code would need to know it is running on a specific set of processors before it would be safe to run it. Martin's testing of di on ARM[0] suggests this issue isn't all that widespread, which lead me to conclude that the risk of making a change like this (either in the kernel or the installer/flash-kernel) for Wheezy was not worth the chance of breaking some other kirkwood device. I think that's ok --- the change would be valuable upstream anyway, and it can filter into mainline and wheezy whenever it has had an appropriate amount of testing. Ian. -- Ian Campbell Current Noise: Faal - My Body Glows Red A soft drink turneth away company. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1347370061.5305.147.ca...@zakaz.uk.xensource.com
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, #0x40
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
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1346319361.27277.52.ca...@zakaz.uk.xensource.com
