Little endianness
Hi.
Looks like PA-RISC 1.1 added bi-endian support.
What about PA-RISC Linux? I know it's big endian.
But does it possible to build little endian kernel? If so, how? Is migration to little endian planned? It should be reasonable as it will bring more compatibility with other Linux world.
Thanks.
Quoted 7 lines · Held Bier
Hi.
Looks like PA-RISC 1.1 added bi-endian support.
What about PA-RISC Linux? I know it's big endian.
But does it possible to build little endian kernel? If so, how? Is migration to little endian planned? It should be reasonable as it will bring more compatibility with other Linux world.
Unlikely. According to the PA 2.0 arch, implementation of this feature was optional.
Further the PDC/IODC firmware and software tool chains need little endian support. This is a massive amount of work. So, unless one one decided to create a 64-bit embedded PA-RISC processor for mass deployment, it wouldn't be worth the effort.
Dave
Signature · 1 line
John David Anglin [email protected]
Quoted 8 lines · John David Anglin
Quoted 7 lines · Held Bier
Hi.
Looks like PA-RISC 1.1 added bi-endian support.
What about PA-RISC Linux? I know it's big endian.
But does it possible to build little endian kernel? If so, how? Is migration to little endian planned? It should be reasonable as it will bring more compatibility with other Linux world.
What compatibility? x86 is LE, Arm is Schizophrenic, PPC, Sparc and PA are BE. We're required to support the bus standards anyway, so the SCSI bus is BE and the PCI bus LE by spec. There's no such thing as a "compatible" endianness.
Quoted 2 lines
Unlikely. According to the PA 2.0 arch, implementation of this feature was optional.
I think it was originally designed for some type of LASI system. There's an endian flip in some of the LASI devices as well. I think the original problem was LASI was designed big endian, but the chosen SCSI processor was designed for LE at that time, so they tried to flip the processor. I suspect the reason the feature became optional is that it caused more problems than it solved.
Quoted 5 lines
Further the PDC/IODC firmware and software tool chains need little endian support. This
is a massive amount of work. So, unless one one decided to create a 64-bit embedded
PA-RISC processor for mass deployment, it wouldn't be worth the effort.
It's a bit pointless too. Coping with endianness isn't really an unsolved OS problem, so it would cost a huge amount, open a large can of worms and buy us nothing.
James
Quoted 12 lines
James Bottomley <[email protected]>:
=20Quoted 8 lines · John David Anglin
Quoted 7 lines · Held Bier
Hi.
=20
Looks like PA-RISC 1.1 added bi-endian support.
What about PA-RISC Linux? I know it's big endian.
But does it possible to build little endian kernel? If so, how? Is migration to little endian planned? It should be reasonable as it will bring more compatibility with other Linux world.
Quoted 2 lines
=20
What compatibility? x86 is LE, Arm is Schizophrenic, PPC, Sparc and =
PA
Quoted 1 line
are BE. We're required to support the bus standards anyway, so the S=
CSI
Quoted 2 lines
bus is BE and the PCI bus LE by spec. There's no such thing as a "compatible" endianness.
Some software authors still assume that we're living in x86 only world,=
or just don't care. This leads to issues when one wish to run such sof=
tware on a BE Linux.
POWER is moving to LE:
https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-8=
17d-44a4f27eba32/entry/just_the_faqs_about_little_endian "Although Power already has Linux distributions and supporting applicat= ions that run in big endian mode, the Linux application ecosystem for x= 86 platforms is much larger and Linux on x86 uses little endian mode. = Numerous clients, software partners, and IBM=E2=80=99s own software dev= elopers have told us that porting their software to Power becomes simpl= er if the Linux environment on Power supports little endian mode, more = closely matching the environment provided by Linux on x86. This new le= vel of support will lower the barrier to entry for porting Linux on x86=
software to Linux on Power."
=46or PPC the patch was made: http://lwn.net/Articles/408845/
Quoted 2 lines
=20
Quoted 1 line
Unlikely. According to the PA 2.0 arch, implementation of this feat=
ure=20
Quoted 4 lines
Quoted 1 line
was optional.
=20
I think it was originally designed for some type of LASI system. There's an endian flip in some of the LASI devices as well. I think =
the
Quoted 1 line
original problem was LASI was designed big endian, but the chosen SCS=
I
Quoted 2 lines
processor was designed for LE at that time, so they tried to flip the processor. I suspect the reason the feature became optional is that =
it
Quoted 5 lines
caused more problems than it solved.
=20Quoted 3 lines
Further the PDC/IODC firmware and software tool chains need little=20 endian support. This
is a massive amount of work. So, unless one one decided to create a=
=20
Quoted 2 lines
Quoted 2 lines
64-bit embedded
PA-RISC processor for mass deployment, it wouldn't be worth the effo=
rt.
Quoted 3 lines
=20
It's a bit pointless too. Coping with endianness isn't really an unsolved OS problem, so it would cost a huge amount, open a large can=
of
Quoted 5 lines
worms and buy us nothing.
=20
James
=20
=20
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · On Sun, 2015-02-15 at 09:49 +0300, [email protected] wrote:
Quoted 11 lines
James Bottomley <[email protected]>:
=20Quoted 8 lines · John David Anglin
Quoted 7 lines · Held Bier
Hi.
=20
Looks like PA-RISC 1.1 added bi-endian support.
What about PA-RISC Linux? I know it's big endian.
But does it possible to build little endian kernel? If so, how? Is migration to little endian planned? It should be reasonable as it will bring more compatibility with other Linux world.
Quoted 2 lines
Quoted 2 lines
=20
What compatibility? x86 is LE, Arm is Schizophrenic, PPC, Sparc an=
d PA
Quoted 1 line
Quoted 1 line
are BE. We're required to support the bus standards anyway, so the=
SCSI
Quoted 9 lines
Quoted 2 lines
bus is BE and the PCI bus LE by spec. There's no such thing as a "compatible" endianness.
=20
Some software authors still assume that we're living in x86 only world, or just don't care. This leads to issues when one wish to run such software on a BE Linux.
=20
POWER is moving to LE:
https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2=
-817d-44a4f27eba32/entry/just_the_faqs_about_little_endian
Quoted 4 lines
"Although Power already has Linux distributions and supporting applications that run in big endian mode, the Linux application ecosystem for x86 platforms is much larger and Linux on x86 uses little endian mode. Numerous clients, software partners, and IBM=E2=80=
=99s
Quoted 7 lines
own software developers have told us that porting their software to Power becomes simpler if the Linux environment on Power supports little endian mode, more closely matching the environment provided by Linux on x86. This new level of support will lower the barrier to entry for porting Linux on x86 software to Linux on Power." =20
For PPC the patch was made: http://lwn.net/Articles/408845/
That's not a correct inference from the facts. Power is interested in playing in the embedded space and some of the graphics SoCs available there are LE only, so they're interested in enabling a LE version to ru= n
in that space ... it won't affect the rest of the PPC boxes.
All our boxes either have no graphics or a HP special big endian card. The only exception is the C8000 which has an ATI with special firmware (also designed for BE).
The thing you don't seem to understand is that the endianness is actually fixed by the firmware of the shipping systems. You're tied to whatever the firmware starts you in because swapping after the firmware init is unbelievably painful, especially when you need to call the firmware to perform OS tasks. We don't have any new systems planned, s= o
all the firmware is now fixed for PA and the endianness with it.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2015-02-15 19:50 GMT+00:00 James Bottomley
<[email protected]>:
Quoted 7 lines · On Sun, 2015-02-15 at 09:49 +0300, [email protected] wrote:
Quoted 6 lines
Quoted 6 lines
James Bottomley <[email protected]>:
Quoted 3 lines · John David Anglin
Quoted 2 lines · Held Bier
Hi.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Looks like PA-RISC 1.1 added bi-endian support.
What about PA-RISC Linux? I know it's big endian.
But does it possible to build little endian kernel? If so, how? Is migration to little endian planned? It should be reasonable as it will bring more compatibility with other Linux world.What compatibility? x86 is LE, Arm is Schizophrenic, PPC, Sparc a=
nd PA
Quoted 1 line
Quoted 1 line
Quoted 1 line
are BE. We're required to support the bus standards anyway, so th=
e SCSI
Quoted 9 lines
Quoted 9 lines
Quoted 2 lines
bus is BE and the PCI bus LE by spec. There's no such thing as a "compatible" endianness.
Some software authors still assume that we're living in x86 only world, or just don't care. This leads to issues when one wish to run such software on a BE Linux.
POWER is moving to LE:
https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f=
2-817d-44a4f27eba32/entry/just_the_faqs_about_little_endian
Quoted 4 lines
Quoted 4 lines
"Although Power already has Linux distributions and supporting applications that run in big endian mode, the Linux application ecosystem for x86 platforms is much larger and Linux on x86 uses little endian mode. Numerous clients, software partners, and IBM=E2=
=80=99s
Quoted 3 lines
Quoted 3 lines
own software developers have told us that porting their software to Power becomes simpler if the Linux environment on Power supports little endian mode, more closely matching the environment provided b=
y
Quoted 6 lines
Quoted 4 lines
Linux on x86. This new level of support will lower the barrier to entry for porting Linux on x86 software to Linux on Power."
For PPC the patch was made: http://lwn.net/Articles/408845/
That's not a correct inference from the facts. Power is interested i=
n
Quoted 2 lines
playing in the embedded space and some of the graphics SoCs available there are LE only, so they're interested in enabling a LE version to =
run
Quoted 3 lines
in that space ... it won't affect the rest of the PPC boxes.
All our boxes either have no graphics or a HP special big endian card=
=2E
Quoted 1 line
The only exception is the C8000 which has an ATI with special firmwar=
e
Quoted 4 lines
(also designed for BE).
The thing you don't seem to understand is that the endianness is actually fixed by the firmware of the shipping systems. You're tied =
to
Quoted 1 line
whatever the firmware starts you in because swapping after the firmwa=
re
Quoted 2 lines
init is unbelievably painful, especially when you need to call the firmware to perform OS tasks. We don't have any new systems planned,=
so
Quoted 3 lines
all the firmware is now fixed for PA and the endianness with it.
James
James,
This was a general question. In case if you're connecting dots with my later topic "Video option for a big endian machine?" - I should rather name it "... for a non-x86 arch", as there may be more platform specific issues, than just byte order. By the links i've provided there are thoughts that some graphics driver / stack (as well as many other non-related programs) may still be not fixed, e.g. they may don't use the host byte order at the CPU side operations, and so don't work. Of course the proper solution is to fix the actual code, but having a LE OS option for that hardware platform should be also an ultimate so-so solution.
Sorry for my question then, that was just a curiosity, I'm in no event asking anyone to sacrifice their forces and time just to bring LE to PA Linux.
Quoted 1 line
The only exception is the C8000 which has an ATI with special firmwar=
e
Quoted 1 line
(also designed for BE).
This doesn't seem to be true:
- Once I've put ATI designed for (and working in, under HP-UX) C8000 into IA64 machine with LE Linux and it worked fine;
- If HP asked ATI to produce a custom firmware, what's the purpose of putting x86 emulator into PDC? Actually both IA64 and PA-RISC ZX1 machines can POST most of relatively modern cards with unmodified VBIOS.
To add, Nvidia cards fail similarly to ATI with ring buffer issue (GPU locks up). If it's not the Nouveau breakage, than some PA Linux code (possibly DMA related) does something wrong.
Quoted 2 lines
The thing you don't seem to understand is that the endianness is actually fixed by the firmware of the shipping systems. You're tied =
to
Quoted 1 line
whatever the firmware starts you in because swapping after the firmwa=
re
Quoted 2 lines
init is unbelievably painful, especially when you need to call the firmware to perform OS tasks.
I'm sure you're right, i'm not expert there. I'm wondering why IA64 (or mentioned POWER) doesn't suffer from such obstacles?
https://forums.gentoo.org/viewtopic-p-2432985.html?sid=3D890fd4a4113673=
0c64d573192c9e3b57#2432985
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html