[PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Joshua Kinard]

From: Joshua Kinard <kumba@gentoo.org>

This is a small patch to display the CPU byteorder that the kernel was compiled
with in /proc/cpuinfo.

Signed-off-by: Joshua Kinard <kumba@gentoo.org>
---
 arch/mips/kernel/proc.c |    5 +++++
 1 file changed, 5 insertions(+)

This patch has been submitted several times prior over the years (I think), but
I don't recall what, if any, objections there were to it.

linux-mips-proc-cpuinfo-byteorder.patch
diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c
index 097fc8d..75e6a62 100644
--- a/arch/mips/kernel/proc.c
+++ b/arch/mips/kernel/proc.c
@@ -65,6 +65,11 @@ static int show_cpuinfo(struct seq_file *m, void *v)
 	seq_printf(m, "BogoMIPS\t\t: %u.%02u\n",
 		      cpu_data[n].udelay_val / (500000/HZ),
 		      (cpu_data[n].udelay_val / (5000/HZ)) % 100);
+#ifdef __MIPSEB__
+	seq_printf(m, "byteorder\t\t: big endian\n");
+#else
+	seq_printf(m, "byteorder\t\t: little endian\n");
+#endif
 	seq_printf(m, "wait instruction\t: %s\n", cpu_wait ? "yes" : "no");
 	seq_printf(m, "microsecond timers\t: %s\n",
 		      cpu_has_counter ? "yes" : "no");

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[David Daney]

On 01/19/2015 01:02 AM, Joshua Kinard wrote:
> From: Joshua Kinard <kumba@gentoo.org>
>
> This is a small patch to display the CPU byteorder that the kernel was compiled
> with in /proc/cpuinfo.

What would use this?  Or in other words, why is this needed?

Userspace C code doesn't need this as it has its own standard ways of 
determining endianness.

If you need to know as a user you can do:

    readelf -h /bin/sh | grep Data | cut -d, -f2


>
> Signed-off-by: Joshua Kinard <kumba@gentoo.org>
> ---
>   arch/mips/kernel/proc.c |    5 +++++
>   1 file changed, 5 insertions(+)
>
> This patch has been submitted several times prior over the years (I think), but
> I don't recall what, if any, objections there were to it.
>
> linux-mips-proc-cpuinfo-byteorder.patch
> diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c
> index 097fc8d..75e6a62 100644
> --- a/arch/mips/kernel/proc.c
> +++ b/arch/mips/kernel/proc.c
> @@ -65,6 +65,11 @@ static int show_cpuinfo(struct seq_file *m, void *v)
>   	seq_printf(m, "BogoMIPS\t\t: %u.%02u\n",
>   		      cpu_data[n].udelay_val / (500000/HZ),
>   		      (cpu_data[n].udelay_val / (5000/HZ)) % 100);
> +#ifdef __MIPSEB__
> +	seq_printf(m, "byteorder\t\t: big endian\n");
> +#else
> +	seq_printf(m, "byteorder\t\t: little endian\n");
> +#endif
>   	seq_printf(m, "wait instruction\t: %s\n", cpu_wait ? "yes" : "no");
>   	seq_printf(m, "microsecond timers\t: %s\n",
>   		      cpu_has_counter ? "yes" : "no");
>
>
>

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Joshua Kinard]

On 01/20/2015 18:05, David Daney wrote:
> On 01/19/2015 01:02 AM, Joshua Kinard wrote:
>> From: Joshua Kinard <kumba@gentoo.org>
>>
>> This is a small patch to display the CPU byteorder that the kernel was compiled
>> with in /proc/cpuinfo.
> 
> What would use this?  Or in other words, why is this needed?

It was a patch I started including years ago in Gentoo's mips-sources, and just
never thought much about.  I know it was submitted several times in the past,
but I can't recall what, if any objection was ever made.  No harm in sending it
in again...


> Userspace C code doesn't need this as it has its own standard ways of
> determining endianness.
> 
> If you need to know as a user you can do:
> 
>    readelf -h /bin/sh | grep Data | cut -d, -f2

This would only tell you the endianness of the userland binary, not of the
kernel.  While they should be one and the same (otherwise, you're not going to
get very far anyways), they are, technically, distinctly different properties.

--J


>>
>> Signed-off-by: Joshua Kinard <kumba@gentoo.org>
>> ---
>>   arch/mips/kernel/proc.c |    5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> This patch has been submitted several times prior over the years (I think), but
>> I don't recall what, if any, objections there were to it.
>>
>> linux-mips-proc-cpuinfo-byteorder.patch
>> diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c
>> index 097fc8d..75e6a62 100644
>> --- a/arch/mips/kernel/proc.c
>> +++ b/arch/mips/kernel/proc.c
>> @@ -65,6 +65,11 @@ static int show_cpuinfo(struct seq_file *m, void *v)
>>       seq_printf(m, "BogoMIPS\t\t: %u.%02u\n",
>>                 cpu_data[n].udelay_val / (500000/HZ),
>>                 (cpu_data[n].udelay_val / (5000/HZ)) % 100);
>> +#ifdef __MIPSEB__
>> +    seq_printf(m, "byteorder\t\t: big endian\n");
>> +#else
>> +    seq_printf(m, "byteorder\t\t: little endian\n");
>> +#endif
>>       seq_printf(m, "wait instruction\t: %s\n", cpu_wait ? "yes" : "no");
>>       seq_printf(m, "microsecond timers\t: %s\n",
>>                 cpu_has_counter ? "yes" : "no");

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Joshua Kinard]

On 01/20/2015 21:45, Joshua Kinard wrote:
> On 01/20/2015 18:05, David Daney wrote:
>> On 01/19/2015 01:02 AM, Joshua Kinard wrote:
>>> From: Joshua Kinard <kumba@gentoo.org>
>>>
>>> This is a small patch to display the CPU byteorder that the kernel was compiled
>>> with in /proc/cpuinfo.
>>
>> What would use this?  Or in other words, why is this needed?
> 
> It was a patch I started including years ago in Gentoo's mips-sources, and just
> never thought much about.  I know it was submitted several times in the past,
> but I can't recall what, if any objection was ever made.  No harm in sending it
> in again...

Clarification, submitted several times in the past by others.  I think I sent
it in once prior, but never got review or feedback.


>> Userspace C code doesn't need this as it has its own standard ways of
>> determining endianness.
>>
>> If you need to know as a user you can do:
>>
>>    readelf -h /bin/sh | grep Data | cut -d, -f2
> 
> This would only tell you the endianness of the userland binary, not of the
> kernel.  While they should be one and the same (otherwise, you're not going to
> get very far anyways), they are, technically, distinctly different properties.
> 
> --J
> 

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Markos Chandras]

On 01/21/2015 02:54 AM, Joshua Kinard wrote:
> On 01/20/2015 21:45, Joshua Kinard wrote:
>> On 01/20/2015 18:05, David Daney wrote:
>>> On 01/19/2015 01:02 AM, Joshua Kinard wrote:
>>>> From: Joshua Kinard <kumba@gentoo.org>
>>>>
>>>> This is a small patch to display the CPU byteorder that the kernel was compiled
>>>> with in /proc/cpuinfo.
>>>
>>> What would use this?  Or in other words, why is this needed?
>>
>> It was a patch I started including years ago in Gentoo's mips-sources, and just
>> never thought much about.  I know it was submitted several times in the past,
>> but I can't recall what, if any objection was ever made.  No harm in sending it
>> in again...
> 
> Clarification, submitted several times in the past by others.  I think I sent
> it in once prior, but never got review or feedback.
> 
I believe this patch is mostly useful for cores that can boot in both LE
and BE so being able to tell the byteorder from cpuinfo can be helpful
at times. Having readelf and other tools in your userland may not always
be the case, but you surely have "cat" :)

So that patch looks good to me but i think the #ifdefs can be avoided.
Can we use

if (config_enabled(CONFIG_CPU_BIG_ENDIAN) {
} else {
}

stuff instead?

-- 
markos

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Joshua Kinard]

On 01/21/2015 05:22, Markos Chandras wrote:
> On 01/21/2015 02:54 AM, Joshua Kinard wrote:
>> On 01/20/2015 21:45, Joshua Kinard wrote:
>>> On 01/20/2015 18:05, David Daney wrote:
>>>> On 01/19/2015 01:02 AM, Joshua Kinard wrote:
>>>>> From: Joshua Kinard <kumba@gentoo.org>
>>>>>
>>>>> This is a small patch to display the CPU byteorder that the kernel was compiled
>>>>> with in /proc/cpuinfo.
>>>>
>>>> What would use this?  Or in other words, why is this needed?
>>>
>>> It was a patch I started including years ago in Gentoo's mips-sources, and just
>>> never thought much about.  I know it was submitted several times in the past,
>>> but I can't recall what, if any objection was ever made.  No harm in sending it
>>> in again...
>>
>> Clarification, submitted several times in the past by others.  I think I sent
>> it in once prior, but never got review or feedback.
>>
> I believe this patch is mostly useful for cores that can boot in both LE
> and BE so being able to tell the byteorder from cpuinfo can be helpful
> at times. Having readelf and other tools in your userland may not always
> be the case, but you surely have "cat" :)
> 
> So that patch looks good to me but i think the #ifdefs can be avoided.
> Can we use
> 
> if (config_enabled(CONFIG_CPU_BIG_ENDIAN) {
> } else {
> }
> 
> stuff instead?

Sure, I just tested on the Octane, and it works fine.  I'll send a v2 shortly.

--J

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Ralf Baechle]

On Wed, Jan 21, 2015 at 10:22:30AM +0000, Markos Chandras wrote:

> >>> What would use this?  Or in other words, why is this needed?
> >>
> >> It was a patch I started including years ago in Gentoo's mips-sources, and just
> >> never thought much about.  I know it was submitted several times in the past,
> >> but I can't recall what, if any objection was ever made.  No harm in sending it
> >> in again...
> > 
> > Clarification, submitted several times in the past by others.  I think I sent
> > it in once prior, but never got review or feedback.
> > 
> I believe this patch is mostly useful for cores that can boot in both LE
> and BE so being able to tell the byteorder from cpuinfo can be helpful
> at times. Having readelf and other tools in your userland may not always
> be the case, but you surely have "cat" :)
> 
> So that patch looks good to me but i think the #ifdefs can be avoided.
> Can we use
> 
> if (config_enabled(CONFIG_CPU_BIG_ENDIAN) {
> } else {
> }
> 
> stuff instead?

Exactly the code Joshua is submitting is what has been there until commit
874124ebb630 (Merge with Linux 2.4.15.) in 2001.  One reason to remove it
was that I had a prototype of a kernel supporting the execution of
application of native and the other byte order working and the field in
/proc/cpuinfo was plain lying in that case.  Not a terribly relevant
reason in retrospective but I'm wondering if just in case we should
rename the field to kernel_byteorder?

  Ralf

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[David Daney]

On 01/21/2015 05:49 AM, Ralf Baechle wrote:
> On Wed, Jan 21, 2015 at 10:22:30AM +0000, Markos Chandras wrote:
>
>>>>> What would use this?  Or in other words, why is this needed?
>>>>
>>>> It was a patch I started including years ago in Gentoo's mips-sources, and just
>>>> never thought much about.  I know it was submitted several times in the past,
>>>> but I can't recall what, if any objection was ever made.  No harm in sending it
>>>> in again...
>>>
>>> Clarification, submitted several times in the past by others.  I think I sent
>>> it in once prior, but never got review or feedback.
>>>
>> I believe this patch is mostly useful for cores that can boot in both LE
>> and BE so being able to tell the byteorder from cpuinfo can be helpful
>> at times. Having readelf and other tools in your userland may not always
>> be the case, but you surely have "cat" :)
>>
>> So that patch looks good to me but i think the #ifdefs can be avoided.
>> Can we use
>>
>> if (config_enabled(CONFIG_CPU_BIG_ENDIAN) {
>> } else {
>> }
>>
>> stuff instead?
>
> Exactly the code Joshua is submitting is what has been there until commit
> 874124ebb630 (Merge with Linux 2.4.15.) in 2001.  One reason to remove it
> was that I had a prototype of a kernel supporting the execution of
> application of native and the other byte order working and the field in
> /proc/cpuinfo was plain lying in that case.  Not a terribly relevant
> reason in retrospective but I'm wondering if just in case we should
> rename the field to kernel_byteorder?
>

This is kind of my reason for questioning adding this thing in the first 
place.

Any user of the data probably wouldn't be ready for the case you 
mention.  *And* the data is available from other sources.


>    Ralf
>

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Aaro Koskinen]

Hi,

On Wed, Jan 21, 2015 at 10:22:30AM +0000, Markos Chandras wrote:
> I believe this patch is mostly useful for cores that can boot in both LE
> and BE so being able to tell the byteorder from cpuinfo can be helpful
> at times. Having readelf and other tools in your userland may not always
> be the case, but you surely have "cat" :)
> 
> So that patch looks good to me but i think the #ifdefs can be avoided.
> Can we use
> 
> if (config_enabled(CONFIG_CPU_BIG_ENDIAN) {

Kernel has already support making whole .config available in /proc
where you can check such things.

A.

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[David Daney]

On 01/21/2015 10:38 AM, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Jan 21, 2015 at 10:22:30AM +0000, Markos Chandras wrote:
>> I believe this patch is mostly useful for cores that can boot in both LE
>> and BE so being able to tell the byteorder from cpuinfo can be helpful
>> at times. Having readelf and other tools in your userland may not always
>> be the case, but you surely have "cat" :)
>>
>> So that patch looks good to me but i think the #ifdefs can be avoided.
>> Can we use
>>
>> if (config_enabled(CONFIG_CPU_BIG_ENDIAN) {
>
> Kernel has already support making whole .config available in /proc
> where you can check such things.
>
You  mean like this?:

~ # zcat /proc/config.gz | grep 'CPU.*ENDIAN='
CONFIG_CPU_BIG_ENDIAN=y

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Maciej W. Rozycki]

On Tue, 20 Jan 2015, Joshua Kinard wrote:

> > Userspace C code doesn't need this as it has its own standard ways of
> > determining endianness.
> > 
> > If you need to know as a user you can do:
> > 
> >    readelf -h /bin/sh | grep Data | cut -d, -f2

 I tend to use `file /sbin/init' if I need to check it for some reason -- 
less typing. ;)

> This would only tell you the endianness of the userland binary, not of the
> kernel.  While they should be one and the same (otherwise, you're not going to
> get very far anyways), they are, technically, distinctly different properties.

 Well, several MIPS processors can reverse the user-mode endianness via 
the CP0.Status.RE bit; though as you may be aware it has never been 
implemented for Linux.  Otherwise it would obviously have to be a 
per-process property (and execve(2) could flip it back).

 What you may find more interesting, we actually used to include this 
information in /proc/cpuinfo, long ago, and I believe it was removed for 
the very reason of the existence of this reverse-endianness feature.  
Which I find sort of weak an argument given that we don't support this 
stuff anyway, but given the simple ways to extract this information from 
elsewhere (/proc/config.gz is another candidate place) I have doubts if 
having it in /proc/cpuinfo adds any value too.  Not that I'd object it 
strongly either though.

 See:

commit 874124ebb6309433a2e1acf1deb95baa1c34db0b
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Sun Dec 2 11:34:32 2001 +0000

    Merge with Linux 2.4.15.

-- which actually makes me wonder what happened here as Linus's 2.4.15 
change does not include any of this stuff.  Only 2.4.19 does, 8 months 
later -- a CVS to GIT conversion problem?

  Maciej

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Ralf Baechle]

On Mon, Jan 26, 2015 at 08:06:35AM +0000, Maciej W. Rozycki wrote:

> On Tue, 20 Jan 2015, Joshua Kinard wrote:
> 
> > > Userspace C code doesn't need this as it has its own standard ways of
> > > determining endianness.
> > > 
> > > If you need to know as a user you can do:
> > > 
> > >    readelf -h /bin/sh | grep Data | cut -d, -f2
> 
>  I tend to use `file /sbin/init' if I need to check it for some reason -- 
> less typing. ;)
> 
> > This would only tell you the endianness of the userland binary, not of the
> > kernel.  While they should be one and the same (otherwise, you're not going to
> > get very far anyways), they are, technically, distinctly different properties.
> 
>  Well, several MIPS processors can reverse the user-mode endianness via 
> the CP0.Status.RE bit; though as you may be aware it has never been 
> implemented for Linux.  Otherwise it would obviously have to be a 
> per-process property (and execve(2) could flip it back).

As posted previously that was why I removed it from /proc/cpuinfo.  And
yes, I had a simple prototype to use the RE feature.  Even in the limited
form I had it was impressively ugly and it became clear it would never
be upstreamable.

Right now MIPS is not making much use of sysfs.  Endian information and
other runtime CPU configuration probably should go there.  Detecting the
size and associativity of cache lines, changing the cache line size, more
control over VPEs in multithreaded kernels come to mind.

>  What you may find more interesting, we actually used to include this 
> information in /proc/cpuinfo, long ago, and I believe it was removed for 
> the very reason of the existence of this reverse-endianness feature.  
> Which I find sort of weak an argument given that we don't support this 
> stuff anyway, but given the simple ways to extract this information from 
> elsewhere (/proc/config.gz is another candidate place) I have doubts if 
> having it in /proc/cpuinfo adds any value too.  Not that I'd object it 
> strongly either though.
> 
>  See:
> 
> commit 874124ebb6309433a2e1acf1deb95baa1c34db0b
> Author: Ralf Baechle <ralf@linux-mips.org>
> Date:   Sun Dec 2 11:34:32 2001 +0000
> 
>     Merge with Linux 2.4.15.
> 
> -- which actually makes me wonder what happened here as Linus's 2.4.15 
> change does not include any of this stuff.  Only 2.4.19 does, 8 months 
> later -- a CVS to GIT conversion problem?

In those days I only sent patches upstream very rarely because committing
to CVS was easy - but extracting patches, breaking the up in useful patches
and submitting them upstream was so painful.  Honestly, the CVS archive
only began to be really useful after it was converted to git!

The conversion to git is as accurate as I possibly could do it and includes
the entire tarball and patch history as well as the linux-2.0 repository.
Linux 2.0 lived in a separate repository because it was created for
around 2.1.73 when it became clear that 2.2 was still going to take a
long time.  The conversion was done custom conversion tools due to the
limitations of the tools that were available at the time.

  Ralf

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Maciej W. Rozycki]

On Mon, 26 Jan 2015, Ralf Baechle wrote:

> >  Well, several MIPS processors can reverse the user-mode endianness via 
> > the CP0.Status.RE bit; though as you may be aware it has never been 
> > implemented for Linux.  Otherwise it would obviously have to be a 
> > per-process property (and execve(2) could flip it back).
> 
> As posted previously that was why I removed it from /proc/cpuinfo.  And
> yes, I had a simple prototype to use the RE feature.  Even in the limited
> form I had it was impressively ugly and it became clear it would never
> be upstreamable.

 Out of curiosity -- what was there that made it so ugly?  The need for 
case-by-case individual handling of byte-swapping the qualifying members 
of syscall and signal data structures such as `struct stat'?  Obviously 
not alignment trap fixups, these are trivial to handle.  And I think 
pretty much everything else is endianness-agnostic.

> Right now MIPS is not making much use of sysfs.  Endian information and
> other runtime CPU configuration probably should go there.  Detecting the
> size and associativity of cache lines, changing the cache line size, more
> control over VPEs in multithreaded kernels come to mind.

 That sounds reasonable to me.  I thought MT support was dropped though -- 
what do you mean in the latter case?

> >  See:
> > 
> > commit 874124ebb6309433a2e1acf1deb95baa1c34db0b
> > Author: Ralf Baechle <ralf@linux-mips.org>
> > Date:   Sun Dec 2 11:34:32 2001 +0000
> > 
> >     Merge with Linux 2.4.15.
> > 
> > -- which actually makes me wonder what happened here as Linus's 2.4.15 
> > change does not include any of this stuff.  Only 2.4.19 does, 8 months 
> > later -- a CVS to GIT conversion problem?
> 
> In those days I only sent patches upstream very rarely because committing
> to CVS was easy - but extracting patches, breaking the up in useful patches
> and submitting them upstream was so painful.  Honestly, the CVS archive
> only began to be really useful after it was converted to git!

 I know you only sent stuff to Linus for upstreaming every once in a while 
back then.  However, here I've been wondering why a change that clearly 
didn't originate from Linus's 2.4.15 ended up with the merge.  Pretty much 
nothing under arch/mips{,64} came from upstream back then, so any changes 
made there at the time of a merge would only be internal API adjustments 
required for interfacing generic code.  And a change made to /proc/cpuinfo 
clearly wasn't such one.

> The conversion to git is as accurate as I possibly could do it and includes
> the entire tarball and patch history as well as the linux-2.0 repository.
> Linux 2.0 lived in a separate repository because it was created for
> around 2.1.73 when it became clear that 2.2 was still going to take a
> long time.  The conversion was done custom conversion tools due to the
> limitations of the tools that were available at the time.

 Yeah, the big issue was to fold changes made to individual files (that 
CVS did track) back into changesets they were a part of (that CVS didn't 
track) -- i.e. what was supposed to have been included with a single `cvs 
commit' command.  I do remember there was a tool readily available that 
did that by grouping changes made close enough in time to one another; I 
think `cvsps'.  One limitation of course was the consequence of asking 
oneself a question: how close is close enough?  This was especially 
important for large commits, and of course independent of the tool used.

 And I agree that the history carried over from the old repo is much more 
useful these days than it originally was back in CVS.  Thank for going 
through the effort of converting it to GIT!

  Maciej

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[David Daney]

On 01/26/2015 06:53 AM, Maciej W. Rozycki wrote:
> On Mon, 26 Jan 2015, Ralf Baechle wrote:
>
>>>   Well, several MIPS processors can reverse the user-mode endianness via
>>> the CP0.Status.RE bit; though as you may be aware it has never been
>>> implemented for Linux.  Otherwise it would obviously have to be a
>>> per-process property (and execve(2) could flip it back).
>>
>> As posted previously that was why I removed it from /proc/cpuinfo.  And
>> yes, I had a simple prototype to use the RE feature.  Even in the limited
>> form I had it was impressively ugly and it became clear it would never
>> be upstreamable.
>
>   Out of curiosity -- what was there that made it so ugly?  The need for
> case-by-case individual handling of byte-swapping the qualifying members
> of syscall and signal data structures such as `struct stat'?  Obviously
> not alignment trap fixups, these are trivial to handle.  And I think
> pretty much everything else is endianness-agnostic.
>

I think *nothing* is endianness-agnostic.  The instruction set reference 
manual (MD00087 MIPS® Architecture For Programmers Volume II-A: The 
MIPS64® Instruction Set, Revision 5.02) is a little cryptic, but I think 
looking at the LB instruction shows how it works.  OCTEON is known to 
implement this and has been verified to work this way.

aligned 64-bit loads and stores are endianness invariant.

32-bit loads and stores have even and odd words swapped in the opposite 
endianness (low order 3 address bits are XOR 4).

16-bit loads and stores half words scrambled in the opposite endianness 
(low order 3 address bits are XOR 6).

8-bit loads and stores are scrambled such that the low order 3 address 
bits are XOR 7 in the opposite endianness.

The result that all byte array data is scrambled when switching endianness.

This means that all read(), write() and similar calls could *not* access 
the user data in-place in the kernel.  The kernel would have to  swap 
around the bytes before using it.  mmap() of the same file in processes 
of opposite endianness would be impossible, as one of the processes 
would see scrambled data.

For this reason, it really only makes sense to have the kernel and 
user-space use the same endianness.

And because kernel and userspace must have the same endianness, the 
endianness can be probed in userspace without consulting the kernel.

David Daney

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Maciej W. Rozycki]

On Mon, 26 Jan 2015, David Daney wrote:

> >   Out of curiosity -- what was there that made it so ugly?  The need for
> > case-by-case individual handling of byte-swapping the qualifying members
> > of syscall and signal data structures such as `struct stat'?  Obviously
> > not alignment trap fixups, these are trivial to handle.  And I think
> > pretty much everything else is endianness-agnostic.
> >
> 
> I think *nothing* is endianness-agnostic.  The instruction set reference
> manual (MD00087 MIPS® Architecture For Programmers Volume II-A: The MIPS64®
> Instruction Set, Revision 5.02) is a little cryptic, but I think looking at
> the LB instruction shows how it works.  OCTEON is known to implement this and
> has been verified to work this way.
> 
> aligned 64-bit loads and stores are endianness invariant.
> 
> 32-bit loads and stores have even and odd words swapped in the opposite
> endianness (low order 3 address bits are XOR 4).
> 
> 16-bit loads and stores half words scrambled in the opposite endianness (low
> order 3 address bits are XOR 6).
> 
> 8-bit loads and stores are scrambled such that the low order 3 address bits
> are XOR 7 in the opposite endianness.
> 
> The result that all byte array data is scrambled when switching endianness.

 But that does not matter as long as the endianness used for reads and one 
used for writes is the same.  Which is going to be the case for user 
software as long as it does not call into the kernel.  The two key points 
are syscalls and signals.  Ah, and the binary loader (e.g. ELF) has to 
byte-swap structures in executable and shared library headers too.

> This means that all read(), write() and similar calls could *not* access the
> user data in-place in the kernel.  The kernel would have to  swap around the
> bytes before using it.  mmap() of the same file in processes of opposite
> endianness would be impossible, as one of the processes would see scrambled
> data.

 Well, read(2), write(2) and similar calls operate on byte streams, these 
are endianness agnostic (like the text of this e-mail for example is -- 
it's stored in memory of a byte-addressed computer the same way regardless 
of its processor's endianness).  You're right about this specific use case 
of mmap(2), but why would you want sharing endianness-specific data 
between two processes of the opposite endiannesses in the first place?  
It's already no different to copying such a binary file between systems of 
the opposite endiannesses -- you need to use export/import tools and a 
portable data encoding format such as XDR or text.  This is how you can 
for example make RPC calls between systems of the opposite endiannesses.

 In the simplest scenario you'd run all your userland with the same 
endianness anyway -- e.g. because you want to validate your user software, 
but only have a machine whose bootstrap endianness is hardwired and cannot 
be set to match your requirement.

> For this reason, it really only makes sense to have the kernel and user-space
> use the same endianness.
> 
> And because kernel and userspace must have the same endianness, the endianness
> can be probed in userspace without consulting the kernel.

 Well, I maintain that it's only data structures passed around syscalls 
and signal handlers that matter here.  Their contents will be interpreted 
differently by the kernel and by user code and therefore have to be 
byte-swapped in transit.  There is no issue with integers passed via 
registers, that have no endianness defined.  And we are also lucky enough 
not to swap register pairs for double-precision integers depending on the 
endianness, unlike with ABIs for some other processor architectures.

  Maciej

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[David Daney]

On 01/26/2015 11:39 AM, Maciej W. Rozycki wrote:
> On Mon, 26 Jan 2015, David Daney wrote:
>
>>>    Out of curiosity -- what was there that made it so ugly?  The need for
>>> case-by-case individual handling of byte-swapping the qualifying members
>>> of syscall and signal data structures such as `struct stat'?  Obviously
>>> not alignment trap fixups, these are trivial to handle.  And I think
>>> pretty much everything else is endianness-agnostic.
>>>
>>
>> I think *nothing* is endianness-agnostic.  The instruction set reference
>> manual (MD00087 MIPS® Architecture For Programmers Volume II-A: The MIPS64®
>> Instruction Set, Revision 5.02) is a little cryptic, but I think looking at
>> the LB instruction shows how it works.  OCTEON is known to implement this and
>> has been verified to work this way.
>>
>> aligned 64-bit loads and stores are endianness invariant.
>>
>> 32-bit loads and stores have even and odd words swapped in the opposite
>> endianness (low order 3 address bits are XOR 4).
>>
>> 16-bit loads and stores half words scrambled in the opposite endianness (low
>> order 3 address bits are XOR 6).
>>
>> 8-bit loads and stores are scrambled such that the low order 3 address bits
>> are XOR 7 in the opposite endianness.
>>
>> The result that all byte array data is scrambled when switching endianness.
>
>   But that does not matter as long as the endianness used for reads and one
> used for writes is the same.  Which is going to be the case for user
> software as long as it does not call into the kernel.  The two key points
> are syscalls and signals.  Ah, and the binary loader (e.g. ELF) has to
> byte-swap structures in executable and shared library headers too.
>
>> This means that all read(), write() and similar calls could *not* access the
>> user data in-place in the kernel.  The kernel would have to  swap around the
>> bytes before using it.  mmap() of the same file in processes of opposite
>> endianness would be impossible, as one of the processes would see scrambled
>> data.
>
>   Well, read(2), write(2) and similar calls operate on byte streams, these
> are endianness agnostic (like the text of this e-mail for example is --
> it's stored in memory of a byte-addressed computer the same way regardless
> of its processor's endianness).

This is precisely the point I was attempting to make.  What you say here 
is *not* correct with respect to MIPS as specified in the architecture 
reference mentioned above.  The byte streams are scrambled up when 
viewed from contexts of opposite endianness.

Byte streams are *not* endian agnostic, but aligned 64-bit loads and 
stores are.

It is bizarre, and perhaps almost mind bending, but that seems to be how 
it is specified.  Certainly the OCTEON implementation works this way.


>  You're right about this specific use case
> of mmap(2), but why would you want sharing endianness-specific data
> between two processes of the opposite endiannesses in the first place?

The whole point is that the result of mmap() of a page of a file must 
yield the same contents as a read() of the same page.  The scrambling of 
byte streams would make any file containing ASCII text appear as 
gibberish when mmaped.


> It's already no different to copying such a binary file between systems of
> the opposite endiannesses -- you need to use export/import tools and a
> portable data encoding format such as XDR or text.  This is how you can
> for example make RPC calls between systems of the opposite endiannesses.
>
>   In the simplest scenario you'd run all your userland with the same
> endianness anyway -- e.g. because you want to validate your user software,
> but only have a machine whose bootstrap endianness is hardwired and cannot
> be set to match your requirement.
>
>> For this reason, it really only makes sense to have the kernel and user-space
>> use the same endianness.
>>
>> And because kernel and userspace must have the same endianness, the endianness
>> can be probed in userspace without consulting the kernel.
>
>   Well, I maintain that it's only data structures passed around syscalls
> and signal handlers that matter here.  Their contents will be interpreted
> differently by the kernel and by user code and therefore have to be
> byte-swapped in transit.  There is no issue with integers passed via
> registers, that have no endianness defined.  And we are also lucky enough
> not to swap register pairs for double-precision integers depending on the
> endianness, unlike with ABIs for some other processor architectures.
>
>    Maciej
>
>

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Maciej W. Rozycki]

On Mon, 26 Jan 2015, David Daney wrote:

> >   Well, read(2), write(2) and similar calls operate on byte streams, these
> > are endianness agnostic (like the text of this e-mail for example is --
> > it's stored in memory of a byte-addressed computer the same way regardless
> > of its processor's endianness).
> 
> This is precisely the point I was attempting to make.  What you say here is
> *not* correct with respect to MIPS as specified in the architecture reference
> mentioned above.  The byte streams are scrambled up when viewed from contexts
> of opposite endianness.
> 
> Byte streams are *not* endian agnostic, but aligned 64-bit loads and stores
> are.
> 
> It is bizarre, and perhaps almost mind bending, but that seems to be how it is
> specified.  Certainly the OCTEON implementation works this way.

 Well, I think this observation:

"2.2.2.2 Memory Operation Functions

"Regardless of byte ordering (big- or little-endian), the address of a 
halfword, word, or doubleword is the smallest byte address of the bytes 
that form the object.  For big-endian ordering this is the 
most-significant byte; for a little-endian ordering this is the 
least-significant byte."

contradicts your claim as it would not be possible to have all these 
quantities at once arranged such that the smallest byte address points at 
the quantity itself *and* the MSB or LSB for the big- and the 
little-endian memory interface byte ordering respectively *both* at a 
time.

 The implication of the above observation is that a 64-bit, 32-bit and 
16-bit values of 0xfedcba9876543210, 0x76543210 and 0x3210 respectively 
are for the individual memory interface endiannesses stored in memory like 
this:

         memory interface endiannesses          | memory
  big    little   big    little   big    little | address
------------------------------------------------+---------
  0x10    0xfe                                  |    7
  0x32    0xdc                                  |    6
  0x54    0xba                                  |    5
  0x76    0x98                                  |    4
  0x98    0x76    0x10    0x76                  |    3
  0xba    0x54    0x32    0x54                  |    2
  0xdc    0x32    0x54    0x32    0x10    0x32  |    1
  0xfe    0x10    0x76    0x10    0x32    0x10  |    0

This representation meets all the requirements set by 2.2.2.2 and makes 
the reverse-endian interpretation correct as well.

 And the supposedly bizarre physical address adjustment made by the LB, 
etc. pseudocode you refer to merely reflects the fact that (in the 64-bit 
case considered here) sub-doubleword addresses (i.e. the 3 LSBs) are 
presented on the SysAD bus with byte enables rather than via address 
lines.  This is clearly indicated in the description of `LoadMemory' and 
`StoreMemory' pseudocode:

"The low-order 2 (or 3) bits of the address and the AccessLength indicate 
which of the bytes within MemElem need to be passed to the processor."

 So given a 64-bit SysAD bus to load a byte from the bus/memory address 
0x00000000 a 0b00000001 logical bit pattern has to be driven on BE[7:0].  
And that pattern corresponds to CPU's physical address 0x00000000 in the 
native-endian load/store instruction mode, but 0x00000007 in the 
reverse-endian load/store instruction mode, because the doubleword 
location requested is swapped compared to how the memory interface has 
been configured (the `BigEndianMem' setting in the architecture spec).  
Hence the `XOR ReverseEndian' address adjustment made for the 
reverse-endianness mode.  And similarly for other sub-doubleword accesses; 
they'll have a higher number of byte enables asserted accordingly.

 So again, to illustrate, we have a 64-bit value of 0xfedcba9876543210 
stored at the bus/memory address 0x00000000 and will use LB to retrieve 
the byte at that address.  For the big memory interface endianness and a 
native access we have this:

BE:       BE7     BE6     BE5     BE4     BE3     BE2     BE1     BE0
memory:  0x10    0x32    0x54    0x76    0x98    0xba    0xdc    0xfe
           |       |       |       |       |       |       |       |
            \       \       \       \     /       /       /       /
             \       \       \       \   /       /       /       /
              ------------------------\ /------------------------
                                       X
              ------------------------/ \------------------------
             /       /       /       /   \       \       \       \
            /       /       /       /     \       \       \       \
           |       |       |       |       |       |       |       |
buffer:  0xfe    0xdc    0xba    0x98    0x76    0x54    0x32    0x10
pAddr:     0       1       2       3       4       5       6       7

(forgive the inferior ASCII art, I hope the way lanes are swapped is 
clear).  So the byte at pAddr 0 in the buffer corresponds to 0xfe at BE0 
and consequently bus/memory address 0x00000000, as expected.  Now in the 
reverse-endian load/store instruction mode we have the lane swapping 
reconfigured in the memory interface so now things look like this:

BE:       BE7     BE6     BE5     BE4     BE3     BE2     BE1     BE0
memory:  0x10    0x32    0x54    0x76    0x98    0xba    0xdc    0xfe
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
buffer:  0x10    0x32    0x54    0x76    0x98    0xba    0xdc    0xfe
pAddr:     0       1       2       3       4       5       6       7

Of course (on a byte-addressed machine) byte addresses are the same 
regardless of the endianness, so we still want to retrieve the 0xfe byte 
at BE0.  But that now corresponds to pAddr 7!

 For the little-endian memory interface mode things are reversed 
respectively and for the native mode we have:

BE:       BE7     BE6     BE5     BE4     BE3     BE2     BE1     BE0
memory:  0xfe    0xdc    0xba    0x98    0x76    0x54    0x32    0x10
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
           |       |       |       |       |       |       |       |
buffer:  0xfe    0xdc    0xba    0x98    0x76    0x54    0x32    0x10
pAddr:     7       6       5       4       3       2       1       0

and for the reverse-endian one:

BE:       BE7     BE6     BE5     BE4     BE3     BE2     BE1     BE0
memory:  0xfe    0xdc    0xba    0x98    0x76    0x54    0x32    0x10
           |       |       |       |       |       |       |       |
            \       \       \       \     /       /       /       /
             \       \       \       \   /       /       /       /
              ------------------------\ /------------------------
                                       X
              ------------------------/ \------------------------
             /       /       /       /   \       \       \       \
            /       /       /       /     \       \       \       \
           |       |       |       |       |       |       |       |
buffer:  0x10    0x32    0x54    0x76    0x98    0xba    0xdc    0xfe
pAddr:     7       6       5       4       3       2       1       0

-- so again we have to use pAddr 7 to get at BE0/0x10.

 Notice that this physical address adjustment is then cancelled by making 
a reverse `XOR BigEndianCPU' adjustment in calculating the byte offset for 
the sub-doubleword value to extract from the intermediate doubleword 
buffer used by the pseudocode (where `BigEndianCPU' is calculated as 
`BigEndianMem XOR ReverseEndian', as defined by Table 1.1 "Symbols Used in 
Instruction Operation Statements").  So referring to the examples above, 
the leftmost byte is extracted from the buffer in the reverse-endian mode 
rather than the rightmost one as it would in the native mode.  Again, this 
makes things work as intended, and makes any byte stream stored in memory 
endianness-agnostic.

 So I don't exactly know what you did with the Octeon implementation, but 
I do hope you did the sane thing.

  Maciej

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[David Daney]

On 01/27/2015 08:15 AM, Maciej W. Rozycki wrote:
> On Mon, 26 Jan 2015, David Daney wrote:
>
>>>    Well, read(2), write(2) and similar calls operate on byte streams, these
>>> are endianness agnostic (like the text of this e-mail for example is --
>>> it's stored in memory of a byte-addressed computer the same way regardless
>>> of its processor's endianness).
>>
>> This is precisely the point I was attempting to make.  What you say here is
>> *not* correct with respect to MIPS as specified in the architecture reference
>> mentioned above.  The byte streams are scrambled up when viewed from contexts
>> of opposite endianness.
>>
>> Byte streams are *not* endian agnostic, but aligned 64-bit loads and stores
>> are.
>>
>> It is bizarre, and perhaps almost mind bending, but that seems to be how it is
>> specified.  Certainly the OCTEON implementation works this way.
>
>   Well, I think this observation:
>
> "2.2.2.2 Memory Operation Functions
>
> "Regardless of byte ordering (big- or little-endian), the address of a
> halfword, word, or doubleword is the smallest byte address of the bytes
> that form the object.  For big-endian ordering this is the
> most-significant byte; for a little-endian ordering this is the
> least-significant byte."
>
> contradicts your claim [...]

One can argue about the meaning of the text in the reference manual. 
But in the end, the behavior of real processors is what we are forced to 
deal with.

In the case of all existing OCTEON processors, there is no Status[RE] 
bit, but you can switch the endianess of the entire CPU under software 
control.  I am really making statements based on how they actually work, 
not assertions about the meaning of the specification.  However, I do 
believe that this is what is specified.

If you have access to processors with a working Status[RE] bit, you 
could empirically determine how they work.

David Daney

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Maciej W. Rozycki]

On Tue, 27 Jan 2015, David Daney wrote:

> > > It is bizarre, and perhaps almost mind bending, but that seems to be how
> > > it is
> > > specified.  Certainly the OCTEON implementation works this way.
> >
> >   Well, I think this observation:
> >
> > "2.2.2.2 Memory Operation Functions
> >
> > "Regardless of byte ordering (big- or little-endian), the address of a
> > halfword, word, or doubleword is the smallest byte address of the bytes
> > that form the object.  For big-endian ordering this is the
> > most-significant byte; for a little-endian ordering this is the
> > least-significant byte."
> >
> > contradicts your claim [...]
> 
> One can argue about the meaning of the text in the reference manual. But in
> the end, the behavior of real processors is what we are forced to deal with.
> 
> In the case of all existing OCTEON processors, there is no Status[RE] bit, but
> you can switch the endianess of the entire CPU under software control.  I am
> really making statements based on how they actually work, not assertions about
> the meaning of the specification.  However, I do believe that this is what is
> specified.
> 
> If you have access to processors with a working Status[RE] bit, you could
> empirically determine how they work.

 Well, I do actually, I have a working machine driven by an R4000 
processor.  It was the original implementation of the Status.RE feature 
and therefore it can be used as the reference.  I don't feel tempted to 
use my time to actually make any checks though.

 What I did instead, I checked the R4000 manual and the descriptions there 
are exactly the same as in the current MIPS architecture manual, down to 
using the same names like `BigEndianMem' or `StoreMemory'.  Given that 
this is documentation that has been purposely prepared for a specific 
piece of silicon I have no reasons to believe it is inaccurate here.

 Furthermore, from your description, assuming that I understand it 
correctly, I infer that the reverse-endian mode as implemented by Octeon 
processors is completely useless and therefore a waste of silicon.  Given 
the circumstances if I was a processor architecture implementer and was 
feaced with a useless optional feature, I would have either omitted it 
entirely or implemented it in a different, useful manner, as a vendor 
extension.

 Given that as you say you don't wire it to Status.RE anyway, as the 
architecture standard mandates, this is already a vendor extension so I 
fail to see a reason to avoid doing it correctly from the usability point 
of view, and then reporting observations back to architecture maintainers 
so that they can be taken into account in a future revision of the 
architecture standard.

 The conclusion is if we ever decide to implement it for Linux, then we'll 
probably have to include a small run-time check that upon the bootstrap 
makes the kernel switch into the reverse-endian user mode temporarily, 
executes a small piece there that stores some immediate data to memory, 
then traps back into the kernel to verify the byte order of stored data is 
sane and decides if to make the feature available to user software, before 
moving on.

  Maciej

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Måns Rullgård]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:

> On Tue, 27 Jan 2015, David Daney wrote:
>
>> > > It is bizarre, and perhaps almost mind bending, but that seems to
>> > > be how it is specified.  Certainly the OCTEON implementation
>> > > works this way.
>> >
>> >   Well, I think this observation:
>> >
>> > "2.2.2.2 Memory Operation Functions
>> >
>> > "Regardless of byte ordering (big- or little-endian), the address of a
>> > halfword, word, or doubleword is the smallest byte address of the bytes
>> > that form the object.  For big-endian ordering this is the
>> > most-significant byte; for a little-endian ordering this is the
>> > least-significant byte."
>> >
>> > contradicts your claim [...]
>> 
>> One can argue about the meaning of the text in the reference manual. But in
>> the end, the behavior of real processors is what we are forced to deal with.
>> 
>> In the case of all existing OCTEON processors, there is no Status[RE]
>> bit, but you can switch the endianess of the entire CPU under
>> software control.  I am really making statements based on how they
>> actually work, not assertions about the meaning of the specification.
>> However, I do believe that this is what is specified.
>> 
>> If you have access to processors with a working Status[RE] bit, you could
>> empirically determine how they work.
>
>  Well, I do actually, I have a working machine driven by an R4000 
> processor.  It was the original implementation of the Status.RE feature 
> and therefore it can be used as the reference.  I don't feel tempted to 
> use my time to actually make any checks though.

Is it reasonably easy to test this on an R10000 (SGI Octane) running
IRIX 6.5?

-- 
Måns Rullgård
mans@mansr.com

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Maciej W. Rozycki]

On Thu, 5 Feb 2015, Måns Rullgård wrote:

> >> If you have access to processors with a working Status[RE] bit, you could
> >> empirically determine how they work.
> >
> >  Well, I do actually, I have a working machine driven by an R4000 
> > processor.  It was the original implementation of the Status.RE feature 
> > and therefore it can be used as the reference.  I don't feel tempted to 
> > use my time to actually make any checks though.
> 
> Is it reasonably easy to test this on an R10000 (SGI Octane) running
> IRIX 6.5?

 I doubt it.  I think the easiest way to experiment with this feature is 
to modify Linux so as to run its userland with CP0.Status.CU0 set to one 
(paying attention to the current use of the bit in the kernel) and then 
make the user program flip CP0.Status.RE itself.  According to the R10000 
manual a 0->1 transition is allowed for this bit in the user mode [1]:

"The Reverse-Endian (RE) bit, bit 25, reverses the endianness of the
machine.  The processor can be configured as either little-endian or
big-endian at system reset; reverse-endian selection is available in
Kernel and Supervisor modes, and in the User mode when the RE bit
is 0.  Setting the RE bit to 1 inverts the User mode endianness."

The same note is present in the R4000 manual too [2].  It's unclear to me 
from it if the reverse transition is allowed in the user mode, although 
I'd find it strange if it was not.

 Once you've got the bit flipped you can experiment, though beware of a 
COP0 hazard likely present here, the effect may not be immediate.  You can 
then safely call exit(2) to terminate the process as only registers have 
to be set appropriately to make this call and for registers endianness 
does not apply.

 HTH,

  Maciej

References:

[1] "MIPS R10000 Microprocessor User's Manual", Version 2.0, MIPS 
    Technologies, Inc., January 29, 1997, p. 247

[2] Joe Heinrich: "MIPS R4000 Microprocessor User's Manual", Second 
    Edition, MIPS Technologies, Inc., April 1, 1994, p. 105

  Maciej

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Måns Rullgård]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:

> On Thu, 5 Feb 2015, Måns Rullgård wrote:
>
>> >> If you have access to processors with a working Status[RE] bit, you could
>> >> empirically determine how they work.
>> >
>> >  Well, I do actually, I have a working machine driven by an R4000 
>> > processor.  It was the original implementation of the Status.RE feature 
>> > and therefore it can be used as the reference.  I don't feel tempted to 
>> > use my time to actually make any checks though.
>> 
>> Is it reasonably easy to test this on an R10000 (SGI Octane) running
>> IRIX 6.5?
>
>  I doubt it.  I think the easiest way to experiment with this feature is 
> to modify Linux so as to run its userland with CP0.Status.CU0 set to one 

Unfortunately, this machine doesn't have Linux installed, and I can't
find an easy way to change the status register for userspace under IRIX.

-- 
Måns Rullgård
mans@mansr.com

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[David Daney]

On 02/05/2015 05:46 AM, Maciej W. Rozycki wrote:
> On Tue, 27 Jan 2015, David Daney wrote:
>
>>>> It is bizarre, and perhaps almost mind bending, but that seems to be how
>>>> it is
>>>> specified.  Certainly the OCTEON implementation works this way.
>>>
>>>    Well, I think this observation:
>>>
>>> "2.2.2.2 Memory Operation Functions
>>>
>>> "Regardless of byte ordering (big- or little-endian), the address of a
>>> halfword, word, or doubleword is the smallest byte address of the bytes
>>> that form the object.  For big-endian ordering this is the
>>> most-significant byte; for a little-endian ordering this is the
>>> least-significant byte."
>>>
>>> contradicts your claim [...]
>>
>> One can argue about the meaning of the text in the reference manual. But in
>> the end, the behavior of real processors is what we are forced to deal with.
>>
>> In the case of all existing OCTEON processors, there is no Status[RE] bit, but
>> you can switch the endianess of the entire CPU under software control.  I am
>> really making statements based on how they actually work, not assertions about
>> the meaning of the specification.  However, I do believe that this is what is
>> specified.
>>
>> If you have access to processors with a working Status[RE] bit, you could
>> empirically determine how they work.
>
>   Well, I do actually, I have a working machine driven by an R4000
> processor.  It was the original implementation of the Status.RE feature
> and therefore it can be used as the reference.  I don't feel tempted to
> use my time to actually make any checks though.
>
>   What I did instead, I checked the R4000 manual  ...

You are still relying on your interpretation of the text, rather than 
actual behavior of the device.  It is not all surprising that your 
interpretation of the manual hasn't changed, but it doesn't persuade me.

I am sticking to my belief that OCTEON faithfully implements the 
specification with respect to the in-memory byte ordering of the various 
load and store instructions.  Switching the endianess of the processor 
results in byte arrays being scrambled such that the low-order 3 bits 
are XOR 7.  This implies that aligned 64-bit loads and stores (LD, SD, 
LLC, SCD) result in identical in-memory and in-register layout for 
either endianess.  This is quite handy when writing driver code for 
devices that have 64-bit registers.

[...]

David Daney

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Maciej W. Rozycki]

On Thu, 5 Feb 2015, David Daney wrote:

> >   Well, I do actually, I have a working machine driven by an R4000
> > processor.  It was the original implementation of the Status.RE feature
> > and therefore it can be used as the reference.  I don't feel tempted to
> > use my time to actually make any checks though.
> >
> >   What I did instead, I checked the R4000 manual  ...
> 
> You are still relying on your interpretation of the text, rather than actual
> behavior of the device.  It is not all surprising that your interpretation of
> the manual hasn't changed, but it doesn't persuade me.
> 
> I am sticking to my belief that OCTEON faithfully implements the specification
> with respect to the in-memory byte ordering of the various load and store
> instructions.  Switching the endianess of the processor results in byte arrays
> being scrambled such that the low-order 3 bits are XOR 7.  This implies that
> aligned 64-bit loads and stores (LD, SD, LLC, SCD) result in identical
> in-memory and in-register layout for either endianess.  This is quite handy
> when writing driver code for devices that have 64-bit registers.

 Fair enough, this helps interfacing fixed-endian peripherals such as a 
PCI bus.  Some MIPS-based SOCs map PCI/memory twice in the bus address 
space for the benefit of big-endian systems, once with a byte lane 
matching policy and again with a bit lane matching policy.  This results 
in a swapped memory view between the two mapping spaces as seen by PCI 
devices doing DMA.

 What you describe refers to the bit lane matching policy which has 
benefits for PIO and MMIO as values written to peripheral registers do not 
change with a host bus endianness change (as long as accesses are as you 
noted only made using a specific data width intended), in contrast to DMA 
where the byte lane matching policy makes more sense as it makes byte 
streams written to memory the same regardless of the host bus endianness.

 What does it have to do with the user mode though?  Device drivers do not 
usually run in the user mode and even if they do (such as X11 DDX), then 
what would be the benefit for them from running in the reverse-endian 
mode?  They'd have to cope with the rest of the environment being 
byte-swapped anyway.  Having say a MMIO resource mapped as a region 
configured in hardware for swapping with the bit lane matching policy 
would make more sense than having the whole user binary (here the X 
server) built for and run with the opposite endianness.

 The use of CP0.Status.RE is different and it has to be implemented such 
as to fulfil its purpose.  That for example may be running little-endian 
DEC Ultrix/MIPS user binaries under a foreign personality on a big-endian 
MIPS machine running SGI IRIX or Linux.  Of course with the demise of 
proprietary *nix systems for the MIPS processor such a feature seems 
little useful.

  Maciej

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Antony Pavlov]

On Tue, 20 Jan 2015 15:05:32 -0800
David Daney <ddaney.cavm@gmail.com> wrote:

> On 01/19/2015 01:02 AM, Joshua Kinard wrote:
> > From: Joshua Kinard <kumba@gentoo.org>
> >
> > This is a small patch to display the CPU byteorder that the kernel was compiled
> > with in /proc/cpuinfo.
> 
> What would use this?  Or in other words, why is this needed?

If you run some test software (e.g. in particular benchmarking software)
on a linux system then you are interisting in a log file with system information.
It's very likely that your log file keeps /proc/cpuinfo content.
So if your /proc/cpuinfo has byteorder information then your have system
byteorder information in your log file for free :)

If you write a bugreport and your attach /proc/cpuinfo content to it
then a bugreport reader have no question on byteorder.

> 
> Userspace C code doesn't need this as it has its own standard ways of 
> determining endianness.
> 
> If you need to know as a user you can do:
> 
>     readelf -h /bin/sh | grep Data | cut -d, -f2

Does this line really show your current CPU byteorder?

IMHO this 'readelf' method is not very reliable :)

> 
> 
> >
> > Signed-off-by: Joshua Kinard <kumba@gentoo.org>
> > ---
> >   arch/mips/kernel/proc.c |    5 +++++
> >   1 file changed, 5 insertions(+)
> >
> > This patch has been submitted several times prior over the years (I think), but
> > I don't recall what, if any, objections there were to it.
> >
> > linux-mips-proc-cpuinfo-byteorder.patch
> > diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c
> > index 097fc8d..75e6a62 100644
> > --- a/arch/mips/kernel/proc.c
> > +++ b/arch/mips/kernel/proc.c
> > @@ -65,6 +65,11 @@ static int show_cpuinfo(struct seq_file *m, void *v)
> >   	seq_printf(m, "BogoMIPS\t\t: %u.%02u\n",
> >   		      cpu_data[n].udelay_val / (500000/HZ),
> >   		      (cpu_data[n].udelay_val / (5000/HZ)) % 100);
> > +#ifdef __MIPSEB__
> > +	seq_printf(m, "byteorder\t\t: big endian\n");
> > +#else
> > +	seq_printf(m, "byteorder\t\t: little endian\n");
> > +#endif
> >   	seq_printf(m, "wait instruction\t: %s\n", cpu_wait ? "yes" : "no");
> >   	seq_printf(m, "microsecond timers\t: %s\n",
> >   		      cpu_has_counter ? "yes" : "no");
> >
> >
> >
> 
> 


-- 
-- 
Best regards,
  Antony Pavlov

Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo

[Joshua Kinard]

On 01/19/2015 04:02, Joshua Kinard wrote:
> From: Joshua Kinard <kumba@gentoo.org>
> 
> This is a small patch to display the CPU byteorder that the kernel was compiled
> with in /proc/cpuinfo.
> 
> Signed-off-by: Joshua Kinard <kumba@gentoo.org>
> ---
>  arch/mips/kernel/proc.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> This patch has been submitted several times prior over the years (I think), but
> I don't recall what, if any, objections there were to it.
> 

[much discussion later]
[snip]

So I assume final consensus is this patch (v1 or v2) isn't acceptable to
reintroduce this feature?  If so, I'll mark it as such in patchwork and just
continue to carry it locally in Gentoo's patchset.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic