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.ma...@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.ma...@gmail.com > <mailto:deval.ma...@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@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 chr...@rtems.org > <mailto:chr...@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>
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
