target entered debug mode

[Mark A. Greer]

Rolf Fiedler wrote:

> hi there,
>
> I have a monta vista 2.4.0-test1 kernel running on a IBM PPC405GP
> selfmade board. Connected to the board is an Abatron BDI2000, which
> I use for TFTP booting. The board mounts the root nfs via PMC ethernet
> (intel i82559ER). The internal ethernet controller isn't working,
> I have no idea why - can't talk to the LXT972 via MII management
> interface. That is my next task...

Doesn't the 82559 have an integrated PHY?

I've seen a problem with the eepro100 driver on big-endian machines where a
value written to a register is byte-swapped twice (making it unswapped).

Look in eepro100.c near the bottom of speedo_resume().  If you have a line
like:
outl(cpu_to_le32(TX_RING_ELEM_DMA(sp, sp->dirty_tx % TX_RING_SIZE)),
then the outl is byte-swapping and so is the cpu_to_le32.  That's wrong.  You
need to get rid of the cpu_to_le32.  Look for other combinations of outl and
cpu_to_le32 together and remove the cpu_to_le32--on my version, there is only
one occurance of this.

I've seen others report this problem too.  My understanding is that the author
is going to fix this and probably has but the 2.4.0-test1 version probably has
this problem.

> My question is:
> How come the board enters debug mode on the Abatron BDI2000 once
> in a while? I had it running processing data all over the weekend,
> and on monday it locked. I had a number of lock-ups since.
>
> what I get from the debugger is:
> - TARGET: target has entered debug mode
>
> and if I do info:
> Target state      : debug mode
> Debug entry cause : JTAG stop request
> Current PC        : 0xc0012b90
> Current CR        : 0x24000028
> Current MSR       : 0x00009230
> Current LR        : 0xc00048c4
>
> Is it a problem with the Abatron debugger or is my board instable?
>
> I did a objdump -d of the kernel running and the debug mode entry
> happend in the scheduler, in schedule:
>         /*
>          * 'sched_data' is protected by the fact that we can run
>          * only one process per CPU.
>          */
>         sched_data = & aligned_data[this_cpu].schedule_data;
> c0012b84:       3d 20 c0 14     lis     r9,-16364
> c0012b88:       39 29 b0 c0     addi    r9,r9,-20288
> c0012b8c:       7f de 4a 14     add     r30,r30,r9
>
>         spin_lock_irq(&runqueue_lock);
> c0012b90:       3d 60 c0 13     lis     r11,-16365     <--------
> c0012b94:       80 0b 83 e0     lwz     r0,-31776(r11)
> c0012b98:       7c 08 03 a6     mtlr    r0
> c0012b9c:       4e 80 00 21     blrl

I see this when cache is stale.  This is very easy to do when you download via
the bdi (or other probes).  A good general practice when downloading code with
a jtag probe is to invalidate all of L1 and L2 caches because they may/will be
stale.

I don't know what the cacheline size is on a 405GP so I don't know if 0x90 is
the first word on a new cacheline (usually ppc processor have 32 byte
cachelines which means it wouldn't be).  Either way, try invalidating all your
caches (do NOT flush them) as soon as the code you downloaded starts to run
and see if that helps.

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/