Raspberry pi support

Raspberry pi support

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 4801 bytes --]

Based on Leif Lindholm's patches I could go to GRUB console on raspberry pi.
The biggest problem is that cache flushing is simply skipped. Another problem
is that due to different linux image format linux loader doesn't work. I didn't
test grub-install but fed GRUB to uboot using kermit.
Is there any advantage in building armv6 binary by default unless user overrides
through TARGET_CFLAGS?
Some of the fixes are to make tools work on amd64


=== modified file 'conf/Makefile.common'
--- conf/Makefile.common	2013-04-07 00:41:07 +0000
+++ conf/Makefile.common	2013-04-07 16:08:07 +0000
@@ -40,8 +40,7 @@
 if COND_arm
 # Image entry point always in ARM (A32) state - ensure proper functionality if
 # the rest is built for the Thumb (T32) state.
-  CFLAGS_PLATFORM += -mthumb-interwork -mno-unaligned-access -mlong-calls
-  CCASFLAGS_PLATFORM = -Wa,-mimplicit-it=thumb
+  CFLAGS_PLATFORM += -mthumb-interwork -march=armv6 -mlong-calls
   LDFLAGS_PLATFORM = -Wl,--wrap=__clear_cache
 endif
 

=== modified file 'configure.ac'
--- configure.ac	2013-04-07 00:41:07 +0000
+++ configure.ac	2013-04-07 16:08:07 +0000
@@ -717,7 +717,7 @@
 fi
 
 # Check for libgcc symbols
-AC_CHECK_FUNCS(__bswapsi2 __bswapdi2 __ashldi3 __ashrdi3 __lshrdi3 __ucmpdi2 _restgpr_14_x __udivsi3 __umoddi3 __udivdi3 __divsi3 __modsi3 __umodsi3 __moddi3 __divdi3 __ctzdi2 __ctzsi2)
+AC_CHECK_FUNCS(__bswapsi2 __bswapdi2 __ashldi3 __ashrdi3 __lshrdi3 __ucmpdi2 _restgpr_14_x __udivsi3 __umoddi3 __udivdi3 __divsi3 __modsi3 __umodsi3 __moddi3 __divdi3 __ctzdi2 __ctzsi2 __aeabi_ulcmp)
 
 if test "x$TARGET_APPLE_CC" = x1 ; then
 CFLAGS="$TARGET_CFLAGS -nostdlib"

=== modified file 'grub-core/kern/arm/dl.c'
--- grub-core/kern/arm/dl.c	2013-04-07 00:41:07 +0000
+++ grub-core/kern/arm/dl.c	2013-04-07 16:08:07 +0000
@@ -27,9 +27,6 @@
 #ifdef GRUB_UTIL
 # include <grub/util/misc.h>
 #else
-# if !defined(__thumb2__)
-#  error "Relocations not implemented for A32 ("ARM") instruction set yet!"
-# endif
 
 grub_err_t reloc_jump24 (grub_uint32_t *addr, Elf32_Addr sym_addr);
 grub_err_t reloc_thm_call (grub_uint16_t *addr, Elf32_Addr sym_addr);
@@ -169,8 +166,8 @@
     }
 
 #ifdef GRUB_UTIL
-  grub_util_info ("    relative destination = 0x%08x",
-		  (unsigned int)target + offset);
+  grub_util_info ("    relative destination = 0x%08lx",
+		  (unsigned long)target + offset);
 #endif
 
   /* Reassemble instruction word */
@@ -358,6 +355,7 @@
 	      return retval;
 	  }
 	  break;
+	case R_ARM_CALL:
 	case R_ARM_JUMP24:
 	  {
 	    retval = reloc_jump24 (target, sym_addr);

=== modified file 'grub-core/kern/dl.c'
--- grub-core/kern/dl.c	2013-03-19 19:25:09 +0000
+++ grub-core/kern/dl.c	2013-04-07 16:08:07 +0000
@@ -588,7 +588,7 @@
 {
   grub_dprintf ("modules", "flushing 0x%lx bytes at %p\n",
 		(unsigned long) mod->sz, mod->base);
-  grub_arch_sync_caches (mod->base, mod->sz);
+  //  grub_arch_sync_caches (mod->base, mod->sz);
 }
 
 /* Load a module from core memory.  */

=== modified file 'include/grub/libgcc.h'
--- include/grub/libgcc.h	2013-04-07 00:41:07 +0000
+++ include/grub/libgcc.h	2013-04-07 16:08:07 +0000
@@ -122,4 +122,5 @@
 void EXPORT_FUNC (__aeabi_uidiv) (void);
 void EXPORT_FUNC (__aeabi_uidivmod) (void);
 void EXPORT_FUNC (__wrap___clear_cache) (void *, void *);
+void EXPORT_FUNC (__aeabi_ulcmp) (void);
 #endif

=== modified file 'include/grub/uboot/api_public.h'
--- include/grub/uboot/api_public.h	2013-04-07 00:41:07 +0000
+++ include/grub/uboot/api_public.h	2013-04-07 16:08:07 +0000
@@ -61,9 +61,6 @@
 
 typedef int (*scp_t) (int, int *, ...);
 
-typedef grub_uint16_t uint16_t;
-typedef grub_uint32_t uint32_t;
-
 #define API_SIG_VERSION	1
 #define API_SIG_MAGIC	"UBootAPI"
 #define API_SIG_MAGLEN	8
@@ -71,8 +68,8 @@
 struct api_signature
 {
   char magic[API_SIG_MAGLEN];	/* magic string */
-  uint16_t version;		/* API version */
-  uint32_t checksum;		/* checksum of this sig struct */
+  grub_uint16_t version;	/* API version */
+  grub_uint32_t checksum;	/* checksum of this sig struct */
   scp_t syscall;		/* entry point to the API */
 };
 

=== modified file 'util/grub-mkimagexx.c'
--- util/grub-mkimagexx.c	2013-04-07 00:41:07 +0000
+++ util/grub-mkimagexx.c	2013-04-07 16:08:07 +0000
@@ -553,7 +553,7 @@
 		   case R_ARM_THM_CALL:
 		   case R_ARM_THM_JUMP24:
 		     {
-		       grub_util_info ("  THM_JUMP24:\ttarget=0x%08x\toffset=(0x%08x)",	(unsigned int) target, sym_addr);
+		       grub_util_info ("  THM_JUMP24:\ttarget=0x%08lx\toffset=(0x%08x)",	(unsigned long) target, sym_addr);
 		       sym_addr -= offset;
 		       /* Thumb instructions can be 16-bit aligned */
 		       reloc_thm_call ((grub_uint16_t *) target, sym_addr);




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Raspberry pi support

[Leif Lindholm]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

On Sun, Apr 07, 2013 at 07:20:35PM +0200, Vladimir '??-coder/phcoder' Serbinenko wrote:
> Based on Leif Lindholm's patches I could go to GRUB console on raspberry pi.
> The biggest problem is that cache flushing is simply skipped. Another
> problem is that due to different linux image format linux loader doesn't
> work.

Is this because you're feeding it a uImage?
It is entirely possible to runtime detect the U-Boot signature, and simply
skip the header.

> I didn't test grub-install but fed GRUB to uboot using kermit.
> Is there any advantage in building armv6 binary by default unless user
> overrides through TARGET_CFLAGS?

I think it would get messy: the barrier operations supported by ARMv6 are
deprecated in ARMv7.

I would suggest an alternative approach, which is to build all of the
assembly in "arm" state, and to keep the generic functionality to an
ARMv6 subset.

This would then have to be done in multiple files, but as an example, I
have implemented this for specifically the cache synchronization, attached
to this email.

> Some of the fixes are to make tools work on amd64
> 
> 
> === modified file 'conf/Makefile.common'
> --- conf/Makefile.common	2013-04-07 00:41:07 +0000
> +++ conf/Makefile.common	2013-04-07 16:08:07 +0000
> @@ -40,8 +40,7 @@
>  if COND_arm
>  # Image entry point always in ARM (A32) state - ensure proper functionality if
>  # the rest is built for the Thumb (T32) state.
> -  CFLAGS_PLATFORM += -mthumb-interwork -mno-unaligned-access -mlong-calls
> -  CCASFLAGS_PLATFORM = -Wa,-mimplicit-it=thumb
> +  CFLAGS_PLATFORM += -mthumb-interwork -march=armv6 -mlong-calls
>    LDFLAGS_PLATFORM = -Wl,--wrap=__clear_cache
>  endif
  
-mno-unaligned-access is required to function on platforms that do not
have caches/MMU enabled at this point. They do exist, so please leave it in.

And for reasons stated above, -march= should be set to whatever your
target architecture is. Extracted by configure, I suppose?

/
    Leif

[-- Attachment #2: armv6cache.patch --]
[-- Type: text/x-diff, Size: 4603 bytes --]

=== modified file 'conf/Makefile.common'
--- conf/Makefile.common	2013-04-04 19:40:53 +0000
+++ conf/Makefile.common	2013-04-08 10:42:47 +0000
@@ -41,6 +41,7 @@
 # Image entry point always in ARM (A32) state - ensure proper functionality if
 # the rest is built for the Thumb (T32) state.
   CFLAGS_PLATFORM += -mthumb-interwork -mno-unaligned-access -mlong-calls
+  CCASFLAGS_PLATFORM = -marm
   LDFLAGS_PLATFORM = -Wl,--wrap=__clear_cache
 endif
 

=== modified file 'grub-core/kern/arm/cache.S'
--- grub-core/kern/arm/cache.S	2013-04-04 19:40:53 +0000
+++ grub-core/kern/arm/cache.S	2013-04-08 11:21:16 +0000
@@ -21,14 +21,16 @@
 	.file	"cache.S"
 	.text
 	.syntax	unified
-#if !defined (__thumb2__)
-	.arm
-#define ARM(x...)	x
-#define THUMB(x...)
+#if (__ARM_ARCH_6__ == 1)
+# define DMB	mcr	p15, 0, r0, c7, c10, 5
+# define DSB	mcr	p15, 0, r0, c7, c10, 4
+# define ISB	mcr	p15, 0, r0, c7, c5, 4
+#elif (__ARM_ARCH_7A__ == 1)
+# define DMB	dmb
+# define DSB	dsb
+# define ISB	isb
 #else
-	.thumb
-#define THUMB(x...)	x
-#define ARM(x...)
+# error Unsupported architecture version!
 #endif
 
 	.align	2
@@ -38,7 +40,7 @@
  */
 
 @ r0 - *beg (inclusive)
-@ r1 - *end (exclusive)	
+@ r1 - *end (exclusive)
 clean_dcache_range:
 	@ Clean data cache for range to point-of-unification
 	ldr	r2, dlinesz
@@ -50,11 +52,11 @@
 	mcr	p15, 0, r0, c7, c11, 1	@ DCCMVAU
 	add	r0, r0, r2		@ Next line
 	b	1b
-2:	dsb
+2:	DSB
 	bx	lr
 
 @ r0 - *beg (inclusive)
-@ r1 - *end (exclusive)	
+@ r1 - *end (exclusive)
 invalidate_icache_range:
 	@ Invalidate instruction cache for range to point-of-unification
 	ldr	r2, ilinesz
@@ -68,17 +70,16 @@
 	b	1b
 	@ Branch predictor invalidate all
 2:	mcr	p15, 0, r0, c7,	c5, 6	@ BPIALL
-	dsb
-	isb
+	DSB
+	ISB
 	bx	lr
 
-sync_caches:	
-	dmb
-	dsb
+sync_caches:
+	DMB
+	DSB
 	push	{r4-r6, lr}
 	ldr	r2, probed	@ If first call, probe cache sizes
 	cmp	r2, #0
- THUMB( it	eq )
 	bleq	probe_caches	@ This call corrupts r3
 	mov	r4, r0
 	mov	r5, r1
@@ -92,7 +93,8 @@
 	push	{r4-r6, lr}
 	mrc 	p15, 0, r4, c0, c0, 1	@ Read Cache Type Register
 	mov	r5, #1
-	ubfx	r6, r4, #16, #4		@ Extract min D-cache num word log2
+	lsr	r6, r4, #16		@ Extract min D-cache num word log2
+	and	r6, r6, #0xf
 	add	r6, r6, #2		@ words->bytes
 	lsl	r6, r5, r6		@ Convert to num bytes
 	ldr	r3, =dlinesz
@@ -133,21 +135,26 @@
 clean_invalidate_dcache:
 	push	{r4-r12, lr}
 	mrc 	p15, 1, r0, c0, c0, 1	@ Read CLIDR
-	ubfx	r1, r0, #24, #3		@ Extract LoC
-	
+	lsr	r1, r0, #24		@ Extract LoC
+	and	r1, r1, #0x7
+
 	mov	r2, #0			@ First level, L1
 2:	and	r8, r0, #7		@ cache type at current level
 	cmp	r8, #2
 	blt	5f			@ instruction only, or none, skip level
 
-	@ set current cache level/type (for CSSIDR read)
+	@ set current cache level/type (for CCSIDR read)
 	lsl	r8, r2, #1
 	mcr	p15, 2, r8, c0, c0, 0	@ Write CSSELR (level, type: data/uni)
 
 	@ read current cache information
-	mrc	p15, 1, r8, c0, c0, 0	@ Read CSSIDR
-	ubfx	r3, r8, #13, #14	@ Number of sets -1
-	ubfx	r4, r8, #3, #9		@ Number of ways -1
+	mrc	p15, 1, r8, c0, c0, 0	@ Read CCSIDR
+	lsr	r3, r8, #13		@ Number of sets -1
+	ldr	r9, =0x3fff
+	and	r3, r3, r9
+	lsr	r4, r8, #3		@ Number of ways -1
+	ldr	r9, =0x1ff
+	and	r4, r4, r9
 	and	r7, r8, #7		@ log2(line size in words) - 2
 	add	r7, r7, #2		@  adjust
 	mov	r8, #1
@@ -170,11 +177,11 @@
 	clz	r9, r10			@ r9 = way field offset
 	add	r9, r9, #1
 4:	lsl	r10, r6, r9
-	orr	r11, r8, r10		@ insert way field	
-	
+	orr	r11, r8, r10		@ insert way field
+
 	@ clean and invalidate line by set/way
 	mcr	p15, 0, r11, c7, c14, 2	@ DCCISW
-	
+
 	@ next way
 	add	r6, r6, #1
 	cmp	r6, r4
@@ -184,7 +191,7 @@
 	add	r5, r5, #1
 	cmp	r5, r3
 	ble	3b
-	
+
 	@ next level
 5:	lsr	r0, r0, #3		@ align next level CLIDR 'type' field
 	add	r2, r2, #1		@ increment cache level counter
@@ -192,8 +199,8 @@
 	blt	2b			@ outer loop
 
 	@ return
-6:	dsb
-	isb
+6:	DSB
+	ISB
 	pop	{r4-r12, pc}
 
 FUNCTION(grub_arm_disable_caches_mmu)
@@ -203,8 +210,8 @@
 	mrc	p15, 0, r0, c1, c0, 0
 	bic	r0, r0, #(1 << 2)
 	mcr	p15, 0, r0, c1, c0, 0
-	dsb
-	isb
+	DSB
+	ISB
 
 	@ clean/invalidate D-cache
 	bl	clean_invalidate_dcache
@@ -213,14 +220,14 @@
 	mrc	p15, 0, r0, c1, c0, 0
 	bic	r0, r0, #(1 << 12)
 	mcr	p15, 0, r0, c1, c0, 0
-	dsb
-	isb
+	DSB
+	ISB
 
 	@ invalidate I-cache (also invalidates branch predictors)
 	mcr	p15, 0, r0, c7, c5, 0
-	dsb
-	isb
-	
+	DSB
+	ISB
+
 	@ clear SCTLR M bit
 	mrc	p15, 0, r0, c1, c0, 0
 	bic	r0, r0, #(1 << 0)
@@ -228,8 +235,8 @@
 
 	mcr	p15, 0, r0, c8, c7, 0	@ invalidate TLB
 	mcr	p15, 0, r0, c7, c5, 6	@ invalidate branch predictor
-	dsb
-	isb
+	DSB
+	ISB
 
 	pop	{r4, pc}
 

Re: Raspberry pi support

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]

On 08.04.2013 13:44, Leif Lindholm wrote:

> On Sun, Apr 07, 2013 at 07:20:35PM +0200, Vladimir '??-coder/phcoder' Serbinenko wrote:
>> Based on Leif Lindholm's patches I could go to GRUB console on raspberry pi.
>> The biggest problem is that cache flushing is simply skipped. Another
>> problem is that due to different linux image format linux loader doesn't
>> work.
> 
> Is this because you're feeding it a uImage?
> It is entirely possible to runtime detect the U-Boot signature, and simply
> skip the header.
> 

The kernel shipped with raspbian aren't uImages. they are with some kind
of raspberry stuff in it. They have to be loaded at 0 with entry point
at 0. u-boot is available for raspberry pi but isn't used by default.

>> I didn't test grub-install but fed GRUB to uboot using kermit.
>> Is there any advantage in building armv6 binary by default unless user
>> overrides through TARGET_CFLAGS?
> 
> I think it would get messy: the barrier operations supported by ARMv6 are
> deprecated in ARMv7.
> 

The questions basically would be how we switch between armv6 and armv7.
I see as possibilities:
defining target_cpu of armv6 and armv7, so it will give 4 ports
armv[67]-(uboot|efi). Another possibility is to decide on runtime but
it's probably more difficult.

> I would suggest an alternative approach, which is to build all of the
> assembly in "arm" state, and to keep the generic functionality to an
> ARMv6 subset.
> 

Do we lose anything by not supporting thumb2 for assembly?
What armv7 functionality is useful?

>> === modified file 'conf/Makefile.common'
>> --- conf/Makefile.common	2013-04-07 00:41:07 +0000
>> +++ conf/Makefile.common	2013-04-07 16:08:07 +0000
>> @@ -40,8 +40,7 @@
>>  if COND_arm
>>  # Image entry point always in ARM (A32) state - ensure proper functionality if
>>  # the rest is built for the Thumb (T32) state.
>> -  CFLAGS_PLATFORM += -mthumb-interwork -mno-unaligned-access -mlong-calls
>> -  CCASFLAGS_PLATFORM = -Wa,-mimplicit-it=thumb
>> +  CFLAGS_PLATFORM += -mthumb-interwork -march=armv6 -mlong-calls
>>    LDFLAGS_PLATFORM = -Wl,--wrap=__clear_cache
>>  endif
>   
> -mno-unaligned-access is required to function on platforms that do not
> have caches/MMU enabled at this point. They do exist, so please leave it in.

My compiler simply doesn't know this option. I suppose it always assumes
that no unaligned access is available. Availability of this option must
be detected on configure time.

> 
> And for reasons stated above, -march= should be set to whatever your
> target architecture is. Extracted by configure, I suppose?

Hence --target-cpu=armv[67] proposal.g


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Raspberry pi support

[Leif Lindholm]

On Mon, Apr 08, 2013 at 02:59:59PM +0200, Vladimir '??-coder/phcoder' Serbinenko wrote:
> > Is this because you're feeding it a uImage?
> > It is entirely possible to runtime detect the U-Boot signature, and simply
> > skip the header.
> 
> The kernel shipped with raspbian aren't uImages. they are with some kind
> of raspberry stuff in it. They have to be loaded at 0 with entry point
> at 0. u-boot is available for raspberry pi but isn't used by default.
 
Ah. Yes - I had heard things about the raspi boot mechanism, but must
admit I'm not entirely certain about how it would affect things.
It could even require a separate loader.

> >> I didn't test grub-install but fed GRUB to uboot using kermit.
> >> Is there any advantage in building armv6 binary by default unless user
> >> overrides through TARGET_CFLAGS?
> > 
> > I think it would get messy: the barrier operations supported by ARMv6 are
> > deprecated in ARMv7.
> 
> The questions basically would be how we switch between armv6 and armv7.
> I see as possibilities:
> defining target_cpu of armv6 and armv7, so it will give 4 ports
> armv[67]-(uboot|efi). Another possibility is to decide on runtime but
> it's probably more difficult.

If we want to support ARMv6 targets (keeping in mind that this is
akin to implementing i386 support several years after the release of
the 486), what we actually end up with is armv6 and v7+ - not a new
version for every revision of the architecture (ignoring a 64-bit
port for now).

For (U)EFI, I don't think you can find any pre-ARMv7 platforms outside
of ARM ltd. early-access development boards (and software models of
the same).

For U-Boot, keeping the hand coded assembly to the ARMv6 subset,
adding preprocessor macros for the barrier operations and setting
suitable CFLAGS would be sufficient to get GRUB working across the
available platforms.
 
> > I would suggest an alternative approach, which is to build all of the
> > assembly in "arm" state, and to keep the generic functionality to an
> > ARMv6 subset.
> 
> Do we lose anything by not supporting thumb2 for assembly?

Not much. It was mainly done from a point-of-view of not having to
explicitly build the assembler files for a specific instruction set.

For ARMv6 there is no support in the thumb instruction set for system
control operations, so in order to support that, assembler files need
to be built for the arm instruction set. And if they need to be
written as arm instructions anyway, let's just do that by default.
I can include that rewrite in my next patchset.

Restricting ourselves to ARMv6 instructions reduces maximum size of
immediate loading and loses some more convenient operations like the
bitfield-extract ones I modified in my patch.

> What armv7 functionality is useful?

As I said, the barrier instructions (required, not just "useful").
 
> >> === modified file 'conf/Makefile.common'
> >> --- conf/Makefile.common	2013-04-07 00:41:07 +0000
> >> +++ conf/Makefile.common	2013-04-07 16:08:07 +0000
> >> @@ -40,8 +40,7 @@
> >>  if COND_arm
> >>  # Image entry point always in ARM (A32) state - ensure proper functionality if
> >>  # the rest is built for the Thumb (T32) state.
> >> -  CFLAGS_PLATFORM += -mthumb-interwork -mno-unaligned-access -mlong-calls
> >> -  CCASFLAGS_PLATFORM = -Wa,-mimplicit-it=thumb
> >> +  CFLAGS_PLATFORM += -mthumb-interwork -march=armv6 -mlong-calls
> >>    LDFLAGS_PLATFORM = -Wl,--wrap=__clear_cache
> >>  endif
> >   
> > -mno-unaligned-access is required to function on platforms that do not
> > have caches/MMU enabled at this point. They do exist, so please leave it in.
> 
> My compiler simply doesn't know this option. I suppose it always assumes
> that no unaligned access is available. Availability of this option must
> be detected on configure time.
 
Then I need to add a configure test for this, causing a failure if the
option is missing. A toolchain that does not support this option cannot
be used to build a reliable bare-metal image for ARM.

FSF GCC 4.7 onwards (and some distribution-patched 4.6) support this flag.

> > And for reasons stated above, -march= should be set to whatever your
> > target architecture is. Extracted by configure, I suppose?
> 
> Hence --target-cpu=armv[67] proposal.g

I think it is a bit overkill, since CFLAGS can cover it.

/
    Leif

Re: Raspberry pi support

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

> Then I need to add a configure test for this, causing a failure if the

> option is missing. A toolchain that does not support this option cannot
> be used to build a reliable bare-metal image for ARM.
> 
> FSF GCC 4.7 onwards (and some distribution-patched 4.6) support this flag.
> 

Why? According to
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=eb04cafba3a6f1eddbdb5ec031d8a7074930d5b9
older version simply have "implicit" -mno-unaligned-access and we
support only GCC.

>>> And for reasons stated above, -march= should be set to whatever your
>>> target architecture is. Extracted by configure, I suppose?
>>
>> Hence --target-cpu=armv[67] proposal.g
> 
> I think it is a bit overkill, since CFLAGS can cover it.
> 

The difference is that for all other targets you can compile for the
lowest supported CPU and use it for all devices with this target but if
I understand correctly on armv7 you need to insert some opcodes which
would cause a crash on armv6. Is only cache flushing displays such kind
of backward incompatibility?
Another question:
I see that efi/startup.S transitions to thumb but not uboot/startup.S.
Was uboot compiled as arm in your port as well or do I miss sth?

> /
>     Leif
> 




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Raspberry pi support

[Leif Lindholm]

Apologies for long silence, I've been off prototyping runtime services
for UEFI on ARMv7 (in order to make EFI grub-install actually _do_
anything), and am really bad at multi-tasking.
I am now focusing 100% on this for the rest of the week.

On Mon, Apr 08, 2013 at 09:58:12PM +0200, Vladimir '??-coder/phcoder' Serbinenko wrote:
> > Then I need to add a configure test for this, causing a failure if the
> 
> > option is missing. A toolchain that does not support this option cannot
> > be used to build a reliable bare-metal image for ARM.
> > 
> > FSF GCC 4.7 onwards (and some distribution-patched 4.6) support this flag.
> > 
> 
> Why? According to
> http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=eb04cafba3a6f1eddbdb5ec031d8a7074930d5b9
> older version simply have "implicit" -mno-unaligned-access and we
> support only GCC.
 
Ok, then it needs to be conditionalised on a configure test.

> >>> And for reasons stated above, -march= should be set to whatever your
> >>> target architecture is. Extracted by configure, I suppose?
> >>
> >> Hence --target-cpu=armv[67] proposal.g
> > 
> > I think it is a bit overkill, since CFLAGS can cover it.
> > 
> 
> The difference is that for all other targets you can compile for the
> lowest supported CPU and use it for all devices with this target but if
> I understand correctly on armv7 you need to insert some opcodes which
> would cause a crash on armv6. Is only cache flushing displays such kind
> of backward incompatibility?

Only the cache flushing code requires barrier operations.
Restricting the .S files to "ARM" instruction set, the barriers can be
conditionalised. I will be sending out some patches that to this toda

> Another question:
> I see that efi/startup.S transitions to thumb but not uboot/startup.S.
> Was uboot compiled as arm in your port as well or do I miss sth?

Since I was calling it as a "kernel" image (to get machine type and
ATAGS/DTB passed on), and the kernel is defined to be called in ARM state,
this was the requirement.
This requirement remains regardless of what instruction set uboot is
compiled to. If uboot-ELF image support was implemented, you change the
protocol, but there would be no strong benefit in changing the entry
point code..


/
    Leif