From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-15?Q?Andr=E9_Schwarz?= Date: Thu, 06 Mar 2008 14:00:57 +0100 Subject: [U-Boot-Users] [Fwd: Re: FPGA mess] Message-ID: <47CFEB09.7020606@matrix-vision.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de forgot "cc" to list... Stefan, sorry for being impatient ... I'm just trying to get clean and universal code with no need for recoding twice a year. Stefan Roese schrieb: > Andre, > > On Wednesday 05 March 2008, Andre Schwarz wrote: > >> you're listed as maintainer for the alpr board. >> > > Correct. But I didn't use this board for quite some time > ok - no problem. I just need to start somewhere. >> It's the only board that uses the ACEX1K.c file for FPGA loading... >> > > Does it? To use this file you have to define CONFIG_FPGA_ACEX1K. I don't see > it defined anywhere in the whole U-Boot tree. So perhaps this code is not > used at all. > > correct - so you can kick it away. There's a include/ACEX1K.h that introduces two interfaces for obviously the same funtionality. The first one is specific to ACEX1K and the other one is a general cyclone implementation as it should be. >> I'm quite sure there are many boards with Altera FPGAs outside and can't >> believe they have all mounted >> platform flashes and therefore don't use u-boot for loading the FPGA. >> Nevertheless those board don't show up in the tree. Maybe they all keep >> their own patches like me ... >> > > Maybe. I suggest you start pushing your code to change this situation. :) > I've been trying to submit patches for years now - there's always a point when you give up. If there's a will to change this and to discard unused/scrambled code I'll provide a patch as soon as my board is up and running. > >> There are some points that doesn't seem to work out very well in general. >> This is where some questions come up (top->down) : >> >> common/cmd_fpga: >> In function do_fpga there's a used environment variable "fpgadata" that >> obviously stores the location of the bitstream. >> What sense does this make if the "data_size" parameter (=arg4) is _not_ >> optional ? >> Instead the command "fpga load 0 0x..." leads to a load function with >> zero length. >> The user always has to supply all 4 args (load, nr, data, size). >> Of course the loading function could use the pre-defined bitstream size >> from the header or the device struct... >> > > I have to admit that I don't understand what you are really asking here. > Please ask more specific questions. Or send a patch to fix something that > is "broken". > > ok - you'll get a patch. The point is that it makes no sense to provide a function "fpga" (declared in common/cmd_fpga) that accepts up to 4 args with arg2 and arg3 being optional and arg4 not ... >> common/altera.c >> What's that ACEX1K ? Isn't it a Cyclone chip and should use that interface >> ? Why does this need special treatment throughout the interface ? >> > > I didn't introduce this file. Perhaps we should ask the author who committed > this code. > > ok - can you do this ? >> include/ACEX1K.h >> Obviously there are some confusions about the various file formats and >> sizes that can be output >> from Altera's SoPC Builder. Compression is also possible with >> de-compression on the fly during load ... >> Of course the defined file sizes should match a raw bit file that >> represents the true size of the device. >> >> Why is ACEX1K and Cyclone not merged ? >> > > No idea. If you have some fixes, please send patches. > > >> Does _any_ real board use the Altera path ? scanning the config files >> ... no. >> > > alpr seems to use the cyclone2.c code. > > no - it uses common/ACEX1K.c .... and common/cyclon2.c is derived from it. >> CYC2_ps_load in common/cyclon2.c the nCONFIG pin is never de-asserted >> during preparation. This code can't work. >> > > No idea. I have to admit, that I didn't implement the FPGA booting on this > board. But it seems to work fine. > > yes - because it's a board specific implementation with an "general" interface. >> Is there any interest in getting this fixed ? >> > > Sure. > > But implementing the Altera path in a clean way means discarding the ACEX1K and breaking the alpr borad. I'm quite sure that Wolfgang will reject those changes. How can we solve this ? >> What about Liberty's Stratix code ? It's living and working ! >> > > Sorry, but I have no clue what "Liberty's Stratix code" is. > Look out for mails from "eran.liberty". Stratix and Arria are high-end FPGA families from Altera. There's some work left to get those chips implemented well. > Best regards, > Stefan > > ===================================================================== > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de > ===================================================================== > MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner