On 03/20/2012 08:00 PM, Brendan Conoboy wrote:
On 03/20/2012 02:48 AM, Gordan Bobic wrote:
Are alignment problems not considered bugs? It's not just that this will
break code on ARM < v7 and IIRC SPARC, but alignment issues also cause
cache line straddling which has a performance impact.
I took this question to be a case of
knowing-just-enough-about-ARM-to-be-harmful. It's really a non-issue,
particularly since later ARM chips don't have the problem.
I disagree. ARMv5 is going to be around for a while yet, and the fix-up
in software at least needs to be implemented either by default or set as
the very first thing in rc.sysinit:
https://bugzilla.redhat.com/show_bug.cgi?id=673691
Otherwise not paying attention to alignment in something like e2fsprogs
could plausibly trash the file system:
https://bugzilla.redhat.com/show_bug.cgi?id=680090
Even if sloppy programming is not an issue on later ARMs, IMO the
alignment issues should be treated as bugs at least until ARMv5 support
is completely dropped.
Is there any actual reason why Anaconda cannot be used? What is to stop
booting a suitable installation kernel for the target platform and
having that fetch/mount an installation rootfs that takes over, same as
it does in x86? Granted the amount of RAM is an issue, but that's just a
case of dieting the installer back to a saner size (de-lobotomizing the
text mode installer back to how it was before F11, for example).
Anaconda isn't *quite* ready to go yet. And you don't actually gain much
by using Anaconda for many devices- you still have to write an image to
a removal storage device. Which you then run boot... and it writes a new
image to a storage device. You've just made more work for yourself when
you could have installed a working image directly.
In that case you might as well use the same installation procedure on
x86, too - there's no reason not to.
On the server side, PXE abilities mean there's more to be said about
Anaconda support. The only issue is, they don't exist yet :-P
I found that if the kernel has support for the right SoC, it is simply a
case of adding a suitable SoC merge config file and plumbing it in for
the build based on a build flag. I have somewhere a
2.6.32-220.<something> kernel src.rpm that builds for both x86 and
Marvell Kirkwood, and it was reasonably straightforward to achieve (even
if it did require fixing a few bugs that were introduced by upstream
vendor patches that didn't manifest on the primary arch).
Yes, using one kernel source rpm is working fine for us. It's the long
build time which needs to be overcome.
distcc helps.
Gordan
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
