ARM

jnml · 2013-01-10 05:37

I would like to build progcc from sources on an ARM Linux(1). It seems(2) that the only missing piece would be the `bstc` prerequisite binary. Anyone aware of a solution to this? Note that AFAIK, bstc is not open sourced, so I think I cannot build it by myself. The overall goal is to attempt hot building (configuration parameters based) a Propeller program as we anticipate that all of the possible supported modules (for several different HW sensors) are not going to fit into Propeller's memory together - and normally only a combination of few of them are really needed. Propeller reports to an Linux ARM master with the configuration file(s), hence the idea of building the firmware there and sending it to the Propeller at power-up.

Thanks in advance for any help ;-)

-j

(1)

$ uname -a
Linux debian-armel 2.6.32-5-versatile #1 Wed Jan 12 23:05:11 UTC 2011 armv5tejl GNU/Linux

(2) The build process is running w/o trouble up to now (for several minutes - in QEMU actually).

mindrobots · 2013-01-10 06:06

Search the forum for PropGCC and raspberrypi or raspi. There's a gentleman by the handle of Heater that has built it for the Raspberry Pi. He's detailed the steps he went through.

jnml · 2013-01-10 06:40

mindrobots wrote: »

Search the forum for PropGCC and raspberrypi or raspi. There's a gentleman by the handle of Heater that has built it for the Raspberry Pi. He's detailed the steps he went through.

Thanks a lot! After reading some of the relevant threads, pointed to by you, it even looks like the build may "just" succeed, as I tar-copied the existing PC repository including all of the *.dat files made by the PC build. I'll try to report the outcome later - the build is still running.

-j

Heater. · 2013-01-10 08:41

propgcc builds easily on the Raspberry Pi. Even if it takes over 12 hours! Qemu was not much quicker.
The trick is, as you have seen, to build it first on a PC then copy those dat and bin files over to your ARM.
However there was a file or two that seemed to get deleted after the build, I could never find them any way. Can't remember which ones now.
I had to hack with loader makefile to get it to copy those to a safe place as it built them.
I also have a version of the loader that will use the uart on the Pi GPIO pins if you need that.

jnml · 2013-01-10 08:56

Heater. wrote: »

propgcc builds easily on the Raspberry Pi. Even if it takes over 12 hours! Qemu was not much quicker.
The trick is, as you have seen, to build it first on a PC then copy those dat and bin files over to your ARM.
However there was a file or two that seemed to get deleted after the build, I could never find them any way. Can't remember which ones now.
I had to hack with loader makefile to get it to copy those to a safe place as it built them.
I also have a version of the loader that will use the uart on the Pi GPIO pins if you need that.

Thank you very much for the info and also for your kind offer to help me - will be used gratefully, if I'll get stuck or similar.

EDIT: I should have noted this before: Our target system is Phytec's Phycard-L.

-j

PS: The build process is still running smoothly, but I'm already leaving the office in minutes. Let's see what I'm gonna find here in the morning ;-)

jazzed · 2013-01-10 09:35

We could build the .dat files from source when Roy (or someone else) adds the pre-processor option in the open-source spin compiler.

The alternative would be to remove the pre-processor dependencies.

Heater. · 2013-01-10 15:37

Can't we build those DAT files with HomeSpun which runs under Mono on Linux?

Not sure if the is a working Mono for my Raspian RPi but I'm sure I had it working a while back on another ARM board running Linaro.

jnml · 2013-01-11 00:17

Build finished w/ error. Last few dozen lines are:

t-doubles/tiny/scanf_getl.o ../../../build/lib/obj/xmm/short-doubles/tiny/gethex.o ../../../build/lib/obj/xmm/short-doubles/tiny/getdec.o ../../../build/lib/obj/xmm/short-doubles/tiny/getudec.o ../../../build/lib/obj/xmm/short-doubles/tiny/getfnum.o ../../../build/lib/obj/xmm/short-doubles/tiny/scanf_getll.o ../../../build/lib/obj/xmm/short-doubles/tiny/getlhex.o ../../../build/lib/obj/xmm/short-doubles/tiny/getldec.o ../../../build/lib/obj/xmm/short-doubles/tiny/getludec.o ../../../build/lib/obj/xmm/short-doubles/tiny/getlfnum.o ../../../build/lib/obj/xmm/short-doubles/tiny/c++-alloc.o ../../../build/lib/obj/xmm/short-doubles/tiny/tinystream.o
propeller-elf-ar: creating ../../../build/lib/obj/xmm/short-doubles/libtiny.a
make[2]: Leaving directory `/root/src/gitlab.schleibinger.com/propgcc/lib/tiny'
make[1]: Leaving directory `/root/src/gitlab.schleibinger.com/propgcc/lib'
cp ../../build/lib/obj/lmm/libtiny.a /opt/parallax/propeller-elf/lib/
cp ../../build/lib/obj/lmm/short-doubles/libtiny.a /opt/parallax/propeller-elf/lib/short-doubles/
cp ../../build/lib/obj/cmm/libtiny.a /opt/parallax/propeller-elf/lib/cmm/
cp ../../build/lib/obj/cmm/short-doubles/libtiny.a /opt/parallax/propeller-elf/lib/cmm/short-doubles/
cp ../../build/lib/obj/xmmc/libtiny.a /opt/parallax/propeller-elf/lib/xmmc
cp ../../build/lib/obj/xmmc/short-doubles/libtiny.a /opt/parallax/propeller-elf/lib/xmmc/short-doubles/
cp ../../build/lib/obj/xmm/libtiny.a /opt/parallax/propeller-elf/lib/xmm/
cp ../../build/lib/obj/xmm/short-doubles/libtiny.a /opt/parallax/propeller-elf/lib/xmm/short-doubles/
cp tiny/tinyio.h tiny/tinystream.h tiny/tinystream tiny/siodev.h /opt/parallax/propeller-elf/include
make: Entering directory `/root/src/gitlab.schleibinger.com/propgcc/loader'
make: Leaving directory `/root/src/gitlab.schleibinger.com/propgcc/loader'
make: Entering directory `/root/src/gitlab.schleibinger.com/propgcc/loader'
mkdir -p ../../build/loader/bin/linux
mkdir -p ../../build/loader/obj/linux
../../build/loader/bin/linux/bin2c
../../build/loader/obj/linux/propeller-load.o
src/loader.c: In function &#8216;WriteFileToSDCard&#8217;:
src/loader.c:1008: warning: format &#8216;%ld&#8217; expects type &#8216;long int&#8217;, but argument 2 has type &#8216;size_t&#8217;
src/loader.c:1015: warning: format &#8216;%ld&#8217; expects type &#8216;long int&#8217;, but argument 2 has type &#8216;size_t&#8217;
../../build/loader/obj/linux/loader.o
../../build/loader/obj/linux/lmm-image.o
../../build/loader/obj/linux/xmm-image.o
../../build/loader/obj/linux/pex-image.o
../../build/loader/obj/linux/loadelf.o
../../build/loader/obj/linux/packet.o
../../build/loader/obj/linux/PLoadLib.o
../../build/loader/obj/linux/config.o
../../build/loader/obj/linux/expr.o
src/system.c: In function &#8216;xbAddProgramPath&#8217;:
src/system.c:133: warning: implicit declaration of function &#8216;readlink&#8217;
../../build/loader/obj/linux/system.o
../../build/loader/obj/linux/port.o
/opt/parallax/bin/bstc.linux: 1: Syntax error: "(" unexpected
make: *** [../../build/loader/obj/linux/serial_helper.binary] Error 2
make: Leaving directory `/root/src/gitlab.schleibinger.com/propgcc/loader'
loader make failed
~/src/gitlab.schleibinger.com/propgcc$

I'll only now start to investigate the results (what was and what was not build). Just wanted to share the status. Also someone might be able to spot some trouble in the build output. BTW, the build was invoked using `./rebuild.sh`.

More info: We are using a git clone of the hg repository (in intranet Gitlab). The source of the git clone was:

(09:00) jnml@fsc-r550:~/src/code.google.com/p/propgcc-hg$ hg summ
parent: 1688:955aeee6df73 
 output _ret labels only for native functions
branch: compressedcode
commit: (clean)
update: (current)
(09:00) jnml@fsc-r550:~/src/code.google.com/p/propgcc-hg$ hg log | head
changeset:   1712:e06f27998d46
branch:      performance
tag:         tip
parent:      1710:d998fcbf30f3
user:        Eric Smith <ersmith@totalspectrum.ca>
date:        Sat Oct 13 20:48:15 2012 -0300
summary:     start work on new debug framework


changeset:   1711:3a482b095db7
parent:      1709:a843b4df354f
(09:00) jnml@fsc-r550:~/src/code.google.com/p/propgcc-hg$

I have made same minor patches, at least one of them is a bug fix, which should perhaps be incorporated back to the master repository (at googlecode). What is the best procedure/practice to send patches for bug fixes and/or proposed changes*?

-j

*: For example, we had to support parity for some serial devices, so there is a patched FDS supporting optionally that using an additional parameter like `fopen("FDS:115200,4,5", "r+");` (backward compatible) or `fopen("FDS:115200,6,7,O", "r+")` (use odd parity). Also sending 'break' was added to the driver.

Heater. · 2013-01-11 00:32

jnml,

Actually looks good!

It has failed buiding the loader. And as we exepected is complaning about the lack of bastc "/opt/parallax/bin/bstc.linux
1: Syntax error:"

Now I seem to remeber that the loader is about the last thing built so you may well find working compiler binaries and tools in /opt/parallax/bin.

I think what I did next was create and empy file called bstc.linux in /opt/parallax/bin/ and give it execute permissions.
Then change to the loader directory in the gcc sources and run the run the build steps for it manually.
Or the long way around is to do the entire build again.

Anyway the loader will then fail when it finds the empty script we created for bstc has no created the dat and bin files. You can the copy those files to the place the loader build expects them to be and continue.

jnml · 2013-01-11 02:05

Heater. wrote: »

jnml,

Actually looks good!

It has failed buiding the loader. And as we exepected is complaning about the lack of bastc "/opt/parallax/bin/bstc.linux
1: Syntax error:"

Now I seem to remeber that the loader is about the last thing built so you may well find working compiler binaries and tools in /opt/parallax/bin.

I think what I did next was create and empy file called bstc.linux in /opt/parallax/bin/ and give it execute permissions.
Then change to the loader directory in the gcc sources and run the run the build steps for it manually.
Or the long way around is to do the entire build again.

Anyway the loader will then fail when it finds the empty script we created for bstc has no created the dat and bin files. You can the copy those files to the place the loader build expects them to be and continue.

After following all of your hints and a little bit of hacking, I'm now here:

root@debian-armel:~/src/gitlab.schleibinger.com/propgcc/loader# ./build.sh
OS 'Linux' detected.
bin/linux/bin2c
obj/linux/serial_helper.c
obj/linux/serial_helper.o
obj/linux/flash_loader.c
obj/linux/flash_loader.o
obj/linux/osint_linux.o
bin/linux/propeller-load
include/c3_cache.dat
include/c3_cache_flash.dat
include/ssf_cache.dat
include/dracblade_cache.dat
include/sdram_cache.dat
include/eeprom_cache.dat
include/sd_cache.dat
include/spi_flash_cache.dat
include/sst_sqi_flash_cache.dat
include/spi_sram_cache.dat
include/winbond_sqi_flash_cache.dat
include/synapse_cache.dat
include/sd_driver.dat
make -C sdloader BUILDROOT=/root/src/gitlab.schleibinger.com/propgcc/loader
make[1]: Entering directory `/root/src/gitlab.schleibinger.com/propgcc/loader/sdloader'
propeller-elf-gcc -Os -Wall -mlmm -c sd_loader.c -o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sd_loader.o
/root/src/gitlab.schleibinger.com/propgcc/loader/obj/sd_loader.o
propeller-elf-gcc -Os -Wall -mlmm -c fatread.c -o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/fatread.o
/root/src/gitlab.schleibinger.com/propgcc/loader/obj/fatread.o
propeller-elf-gcc -Os -Wall -mlmm -c sdio.c -o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sdio.o
/root/src/gitlab.schleibinger.com/propgcc/loader/obj/sdio.o
propeller-elf-gcc -Os -Wall -mlmm -c vm_start.S -o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/vm_start.o
/root/src/gitlab.schleibinger.com/propgcc/loader/obj/vm_start.o
propeller-elf-gcc -Os -Wall -mlmm -o /root/src/gitlab.schleibinger.com/propgcc/loader/include/sd_loader.elf /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sd_loader.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/fatread.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sdio.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/vm_start.o
propeller-elf-gcc -Os -Wall -mlmm -c sd_cache_loader.c -o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sd_cache_loader.o
/root/src/gitlab.schleibinger.com/propgcc/loader/obj/sd_cache_loader.o
propeller-elf-gcc -Os -Wall -mlmm -o /root/src/gitlab.schleibinger.com/propgcc/loader/include/sd_cache_loader.elf /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sd_cache_loader.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/fatread.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sdio.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/vm_start.o
make[1]: Leaving directory `/root/src/gitlab.schleibinger.com/propgcc/loader/sdloader'
bin/linux/bin2c
bin/linux/propeller-load
include/c3_cache.dat
include/c3_cache_flash.dat
include/ssf_cache.dat
include/dracblade_cache.dat
include/sdram_cache.dat
include/eeprom_cache.dat
include/sd_cache.dat
include/spi_flash_cache.dat
include/sst_sqi_flash_cache.dat
include/spi_sram_cache.dat
include/winbond_sqi_flash_cache.dat
include/synapse_cache.dat
include/sd_driver.dat
make -C sdloader BUILDROOT=/root/src/gitlab.schleibinger.com/propgcc/loader
make[1]: Entering directory `/root/src/gitlab.schleibinger.com/propgcc/loader/sdloader'
propeller-elf-gcc -Os -Wall -mlmm -c sd_loader.c -o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sd_loader.o
/root/src/gitlab.schleibinger.com/propgcc/loader/obj/sd_loader.o
propeller-elf-gcc -Os -Wall -mlmm -c fatread.c -o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/fatread.o
/root/src/gitlab.schleibinger.com/propgcc/loader/obj/fatread.o
propeller-elf-gcc -Os -Wall -mlmm -c sdio.c -o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sdio.o
/root/src/gitlab.schleibinger.com/propgcc/loader/obj/sdio.o
propeller-elf-gcc -Os -Wall -mlmm -c vm_start.S -o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/vm_start.o
/root/src/gitlab.schleibinger.com/propgcc/loader/obj/vm_start.o
propeller-elf-gcc -Os -Wall -mlmm -o /root/src/gitlab.schleibinger.com/propgcc/loader/include/sd_loader.elf /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sd_loader.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/fatread.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sdio.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/vm_start.o
propeller-elf-gcc -Os -Wall -mlmm -o /root/src/gitlab.schleibinger.com/propgcc/loader/include/sd_cache_loader.elf /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sd_cache_loader.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/fatread.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/sdio.o /root/src/gitlab.schleibinger.com/propgcc/loader/obj/vm_start.o
make[1]: Leaving directory `/root/src/gitlab.schleibinger.com/propgcc/loader/sdloader'
mkdir -p ../../../build/loader/bin
mkdir -p ../../../build/loader/propeller-load
cp -f ./bin/linux/propeller-load ../../../build/loader/bin
cp -f ./include/* ../../../build/loader/propeller-load
cp -f include/* ../../../build/loader/propeller-load
cp ./bin/linux/* /opt/parallax/bin/.
-rwxr-xr-x 1 root root 6976 Jan 11 09:52 /opt/parallax/bin/bin2c
-rwxr-xr-x 1 root root 90148 Jan 11 09:52 /opt/parallax/bin/propeller-load
Build complete.
root@debian-armel:~/src/gitlab.schleibinger.com/propgcc/loader#

Yeah!

Many thanks again to all of you which helped me. Next step is to copy all of the necessary bits from QEMU to the real thing and make it work there. I'm quite optimistic about it.

-j

Heater. · 2013-01-11 03:42

Well done!
I'm sure it will move over from QEMU, I have done that a few times.

Does your ARM board have some HDMI output or similar? If so you could get SimpleIDE running there as well.

This is a nice positive note for my 5000th post !

jazzed · 2013-01-11 12:42

Great Job.

Now you can start using this: $ jbuild.sh 2

That says use multi-make with 2 jobs.

Maybe your arm doesn't have 2 cores, but the extra scheduling forces linux to work harder and finish faster.
The rebuild.sh is good for debugging builds (or first builds) since it specifies just 1 job as normal.

@Heater does homespun offer a -c like option?
That option allows extracting pasm dat sections to a separate file in spin and bstc.linux programs.
Unfortunately the open-source spin does not handle #defines yet.

Heater. · 2013-01-11 16:03

According to the HomeSpun web page it supports -c like so:

-c - generates a .dat file containing the top object's DAT data.

I have never tried it and don't have the means to at the moment.

ersmith · 2013-01-12 06:02

spin2cpp can generate .dat files with the --dat option, and it's open source and pretty portable. We could probably use that to build all the .dat files required. I'm not sure if there's any actual Spin code that needs to be compiled though -- spin2cpp won't generate spin bytecodes, although perhaps LMM compiled Spin code would work instead. When I get a chance I'll look into it.

ARM

Comments