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
