[ARMedslack] Building software on ArmedSlack

[Niels Horn]

On Mon, Feb 15, 2010 at 9:20 PM, Stuart Winter <m-lists at biscuit.org.uk> wrote:
>
> Hi Niel
>
>> I noticed most of armedslack is built with the "-march=armv4t" flag.
>> Slackware on the other hand uses "-march=armv4 -mtune=xscale" if the
>> architecture is set to "arm" and "-march=armv4t" if set to "armel".
>
> This is old stuff for when I was planning on having two ports: arm would
> be "old abi" and armel "EABI".
> Now there is only one going forward, "arm" for EABI.
>
> -march=armv4 -mtune=xscale is for the Old ABI, ARMedslack 12.2
> -march=armv4t is for EABI, -current.
>

OK, that clarified it. :)

> There are only a couple of the build scripts in Slackware which could be
> used directly without modification: xap/pidgin, xap/blackbox (in the next
> round of updates) and ap/linuxdoc-tools.
> It's not too much effort to update the Slackware build scripts to run on
> ARMedslack - typically all I do is merge the main content into my template
> scripts; it's rare to have to patch or modify.
>

I took a look at the pidgin SlackBuild from Slackware-current. It
would be very nice to have a unified standard between Slackware /
ArmedSlack / Slack/390. (I use the first two and play with the third)
to make things simpler. Since I maintain some packages on
SlackBuild.org, having this "unified standard" interests me so that I
can maintain my builds for all platforms.

>> I've been using "-march=armv4" for now and the compiled packages are
>> working fine.
>
> For 12.2 this is ok but -current should be armv4t.
> I actually can't remember why not to use armv4 on -current - I think I
> tried it once when I forgot to update a build script, and got weird
> results.
>

Well, the (very few) packages I built are working under
armedslack-current without problems. But I just tried a few simple
things until now and Hercules was my first "big" project.

>> I would like to be able to build packages that work on both the
>> SheevaPlug and in Qemu, so that I can use one as a test setup before
>> deploying on the other. On the other hand, I would like to get the
>> best performance possible. :)
>
> The userland is all the same and both are armv5.  The only different
> packages are the kernels which you need for ARM.
>

OK, that makes things simpler. I guess 99% I can build using armv4t as
this is the standard.

> QEMU:
> Linux slackware 2.6.32.7-versatile #2 PREEMPT Sun Jan 31 21:57:08 GMT 2010
> armv5tejl GNU/Linux
>
> Sheevaplug:
> Linux zaden 2.6.32.8-kirkwood #2 PREEMPT Sun Feb 14 21:29:38 GMT 2010
> armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board
> GNU/Linux
>
> If you want the better performance, you could compile it for armv5t but I
> doubt you'd notice any difference.  ARMedslack is compiled for armv4t
> because it's the lowest ARM CPU still just about sensible to use and there
> are many of them in the field.
>

I will rebuild Hercules with armv5t. As it is an emulator, every
microsecond counts. :)

>> As an example, I built Hercules (the mainframe emulator) under
>> armedslack and it runs reasonably under Qemu.
>
> You built an emulator inside an emulator?!  what is your x86 hardware?!
> QEMU isn't exactly that fast for me even on a reasonable machine!
>

Yes, but this was only to test the concept. The idea is to use
Hercules on my SheevaPlug when it arrives. Then I can carry a
mainframe around in my bag :D
My x86 system is a "Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU
E8400  @ 3.00GHz", running Slackware64-current, with 4GB of memory and
1.2TB of hard drives.
For the older mainframe operating systems like MVS (from decades ago),
it actually works reasonably well even under Qemu.
The idea of using Qemu is that it works nice with snapshots, so I can
fall back to a stable installation if I mess things up.
But OK, I am known to do unusual things with emulators and virtual machines :)

Thanks for the information and keep up the good work!

Niels