Kernel oops when initializing ethernet driver

Kernel oops when initializing ethernet driver

[Patrick Huesmann]

Hi,

I'm getting a kernel oops that's triggered by the device driver
initialization code (Xilinx VirtexII-Pro on-chip ethernet).

It crashes when executing the code
XIIF_V123B_RESET(InstancePtr->BaseAddress);
(line 554, function XEmac_Reset() in drivers/net/xilinx_enet/xemac.c)

The oops message looks like this:
> Instruction machine check in kernel mode.
> Oops: machine check, sig: 7
> NIP: C00BBA78 XER: C000005F LR: C00BBA6C SP: C1FEFF20 REGS: c1fefe70 TRAP:
0200    Not tainted
> MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> TASK = c1fee000[1] 'swapper' Last syscall: 120
> last math 00000000 last altivec 00000000
> GPR00: 0000000A C1FEFF20 C1FEE000 00000020 00001030 00000001 0000068D
C015377F
> GPR08: 00000000 C3000000 00000034 C1FEFE30 C0160000 00003104 00000000
00000000
> GPR16: 00000000 00000000 00000000 FFFFC430 00000000 FFFFC488 FFFFC420
FFFFC4A0
> GPR24: 00000000 08100000 00000000 C0130A60 C1FD7560 00000000 C0160000
C1FD75E8
> Call backtrace:
> C00BBA6C C00BB5E0 C0162890 C0162AA4 C015A618 C00024B0 C0006BD4

I don't know jack about kernel oopses, but I learned that this is probably a
access violation (Address not mapped in MMU, or whatever).

The address that the driver wants to access is 0xc3000040, which is the
virtual address of some ethernet softcore register. The physical registers
of the NIC begin at 0x80000000, and IIRC they are mapped to 0xc3000000 by
cfg->BaseAddress = (u32) ioremap(lp->save_BaseAddress, remap_size);
in the module's probe() function in xilinx_enet/adapter.c
where remap_size is well above 0x40 (it's 0x4000, AFAIK)

Does anybody know what could be the problem? Do I have to do some I/O
mapping by hand, before the driver's init routine is invoked? Do I have to
configure the FPGA bitstream in some magic way, before the Linux drivers can
be used?

I'm using the linuxppc_2_4_devel tree from Montavista and a gcc-3.3.2
toolchain.
I'm linking the ethernet driver straight into the kernel (not as loadable
module).

Thanks in advance,
Patrick


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

Re: Kernel oops when initializing ethernet driver

[Patrick Huesmann]

Hi,

> Machine check means you generated an address that the hardware was
> unable to complete - you wrote (or read) a non-existent address.  It's
> mapped in the MMU ok but doesn't exist on the board.

Do you mean something like a "bus error"?

> Memory mapped I/O tends to exist in tight little clusters, and if you get
> your address off by 1 or something you get a machine check.  So you
> gotta find exactly what address it's writing to and why it's off -
> probably
> .h configuration kind of thing somewhere...

Interestingly, the kernel only crashes when accessing that one particular
register (at offset 0x0040). Every other register in that range can be
written to and read from w/o problems.

> Hope that's some kind of help :-)

Thanks a lot,
Patrick


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

Re: Kernel oops when initializing ethernet driver

[Patrick Huesmann]

Hi,

> > Interestingly, the kernel only crashes when accessing that one
> particular
> > register (at offset 0x0040). Every other register in that range can be
> > written to and read from w/o problems.
>
> So that sounds like a hardware problem, doesn't it.  This is one of those
> things where the FPGA has a hard PPC core and a bunch of VHDL
> peripherals?

Yes, exactly. The peripherals are connected to the PPC core via the OPB
(on-chip peripheral bus) and now I must assume that the address decode /
"chip" select logic within that OPB is buggy or not configured right.

> The good thing there is that the VHDL isn't much harder
> to fix than C code.  That would be my wild guess - the VHDL is not
> decoding the address correctly.

I don't even know if we have the VHDL source - the peripherals are
ready-to-go logic units that are just inserted in the FPGA design.

> However, also check that you are not accidentally writing past 0x0040.
> For instance, if 0x0040 is a byte address and you write 16 bits you'll
> be writing to 0x0040 and 0x0041.

It is a 32-bit access at 0x0040.

Thanks,
Patrick


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

Re: Kernel oops when initializing ethernet driver

[Andrei Konovalov]

Hi Patrick,

Patrick Huesmann wrote:
> Hi,
>
>
>>>Interestingly, the kernel only crashes when accessing that one
>>
>>particular
>>
>>>register (at offset 0x0040). Every other register in that range can be
>>>written to and read from w/o problems.
>>
>>So that sounds like a hardware problem, doesn't it.  This is one of those
>>things where the FPGA has a hard PPC core and a bunch of VHDL
>>peripherals?
>
>
> Yes, exactly. The peripherals are connected to the PPC core via the OPB
> (on-chip peripheral bus) and now I must assume that the address decode /
> "chip" select logic within that OPB is buggy or not configured right.
>

AFAIK Xilinx recommends to use PLB version of the ethernet controller.
For performance reasons at least.

>
>>The good thing there is that the VHDL isn't much harder
>>to fix than C code.  That would be my wild guess - the VHDL is not
>>decoding the address correctly.
>
>
> I don't even know if we have the VHDL source - the peripherals are
> ready-to-go logic units that are just inserted in the FPGA design.
>
Do you use EDK to build your design?
>
>>However, also check that you are not accidentally writing past 0x0040.
>>For instance, if 0x0040 is a byte address and you write 16 bits you'll
>>be writing to 0x0040 and 0x0041.
>
>
> It is a 32-bit access at 0x0040.
>
> Thanks,
> Patrick
>

In your kernel boot messages do you see a line similar to:

eth0: Xilinx EMAC #0 at 0x60000000 mapped to 0xC9015000, irq=30

Is the physical address in your log the one you expect?


Best regards,
Andrei


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

Re: Kernel oops when initializing ethernet driver

[Patrick Huesmann]

> Hi Patrick,
>
> Patrick Huesmann wrote:
> > Hi,
> >
> >
> >>>Interestingly, the kernel only crashes when accessing that one
> >>
> >>particular
> >>
> >>>register (at offset 0x0040). Every other register in that range can be
> >>>written to and read from w/o problems.
> >>
> >>So that sounds like a hardware problem, doesn't it.  This is one of
> those
> >>things where the FPGA has a hard PPC core and a bunch of VHDL
> >>peripherals?
> >
> >
> > Yes, exactly. The peripherals are connected to the PPC core via the OPB
> > (on-chip peripheral bus) and now I must assume that the address decode /
> > "chip" select logic within that OPB is buggy or not configured right.
> >
>
> AFAIK Xilinx recommends to use PLB version of the ethernet controller.
> For performance reasons at least.
>
> >
> >>The good thing there is that the VHDL isn't much harder
> >>to fix than C code.  That would be my wild guess - the VHDL is not
> >>decoding the address correctly.
> >
> >
> > I don't even know if we have the VHDL source - the peripherals are
> > ready-to-go logic units that are just inserted in the FPGA design.
> >
> Do you use EDK to build your design?
> >
> >>However, also check that you are not accidentally writing past 0x0040.
> >>For instance, if 0x0040 is a byte address and you write 16 bits you'll
> >>be writing to 0x0040 and 0x0041.
> >
> >
> > It is a 32-bit access at 0x0040.
> >
> > Thanks,
> > Patrick
> >
>
> In your kernel boot messages do you see a line similar to:
>
> eth0: Xilinx EMAC #0 at 0x60000000 mapped to 0xC9015000, irq=30
>
> Is the physical address in your log the one you expect?
>
>
> Best regards,
> Andrei
>


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

Re: Kernel oops when initializing ethernet driver

[Patrick Huesmann]

Hi,

> > I don't even know if we have the VHDL source - the peripherals are
> > ready-to-go logic units that are just inserted in the FPGA design.
> >
> Do you use EDK to build your design?

Yes.

> Is the physical address in your log the one you expect?

Yes.

Apparently, the hardware guy disabled the ethernet controller's "S/W reset"
option in the EDK. This explains why the PPC got no ACK from OPB when
writing to the reset register, and threw the data check exception. I hope
that this problem is solved, when we enable that option.

Thanks again to all who replied,
Patrick


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