[MailServer Resend]Resending quarantined email -- use caution when opening.Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[MailServer Resend]Resending quarantined email -- use caution when opening.Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Administrator]

[-- Attachment #1.1: Type: text/plain, Size: 350 bytes --]

Warning: Attachment contains virus code or meets the filtering/blocking rules.  Use caution when accessing the contents.

----- Original Message Header -----
Subject: Re: Linux on Memec Virtex II Pro V4P7 Rev. 3
From: Jon Masters
To: Luca Giuliani
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
-----------------------------------

[-- Attachment #1.2: Type: text/html, Size: 966 bytes --]

[-- Attachment #2: Type: message/rfc822, Size: 2753 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 177 bytes --]

REMOVED_BY_THE_EXCHANGE_CONTENT_SCANNING_SERVICE_5CAE6CF4_00006d34_E
The original message content contained a virus or was blocked due to blocking rules and has been removed.

[-- Attachment #2.1.2: Type: text/html, Size: 587 bytes --]

[-- Attachment #3: Msgbody1.doc --]
[-- Type: application/octet-stream, Size: 3090 bytes --]

[ Will followup only to linuxppc-embedded ]

On Tue, 5 Oct 2004 13:26:15 +0200, Luca Giuliani <l.giuliani@tiscali.it> wrote:

> I'm a newbie of Linux on embedded devices and I tried longly to make
> Linux work on the embedded PPC405 on the Memec Virtex II Prov V4P7 board

I have one of these boards which we base our platform upon.

> WITHOUT P160 module.

I use an SMC91111 on a custom ISA bodge - no P160 here but we do also
use xuart et al. (Why would you want to buy the Xilinx Ethernet MAC or
use the P160 anyway - who needs a second serial port :P).

> I'm using the patched 2.4.22 patched by Mind.be, freely available on
> their FTP site.

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. I'll
stick up my mods at some point (product not shipping at this moment so
this'll be done at some point before then).

> The boot process always freezes after the "Uncompressing Linux...done"

There's a bunch of problems with that board. You end up disabling the
ME reporting on those boards by bodging the MSR as you mentioned.
That's a bastard to figure out.

> The only way to make the kernel INITIATE the boot process was to modify
> the MSR mask (/include/asm-ppc/processor.h) as to disable the Machine
> Check, but this is not a good idea!

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

> The first thing that came to my mind was that there was an error in the
> hardware design, but it was auto-generated with the "Base platform
> builder" wizard included in EDK 6.2 and then customized only to meet the
> requirements of the Mind kernel.

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.

> Has someone succeeded in booting Linux on this device WITHOUT P160
> expansion card?

Yes. Spam me.

> If so I kindly ask you to answer me privately, at least to know how you
> built the hardware design, which kernel did you use and which are the
> vital parameters to be set in the kernel.

A custom 2.4.23 based purely on the stock kernel from kernel.org. I
use a few Mind patches, some stuff from the Monta tree and a bunch of
hacks I did myself. It boots using my own firmware which is in the
hardware image on the SystemACE and runs with a root RAMdisk off the
sysace (but you need to use my nointr sysace patch for this board).

I can help you with generalities but for various commerical reasons
there's a limit to how much I can talk about here or in private mail
concerning our specific design.

Cheers,

Jon.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Ralph Siemsen]

Sorry folks... I am trying to get our IT department to turn off their 
scanning software, or to configure it correctly... I am hoping not to 
have to resort to subscribing from my non-work address but it might just 
come to that.

And now back to regularly scheduled embedded discussions.

-R

Linux on Memec Virtex II Pro V4P7 Rev. 3

[Nguyen, Tony (US SSA)]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

Hello,

 

I saw one of your posting on the web regarding writing to a compact
flash on the Virtex II Pro V4P7 board.  A problem that was encountered

Was that the ISR needed to be disabled.  I saw that you had a patch to
fix this problem. ( nointr sysace patch).  I would be greatly
appreciated if 

Could send or let me know where if could find this patch.

 

Would greatly appreciate your help.

 

Tony.  


[-- Attachment #2: Type: text/html, Size: 2260 bytes --]

Linux on Memec Virtex II Pro V4P7 Rev. 3

[Luca Giuliani]

I'm a newbie of Linux on embedded devices and I tried longly to make
Linux work on the embedded PPC405 on the Memec Virtex II Prov V4P7 board
WITHOUT P160 module.
I'm using the patched 2.4.22 patched by Mind.be, freely available on
their FTP site.
The boot process always freezes after the "Uncompressing Linux...done"
i.e. after the bootloader has given the control to the uncompressed
kernel.
By making a long step-by-step debugging I found out that the problem was
due to a "Machine check" exception happining in various points (yes, not
always the same!) in memset when zeroing the BSS in early_init.
The only way to make the kernel INITIATE the boot process was to modify
the MSR mask (/include/asm-ppc/processor.h) as to disable the Machine
Check, but this is not a good idea!
The first thing that came to my mind was that there was an error in the
hardware design, but it was auto-generated with the "Base platform
builder" wizard included in EDK 6.2 and then customized only to meet the
requirements of the Mind kernel.
Has someone succeeded in booting Linux on this device WITHOUT P160
expansion card?
If so I kindly ask you to answer me privately, at least to know how you
built the hardware design, which kernel did you use and which are the
vital parameters to be set in the kernel.

Thanks in advance for your invaluable advice.

Luca

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Matt Porter]

On Tue, Oct 05, 2004 at 01:26:15PM +0200, Luca Giuliani wrote:
> I'm a newbie of Linux on embedded devices and I tried longly to make
> Linux work on the embedded PPC405 on the Memec Virtex II Prov V4P7 board
> WITHOUT P160 module.

Hello, this is on the wrong list, it should be on linuxppc-embedded.

http://ozlabs.org/mailman/listinfo/linuxppc-embedded

-Matt

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Jon Masters]

[ Will followup only to linuxppc-embedded ]

On Tue, 5 Oct 2004 13:26:15 +0200, Luca Giuliani <l.giuliani@tiscali.it> wrote:

> I'm a newbie of Linux on embedded devices and I tried longly to make
> Linux work on the embedded PPC405 on the Memec Virtex II Prov V4P7 board

I have one of these boards which we base our platform upon.

> WITHOUT P160 module.

I use an SMC91111 on a custom ISA bodge - no P160 here but we do also
use xuart et al. (Why would you want to buy the Xilinx Ethernet MAC or
use the P160 anyway - who needs a second serial port :P).

> I'm using the patched 2.4.22 patched by Mind.be, freely available on
> their FTP site.

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. I'll
stick up my mods at some point (product not shipping at this moment so
this'll be done at some point before then).

> The boot process always freezes after the "Uncompressing Linux...done"

There's a bunch of problems with that board. You end up disabling the
ME reporting on those boards by bodging the MSR as you mentioned.
That's a bastard to figure out.

> The only way to make the kernel INITIATE the boot process was to modify
> the MSR mask (/include/asm-ppc/processor.h) as to disable the Machine
> Check, but this is not a good idea!

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

> The first thing that came to my mind was that there was an error in the
> hardware design, but it was auto-generated with the "Base platform
> builder" wizard included in EDK 6.2 and then customized only to meet the
> requirements of the Mind kernel.

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.

> Has someone succeeded in booting Linux on this device WITHOUT P160
> expansion card?

Yes. Spam me.

> If so I kindly ask you to answer me privately, at least to know how you
> built the hardware design, which kernel did you use and which are the
> vital parameters to be set in the kernel.

A custom 2.4.23 based purely on the stock kernel from kernel.org. I
use a few Mind patches, some stuff from the Monta tree and a bunch of
hacks I did myself. It boots using my own firmware which is in the
hardware image on the SystemACE and runs with a root RAMdisk off the
sysace (but you need to use my nointr sysace patch for this board).

I can help you with generalities but for various commerical reasons
there's a limit to how much I can talk about here or in private mail
concerning our specific design.

Cheers,

Jon.

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Andrei Konovalov]

Jon Masters wrote:
> [ Will followup only to linuxppc-embedded ]
> 
> On Tue, 5 Oct 2004 13:26:15 +0200, Luca Giuliani <l.giuliani@tiscali.it> wrote:
> 
> 
...
>>I'm using the patched 2.4.22 patched by Mind.be, freely available on
>>their FTP site.
> 
> 
> 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.

> 
...
> 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. With P160 COMM module though.
I've posted the patch last Friday, but it got into the bi_recs thread - my
fault (hopefully doesn't affect those not reading the archives).

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

Jon,
Do you use EDK for your desing?
If yes, how do you get the addresses etc from you design without using xparams?
Do you use the mhs file for this?
I guess you do not use what Xilinx calls "OS independent drivers" (== HAL?)
too then.

> 
...
 >

Thanks,
Andrei

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Jon Masters]

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

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

Re: 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@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

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Jon Masters]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrei Konovalov wrote:

|>> Do you use EDK for your desing?

jcm>> EDK gets used for bits of it but then treated as a black box which
jcm>> goes in to various other design tools. I don't rely upon any defines
jcm>> 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.

Thing is, EDK is good at certain things but Synplify and other tools are
much better at overal project design so we build the platform in EDK and
then treat it as a black box in a much larger design. I use a bunch of
scripts and the dummy.o type behaviour of a kernel build to bodge in my
own firmware with kernel and root initrd in a single image which can be
loaded by the sysace. It works better than most examples I have seen.

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

I'd like to but there are various reasons why that's impractical at the
moment - eventually I'm going to fix this and use the ported tools.
Certainly they could have done a much better job with xygwin as they
severely limit what I can script in some of my Makefiles.

|>> I guess you do not use what Xilinx calls "OS independent drivers" (==
|>> HAL?) too then.

jcm>> I use them only for xsysace because I looked in to rewriting your
jcm>> driver to not do that but it would take too long. I'm still planning
jcm>> to rewrite it though to not use their HAL concept. It's a really bad
jcm>> idea to rely upon third party HAL code in the kernel itself and should
jcm>> not be done - instead the kernel needs to be able to be given
jcm>> parameters at run time and do the driver work itself. The xsysace
jcm>> adapter stuff it not pretty (though you guys did a good job, thanks)
jcm>> 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.

No it's not. But it does take more than an afternoon to get working
properly and I have other more pressing issues to sort first.

| IMHO more complex drivers like ethernet in SGDMA mode is a problem:

Yes. Luckily I wouldn't use the Xilinx ethernet MAC unless there were
few alternatives, since I've heard only negative things about it. It
apparently occupies a large amount of chip resources and has a few other
issues that have yet to be fully resolved, hardware MACs are cheap.

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

I thought you probably didn't. We/I have this cunning thought that very
few people are actually using sysace for read/write filesystems.

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

I spent a long time going through your driver code (where you is whoever
at Monta wrote it in combination with Xilinx) and can say that, while it
isn't pretty, I can't fault it. There's nothing in there which is
horribly buggy and wrong despite the xsa_thread concept which ac agrees
is a really bad idea in theory (but you end up having to use it to make
this xsysace driver work) :-).

Jon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBZJXxeTyyexZHHxERAv3eAJ9/w42mIMEG0ghJBx7+BKu8GooB6ACcC+KQ
5G3HoMvX8a4cW+YbGIUgMZU=
=8FCM
-----END PGP SIGNATURE-----

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Tony Lee]

On Wed, 06 Oct 2004 19:41:22 +0400, Andrei Konovalov
<akonovalov@ru.mvista.com> wrote:
> Jon Masters wrote:
> > On Tue, 05 Oct 2004 20:05:29 +0400, Andrei Konovalov
> > <akonovalov@ru.mvista.com> wrote:
> >
> >
> > 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.
> 

I have to use the non-interrupt mode in sysace.  I thought there were some
HW issue in our HW board (no ML 300).   Good to know other have the 
same problem.   We don't have ML300, otherwise, I will run the 
kernel with printk in the sysace driver to see that system ISR behavior
on write.  The problem I had was: I can not turn off the ISR when write
to the system (nor when send ID drive command).

 
Jon,  what kind of performance you got from the sysace?

When I copy 18 MB of ace file into sysace with Linux, the 
sync command took minutes to complete for me.

Sysace ISR should not be the issue, since there is no seeks
and all the IO is dirven from the kernel.


-- 
-Tony

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Jon Masters]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tony Lee wrote:

| I have to use the non-interrupt mode in sysace.

If necessary I will modify the quick patch I posted to use a CONFIG
option but several of us are seeing problems with interrupts - I will
change it to be the most useful for everyone, I suppose that means
making it an option.

| Jon,  what kind of performance you got from the sysace?

Crap. That's a technical term. The chip IMO has some fundamental issues
which really need to get resolved in a rev - it takes on the order of
several minutes to commit writes with a sync however we rarely have to
write to the flash and usually only store small parameter files.

| When I copy 18 MB of ace file into sysace with Linux, the
| sync command took minutes to complete for me.

Where this affects you and I is likely in writes to update the hardware
image with a new one that you have sent to the customer as a "firmware
upgrade" to be installed. It takes ages for me too - but this is a rare
enough thing that we can live with it for the moment.

| Sysace ISR should not be the issue, since there is no seeks
| and all the IO is dirven from the kernel.

The polled approach is worse IMO although I agree that there is very
little overhead in the actual ISR. Where the author went wrong (well
perhaps not wrong per se but didn't provide enough protection) was in
the unlikely case that the hardware is braindead and generates
interrupts that you didn't ask it to - the xsysace driver should also
catch interrupts when we're QUEUE_EMPTY and should not try to manipulate
an empty request queue.

Jon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBZduDeTyyexZHHxERArI0AJ9zd7sRSnO6dZBYw/G3NpuqjNqe7wCgixC0
/eRaHY5fhfUVW7TAFRtCrQM=
=3n0G
-----END PGP SIGNATURE-----

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Tony Lee]

On Fri, 08 Oct 2004 01:12:51 +0100, Jon Masters <jonathan@jonmasters.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> > 
> The polled approach is worse IMO although I agree that there is very
> little overhead in the actual ISR. Where the author went wrong (well
> perhaps not wrong per se but didn't provide enough protection) was in
> the unlikely case that the hardware is braindead and generates
> interrupts that you didn't ask it to - the xsysace driver should also
> catch interrupts when we're QUEUE_EMPTY and should not try to manipulate
> an empty request queue.
> 
> Jon.

The problem I saw was that I can't turn off the interrupt at all.
Once I start one write command, the ISR keep coming in.
I review the verilog code and schematic multiple times with the
HW group but can't figure out what went wrong.   My best
guess was the BUFRDY line is mix up with the ISR line some
how when write cmd and when IDEN drive command is issued.  

I try turn off the ISR on write with SYSACE register and 
the ppc interrupt control register.  None of them worked.

Jon, 

Do you think if we add a small DMA engine would help
the performance or the performance problem is caused
by the sysace firmware + the CF disk?

The sysace controller IS VERY fast on loading the bitstream
and linux boot image.


-- 
-Tony
Having a lot of fun with Xilinx Virtex Pro II reconfigurable HW + ppc + Linux

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Jon Masters]

On Thu, 7 Oct 2004 19:53:52 -0700, Tony Lee <tony.p.lee@gmail.com> wrote:

> The problem I saw was that I can't turn off the interrupt at all.

On the Memec board? really?

> Once I start one write command, the ISR keep coming in.

Ouch.

> I review the verilog code and schematic multiple times with the
> HW group but can't figure out what went wrong.

We had to move one of the sysace lines to a different bank on the v2p
but that was because we were cunningly running out of particular IO
lines (the v2p does different signalling and voltages on different
banks - I didn't make the modification as I don't work on the hardware
directly, just mess with Xilinx hardware stuff in my spare time and
software for them when at work :-) ).

> My best guess was the BUFRDY line is mix up with the ISR line

Perhaps. But that's down to your hardware guys to check the error
output from your synthesis tool to see if this weirdly has happened.
Our board doesn't have lines hard tied together, if that was the
notion you were offering.

> I try turn off the ISR on write with SYSACE register and
> the ppc interrupt control register.  None of them worked.

Did you do it as per my patch, or what?

> Do you think if we add a small DMA engine would help
> the performance or the performance problem is caused
> by the sysace firmware + the CF disk?

Perhaps. I'll have a think about that - I'm certainly not going to get
paid to do that, and until I can buy a v2p board for home or have some
spare time in the office, it'll have to wait for an implementation.
Kind of like porting to 2.6 and a whole bunch of other non-comercially
useful things I want to do with this thing :-).

> The sysace controller IS VERY fast on loading the bitstream
> and linux boot image.

Yes. We come up in 8 seconds to my firmware, and total boot time is
around 20 seconds, without any effort to make it less. That includes
cunning DHCP+ZeroConf scripts I wrote.

Jon.

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Tony Lee]

On Sat, 9 Oct 2004 20:27:15 +0100, Jon Masters <jonmasters@gmail.com> wrote:
> On Thu, 7 Oct 2004 19:53:52 -0700, Tony Lee <tony.p.lee@gmail.com> wrote:
> 
> > The problem I saw was that I can't turn off the interrupt at all.
> 
> On the Memec board? really?
> 

No, not on Memec,  just on our own HW.    I have the memec board, but
I don't have time to play on that one.   I got to debug the HW one week after
I was hired.    As far as I can tell, our linux for memec board doesn't load
the sysace driver.


> > Once I start one write command, the ISR keep coming in.
> 
> Ouch.

Tell me about it.  It tooks me 3+ days to id this.

> Perhaps. But that's down to your hardware guys to check the error
> output from your synthesis tool to see if this weirdly has happened.
> Our board doesn't have lines hard tied together, if that was the
> notion you were offering.

I tried to synthesize chipscope into into our VP20.  But don't have
much time for it now.  It is less of a priority since the sysace is working 
now for 1.5 months (without ISR).  Also, we use linux as Xilinux dev environment
but the chipscope only work in Windows platform.  Our HW folks
don't have time to touch Windows side of Xilinx tools.  It make it
more difficult to debug SW/HW integration issue.


> 
> > I try turn off the ISR on write with SYSACE register and
> > the ppc interrupt control register.  None of them worked.
> 
> Did you do it as per my patch, or what?

No, where can I find your patch?

> 
> Yes. We come up in 8 seconds to my firmware, and total boot time is
> around 20 seconds, without any effort to make it less. That includes
> cunning DHCP+ZeroConf scripts I wrote.
> 

That's about right,  We don't do DHCP, it comes up a bit faster.

-- 
-Tony
Having a lot of fun with Xilinx Virtex Pro II reconfigurable HW + ppc + Linux

Re: Linux on Memec Virtex II Pro V4P7 Rev. 3

[Jon Masters]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tony Lee wrote:

| On Sat, 9 Oct 2004 20:27:15 +0100, Jon Masters <jonmasters@gmail.com>
wrote:
|
|>On Thu, 7 Oct 2004 19:53:52 -0700, Tony Lee <tony.p.lee@gmail.com> wrote:
|>
|>
|>>The problem I saw was that I can't turn off the interrupt at all.
|>
|>On the Memec board? really?

| No, not on Memec,  just on our own HW.

Ah ok. Like you said, it's probably tied lines probably in the hardware
definition at fault here.

| I have the memec board, but I don't have time to play on that one.

Ah ok. I have a wonderful mixture of Memec and custom board also.

| I got to debug the HW one week after I was hired.

Indeed. Fun huh.

| As far as I can tell, our linux for memec board doesn't load
| the sysace driver.

Ok if you're not using it I guess.

|>>Once I start one write command, the ISR keep coming in.

|>Ouch.

| Tell me about it.  It tooks me 3+ days to id this.

It's taken me a long time on and off to fix these kinds of problem
because of the usual case of balancing other bits and pieces.

|>Perhaps. But that's down to your hardware guys to check the error
|>output from your synthesis tool to see if this weirdly has happened.
|>Our board doesn't have lines hard tied together, if that was the
|>notion you were offering.

| I tried to synthesize chipscope into into our VP20.

It apparently doesn't work if you're using sysace inline on the same
JTAG line that you want to use for chipscope interfacing. Having said
that I've not used chipscope other than seeing a very biref demo, and I
only heard this from a third party...so it might actually work ok.

| It is less of a priority since the sysace is working
| now for 1.5 months (without ISR).

I also have moved on to fixing other bits, bodging in a NULL ioctl in
smc91111.c to handle ethtool requests that aren't wanted, etc. Usual
case of fixing it up good enough for the current project and problem at
hand but wanting to find a better solution for next time around.

| Also, we use linux as Xilinux dev environment

We don't mostly for historical reasons, but I'm planning on moving the
development the way soon - I want this all nice and scriptable and this
just aint gonna be pretty on Windows. [OT] I just spent two hours on a
train with an MSFT employee sitting next to me...we didn't kill each
other but had a variety of interesting conversation.

|>>I try turn off the ISR on write with SYSACE register and
|>>the ppc interrupt control register.  None of them worked.

|>Did you do it as per my patch, or what?

| No, where can I find your patch?

In the list archives. It's only a quickie few lines, there's other stuff
I need to cleaup. Having mentioned that, I'm still working on the stuff
I mentioned in another thread on OpenFirmware tonight, having not got as
far as I planned this weekend. Less sleep tonight then.

|>Yes. We come up in 8 seconds to my firmware, and total boot time is
|>around 20 seconds, without any effort to make it less. That includes
|>cunning DHCP+ZeroConf scripts I wrote.

| That's about right,  We don't do DHCP, it comes up a bit faster.

I'd love to create a special interest group of Linux on Virtex II Pro
users - not really a mailing list, just a group of us who use it and are
willing to share experiences with eachother and perhaps newcomers as the
documentation for all of this is shockingly absent :-).

Jon.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBabWXeTyyexZHHxERAtB9AJ4yfwsoMfABgwtSB5hZfIRafuszrgCbBM83
UBVQN83pPbwi1PnMpFvCg+0=
=QH8A
-----END PGP SIGNATURE-----