Am 22.12.2010 08:02, schrieb Albert ARIBAUD:
Le 22/12/2010 01:11, Alexander Holler a écrit :
Am 21.12.2010 21:04, schrieb Dirk Behme:
On 21.12.2010 20:52, Wolfgang Denk wrote:
Dear Albert& friends,
what is your opinion? Should we include the memory barrier patch into the upcoming release (and eventually delay it for further testing), or release as is and solve this issue in the next release?
I tend to leave it as is, as I expect that most people will disappear in the next few days for holidays, so no much testing will be done anyway, and we then can solve this with less pressure in the next release - but I'm not really sure if this is a good idea?
I somehow tend to leave it as is, too.
We have issues with some recent compilers. For these we found a fix using the io.h somehow the same way the Linux kernel does. But this introduces new issues for us, we haven't found a proper fix yet (except changing the code to the 'old' io.h style). But we don't know where we might have this issue additionally, yet.
The only real problem found with that patch was one with a register which doesn't like an (unmotivated) read after write.
Yes, and this is enough for me to not want it right away: we caught this one, but how many others, so far unseen, will creep up?
On the other side, without that patch, using gcc>= 4.5.x (at least on arm) proved to fail. In contrast to that problem of gcc 4.5.x ignoring that volatile, 4.5.x still fixes many bugs for arm and gcc>= 4.5.x is necessary for hardfloat. So it's likely that more people will start using 4.5.x (4.5.2 was just released).
Do we need hard floating point in u-boot? IIRC, and unless this changed, the kernel does not want floating point, so I wonder why u-boot would.
Most people won't use U-Boot as base for the decision which compiler version to use.
As for getting 4.5 to work, for the next cycle people can still use pre 4.5 gccs / toolchains, so this is important but not urgent to the point of rushing decisions.
I've just written down my opinion.
Regards,
Alexander