Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Jon Masters <jonathan@jonmasters.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrei Konovalov wrote:

|>> Do you use EDK for your desing?

jcm>> EDK gets used for bits of it but then treated as a black box which
jcm>> goes in to various other design tools. I don't rely upon any defines
jcm>> EDK generates for me as I don't trust them ;-).

| I see. The bitstream (ACE file) is generated with EDK,
| autogenerated BSP is mostly ignored.

Thing is, EDK is good at certain things but Synplify and other tools are
much better at overal project design so we build the platform in EDK and
then treat it as a black box in a much larger design. I use a bunch of
scripts and the dummy.o type behaviour of a kernel build to bodge in my
own firmware with kernel and root initrd in a single image which can be
loaded by the sysace. It works better than most examples I have seen.

| I use the Linux version of their tools. cygwin is not a 100% replacement
| for Linux.

I'd like to but there are various reasons why that's impractical at the
moment - eventually I'm going to fix this and use the ported tools.
Certainly they could have done a much better job with xygwin as they
severely limit what I can script in some of my Makefiles.

|>> I guess you do not use what Xilinx calls "OS independent drivers" (==
|>> HAL?) too then.

jcm>> I use them only for xsysace because I looked in to rewriting your
jcm>> driver to not do that but it would take too long. I'm still planning
jcm>> to rewrite it though to not use their HAL concept. It's a really bad
jcm>> idea to rely upon third party HAL code in the kernel itself and should
jcm>> not be done - instead the kernel needs to be able to be given
jcm>> parameters at run time and do the driver work itself. The xsysace
jcm>> adapter stuff it not pretty (though you guys did a good job, thanks)
jcm>> and really doesn't want to be implemented that way.

| Understand. I think rewriting UART Lite or probably xsysace not to
| use HAL code is not a tremendous effort.

No it's not. But it does take more than an afternoon to get working
properly and I have other more pressing issues to sort first.

| IMHO more complex drivers like ethernet in SGDMA mode is a problem:

Yes. Luckily I wouldn't use the Xilinx ethernet MAC unless there were
few alternatives, since I've heard only negative things about it. It
apparently occupies a large amount of chip resources and has a few other
issues that have yet to be fully resolved, hardware MACs are cheap.

|> While we're on this subject I will ask - do you also need something
|> like the nointr mods I pointed out in order to use sysace for writing
|> on that board? The hardware generates more interrupts than anything
|> documented suggests that it should and your driver dies horribly (or
|> is completely unreliable) unless I modify it as I mentioned. It's
|> probably a sysaceism.

| Not too much to say about sysace at the moment.
| We do not use xsysace in our Memec 2VP7 design

I thought you probably didn't. We/I have this cunning thought that very
few people are actually using sysace for read/write filesystems.

| I was just asked to try to enhance the xsysace driver performance -
| will use this opportunity to have a deeper look at the driver's internals.

I spent a long time going through your driver code (where you is whoever
at Monta wrote it in combination with Xilinx) and can say that, while it
isn't pretty, I can't fault it. There's nothing in there which is
horribly buggy and wrong despite the xsa_thread concept which ac agrees
is a really bad idea in theory (but you end up having to use it to make
this xsysace driver work) :-).

Jon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBZJXxeTyyexZHHxERAv3eAJ9/w42mIMEG0ghJBx7+BKu8GooB6ACcC+KQ
5G3HoMvX8a4cW+YbGIUgMZU=
=8FCM
-----END PGP SIGNATURE-----