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