All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Konovalov <akonovalov@ru.mvista.com>
To: jonathan@jonmasters.org
Cc: akpm@osdl.org, linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH][PPC32] Xilinx ML300 board support (very basic)
Date: Mon, 11 Oct 2004 15:53:23 +0400	[thread overview]
Message-ID: <416A7433.4080605@ru.mvista.com> (raw)
In-Reply-To: <35fb2e5904100912409628a94@mail.gmail.com>

Jon Masters wrote:
> On Fri, 08 Oct 2004 21:23:01 +0400, Andrei Konovalov
> <akonovalov@ru.mvista.com> wrote:
> 
> 
>>Adds minimal Xilinx ML300 board support (enough to boot with ramdisk).
>>The only peripheral devices supported are 16x50 compatible UARTs.
>>
>>Signed-off-by: Andrei Konovalov <akonovalov@ru.mvista.com>
> 
> 
> I'll test this if I get chance soon.
> 

Great!

> 
>>        /*
>>-        * At one point, we were getting machine checks.  Linux was not
>>-        * invalidating the data cache before it was enabled.  The
>>-        * following code was added to do that.  Soon after we had done
>>-        * that, we found the real reasons for the machine checks.  I've
>>-        * run the kernel a few times with the following code
>>-        * temporarily removed without any apparent problems.  However,
>>-        * I objdump'ed the kernel and boot code and found out that
>>-        * there were no other dccci's anywhere, so I put the code back
>>-        * in and have been reluctant to remove it.  It seems safer to
>>-        * just leave it here.
>>+        * Invalidate the data cache if the data cache is turned off.
>>+        * - The 405 core does not invalidate the data cache on power-up
>>+        *   or reset but does turn off the data cache. We cannot assume
>>+        *   that the cache contents are valid.
>>+        * - If the data cache is turned on this must have been done by
>>+        *   a bootloader and we assume that the cache contents are
>>+        *   valid.
>>         */
> 
> 
> Er...the caveat about the MSR is still worth noting - I had this
> problem and for a while couldn't figure out why the fsck the board
> wouldn't come up with cacheing enabled (I've written patches for
> debugging that turn off various cacheing by modifying the pte macros,
> etc.) and *still* believe we're not clean from unwanted machine checks
> here. Just FYI.
> 

The code which follows the comment above works for me with both ML300
and the Memec 2VP7 boards I have.
Do you mean that some boards (or FPGA designs) need cacheing to be
disabled completely?

If this is the case, and you have the patch that handles this, I would
welcome that patch to follow mine.

Is there any chance for me to reproduce that problem on my site with
the hardware I have (1. ML300; 2. Memec 2VP7 board plus the COMM and the
System ACE modules)?

> 
...
> 
>>+*     This program is free software; you can redistribute it and/or modify it
>>+*     under the terms of the GNU General Public License as published by the
>>+*     Free Software Foundation; either version 2 of the License, or (at your
>>+*     option) any later version.
> 
> 
> ...and then:
> 
> 
>>+*     Xilinx hardware products are not intended for use in life support
>>+*     appliances, devices, or systems. Use in such applications is
>>+*     expressly prohibited.
> 
> 
> I've always loved it how Xilinx GPL disclaimers cunningly aren't. They
> might want to wake up and smell the coffee at some point.

I know this doesn't look good.
If it *does* prevent this code from getting into the kernel tree I could
try contacting Xilinx (doubt it will help though - they have already
changed the copyrights once to be more community friendly).

> 
> Andrei, you'll want to modify the ML300 xparameters stuff to allow
> it's location to be specified by a parameter. People who want to use
> (ewww, spit) autogenerated Xilinx xparameters.h from their EDK will
> probably also want to choose where it lives.
> 

Why renaming someone's autogenerated xparameters.h into xparameters_my_ml300.h
and placing it into arch/ppc/platforms/4xx/xparameters/,
defining CONFIG_XILINX_MY_ML300, and adding
few lines to include/asm-ppc/xparameters.h like:

#if defined(CONFIG_XILINX_ML300)
#include <platforms/4xx/xparameters/xparameters_ml300.h>
#endif

+#if defined(CONFIG_XILINX_MY_ML300)
+#include <platforms/4xx/xparameters/xparameters_my_ml300.h>
+#endif

doesn't work in your oppinion?

> 
...
> 
> Jon.
> 
> 

Thanks,
Andrei

  reply	other threads:[~2004-10-11 11:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-08 17:23 [PATCH][PPC32] Xilinx ML300 board support (very basic) Andrei Konovalov
2004-10-09 19:40 ` Jon Masters
2004-10-11 11:53   ` Andrei Konovalov [this message]
2004-10-11 12:23     ` Jon Masters
2004-10-11 15:19   ` Tom Rini
2004-10-11 16:23     ` Jon Masters

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=416A7433.4080605@ru.mvista.com \
    --to=akonovalov@ru.mvista.com \
    --cc=akpm@osdl.org \
    --cc=jonathan@jonmasters.org \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.