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

Alan Cudmore alan.cudmore at gmail.com
Fri Jul 22 00:03:34 UTC 2016


Hi Deval,
That is great news!
Is this in your bsdlib github repository?
I would like to try it out soon.
Thanks,
Alan

> On Jul 21, 2016, at 12:57 PM, Deval Shah <deval.maker at gmail.com> wrote:
> 
> Hello all, 
> 
> Good news ! The usb_ethernet controller is working.
> 
> Dr. Joel pointed out to check if I am actually getting the interrupt. So I checked there and found out that there was no entry for USB interrupt. As soon as I added that entry, everything started working.
> 
> Now I am getting the Power in the USB devices when I plug them in also the Ethernet address. I am adding the init test log below.
> 
> -------------------------------------------------------------------------------------------
> *** LIBBSD INIT 1 TEST ***
> nexus0: <RTEMS Nexus device>
> bcm283x_dwcotg0: <DWC OTG 2.0 integrated USB controller (bcm283x)> on nexus0
> usbus0 on bcm283x_dwcotg0
> usbus0: 480Mbps High Speed USB v2.0
> uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
> Sleeping to see what happens
> uhub0: 1 port with 1 removable, self powered
> uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr 2> on usbus0
> uhub1: MTT enabled
> uhub1: 5 ports with 4 removable, self powered
> 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: 5a:ee:60:74:67:92
> Stack usage by thread
>     ID NAME LOW HIGH CURRENT AVAILABLE USED
> 0x09010001 IDLE 0x133148 - 0x134147 0x1340e0 4080 128
> 0x0a010001 UI1 0x134360 - 0x13c35f 0x13bf88 32752 1008
> 0x0a010002 TIME 0x13cab0 - 0x144aaf 0x1449f0 32752 332
> 0x0a010003 IRQS 0x144ab8 - 0x14cab7 0x14c9f8 32752 408
> 0x0a010004 _BSD 0x15f3f8 - 0x1673f7 0x167330 32752 352
> 0x0a010005 _BSD 0x167550 - 0x16f54f 0x16f488 32752 240
> 0x0a010006 _BSD 0x172bb0 - 0x17abaf 0x17aaf0 32752 232
> 0x0a010007 _BSD 0x17ad50 - 0x182d4f 0x182c88 32752 240
> 0x0a010008 _BSD 0x182e10 - 0x18ae0f 0x18ad50 32752 232
> 0x0a010009 _BSD 0x18afb0 - 0x192faf 0x192ee8 32752 240
> 0x0a01000a _BSD 0x1941d0 - 0x19c1cf 0x19c110 32752 232
> 0x0a01000b _BSD 0x19c238 - 0x1a4237 0x1a4178 32752 368
> 0x0a01000c _BSD 0x1a42a0 - 0x1ac29f 0x1ac1e0 32752 232
> 0x0a01000d _BSD 0x1ac308 - 0x1b4307 0x1b4248 32752 1420
> 0x0a01000e _BSD 0x1b4370 - 0x1bc36f 0x1bc2b0 32752 472
> 0x0a01000f _BSD 0x1dddd0 - 0x1e5dcf 0x1e5d10 32752 952
> *** END OF TEST LIBBSD INIT 1 ***
> -------------------------------------------------------------------------------------------
> 
> I am still not getting the device name attached in the USB port. So I will look into that now.
> 
> I am not starting a new thread for now. (as per the chat in IRC, I told that I will create another thread to describe the problem.) I will if I get stuck again.
> 
> Thank you for the help.
> 
> Deval Shah
> 
> 
> 
> 
> 
> On Tue, Jul 19, 2016 1:18 PM, Deval Shah deval.maker at gmail.com <mailto:deval.maker at gmail.com> wrote:
> 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: https://github.com/deval-maker/rtems-libbsd/commit/91f4c1ef04267c6186e38e23e571e7806016480c <https://github.com/deval-maker/rtems-libbsd/commit/91f4c1ef04267c6186e38e23e571e7806016480c>.
> 
> 
> 
> 
> 
> On Wed, Jul 13, 2016 5:41 AM, Chris Johns chrisj at rtems.org <mailto: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.
> 
> 
> 
> Chris
> 
> 
> 
> 
> 
> Deval Shah
> Graduate Student,
> B.E. (Hons.) Electrical and Electronics Engineering
> BITS Pilani Hyderabad Campus <http://www.bits-pilani.ac.in/hyderabad/>
> Github Profile <https://github.com/deval-maker>
> 
> Deval Shah
> Graduate Student,
> B.E. (Hons.) Electrical and Electronics Engineering
> BITS Pilani Hyderabad Campus <http://www.bits-pilani.ac.in/hyderabad/>
> Github Profile <https://github.com/deval-maker>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160721/1459c3a3/attachment-0002.html>


More information about the devel mailing list