From: Andrei Konovalov <akonovalov@ru•mvista.com>
To: jonathan@jonmasters•org
Cc: Luca Giuliani <l.giuliani@tiscali•it>, linuxppc-embedded@ozlabs•org
Subject: Re: Linux on Memec Virtex II Pro V4P7 Rev. 3
Date: Wed, 06 Oct 2004 19:41:22 +0400 [thread overview]
Message-ID: <41641222.6080405@ru.mvista.com> (raw)
In-Reply-To: <35fb2e590410051507367017a@mail.gmail.com>
Jon Masters wrote:
> On Tue, 05 Oct 2004 20:05:29 +0400, Andrei Konovalov
> <akonovalov@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
next prev parent reply other threads:[~2004-10-06 15:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-05 11:26 Linux on Memec Virtex II Pro V4P7 Rev. 3 Luca Giuliani
2004-10-05 14:12 ` Matt Porter
2004-10-05 15:15 ` Jon Masters
2004-10-05 16:05 ` Andrei Konovalov
2004-10-05 22:07 ` Jon Masters
2004-10-06 15:41 ` Andrei Konovalov [this message]
2004-10-07 1:03 ` Jon Masters
2004-10-07 22:34 ` Tony Lee
2004-10-08 0:12 ` Jon Masters
2004-10-08 2:53 ` Tony Lee
2004-10-09 19:27 ` Jon Masters
2004-10-10 4:26 ` Tony Lee
2004-10-10 22:20 ` Jon Masters
-- strict thread matches above, loose matches on Subject: below --
2004-10-05 16:34 [MailServer Resend]Resending quarantined email -- use caution when opening.Re: " Administrator
2004-10-05 17:00 ` Ralph Siemsen
2005-03-24 19:01 Nguyen, Tony (US SSA)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41641222.6080405@ru.mvista.com \
--to=akonovalov@ru$(echo .)mvista.com \
--cc=jonathan@jonmasters$(echo .)org \
--cc=l.giuliani@tiscali$(echo .)it \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox