FPGA mess
Stefan,
you're listed as maintainer for the alpr board.
It's the only board that uses the ACEX1K.c file for FPGA loading...
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 ...
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...
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 ?
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 ?
Does _any_ real board use the Altera path ? scanning the config files ... no.
CYC2_ps_load in common/cyclon2.c the nCONFIG pin is never de-asserted during preparation. This code can't work.
Is there any interest in getting this fixed ?
What about Liberty's Stratix code ? It's living and working !
regards,
Andre Schwarz
MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Andre,
Quoted 1 line · Andre Schwarz
you're listed as maintainer for the alpr board.
Correct. But I didn't use this board for quite some time.
Quoted 1 line
It's the only board that uses the
ACEX1K.cfile 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.
Quoted 5 lines
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. :)
Quoted 13 lines
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 functiondo_fpgathere'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".
Quoted 3 lines
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.
Quoted 9 lines
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.
Quoted 2 lines
Does _any_ real board use the Altera path ? scanning the config files ... no.
alpr seems to use the cyclone2.c code.
Quoted 2 lines
CYC2_ps_loadincommon/cyclon2.cthe 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.
Quoted 1 line
Is there any interest in getting this fixed ?
Sure.
Quoted 1 line
What about Liberty's Stratix code ? It's living and working !
Sorry, but I have no clue what "Liberty's Stratix code" is.
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
=====================================================================
Andre,
Quoted 2 lines · Andre Schwarz
sorry for being impatient ... I'm just trying to get clean and universal code with no need for recoding twice a year.
No problem.
Quoted 9 lines
Quoted 6 lines · Stefan Roese
Andre,
Quoted 1 line · Andre Schwarz
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.
Good.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
It's the only board that uses the
ACEX1K.cfile 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.
If no official board uses it and it looks broken to you, then please send a patch to remove it.
Quoted 4 lines
There's a
include/ACEX1K.hthat 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.
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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 ...
Quoted 6 lines
Quoted 1 line
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.
As you may know, we changed our development infrastructure by adding submaintainers (custodians) for subsystems. Currently this is working not perfect, but seems to get better over the time. So we are improving here.
Unfortunately we don't have a custodian for the FPGA stuff. Since it's getting more and more complex, it would be great if somebody would step up here. Any volunteers? :)
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
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 functiondo_fpgathere'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...
Quoted 8 lines
Quoted 3 lines
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 ...
Right. With this description it makes sense to me. But we have to be careful here, not to change the command syntax in a non backward compatible way.
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
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 ?
Yes. Steven Scholz as original author is on CC.
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
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 ?
Quoted 8 lines
Quoted 6 lines
No idea. If you have some fixes, please send patches.
Quoted 2 lines
Does _any_ real board use the Altera path ? scanning the config files ... no.
alpr seems to use the
cyclone2.ccode.no - it uses
common/ACEX1K.c.... andcommon/cyclon2.cis derived from it.
No, it doesn't use common/ACEX1K.c.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
CYC2_ps_loadincommon/cyclon2.cthe 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.
???
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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. :)
Quoted 1 line
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.
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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.
Sorry, I currently don't have the time to read through this whole email thread. Please write an answer to this thread if you have some comments there.
Thanks.
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
=====================================================================
Hello Stefan,
Quoted 3 lines · Stefan Roese
Quoted 2 lines · Andre Schwarz
Quoted 1 line · Stefan Roese
On Wednesday 05 March 2008, Andre Schwarz wrote:
[...]
Quoted 6 lines
Quoted 4 lines
There's a
include/ACEX1K.hthat 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 ?
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
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 ?
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
No idea. If you have some fixes, please send patches.
Quoted 2 lines
Does _any_ real board use the Altera path ? scanning the config files ... no.
alpr seems to use the
cyclone2.ccode.no - it uses
common/ACEX1K.c.... andcommon/cyclon2.cis 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.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
CYC2_ps_loadincommon/cyclon2.cthe 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 ...
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Quoted 1 line
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?)
Quoted 5 lines
Quoted 1 line
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
Signature · 2 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 74 lines · Heiko Schocher
Hello Stefan,
Quoted 6 lines · Stefan Roese
Quoted 4 lines · Andre Schwarz
Quoted 2 lines · Stefan Roese
On Wednesday 05 March 2008, Andre Schwarz wrote:
[...]
Quoted 7 lines
Quoted 5 lines
There's a
include/ACEX1K.hthat 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?Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 10 lines
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.
Quoted 9 lines
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Does _any_ real board use the Altera path ? scanning the config files ... no.
alpr seems to use the
cyclone2.ccode.no - it uses
common/ACEX1K.c.... andcommon/cyclon2.cis derived from it.No, it doesn't use
common/ACEX1K.c.Yes,
common/ACEX1K.cwas the base for me to make thecyclon2.c.Quoted 11 lines
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
CYC2_ps_loadincommon/cyclon2.cthe 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 ...
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 2 lines
Yes, I will reject this too. :)
Why you break the alpr board. It uses the
common/cyclon2.c?
(OK, we should make ainclude/cyclon2.hand 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.
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
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
Hello Andre,
Quoted 10 lines · Andre Schwarz
Quoted 9 lines · Heiko Schocher
Hello Stefan,
Quoted 5 lines · Stefan Roese
Quoted 3 lines · Andre Schwarz
Quoted 1 line · Stefan Roese
On Wednesday 05 March 2008, Andre Schwarz wrote:
[...]
Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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.Quoted 8 lines
Quoted 2 lines
Yes, I will reject this too. :)
Why you break the alpr board. It uses the
common/cyclon2.c? (OK, we should make ainclude/cyclon2.hand then we can drop the ACEX1K, right?)
Quoted 5 lines
I admit that I have not followed the ACEX1K down through the interface. But since there is an ACEX1K "#define"
incommon/altera.cand 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 ;-)
Quoted 5 lines
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.
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 2 lines
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?
Quoted 5 lines
Quoted 3 lines
bye
HeikoIf 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 :-(
Quoted 2 lines
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
Signature · 2 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Hi Heiko,
Quoted 9 lines · Heiko Schocher
Quoted 5 lines
Quoted 1 line
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?
I have one here, but I haven't used it for a long time. So either I could try to setup this board again, or I could ask the customer to test it on their system. One or the other way should be possible.
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
=====================================================================
Heiko,
this all sounds very well indeed. Looks like we'll get common code.
Quoted 58 lines · Heiko Schocher
Hello Andre,
Quoted 15 lines · Andre Schwarz
Quoted 13 lines · Heiko Schocher
Hello Stefan,
Quoted 8 lines · Stefan Roese
Quoted 5 lines · Andre Schwarz
Quoted 2 lines · Stefan Roese
On Wednesday 05 March 2008, Andre Schwarz wrote:
[...]
Quoted 20 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
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.Quoted 9 lines
Quoted 3 lines
Yes, I will reject this too. :)
Why you break the alpr board. It uses the
common/cyclon2.c? (OK, we should make ainclude/cyclon2.hand then we can drop the ACEX1K, right?)Quoted 6 lines
I admit that I have not followed the ACEX1K down through the interface. But since there is an ACEX1K "#define"
incommon/altera.cand 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
Quoted 9 lines
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.
Quoted 33 lines
Quoted 6 lines
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.
Quoted 12 lines
Quoted 12 lines
Quoted 8 lines
Quoted 3 lines
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?
Quoted 7 lines
Quoted 4 lines
bye
HeikoIf 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 :-(
Quoted 9 lines
Quoted 3 lines
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
Hello Andr?,
Andr? Schwarz wrote:
[...]
Quoted 1 line
I'll supply a patch to the FPGA tree as soon as everything is running fine.
Great.
Quoted 2 lines
It would be great if you could test the patch against the alpr and give me some feedback.
It looks like Stefan can "organize" a board, so I can test it.
bye,
Heiko
Signature · 2 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany