Updates and Problems on "Raspberry Pi USB and Ethernet Support" Project

Deval Shah deval.maker at gmail.com
Tue Jul 19 07:48:27 UTC 2016

Hello everyone,
As per the conversation at IRC I booted the testsuit with turning USB and
ethernet on. Also I ran FreeBSD on my Pi and got the bootup log as suggested by
Alan and Chris. Here are some observations.
1. After turning on USB in u-boot, I was getting power on USB devices atached.
(One of the device I have, has a LED idicator.) But as soon the testsuit
(init01) starts, the power to USB goes off. And didn't start afterwords.
2. I am adding relevant part of the FreeBSD boot log of my Pi. (Lines marked with “*” are the ones also coming in my testsuit.)

------------------------------------------------------------------------------------------------------ *bcm283x_dwcotg0: <DWC OTG 2.0 integrated USB controller (bcm283x)> mem
0x980000-0x99ffff on simplebus0 *usbus0 on bcm283x_dwcotg0 fb0: <BCM2835 VT framebuffer driver> on ofwbus0 fbd0 on fb0 VT: initialize with new VT driver “fb”. fb0: 656x416(656x416 at 0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x1eaac000, screen_size 818688 cryptosoft0: <software crypto> Timecounters tick every 10.000 msec *usbus0: 480Mbps High Speed USB v2.0 bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF ugen0.1: <DWCOTG> at usbus0 *uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0 mmcsd0: 8GB <SDHC SL08G 8.0 SN D00568A8 MFG 07/2015 by 3 SD> at mmc0
41.6MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/rootfs [rw]... warning: no time-of-day clock registered, system time will not be set
accurately *uhub0: 1 port with 1 removable, self powered ugen0.2: <vendor 0x0424> at usbus0 #uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr 2> on
usbus0 #uhub1: MTT enabled Growing root partition to fill device GEOM_PART: mmcsd0s2 was automatically resized. Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` to revert
them. mmcsd0s2 resized #uhub1: 5 ports with 4 removable, self powered mmcsd0s2a resized super-block backups (for fsck_ffs -b #) at: 2062528, 2578112, 3093696, 3609280, 4124864, 4640448,ugen0.3: <vendor 0x0424>
at usbus0 smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: <MII bus> on smsc0 ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: <USB Ethernet> on smsc0 ue0: Ethernet address: b8:27:eb:06:16:f9 5156032,ugen0.4: <vendor 0x0846> at usbus0 5671616, 6187200, 6702784, 7218368,ugen0.5: <SanDisk> at usbus0 umass0: <SanDisk Cruzer Blade, class 0/0, rev 2.10/1.00, addr 5> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0xc100 umass0:0:0: Attached to scbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: <SanDisk Cruzer Blade 1.00> Removable Direct Access SPC-4 SCSI device da0: Serial Number 4C530001020307111083 ... 

The Lines with “#” are related to the usb_ethernet controller driver. Detection
of the second “uhub” child (uhub1) seems the key thing here. After that smsc,
miibus and ukphy gets initialised. In my test suit I am not getting the “uhub1:”
part. Which have 5 ports with 4 removable, i.e. 1 Ethernet and 4 USB. I double checked the USB base adderess and the irq number.
In the line “uhub1: 5 ports with 4 removable, self powered”, does “self powered”
mean that it should be On by default for getting detected ? If that is true, How
can we switch On something in RTEMS ? Also what can switch off the USB, which
was already On by uboot ?
It looks like the “ugen” module finds that device and then gives control to
“uhub” (in the freebsd boot log). But ugen is disabled in RTEMS. Anything in
this direction ?
code link:

On Wed, Jul 13, 2016 5:41 AM, Chris Johns chrisj at rtems.org wrote:
On 12/07/2016 23:32, Alan Cudmore wrote:

> I'm not sure what I did to get the extra debug messages. When I run the

> usb01 example, I just see:

> nexus0: <RTEMS Nexus device>


> I will have to read up on how the libbsd drivers are used, and what

> needs to be done to set them up in nexus-devices.h


I would work backwards from one of the prints you are not seeing.

One way to work out the issue is to directly check the missing prints statements
in the module of code. If you add '--show-commands' to the waf configure command
line the commands used to build the code are printed. If you then change in to
the build directory, cut and paste the command to build the source you are
interested and add '-save-temps' you will get the pre-processed output. Check
the .i file and if there are no print statements you know a define controlling
it is missing. You will then need to track the headers to find it. Once found
add the option to the '--freebsd-options' list.

Note, if you create an error in the source, eg add 'x' anywhere, the build will
stop on the file of interest. This speeds up getting to the command line you are
interested in. Remove the error once you have the command.

> Chris: do you know if it would help to boot FreeBSD on the Pi to see the

> messages and look at what drivers are used?

I tend to try and boot FreeBSD if possible and check the messages and what is
detected match. I am doing this on the Beckhoff PC hardware at the moment.


Deval Shah Graduate Student, B.E. (Hons.) Electrical and Electronics Engineering
BITS Pilani Hyderabad Campus
Github Profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160719/96c04fdd/attachment-0002.html>

More information about the devel mailing list