[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Raspberry pi support
Vladimir 'φ-coder/phcoder' Serbinenko
Re: Raspberry pi support
Mon, 08 Apr 2013 14:59:59 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
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
> 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-(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
>> # 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
> -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 proposal.g
Description: OpenPGP digital signature