Plan for commiting Xilinx Zynq support to HEAD

Tim Kientzle tim at kientzle.com
Sat Apr 20 17:49:57 UTC 2013


On Apr 19, 2013, at 9:14 AM, Thomas Skibo wrote:

> On 4/18/13 10:03 PM, Tim Kientzle wrote:
>> 
>> On Apr 18, 2013, at 10:49 AM, Warner Losh wrote:
>> 
>>> 
>>> We do need it documented on the wiki regardless of the automation we put into place. The problem with scripts is that accrue arcane knowledge that later becomes hard to reconstruct.
>> 
>> Should be in the Wiki, yes.
> 
> I think something needs to go into the Wiki.  I think I need to describe the process of booting on Zynq and how I build u-boot, BOOT.BIN, ubldr, etc.

Having documented this myself for a bunch of boards now, here are some suggestions:

For U-Boot:

* Key piece of information is where you got the sources from.  There
  are a lot of U-Boot repos out there with different board support.
  Specifying a particular tag helps a lot.  If the upstream changes
  quickly, setting up your own clone on github may be the only
  practical way to provide stable source.

* What toolchain you built with?  I've been building with FreeBSD's xdev
  toolchain.  It works well but requires a few standard patches
  to build U-Boot on FreeBSD/ARM:
    = -print-file-name=include is used in config.mk but is broken
       on FreeBSD.  I'm trying to get that fixed.  The workaround
       is to patch it to hardcode /usr/include
   = Add -lc to PLATFORM_LIBS since FreeBSD/ARM has some
       arithmetic support routines in the wrong place (they should
       be in libcompiler_rt but are only in libc).
   = Some U-Boot forks now have GNU sed dependencies.

* Finally, the patches for the board configuration itself.  (Enabling
   API and ELF loader, for example.  Rewriting the bootcmd.)

Hopefully, the above is all you'll need.



For ubldr:

Apart from the usual buildenv juggling, you shouldn't need anything special other than
   UBLDR_LOADADDR=<load address>
If you do, let us know.  A few of us have been trying to make ubldr more
generic with an eye towards eventually having a single ubldr binary that
runs "everywhere."


Tim



More information about the freebsd-arm mailing list