Re: GSoC 2015 RPi USB Support
There isn't much action here on Fridays or Weekends normally. Have you gotten around to writing up your blog post describing the various steps you have tried? It's a little hard to help you to debug without understanding the full scope of what you have been trying to do. Gedare On Sun, Aug 9, 2015 at 12:36 PM, Yurii Shevtsov unge...@gmail.com wrote: Ping! Any news? 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov unge...@gmail.com: 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
Re: GSoC 2015 RPi USB Support
The one other thing I will say, to repeat myself, is that I'd like you to clean-up your code on github so that you have clean commit history without any merge commits. Gedare On Sun, Aug 9, 2015 at 7:09 PM, Gedare Bloom ged...@gwu.edu wrote: There isn't much action here on Fridays or Weekends normally. Have you gotten around to writing up your blog post describing the various steps you have tried? It's a little hard to help you to debug without understanding the full scope of what you have been trying to do. Gedare On Sun, Aug 9, 2015 at 12:36 PM, Yurii Shevtsov unge...@gmail.com wrote: Ping! Any news? 2015-08-07 0:41 GMT+03:00 Yurii Shevtsov unge...@gmail.com: 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
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
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.
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
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
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 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
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
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.
--
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
--
-- Joel Sherrill
Ask me about RTEMS: a free RTOS
Support and Training Available
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
On 16/07/15 20:39, Yurii Shevtsov wrote: Which qemu build are you using? And what qemu args for xilinx zynq? See README file in the BSP directory. -- 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
On 9/07/2015 5:38 am, Sebastian Huber wrote: You have to figure out how the linker set mechanism works in general. The following is a simplified view of the 'linker set' mechanism. The idea is similar to C++ static constructors and destructors without compiler and linker support automatically managing the process. The end result of the 'linker set' process is to create a section of the executable memory that is an array of values, usually pointers, to the data being managed. The run-time code knows how to find this section of memory and how to process the data it contains. The feature uses specially name ELF sections. The reason 'linker sets' exist and the need for the complexity can be seen by considering a simple example. Lets say you have a statically linked ELF application called 'app' that consists of a single ELF object file called 'a.o' linked to 'fb.o' (for FreeBSD). You can link this executable and have no unresolved external symbols. When you run this executable and it looks for specific resources there are none because you did not link any. You now build module 'm.o' and driver 'd.o' and add these to the linker command line. Again the executable links without error and this time when you run it you can find the resources present in 'm.o' and 'd.o'. How can an executable that originally linked without any unresolved externals make calls and see resources in the module and driver code by just linking them ? There cannot be any static calls to the module or driver code or we would have seen the unresolved externals, yet some how those object files have automatically bound themselves to the system at run-time and their resources have become available. The 'linker sets' do this. By linking the module and driver object files the specific data they have gets included in the specific linker 'set' and so the generic code in the 'fb.o' object file can see it and make the needed calls to the module and driver code so the resources contained in them become available. This architecture is really neat and has been implemented nicely in FreeBSD. It means FreeBSD can bind new sub-systems and drivers into the kernel without having to have complex and hard to maintain conditionals in the code based on magic compile time defines. All they do is compile the needed parts and link what is needed. A different hardware architecture is a different set of object files. Chris ___ 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
- Yurii Shevtsov unge...@gmail.com schrieb: 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? You have to figure out how the linker set mechanism works in general. -- 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.huber at 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 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
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
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
Ask what other folks using the RPi are doing.
On Thu, Jun 25, 2015 at 9:24 AM, Yurii Shevtsov unge...@gmail.com wrote:
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
___
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
Re: GSoC 2015 RPi USB Support
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
On 25-06-2015 14:33, Gedare Bloom wrote:
Ask what other folks using the RPi are doing.
I do not know if anyone using the Pi with RTEMS currently has a debugger
working. Last year Alan posted in his blog [1] a configuration using a
FT2232H mini module and OpenOCD that connects to the Pi through JTAG,
however although we get a JTAG connection, any code that is sent to the
Pi fails to be tranferred. I have checked his wiring, and pinpointed one
of the possible reasons for the fail to be in the JTAG setup program
(the JTAG interface has to be configured on GPIO, but also pull
resistors have to be disabled, as well as possibly some other details
that are vaguely referred on the Internet). Another point of possible
failure may be in the configurations used with OpenOCD (which are
adapted from another ftdi device), or that something is missing in the
JTAG wiring. I checked this again before GSOC started, but without much
progress.
[1] -
http://alanstechnotes.blogspot.pt/2014/05/a-low-cost-jtag-debugger-for-raspberry.html
On Thu, Jun 25, 2015 at 9:24 AM, Yurii Shevtsov unge...@gmail.com wrote:
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
___
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 2015 RPi USB Support
On 25/06/2015 11:22 pm, Sebastian Huber wrote: On 25/06/15 15:21, Yurii Shevtsov wrote: What kind of debugging info do you mean? What else can I get except serial output? Can I make it verbose? I would use a debugger and not serial output. This is not easy on a RPi. The JTAG signals are not available on a single connector such as the standard ARM 20pin one. The RPi assumes you have a working Linux kernel and you play in user land. The best idea I can come up with for a RPi is a boot type piece of code that uses the OTG USB port as a slave USB serial device with the GDB protocol. There was a GitHub project with something but I never looked any further. Alan do you remember the link ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
