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