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 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
--
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
--joel
--
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
