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.
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 Shevtsov<unge...@gmail.com>:
So, it is empty.
.rtemsroset.bsd.nexus.begin
0x001104bc 0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
0x001104bc _bsd__start_set_nexus
.rtemsroset.bsd.nexus.end
0x001104bc 0x0 ./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
0x000000000052ef7c 0x0
libbsd.a(rtems-bsd-nexus.o)
0x000000000052ef7c _bsd__start_set_nexus
.rtemsroset.bsd.nexus.content
0x000000000052ef7c 0x28
testsuite/telnetd01/test_main.o
.rtemsroset.bsd.nexus.end
0x000000000052efa4 0x0
libbsd.a(rtems-bsd-nexus.o)
0x000000000052efa4 _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
--
-- Joel Sherrill
Ask me about RTEMS: a free RTOS
Support and Training Available
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-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
