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. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
