From: Gabriel Paubert <paubert@iram.es>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linas@austin.ibm.com, valvoline <valvoline@vrlteam.org>,
linuxppc-dev@lists.linuxppc.org
Subject: Re: Broadcom BCM94306
Date: Fri, 16 Jan 2004 20:54:06 +0100 [thread overview]
Message-ID: <20040116195406.GA25566@iram.es> (raw)
In-Reply-To: <C404D01A-475A-11D8-A8C3-000A95A4DC02@kernel.crashing.org>
On Thu, Jan 15, 2004 at 02:00:16PM +0100, Segher Boessenkool wrote:
>
> >>Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
> >>mode
> >>at all.
> >
> >BTW, where did you find this? IBM's sites have no real documentation on
> >the 970, or I was too dumb to find them.
>
> I work for IBM. I did not realize this information wasn't
> publicly available -- if it isn't, and it's not just you.
The fact is that the documentation for the 970 is by far the
poorest from all the processors on IBM's website. I believed
IBM would release more information about these processors. Or
doesn't IBM really want to sell them?
Anyway, since you seem to have ties inside IBM ;-), you might
know why they do not even give a list of differences of the
970 implementation. I know from another source that the 970 does
not have BATs, but supports large pages with a size of 16MB.
>
> >It's more complex than this, because it is pseudo little endian,
> >munging
> >low address bits.
>
> It's not, afaics.
It's the case for all 603/604/7xx/7xxx processors.
>
> > The memory seen as an array of bytes is not invariant
> >through this transformation for most processors. For example the
> >character
> >chain "abcdefgh" copied from a kernel buffer through a read call will
> >look as "hgfedcba" from a little endian application.
>
> Representation depends on access size.
Indeed, but I said array of bytes, implying byte size accesses even
if it was not clear. However, I forgot to mention that it should be
an 8 byte array on a 8 byte boundary. This is the rule for all the
processors I have mentioned before.
>
> > Bridges have a
> >"LE" bit to also mung addresses during DMA and PIO transfers.
>
> Well yeah, PCI swizzling is awful and complicates the hell out
> of everything.
Well, if the processors switched to little endian with byte
invariant addressing, there would be no need for mode switching
control bits in the bridges, and it would be almost easy to
support a mixture of BE and LE applications (note that I said
"almost", but the only practical interest is for emulators).
>
> >But this makes it almost impossible to support a mixture of little and
> >bug endian applications. Indeed the ROM BIOS x86 emulator I wrote a
> >few years ago runs in big-endian mode and uses {l,st}[hw]brx
> >instructions
> >to emulate x86 crapitecture.
>
> That's how to normally access PCI as well, yeah.
>
> >P.S.: there is nothing wrong with calling little-endian wrong or
> >perverted or fucked-up ;-)
>
> I don't know if I trust you here -- you wrote "bug endian" just a few
> lines up ;-)
Damned laptop keyboards! U and I keys are just too close from each
other;-) Apart from this, if you look up some archives, you'll certainly
find that I think, live and breathe big-endianly ;-) (bit 0 is the most
significant bit, period)
Now the fact that the 970 does not support backwards-endian is a very
good thing. From time to time (although it has been less frequent
recently) somebody suggest on the list that Linux/PPC switches to the
dark side of the endianness. The fact that some processors don't support
it will be a killer argument.
Gabriel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-01-16 19:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-14 16:11 Broadcom BCM94306 valvoline
2004-01-15 0:13 ` linas
2004-01-15 9:30 ` Segher Boessenkool
2004-01-15 11:50 ` Gabriel Paubert
2004-01-15 13:00 ` Segher Boessenkool
2004-01-15 13:12 ` Sven Luther
2004-01-15 13:18 ` Segher Boessenkool
2004-01-16 19:54 ` Gabriel Paubert [this message]
2004-01-16 23:19 ` linas
2004-01-17 3:25 ` Benjamin Herrenschmidt
2004-01-17 18:21 ` Geert Uytterhoeven
2004-01-19 14:11 ` Segher Boessenkool
2004-01-19 22:05 ` Benjamin Herrenschmidt
2004-01-20 18:01 ` Segher Boessenkool
2004-01-21 17:27 ` Gabriel Paubert
2004-01-15 13:39 ` Colin Leroy
2004-01-16 22:09 ` Gabriel Paubert
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=20040116195406.GA25566@iram.es \
--to=paubert@iram.es \
--cc=linas@austin.ibm.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=segher@kernel.crashing.org \
--cc=valvoline@vrlteam.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).