public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "André Schwarz" <Andre.Schwarz@matrix-vision.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] FPGA mess
Date: Thu, 06 Mar 2008 21:41:11 +0100	[thread overview]
Message-ID: <47D056E7.9030506@matrix-vision.de> (raw)
In-Reply-To: <47D04A1B.80603@denx.de>

Heiko,

this all sounds very well indeed. Looks like we'll get common code.

Heiko Schocher wrote:
> Hello Andre,
>
> Andre Schwarz wrote:
>   
>> 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:
>>>>>>             
> [...]
>   
>>>>>>> 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.
>>     
>
> Ah, I understand (but the serial download on a cyclon 2 work(ed) fine ...)
> I think I will have a look in the datasheet for the cyclon 2 ...
>
> Hmm.. maybe I overlook something, but I see in:
>
> www.altera.com/literature/hb/cfg/cfg_cf51001.pdf
>
> on page 3 in the "Device Configuration Overview for Passive Schemes"
> Figure 1-1
>
> No need to deassert the nConfig Line after the Configuration ...
>
> And a "A reconfiguration is initiated by toggling the nCONFIG pin from high to
> low and then back to high."
>
> So it sounds to me its better to hold this line high ... but I am
> not a expert ;-)
>
>   
yes - exactly. The pin is low active and by pulling it low (falling 
edge) you can inititate device programming.
Holding this pin low doesn't work on any cyclone-II/III chip I have. You 
have to deassert (=back to high) this before the first data bit comes in.
>> 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.
>>     
>
> Sounds good.
>
>   
>>>>> 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.
>>     
>
> I fast look in the VLAB and I found no alpr board :-(
>
>   
>> It looks like no other Altera boards are in the tree ... I have
>> different ones and can do excessive testing.
>>     
>
> That would be great
>
> bye,
> Heiko
>   
I'm doing a lot of updates regarding u-boot + linux kernel right now 
since we're upgrading the kernel to 2.6.24 with the new "libfdt".
Of course there will be a lot of code cleaning and hopefully Wolfgang 
will accept our boards :-)

I'll supply a patch to the FPGA tree as soon as everything is running fine.
It would be great if you could test the patch against the alpr and give 
me some feedback.

cheers,

Andr?


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/bfe83a69/attachment.htm 

  reply	other threads:[~2008-03-06 20:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-05 16:42 [U-Boot-Users] FPGA mess Andre Schwarz
2008-03-06  6:53 ` Stefan Roese
     [not found]   ` <47CFC43C.2060401@matrix-vision.de>
2008-03-06 14:24     ` Stefan Roese
2008-03-06 17:37       ` Heiko Schocher
2008-03-06 17:50         ` Andre Schwarz
2008-03-06 19:46           ` Heiko Schocher
2008-03-06 20:41             ` André Schwarz [this message]
2008-03-07  6:13               ` Heiko Schocher
2008-03-06 19:47         ` Stefan Roese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47D056E7.9030506@matrix-vision.de \
    --to=andre.schwarz@matrix-vision.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox