* [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo @ 2015-01-19 9:02 Joshua Kinard 2015-01-20 23:05 ` David Daney 2015-02-12 4:16 ` Joshua Kinard 0 siblings, 2 replies; 26+ messages in thread From: Joshua Kinard @ 2015-01-19 9:02 UTC (permalink / raw) To: Ralf Baechle; +Cc: Linux MIPS List 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"); ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-19 9:02 [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo Joshua Kinard @ 2015-01-20 23:05 ` David Daney 2015-01-21 2:45 ` Joshua Kinard 2015-01-21 6:50 ` Antony Pavlov 2015-02-12 4:16 ` Joshua Kinard 1 sibling, 2 replies; 26+ messages in thread From: David Daney @ 2015-01-20 23:05 UTC (permalink / raw) To: Joshua Kinard; +Cc: Ralf Baechle, Linux MIPS List 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"); > > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-20 23:05 ` David Daney @ 2015-01-21 2:45 ` Joshua Kinard 2015-01-21 2:54 ` Joshua Kinard 2015-01-26 8:06 ` Maciej W. Rozycki 2015-01-21 6:50 ` Antony Pavlov 1 sibling, 2 replies; 26+ messages in thread From: Joshua Kinard @ 2015-01-21 2:45 UTC (permalink / raw) To: David Daney; +Cc: Ralf Baechle, Linux MIPS List 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"); ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-21 2:45 ` Joshua Kinard @ 2015-01-21 2:54 ` Joshua Kinard 2015-01-21 10:22 ` Markos Chandras 2015-01-26 8:06 ` Maciej W. Rozycki 1 sibling, 1 reply; 26+ messages in thread From: Joshua Kinard @ 2015-01-21 2:54 UTC (permalink / raw) To: David Daney; +Cc: Ralf Baechle, Linux MIPS List 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-21 2:54 ` Joshua Kinard @ 2015-01-21 10:22 ` Markos Chandras 2015-01-21 11:26 ` Joshua Kinard ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Markos Chandras @ 2015-01-21 10:22 UTC (permalink / raw) To: Joshua Kinard, David Daney; +Cc: Ralf Baechle, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-21 10:22 ` Markos Chandras @ 2015-01-21 11:26 ` Joshua Kinard 2015-01-21 13:49 ` Ralf Baechle 2015-01-21 18:38 ` Aaro Koskinen 2 siblings, 0 replies; 26+ messages in thread From: Joshua Kinard @ 2015-01-21 11:26 UTC (permalink / raw) To: Markos Chandras, David Daney; +Cc: Ralf Baechle, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-21 10:22 ` Markos Chandras 2015-01-21 11:26 ` Joshua Kinard @ 2015-01-21 13:49 ` Ralf Baechle 2015-01-21 18:18 ` David Daney 2015-01-21 18:38 ` Aaro Koskinen 2 siblings, 1 reply; 26+ messages in thread From: Ralf Baechle @ 2015-01-21 13:49 UTC (permalink / raw) To: Markos Chandras; +Cc: Joshua Kinard, David Daney, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-21 13:49 ` Ralf Baechle @ 2015-01-21 18:18 ` David Daney 0 siblings, 0 replies; 26+ messages in thread From: David Daney @ 2015-01-21 18:18 UTC (permalink / raw) To: Ralf Baechle; +Cc: Markos Chandras, Joshua Kinard, Linux MIPS List 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-21 10:22 ` Markos Chandras 2015-01-21 11:26 ` Joshua Kinard 2015-01-21 13:49 ` Ralf Baechle @ 2015-01-21 18:38 ` Aaro Koskinen 2015-01-21 18:42 ` David Daney 2 siblings, 1 reply; 26+ messages in thread From: Aaro Koskinen @ 2015-01-21 18:38 UTC (permalink / raw) To: Markos Chandras; +Cc: Joshua Kinard, David Daney, Ralf Baechle, Linux MIPS List 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-21 18:38 ` Aaro Koskinen @ 2015-01-21 18:42 ` David Daney 0 siblings, 0 replies; 26+ messages in thread From: David Daney @ 2015-01-21 18:42 UTC (permalink / raw) To: Aaro Koskinen Cc: Markos Chandras, Joshua Kinard, Ralf Baechle, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-21 2:45 ` Joshua Kinard 2015-01-21 2:54 ` Joshua Kinard @ 2015-01-26 8:06 ` Maciej W. Rozycki 2015-01-26 13:16 ` Ralf Baechle 1 sibling, 1 reply; 26+ messages in thread From: Maciej W. Rozycki @ 2015-01-26 8:06 UTC (permalink / raw) To: Joshua Kinard; +Cc: David Daney, Ralf Baechle, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-26 8:06 ` Maciej W. Rozycki @ 2015-01-26 13:16 ` Ralf Baechle 2015-01-26 14:53 ` Maciej W. Rozycki 0 siblings, 1 reply; 26+ messages in thread From: Ralf Baechle @ 2015-01-26 13:16 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Joshua Kinard, David Daney, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-26 13:16 ` Ralf Baechle @ 2015-01-26 14:53 ` Maciej W. Rozycki 2015-01-26 18:15 ` David Daney 0 siblings, 1 reply; 26+ messages in thread From: Maciej W. Rozycki @ 2015-01-26 14:53 UTC (permalink / raw) To: Ralf Baechle; +Cc: Joshua Kinard, David Daney, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-26 14:53 ` Maciej W. Rozycki @ 2015-01-26 18:15 ` David Daney 2015-01-26 19:39 ` Maciej W. Rozycki 0 siblings, 1 reply; 26+ messages in thread From: David Daney @ 2015-01-26 18:15 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Ralf Baechle, Joshua Kinard, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-26 18:15 ` David Daney @ 2015-01-26 19:39 ` Maciej W. Rozycki 2015-01-26 20:13 ` David Daney 0 siblings, 1 reply; 26+ messages in thread From: Maciej W. Rozycki @ 2015-01-26 19:39 UTC (permalink / raw) To: David Daney; +Cc: Ralf Baechle, Joshua Kinard, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-26 19:39 ` Maciej W. Rozycki @ 2015-01-26 20:13 ` David Daney 2015-01-27 16:15 ` Maciej W. Rozycki 0 siblings, 1 reply; 26+ messages in thread From: David Daney @ 2015-01-26 20:13 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Ralf Baechle, Joshua Kinard, Linux MIPS List 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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-26 20:13 ` David Daney @ 2015-01-27 16:15 ` Maciej W. Rozycki 2015-01-27 19:57 ` David Daney 0 siblings, 1 reply; 26+ messages in thread From: Maciej W. Rozycki @ 2015-01-27 16:15 UTC (permalink / raw) To: David Daney; +Cc: Ralf Baechle, Joshua Kinard, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-27 16:15 ` Maciej W. Rozycki @ 2015-01-27 19:57 ` David Daney 2015-02-05 13:46 ` Maciej W. Rozycki 0 siblings, 1 reply; 26+ messages in thread From: David Daney @ 2015-01-27 19:57 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Ralf Baechle, Joshua Kinard, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-27 19:57 ` David Daney @ 2015-02-05 13:46 ` Maciej W. Rozycki 2015-02-05 15:28 ` Måns Rullgård 2015-02-05 16:27 ` David Daney 0 siblings, 2 replies; 26+ messages in thread From: Maciej W. Rozycki @ 2015-02-05 13:46 UTC (permalink / raw) To: David Daney; +Cc: Ralf Baechle, Joshua Kinard, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-02-05 13:46 ` Maciej W. Rozycki @ 2015-02-05 15:28 ` Måns Rullgård 2015-02-05 16:12 ` Maciej W. Rozycki 2015-02-05 16:27 ` David Daney 1 sibling, 1 reply; 26+ messages in thread From: Måns Rullgård @ 2015-02-05 15:28 UTC (permalink / raw) To: Maciej W. Rozycki Cc: David Daney, Ralf Baechle, Joshua Kinard, Linux MIPS List "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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-02-05 15:28 ` Måns Rullgård @ 2015-02-05 16:12 ` Maciej W. Rozycki 2015-02-05 19:36 ` Måns Rullgård 0 siblings, 1 reply; 26+ messages in thread From: Maciej W. Rozycki @ 2015-02-05 16:12 UTC (permalink / raw) To: Måns Rullgård Cc: David Daney, Ralf Baechle, Joshua Kinard, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-02-05 16:12 ` Maciej W. Rozycki @ 2015-02-05 19:36 ` Måns Rullgård 0 siblings, 0 replies; 26+ messages in thread From: Måns Rullgård @ 2015-02-05 19:36 UTC (permalink / raw) To: Maciej W. Rozycki Cc: David Daney, Ralf Baechle, Joshua Kinard, Linux MIPS List "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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-02-05 13:46 ` Maciej W. Rozycki 2015-02-05 15:28 ` Måns Rullgård @ 2015-02-05 16:27 ` David Daney 2015-02-05 21:02 ` Maciej W. Rozycki 1 sibling, 1 reply; 26+ messages in thread From: David Daney @ 2015-02-05 16:27 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Ralf Baechle, Joshua Kinard, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-02-05 16:27 ` David Daney @ 2015-02-05 21:02 ` Maciej W. Rozycki 0 siblings, 0 replies; 26+ messages in thread From: Maciej W. Rozycki @ 2015-02-05 21:02 UTC (permalink / raw) To: David Daney; +Cc: Ralf Baechle, Joshua Kinard, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-20 23:05 ` David Daney 2015-01-21 2:45 ` Joshua Kinard @ 2015-01-21 6:50 ` Antony Pavlov 1 sibling, 0 replies; 26+ messages in thread From: Antony Pavlov @ 2015-01-21 6:50 UTC (permalink / raw) To: David Daney; +Cc: Joshua Kinard, Ralf Baechle, Linux MIPS List 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo 2015-01-19 9:02 [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo Joshua Kinard 2015-01-20 23:05 ` David Daney @ 2015-02-12 4:16 ` Joshua Kinard 1 sibling, 0 replies; 26+ messages in thread From: Joshua Kinard @ 2015-02-12 4:16 UTC (permalink / raw) To: linux-mips 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2015-02-12 4:17 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-19 9:02 [PATCH] MIPS: Display CPU byteorder in /proc/cpuinfo Joshua Kinard 2015-01-20 23:05 ` David Daney 2015-01-21 2:45 ` Joshua Kinard 2015-01-21 2:54 ` Joshua Kinard 2015-01-21 10:22 ` Markos Chandras 2015-01-21 11:26 ` Joshua Kinard 2015-01-21 13:49 ` Ralf Baechle 2015-01-21 18:18 ` David Daney 2015-01-21 18:38 ` Aaro Koskinen 2015-01-21 18:42 ` David Daney 2015-01-26 8:06 ` Maciej W. Rozycki 2015-01-26 13:16 ` Ralf Baechle 2015-01-26 14:53 ` Maciej W. Rozycki 2015-01-26 18:15 ` David Daney 2015-01-26 19:39 ` Maciej W. Rozycki 2015-01-26 20:13 ` David Daney 2015-01-27 16:15 ` Maciej W. Rozycki 2015-01-27 19:57 ` David Daney 2015-02-05 13:46 ` Maciej W. Rozycki 2015-02-05 15:28 ` Måns Rullgård 2015-02-05 16:12 ` Maciej W. Rozycki 2015-02-05 19:36 ` Måns Rullgård 2015-02-05 16:27 ` David Daney 2015-02-05 21:02 ` Maciej W. Rozycki 2015-01-21 6:50 ` Antony Pavlov 2015-02-12 4:16 ` Joshua Kinard
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.