Forum: GNU Radio USRP2 firmware build

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
De874e3a59a6990584a8a75eff4f434a?d=identicon&s=25 Jeff Long (Guest)
on 2008-10-03 19:59
(Received via mailing list)
Trying out the firmware build ...

- had to comment out apps/rx_only_v2.c, line 104
   (static volatile bool link_is_up = false) to avoid
   multiple definitions ... does not appear to be used
   in this file and is declared static

- build exceeds size of flatmem (0x8000) ... bumped to
   0xa000 and it worked, but I don't know what flatmem is
   at this point, so that's probably wrong

- not sure why, but the EDK101_GPL_GNU gcc didn't build
   right on a Fedora 9 machine ... worked fine on Fedora 8
   ... will try again

Also, should USRP2/RFX be working at this point?  Noticed
select_rx_antenna is unimplemented (get more signal using
RX2 than TX/RX but signal is really low), and rfx_set_gain_rx
doesn't seem to have any effect.
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2008-10-03 20:30
(Received via mailing list)
On Fri, Oct 03, 2008 at 01:58:02PM -0400, Jeff Long wrote:
> Trying out the firmware build ...
>
> - had to comment out apps/rx_only_v2.c, line 104
>   (static volatile bool link_is_up = false) to avoid
>   multiple definitions ... does not appear to be used
>   in this file and is declared static
>
> - build exceeds size of flatmem (0x8000) ... bumped to
>   0xa000 and it worked, but I don't know what flatmem is
>   at this point, so that's probably wrong

flatmem is the total size of available memory.  It's 32K, so if it's
taking 0xa000, you've got a problem :-)

> - not sure why, but the EDK101_GPL_GNU gcc didn't build
>   right on a Fedora 9 machine ... worked fine on Fedora 8
>   ... will try again

Fedora 9 uses gcc 4.3 which is more stingent than earlier versions.

> Also, should USRP2/RFX be working at this point?  Noticed
> select_rx_antenna is unimplemented (get more signal using
> RX2 than TX/RX but signal is really low), and rfx_set_gain_rx
> doesn't seem to have any effect.

Thanks for the feedback.

I'll be testing this with the EDK101 tools soon.  Most likely today.

None of the interfaces are stable at this point.
There has been no comprehensive QA of any of the daugherboard code.
All the daughterboard code does not fit at this time.  We're
investigating our options, including overlays loaded out of the flash
at boot time.

See also the open tickets:
http://gnuradio.org/trac/query?status=new&status=a...

Eric
De874e3a59a6990584a8a75eff4f434a?d=identicon&s=25 Jeff Long (Guest)
on 2008-10-03 20:32
(Received via mailing list)
Also, mb-gcc had trouble with "-Wl,-T$(LINKER_SCRIPT)".
Had to add another comma: "-Wl,-T,$(LINKER_SCRIPT)"
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2008-10-04 00:14
(Received via mailing list)
On Fri, Oct 03, 2008 at 01:58:02PM -0400, Jeff Long wrote:
>
> - not sure why, but the EDK101_GPL_GNU gcc didn't build
>   right on a Fedora 9 machine ... worked fine on Fedora 8
>   ... will try again
>
> Also, should USRP2/RFX be working at this point?  Noticed
> select_rx_antenna is unimplemented (get more signal using
> RX2 than TX/RX but signal is really low), and rfx_set_gain_rx
> doesn't seem to have any effect.


Update: it looks like the size problem is caused by some change in the
system initialization code, or by some dependency we're accidental
triggering.  It's linking some things we're not using such as malloc
and signal(!).

The size of our individual object files are more or less the same
between versions of the tools.

Eric
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2008-10-04 03:32
(Received via mailing list)
On Fri, Oct 03, 2008 at 01:58:02PM -0400, Jeff Long wrote:
>
> - not sure why, but the EDK101_GPL_GNU gcc didn't build
>   right on a Fedora 9 machine ... worked fine on Fedora 8
>   ... will try again
>
> Also, should USRP2/RFX be working at this point?  Noticed
> select_rx_antenna is unimplemented (get more signal using
> RX2 than TX/RX but signal is really low), and rfx_set_gain_rx
> doesn't seem to have any effect.

As of r9708 on the trunk, the usrp2 firmware builds properly with the
EDK 10.1 based microblaze toolchain.

Eric
De874e3a59a6990584a8a75eff4f434a?d=identicon&s=25 Jeff Long (Guest)
on 2008-10-04 05:20
(Received via mailing list)
Generated a new txrx.bin using EDK101 and put it on the SD
card.  Works!  I'm assuming that's the correct app, based on
strings on the provided SD.  BTW, is any of this documented
yet?

Where do printf's go to?

Using -Os vs. -O2 shaves off another 500 bytes if you ever
need the space.  Takes txrx.bin from 26028 to 25484 bytes.

The function __udivdi3 is 1836 bytes long, and is only used
in print_uint64, which is used only in printf_fxpt_freq.
That might be something to get rid of.
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2008-10-04 08:16
(Received via mailing list)
Jeff Long wrote:
> Generated a new txrx.bin using EDK101 and put it on the SD
> card.  Works!  I'm assuming that's the correct app, based on
> strings on the provided SD.  BTW, is any of this documented
> yet?

Yes, txrx is the correct app to use, and is the one which is on the SD
card which I ship out.  No, we don't really have this written anywhere.
I've been putting stuff on the USRP2 FAQ page on the wiki, but clearly
this is a lot which still needs to be documented.

> Where do printf's go to?

They go to the serial port on the right side of the USRP2, between the
two daughterboards.  You would have to connect a TTL-level serial port
to it, at 230,400 baud.

>
> Using -Os vs. -O2 shaves off another 500 bytes if you ever
> need the space.  Takes txrx.bin from 26028 to 25484 bytes.

I was thinking that -Os would probably be a good thing to try.  Having
only 32K of RAM can be a bit constraining.

> The function __udivdi3 is 1836 bytes long, and is only used
> in print_uint64, which is used only in printf_fxpt_freq.
> That might be something to get rid of.


Wow, 1836 bytes is a lot.

I'm really glad to have your feedback and bug reports on this.  It will
definitely help blaze the trail for other users.

Thanks,
Matt
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2008-10-04 15:05
(Received via mailing list)
On Fri, Oct 03, 2008 at 11:10:36PM -0700, Matt Ettus wrote:
> Jeff Long wrote:
>> Generated a new txrx.bin using EDK101 and put it on the SD
>> card.  Works!  I'm assuming that's the correct app, based on
>> strings on the provided SD.  BTW, is any of this documented
>> yet?
>
> Yes, txrx is the correct app to use, and is the one which is on the SD
> card which I ship out.  No, we don't really have this written anywhere.
> I've been putting stuff on the USRP2 FAQ page on the wiki, but clearly
> this is a lot which still needs to be documented.

txrx is the standard firmware at this point.

>> Where do printf's go to?
>
> They go to the serial port on the right side of the USRP2, between the
> two daughterboards.  You would have to connect a TTL-level serial port
> to it, at 230,400 baud.
>
>>
>> Using -Os vs. -O2 shaves off another 500 bytes if you ever
>> need the space.  Takes txrx.bin from 26028 to 25484 bytes.

Good to know.  We'll need to see how the inner loop holds up.
At decim = 4 and/or interp = 4, it's close to being the bottleneck.


> I was thinking that -Os would probably be a good thing to try.  Having
> only 32K of RAM can be a bit constraining.
>
>> The function __udivdi3 is 1836 bytes long, and is only used
>> in print_uint64, which is used only in printf_fxpt_freq.
>> That might be something to get rid of.

> Wow, 1836 bytes is a lot.

Right now __moddi3, __umoddi3, __divdi3 and __udivdi3 contain inlined
versions of __udivmoddi4.   Un-inlining them should save about 5KB in
the worst case, 4KB typical.  I'm working on it.  (These routines
implement signed and unsigned 64-bit divides and mods.  We use these
in dealing with our 64-fixed point frequency representation.)


Jeff, which RFX board are you using?


Eric
De874e3a59a6990584a8a75eff4f434a?d=identicon&s=25 Jeff Long (Guest)
on 2008-10-04 21:26
(Received via mailing list)
>
> Right now __moddi3, __umoddi3, __divdi3 and __udivdi3 contain inlined
> versions of __udivmoddi4.   Un-inlining them should save about 5KB in
> the worst case, 4KB typical.  I'm working on it.  (These routines
> implement signed and unsigned 64-bit divides and mods.  We use these
> in dealing with our 64-fixed point frequency representation.)
>
I just commented out all the lines in print_tune_result, and the size
of txrx went down to 21404.  Adding -Os gives 20900 (didn't test these
builds).  Did not test -Os version.
>
> Jeff, which RFX board are you using?
>
RFX2400 Rev30 12-26-2006
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2008-10-04 21:54
(Received via mailing list)
On Sat, Oct 04, 2008 at 03:22:52PM -0400, Jeff Long wrote:
>>
>> Jeff, which RFX board are you using?
>>
> RFX2400 Rev30 12-26-2006
>>
>> Eric
>

With the un-inlining of __udivmoddi4, txrx is down 3100 bytes using
-O2, nothing else changed:

$ size txrx
   text    data     bss     dec     hex filename
  21516    1348    2256   25120    6220 txrx


$ nm --size-sort txrx
...
00000150 T __muldi3
0000015c T dbsm_init
0000016c T print_tune_result
00000188 T db_tune
000001a8 T start_rx_streaming_cmd
000001b4 T clocks_mimo_config
000001b8 T printf
000001d8 T calc_dxc_freq
000001dc t dbsm_process_helper
000001f8 T main
00000230 T rfx_set_freq
00000258 T tvrx_set_freq
0000026c T u2_init
00000708 T handle_control_chan_frame
000008f0 T __udivmoddi4



I'll work up a clean patch to the compiler and upload the source and
generated binaries.

I was also trying to use the -mxl-gp-opt -G 16384 options, but this
triggers a bug (Xilinx AR #30271) that's fixed in EDK 10.1 SP1.  They
are currently not distributing the source for that (in violation of
the GPL).  I've just registered as a WebCase user; once I'm approved
I'll attempt to open a ticket on this.  (The bug is that they are
putting "small" zero initialized items in the .bss section instead of
the .sbss section.)  I may be able to find and fix this quicker than I
can get Xilinx to release the code :-/

-mxl-gp-opt -G 16384 should remove virtually all of the IMM
instructions, since all accesses to statically allocated data will be
based off of the small data base registers.

Eric
This topic is locked and can not be replied to.