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.
