Linux on Memec Virtex II Pro V4P7 Rev. 3

[Jon Masters]

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 ;-).

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

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.

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

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.

Cheers,

Jon.