Hello,

I now have a netbook computer with an ARM processor running Ubuntu. Ideally I would like to install FPC and Lazarus on it and do native ARM development. I wonder if it might be possible. Can I cross-compile FPC to get a native FPC running on ARM?

Or at least can I cross-compile my app?

The target will be ARM-Ubuntu, not ARM-WinCE ;=)

Cheers,
Tobias

2011/3/23 Tobias Giesen :

Or at least can I cross-compile my app? The target will be ARM-Ubuntu, not ARM-WinCE ;=)

http://wiki.lazarus.freepascal.org/Setup_Cross_Compile_For_ARM

I run both FPC and Lazarus natively on ARM. The major issue is ensuring that enough memory is available- a Lazarus build wants about 512Mb during link. I've got a couple of issues with the Lazarus IDE that I need to get to the stage where I can raise bug reports but lazbuild works fine.

Mark Morgan Lloyd wrote

I run both FPC and Lazarus natively on ARM.

There is a Wiki page about cross compiling. It would be great to have a wiki page on how to set up a native FPC environment on ARM/Linux.

-Michael

Michael Schnell wrote

On 03/24/2011 08:55 AM, Mark Morgan Lloyd wrote: > I run both FPC and Lazarus natively on ARM. There is a Wiki page about cross compiling. It would be great to have a wiki page on how to set up a native FPC environment on ARM/Linux.

e.g. an "ARM-based development systems" page referenced at http://wiki.lazarus.freepascal.org/Platform_list#Supported_targets_for_ARM

I'd be happy to contribute what I know, but in short the major issue is getting a distro running on the available hardware. And, it must be said, keeping it running: I've seen tales of woe from Sheevaplug users who've ended up with corrupt or bricked systems.

In my case I'm using NSLU2 "Slugs", which are supported by a variant of Debian- once running they can use the standard Debian package repositories. I've made some recent progress towards getting something running on some "PC-like" ARM development boards I've got, but I won't have those up for a few weeks due to other demands on my time.

Mark Morgan Lloyd wrote

e.g. an "ARM-based development systems" page referenced at http://wiki.lazarus.freepascal.org/Platform_list#Supported_targets_for_ARM

leading to http://wiki.lazarus.freepascal.org/Linux_for_ARM which in fact leads to
http://wiki.lazarus.freepascal.org/Compile_and_Develop_on_Maemo_device

which really shows how to get Lazarus working on an Arm-Linux device.

I have no idea what is special about Maemo that might not apply to other Arm-Linux environments, so a more general description could help in many cases.

:-) :-) I, too have an old slug at home and did load debian on same. I fear it is quite low on memory for complex userland stuff.

Completely Off-Topic: (please answer in a private mail): As I have your attention: I want do use the slug either as a ISCSI server or as an NFS server to provide a remote (backup) USB-disks to my (Suse) Linux File server. In case of NFS it would need to support "device mapper", as the disks are managed in volume groups.

What do you think ?

Thanks,
-Michael

2011/3/24 Michael Schnell :

Maemo/MeeGo are arm-linux distro, maemo is based on debian meego on fedora. So I think that the wiki could be used to installa fpc/lazarus on any arm-linux platform. :)

Kjow

So I think that the wiki could be used to installa fpc/lazarus on any arm-linux platform. :)

Sounds great. So maybe Mark could do some testing and enhance the text to be more general.

-Michael

I'll try and read through that but I was thinking of something at the top level which emphasised that it was running on something behaving as "a computer" rather than "an appliance" or "something requiring cross-development".

Well, provided that we don't get into "distro wars" I'm sure limited comment here is acceptable to the list owners since such a thing could also be used for local SVN and so on. I can't speak for the device mapper but I've had no problem at all with NFS on a Slug running Debian "Lenny"- just install nfs-kernel-server and set up /etc/export.

I think that the one thing I'd caution is that NFS is poor at handling symlinks, and I'm not sure where it stands on locking. If you have a server setup that uses symlinks or a client app that requires locking then it might be safer to consider other options [waves hands in air] should they exist.

Michael Schnell wrote

> So I think that the wiki could be used to installa fpc/lazarus > on any arm-linux platform. :) Sounds great. So maybe Mark could do some testing and enhance the text to be more general.

I'll see what I can do, but it might be better if I started off by transcribing my notes into a new page which could then be reconciled.

I had a lot of difficulty at the time that Debian was forcing a transition from ABI to EABI. I think it was Jonas who pointed me at a binary that got me out of some of the problems, but I'm very quick to admit that I don't really know my way around the various non-production versions.

My intention is to install it as a remote backup device using "Dirvish", just moving the now local USB disk box to a remote location on the Ethernet. So my first preference used to be ISCSI, as the Server PC now still just sees some "local" disks below the device manager layer. But NFS should work as well (providing a single disk above the device manager layer), as I _thought_ NFS would easily support hard links (this is what Dirvish heavily relies on) and symlinks (Dirvish backups the symlinks as they are, not following them).

In fact I have no experience at all with any of ISCSI, NFS and Debian, so I did not dare to start the migration yet.

Thanks,
-Michael

Kjow wrote

Maemo/MeeGo are arm-linux distro, maemo is based on debian meego on fedora. So I think that the wiki could be used to installa fpc/lazarus on any arm-linux platform. :)

This one also contains arm platform instructions
http://wiki.freepascal.org/Qt4_Maemo_Binding
|

I did not try the following, but perhaps interesting http://vserver.rosseaux.net/tutorials/fpcn900.php
http://wiki.maemo.org/Compile_FreePascal_on_device http://wiki.freepascal.org/Compile_and_Develop_on_Maemo_device

Some other interesting devices (all Marvell kirkwood based):

- WD GOflex.NET: 128MB but two 2.5" sata ports. First attempt at rooting it failed, and I am waiting for a jtag cable
- IOMega IConnect - 256 MB.

Besides that I have GlobalScale reference equipment, SheevaPlug (512MB) and since about a month an OpenRD.

The latter is particularly interesting since it is effectively a desktop (sata + lots of USB + VGA). I'm planning to install the just new Fedora 13 and need to set up a crosscompile kernel.

Still, I wouldn't advise bying the kirkwood based reference stuff. Quite expensive (specially when ordered from Europe), and the panda board with its dual core and armv7 is more interesting. (but I'm told that the DVI from the Beagle/Panda is digital only)

That OpenRD Ultimate looks interesting. I've got a small number of development boards with most of that (no video) but they're unusual in that they've got PC-style BIOSes and boot CE from a partitioned CompactFlash. I'm hoping to be able to put Open Firmware on the CF which will make it look very much like the Sun etc. systems I'm used to and will save messing around with internal firmware, and from there I should be able to boot Linux from USB.

At this point I need to come clean: I'm aware of one and possibly two bugs that affect the Lazarus IDE on both ARM and SPARC: basically, an exception when switching projects and when closing the IDE. It doesn't happen on x86 and PPC, which suggests to me that it could be an alignment issue. I was hoping to get more familiar with the innards of FPC and Lazarus (not to mention Mantis etc.) before reporting this, meanwhile lazbuild works fine as do generated apps.

I've been thinking about getting one of these:

http://www.genesi-usa.com/products/efika

I need something small and quiet to drive my projector and with the new debian armhf port, the performance could be quite nice, too. Cortex A8 seems like the thing to go for now, with linaro and debian focusing on armv7 + vfp3 mainly.

Henry

I've hacked something into
http://wiki.lazarus.freepascal.org/Native_ARM_Systems based on my notes and an audit of what I've installed on development systems. If anybody has additional detail please add it, in particular if anybody has useful links for things like getting FPC or Lazarus sources over Subversion they could go in.

Another useful page would be on getting/building libgdb- has anybody done this (and if not where should it be)?

I wonder if I could make a suggestion: if anybody adds arcana related to hardware that the rest of the community doesn't have, please initial it so that everybody knows who the expert is :-)

800mhz is a tad slow though. Very affordable though.

The Openrd armv5 1.2GHz seems hardly able to run a modern browser. (I had some embedded firefox variant on my default openrd install)

I'm not sure how much FP a browser uses though (due to scaling requirements it might actually use FP).

Thanks a lot !
Great Work.

I am really astonished to hear that you were to run a graphical desktop on the slug. Could you elaborate on that a little bit ?

Thanks,
-Michael

The Cortex A8 (armv7) is 2 generations newer than the Kirkwood processor on open-rd (armv5). It's got almost twice the DMIPS/MHz. I'd be very surprised if it's slower.

I'm not sure how much FP a browser uses though (due to scaling requirements it might actually use FP).

Driving graphics is also probably a big factor.

Henry

I find that surprising, since I could run Debian's Mozilla on a 32Mb Slug /provided/ that I used FluxBox rather than KDE as the window manager. There is always a possibility that current browsers use vastly more resources than the one with Debian (which isn't exactly famed for being bleeding edge)... but there's also the possibility that they've regressed to the position they shared with Lazarus a couple of years ago of generating far too much X-protocol traffic which made remote operation infeasible.

No problem at all, but a note on administration to start with: every time one of my (Debian) systems boots, it dumps the list of installed packages into RCS so that I can go back later and see what went on when.

Most of the systems around here are set up using a Debian+KDE CD, although I might change that policy in view of the mess that is KDE v4. I install the basics plus checking the box for a desktop system, later I tell it to install gdm since that is the only display manager that handles XDMCP properly- there's a dialog(ue) asking whether this is to be made the default. I also install a VNC server because some app versions (specifically, Lazarus and Mozilla of a couple of years ago) are very slow over remote X, this runs via a script hooked into inittab (not available on ARM).

Since Debian ARM is a network install getting KDE etc. onto the system is fairly expensive in terms of bandwidth, so I tend to do this out of hours. Once the system is set up as above I simply add the fluxbox and xterm packages, I think there's a dialog(ue) asking whether this is to be made the default window manager but in any case there's a gdm option.

That leaves a system with some "extra bits" that I'd rather not have, for example there are both Gnome and KDE user administration programs in the KDE menu. In the case of ARM you can connect to it via X, if that doesn't work check forward and reverse name lookup. I can't remember how you add programs for FluxBox- you might need to edit a .ini file.

I'll see if I can work a bit of that detail into the wiki page, but right now I'm trying to work on other things and would like to give other people an opportunity to hack it around a bit.

As I said earlier, this is slightly moot since I need to bug-report a Lazarus IDE problem. I should have done that some time ago but I didn't want to rock the boat before I was fairly familiar with the way things worked, and to be honest I wasn't expecting a very sympathetic reception if the major platform it affected was SPARC :-)

I assumed it was the browser. It could be the XGI X-Server too.

Henry Vermaak wrote

The Cortex A8 (armv7) is 2 generations newer than the Kirkwood processor on open-rd (armv5). It's got almost twice the DMIPS/MHz. I'd be very surprised if it's slower.

Interesting, do you have an URL to those benchmarks?

Google can get you quite far. ARM9 is usually quoted to have 1.1 DMIPS/MHz:

http://hubpages.com/hub/The-ARM-family

Wikipedia says that Cortex A8 is "up to 2 DMIPS/Mhz". Of course, if you have a floating point intensive app, you can get much bigger gains.

Henry

Everybody knows that benchmarks are odious, but I've got a handy "torture test" that I've run on a variety of systems from a 16-way Sun down to a "Slug". Usefully, this can be used both to get a time to completion of the standard job and a Watt-minutes figure, both of which are significant when choosing systems:

SPARCserver 1000E, 8 jobs, 550W (560VA) 1m51.926s 1,018

E4500 8x SMP 400MHz 4Gb 16 jobs, 772W (845VA) 0m31.025s 399

Compaq ProLiant ML530 G2, 2.8GHz, 3Gb, 8 jobs, 390W 0m12.170 79

Linksys NSLU2, 266MHz 32Mb, 1 job, 7W 6m35.014s 46

It doesn't exercise network functions, but my experience is that these are comparatively cheap compared with compression etc. that it does.

Me too. But I use FPC's "make all" usually. The sheevaplug does about 25minutes doing that (compared to sub 2 minutes on modern Core2 systems). It would be interesting to see how the efika fares. (also 25min I'd expect, since it is at 600MHz half the speed, but twice the DMIPS. But I think it will only do so if it really gets specialized code generated. So we'll probably have to compile something with gcc to benchmark too, assuming that gcc can already generated optimized code)

I looked up Henry's comments, and I can also only find the "(up to) 2 DMIPS)" remark, but no actual benchmarks. (only subjective "feels faster" remarks)

The fun part of using FPC as benchmark is that it is not a synthetic benchmark, and not purely number crunching, and as it doesn't use highly optimized libraries, it gives a good impression of how memory intensive business code will perform. So I actually use it at work to get an impression of new HW.

In the past, the linux kernel compile was used as a benchmark figure a lot, and I'm somewhat sad that the benchmarking community dropped that.

Hello,

many thanks for all the help!

If anybody is looking for an ARM device, the Toshiba AC100 is pretty cool. Around 200 EUR with Cortex A9 dual core and 512 MB RAM. It is a netbook computer and has HDMI as well as USB. Mine has an 8GB SSD. It comes with Android 2.1 (a 2.2 update is available).

It takes quite a bit of hacking to get Ubuntu installed onto it, but then you get a full Linux with Gnome on a real computer, not just a small ARM device. All the info you need is available on the Internet (I can put together a few links if anybody needs them).

Cheers,
Tobias

Marco van de Voort wrote

It would be interesting to see how the efika fares. (also 25min I'd expect,

Google translate if your French is rusty.
http://www.blogarm.net/test-du-genesi-efikamx-smartbook-par-pipou24/ http://www.blogarm.net/froyo-enfin-disponible-pour-le-ac100/

Anything relevant to "real computers" would be really appreciated at http://wiki.lazarus.freepascal.org/Native_ARM_Systems

Tobias Giesen wrote

If anybody is looking for an ARM device, the Toshiba AC100 is pretty cool. Around 200 EUR with Cortex A9 dual core and 512 MB RAM. It is a netbook computer and has HDMI as well as USB. Mine has an 8GB SSD.

Hmm, would be a nice system to improve fpc arm eabi support on modern ARM CPUs :)

Hi,

apparently the binary release 2.2.2 for ARM does not run on Cortex A9, I get "Illegal instruction". So I will try to do cross-compiling next.

Cheers,
Tobias

I was excited when I saw the AC100, but it comes with Android (!?) and it got spectacularly low reviews (10%, or so). Seeing Ubuntu on it now sounds promising, though.

Henry

Michael Schnell wrote

In fact I have no experience at all with any of ISCSI, NFS and Debian, so I did not dare to start the migration yet.

Triggered by this discussion, in the weekend, I took my Slug out of the cupboard, updated Debian to the most recent distribution and found:

- The NFS Kernel-Server already is in place
- The LVM (Logical Volume Manager / Device Mapper) already is in place. :)
- The "automount" file system already is in place :)
- I was able to publish a local directory via NFS just by writing the appropriate information in the "/etc/exports" file and restarting the nfs-kernel-server :)
- I was able to make my Suse Box automount this NFS share read it and re-publish it via SMB :)
- Unfortunately, the NFS share is read-only on the Suse Box (using only root user at both sites), even tough "mount" says read-write, and "rw" is enabled in the "exports" file :( .
- Unfortunately, on the Slug, automount does not seem to create the subdirectory given in the /etc/auto.xxx file denoted by /auto/auto.master, so that I can't automount the USB disks yet :( .
- I did not yet try to attach an existing LVM disk to the slug (but I do know that I need to issue some commands to make the system see it and make it usable for mounting. ;)

Moreover ion the Suse-Box I tested that creating and using hard links and symlinks on a NFS-remoted device works just fine. :)

-Michael

Henry Vermaak wrote

I was excited when I saw the AC100, but it comes with Android (!?) and it got spectacularly low reviews (10%, or so). ?Seeing Ubuntu on it now sounds promising, though.

I have AC100 in my office. Remember that if you have Android installed don't think that you will be able to use it as a development platform. Android pretty much kills this possibility because:
* There is no user-acessible console
* Users cannot run native apps (like FPC, binutils, etc)
* No appropriate text editor, no appropriate IDEs
* Strict permissions
* No SDK which runs in Android (the requirements to get the Android SDK working are huge anyway)

In short, if you just want to test installing software cross-compiled from the PC, then you might just as well buy a phone. If you want to actually develop on the platform, you really need to get rid of Android and install a standard Linux. If you manage to do that, then AC100 with a USB mouse might actually be a good ARM test platform for developers.

Michael Schnell wrote:
...

- Unfortunately, the NFS share is read-only on the Suse Box (using only root user at both sites), even tough "mount" says read-write, and "rw" is enabled in the "exports" file :( .

look at the no_root_squash export option

- Unfortunately, on the Slug, automount does not seem to create the subdirectory given in the /etc/auto.xxx file denoted by /auto/auto.master, so that I can't automount the USB disks yet :( .

submounts need to be reexported
Unless you are using nfs4 and have some option enabled (haven't figured that one out yet)

Marc

Not true.
My son just bought an android phone. Within just a few minutes he had an App up and running that gave him a console window (including a keyboard on the touch screen, as his device does not have a physical keyboard). He did not have root access then, but he said there are instructions found on the Internet how to do this.

* Users cannot run native apps (like FPC, binutils, etc)

Not true. On this forum I recently found a link to instructions on how to install an FPC program on an Android device.

* No appropriate text editor,

I am positive that editor Apps easily can be found

no appropriate IDEs

As FPC programs do run and I seem to remember that there are several ways (with pros and cons) to make them create a GUI, I do suppose that someone will make Lazarus run some day soon.

* Strict permissions

I am positive that they are breakable, given that the software is open source, GPL licensed, mostly community driven, and there is a lot of public interest in giving knowledgeable users all permissions they want.

-Michael

Marc Weustink wrote

look at the no_root_squash export option

Thanks a lot ! I'll try this.

Hmm.
I'll recheck, but in fact this had been tested without any NFS binding. Just trying to mount a volume on an USB stick, which I had been able to mount easily with the "mount" command.

And even with nothing mountable available, I think the appropriate mount points given in auto.xxx should be created by "autofs" just when staring it.

Thanks again,
-Michael

Did you do so?

Well, be my guest and try to write software in AC100 (or any other Android device) =) And then we can discuss again.

No, not really. In my work all development is done via cross-compiling.

Felipe Monteiro de Carvalho wrote

> Did you do so? No, not really. In my work all development is done via cross-compiling.

I didn't even previously know that it is possible to install Linux in AC100, found out with Henry Vermaak's message. Some issues which come to my mind about doing that:
* Will the WiFi keep working?
* Will one be able to mount the sdcard? (I doubt it)

:-) but don't try building Lazarus on it- it will take a week.

Mark Morgan Lloyd wrote

:-) but don't try building Lazarus on it- it will take a week.

Thanks for the warning :-) :-) .

It's just supposed to be a remote host attaching the backup drives to the network. Its usual work is receiving the files when the main server does the nightly backup.

-Michael

I didn't even previously know that it is possible to install Linux in AC100, found out with Henry Vermaak's message. Some issues which come to my mind about doing that: * Will the WiFi keep working?

Yes, with some simple tweaks. But I am now using a USB Ethernet adapter because I didn't have enough time to do those tweaks. But there is a lot of user reports and guides on how to do it on the Internet.

* Will one be able to mount the sdcard?

Yes. In fact most users boot from it in order to be able to keep the original SSD contents.

I've got Ubuntu working fine on the AC100, I just need to get the (cross-)compile working now.

Kind Regards,
Tobias Giesen

"To avoid a reboot, make sure that no SuperFlexible or ExtremeSync processes are running in Task Manager before installing an update."

Super Flexible Software Ltd. & Co. KG
Lessingstr. 42
48485 Neuenkirchen, Germany
www.superflexible.com
www.tgtools.com

----------------------------------------------------------- Registered at register court Steinfurt as HRA 5061 Liability / general partner: TGTools Ltd.
Company No. 05513299
Registered in England and Wales
Directors: Tobias Giesen and Claudia Giesen

Michael Schnell wrote

On 03/28/2011 12:43 PM, Marc Weustink wrote: > look at the no_root_squash export option Thanks a lot ! I'll try this.

Works !

Thanks a lot !

-Michael

i.e. it does work magically.

While on the Suse Box in the automount master directory, the mount points taken from the automount.xx file, where automount will mount the file systems in question can be seen by doing ls, on the slug, no directories are shown, but when doing a cd to the no t yet existing directory it is auto-created and automounted so it just works.

Thanks,
-Michael

Thanks a lot for the push !!!

It works. And it's astonishingly fast.

-Michael

Hmm, I'am still looking for a reasonable system for arm eabi development.

A long time ago I tried compiling Lazarus natively on the N900 (Maemo), it didn't work due to some arm resource compiling problems. As cross compiling work like a charm, I did not try for some time. Now with a recent trunk of fpc and lazarus, Lazarus compiles and runs on the device. The advantage of Maemo is that it is a fairly standard Linux (debian based, apt-get install whatever)
with a Qt source compatible with Desktop Qt.

Nevertheless Lazarus on the device is not usable due to the many windows of Lazarus that all get maximized and some other small problems. Lazarus can compile and run the default application project.

Screenshots:
The first screenshot is the alt-tab equivalent (composited window manager program/window switcher)

http://users.telenet.be/Jan.Van.hijfte/qtforfpc/N900/LazN900_AltTab.png http://users.telenet.be/Jan.Van.hijfte/qtforfpc/N900/LazN900_Editor.png http://users.telenet.be/Jan.Van.hijfte/qtforfpc/N900/LazN900_Main.png http://users.telenet.be/Jan.Van.hijfte/qtforfpc/N900/LazN900_ObjectInspector.png

regards,

Den Jean

That's interesting. I've now got 0.9.30 compiled to run natively on my development "Slug" and still get an exception when changing project or exiting- I was about to start a bug report. If you've got it running reliably that might localise the problem to a range of CPUs.

Now reported as 0019109.