Second ethernet port

Hi gmz,

> What do I need to do to get uClinux to find the second port?

Take a look at drivers/net/smc91111.c.

At a minimum, it looks like you'll have to add an entry to smc_portlist[] and

smc_irqlist[] (both are NULL-terminated lists).

The smc_portlist[] is used during the initial scan in the driver init routine.

Regards,

--Scott

Thanks for the info Scott. Unfortunately, I'm just a HW guy trying to hack the kernel a bit and get some testing done. I tried several different values in the two arrays you mentioned but no change. The address that the kernel maps the first port to does not match the actual HW address. This probably isn't important, since the first port works fine.

Any suggestions for values? Should they match the ether= and reserve= on the kernel command line, or do I need some other probe function call somewhere else?

-Gary

Hi Gary,

> trying to hack the kernel a bit and get some testing done.

I took a closer look myself ... as it turns out it looks like the driver will

only work with a single device since it stops probing once it finds the

first device.

> the kernel maps the first port to does not match the actual HW address.

If the address is 0x300 higher than you expect, this is normal as that is

where the registers are actually located.

> Any suggestions for values?

If all you want to do is test the second device (e.g. HW DVT), you can just

hardcode the values as the first entries in the tables. This way, your second device,

if present & detected will always be selected in lieu of the first device. (remember to

use the address of the registers). Otherwise, the driver code will need to be

updated to support more than a single device.

Regards,

--Scott

Hi Gary,

I forgot some food-for-thought:

Our HW engineers have found u-boot to be fairly handy for a variety

of hardware testing tasks. If you get a chance you might want to take

a peek.

Regards,

--Scott

Hi Scott,

Thanks for all the help. I'll check out u_boot. Finally got everything tested, and BTW, the kernel recognized both ports once I got the arrays initialized with the correct values. The base addresses were offset by 0x80000000, I'm guessing to activate the cache bypass.

Do you happen to know where the variables na_enet and na_enet_irq get initialized? I'm grepping through the source now.

-Gary

Hi Gary,

Glad things are working :-)

> Do you happen to know where the variables na_enet and na_enet_irq get initialized?

All the na_xxx stuff is from the SDK, SOPCBuilder, whatever header files -- I don't have

access to my linux build machine right now ... but the header file should be in your

local directory (the one setup by the IDE for building the kernel). I think it's system.h.

Regards,

--Scott

Hi gary... Scott is right... the na_xxx style variables are all hold overs from the Nios I days.

In the Nios II kernel, you'll find all na_xxx definitions within the kernel build include directory (...include/nios2_system.h). At the current point in time, whenever an LAN91C111 component is found, the base address and the irq for the component are stored in the na_enet and na_enet_irq symbols.

The creation of the nios2_system.h file is handled by the kernel build process, and in particular, the scripts can be found within (...arch/nios2nommu/scripts).

And yes, the high bit is always turned on during device access to bypass the cache.