-----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-----
