From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.aribaud@free.fr>
Date: Tue, 05 Oct 2010 12:33:01 +0200
Subject: [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
In-Reply-To: <4CAAF0E3.20801@emk-elektronik.de>
References: <1286260287-1571-1-git-send-email-albert.aribaud@free.fr>
	<20101005064516.AEA4C153A7E@gemini.denx.de>
	<4CAACE47.5090105@emk-elektronik.de>
	<4CAAD255.1080501@emk-elektronik.de>
	<4CAAD944.2040309@emk-elektronik.de> <4CAAE2C5.4040304@denx.de>
	<4CAAE4BF.3030306@free.fr> <4CAAE949.1010200@denx.de>
	<4CAAEB84.2070602@emk-elektronik.de> <4CAAECA1.8090903@denx.de>
	<4CAAEDAE.9040908@emk-elektronik.de> <4CAAEFDF.5080803@denx.de>
	<4CAAF0E3.20801@emk-elektronik.de>
Message-ID: <4CAAFEDD.4060005@free.fr>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Le 05/10/2010 11:33, Reinhard Meyer a ?crit :
> Dear Heiko Schocher,
>>> start = first entry, end = address AFTER last entry,
>>> so it should be "blt", or?
>>
>> Yep. But I think, ble is right ... we should know, why this
>> entry is filled with 00000000
>
> No, we want a loop through all entries:
>
> start:	1st entry
> 	2nd entry
> 	...
> 	last entry
> end:
>
> so it must be:
>
> for (p = start; p<  end; p += 8)
> 	work;
> and not
>
> for (p = start; p<= end; p += 8)
> 	work;
>
> Reinhard

Indeed, hence my post on 'blo' vs 'ble'. Note that the same erroneous 
'ble' was used throughout start.S, for instance in the source-to-target 
copy loop and in the bss clear loop, which means those two had a latent 
bug since long ago.

It seems like fixing this 'ble' bug and adding Graeme's DISCARDs gives 
us a pretty good candidate for actual patch submission. If no one finds 
a serious blocker, I'll submit a patch set tonight french timezone.

As for splitting the thing into individual patches, I would like some 
advice. Obviously a first patch could be the bugfix to the ble/blo 
issuein existing start.S, and the last patch shall be the change to 
edminiv2.

My problem is with the essential part: changing only the compile and 
link options in arm, or changing only the start.S and u-boot.lds in 
arm926, produces a nonworking, non-buildable, tree. So it would seem 
that all of this should go in a single patch in order to remain bisectable.

However, changing arm without changing other cpus than arm926 would 
break build on these, so a bisectable change would require a single 
patch to arm and all its cpus. Seems a bit big for me.

Wolfgang, Heiko, your advice is sought.

Amicalement,
-- 
Albert.