Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Honored Contributor I
1,265 Views

Second ethernet port

I have a custom board with two 91c111 ethernet ports. uClinux recognizes the first port as eth0, but can't find eth1. I've tried the usual kernel parameters to autoprobe the second port, but no luck. 

 

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

 

Thanks.
0 Kudos
7 Replies
Highlighted
Honored Contributor I
5 Views

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
0 Kudos
Highlighted
Honored Contributor I
5 Views

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
0 Kudos
Highlighted
Honored Contributor I
5 Views

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
0 Kudos
Highlighted
Honored Contributor I
5 Views

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
0 Kudos
Highlighted
Honored Contributor I
5 Views

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
0 Kudos
Highlighted
Honored Contributor I
5 Views

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
0 Kudos
Highlighted
Honored Contributor I
5 Views

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