Linux on Memec Virtex II Pro V4P7 Rev. 3

[Andrei Konovalov]

Jon Masters wrote:
> On Tue, 05 Oct 2004 20:05:29 +0400, Andrei Konovalov
> <akonovalov at ru.mvista.com> wrote:
> 
>>Jon Masters wrote:
> 
> 
>>>You need a few extra patches such as the one to use even TLBs only
>>>that I and others ended up implementing on the engineering v2ps.
>>
>>This one does present in the patch from Mind.be. Look for
>>CONFIG_IBM405D5XN_TLB_BUG in patch-platform-insightv2pro.
> 
> 
> They've added it since I think - I had thought they had done.
> 
> 
>>>It's necessary elsewhere too so I wouldn't get too worked up about
>>>that. The Monta guys don't get this problem on their shiney ML300s but
>>>then if I wanted to expense 6K to Xilinx for a touchscreen board I
>>>might buy one too :-).
>>
>>We have the Memec board running as well.
> 
> 
> Well great :-).
> 
> 
>>With P160 COMM module though.
> 
> 
> It's not worth using the P160 module most of the time though it's good
> for a dev board.
> 
> 
>>>The EDK stuff sucks horribly - avoid the autogenerated platforms
>>>beyond the necessary. Certainly don't use the xparms file from EDK in
>>>your design, that supports the notion Xilinx have of shoving a HAL in
>>>to the kernel.
> 
> 
>>Do you use EDK for your desing?
> 
> 
> EDK gets used for bits of it but then treated as a black box which
> goes in to various other design tools. I don't rely upon any defines
> 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.

> 
>>If yes, how do you get the addresses etc from you design without using xparams?
> 
> 
> I've modified most of the drivers I use to have defines, or used an
> xparameters.h for some stuff but written it by hand without relying
> upon the EDK generation tools. They managed to get the MHS out of sync
> with the design one too many times for me to trust them for a long
> long time with parameters.

With P160 COMM module I have seen that the flash size was taken
in words, not bytes, which led to the memory window in EMC to be 1/4
of the real flash size. This was fixed in the next service pack but ...
I had to fix it by hand before then. Though in this particular case
the hardware design was in perfect sync with MHS ;)

> For example, turning on the MMU had us racking our brains to figure
> out why it wasn't working as it should - turned out the EDK design
> tool had itself out of sync. I've moaned at various people I've met
> from Xilinx that the overall tools are ok (xygwin causes nice issues
> with cygwin dlls sometimes and should come with basic utilities such
> as less and more) and I use them, but I won't be jumping for the
> notion of having their tool generate a BSP for my use because it's not
> the place of their tools to do this kind of thing IMO.
> 

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

> 
>>Do you use the mhs file for this?
> 
> 
> Effectively yes. I produce the equivalents by hand at the moment -
> there is an xparameters file for bits I don't care to change in
> generic drivers, but it's done by hand.
> 
> 
>>I guess you do not use what Xilinx calls "OS independent drivers" (== HAL?)
>>too then.
> 
> 
> I use them only for xsysace because I looked in to rewriting your
> driver to not do that but it would take too long. I'm still planning
> to rewrite it though to not use their HAL concept. It's a really bad
> idea to rely upon third party HAL code in the kernel itself and should
> not be done - instead the kernel needs to be able to be given
> parameters at run time and do the driver work itself. The xsysace
> adapter stuff it not pretty (though you guys did a good job, thanks)
> 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. IMHO more complex drivers
like ethernet in SGDMA mode is a problem: one needs to write
the code to handle the SGDMA IP, EMAC IP; then he needs to follow
the IP updates (they happen few times per year - the IP is a soft thing,
not a hardblock in silicon, and can easily be updated frequently).

> 
> 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 (this is a chip select
issue with P160 flash and xsysace sitting on the same bus - we do
not have HW engineer to do an IP to control the chip select inputs;
by default both are tied to ground - always selected).
With ML300 we've never seen this problem. 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.


Thanks,
Andrei