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

[Marko Katić]

> 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.