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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1347355043.5305.137.camel@zakaz.uk.xensource.com"> http://lists.debian.org/1347355043.5305.137.camel@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1347370061.5305.147.camel@zakaz.uk.xensource.com"> http://lists.debian.org/1347370061.5305.147.camel@zakaz.uk.xensource.com