WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: USB NIC : PiCore 7/8 on RPiZero v1.3  (Read 1724 times)

Offline CentralWare

  • Administrator
  • Hero Member
  • *****
  • Posts: 1652
USB NIC : PiCore 7/8 on RPiZero v1.3
« on: January 30, 2017, 05:11:36 PM »
armv6/7.0 and armv6/8.1.5 images being used to test with,
existing tce/optional cleared out completely,
dropbear and usb-net-KERNEL installed on both.

ifconfig -a shows only local loop (lo)

dmesg shows:
usb 1-1.2: new full-speed USB device number 4 using dwc_otg
usb 1-1.2: new USB device found, idVendor=0fe6, idProduct=8101
usb 1-1.2: new USB device strings: Mfr=0, Product=2, SerialNumber=3
usb 1-1.2: Product: USB Network Controller

Power supply is a 40amp regulated 5v source, OTG connected to 4 port hub connected to keyboard and NIC.
Keyboard is operational, NIC (LED) lights up as expected and links (100-T) to the switch with no flags noted on the switch.
I'll be trying wireless dongles here in a few, but wired ethernet is the goal for the project at hand even if wifi is successful.
Only TCL has been tested on the Zeros thus no clue as to another distro working or not with these NIC devices.

Note: Same setup and SD on Pi2/Pi3 seems to work fine
« Last Edit: January 30, 2017, 05:15:30 PM by centralware »
Over 90% of all computer problems can be traced back to the interface between the keyboard and the chair

Offline CentralWare

  • Administrator
  • Hero Member
  • *****
  • Posts: 1652
Re: USB NIC : PiCore 7/8 on RPiZero v1.3
« Reply #1 on: January 30, 2017, 10:33:27 PM »
After a total of eleven hours spent digging through What could have happened...

  • Turns out that my Zeros dislike Kontron (ICS) DM9601 Ethernet adapters (0FE6:8101) but they're okay with Davicom DM9601 (0A46:9106)?
        I haven't looked within the sources to see if there are any differences (or lack of IDs?) in net-usb-KERNEL.tcz
        HOWEVER, when both Kontron AND Davicom are connected (same hub) they BOTH work????  Tree problem, maybe?
  • Realtek RTL8150 from eons ago worked out of the box (though considering its age, took a while to find which box!)

I have all three versions connected to the hub (plus a keyboard) and oddly enough, they're all playing nice together without pipe issues/drops/etc. (thus far.)  Disconnect the Kontron, though, and the Davicom disappears right along with it.

Now, for those playing with PiZ's by using Pi2/Pi3/etc. as a programmer for the SD card...  if you're using TCZ's which are kernel related (such as this case with net-usb, I strongly recommend downloading BOTH the Arm6 AND the Arm7 versions, placing them in tce/optional together and updating onboot.lst to read the word KERNEL instead of the version listed (in the above case, it would be usb-net-KERNEL.tcz instead of usb-net-4.4.39-piCore+.tcz within onboot.lst thus it will know which file to use based on which Pi it's running on. This will save a great amount of grief and when you're finished, just DELETE any _v7 files in tce/optional if you need to conserve space.)

For those who own a soldering iron and enough skill to use it...

To do things cleanly with no OTG cables in stock (or if you simply want to ENSURE the cable you end up with works the first time) DISREGARD a lot of what you read online pertaining to "OTG" as it DOES NOT APPLY TO PI ZERO if you are connecting DEVICES TO IT as opposed to IT being connected TO a master device such as a PC (where the PI itself ends up being the plug-and-play device.)

For GADGET MODE (where PI connects to a PC), use ALL FIVE connectors on the MicroUSB side in the following order:
  • Vcc 5V
  • DATA -
  • DATA +
  • ID (GROUND)
  • GROUND

For USB MODE (where you connect the PI to a hub, ethernet or what-not)
  • Vcc 5V
  • DATA -
  • DATA +
  • DO NOT USE
  • GROUND

For USB MODE where you do not have a MicroUSB cable to hack or a MicroUSB end-connector to open up, on the bottom of the ZERO board
  • Vcc 5V (RED) Solder to P1
  • DATA - Solder to P23
  • DATA + Solder to P22
  • GROUND (BLACK) Solder to P6
Over 90% of all computer problems can be traced back to the interface between the keyboard and the chair