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