hi all

i managed to build a ppcarm (msb) over the last couple of days. there were a couple of problems, most problematic of which were that the compiler (ppccrossarm at that stage) seemed to go into a weird "state" when trying to compile the gtk and gtk2 packages (can't remember specific files now). running top showed that it appeared to be working, but it never finished (given 10 or 20 minutes), so had to be aborted. i just hacked the makefile to exclude those packages, since i don't need them anyway. this is just for info, really. i used fpc 2.0.4 and i guess i really should've used latest svn.

demo programs and such worked well, i could link to my shared libs that were built with gcc and everything goes well until i try some floating point math - at which point it hangs. the arm processor that i'm using doesn't have an fpu and i had to use a libgcc emulation when i built my shared libs with gcc, so i guess i need to do the same thing with ppcarm (i noticed the -Cf<xx> option).

will i need to re-build my ppcarm and the units to use libgcc floating point emulation? if so, how would i do that? (a simple OPT="-CfLIBGCC" doesn't work on the make command line, since it tries to pass it to ppc386 which doesn't support that option). if i just compile my program with -CfLIBGCC then it comes up with "Fatal: Internal error 200308251".

also, is the "SOFT" option complete in latest fpc? this would probably save me lots of trouble.

many thanks

henry

Op Mon, 26 Feb 2007, schreef Henry Vermaak:

FPC cannot use libc for fpu emulation.

also, is the "SOFT" option complete in latest fpc? this would probably save me lots of trouble.

Yes, softfpu should work on ARM.

Daniël

thanks, i'll try this.

henry

with latest fpc svn i try 'make distclean all CPU_TARGET=arm BINUTILSPREFIX=armbe-linux-' and get this (after a while):

/home/hcv/freepascal/latest/compiler/ppcrossarm -Ur -Parm -XParmbe-linux- -Xc -Xr -Ur -Xs -O1r -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE. -FU/home/hcv/freepascal/latest/rtl/units/arm-linux -darm -dRELEASE ../unix/errors.pp
/home/hcv/freepascal/latest/compiler/ppcrossarm -Ur -Parm -XParmbe-linux- -Xc -Xr -Ur -Xs -O1r -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE. -FU/home/hcv/freepascal/latest/rtl/units/arm-linux -darm -dRELEASE ../objpas/sysconst.pp
/home/hcv/freepascal/latest/compiler/ppcrossarm -Ur -Parm -XParmbe-linux- -Xc -Xr -Ur -Xs -O1r -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE. -FU/home/hcv/freepascal/latest/rtl/units/arm-linux -darm -dRELEASE -Fi../objpas/sysutils ../unix/sysutils.pp sysstr.inc(2503,11) Fatal: Internal error 2002090902 Fatal: Compilation aborted

any ideas? is there something wrong with my make command line?

henry

Revert to r6643, current svn head is broken for big endian.

Jonas

thanks, jonas.

with rev6643, i run make all CPU_TARGET=arm
BINUTILSPREFIX=armbe-linux- CROSSINSTALL=1 OPT="-CfSOFT" and get:

/home/hcv/freepascal/latest/compiler/ppcrossarm -Ur -Parm -XParmbe-linux- -Xc -Xr -XX -CX -Ur -Xs -O1r -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE.
-FU/home/hcv/freepascal/latest/rtl/units/arm-linux -CfSOFT -darm -dRELEASE -Us -Sg system.pp
genmath.inc(419,22) Fatal: Internal error 200308252

is it wrong to specify OPT="-CfSOFT" on the make command line?

henry

Jonas

hi, i can't get anything compiled with ppcarm/ppcrossarm when i use -CfSOFT. anyone have any luck with this? where can i go and dig? sorry i have to ask here the whole time, i'm not experienced with this platform at all...

henry

o.k. this is where i've come to with my struggle with arm big endian (without fpu):

2.0.4: works well, except with floating point (hangs on my board). can't compile the rtl with softfloat support.

2.0.5: just tried latest rev. doesn't work well, writeln('hello world') spits out rubbish after 'hello world'. can't compile rtl with softfloat.

2.1.1: tried many revisions, most of them compile without problems (i only compile the compiler and the rtl). can compile for softfloat (when i use -Ce -CfSOFT). doesn't seem to work at all, however. writeln('hello world') doesn't do anything and the program just exits.

i'll try and debug 2.1.1. rev 6643 soon to see what i can learn. any insight or info from anyone?

thanks

henry

I'll try to fix building with -Cfsoft

At least cross it works now.

Florian Klaempfl wrote

At least cross it works now.

with 2.3.1? i can compile, but no output from writeln and seg fault on floating point. i'm using big endian, btw.

thanks

henry

I've no access to an arm machine running be so I can't test and fix :(

anything i can try that could help you get to the bottom of the problem?

I've no access to an arm machine running be so I can't test and fix :(

What about a Linksys NSLU2? Cost's about 100€ - If it would help I send you one ....

helmut

here's an update on this. i tried a couple of different things to rule out what can be the problem. i got an nslu2 that i set up with a big endian firmware that runs a different kernel (2.6.16) version than my other board. the results were exactly consistent between these boards. i also tried different crossbinutils, but got the same results again. this is as expected, but i just had to make sure it wasn't anything silly.

these results are (everything compiled with -CfSOFT for big endian):

1) writeln('Hello World') outputs "Hello WorldHello W". all other writeln and readln calls seem to work after that.

2) i get "Runtime error 207" when i attempt floating point operations.

then i flashed the nslu2 with little endian firmware and everything works perfectly with softfloat (after i recompiled ppcrossarm and my test program, obviously). i haven't tested extensively, but something like format('%.2f', [a/b]) works well. good job to all who's been working on this.

so i guess the problem lies with big endian...

thanks
henry

Try to get a stack trace please.

(gdb) s
Illegal update to pc in instruction
148 in arm.inc
(gdb) bt
#0 MOVE_PLD () at arm.inc:148
#1 $0002e410 in FPC_WRITEBUFFER () at text.inc:477 #2 $0002ea08 in fpc_write_text_pchar_as_array () at text.inc:568 #3 $00008264 in main () at armbetest.pas:15
(gdb) list
15 writeln('the quotient is ', s1/s2);
16 end.
(gdb)

source:
program hello;

{uses sysutils;}

var
  s1, s2: real;
begin
  writeln('hello there!');
  write('enter a dividend: ');
  readln(s1);
  write('enter a divisor: ');
  readln(s2);
{  writeln('the quotient is ' + format('%.2f', [s1/s2]));}
  writeln('the quotient is ', s1/s2);
end.

when i un-comment uses sysutils; i get:

(gdb) s
Single stepping until exit from function _start,
which has no line number information.

Program received signal SIGSEGV, Segmentation fault. fpc_ansistr_decr_ref () at astrings.inc:100
100 astrings.inc: No such file or directory.
in astrings.inc
(gdb) bt
#0 fpc_ansistr_decr_ref () at astrings.inc:100
#1 $0004c2b4 in FINALIZERESOURCETABLES () at objpas.pp:347 #2 $0004c36c in OBJPAS_finalize () at objpas.pp:515 #3 $00026c18 in FINALIZEUNITS () at system.inc:687 #4 $00026cb0 in INTERNALEXIT () at system.inc:723 #5 $00026edc in DO_EXIT () at system.inc:769
#6 $00026f04 in HALT () at system.inc:783
#7 $00026ffc in HANDLEERRORADDRFRAME () at system.inc:807 #8 $0002705c in HANDLEERRORFRAME () at system.inc:822 #9 $00027078 in HANDLEERROR () at system.inc:832
#10 $00029f7c in ALLOC_OSCHUNK () at heap.inc:813
#11 $0002a13c in SYSGETMEM_FIXED () at heap.inc:885 #12 $0002a344 in SYSGETMEM () at heap.inc:983
#13 $00028d78 in GETMEM (P=$0, SIZE=13) at heap.inc:241 #14 $000221a8 in TOBJECT__NEWINSTANCE () at objpas.inc:213 #15 $00046c3c in EXCEPTION__CREATE (MSG=$5a864) at sysutils.inc:116 #16 $000487cc in INITEXCEPTIONS () at sysutils.inc:363 #17 $0004b9a8 in SYSUTILS_init () at sysutils.pp:1062 #18 $00026b88 in fpc_initializeunits () at system.inc:668 #19 $0000812c in main () at armbetest.pas:8
(gdb) s

Program exited normally.
(gdb)

hope this is helpful.

henry

Interesting. I was about to send the following...

I played around on the weekend with several toolchains and multiple cross-compile options (with / without -Ce, -CfSOFT etc) . With all of these (arm-xscale-linux-gnu-, armv5b-softfloat-linux-, armeb-linux- and armbe-linux-) I was getting runtime 207s with float. testing program with qemu-armeb gave same result as running on (NSLU2) board.

FWIW arm-xscale-linux-gnu- in little endian with -CfSOFT seems work fine in qemu-arm emulator

Changing endian_little to endian_big in compiler/systems/i_linux.pas (which I believe is the correct thing to do for big endian arm systems) results in bizarre output and hanging / segfaults. A simple writeln('hello') outputs the string twice - hellohello without CRLF - then - if set to writeln a float value as well - on qemu-armeb it displays 2 of each hellohello0.0000.000 (without line feeds) - on NSLU2 board it hangs... hellohello - stuck forever.

My suspicion is that endian_big /needs/ to be defined in compiler/systems/i_linux.pas but it severely breaks stuff. There may be some {$IFDEF arm} that bypasses endian defs or the big endian bit rotation is wrong for arm??

What I would like to know is what the alignment stuff...
            alignment    :
              (
                procalign       : 4;
                loopalign       : 4;
                jumpalign       : 0;
                constalignmin   : 0;
                constalignmax   : 4;
                varalignmin     : 0;
                varalignmax     : 4;
                localalignmin   : 4;
                localalignmax   : 8;
                recordalignmin  : 0;
                recordalignmax  : 4;
                maxCrecordalign : 4
              );
            first_parm_offset : 8;
            stacksize    : 262144;
            abi : abi_default
          );
does and if it needs to be changed for a big endian arm.

FWIW I have a prototype industrial evaporator running using a NSLU2 as the controller. I am using a 2.0.5 fpc-armbe compiler with the endian_big define set. The only issue I have is with float so I had to use fixed point for analog data. It goes well though.

Terry

On 12/03/07, Terry Kemp wrote:
...

FWIW I have a prototype industrial evaporator running using a NSLU2 as the controller. I am using a 2.0.5 fpc-armbe compiler with the endian_big define set. The only issue I have is with float so I had to use fixed point for analog data. It goes well though.

it's very easy to flash the slug with little endian firmware. i can use latest (well, latest is broken now, use 6811) compiled with soft float on mine without problems now. maybe this is a solution for you?

Terry

florian: the section smartlinking change in i_linux.pas causes a segfault on both little and big endian arm. can't get a trace...

henry

Henry Vermaak wrote

it's very easy to flash the slug with little endian firmware. i can use latest (well, latest is broken now, use 6811) compiled with soft float on mine without problems now. maybe this is a solution for you?

Yeah you are right! I thought there were issues with the ethernet but I built the latest SlugOSle from MasterMakefile head and flashed... too simple ;) Bye Bye big endian.

Thanks

Terry

Sorry for stumbling into this thread. May I ask what type of hardware you're using?

Marc
(Permanently seeking interesting small boards ... ;)

Marc Santhoff wrote

Sorry for stumbling into this thread. May I ask what type of hardware you're using?

linksys nslu2. www.nslu2-linux.org. very neat piece of kit - and you can choose what kind of an os you want to flash onto it. 2xusb2 ports and 1xeth.

i've got an arcom vulcan board, too. it's about twice as fast, got 2xeth and 4xusb2 ports, but i can't get it to work with little endian kernel.

Marc (Permanently seeking interesting small boards ... ;)

henry