Re: libbsd - USB Host Stack for HID, WirelessLAN
2015-08-26 9:55 GMT+03:00 Thomas Kim thomas73@gmail.com: 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 unge...@gmail.com: 2015-08-25 12:10 GMT+03:00 Thomas Kim thomas73@gmail.com: 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 unge...@gmail.com: 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-25 12:10 GMT+03:00 Thomas Kim thomas73@gmail.com: 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 unge...@gmail.com: 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
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: GSoC 2015 RPi USB Support
What do you mean by getting pulled?
2015-08-06 23:48 GMT+03:00 Joel Sherrill joel.sherr...@oarcorp.com:
On 8/6/2015 3:42 PM, Yurii Shevtsov wrote:
2015-08-06 23:36 GMT+03:00 Joel Sherrill joel.sherr...@oarcorp.com:
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 unge...@gmail.com:
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 joel.sherr...@oarcorp.com:
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 Shevtsovunge...@gmail.com:
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
Hubersebastian.hu...@embedded-brains.de:
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 Shevtsovunge...@gmail.com:
2015-06-25 16:00 GMT+03:00 Sebastian Huber
sebastian.hu...@embedded-brains.de:
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 Shevtsovunge...@gmail.com:
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
Re: GSoC 2015 RPi USB Support
2015-08-07 0:08 GMT+03:00 Joel Sherrill joel.sherr...@oarcorp.com:
On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov unge...@gmail.com 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 joel.sherr...@oarcorp.com:
On 8/6/2015 3:42 PM, Yurii Shevtsov wrote:
2015-08-06 23:36 GMT+03:00 Joel Sherrill
joel.sherr...@oarcorp.com:
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 unge...@gmail.com:
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
joel.sherr...@oarcorp.com:
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 Shevtsovunge...@gmail.com:
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
Hubersebastian.hu...@embedded-brains.de:
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
Shevtsovunge...@gmail.com:
2015-06-25 16:00 GMT+03:00 Sebastian Huber
sebastian.hu...@embedded-brains.de:
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
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 joel.sherr...@oarcorp.com: 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 joel.sherr...@oarcorp.com: On 8/6/2015 4:16 PM, Yurii Shevtsov wrote: 2015-08-07 0:08 GMT+03:00 Joel Sherrill joel.sherr...@oarcorp.com: On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov unge...@gmail.com 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 joel.sherr...@oarcorp.com: On 8/6/2015 3:42 PM, Yurii Shevtsov wrote: 2015-08-06 23:36 GMT+03:00 Joel Sherrill joel.sherr...@oarcorp.com: 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 unge...@gmail.com: 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 joel.sherr...@oarcorp.com: 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 Shevtsovunge...@gmail.com: 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
Re: GSoC 2015 RPi USB Support
Ping! Any news?
2015-08-05 18:29 GMT+03:00 Yurii Shevtsov unge...@gmail.com:
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 joel.sherr...@oarcorp.com:
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 Shevtsovunge...@gmail.com:
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
Hubersebastian.hu...@embedded-brains.de:
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 Shevtsovunge...@gmail.com:
2015-06-25 16:00 GMT+03:00 Sebastian Huber
sebastian.hu...@embedded-brains.de:
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 Shevtsovunge...@gmail.com:
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:RTEMS Nexus device
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
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 joel.sherr...@oarcorp.com:
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 Shevtsovunge...@gmail.com:
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
Hubersebastian.hu...@embedded-brains.de:
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 Shevtsovunge...@gmail.com:
2015-06-25 16:00 GMT+03:00 Sebastian Huber
sebastian.hu...@embedded-brains.de:
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 Shevtsovunge...@gmail.com:
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:RTEMS Nexus device
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
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 unge...@gmail.com:
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
sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
2015-06-25 16:00 GMT+03:00 Sebastian Huber
sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
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: RTEMS Nexus device
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
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 sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
2015-06-25 16:00 GMT+03:00 Sebastian Huber
sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
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: RTEMS Nexus device
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
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
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
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 unge...@gmail.com: 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
ping
2015-07-01 17:20 GMT+03:00 Yurii Shevtsov unge...@gmail.com:
Any news?
2015-06-29 19:50 GMT+03:00 Yurii Shevtsov unge...@gmail.com:
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
sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
2015-06-25 16:00 GMT+03:00 Sebastian Huber
sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
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: RTEMS Nexus device
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 unge...@gmail.com:
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
sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
2015-06-25 16:00 GMT+03:00 Sebastian Huber
sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
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: RTEMS Nexus device
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
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 sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
2015-06-25 16:00 GMT+03:00 Sebastian Huber
sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
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: RTEMS Nexus device
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 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 unge...@gmail.com:
2015-06-25 16:00 GMT+03:00 Sebastian Huber
sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
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: RTEMS Nexus device
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
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 sebastian.hu...@embedded-brains.de:
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 unge...@gmail.com:
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: RTEMS Nexus device
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
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 unge...@gmail.com: 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: RTEMS Nexus device 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 ged...@gwu.edu: 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 unge...@gmail.com 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 unge...@gmail.com: 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: RTEMS Nexus device 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
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: RTEMS Nexus device 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: 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 unge...@gmail.com: 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: 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
Re: rtems-libbsd waf params
2015-06-05 21:02 GMT+03:00 Sujay Raj sujayr...@gmail.com: 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 unge...@gmail.com 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
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
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
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 joel.sherr...@oarcorp.com: 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
'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
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
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 ged...@gwu.edu:
On Fri, Mar 13, 2015 at 12:05 PM, Юрий Шевцов unge...@gmail.com 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: [GSoC] RPi BSP improvement idea separation
These are called USB HID :-) 2015-03-16 22:17 GMT+02:00 Joel Sherrill joel.sherr...@oarcorp.com: 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 joel.sherr...@oarcorp.com 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
[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 joel.sherr...@oarcorp.com 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: sb-set-builder problems
Thanks a lot! It helped 2015-03-15 23:24 GMT+02:00 Chris Johns chr...@rtems.org: 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
