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

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

Reply via email to