[U-Boot-Users] FPGA mess

[Andre Schwarz <andre.schwarz@matrix-vision.de>]

Heiko Schocher schrieb:
> Hello Stefan,
>
> Stefan Roese wrote:
>   
>> On Thursday 06 March 2008, Andre Schwarz wrote:
>>     
>>> Stefan Roese schrieb:
>>>       
>>>> On Wednesday 05 March 2008, Andre Schwarz wrote:
>>>>         
> [...]
>   
>>> 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.
>>>       
>> Please clean it up too.
>>     
>
> Maybe we should do a cyclon2.h ?
>
>   
>>>>> 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.
>>>       
>> No, it doesn't use common/ACEX1K.c.
>>     
>
> Yes, common/ACEX1K.c was the base for me to make the cyclon2.c.
>
>   
>>>>> 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.
>>>       
>> ???
>>     
>
> What do you mean with "board specific implementation". Its for a cyclon2
> FPGA. I am not a FPGA specialist, but I think there were some differences
> between this FPGAs and so I made a new File ...
>
>   
>>>>> 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.
>>>       
>> Yes, I will reject this too. :)
>>     
>
> Why you break the alpr board. It uses the common/cyclon2.c?
> (OK, we should make a include/cyclon2.h and then we can drop the ACEX1K, right?)
>
>   
I admit that I have not followed the ACEX1K down through the interface. 
But since there is an ACEX1K "#define"
in common/altera.c and the serial download of the Cyclone is broken 
(missing deassertion of nConfig) it looked like
alpr used the ACEX1K.

As I see now this is not true. We should fix the programming of nConfig 
and verify on alpr.
Then we can remove ACEX1K and prepare for Cyclone-II and -III with a 
unified loader, corrected chip
sizes and variable bitstream formats including endianess.
>>> How can we solve this ?
>>>       
>> By trying to solve it in a compatible way. I added Heiko Schocher to CC too, 
>> since he was responsible for the FPGA booting implementation of the alpr 
>> board.
>>     
>
> I have to admit that this was my First and only FPGA Implementation.
> Stefan, do you know, if we have somewhere an alpr board, so we can do
> tests with it, if we change code?
>
> bye
> Heiko
>   
If would be great if you could test the changes on alpr before applying 
patches.
It looks like no other Altera boards are in the tree ... I have 
different ones and can do excessive testing.


regards,
Andre



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080306/0fba0f09/attachment.htm