Patchwork [xserver] Add definitions for the AArch64 architecture

login
register
mail settings
Submitter Thomas Petazzoni
Date Jan. 3, 2013, 3:33 p.m.
Message ID <1357227183-999-1-git-send-email-thomas.petazzoni@free-electrons.com>
Download mbox | patch
Permalink /patch/12744/
State New
Headers show

Comments

Thomas Petazzoni - Jan. 3, 2013, 3:33 p.m.
AArch64 is the new 64 bits architecture from ARM, for which a few
definitions are needed in the X.org server to make it build properly.

Like for the ARM 32 bits architecture, we for now assume that AArch64
will be used in Little Endian mode for Linux.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 include/servermd.h |    9 +++++++++
 1 file changed, 9 insertions(+)
Thierry Reding - Jan. 3, 2013, 8:48 p.m.
On Thu, Jan 03, 2013 at 04:33:03PM +0100, Thomas Petazzoni wrote:
> AArch64 is the new 64 bits architecture from ARM, for which a few
> definitions are needed in the X.org server to make it build properly.
> 
> Like for the ARM 32 bits architecture, we for now assume that AArch64
> will be used in Little Endian mode for Linux.

Is there a reason for doing so? It should be possible to get this
information from predefined preprocessor macros:

	$ arm-unknown-linux-gnueabi-gcc -mlittle-endian -dM -E - < /dev/null | grep -i arm
	#define __ARMEL__ 1
	#define __ARM_ARCH_5T__ 1
	#define __ARM_PCS 1
	#define __arm__ 1
	#define __ARM_EABI__ 1

	$ arm-unknown-linux-gnueabi-gcc -mbig-endian -dM -E - < /dev/null | grep -i arm
	#define __ARM_ARCH_5T__ 1
	#define __ARMEB__ 1
	#define __ARM_PCS 1
	#define __arm__ 1
	#define __ARM_EABI__ 1

So it should be possible to make the byte order conditional on __ARMEL__
and __ARMEB__ respectively. Alternatively there is __BYTE_ORDER__ which
is defined to __ORDER_LITTLE_ENDIAN__ and __ORDER_BIG_ENDIAN__ for
-mlittle-endian and -mbig-endian respectively.

Thierry
Alan Coopersmith - Jan. 3, 2013, 9:30 p.m.
On 01/ 3/13 07:33 AM, Thomas Petazzoni wrote:
> AArch64 is the new 64 bits architecture from ARM, for which a few
> definitions are needed in the X.org server to make it build properly.
> 
> Like for the ARM 32 bits architecture, we for now assume that AArch64
> will be used in Little Endian mode for Linux.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  include/servermd.h |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/include/servermd.h b/include/servermd.h
> index d6a9a3a..c2d7d70 100644
> --- a/include/servermd.h
> +++ b/include/servermd.h
> @@ -272,6 +272,15 @@ SOFTWARE.
>  
>  #endif                          /* linux/m68k */
>  
> +/* linux on AArch64 */
> +#if defined(linux) && defined(__aarch64__)
> +
> +#define IMAGE_BYTE_ORDER       LSBFirst
> +#define BITMAP_BIT_ORDER       LSBFirst
> +#define GLYPHPADBYTES          4
> +
> +#endif
> +
>  /* linux on ARM */
>  #if defined(linux) && defined(__arm__)
>  #define IMAGE_BYTE_ORDER	LSBFirst

Since you're defining the same values as the next section, why not just
make it #if defined(linux) && (defined(__arm__) || defined(__aarch64__))
instead of duplicating them?
Thomas Petazzoni - Jan. 3, 2013, 10:16 p.m.
Dear Thierry Reding,

On Thu, 3 Jan 2013 21:48:22 +0100, Thierry Reding wrote:
> On Thu, Jan 03, 2013 at 04:33:03PM +0100, Thomas Petazzoni wrote:
> > AArch64 is the new 64 bits architecture from ARM, for which a few
> > definitions are needed in the X.org server to make it build
> > properly.
> > 
> > Like for the ARM 32 bits architecture, we for now assume that
> > AArch64 will be used in Little Endian mode for Linux.
> 
> Is there a reason for doing so? It should be possible to get this
> information from predefined preprocessor macros:

For the AArch64 addition, there is no other reason than just using the
same pattern as the one used for ARM. For sure the ARM thing itself
could be improved. I think ultimately all those architecture-specific
definitions could potentially be guessed from standard headers, but
isn't that a separate effort?

Thanks,

Thomas
Marcin Juszkiewicz - Jan. 7, 2013, 11:27 a.m.
Hi

As my work nowadays is getting as much as possible built for AArch64
platform I took some time to get "xserver-xorg" 1.13.1 built.

My first attempt was same as Thomas Petazzoni did. Xserver builds and
starts fine but graphical output is wrong:

https://plus.google.com/u/0/105007947798310229700/posts/grcK83g5jys

So I changed byte order from LSBFirst to MSBFirst and now it looks like
it should:

https://plus.google.com/u/0/105007947798310229700/posts/dRu2UVEv9gz

And I love how xf86EnableIO got cleaned - I had to patch them too.
Thomas Petazzoni - Jan. 7, 2013, 12:47 p.m.
Dear Marcin Juszkiewicz,

On Mon, 07 Jan 2013 13:25:45 +0100, Marcin Juszkiewicz wrote:

> > +/* linux on AArch64 */
> > +#if defined(linux) && defined(__aarch64__)
> > +
> > +#define IMAGE_BYTE_ORDER       LSBFirst
> > +#define BITMAP_BIT_ORDER       LSBFirst
> > +#define GLYPHPADBYTES          4
> > +
> > +#endif
> 
> Order is reverse. I went that way first time but image booted in
> AArch64 commercial fast model shown distorted xterm [1]. Changed to
> MSBFirst and xterm starts and displays properly [2].

I guess AArch64 runs Little-endian, no? If so, why would the order be
MSBFirst? Of course, I see that it "fixes" the problem for you, but I'd
like to understand the fix.

Also, is the AArch64 model with graphic support publicly available?

Thanks!

Thomas
Marcin Juszkiewicz - Jan. 7, 2013, 1 p.m.
W dniu 07.01.2013 13:47, Thomas Petazzoni pisze:
> Dear Marcin Juszkiewicz,
> 
> On Mon, 07 Jan 2013 13:25:45 +0100, Marcin Juszkiewicz wrote:
> 
>>> +/* linux on AArch64 */ +#if defined(linux) &&
>>> defined(__aarch64__) + +#define IMAGE_BYTE_ORDER       LSBFirst 
>>> +#define BITMAP_BIT_ORDER       LSBFirst +#define GLYPHPADBYTES
>>> 4 + +#endif
>> 
>> Order is reverse. I went that way first time but image booted in 
>> AArch64 commercial fast model shown distorted xterm [1]. Changed
>> to MSBFirst and xterm starts and displays properly [2].
> 
> I guess AArch64 runs Little-endian, no?

So far everyone agreed that AArch64 will be used with Little endian. Big
endian should be possible but can be skipped for now.

> If so, why would the order be MSBFirst? Of course, I see that it
> "fixes" the problem for you, but I'd like to understand the fix.

I concentrated on getting it working. Will try to understand it later ;(

> Also, is the AArch64 model with graphic support publicly available?

You need to buy license from ARM Ltd. I have access due to my Linaro work.
Thomas Petazzoni - Jan. 7, 2013, 1:10 p.m.
Dear Marcin Juszkiewicz,

On Mon, 07 Jan 2013 14:00:33 +0100, Marcin Juszkiewicz wrote:

> >> Order is reverse. I went that way first time but image booted in 
> >> AArch64 commercial fast model shown distorted xterm [1]. Changed
> >> to MSBFirst and xterm starts and displays properly [2].
> > 
> > I guess AArch64 runs Little-endian, no?
> 
> So far everyone agreed that AArch64 will be used with Little endian.
> Big endian should be possible but can be skipped for now.

Ok, that was my understanding as well, which lead to the usage of
LSBFirst.

> > If so, why would the order be MSBFirst? Of course, I see that it
> > "fixes" the problem for you, but I'd like to understand the fix.
> 
> I concentrated on getting it working. Will try to understand it
> later ;(

Ok. Using MSBFirst for a little-endian architecture sounds odd, no?
Except if the graphics hardware somehow has a different endianess, I
don't know.

> > Also, is the AArch64 model with graphic support publicly available?
> 
> You need to buy license from ARM Ltd. I have access due to my Linaro
> work.

Argh. Too bad.

Thanks,

Thomas

Patch

diff --git a/include/servermd.h b/include/servermd.h
index d6a9a3a..c2d7d70 100644
--- a/include/servermd.h
+++ b/include/servermd.h
@@ -272,6 +272,15 @@  SOFTWARE.
 
 #endif                          /* linux/m68k */
 
+/* linux on AArch64 */
+#if defined(linux) && defined(__aarch64__)
+
+#define IMAGE_BYTE_ORDER       LSBFirst
+#define BITMAP_BIT_ORDER       LSBFirst
+#define GLYPHPADBYTES          4
+
+#endif
+
 /* linux on ARM */
 #if defined(linux) && defined(__arm__)
 #define IMAGE_BYTE_ORDER	LSBFirst