All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Russell <caret@c-side.com>
To: Arto Vuori <avuori@ssh.com>, linuxppc-dev@lists.linuxppc.org
Subject: Re: 8260 io and caches
Date: Mon, 1 May 2000 10:19:16 -0700	[thread overview]
Message-ID: <20000501101916.E6832@lx.c-side.com> (raw)
In-Reply-To: <390DB320.DC787D62@ssh.com>; from Arto Vuori on Mon, May 01, 2000 at 07:38:56PM +0300


>From what I can see, the uart driver in the current linux source is written
for the 860, with no mods for the 8260.  The 8260 has some different bits
in the RFCR/TFCR parameter RAM fields.  There is a GBL bit (bit 2) that
enables cache snooping.

I'm looking at the 2.3.99-pre5 sources, at about line 2519 in uart.c:

	up->smc_rfcr = SMC_EB;
	up->smc_tfcr = SMC_EB;

change them to:

	up->smc_rfcr = SMC_EB | 0x20;
	up->smc_tfcr = SMC_EB | 0x20;

and see what happens.  Of course, you probably want to add a SMC_GBL
#define to do this properly.


Neil.


On Mon, May 01, 2000 at 07:38:56PM +0300, Arto Vuori wrote:
> I'm currently trying to get linux running on EST SBC8260 board. I had
> some problems with serial ports. Initially it just sent some garbage. I
> found that serial port driver doesn't initialize BRG division factor in
> SCCR register even though it assumes that it should be set to 0. I
> modified my bootloader to initialize it and output looks now much
> better.
>
> There still seems to be some problems with caches. Everything is just
> fine with caches disabled, but if i enable caches output doesn't look
> correct. Adding some flush_dcache_range() calls to uart.c seems to fix
> that problem, but shouldn't rx & tx buffers be allocated from some non
> cacheable region??

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  parent reply	other threads:[~2000-05-01 17:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-01 16:38 8260 io and caches Arto Vuori
2000-05-01 16:59 ` Dan Malek
2000-05-01 17:19 ` Neil Russell [this message]
2000-05-01 21:53   ` Dan Malek

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=20000501101916.E6832@lx.c-side.com \
    --to=caret@c-side.com \
    --cc=avuori@ssh.com \
    --cc=linuxppc-dev@lists.linuxppc.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.