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