Marvell SoCs: is register remapping to 0xf1NNNNNN safe?

Marvell SoCs: is register remapping to 0xf1NNNNNN safe?

[Russell King - ARM Linux]

On the Armada 510, like most mvebu platforms, the registers are remapped
to 0xf1NNNNNN.  This means things like the ATA interfaces are at
0xf10a0000, SPI at 0xf1010600 etc.

It also means that the global config 1 register is at 0xf10e802c.  Other
registers live at 0xf10e0000, 0xf10e4000, etc.

Now, if I access any register in the 0xf10eNNNN, whether it be the global
configuration register, a GPIO register, AC'97 register, the result is an
instant and solid hang - presumably the bus locks up.  It doesn't matter
if it is accessed in an interrupt-protected region, preempt-disabled
region, or via a userspace mapping of that memory, the result is always
the same, and things like sysrq don't work.

Only a watchdog or power cycle recovers the SoC (presumably also a hardware
reset too, but I can't test that.)

Any ideas?  Can this behaviour be replicated on any other of these SoCs?

Marvell SoCs: is register remapping to 0xf1NNNNNN safe?

[Andrew Lunn]

On Tue, Jun 18, 2013 at 02:42:20PM +0100, Russell King - ARM Linux wrote:
> On the Armada 510, like most mvebu platforms, the registers are remapped
> to 0xf1NNNNNN.  This means things like the ATA interfaces are at
> 0xf10a0000, SPI at 0xf1010600 etc.
> 
> It also means that the global config 1 register is at 0xf10e802c.  Other
> registers live at 0xf10e0000, 0xf10e4000, etc.
> 
> Now, if I access any register in the 0xf10eNNNN, whether it be the global
> configuration register, a GPIO register, AC'97 register, the result is an
> instant and solid hang - presumably the bus locks up.  It doesn't matter
> if it is accessed in an interrupt-protected region, preempt-disabled
> region, or via a userspace mapping of that memory, the result is always
> the same, and things like sysrq don't work.
> 
> Only a watchdog or power cycle recovers the SoC (presumably also a hardware
> reset too, but I can't test that.)
> 
> Any ideas?  Can this behaviour be replicated on any other of these SoCs?

Hi Russell

Kirkwood, and some of the other SoCs, will hang if the clock for the
IP block is not ticking.

   Andrew

Marvell SoCs: is register remapping to 0xf1NNNNNN safe?

[Sebastian Hesselbarth]

On 06/18/13 15:42, Russell King - ARM Linux wrote:
> On the Armada 510, like most mvebu platforms, the registers are remapped
> to 0xf1NNNNNN.  This means things like the ATA interfaces are at
> 0xf10a0000, SPI at 0xf1010600 etc.
>
> It also means that the global config 1 register is at 0xf10e802c.  Other
> registers live at 0xf10e0000, 0xf10e4000, etc.
>
> Now, if I access any register in the 0xf10eNNNN, whether it be the global
> configuration register, a GPIO register, AC'97 register, the result is an
> instant and solid hang - presumably the bus locks up.  It doesn't matter
> if it is accessed in an interrupt-protected region, preempt-disabled
> region, or via a userspace mapping of that memory, the result is always
> the same, and things like sysrq don't work.
>
> Only a watchdog or power cycle recovers the SoC (presumably also a hardware
> reset too, but I can't test that.)
>
> Any ideas?  Can this behaviour be replicated on any other of these SoCs?

Russell,

just to make sure: Is pdma clock enabled, i.e. ungated? Usually, Dove
only hangs if corresponding clocks are not enabled.

Sebastian