I finally found the solution. All I need is to add
#include to a testsuite source
Now I have a rtemsroset.bsd.nexus.content section
2015-08-07 0:41 GMT+03:00 Yurii Shevtsov :
> These macroses are placed here
> https://github.com/gtament/rtems-libbsd/blob/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace/r
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 wrote:
> There isn't much action here on Fridays or Weekends normally. Have
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, 201
Ping! Any news?
2015-08-07 0:41 GMT+03:00 Yurii Shevtsov :
> 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
> init0
Ping! Any news?
2015-08-07 0:41 GMT+03:00 Yurii Shevtsov :
> 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
> init0
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-
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 referenci
Isn't this line enough?
SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus)
2015-08-07 0:23 GMT+03:00 Joel Sherrill :
>
>
> On 8/6/2015 4:16 PM, Yurii Shevtsov wrote:
>>
>> 2015-08-07 0:08 GMT+03:00 Joel Sherrill :
>>>
>>>
>>>
>>> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov
>>> wrote:
On 8/6/2015 4:16 PM, Yurii Shevtsov wrote:
2015-08-07 0:08 GMT+03:00 Joel Sherrill :
On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov 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
2015-08-07 0:08 GMT+03:00 Joel Sherrill :
>
>
> On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov 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
On August 6, 2015 3:57:40 PM CDT, Yurii Shevtsov 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 :
>>
>>
>> On 8/6/2015 3:42
What do you mean by "getting pulled"?
2015-08-06 23:48 GMT+03:00 Joel Sherrill :
>
>
> On 8/6/2015 3:42 PM, Yurii Shevtsov wrote:
>>
>> 2015-08-06 23:36 GMT+03:00 Joel Sherrill :
>>>
>>>
>>>
>>> On 8/6/2015 3:22 PM, Yurii Shevtsov wrote:
Ping! Any news?
>>>
>>>
>>>
>>> The people wi
On 8/6/2015 3:42 PM, Yurii Shevtsov wrote:
2015-08-06 23:36 GMT+03:00 Joel Sherrill :
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 :
The problem is that rtemsr
2015-08-06 23:36 GMT+03:00 Joel Sherrill :
>
>
> 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 :
>>>
>>> The problem is that rtemsroset.bsd.nexus.content doe
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 :
The problem is that rtemsroset.bsd.nexus.content doesn't exist in
final elf. If I change driver's name in RTEMS_BSD_DEF
Ping! Any news?
2015-08-05 18:29 GMT+03:00 Yurii Shevtsov :
> 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
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(war
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 e
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
On 31/07/15 15:17, Yurii Shevtsov wrote:
Where is the linker script which is responsible for
.rtemsroset.bsd.nexus.content section?
This is linkcmds.base, search for rtemsroset.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189
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 :
> You can debug this issue on Qemu. The Nexus childes are registered in a
> linker set, so I would cons
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 4
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
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
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 automatic
- Yurii Shevtsov 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
And what to debug, if problem is on linkage stage? Or I misunderstood something?
2015-07-08 22:32 GMT+03:00 Yurii Shevtsov :
> 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?
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
Did you build the tests of libbsd for the xilinx_zynq_a9_qemu? Did you run and
debug the telnetd01 test in Qemu to see how the device tree initialization
works?
- Yurii Shevtsov schrieb:
> ping
>
> 2015-07-01 17:20 GMT+03:00 Yurii Shevtsov :
> > Any news?
> >
> > 2015-06-29 19:50 GMT+03:0
ping
2015-07-01 17:20 GMT+03:00 Yurii Shevtsov :
> Any news?
>
> 2015-06-29 19:50 GMT+03:00 Yurii Shevtsov :
>> So, it is empty.
>>
>> .rtemsroset.bsd.nexus.begin
>> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
>> 0x001104bc_bsd__start_s
Any news?
2015-06-29 19:50 GMT+03:00 Yurii Shevtsov :
> 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
> 0x00
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)
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__
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 :
> 2015-06-25 16:00 GMT+03:00 Sebastian Huber
> :
>> I would set a break point to nexus_probe(). In this loop
>>
>> SET_FOREACH(nd, nexus) {
>> device_add_child(dev,
2015-06-25 16:00 GMT+03:00 Sebastian Huber :
> 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
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 signal
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 throug
Ask what other folks using the RPi are doing.
On Thu, Jun 25, 2015 at 9:24 AM, Yurii Shevtsov 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
> :
>> I would set a break point to nexus_probe(). In
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 :
> 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 d
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.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone
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 :
> Can you add more debugging info?
>
> I glanced at your code, some comments, make sure you follow the
> recommendations in libbsd.txt about modifying
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 2
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 :
> Hello)
> Now I have apps from libbsd testsuite running. But DWC OTG driver doesn't
> loads.
> I added this lines to
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:
devctl: +nexus0 at o
45 matches
Mail list logo
