[ARM] head.S change broke platform device registration?

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Mon, Dec 10, 2012 at 06:21:52PM +0100, Marko Kati? wrote:
> > The code which distinguishes between Borzoi and Akita is this:
> >
> > /* Check for a second SCOOP chip - if found we have Borzoi */
> >         ldr     r1, .SCOOP2ADDR
> > ==cacheline boundary without patch (0x120)=====
> >         ldr     r7, .BORZOIID
> >         mov     r6, #0x0140
> >         strh    r6, [r1]
> > ==cacheline boundary with patch (0x160)======
> >         ldrh    r6, [r1]
> >         cmp     r6, #0x0140
> >         beq     .SHARPEND                       @ We have Borzoi
> >
> > /* Must be Akita */
> >         ldr     r7, .AKITAID
> >         b       .SHARPEND                       @ We have Borzoi
> >
> > and I've marked where the cache line boundary ends up with the patch
> > in place... except of course that the caches are off here, so the
> > placement of the code should be irrelevant.  It also would have the
> > reverse results from those that you're experiencing.
> >
> > My guess is that because the Scoop2 device is not present, the strh
> > access places 0x140 onto the data bus.  By the time the ldrh is
> > executed, it reads the data bus, and because nothing drives it, it
> > reads back the value last present on the bus, which happens to be
> > 0x140 - and this allows us to think we have the Scoop2 device.
> >
> > In theory, because the caches are off (including the instruction
> > cache) the CPU should fetch ldrh between the strh write and the
> > ldrh access to the same address.
> >
> > Having said all that, I'm not impressed by the above code; to write to
> > a memory region which may or may not have a device, and immediately
> > read it back is a recipe for exactly this kind of stuff happening.  If
> > anyone has looked at any real device detection code, they'll know that
> > this sequence is typical:
> >
> >         ldr     r0, =address
> >         mov     r1, #probe_data
> >         eor     r2, r1, #~0
> >         str     r1, [r0, #reg1]
> >         str     r2, [r0, #reg2]
> >         ldr     r3, [r0, #reg1]
> >         ldr     r0, [r0, #reg2]
> >         teq     r1, r3
> >         teqeq   r2, r0
> >         beq     found
> >
> > This sequence _purposely_ writes the opposite value between the first
> > store and the read-back of it to perturb the bus in case it's floating,
> > to prevent exactly these kinds of false positives.  The second check is
> > additional belt and braces to make the check even more secure.
> >
> > Can we do that with Scoop2?  I've no idea, I don't know what the weird
> > 0x40 offset is that's being probed by this code.  We need whoever wrote
> > this code, but I suspect they've long since moved on and aren't
> > interested in it.
> >
> > The alternative is we can rip out all this autodetection code and go
> > in the exact opposite direction to arm-soc and force Sharp kernels
> > to be built for the exact machine that they're to be run on.  Not
> > particularly desirable, but I don't have any other answers to this
> > without more information about the hardware.
> 
> The scoop device is a gate array, it's programming was never disclosed.
> It's datasheet can be found here (if it's of any use):
> 
> http://www.penguin.cz/~utx/zaurus/datasheets/ASIC_S1L50752B26B200/
> 
> So the only documentation we have is the arm/common/scoop.c driver.
> Richard might have more information on it, I CC-ed him.

Or maybe Richard can suggest a more secure probing solution along the
lines of the above given his experience with these platforms.