<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Heiko,<br>
<br>
this all sounds very well indeed. Looks like we'll get common code.<br>
<br>
Heiko Schocher wrote:
<blockquote cite="mid:47D04A1B.80603@denx.de" type="cite">
<pre wrap="">Hello Andre,
Andre Schwarz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Heiko Schocher schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Hello Stefan,
Stefan Roese wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thursday 06 March 2008, Andre Schwarz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Stefan Roese schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">On Wednesday 05 March 2008, Andre Schwarz wrote:
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->[...]
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Is there any interest in getting this fixed ?
</pre>
</blockquote>
<pre wrap="">Sure.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Yes, I will reject this too. :)
</pre>
</blockquote>
<pre wrap="">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?)
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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:
<a class="moz-txt-link-abbreviated" href="http://www.altera.com/literature/hb/cfg/cfg_cf51001.pdf">www.altera.com/literature/hb/cfg/cfg_cf51001.pdf</a>
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 ;-)
</pre>
</blockquote>
yes - exactly. The pin is low active and by pulling it low (falling
edge) you can inititate device programming.<br>
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.<br>
<blockquote cite="mid:47D04A1B.80603@denx.de" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Sounds good.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">How can we solve this ?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">If would be great if you could test the changes on alpr before applying
patches.
</pre>
</blockquote>
<pre wrap=""><!---->
I fast look in the VLAB and I found no alpr board :-(
</pre>
<blockquote type="cite">
<pre wrap="">It looks like no other Altera boards are in the tree ... I have
different ones and can do excessive testing.
</pre>
</blockquote>
<pre wrap=""><!---->
That would be great
bye,
Heiko
</pre>
</blockquote>
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".<br>
Of course there will be a lot of code cleaning and hopefully Wolfgang
will accept our boards :-)<br>
<br>
I'll supply a patch to the FPGA tree as soon as everything is running
fine.<br>
It would be great if you could test the patch against the alpr and give
me some feedback.<br>
<br>
cheers,<br>
<br>
André<br>
<BR>
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
<BR>
</body>
</html>