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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
