[armedslack] EABI ?
m-lists at biscuit.org.uk
Sat Jun 23 12:08:47 UTC 2007
> I don't know what the reasons are to completely abandon the old ABI but
> isn't it possible to make these older ARM versions functional with the
> new EABI?
>From the reading I have done of the Debian EABI port, I am lead to
believe that the answer is no. Debian are supporting ARMv4 -- but I'm
not sure whether that's because they're dropping armv3 support anyway for
their little endian old ABI port, or not. I've asked on #debian-arm on
irc and I'll see what response I get.
> That would extend the useful life of the hardware enormously. I don't
> like throwing away working hardware, I still have some i486 and Pentiums
> lying around, and neither should you.
Heh. Well, The RiscPC isn't exactly the height of excellence in
the range of hardware -- I think it's just that I spent so much
money on it when I bought it, that subconciously I'm protecting
my investment ;-)
I'm barely using the RiscPC now apart from to test the installer every
now and then once I've done enough package updates -- everthing
happens inside QEMU.
> It's really a shame the patch for 2.4 was never integrated into the
> kernel proper and/or updated for 2.6. That would have alleviated the
> process a lot and you could be running the newer Slackware releases on
> your Iyonix. Now for the time being you could just install those in
> chroots and build software that way.
I cannot chroot into it though because we need a 2.6 Kernel with the
glibc in armedslack-current. The Iyonix is reduced to a build host
for -noarch packages and a few other native-only distribution building
scripts which I didn't get around to modifying to run on another host
yet;other than that I may as well turn it off! :-(
> I initially built Slackware MIPS that way from the installed Debian
> system, just until the point that it could become self-hosting after six
> days of building and rebuilding using LFS as a guideline.
That's one way of doing it -- good old Debian :-)
Ah yeah. Thinking about the EABI port I started wondering how I actually
managed to get the original armedslack bootstrapped. I think scratchbox
helped a lot since it had a number of tools and libraries already
available. It's amazing how much stuff, even just during the build
process, relies on things you'd not realise - like perl, ruby and so on.
> I have been looking into your 2.4.27 kernel diff but it's huge and it's
> really time-consuming to try to make sense of it and split it up into
> smaller pieces that I could understand, not that I'm in the least
> knowledgeable about kernel matters anyway :-).
Yeah - Jim had a look at it at one point too and came to the conclusion
that most of it was Debian junk. Why the hell Peter ported it against
a Debian kernel, I don't know. I spoke to Wookey (one of the Debian
devels) and he said he thinks there would not be a lot to do for the
Iyonix with the latest 2.6 kernels. But I'm not even a C programmer so
there is no point in me looking at it -- it'd be like going to those
modern art exhibitions where someone's parcel taped a load of lego men
to some egg boxes and poured moulten nutella over them. I'm like "Well it
looks interesting but I'm not really sure what they're trying to do
Jim also said that you'd definitley need one of the Iyonixes to port it
with. When Peter was doing the intial port he was always using the
serial console since the graphics driver wasn't working.
Castle may lend or give someone a machine if they could port it-- maybe --
I have never asked.
> I could do the same for ARM but where is the cheap ARM hardware that
> should be abounding now that the Windows and the x86 hardware that can
> run it is becoming less and less valuable and relevant?
I know what you mean but most of the ARM boards/devices are embedded stuff
with limited RAM and storage which isn't good for compiling anything... or
they cost a small fortune.
> It's really time for an Acorn Risc Machines renaissance and seeing what
> Lemote have done with their miniature Fu Long computer I am really
> interested in an ARM equivalent as well.
I've decided that what I'll do is release armedslack-12.0 (Slackware 12)
and get it working properly, rather than continually chasing -current.
And once 12.0's working properly, I'll move to making -current with
EABI- even if it means that the RiscPC cannot be used anymore.
More information about the ARMedslack