All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Armin F. Gnosa" <mipslist@gnosa.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: <linux-mips@oss.sgi.com>
Subject: Re: Problem with PMAD-AA / DECStation 5000/200
Date: Fri, 10 Aug 2001 15:32:13 +0200	[thread overview]
Message-ID: <002601c121a0$de4f2fa0$237900d9@shodan> (raw)
In-Reply-To: Pine.GSO.3.96.1010810110057.2724F-100000@delta.ds2.pg.gda.pl

>  I'm not sure how exactly the ROMs are wired (they're usually 8-bit);
> hopefully in a "natural" way.  You can read most of ROMs under Linux via
> mmap()ping /dev/mem -- parts of ROMs may not be directly available to the
> host CPU if they contain option's CPU firmware.  The MB ROM is remapped
> (byte-merged) by the chipset so that it can be read in 32-bit quantities
> as parts of it get executed directly (the I/O ASIC permits switching the
> byte merging off).  Option ROMs are not remapped as they always get copied
> to the system RAM before execution.  Their organization can be read from
> their headers as specified by the TURBOchannel firmware specification.

That sounds like an interesting alternative to pulling the PROM out of
its socket. Then, a program running on a DECStation 5000/200 should be
reading from 0x1F81C0000..0x1F1FFFFF, right? One question about Byte
Merging: Does it mean that I don't have to read bytewise but instead
DWORD-wise?

Regards,
Armin

WARNING: multiple messages have this Message-ID (diff)
From: "Armin F. Gnosa" <mipslist@gnosa.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@oss.sgi.com
Subject: Re: Problem with PMAD-AA / DECStation 5000/200
Date: Fri, 10 Aug 2001 15:32:13 +0200	[thread overview]
Message-ID: <002601c121a0$de4f2fa0$237900d9@shodan> (raw)
Message-ID: <20010810133213.x_7__LFCZZlOfqhwbcKoMM8w8RJA1gZQiQc89WPvlfU@z> (raw)
In-Reply-To: Pine.GSO.3.96.1010810110057.2724F-100000@delta.ds2.pg.gda.pl

>  I'm not sure how exactly the ROMs are wired (they're usually 8-bit);
> hopefully in a "natural" way.  You can read most of ROMs under Linux via
> mmap()ping /dev/mem -- parts of ROMs may not be directly available to the
> host CPU if they contain option's CPU firmware.  The MB ROM is remapped
> (byte-merged) by the chipset so that it can be read in 32-bit quantities
> as parts of it get executed directly (the I/O ASIC permits switching the
> byte merging off).  Option ROMs are not remapped as they always get copied
> to the system RAM before execution.  Their organization can be read from
> their headers as specified by the TURBOchannel firmware specification.

That sounds like an interesting alternative to pulling the PROM out of
its socket. Then, a program running on a DECStation 5000/200 should be
reading from 0x1F81C0000..0x1F1FFFFF, right? One question about Byte
Merging: Does it mean that I don't have to read bytewise but instead
DWORD-wise?

Regards,
Armin

  reply	other threads:[~2001-08-10 13:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-09 15:35 Problem with PMAD-AA / DECStation 5000/200 Armin F. Gnosa
2001-08-09 15:35 ` Armin F. Gnosa
2001-08-09 15:51 ` Florian Lohoff
2001-08-09 16:20   ` Jan-Benedict Glaw
2001-08-09 16:22     ` Martin Schulze
2001-08-09 16:35       ` Jan-Benedict Glaw
2001-08-10  9:00         ` Maciej W. Rozycki
2001-08-10  9:10           ` Jan-Benedict Glaw
2001-08-10  9:11     ` Maciej W. Rozycki
2001-08-10 13:32       ` Armin F. Gnosa [this message]
2001-08-10 13:32         ` Armin F. Gnosa
2001-08-13 11:30         ` Maciej W. Rozycki
2001-08-10  0:29   ` Problems mounting RedHat 7.0 or 7.1 from oss.sgi site Wayne Gowcher
2001-08-10  4:55     ` H . J . Lu
2001-08-13 17:34       ` Benchmark performance Wayne Gowcher
2001-08-13 17:34         ` Wayne Gowcher
2001-08-14  7:51         ` Ralf Baechle
2001-08-14 15:29           ` Wayne Gowcher
2001-08-16  3:56         ` Atsushi Nemoto
2001-08-16  7:43           ` Carsten Langgaard
2001-08-16  9:11           ` Kevin D. Kissell
2001-08-16  9:11             ` Kevin D. Kissell
2001-08-16 11:06             ` Ralf Baechle
2001-08-16 11:15             ` Atsushi Nemoto
2001-08-16  9:18           ` Ralf Baechle
2001-08-16 11:07             ` Carsten Langgaard
2001-08-16 11:14               ` Ralf Baechle
2001-08-24  9:06                 ` Atsushi Nemoto
2001-08-24 18:27                   ` Ralf Baechle
2001-08-10  8:54   ` Problem with PMAD-AA / DECStation 5000/200 Armin F. Gnosa
2001-08-10  8:54     ` Armin F. Gnosa
2001-08-10 10:33     ` Florian Lohoff
2001-08-12 20:32       ` Ralf Baechle
2001-08-12 20:40         ` Armin F. Gnosa
2001-08-12 20:40           ` Armin F. Gnosa
2001-08-12 20:41         ` Jan-Benedict Glaw
2001-08-13  9:58           ` Ralf Baechle

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='002601c121a0$de4f2fa0$237900d9@shodan' \
    --to=mipslist@gnosa.com \
    --cc=linux-mips@oss.sgi.com \
    --cc=macro@ds2.pg.gda.pl \
    /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.