[Balloon] [Fwd: Re: balloon bootldr gcc 3 considerations]

CC of reply to bootldr discussion thread.

Nick Bane

-------- Original Message --------
Subject: Re: balloon bootldr gcc 3 considerations
Date: Fri, 10 Mar 2006 11:23:33 +0000
From: Nick Bane <nick@cecomputing.co.uk>
To: Colin Tuckley <colin@tuckley.org>
CC: Wookey <wookey@aleph1.co.uk>, David Bisset
<david_bisset@btinternet.com>, Chris Jones <chris@martin-jones.com>,
Steve Wiseman <steve@steves-house.org.uk>
References: <440EFB52.9080807@tuckley.org>
<440EFE2A.9010404@cecomputing.co.uk> <440F1348.2090108@tuckley.org>
<440F3074.1010309@cecomputing.co.uk> <440F38E4.8010908@tuckley.org>
<440F47A6.7080903@cecomputing.co.uk> <440FF459.1040807@tuckley.org>
<44102564.4060606@cecomputing.co.uk> <44113A43.5050008@tuckley.org>

Colin Tuckley wrote:
> I spent quite a bit of time yesterday working out what was going on when
> using gcc 3.3 to compile bootldr.
>
> Since this has ramifications for Balloon 3 can I ask all 4 of you to please
> comment on the things below.
>
> 1) I'm going to be doing a major clean up of the bootldr code at some point
> in the future and if I don't hear anything I'm going to remove pretty much
> *everything* that is not used or explicitly to do with Balloons.
>
Oh dear.

I pushed yaffs patches back to Handhelds and they have been good enough
to make that part of the official bootldr code. Do we really want to
fork bootldr development?

My preference would be to add config options to isolate unneeded code.
If handhelds do continue bootldr development (extending CF socket usage
and maybe pxa270 usb console usage) then to strip out their work might
be a wrong way of cooperating. I am generally against such a fork unless
there is some policy of avoiding Handhelds. I would prefer to act with
Handhelds and donate a balloon3 to them for inclusion in their efforts.

> 2) After working through all the various options used in the Makefile the
> following has come to light:
>
> a) -UBOOT_SILENT gets added to the compiler options. A grep for this shows
> that it is only referenced once in boot-sa1100.s so why is it *unset* when
> we never set it? or is this just a hangover from something which got
> removed. There are other options in a similar situation what should we do in
> the general case?
>
No idea. Looks like a cleanup candidate. My guess is that it was
probably related to the squelch_serial stuff.

> b) -mshort-load-words is set, this is a deprecated alias for
> -mno-alignment-traps which does nothing on ARMv4 and later processors, I've
> removed it.
>
That was crucial for the initial 2.95 to work for reasons that no one
seemed to understand. You may be right that it is deprecated but I would
like someone to ratify this choice assuming that we want backwards
compatability with 2.95 unless it was deprecated there too.

> c) both -fPIC and -fpic were being added to the options for CC, these do
> subtly different things, which should we be using? not both since they
> actually conflict I think.
>
I have no idea. Looks like more confusion. Do clean that one up. Might
that even be related to the gcc 2.95/3.3 conflict?

> 3) This is probably the most important one, my problems with odd-ball things
> happening due to initialised variables not getting set appear to be due to
> the different optimisations done by gcc 2.95 and gcc 3.3 when the -O (-O1)
> option is set.
>
That is remarkable. For future work it may be very helpful to understand
why gcc 3.3 superficially seems to screw up else we could spend px270
time chasing mirages.
> If I set -O0 (optimisation off) then things work properly. I'm still
> investigating whats actually happening, but so far it looks like gcc 3.3
> includes a lot more optimisation at level 1. The man page mentions 18 flags
> that get turned on in gcc 3.3 at level 1 vs only 4 in gcc 2.95
>
> Is it worth trying to find out which flag is causing the problem and then
> trying to find and fix the bit of code or turn that option off individually?
> Or should we just run bootldr with no optimisation?
>
This is a very good point. I think we should definitely start with
understanding the problem and fixing any rogue code. I was involved in
part of a port of some C code in Sweden a while back where they said
that their code wouldn't "optimise". It turned out that an assembler
patch of theirs was using a register that was involved in optimisation
under gcc but not with the M$ WinCE compilers as I discovered by careful
inspection. In 1/2 day I speeded up their time-critical code by 400%
with that scrat of information.

I know that there were certain assembler options that were useless (for
obscure reasons) with optimisations <O2.

Is there a reason that this is not on-list as it affects the whole
balloonboard community? It may be that Handhelds have a view and we
should include them in at least one cc for their input.

Nick
>
> regards,
>
> Colin
>