Re: [Balloon] Build FPGA image from source

OH! I love it when I see somebody else do that! Did you mean to
Reply-All instead of Reply?

On a slightly different note -- is it possible to configure the
mailing list so that it sets the reply-to field to point back at the
list instead of the author?
On Tue, May 24, 2011 at 4:51 PM, Wookey <wookey@wookware.org> wrote:
> +++ Patrick Doyle [2011-05-24 15:56 -0400]:
>> Hi Team!
>>
>> I have updated (mostly) the vhdl directory to build the FPGA image
>> from source using the Xilinx 13.1 tools.(*)  Attached is a patchfile
>> showing what I changed.
>
> Cool. The jed and xsvf shouldn't be in svn IMHO, so they wouldn't need
> reverting. They should only be in the releases, as generated files,
> like other binaries. Some others in the team prefer to have
> out-of-date binaries checked in than doing things properly :-)
>
> Perhaps your svn revert is useful compromise on this point.

It is handy to be able to say, "Wait a minute, didn't XYZ used to
work?" pull it out of the repository, load it in the device and answer
that question. Especially when silly things like changing revs of the
Xilinx tools can lead to XYZ no longer working.


>> Can anybody tell me why Makefile.local is under revision control?
>> Shouldn't that be something that I own locally and modify as I see
>> fit?
>
> That certainly used to be the case, but since r1133 Makefile.local
> seems to be something completely different, which doesn't look like
> local config . Are you working from trunk or the 1.0 branch release?

I'm working from trunk. 1.0 doesn't build from scratch right now, at
a minimum because it tries to retrieve a source tarball from
ftp.uk.linux.org, which doesn't seem to exist anymore.

>
>> Anyway, this patch assumes that XILINX-TOOLS is set in Makefile.local
>> and that it points to the local Xilinx installation.  It also assumes
>> that you're running something recent enough that you need to source
>> settings32.sh instead of settings.sh.
>
> What's the difference? I don't have the (unfeasibly fat) Xilinx tools
> on this machine,
I haven't used the Xilinx tools in ages, and the last time I did, I
didn't have a real computer on which to use them, so I had to use the
Windows version. I'm inferring from the scripts that at one time one
had to source settings.sh. Nowadays, one has to source settings32.sh
(or probably settings64.sh on a 64-bit machine, but I'm playing on a
32 bit machine right now.)

I could pull XILINX-TOOLS out of Makefile.local and instead rely upon
it being set in the environment, but then we would probably have to
change it from "XILINX-TOOLS" to "XILINX_TOOLS".

>> With these changes, I can do a
>>
>> $ make fpga
>>
>> in either the top level or the package/vhdl directory & rebuild the
>> FPGA code.
>
> Excellent. I'm glad someone else is interested in having this working.
> The other hardware people on the team use the Windows tools, and
> aren't very bothered about being able to do a proper 'make' release of
> the code.
>
> The big problem here is that since Xilinx turned the project files
> froma sensible list of the files to a huge mess of concatenated
> source+binary bits it's very hard to keep the project and build files
> in sync, and for both the GUI and the 'make' build systems to produce
> matching output we need them to stay synced. If we could solve this
> everyone would be happy.
WIth 13.1, (or perhaps sometime earlier than that) they seem to be
using XML to store a lot (all?) of the project data. That should make
it easier to keep things in sync.

>
>> (*) Why 13.1?  Because that's what I happened to download when I said
>> to myself, "I need to go get some Xilinx tools".  I know some folks
>> like to run one release behind the latest (especially for Xilinx
>> tools) and it doesn't appear that we're doing anything that really
>> needs the latest & greatest from Xilinx, but that's what I've got.
>
> This doesn't matter for the 'make' build, but it does matter for the GUI
> tools because if one runs a newer version then the tools convert the
> project file forward to a new incompatible format. If they check that
> in, then immediately no-one else can build the files with downloading
> another 3GB of software.

In light of that, perhaps I should roll back to whatever version the
rest of the team is using. Although in light of the move to XML based
configuration data, it's tougher to argue that point.

>
> For this reason the project tries to stick with one version of the
> tools that keeps everyone happy. If Xilinx didn't write such
> badly-behaved tools our lives would be a lot easier.
>
I agree

>> Index: Makefile.local
>> ===================================================================
>> --- Makefile.local    (revision 1572)
>> +++ Makefile.local    (working copy)
>> @@ -1,3 +1,5 @@
>> +export XILINX-TOOLS=/opt/Xilinx/13.1/ISE_DS
>
> I'm not sure if this is still the right place for this. Nick, how do
> such locally-configured vars work in the new menuconfig scheme?
>
wpd anxiously awaits a reply...

>
>>  default: cpld fpga
>>  ifdef XILINX-TOOLS
>> -     #$(shell . $(XILINX-TOOLS)/settings.sh)
>>       ./build_cpld $(XILINX-TOOLS) && mv -f l3cpld.jed cpld/
>>  else
>> -     # ***************************************************************
>> -     # ** Your CPLD image is out of date. You need to regenerate it **
>> -     # **      with the XILINX tools. Specify path to these in      **
>> -     # **      XILINX-TOOLS in Makefile.local to automate this      **
>> -     # ***************************************************************
>> +     @echo "***************************************************************"
>> +     @echo "** Your CPLD image is out of date. You need to regenerate it **"
>> +     @echo "**      with the XILINX tools. Specify path to these in      **"
>> +     @echo "**      XILINX-TOOLS in Makefile.local to automate this      **"
>> +     @echo "***************************************************************"
>
> We didn't used to need the echo because make prints out comment lines
> in executed targets. Doesn't this make it appear twice?

The "@" sign inhibits the command from being displayed. Emacs was
whining at me about the lines that began with tabs not being real
commands. In this situation, I agree with Emacs, so I changed the
commands (instead of changing Emacs, which is what I do when I don't
agree).


>
>
> Other than that, nice cleanup. I'd like to run it all in a separate
> build dir so we didn't get piles of temp files cluttering up the
> checkout. It would make things clearer (and avoid the issue with .jed
> and xsvf files in svn). But I didn't get that far. It's not possible
> (so far as I can tell, and I tried) to tell the tools to 'put all
> files over there' - it has to be done the other way round: cd to build
> dir and refer to files in the checkout.

Yeah, I spent some time today trying to figure out what buttons to
push to get all of the files in the build dir, but it seems that
Xilinx doesn't share this philosophy. I guess I could have done the
"svn propedit" thing and added the remaining files to .gitignore
(oops, my git showed through here), but I let it slide.


>
> Unless anyone violently objects I'll check this in.

I think I'd wait until I heard some more about what the standard
version of the tools is. I can roll back to that standard and then
make sure that things like "settings.sh" vs. "settings32.sh" don't
break the standard. Hmmm... I might even put some automation in the
process to dynamically source the right one.... I like that.

>
> Wookey
> --
> Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
> http://wookware.org/
>

--wpd
--
Doesn't wear hats because his head is too fat.