ZedBoard GNU Radio image boot problems

GNU Radio
1

I’m trying to boot a ZedBoard with the GNU Radio image here:
http://gnuradio.org/data/sdk/zedboard_armv7a-hf-vfp-neon/. I picked the
hard float image even though the tutorial points to the soft float image
(http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq). I don’t know
why I’d want the soft float image since using the FPU will be much
faster.

I followed the directions at the aforementioned tutorial except I
renamed “u-boot.bin” to “BOOT.BIN” and “uImage-zedboard-zynq7.dtb” to
“devicetree.dtb”. I could not get the board to boot. The USB-to-UART
triggers cdc_acm to load /dev/ttyACM0 on my Linux host PC, but there is
no activity over serial. I’m confident the board is not dead because I
am able to boot from the preloaded SD card that came with the ZedBoard
development kit. Does anybody have any suggestions? It seems like either
some step is missing or I am misunderstanding a step in the tutorial.

Thanks,
Sean Nowlan

2

On Wed, Sep 3, 2014 at 4:30 PM, Nowlan, Sean
[email protected]
wrote:

I’m trying to boot a ZedBoard with the GNU Radio image here:
http://gnuradio.org/data/sdk/zedboard_armv7a-hf-vfp-neon/. I picked the
hard float image even though the tutorial points to the soft float image (
http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq). I don’t know
why I’d want the soft float image since using the FPU will be much faster.

There’s a bug in ORC on hard float. So we were looking into soft float +
ORC or hard flow - ORC. Now that we’ve checked in all of Nathan’s NEON
VOLK
kernels to GNU Radio, we mostly cover all of the cases where we were
benefiting from ORC.

Bottom line, at this point in the development, use hard float. We will
likely stop all support of soft float images in the future.

Thanks,

Sean Nowlan

u-boot.bin != BOOT.BIN. I know it feels like it should, but it’s missing
the first stage boot loader (fsbl). There are licensing issues with
distributing that ourselves. I might have the details slightly wrong
since
it’s been a while. But basically, follow the instructions on the Zynq
wiki
you linked to above to build your of fsbl file and properly build your
own
boot.bin. Then DON’T LOSE THAT FILE. That’ll be pretty much permanent
for
your uses. You did the right thing with the device tree file, as that
might
be updated and changed and we’ll continue providing that.

Tom

3

On 09/03/2014 04:30 PM, Nowlan, Sean wrote:

I’m trying to boot a ZedBoard with the GNU Radio image here:
http://gnuradio.org/data/sdk/zedboard_armv7a-hf-vfp-neon/. I picked the hard float
image even though the tutorial points to the soft float image
(http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq). I don’t know why I’d
want the soft float image since using the FPU will be much faster.

Hard float isn’t that much faster. It referes to the ARM abi used for
function calls. Hard float lets you return floats in NEON registers,
which makes functions that return floats faster. Pretty much everything
else is the same. So, it is a win, but not huge, except for certain
cases.

Philip

4

On Wed, Sep 3, 2014 at 5:53 PM, Philip B. [email protected]
wrote:

Hard float isn’t that much faster. It referes to the ARM abi used for
function calls. Hard float lets you return floats in NEON registers,
which makes functions that return floats faster. Pretty much everything
else is the same. So, it is a win, but not huge, except for certain cases.

Philip

Nathan and I have both done some tests. You can get a few percent
improvement in speed with just hard float. That by itself was not a
compelling enough reason to drop the ORC support. It was only because of
the NEON VOLK proto-kernels that made the change worth it.

I had some data that I was going to publish at one point, but it was too
confused with different development stages so that the comparisons
wouldn’t
be clean or clear.

Tom

5

On Thu, Sep 4, 2014 at 9:49 AM, Tom R. [email protected] wrote:

I’d want the soft float image since using the FPU will be much faster.
Nathan and I have both done some tests. You can get a few percent

That’s correct, in my VOLK tests the only time hardfloat made any
difference was when the compiler inserted a call to its runtime
library for generic code. I expect this will come up in the VOLK
and/or embedded working group sessions at grcon.

6

On Wed, Sep 3, 2014 at 4:30 PM, Nowlan, Sean
<[email protected]mailto:[email protected]> wrote:
I’m trying to boot a ZedBoard with the GNU Radio image here:
http://gnuradio.org/data/sdk/zedboard_armv7a-hf-vfp-neon/. I picked the
hard float image even though the tutorial points to the soft float image
(http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq). I don’t know
why I’d want the soft float image since using the FPU will be much
faster.

There’s a bug in ORC on hard float. So we were looking into soft float +
ORC or hard flow - ORC. Now that we’ve checked in all of Nathan’s NEON
VOLK kernels to GNU Radio, we mostly cover all of the cases where we
were benefiting from ORC.

Bottom line, at this point in the development, use hard float. We will
likely stop all support of soft float images in the future.

I followed the directions at the aforementioned tutorial except I
renamed “u-boot.bin” to “BOOT.BIN” and “uImage-zedboard-zynq7.dtb” to
“devicetree.dtb”. I could not get the board to boot. The USB-to-UART
triggers cdc_acm to load /dev/ttyACM0 on my Linux host PC, but there is
no activity over serial. I’m confident the board is not dead because I
am able to boot from the preloaded SD card that came with the ZedBoard
development kit. Does anybody have any suggestions? It seems like either
some step is missing or I am misunderstanding a step in the tutorial.

Thanks,
Sean Nowlan

u-boot.bin != BOOT.BIN. I know it feels like it should, but it’s missing
the first stage boot loader (fsbl). There are licensing issues with
distributing that ourselves. I might have the details slightly wrong
since it’s been a while. But basically, follow the instructions on the
Zynq wiki you linked to above to build your of fsbl file and properly
build your own boot.bin. Then DON’T LOSE THAT FILE. That’ll be pretty
much permanent for your uses. You did the right thing with the device
tree file, as that might be updated and changed and we’ll continue
providing that.

Tom

Ok. I was afraid of that, but it’s not clear in the tutorial. Also, I
see the process for building BOOT.BIN in Appendix A. I think things
would be more clear if the “Pre-built” wiki section had a paragraph
explicitly referring to Appendix A as a necessary step before using
pre-built images (second stage boot loader, kernel, boot parameters,
rootfs, etc.) for everything else. In my mind it seemed like that step
only applied if doing a full OpenEmbedded build.

Thanks!
Sean