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.
On Fri, Oct 03, 2008 at 01:58:02PM -0400, Jeff L. 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.
On Fri, Oct 03, 2008 at 01:58:02PM -0400, Jeff L. 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.
On Fri, Oct 03, 2008 at 01:58:02PM -0400, Jeff L. 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.
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.
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.
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.
On Fri, Oct 03, 2008 at 11:10:36PM -0700, Matt E. wrote:
Jeff L. 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.)
On Sat, Oct 04, 2008 at 03:22:52PM -0400, Jeff L. 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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
