Re: sb-set-builder problems
Thanks a lot! It helped 2015-03-15 23:24 GMT+02:00 Chris Johns : > On 15/03/2015 1:35 am, Юрий Шевцов wrote: >> >> It fails and I don't why. > > > Python development libraries are not installed. Please take a look at the > various ways Python development libraries can be installed on Linux .. > https://docs.rtems.org/rsb/#_linux > >> Here is the log >> http://paste.kolibrios.org/show/373/ Seems like the problem is in python >> but I have python 2.6 and it is default version (running cmd 'python' >> invokes exactly 2.6.6 version). Also is it possible to disable all these >> checks, because sb-set-builder runs more than one hour till it fails?? > > > This is actually part of GDB and I want to have Python built into GDB > because The RTEMS Tools Project has GDB Python support for looking at kernel > structures. > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[GSoC] "RPi BSP improvement" idea separation
Is there any final list of items? I have red through this thread https://lists.rtems.org/pipermail/devel/2015-March/010175.html but I didn't found any final list, except Joel's Sherrill suggestion (https://lists.rtems.org/pipermail/devel/2015-March/010184.html). Personally I would like to work on USB-related stuff since I have experience in that field. Thanks in advance! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC] "RPi BSP improvement" idea separation
> On 3/16/2015 2:37 PM, Gedare Bloom wrote: >> On Mon, Mar 16, 2015 at 3:21 PM, Joel Sherrill >> wrote: >>> I don't know if this has been posted or merged into the WIki. >>> Alan, Gedare and I were discussing this earlier today. One thing >>> to remember is that it is always possible something we think >>> is 1/2 a summer is incredibly easy so bonus tasks should be >>> defined for every student. In broad strokes, a possible breakdown >>> could be. >>> >>> + Complete GPIO/I2C/SPI integration and add SD card >>> support (since it uses SPI) >>> >>> + USB and Network stack based on new BSP stack > My understanding is that USB will need to be done first since > the NIC is on the other side of USB. > > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi > > makes it look like both USB and the NIC could come up easy. > And there is the potential to leverage more code. >>> + Raspberry Pi 2 optimization and SMP support >>> Basic support is merged but the cache is clearly >>> not in the right state based on benchmarks and >>> the MMU might need initialization based on an >>> early report from Alan. For sure, all capabilities >>> that work now or begin to work on the Pi1 will >>> need to be checked on Pi 2. >>> >> My intuition is there needs to be extra work added beyond just >> fine-tuning the RPI2. > +1 I just don't know what that is either. :) >>> + User interface stack >>> This could include an HDMI/USB console, and perhaps a >>> port for the RTEMS graphics library. Obviously, you >>> can't use any USB devices for UI unless the USB stack >>> works so the USB effort would bring that up while >>> doing the graphics work. Then move to USB UI devices. >>> >> Avoid proposing any work that overlaps (conflict or dependent) on >> another. No USB UI devices should be proposed. > Yes. The first step of this one could be to get the Graphics Toolkit into > the RSB. > > Then leave USB UI devices as bonus work. BTW, what do you mean by USB UI device? Something like external video card? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC] "RPi BSP improvement" idea separation
These are called USB HID :-) 2015-03-16 22:17 GMT+02:00 Joel Sherrill : > > > On 3/16/2015 2:57 PM, Yurii Shevtsov wrote: >>> On 3/16/2015 2:37 PM, Gedare Bloom wrote: >>>> On Mon, Mar 16, 2015 at 3:21 PM, Joel Sherrill >>>> wrote: >>>>> I don't know if this has been posted or merged into the WIki. >>>>> Alan, Gedare and I were discussing this earlier today. One thing >>>>> to remember is that it is always possible something we think >>>>> is 1/2 a summer is incredibly easy so bonus tasks should be >>>>> defined for every student. In broad strokes, a possible breakdown >>>>> could be. >>>>> >>>>> + Complete GPIO/I2C/SPI integration and add SD card >>>>> support (since it uses SPI) >>>>> >>>>> + USB and Network stack based on new BSP stack >>> My understanding is that USB will need to be done first since >>> the NIC is on the other side of USB. >>> >>> https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi >>> >>> makes it look like both USB and the NIC could come up easy. >>> And there is the potential to leverage more code. >>>>> + Raspberry Pi 2 optimization and SMP support >>>>> Basic support is merged but the cache is clearly >>>>> not in the right state based on benchmarks and >>>>> the MMU might need initialization based on an >>>>> early report from Alan. For sure, all capabilities >>>>> that work now or begin to work on the Pi1 will >>>>> need to be checked on Pi 2. >>>>> >>>> My intuition is there needs to be extra work added beyond just >>>> fine-tuning the RPI2. >>> +1 I just don't know what that is either. :) >>>>> + User interface stack >>>>> This could include an HDMI/USB console, and perhaps a >>>>> port for the RTEMS graphics library. Obviously, you >>>>> can't use any USB devices for UI unless the USB stack >>>>> works so the USB effort would bring that up while >>>>> doing the graphics work. Then move to USB UI devices. >>>>> >>>> Avoid proposing any work that overlaps (conflict or dependent) on >>>> another. No USB UI devices should be proposed. >>> Yes. The first step of this one could be to get the Graphics Toolkit into >>> the RSB. >>> >>> Then leave USB UI devices as bonus work. >> BTW, what do you mean by USB UI device? Something like external video card? > I am primarily thinking keyboard and mouse. User interface devices. > The video should (hopefully) be usable without incorporating pure > GPL code. FreeBSD and Minix should be references there. > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RPi Support GSoC 2015
Patch:
diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index d8fe450..8bf3604 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -28,7 +28,9 @@ rtems_task Init(
)
{
rtems_test_begin();
- printf( "Hello World\n" );
+ printf( "Hello RTEMS\n" );
+ printf( "This is Yurii's Hello world\n" );
+ printf( "Have a nice day\n" );
rtems_test_end();
exit( 0 );
}
Image:
http://habrastorage.org/files/ef9/936/a2c/ef9936a2c3134fd89d4f7cf80ec56bc8.png
Working on hello for RPi
2015-03-13 18:19 GMT+02:00 Gedare Bloom :
> On Fri, Mar 13, 2015 at 12:05 PM, Юрий Шевцов wrote:
>> Am I right that completing Hello is just change and somehow submit lines in
>> samples/hello/init.c ? And how can I submit the proof, of course?)
>>
> Correct. You can send an email here with patch attached and a link to
> a screenshot posted somewhere.
>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RPi Support GSoC 2015
Hi) Right now arm cross-compiler is being compiled. And of course I will test Hello on actual RPi board. I would like to work with USB part of task as I mentioned here https://lists.rtems.org/pipermail/devel/2015-March/010462.html Which part would yo like to take? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
'RPi BSP improvement' students unite!
Since we are working around the same hardware, we definitely should cooperate, share info and ideas. Feel free to ask questions. Inspire each other! Off-topic is allowed here, in small portions, of course ;-) I'm sure we will be a good team! P.S. Roll-call would be a great start for this thread) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Got errors compiling latest version of rtems-libbsd
commit 66ec94a3fc3c41470f90b7d20913ea1fafc019a9 make install prints this http://paste.kolibrios.org/show/394/ I copied _timeval.h (found it somewhere in rtems folder) to rtemsbsd/include/rtems/bsd/sys/. It seemed like it helped but I got new errors http://paste.kolibrios.org/show/395/ Result doesn't depend on architecture. Thanks in advance ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Mailbox methods for RPi
I have this lines in FreeBSD driver: | bcm2835_mbox_set_power_state(dev, BCM2835_MBOX_POWER_ID_USB_HCD, TRUE); How should I replace it? Thanks in advance) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Mailbox methods for RPi
Joel, actually I have no idea. I just thought there is method analogue, or somebody will point me to mailbox API 2015-06-01 22:44 GMT+03:00 Joel Sherrill : > > > On 6/1/2015 2:32 PM, Yurii Shevtsov wrote: >> >> I have this lines in FreeBSD driver: >>| bcm2835_mbox_set_power_state(dev, BCM2835_MBOX_POWER_ID_USB_HCD, >> TRUE); >> How should I replace it? >> > > What does that do? Without knowing the impact of that setting, > it is hard to make a statement. > > >> Thanks in advance) >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-libbsd waf params
Since 'waf' requires four params and 'make' only three in config.inc, I got confused with waf. Could anyone help me with waf params? Here is my config.inc: TARGET = arm-rtems4.11 BSP = c/raspberrypi/make PREFIX = /home/gtament/development/rtems/src/b-rpi Thanks in advance) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-libbsd waf params
2015-06-05 21:02 GMT+03:00 Sujay Raj : > From what I could make out from the documentation in README.waf, > in waf configure , --prefix is where you would like to install rtems-libbsd, > --rtems is where you installed your bsp, that is, the '--prefix' you > passed while configuring the bsp. > '--rtems-tools' points to the tool-set you built using RSB (the > --prefix you passed to the RSB) and > '--rtems-bsps' should be provided with the string 'architecture/bsp'. > > (everything without quotes, quotes are just for illustration) > > usually --prefix and --rtems would have the same value, but it depends > on how you are setting things up. Thanks, I'll try. > Further, from libbsd.txt, in config.inc BSP should only be the name of > your BSP, not c/raspberrypi/make. Can't agree with you here. This path is exactly what is needed for successful build > See if this helps. > Regards > > > > On Fri, Jun 5, 2015 at 10:47 PM, Yurii Shevtsov wrote: >> Since 'waf' requires four params and 'make' only three in config.inc, >> I got confused with waf. Could anyone help me with waf params? Here is >> my config.inc: >> TARGET = arm-rtems4.11 >> BSP = c/raspberrypi/make >> PREFIX = /home/gtament/development/rtems/src/b-rpi >> >> Thanks in advance) >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-libbsd waf params
Here is what I get now: No valid arch/bsps found where --rtems-bsps=arm/raspberrypi also tried archs: armv6, arm-rtems4.11 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-libbsd waf params
Ok, I figured it out, I should use path from rtems configure prefix ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
usb01.exe from rtems-libbsd testsuites gives no output
I compiled it from repo with latest commit 66ec94a3fc3c41470f90b7d20913ea1fafc019a9 Tried to run it on RPi with uboot. Boot approach is OK, because testsuites from rtems samples are running normally. I thought ported driver hangs system, but then I commented out USB init macro and also added some printf to the beginning of Init() proc and still got no output. RPi is connected through Serial. Now I'm trying to setup QEMU, maybe I would get some more info. Also feel free to suggest some other testsuite, which can help me testing ported driver. Thanks in advance) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: usb01.exe from rtems-libbsd testsuites gives no output
This is "Please, pay attention" message. I really need help. Also I still can't start working with the latest libbsd repo because of this https://lists.rtems.org/pipermail/users/2015-June/029005.html Thanks in advance, and excuse me, if my questions seem stupid 2015-06-13 13:56 GMT+03:00 Yurii Shevtsov : > I compiled it from repo with latest commit > 66ec94a3fc3c41470f90b7d20913ea1fafc019a9 > Tried to run it on RPi with uboot. Boot approach is OK, because > testsuites from rtems samples are running normally. I thought ported > driver hangs system, but then I commented out USB init macro and also > added some printf to the beginning of Init() proc and still got no > output. RPi is connected through Serial. Now I'm trying to setup QEMU, > maybe I would get some more info. Also feel free to suggest some other > testsuite, which can help me testing ported driver. > > Thanks in advance) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSoC 2015 RPi USB Support
Hello) Now I have apps from libbsd testsuite running. But DWC OTG driver doesn't loads. I added this lines to init01/test_main.c: +SYSINIT_NEED_USB_CORE; +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus); (I know it's bad hardcode) If I run it. I get only this: nexus0: devctl: +nexus0 at on root0 devctl: !system=IFNET subsystem=lo0 type=ATTACH Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and did other nexus-related changes to drivers. You can find changes in my repo https://github.com/gtament/rtems-libbsd/ So I need some kind of code review, please. P.S. All testsuites (netshell01, usb01) with shell hangs without any output. Thanks in advance! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
This is ping message, with small update: the problem is not on the linking stage, driver is linked to testsuite (checked with objdump) 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov : > Hello) > Now I have apps from libbsd testsuite running. But DWC OTG driver doesn't > loads. > I added this lines to init01/test_main.c: > > +SYSINIT_NEED_USB_CORE; > +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus); > > (I know it's bad hardcode) > > If I run it. I get only this: > nexus0: > devctl: +nexus0 at on root0 > devctl: !system=IFNET subsystem=lo0 type=ATTACH > > Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and > rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and > did other nexus-related changes to drivers. You can find changes in my > repo https://github.com/gtament/rtems-libbsd/ > So I need some kind of code review, please. > P.S. All testsuites (netshell01, usb01) with shell hangs without any output. > > Thanks in advance! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
What kind of debugging info do you mean? What else can I get except serial output? Can I make it verbose? 2015-06-25 16:00 GMT+03:00 Gedare Bloom : > Can you add more debugging info? > > I glanced at your code, some comments, make sure you follow the > recommendations in libbsd.txt about modifying code taken from freebsd. > You also might find it more convenient to work on a branch instead of > a master, and to avoid merge commits. > > Gedare > > On Thu, Jun 25, 2015 at 8:50 AM, Yurii Shevtsov wrote: >> This is ping message, with small update: the problem is not on the >> linking stage, driver is linked to testsuite (checked with objdump) >> >> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov : >>> Hello) >>> Now I have apps from libbsd testsuite running. But DWC OTG driver doesn't >>> loads. >>> I added this lines to init01/test_main.c: >>> >>> +SYSINIT_NEED_USB_CORE; >>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus); >>> >>> (I know it's bad hardcode) >>> >>> If I run it. I get only this: >>> nexus0: >>> devctl: +nexus0 at on root0 >>> devctl: !system=IFNET subsystem=lo0 type=ATTACH >>> >>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and >>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and >>> did other nexus-related changes to drivers. You can find changes in my >>> repo https://github.com/gtament/rtems-libbsd/ >>> So I need some kind of code review, please. >>> P.S. All testsuites (netshell01, usb01) with shell hangs without any output. >>> >>> Thanks in advance! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
How to set a break point? Is there any other way of debugging except
printfs and tracing?
2015-06-25 16:00 GMT+03:00 Sebastian Huber :
> I would set a break point to nexus_probe(). In this loop
>
> SET_FOREACH(nd, nexus) {
> device_add_child(dev, nd->name, nd->unit);
> }
>
> your device must get added. I would also set break points to the probe and
> attach functions of your device.
>
>
> On 25/06/15 14:50, Yurii Shevtsov wrote:
>>
>> This is ping message, with small update: the problem is not on the
>> linking stage, driver is linked to testsuite (checked with objdump)
>>
>> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov :
>>>
>>> Hello)
>>> Now I have apps from libbsd testsuite running. But DWC OTG driver doesn't
>>> loads.
>>> I added this lines to init01/test_main.c:
>>>
>>> +SYSINIT_NEED_USB_CORE;
>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus);
>>>
>>> (I know it's bad hardcode)
>>>
>>> If I run it. I get only this:
>>>nexus0:
>>>devctl: +nexus0 at on root0
>>>devctl: !system=IFNET subsystem=lo0 type=ATTACH
>>>
>>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and
>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and
>>> did other nexus-related changes to drivers. You can find changes in my
>>> repo https://github.com/gtament/rtems-libbsd/
>>> So I need some kind of code review, please.
>>> P.S. All testsuites (netshell01, usb01) with shell hangs without any
>>> output.
>>>
>>> Thanks in advance!
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
2015-06-25 16:00 GMT+03:00 Sebastian Huber :
> I would set a break point to nexus_probe(). In this loop
>
> SET_FOREACH(nd, nexus) {
> device_add_child(dev, nd->name, nd->unit);
> }
>
> your device must get added. I would also set break points to the probe and
> attach functions of your device.
Added printfs()
printf("before setforeach\n");
SET_FOREACH(nd, nexus) {
printf("setforeach: %s\n", nd->name);
device_add_child(dev, nd->name, nd->unit);
}
Got only 'before setforeach' in console. So it doesn't step into loop.
Any ideas? Also I already had printfs in my driver's probe and attach,
also got no output.
> On 25/06/15 14:50, Yurii Shevtsov wrote:
>>
>> This is ping message, with small update: the problem is not on the
>> linking stage, driver is linked to testsuite (checked with objdump)
>>
>> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov :
>>>
>>> Hello)
>>> Now I have apps from libbsd testsuite running. But DWC OTG driver doesn't
>>> loads.
>>> I added this lines to init01/test_main.c:
>>>
>>> +SYSINIT_NEED_USB_CORE;
>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus);
>>>
>>> (I know it's bad hardcode)
>>>
>>> If I run it. I get only this:
>>>nexus0:
>>>devctl: +nexus0 at on root0
>>>devctl: !system=IFNET subsystem=lo0 type=ATTACH
>>>
>>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and
>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and
>>> did other nexus-related changes to drivers. You can find changes in my
>>> repo https://github.com/gtament/rtems-libbsd/
>>> So I need some kind of code review, please.
>>> P.S. All testsuites (netshell01, usb01) with shell hangs without any
>>> output.
>>>
>>> Thanks in advance!
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
Any ideas? Maybe I did some typo? Maybe you can compile and try it in qemu?
2015-06-26 17:05 GMT+03:00 Yurii Shevtsov :
> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
> :
>> I would set a break point to nexus_probe(). In this loop
>>
>> SET_FOREACH(nd, nexus) {
>> device_add_child(dev, nd->name, nd->unit);
>> }
>>
>> your device must get added. I would also set break points to the probe and
>> attach functions of your device.
>
> Added printfs()
>
> printf("before setforeach\n");
>
> SET_FOREACH(nd, nexus) {
> printf("setforeach: %s\n", nd->name);
> device_add_child(dev, nd->name, nd->unit);
> }
>
> Got only 'before setforeach' in console. So it doesn't step into loop.
> Any ideas? Also I already had printfs in my driver's probe and attach,
> also got no output.
>
>> On 25/06/15 14:50, Yurii Shevtsov wrote:
>>>
>>> This is ping message, with small update: the problem is not on the
>>> linking stage, driver is linked to testsuite (checked with objdump)
>>>
>>> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov :
>>>>
>>>> Hello)
>>>> Now I have apps from libbsd testsuite running. But DWC OTG driver doesn't
>>>> loads.
>>>> I added this lines to init01/test_main.c:
>>>>
>>>> +SYSINIT_NEED_USB_CORE;
>>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus);
>>>>
>>>> (I know it's bad hardcode)
>>>>
>>>> If I run it. I get only this:
>>>>nexus0:
>>>>devctl: +nexus0 at on root0
>>>>devctl: !system=IFNET subsystem=lo0 type=ATTACH
>>>>
>>>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and
>>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and
>>>> did other nexus-related changes to drivers. You can find changes in my
>>>> repo https://github.com/gtament/rtems-libbsd/
>>>> So I need some kind of code review, please.
>>>> P.S. All testsuites (netshell01, usb01) with shell hangs without any
>>>> output.
>>>>
>>>> Thanks in advance!
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
So, it is empty.
.rtemsroset.bsd.nexus.begin
0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
0x001104bc_bsd__start_set_nexus
.rtemsroset.bsd.nexus.end
0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
0x001104bc_bsd__stop_set_nexus
What will be next step? My repo:
https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace
2015-06-29 9:43 GMT+03:00 Sebastian Huber :
> You can debug this issue on Qemu. The Nexus childes are registered in a
> linker set, so I would consult the linker map file. It should look like
> this:
>
> .rtemsroset.bsd.nexus.begin
> 0x0052ef7c0x0 libbsd.a(rtems-bsd-nexus.o)
> 0x0052ef7c _bsd__start_set_nexus
> .rtemsroset.bsd.nexus.content
> 0x0052ef7c 0x28
> testsuite/telnetd01/test_main.o
> .rtemsroset.bsd.nexus.end
> 0x0052efa40x0 libbsd.a(rtems-bsd-nexus.o)
> 0x0052efa4 _bsd__stop_set_nexus
>
> The .rtemsroset.bsd.nexus.content section must be non-empty.
>
>
> On 27/06/15 16:39, Yurii Shevtsov wrote:
>>
>> Any ideas? Maybe I did some typo? Maybe you can compile and try it in
>> qemu?
>>
>> 2015-06-26 17:05 GMT+03:00 Yurii Shevtsov :
>>>
>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
>>> :
>>>>
>>>> I would set a break point to nexus_probe(). In this loop
>>>>
>>>> SET_FOREACH(nd, nexus) {
>>>> device_add_child(dev, nd->name, nd->unit);
>>>> }
>>>>
>>>> your device must get added. I would also set break points to the probe
>>>> and
>>>> attach functions of your device.
>>>
>>> Added printfs()
>>>
>>> printf("before setforeach\n");
>>>
>>> SET_FOREACH(nd, nexus) {
>>> printf("setforeach: %s\n", nd->name);
>>> device_add_child(dev, nd->name, nd->unit);
>>> }
>>>
>>> Got only 'before setforeach' in console. So it doesn't step into loop.
>>> Any ideas? Also I already had printfs in my driver's probe and attach,
>>> also got no output.
>>>
>>>> On 25/06/15 14:50, Yurii Shevtsov wrote:
>>>>>
>>>>> This is ping message, with small update: the problem is not on the
>>>>> linking stage, driver is linked to testsuite (checked with objdump)
>>>>>
>>>>> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov :
>>>>>>
>>>>>> Hello)
>>>>>> Now I have apps from libbsd testsuite running. But DWC OTG driver
>>>>>> doesn't
>>>>>> loads.
>>>>>> I added this lines to init01/test_main.c:
>>>>>>
>>>>>> +SYSINIT_NEED_USB_CORE;
>>>>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus);
>>>>>>
>>>>>> (I know it's bad hardcode)
>>>>>>
>>>>>> If I run it. I get only this:
>>>>>> nexus0:
>>>>>> devctl: +nexus0 at on root0
>>>>>> devctl: !system=IFNET subsystem=lo0 type=ATTACH
>>>>>>
>>>>>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and
>>>>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and
>>>>>> did other nexus-related changes to drivers. You can find changes in my
>>>>>> repo https://github.com/gtament/rtems-libbsd/
>>>>>> So I need some kind of code review, please.
>>>>>> P.S. All testsuites (netshell01, usb01) with shell hangs without any
>>>>>> output.
>>>>>>
>>>>>> Thanks in advance!
>>>>>
>>>>> ___
>>>>> devel mailing list
>>>>> devel@rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>>
>>>> --
>>>> Sebastian Huber, embedded brains GmbH
>>>>
>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>>> Phone : +49 89 189 47 41-16
>>>> Fax : +49 89 189 47 41-09
>>>> E-Mail : sebastian.hu...@embedded-brains.de
>>>> PGP : Public key available on request.
>>>>
>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
Any news?
2015-06-29 19:50 GMT+03:00 Yurii Shevtsov :
> So, it is empty.
>
> .rtemsroset.bsd.nexus.begin
> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
> 0x001104bc_bsd__start_set_nexus
> .rtemsroset.bsd.nexus.end
> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
> 0x001104bc_bsd__stop_set_nexus
>
> What will be next step? My repo:
> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace
>
> 2015-06-29 9:43 GMT+03:00 Sebastian Huber
> :
>> You can debug this issue on Qemu. The Nexus childes are registered in a
>> linker set, so I would consult the linker map file. It should look like
>> this:
>>
>> .rtemsroset.bsd.nexus.begin
>> 0x0052ef7c0x0 libbsd.a(rtems-bsd-nexus.o)
>> 0x0052ef7c _bsd__start_set_nexus
>> .rtemsroset.bsd.nexus.content
>> 0x0052ef7c 0x28
>> testsuite/telnetd01/test_main.o
>> .rtemsroset.bsd.nexus.end
>> 0x0052efa40x0 libbsd.a(rtems-bsd-nexus.o)
>> 0x0052efa4 _bsd__stop_set_nexus
>>
>> The .rtemsroset.bsd.nexus.content section must be non-empty.
>>
>>
>> On 27/06/15 16:39, Yurii Shevtsov wrote:
>>>
>>> Any ideas? Maybe I did some typo? Maybe you can compile and try it in
>>> qemu?
>>>
>>> 2015-06-26 17:05 GMT+03:00 Yurii Shevtsov :
>>>>
>>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
>>>> :
>>>>>
>>>>> I would set a break point to nexus_probe(). In this loop
>>>>>
>>>>> SET_FOREACH(nd, nexus) {
>>>>> device_add_child(dev, nd->name, nd->unit);
>>>>> }
>>>>>
>>>>> your device must get added. I would also set break points to the probe
>>>>> and
>>>>> attach functions of your device.
>>>>
>>>> Added printfs()
>>>>
>>>> printf("before setforeach\n");
>>>>
>>>> SET_FOREACH(nd, nexus) {
>>>> printf("setforeach: %s\n", nd->name);
>>>> device_add_child(dev, nd->name, nd->unit);
>>>> }
>>>>
>>>> Got only 'before setforeach' in console. So it doesn't step into loop.
>>>> Any ideas? Also I already had printfs in my driver's probe and attach,
>>>> also got no output.
>>>>
>>>>> On 25/06/15 14:50, Yurii Shevtsov wrote:
>>>>>>
>>>>>> This is ping message, with small update: the problem is not on the
>>>>>> linking stage, driver is linked to testsuite (checked with objdump)
>>>>>>
>>>>>> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov :
>>>>>>>
>>>>>>> Hello)
>>>>>>> Now I have apps from libbsd testsuite running. But DWC OTG driver
>>>>>>> doesn't
>>>>>>> loads.
>>>>>>> I added this lines to init01/test_main.c:
>>>>>>>
>>>>>>> +SYSINIT_NEED_USB_CORE;
>>>>>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus);
>>>>>>>
>>>>>>> (I know it's bad hardcode)
>>>>>>>
>>>>>>> If I run it. I get only this:
>>>>>>> nexus0:
>>>>>>> devctl: +nexus0 at on root0
>>>>>>> devctl: !system=IFNET subsystem=lo0 type=ATTACH
>>>>>>>
>>>>>>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and
>>>>>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and
>>>>>>> did other nexus-related changes to drivers. You can find changes in my
>>>>>>> repo https://github.com/gtament/rtems-libbsd/
>>>>>>> So I need some kind of code review, please.
>>>>>>> P.S. All testsuites (netshell01, usb01) with shell hangs without any
>>>>>>> output.
>>>>>>>
>>>>>>> Thanks in advance!
>>>>>>
>>>>>> ___
>>>>>> devel mailing list
>>>>>> devel@rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Huber, embedded brains GmbH
>>>>>
>>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>>>> Phone : +49 89 189 47 41-16
>>>>> Fax : +49 89 189 47 41-09
>>>>> E-Mail : sebastian.hu...@embedded-brains.de
>>>>> PGP : Public key available on request.
>>>>>
>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>>
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
ping
2015-07-01 17:20 GMT+03:00 Yurii Shevtsov :
> Any news?
>
> 2015-06-29 19:50 GMT+03:00 Yurii Shevtsov :
>> So, it is empty.
>>
>> .rtemsroset.bsd.nexus.begin
>> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
>> 0x001104bc_bsd__start_set_nexus
>> .rtemsroset.bsd.nexus.end
>> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
>> 0x001104bc_bsd__stop_set_nexus
>>
>> What will be next step? My repo:
>> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace
>>
>> 2015-06-29 9:43 GMT+03:00 Sebastian Huber
>> :
>>> You can debug this issue on Qemu. The Nexus childes are registered in a
>>> linker set, so I would consult the linker map file. It should look like
>>> this:
>>>
>>> .rtemsroset.bsd.nexus.begin
>>> 0x0052ef7c0x0 libbsd.a(rtems-bsd-nexus.o)
>>> 0x0052ef7c _bsd__start_set_nexus
>>> .rtemsroset.bsd.nexus.content
>>> 0x0052ef7c 0x28
>>> testsuite/telnetd01/test_main.o
>>> .rtemsroset.bsd.nexus.end
>>> 0x0052efa4 0x0 libbsd.a(rtems-bsd-nexus.o)
>>> 0x0052efa4 _bsd__stop_set_nexus
>>>
>>> The .rtemsroset.bsd.nexus.content section must be non-empty.
>>>
>>>
>>> On 27/06/15 16:39, Yurii Shevtsov wrote:
>>>>
>>>> Any ideas? Maybe I did some typo? Maybe you can compile and try it in
>>>> qemu?
>>>>
>>>> 2015-06-26 17:05 GMT+03:00 Yurii Shevtsov :
>>>>>
>>>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
>>>>> :
>>>>>>
>>>>>> I would set a break point to nexus_probe(). In this loop
>>>>>>
>>>>>> SET_FOREACH(nd, nexus) {
>>>>>> device_add_child(dev, nd->name, nd->unit);
>>>>>> }
>>>>>>
>>>>>> your device must get added. I would also set break points to the probe
>>>>>> and
>>>>>> attach functions of your device.
>>>>>
>>>>> Added printfs()
>>>>>
>>>>> printf("before setforeach\n");
>>>>>
>>>>> SET_FOREACH(nd, nexus) {
>>>>> printf("setforeach: %s\n", nd->name);
>>>>> device_add_child(dev, nd->name, nd->unit);
>>>>> }
>>>>>
>>>>> Got only 'before setforeach' in console. So it doesn't step into loop.
>>>>> Any ideas? Also I already had printfs in my driver's probe and attach,
>>>>> also got no output.
>>>>>
>>>>>> On 25/06/15 14:50, Yurii Shevtsov wrote:
>>>>>>>
>>>>>>> This is ping message, with small update: the problem is not on the
>>>>>>> linking stage, driver is linked to testsuite (checked with objdump)
>>>>>>>
>>>>>>> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov :
>>>>>>>>
>>>>>>>> Hello)
>>>>>>>> Now I have apps from libbsd testsuite running. But DWC OTG driver
>>>>>>>> doesn't
>>>>>>>> loads.
>>>>>>>> I added this lines to init01/test_main.c:
>>>>>>>>
>>>>>>>> +SYSINIT_NEED_USB_CORE;
>>>>>>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus);
>>>>>>>>
>>>>>>>> (I know it's bad hardcode)
>>>>>>>>
>>>>>>>> If I run it. I get only this:
>>>>>>>> nexus0:
>>>>>>>> devctl: +nexus0 at on root0
>>>>>>>> devctl: !system=IFNET subsystem=lo0 type=ATTACH
>>>>>>>>
>>>>>>>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and
>>>>>>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and
>>>>>>>> did other nexus-related changes to drivers. You can find changes in my
>>>>>>>> repo https://github.com/gtament/rtems-libbsd/
>>>>>>>> So I need some kind of code review, please.
>>>>>>>> P.S. All testsuites (netshell01, usb01) with shell hangs without any
>>>>>>>> output.
>>>>>>>>
>>>>>>>> Thanks in advance!
>>>>>>>
>>>>>>> ___
>>>>>>> devel mailing list
>>>>>>> devel@rtems.org
>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Huber, embedded brains GmbH
>>>>>>
>>>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>>>>> Phone : +49 89 189 47 41-16
>>>>>> Fax : +49 89 189 47 41-09
>>>>>> E-Mail : sebastian.hu...@embedded-brains.de
>>>>>> PGP : Public key available on request.
>>>>>>
>>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>>>
>>>
>>> --
>>> Sebastian Huber, embedded brains GmbH
>>>
>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>> Phone : +49 89 189 47 41-16
>>> Fax : +49 89 189 47 41-09
>>> E-Mail : sebastian.hu...@embedded-brains.de
>>> PGP : Public key available on request.
>>>
>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
No I haven't. I tried to write driver stub, but I got same issueson RPi. What are the qemu args? Can I run qemu in terminal? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
And what to debug, if problem is on linkage stage? Or I misunderstood something? 2015-07-08 22:32 GMT+03:00 Yurii Shevtsov : > No I haven't. I tried to write driver stub, but I got same issueson > RPi. What are the qemu args? Can I run qemu in terminal? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
Ok, now the mechanism become clear. But still, why do I have troubles with linker set?? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
Which qemu build are you using? And what qemu args for xilinx zynq? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
Where is the linker script which is responsible for
.rtemsroset.bsd.nexus.content section? And how debuging the code will
help me with empty section??
2015-06-29 9:43 GMT+03:00 Sebastian Huber :
> You can debug this issue on Qemu. The Nexus childes are registered in a
> linker set, so I would consult the linker map file. It should look like
> this:
>
> .rtemsroset.bsd.nexus.begin
> 0x0052ef7c0x0 libbsd.a(rtems-bsd-nexus.o)
> 0x0052ef7c _bsd__start_set_nexus
> .rtemsroset.bsd.nexus.content
> 0x0052ef7c 0x28
> testsuite/telnetd01/test_main.o
> .rtemsroset.bsd.nexus.end
> 0x0052efa40x0 libbsd.a(rtems-bsd-nexus.o)
> 0x0052efa4 _bsd__stop_set_nexus
>
> The .rtemsroset.bsd.nexus.content section must be non-empty.
>
>
> On 27/06/15 16:39, Yurii Shevtsov wrote:
>>
>> Any ideas? Maybe I did some typo? Maybe you can compile and try it in
>> qemu?
>>
>> 2015-06-26 17:05 GMT+03:00 Yurii Shevtsov :
>>>
>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
>>> :
>>>>
>>>> I would set a break point to nexus_probe(). In this loop
>>>>
>>>> SET_FOREACH(nd, nexus) {
>>>> device_add_child(dev, nd->name, nd->unit);
>>>> }
>>>>
>>>> your device must get added. I would also set break points to the probe
>>>> and
>>>> attach functions of your device.
>>>
>>> Added printfs()
>>>
>>> printf("before setforeach\n");
>>>
>>> SET_FOREACH(nd, nexus) {
>>> printf("setforeach: %s\n", nd->name);
>>> device_add_child(dev, nd->name, nd->unit);
>>> }
>>>
>>> Got only 'before setforeach' in console. So it doesn't step into loop.
>>> Any ideas? Also I already had printfs in my driver's probe and attach,
>>> also got no output.
>>>
>>>> On 25/06/15 14:50, Yurii Shevtsov wrote:
>>>>>
>>>>> This is ping message, with small update: the problem is not on the
>>>>> linking stage, driver is linked to testsuite (checked with objdump)
>>>>>
>>>>> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov :
>>>>>>
>>>>>> Hello)
>>>>>> Now I have apps from libbsd testsuite running. But DWC OTG driver
>>>>>> doesn't
>>>>>> loads.
>>>>>> I added this lines to init01/test_main.c:
>>>>>>
>>>>>> +SYSINIT_NEED_USB_CORE;
>>>>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus);
>>>>>>
>>>>>> (I know it's bad hardcode)
>>>>>>
>>>>>> If I run it. I get only this:
>>>>>> nexus0:
>>>>>> devctl: +nexus0 at on root0
>>>>>> devctl: !system=IFNET subsystem=lo0 type=ATTACH
>>>>>>
>>>>>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and
>>>>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and
>>>>>> did other nexus-related changes to drivers. You can find changes in my
>>>>>> repo https://github.com/gtament/rtems-libbsd/
>>>>>> So I need some kind of code review, please.
>>>>>> P.S. All testsuites (netshell01, usb01) with shell hangs without any
>>>>>> output.
>>>>>>
>>>>>> Thanks in advance!
>>>>>
>>>>> ___
>>>>> devel mailing list
>>>>> devel@rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>>
>>>> --
>>>> Sebastian Huber, embedded brains GmbH
>>>>
>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>>> Phone : +49 89 189 47 41-16
>>>> Fax : +49 89 189 47 41-09
>>>> E-Mail : sebastian.hu...@embedded-brains.de
>>>> PGP : Public key available on request.
>>>>
>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
During debugging of compiled Nexus module(driver) I found out that
content which suppose to be created in RTEMS_BSD_DEFINE_SET(nexus,
rtems_bsd_device) is empty, That should mean that either it is not
found or cannot be read. Please, let me know why empty content is not
create any error message and in what situation it can be empty.
2015-06-29 19:50 GMT+03:00 Yurii Shevtsov :
> So, it is empty.
>
> .rtemsroset.bsd.nexus.begin
> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
> 0x001104bc_bsd__start_set_nexus
> .rtemsroset.bsd.nexus.end
> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
> 0x001104bc_bsd__stop_set_nexus
>
> What will be next step? My repo:
> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace
>
> 2015-06-29 9:43 GMT+03:00 Sebastian Huber
> :
>> You can debug this issue on Qemu. The Nexus childes are registered in a
>> linker set, so I would consult the linker map file. It should look like
>> this:
>>
>> .rtemsroset.bsd.nexus.begin
>> 0x0052ef7c0x0 libbsd.a(rtems-bsd-nexus.o)
>> 0x0052ef7c _bsd__start_set_nexus
>> .rtemsroset.bsd.nexus.content
>> 0x0052ef7c 0x28
>> testsuite/telnetd01/test_main.o
>> .rtemsroset.bsd.nexus.end
>> 0x0052efa40x0 libbsd.a(rtems-bsd-nexus.o)
>> 0x0052efa4 _bsd__stop_set_nexus
>>
>> The .rtemsroset.bsd.nexus.content section must be non-empty.
>>
>>
>> On 27/06/15 16:39, Yurii Shevtsov wrote:
>>>
>>> Any ideas? Maybe I did some typo? Maybe you can compile and try it in
>>> qemu?
>>>
>>> 2015-06-26 17:05 GMT+03:00 Yurii Shevtsov :
>>>>
>>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
>>>> :
>>>>>
>>>>> I would set a break point to nexus_probe(). In this loop
>>>>>
>>>>> SET_FOREACH(nd, nexus) {
>>>>> device_add_child(dev, nd->name, nd->unit);
>>>>> }
>>>>>
>>>>> your device must get added. I would also set break points to the probe
>>>>> and
>>>>> attach functions of your device.
>>>>
>>>> Added printfs()
>>>>
>>>> printf("before setforeach\n");
>>>>
>>>> SET_FOREACH(nd, nexus) {
>>>> printf("setforeach: %s\n", nd->name);
>>>> device_add_child(dev, nd->name, nd->unit);
>>>> }
>>>>
>>>> Got only 'before setforeach' in console. So it doesn't step into loop.
>>>> Any ideas? Also I already had printfs in my driver's probe and attach,
>>>> also got no output.
>>>>
>>>>> On 25/06/15 14:50, Yurii Shevtsov wrote:
>>>>>>
>>>>>> This is ping message, with small update: the problem is not on the
>>>>>> linking stage, driver is linked to testsuite (checked with objdump)
>>>>>>
>>>>>> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov :
>>>>>>>
>>>>>>> Hello)
>>>>>>> Now I have apps from libbsd testsuite running. But DWC OTG driver
>>>>>>> doesn't
>>>>>>> loads.
>>>>>>> I added this lines to init01/test_main.c:
>>>>>>>
>>>>>>> +SYSINIT_NEED_USB_CORE;
>>>>>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus);
>>>>>>>
>>>>>>> (I know it's bad hardcode)
>>>>>>>
>>>>>>> If I run it. I get only this:
>>>>>>> nexus0:
>>>>>>> devctl: +nexus0 at on root0
>>>>>>> devctl: !system=IFNET subsystem=lo0 type=ATTACH
>>>>>>>
>>>>>>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and
>>>>>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and
>>>>>>> did other nexus-related changes to drivers. You can find changes in my
>>>>>>> repo https://github.com/gtament/rtems-libbsd/
>>>>>>> So I need some kind of code review, please.
>>>>>>> P.S. All testsuites (netshell01, usb01) with shell hangs without any
>>>>>>> output.
>>>>>>>
>>>>>>> Thanks in advance!
>>>>>>
>>>>>> ___
>>>>>> devel mailing list
>>>>>> devel@rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Huber, embedded brains GmbH
>>>>>
>>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>>>> Phone : +49 89 189 47 41-16
>>>>> Fax : +49 89 189 47 41-09
>>>>> E-Mail : sebastian.hu...@embedded-brains.de
>>>>> PGP : Public key available on request.
>>>>>
>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>>
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
The problem is that rtemsroset.bsd.nexus.content doesn't exist in
final elf. If I change driver's name in RTEMS_BSD_DEFINE_NEXUS_DEVICE
macro, linker will throw an error
(.rtemsroset.bsd.nexus.content+0x10): undefined reference to '%wrong
driver's name%'. Otherwise with correct name - no errors(warnings) and
no nexus.content section. How can you explain this??
2015-08-02 18:02 GMT+03:00 Joel Sherrill :
> On 08/01/2015 04:00 PM, Yurii Shevtsov wrote:
>>
>> During debugging of compiled Nexus module(driver) I found out that
>> content which suppose to be created in RTEMS_BSD_DEFINE_SET(nexus,
>> rtems_bsd_device) is empty, That should mean that either it is not
>> found or cannot be read. Please, let me know why empty content is not
>> create any error message and in what situation it can be empty.
>>
> Sebastian just added the pc386 to the nexus-devices file. Make sure
> the bsp.h is tripping the conditional logic in that file to get the Pi
> path as a minimum.
>
> Then you are going to need to add the appropriate devices for Pi
> USB. If the Pi doesn't have one of the standard USB controllers, then
> you will have to import the source for it from FreeBSD.
>
> The pc386 is stuck at the point where it detects the NIC configured
> but needs resources. I am going to try to debug that.
>
>> 2015-06-29 19:50 GMT+03:00 Yurii Shevtsov:
>>>
>>> So, it is empty.
>>>
>>> .rtemsroset.bsd.nexus.begin
>>> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
>>> 0x001104bc_bsd__start_set_nexus
>>> .rtemsroset.bsd.nexus.end
>>> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
>>> 0x001104bc_bsd__stop_set_nexus
>>>
>>> What will be next step? My repo:
>>>
>>> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace
>>>
>>> 2015-06-29 9:43 GMT+03:00 Sebastian
>>> Huber:
>>>>
>>>> You can debug this issue on Qemu. The Nexus childes are registered in a
>>>> linker set, so I would consult the linker map file. It should look like
>>>> this:
>>>>
>>>> .rtemsroset.bsd.nexus.begin
>>>> 0x0052ef7c0x0
>>>> libbsd.a(rtems-bsd-nexus.o)
>>>> 0x0052ef7c _bsd__start_set_nexus
>>>> .rtemsroset.bsd.nexus.content
>>>> 0x0052ef7c 0x28
>>>> testsuite/telnetd01/test_main.o
>>>> .rtemsroset.bsd.nexus.end
>>>> 0x0052efa40x0
>>>> libbsd.a(rtems-bsd-nexus.o)
>>>> 0x0052efa4 _bsd__stop_set_nexus
>>>>
>>>> The .rtemsroset.bsd.nexus.content section must be non-empty.
>>>>
>>>>
>>>> On 27/06/15 16:39, Yurii Shevtsov wrote:
>>>>>
>>>>> Any ideas? Maybe I did some typo? Maybe you can compile and try it in
>>>>> qemu?
>>>>>
>>>>> 2015-06-26 17:05 GMT+03:00 Yurii Shevtsov:
>>>>>>
>>>>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
>>>>>> :
>>>>>>>
>>>>>>> I would set a break point to nexus_probe(). In this loop
>>>>>>>
>>>>>>> SET_FOREACH(nd, nexus) {
>>>>>>> device_add_child(dev, nd->name, nd->unit);
>>>>>>> }
>>>>>>>
>>>>>>> your device must get added. I would also set break points to the
>>>>>>> probe
>>>>>>> and
>>>>>>> attach functions of your device.
>>>>>>
>>>>>> Added printfs()
>>>>>>
>>>>>> printf("before setforeach\n");
>>>>>>
>>>>>> SET_FOREACH(nd, nexus) {
>>>>>> printf("setforeach: %s\n", nd->name);
>>>>>> device_add_child(dev, nd->name, nd->unit);
>>>>>> }
>>>>>>
>>>>>> Got only 'before setforeach' in console. So it doesn't step into loop.
>>>>>> Any ideas? Also I already had printfs in my driver's probe and attach,
>>>>>> also got no output.
>>>>>>
>>>>>>> On 25/06/15 14:50, Yurii Shevtsov wrote:
>&g
Re: GSoC 2015 RPi USB Support
Ping! Any news?
2015-08-05 18:29 GMT+03:00 Yurii Shevtsov :
> The problem is that rtemsroset.bsd.nexus.content doesn't exist in
> final elf. If I change driver's name in RTEMS_BSD_DEFINE_NEXUS_DEVICE
> macro, linker will throw an error
> (.rtemsroset.bsd.nexus.content+0x10): undefined reference to '%wrong
> driver's name%'. Otherwise with correct name - no errors(warnings) and
> no nexus.content section. How can you explain this??
>
> 2015-08-02 18:02 GMT+03:00 Joel Sherrill :
>> On 08/01/2015 04:00 PM, Yurii Shevtsov wrote:
>>>
>>> During debugging of compiled Nexus module(driver) I found out that
>>> content which suppose to be created in RTEMS_BSD_DEFINE_SET(nexus,
>>> rtems_bsd_device) is empty, That should mean that either it is not
>>> found or cannot be read. Please, let me know why empty content is not
>>> create any error message and in what situation it can be empty.
>>>
>> Sebastian just added the pc386 to the nexus-devices file. Make sure
>> the bsp.h is tripping the conditional logic in that file to get the Pi
>> path as a minimum.
>>
>> Then you are going to need to add the appropriate devices for Pi
>> USB. If the Pi doesn't have one of the standard USB controllers, then
>> you will have to import the source for it from FreeBSD.
>>
>> The pc386 is stuck at the point where it detects the NIC configured
>> but needs resources. I am going to try to debug that.
>>
>>> 2015-06-29 19:50 GMT+03:00 Yurii Shevtsov:
>>>>
>>>> So, it is empty.
>>>>
>>>> .rtemsroset.bsd.nexus.begin
>>>> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
>>>> 0x001104bc_bsd__start_set_nexus
>>>> .rtemsroset.bsd.nexus.end
>>>> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
>>>> 0x001104bc_bsd__stop_set_nexus
>>>>
>>>> What will be next step? My repo:
>>>>
>>>> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace
>>>>
>>>> 2015-06-29 9:43 GMT+03:00 Sebastian
>>>> Huber:
>>>>>
>>>>> You can debug this issue on Qemu. The Nexus childes are registered in a
>>>>> linker set, so I would consult the linker map file. It should look like
>>>>> this:
>>>>>
>>>>> .rtemsroset.bsd.nexus.begin
>>>>> 0x0052ef7c0x0
>>>>> libbsd.a(rtems-bsd-nexus.o)
>>>>> 0x0052ef7c _bsd__start_set_nexus
>>>>> .rtemsroset.bsd.nexus.content
>>>>> 0x0052ef7c 0x28
>>>>> testsuite/telnetd01/test_main.o
>>>>> .rtemsroset.bsd.nexus.end
>>>>> 0x0052efa40x0
>>>>> libbsd.a(rtems-bsd-nexus.o)
>>>>> 0x0052efa4 _bsd__stop_set_nexus
>>>>>
>>>>> The .rtemsroset.bsd.nexus.content section must be non-empty.
>>>>>
>>>>>
>>>>> On 27/06/15 16:39, Yurii Shevtsov wrote:
>>>>>>
>>>>>> Any ideas? Maybe I did some typo? Maybe you can compile and try it in
>>>>>> qemu?
>>>>>>
>>>>>> 2015-06-26 17:05 GMT+03:00 Yurii Shevtsov:
>>>>>>>
>>>>>>> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
>>>>>>> :
>>>>>>>>
>>>>>>>> I would set a break point to nexus_probe(). In this loop
>>>>>>>>
>>>>>>>> SET_FOREACH(nd, nexus) {
>>>>>>>> device_add_child(dev, nd->name, nd->unit);
>>>>>>>> }
>>>>>>>>
>>>>>>>> your device must get added. I would also set break points to the
>>>>>>>> probe
>>>>>>>> and
>>>>>>>> attach functions of your device.
>>>>>>>
>>>>>>> Added printfs()
>>>>>>>
>>>>>>> printf("before setforeach\n");
>>>>>>>
>>>>>>> SET_FOREACH(nd, nexus) {
>>>>>>> printf("setforeach: %s\n", nd->name);
>>>>>>> device_add_child(dev, nd->name
Re: GSoC 2015 RPi USB Support
2015-08-06 23:36 GMT+03:00 Joel Sherrill : > > > On 8/6/2015 3:22 PM, Yurii Shevtsov wrote: >> >> Ping! Any news? > > > The people with experience with the libbsd code is quite small. :( > >> >> 2015-08-05 18:29 GMT+03:00 Yurii Shevtsov : >>> >>> The problem is that rtemsroset.bsd.nexus.content doesn't exist in >>> final elf. If I change driver's name in RTEMS_BSD_DEFINE_NEXUS_DEVICE >>> macro, linker will throw an error >>> (.rtemsroset.bsd.nexus.content+0x10): undefined reference to '%wrong >>> driver's name%'. Otherwise with correct name - no errors(warnings) and >>> no nexus.content section. How can you explain this?? > > > The RTEMS_BSD_DEFINE_NEXUS_DEVICE() macro must reference a bus/mexus, > not a regular device driver. I would expect a nexus device for the Pi > to be in > https://github.com/freebsd/freebsd/tree/master/sys/arm/broadcom/bcm2835 > or pointed to by a file in there. > > Look at the configuration for the various bsps in nexus-devices.h and > then at the source the macros refer to. > > Raspberry Pi source will have to be imported from the FreeBSD tree. Of course, I did it!) https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace >>> 2015-08-02 18:02 GMT+03:00 Joel Sherrill : >>>> >>>> On 08/01/2015 04:00 PM, Yurii Shevtsov wrote: >>>>> >>>>> >>>>> During debugging of compiled Nexus module(driver) I found out that >>>>> content which suppose to be created in RTEMS_BSD_DEFINE_SET(nexus, >>>>> rtems_bsd_device) is empty, That should mean that either it is not >>>>> found or cannot be read. Please, let me know why empty content is not >>>>> create any error message and in what situation it can be empty. >>>>> >>>> Sebastian just added the pc386 to the nexus-devices file. Make sure >>>> the bsp.h is tripping the conditional logic in that file to get the Pi >>>> path as a minimum. >>>> >>>> Then you are going to need to add the appropriate devices for Pi >>>> USB. If the Pi doesn't have one of the standard USB controllers, then >>>> you will have to import the source for it from FreeBSD. >>>> >>>> The pc386 is stuck at the point where it detects the NIC configured >>>> but needs resources. I am going to try to debug that. >>>> >>>>> 2015-06-29 19:50 GMT+03:00 Yurii Shevtsov: >>>>>> >>>>>> >>>>>> So, it is empty. >>>>>> >>>>>>.rtemsroset.bsd.nexus.begin >>>>>> 0x001104bc0x0 >>>>>> ./libbsd.a(rtems-bsd-nexus.c.16.o) >>>>>> 0x001104bc_bsd__start_set_nexus >>>>>>.rtemsroset.bsd.nexus.end >>>>>> 0x001104bc0x0 >>>>>> ./libbsd.a(rtems-bsd-nexus.c.16.o) >>>>>> 0x001104bc_bsd__stop_set_nexus >>>>>> >>>>>> What will be next step? My repo: >>>>>> >>>>>> >>>>>> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace >>>>>> >>>>>> 2015-06-29 9:43 GMT+03:00 Sebastian >>>>>> Huber: >>>>>>> >>>>>>> >>>>>>> You can debug this issue on Qemu. The Nexus childes are registered in >>>>>>> a >>>>>>> linker set, so I would consult the linker map file. It should look >>>>>>> like >>>>>>> this: >>>>>>> >>>>>>>.rtemsroset.bsd.nexus.begin >>>>>>> 0x0052ef7c0x0 >>>>>>> libbsd.a(rtems-bsd-nexus.o) >>>>>>> 0x0052ef7c _bsd__start_set_nexus >>>>>>>.rtemsroset.bsd.nexus.content >>>>>>> 0x0052ef7c 0x28 >>>>>>> testsuite/telnetd01/test_main.o >>>>>>>.rtemsroset.bsd.nexus.end >>>>>>> 0x0052efa40x0 >>>>>>> libbsd.a(rtems-bsd-nexus.o) >>>>>>> 0x0052efa4 _bsd__stop_set_nexus >>>>>>> >>>>>>> The .rtemsroset.bsd.nexus.co
Re: GSoC 2015 RPi USB Support
What do you mean by "getting pulled"? 2015-08-06 23:48 GMT+03:00 Joel Sherrill : > > > On 8/6/2015 3:42 PM, Yurii Shevtsov wrote: >> >> 2015-08-06 23:36 GMT+03:00 Joel Sherrill : >>> >>> >>> >>> On 8/6/2015 3:22 PM, Yurii Shevtsov wrote: >>>> >>>> >>>> Ping! Any news? >>> >>> >>> >>> The people with experience with the libbsd code is quite small. :( >>> >>>> >>>> 2015-08-05 18:29 GMT+03:00 Yurii Shevtsov : >>>>> >>>>> >>>>> The problem is that rtemsroset.bsd.nexus.content doesn't exist in >>>>> final elf. If I change driver's name in RTEMS_BSD_DEFINE_NEXUS_DEVICE >>>>> macro, linker will throw an error >>>>> (.rtemsroset.bsd.nexus.content+0x10): undefined reference to '%wrong >>>>> driver's name%'. Otherwise with correct name - no errors(warnings) and >>>>> no nexus.content section. How can you explain this?? >>> >>> >>> >>> The RTEMS_BSD_DEFINE_NEXUS_DEVICE() macro must reference a bus/mexus, >>> not a regular device driver. I would expect a nexus device for the Pi >>> to be in >>> https://github.com/freebsd/freebsd/tree/master/sys/arm/broadcom/bcm2835 >>> or pointed to by a file in there. >>> >>> Look at the configuration for the various bsps in nexus-devices.h and >>> then at the source the macros refer to. >>> >>> Raspberry Pi source will have to be imported from the FreeBSD tree. >> >> >> Of course, I did it!) >> >> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace > > > Is bcm283x_dwcotg* getting pulled into your build? > > >>>>> 2015-08-02 18:02 GMT+03:00 Joel Sherrill : >>>>>> >>>>>> >>>>>> On 08/01/2015 04:00 PM, Yurii Shevtsov wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> During debugging of compiled Nexus module(driver) I found out that >>>>>>> content which suppose to be created in RTEMS_BSD_DEFINE_SET(nexus, >>>>>>> rtems_bsd_device) is empty, That should mean that either it is not >>>>>>> found or cannot be read. Please, let me know why empty content is not >>>>>>> create any error message and in what situation it can be empty. >>>>>>> >>>>>> Sebastian just added the pc386 to the nexus-devices file. Make sure >>>>>> the bsp.h is tripping the conditional logic in that file to get the Pi >>>>>> path as a minimum. >>>>>> >>>>>> Then you are going to need to add the appropriate devices for Pi >>>>>> USB. If the Pi doesn't have one of the standard USB controllers, >>>>>> then >>>>>> you will have to import the source for it from FreeBSD. >>>>>> >>>>>> The pc386 is stuck at the point where it detects the NIC configured >>>>>> but needs resources. I am going to try to debug that. >>>>>> >>>>>>> 2015-06-29 19:50 GMT+03:00 Yurii Shevtsov: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> So, it is empty. >>>>>>>> >>>>>>>> .rtemsroset.bsd.nexus.begin >>>>>>>>0x001104bc0x0 >>>>>>>> ./libbsd.a(rtems-bsd-nexus.c.16.o) >>>>>>>>0x001104bc_bsd__start_set_nexus >>>>>>>> .rtemsroset.bsd.nexus.end >>>>>>>>0x001104bc0x0 >>>>>>>> ./libbsd.a(rtems-bsd-nexus.c.16.o) >>>>>>>>0x001104bc_bsd__stop_set_nexus >>>>>>>> >>>>>>>> What will be next step? My repo: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace >>>>>>>> >>>>>>>> 2015-06-29 9:43 GMT+03:00 Sebastian >>>>>>>> Huber: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>&g
Re: GSoC 2015 RPi USB Support
2015-08-07 0:08 GMT+03:00 Joel Sherrill : > > > On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov wrote: >>What do you mean by "getting pulled"? > > > As I understood things, you had a linked executable but an empty section. > Just curious if your devices were showing up at all. Yes, exactly. If you mean is probe function being executed, the answer is ''no" >>2015-08-06 23:48 GMT+03:00 Joel Sherrill : >>> >>> >>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote: >>>> >>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill >>: >>>>> >>>>> >>>>> >>>>> On 8/6/2015 3:22 PM, Yurii Shevtsov wrote: >>>>>> >>>>>> >>>>>> Ping! Any news? >>>>> >>>>> >>>>> >>>>> The people with experience with the libbsd code is quite small. :( >>>>> >>>>>> >>>>>> 2015-08-05 18:29 GMT+03:00 Yurii Shevtsov : >>>>>>> >>>>>>> >>>>>>> The problem is that rtemsroset.bsd.nexus.content doesn't exist in >>>>>>> final elf. If I change driver's name in >>RTEMS_BSD_DEFINE_NEXUS_DEVICE >>>>>>> macro, linker will throw an error >>>>>>> (.rtemsroset.bsd.nexus.content+0x10): undefined reference to >>'%wrong >>>>>>> driver's name%'. Otherwise with correct name - no >>errors(warnings) and >>>>>>> no nexus.content section. How can you explain this?? >>>>> >>>>> >>>>> >>>>> The RTEMS_BSD_DEFINE_NEXUS_DEVICE() macro must reference a >>bus/mexus, >>>>> not a regular device driver. I would expect a nexus device for the >>Pi >>>>> to be in >>>>> >>https://github.com/freebsd/freebsd/tree/master/sys/arm/broadcom/bcm2835 >>>>> or pointed to by a file in there. >>>>> >>>>> Look at the configuration for the various bsps in nexus-devices.h >>and >>>>> then at the source the macros refer to. >>>>> >>>>> Raspberry Pi source will have to be imported from the FreeBSD tree. >>>> >>>> >>>> Of course, I did it!) >>>> >>>> >>https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace >>> >>> >>> Is bcm283x_dwcotg* getting pulled into your build? >>> >>> >>>>>>> 2015-08-02 18:02 GMT+03:00 Joel Sherrill >>: >>>>>>>> >>>>>>>> >>>>>>>> On 08/01/2015 04:00 PM, Yurii Shevtsov wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> During debugging of compiled Nexus module(driver) I found out >>that >>>>>>>>> content which suppose to be created in >>RTEMS_BSD_DEFINE_SET(nexus, >>>>>>>>> rtems_bsd_device) is empty, That should mean that either it is >>not >>>>>>>>> found or cannot be read. Please, let me know why empty content >>is not >>>>>>>>> create any error message and in what situation it can be empty. >>>>>>>>> >>>>>>>> Sebastian just added the pc386 to the nexus-devices file. Make >>sure >>>>>>>> the bsp.h is tripping the conditional logic in that file to get >>the Pi >>>>>>>> path as a minimum. >>>>>>>> >>>>>>>> Then you are going to need to add the appropriate devices for Pi >>>>>>>> USB. If the Pi doesn't have one of the standard USB >>controllers, >>>>>>>> then >>>>>>>> you will have to import the source for it from FreeBSD. >>>>>>>> >>>>>>>> The pc386 is stuck at the point where it detects the NIC >>configured >>>>>>>> but needs resources. I am going to try to debug that. >>>>>>>> >>>>>>>>> 2015-06-29 19:50 GMT+03:00 Yurii Shevtsov: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So, it is empty. >>>>>>>>>> >>>>>>>>>>
Re: GSoC 2015 RPi USB Support
Isn't this line enough? SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) 2015-08-07 0:23 GMT+03:00 Joel Sherrill : > > > On 8/6/2015 4:16 PM, Yurii Shevtsov wrote: >> >> 2015-08-07 0:08 GMT+03:00 Joel Sherrill : >>> >>> >>> >>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov >>> wrote: >>>> >>>> What do you mean by "getting pulled"? >>> >>> >>> >>> As I understood things, you had a linked executable but an empty section. >>> Just curious if your devices were showing up at all. >> >> >> Yes, exactly. If you mean is probe function being executed, the answer is >> ''no" > > > You have to associate the drivers with a nexus bus. Something like this > > SYSINIT_DRIVER_REFERENCE(mmc, dw_mmc); > SYSINIT_DRIVER_REFERENCE(mmcsd, mmc); > > That's from the Altera Cyclone. > > You only configured a nexus device and didn't hang anything off it. > > >>>> 2015-08-06 23:48 GMT+03:00 Joel Sherrill : >>>>> >>>>> >>>>> >>>>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote: >>>>>> >>>>>> >>>>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill >>>> >>>> : >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 8/6/2015 3:22 PM, Yurii Shevtsov wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ping! Any news? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The people with experience with the libbsd code is quite small. :( >>>>>>> >>>>>>>> >>>>>>>> 2015-08-05 18:29 GMT+03:00 Yurii Shevtsov : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The problem is that rtemsroset.bsd.nexus.content doesn't exist in >>>>>>>>> final elf. If I change driver's name in >>>> >>>> RTEMS_BSD_DEFINE_NEXUS_DEVICE >>>>>>>>> >>>>>>>>> macro, linker will throw an error >>>>>>>>> (.rtemsroset.bsd.nexus.content+0x10): undefined reference to >>>> >>>> '%wrong >>>>>>>>> >>>>>>>>> driver's name%'. Otherwise with correct name - no >>>> >>>> errors(warnings) and >>>>>>>>> >>>>>>>>> no nexus.content section. How can you explain this?? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The RTEMS_BSD_DEFINE_NEXUS_DEVICE() macro must reference a >>>> >>>> bus/mexus, >>>>>>> >>>>>>> not a regular device driver. I would expect a nexus device for the >>>> >>>> Pi >>>>>>> >>>>>>> to be in >>>>>>> >>>> https://github.com/freebsd/freebsd/tree/master/sys/arm/broadcom/bcm2835 >>>>>>> >>>>>>> or pointed to by a file in there. >>>>>>> >>>>>>> Look at the configuration for the various bsps in nexus-devices.h >>>> >>>> and >>>>>>> >>>>>>> then at the source the macros refer to. >>>>>>> >>>>>>> Raspberry Pi source will have to be imported from the FreeBSD tree. >>>>>> >>>>>> >>>>>> >>>>>> Of course, I did it!) >>>>>> >>>>>> >>>> >>>> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace >>>>> >>>>> >>>>> >>>>> Is bcm283x_dwcotg* getting pulled into your build? >>>>> >>>>> >>>>>>>>> 2015-08-02 18:02 GMT+03:00 Joel Sherrill >>>> >>>> : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/01/2015 04:00 PM, Yurii Shevtsov wrote: >>>>>>>>>>> >>>>>>>>>&
Re: GSoC 2015 RPi USB Support
These macroses are placed here https://github.com/gtament/rtems-libbsd/blob/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace/rtemsbsd/include/machine/rtems-bsd-sysinit.h And of course I added proper lines to specific testsuites, like init01. And IRC, without this macro driver just won't be linked 2015-08-07 0:34 GMT+03:00 Joel Sherrill : > > > On 8/6/2015 4:29 PM, Yurii Shevtsov wrote: >> >> Isn't this line enough? >> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) > > > I was looking in nexus-devices.h since that is BSP specific. > I wasn't expecting a generic macro. > > But where is that referenced? That is a macro that somewhere > should be referencing so it is expanded. > > I would expect to see > > SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) > > below the nexus definition in nexus-devices.h. > > Anyway, it is never being expanded so that definition has no impact. > > Whether it will work and find the right bus, is another issue > but it isn't putting code in for sure. :) > > I have the pc386 to the point where it the RTEMS nexus device > is trying to find em on the legacy bus but it is configured > as being on pci. Need to run down that or trick it to work. > But the probe is working. > > --joel > > > >> 2015-08-07 0:23 GMT+03:00 Joel Sherrill : >>> >>> >>> >>> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote: >>>> >>>> >>>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill : >>>>> >>>>> >>>>> >>>>> >>>>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov >>>>> wrote: >>>>>> >>>>>> >>>>>> What do you mean by "getting pulled"? >>>>> >>>>> >>>>> >>>>> >>>>> As I understood things, you had a linked executable but an empty >>>>> section. >>>>> Just curious if your devices were showing up at all. >>>> >>>> >>>> >>>> Yes, exactly. If you mean is probe function being executed, the answer >>>> is >>>> ''no" >>> >>> >>> >>> You have to associate the drivers with a nexus bus. Something like this >>> >>> SYSINIT_DRIVER_REFERENCE(mmc, dw_mmc); >>> SYSINIT_DRIVER_REFERENCE(mmcsd, mmc); >>> >>> That's from the Altera Cyclone. >>> >>> You only configured a nexus device and didn't hang anything off it. >>> >>> >>>>>> 2015-08-06 23:48 GMT+03:00 Joel Sherrill : >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill >>>>>> >>>>>> >>>>>> : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 8/6/2015 3:22 PM, Yurii Shevtsov wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ping! Any news? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The people with experience with the libbsd code is quite small. :( >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-08-05 18:29 GMT+03:00 Yurii Shevtsov : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The problem is that rtemsroset.bsd.nexus.content doesn't exist in >>>>>>>>>>> final elf. If I change driver's name in >>>>>> >>>>>> >>>>>> RTEMS_BSD_DEFINE_NEXUS_DEVICE >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> macro, linker will throw an error >>>>>>>>>>> (.rtemsroset.bsd.nexus.content+
Re: GSoC 2015 RPi USB Support
Ping! Any news? 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov : > These macroses are placed here > https://github.com/gtament/rtems-libbsd/blob/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace/rtemsbsd/include/machine/rtems-bsd-sysinit.h > And of course I added proper lines to specific testsuites, like > init01. And IRC, without this macro driver just won't be linked > > 2015-08-07 0:34 GMT+03:00 Joel Sherrill : >> >> >> On 8/6/2015 4:29 PM, Yurii Shevtsov wrote: >>> >>> Isn't this line enough? >>> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) >> >> >> I was looking in nexus-devices.h since that is BSP specific. >> I wasn't expecting a generic macro. >> >> But where is that referenced? That is a macro that somewhere >> should be referencing so it is expanded. >> >> I would expect to see >> >> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) >> >> below the nexus definition in nexus-devices.h. >> >> Anyway, it is never being expanded so that definition has no impact. >> >> Whether it will work and find the right bus, is another issue >> but it isn't putting code in for sure. :) >> >> I have the pc386 to the point where it the RTEMS nexus device >> is trying to find em on the legacy bus but it is configured >> as being on pci. Need to run down that or trick it to work. >> But the probe is working. >> >> --joel >> >> >> >>> 2015-08-07 0:23 GMT+03:00 Joel Sherrill : >>>> >>>> >>>> >>>> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote: >>>>> >>>>> >>>>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill : >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> What do you mean by "getting pulled"? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> As I understood things, you had a linked executable but an empty >>>>>> section. >>>>>> Just curious if your devices were showing up at all. >>>>> >>>>> >>>>> >>>>> Yes, exactly. If you mean is probe function being executed, the answer >>>>> is >>>>> ''no" >>>> >>>> >>>> >>>> You have to associate the drivers with a nexus bus. Something like this >>>> >>>> SYSINIT_DRIVER_REFERENCE(mmc, dw_mmc); >>>> SYSINIT_DRIVER_REFERENCE(mmcsd, mmc); >>>> >>>> That's from the Altera Cyclone. >>>> >>>> You only configured a nexus device and didn't hang anything off it. >>>> >>>> >>>>>>> 2015-08-06 23:48 GMT+03:00 Joel Sherrill : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill >>>>>>> >>>>>>> >>>>>>> : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 8/6/2015 3:22 PM, Yurii Shevtsov wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ping! Any news? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The people with experience with the libbsd code is quite small. :( >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-08-05 18:29 GMT+03:00 Yurii Shevtsov : >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>&g
Re: GSoC 2015 RPi USB Support
Ping! Any news? 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov : > These macroses are placed here > https://github.com/gtament/rtems-libbsd/blob/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace/rtemsbsd/include/machine/rtems-bsd-sysinit.h > And of course I added proper lines to specific testsuites, like > init01. And IRC, without this macro driver just won't be linked > > 2015-08-07 0:34 GMT+03:00 Joel Sherrill : >> >> >> On 8/6/2015 4:29 PM, Yurii Shevtsov wrote: >>> >>> Isn't this line enough? >>> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) >> >> >> I was looking in nexus-devices.h since that is BSP specific. >> I wasn't expecting a generic macro. >> >> But where is that referenced? That is a macro that somewhere >> should be referencing so it is expanded. >> >> I would expect to see >> >> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) >> >> below the nexus definition in nexus-devices.h. >> >> Anyway, it is never being expanded so that definition has no impact. >> >> Whether it will work and find the right bus, is another issue >> but it isn't putting code in for sure. :) >> >> I have the pc386 to the point where it the RTEMS nexus device >> is trying to find em on the legacy bus but it is configured >> as being on pci. Need to run down that or trick it to work. >> But the probe is working. >> >> --joel >> >> >> >>> 2015-08-07 0:23 GMT+03:00 Joel Sherrill : >>>> >>>> >>>> >>>> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote: >>>>> >>>>> >>>>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill : >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> What do you mean by "getting pulled"? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> As I understood things, you had a linked executable but an empty >>>>>> section. >>>>>> Just curious if your devices were showing up at all. >>>>> >>>>> >>>>> >>>>> Yes, exactly. If you mean is probe function being executed, the answer >>>>> is >>>>> ''no" >>>> >>>> >>>> >>>> You have to associate the drivers with a nexus bus. Something like this >>>> >>>> SYSINIT_DRIVER_REFERENCE(mmc, dw_mmc); >>>> SYSINIT_DRIVER_REFERENCE(mmcsd, mmc); >>>> >>>> That's from the Altera Cyclone. >>>> >>>> You only configured a nexus device and didn't hang anything off it. >>>> >>>> >>>>>>> 2015-08-06 23:48 GMT+03:00 Joel Sherrill : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill >>>>>>> >>>>>>> >>>>>>> : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 8/6/2015 3:22 PM, Yurii Shevtsov wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ping! Any news? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The people with experience with the libbsd code is quite small. :( >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-08-05 18:29 GMT+03:00 Yurii Shevtsov : >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>&g
Re: GSoC 2015 RPi USB Support
I finally found the solution. All I need is to add #include to a testsuite source Now I have a rtemsroset.bsd.nexus.content section 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov : > These macroses are placed here > https://github.com/gtament/rtems-libbsd/blob/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace/rtemsbsd/include/machine/rtems-bsd-sysinit.h > And of course I added proper lines to specific testsuites, like > init01. And IRC, without this macro driver just won't be linked > > 2015-08-07 0:34 GMT+03:00 Joel Sherrill : >> >> >> On 8/6/2015 4:29 PM, Yurii Shevtsov wrote: >>> >>> Isn't this line enough? >>> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) >> >> >> I was looking in nexus-devices.h since that is BSP specific. >> I wasn't expecting a generic macro. >> >> But where is that referenced? That is a macro that somewhere >> should be referencing so it is expanded. >> >> I would expect to see >> >> SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus) >> >> below the nexus definition in nexus-devices.h. >> >> Anyway, it is never being expanded so that definition has no impact. >> >> Whether it will work and find the right bus, is another issue >> but it isn't putting code in for sure. :) >> >> I have the pc386 to the point where it the RTEMS nexus device >> is trying to find em on the legacy bus but it is configured >> as being on pci. Need to run down that or trick it to work. >> But the probe is working. >> >> --joel >> >> >> >>> 2015-08-07 0:23 GMT+03:00 Joel Sherrill : >>>> >>>> >>>> >>>> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote: >>>>> >>>>> >>>>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill : >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> What do you mean by "getting pulled"? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> As I understood things, you had a linked executable but an empty >>>>>> section. >>>>>> Just curious if your devices were showing up at all. >>>>> >>>>> >>>>> >>>>> Yes, exactly. If you mean is probe function being executed, the answer >>>>> is >>>>> ''no" >>>> >>>> >>>> >>>> You have to associate the drivers with a nexus bus. Something like this >>>> >>>> SYSINIT_DRIVER_REFERENCE(mmc, dw_mmc); >>>> SYSINIT_DRIVER_REFERENCE(mmcsd, mmc); >>>> >>>> That's from the Altera Cyclone. >>>> >>>> You only configured a nexus device and didn't hang anything off it. >>>> >>>> >>>>>>> 2015-08-06 23:48 GMT+03:00 Joel Sherrill : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill >>>>>>> >>>>>>> >>>>>>> : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 8/6/2015 3:22 PM, Yurii Shevtsov wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ping! Any news? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The people with experience with the libbsd code is quite small. :( >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-08-05 18:29 GMT+03:00 Yurii Shevtsov : >>>>>>>>>>>> >>>>
Re: libbsd - USB Host Stack for HID, WirelessLAN
Hi) For porting guide check this blogpost http://ragustechblog.blogspot.in/2015/06/porting-driver-from-freebsd-to-rtems.html Also read libbsd's README, especially "Rules for Modifying FreeBSD Source" Can't say anything specific about USB HID and WLAN. Definitely WLAN will require porting libraries with auth protocols (WPA\WEP). About HID, you can try searching how input works in RTEMS. Maybe you can implement API in your future HID driver ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd - USB Host Stack for HID, WirelessLAN
2015-08-25 12:10 GMT+03:00 Thomas Kim : > Dear Yurii, > > Thank you very much. > > I want to review freeBSD source code. > > Please let me know where is libbsd's README file. there is not README file > in current tree (https://git.rtems.org/rtems-libbsd/tree/). > I want to check "Rules for Modiying FreeBSD source" in REAME file. > https://github.com/RTEMS/rtems-libbsd/blob/master/libbsd.txt > > Also, I want to compare FreeBSD original code and the modified FreeBSD > code. > I guess that FreeBSD original code version is 8.x. > it's actually 9.2 (from the readme) > > Please let me know how to get FreeBSD original code version which was used > for libbsd porting work. > https://svnweb.freebsd.org/base/release/9.2.0/ It's Subversion https://www.freebsd.org/doc/handbook/svn.html > > Best Regards, > Thomas. > > 2015-08-21 23:57 GMT+09:00 Yurii Shevtsov : > >> Hi) >> >> For porting guide check this blogpost >> >> http://ragustechblog.blogspot.in/2015/06/porting-driver-from-freebsd-to-rtems.html >> Also read libbsd's README, especially "Rules for Modifying FreeBSD Source" >> >> Can't say anything specific about USB HID and WLAN. Definitely WLAN will >> require porting libraries with auth protocols (WPA\WEP). About HID, you can >> try searching how input works in RTEMS. Maybe you can implement API in your >> future HID driver >> >> >> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] [libbsd] Pulled and ported DWC OTG driver for RPi from FreeBSD. Modified USB sources during porting. Added driver to build by waf and make
Ping ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd - USB Host Stack for HID, WirelessLAN
2015-08-26 9:55 GMT+03:00 Thomas Kim : > Dear Yurii, > > Thank you for your kindly reply. > > At this time, I built lastest libbsd successfully. > Also, I am tring to add USB input files in freebsd\sys\dev\usb\input. > > Question 1) > As I guess, I think that I should modify Makefile, wscript file. also, I > should modify USB input files(atp.c, uep.c, uhid.c, uknd.c, ums.c, etc) > according to "Rules for Modifing FreeBSD source". > Is it correct ? > I'm not sure about which sources exactly are for USB input. But yes, you should modify Makefile or wscript file, to build new sources and later use these binaries. I suggest you to use waf, it's much more convenient. > > Question 2) > As I test freebsd-to-rtems.py, it just move the ported FreeBSD code only > from FreeBSD 9.2 original code to libbsd Freebsd. that is, > freebsd-to-rtems.py is not used for changing additional new files from > FreeBSD 9.2 original code automatically. > Is it correct ? > > Question 3) > As I check libbsd.py file, there is below definitions. > - def dev_usb_input(mm): > - def dev_usb_mouse(mm): > > Is there how to use libbsd.py for adding new files(source, header files) > easily ? > Or, I want to know that libbsd.py file is used for which purpose. > You don't need any of *.py to do, what you want > Best Regards, > Thomas > > 2015-08-25 19:19 GMT+09:00 Yurii Shevtsov : > >> >> >> 2015-08-25 12:10 GMT+03:00 Thomas Kim : >> >>> Dear Yurii, >>> >>> Thank you very much. >>> >>> I want to review freeBSD source code. >>> >>> Please let me know where is libbsd's README file. there is not README >>> file in current tree (https://git.rtems.org/rtems-libbsd/tree/). >>> I want to check "Rules for Modiying FreeBSD source" in REAME file. >>> >> https://github.com/RTEMS/rtems-libbsd/blob/master/libbsd.txt >> >>> >>> Also, I want to compare FreeBSD original code and the modified FreeBSD >>> code. >>> I guess that FreeBSD original code version is 8.x. >>> >> it's actually 9.2 (from the readme) >> >>> >>> Please let me know how to get FreeBSD original code version which was >>> used for libbsd porting work. >>> >> https://svnweb.freebsd.org/base/release/9.2.0/ It's Subversion >> https://www.freebsd.org/doc/handbook/svn.html >> >>> >>> Best Regards, >>> Thomas. >>> >>> 2015-08-21 23:57 GMT+09:00 Yurii Shevtsov : >>> >>>> Hi) >>>> >>>> For porting guide check this blogpost >>>> >>>> http://ragustechblog.blogspot.in/2015/06/porting-driver-from-freebsd-to-rtems.html >>>> Also read libbsd's README, especially "Rules for Modifying FreeBSD >>>> Source" >>>> >>>> Can't say anything specific about USB HID and WLAN. Definitely WLAN >>>> will require porting libraries with auth protocols (WPA\WEP). About HID, >>>> you can try searching how input works in RTEMS. Maybe you can implement API >>>> in your future HID driver >>>> >>>> >>>> >>> >> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
