[fpc-devel] cortex-m0 support
With the cortex-m0 parts now hitting the market I think it is time to bring up the topic of thumb support again, not arm not thumb2 but thumb (the only common instruction set across almost the entire arm family (the exception being the pre-armv4t)). cortex-m0 and -m1 are armv6-m based, the -m3 and -m4 are armv7m based. I count something like 20 armv6m instructions that are not in the all thumb variants category. something like 148 armv7m that are not supported by armv6m nor all thumb variants. Just a rough count. This is why you will see folks saying that the cortex-m0 and -m1 are thumb only not thumb2. The cortex-m0 based mbed's have hit the street btw, available at sparkfun and other places. Note that gcc and llvm fail to build working code for the cortex-m0, when you specify cortex-m0 you get thumb2 code which fails miserably. David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trunk does not compile on Linux x86-64
is there an svn release number that does compile with 2.4.0 that will get me to 2.4.4 or better so that I can compile the trunk? David On 10/20/2011 02:06 AM, Sven Barth wrote: Am 19.10.2011 15:55, schrieb Leonardo M. Ramé: From: Paul Isheninwebpi...@mail.ru To: Leonardo M. Ramémartinr...@yahoo.com; FPC developers' listfpc-devel@lists.freepascal.org Sent: Wednesday, October 19, 2011 10:53 AM Subject: Re: [fpc-devel] Trunk does not compile on Linux x86-64 19.10.11 21:47, Leonardo M. Ramé пишет: Hi, I'm trying to compile trunk on Ubuntu 11.10 x86-64: Linux leonardo-laptop 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux And get this: ... /usr/local/bin/fpc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/home/leonardo/Desarrollo/fpc/rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE ../objpas/sysconst.pp sysconst.pp(243,7) Error: Wrong number of parameters specified for call to $fpc_ansistr_sint sysconst.pp(249) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted ... Are you using the latest released FPC = fpc 2.4.4 to build the trunk? If not please build with it. Building trunk compiler by an earlier version of trunk compiler is not supported. Best regards, Paul Ishenin No, sorry, I'm using 2.7.1. Let me correct Paul's statement: Compiling trunk with a compiler that is not the latest release is not supported. Thus you MUST compile using 2.4.4. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] target embedded heap.inc
I tried a make build from the current svn tree and it fails to build (mysqlcon something). apt-get is giving me 2.4.0, so still a big stuck. David On 10/19/2011 05:08 AM, Marco van de Voort wrote: In our previous episode, Jeppe Gr?sdal Johansen said: And from that point to the present (19505 or so) using instructions from the target embedded wiki page: make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv4 the build fails with a lot of heap.inc errors. Is the problem the build command line or somewhere else? Not that I can see. I just tried the same and it worked just fine. I'm using 2.7.1 from 2011/10/04 to build it with There was another person having the same problem. I guess you just need a recent version as host to build the embedded target While merging I kept apart a list of embedded revs: http://www.stack.nl/~marcov/mergelogs26/embedded.txt ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] target embedded heap.inc
Has anyone tried the embedded target in a while? rev 19168 there was a change to heap.inc and other files I assume * moved heap manager on embedded systems into a separate unit * moved console io on embedded systems into a seperate unit, this unit might setup input/output e.g. to be redirected to a serial port * cleanup of the embedded system unit And from that point to the present (19505 or so) using instructions from the target embedded wiki page: make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv4 the build fails with a lot of heap.inc errors. Is the problem the build command line or somewhere else? rev 19167 is the last build that works per the wiki page. Thanks, David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] DIFF for consideration
See attached.
Index: rtl/embedded/arm/lpc1768.pp
===
--- rtl/embedded/arm/lpc1768.pp (revision 0)
+++ rtl/embedded/arm/lpc1768.pp (revision 0)
@@ -0,0 +1,160 @@
+
+unit lpc1768;
+
+{$goto on}
+{$define lpc1768}
+
+interface
+
+var
+STCTRL : DWord absolute $E000E010;
+STRELOAD : DWord absolute $E000E014;
+STCURR : DWord absolute $E000E018;
+
+FIO1DIR2 : Byte absolute $2009C022;
+FIO1SET2 : Byte absolute $2009C03A;
+FIO1CLR2 : Byte absolute $2009C03E;
+
+SCS : DWord absolute $400FC1A0;
+CLKSRCSEL: DWord absolute $400FC10C;
+PLL0FEED : DWord absolute $400FC08C;
+PLL0CON : DWord absolute $400FC080;
+PLL0CFG : DWord absolute $400FC084;
+PLL0STAT : DWord absolute $400FC088;
+CCLKCFG : DWord absolute $400FC104;
+
+implementation
+
+var
+_data: record end; external name '_data';
+_edata: record end; external name '_edata';
+_etext: record end; external name '_etext';
+_bss_start: record end; external name '_bss_start';
+_bss_end: record end; external name '_bss_end';
+_stack_top: record end; external name '_stack_top';
+
+procedure PASCALMAIN; external name 'PASCALMAIN';
+
+procedure _FPC_haltproc; assembler; nostackframe; public name '_haltproc';
+asm
+.Lhalt:
+b .Lhalt
+end;
+
+procedure _FPC_start; assembler; nostackframe;
+label _start;
+asm
+.init
+.balign 16
+
+.long _stack_top// stack top address
+.long _start+1 // 1 Reset
+.long .LDefaultHandler+1// 2 NMI
+.long .LDefaultHandler+1// 3 HardFault
+.long .LDefaultHandler+1// 4 MemManage
+.long .LDefaultHandler+1// 5 BusFault
+.long .LDefaultHandler+1// 6 UsageFault
+.long .LDefaultHandler+1// 7 RESERVED
+.long .LDefaultHandler+1// 8 RESERVED
+.long .LDefaultHandler+1// 9 RESERVED
+.long .LDefaultHandler+1// 10 RESERVED
+.long .LDefaultHandler+1// 11 SVCall
+.long .LDefaultHandler+1// 12 Debug Monitor
+.long .LDefaultHandler+1// 13 RESERVED
+.long .LDefaultHandler+1// 14 PendSV
+.long .LDefaultHandler+1// 15 SysTick
+.long .LDefaultHandler+1// 16 External Interrupt(0)
+.long .LDefaultHandler+1// 17 External Interrupt(1)
+.long .LDefaultHandler+1// 18 External Interrupt(2)
+.long .LDefaultHandler+1// 19 ...
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+
+.globl _start
+.text
+_start:
+
+// Copy initialized data to ram
+ldr r1,.L_etext
+ldr r2,.L_data
+ldr r3,.L_edata
+.Lcopyloop:
+cmp r2,r3
+ittt ls
+ldrls r0,[r1],#4
+strls r0,[r2],#4
+bls .Lcopyloop
+
+// clear onboard ram
+ldr r1,.L_bss_start
+ldr r2,.L_bss_end
+mov r0,#0
+.Lzeroloop:
+cmp r1,r2
+itt ls
+strls r0,[r1],#4
+bls .Lzeroloop
+
+b PASCALMAIN
+b _FPC_haltproc
+
+.L_bss_start:
+.long _bss_start
+.L_bss_end:
+.long _bss_end
+.L_etext:
+.long _etext
+.L_data:
+.long _data
+.L_edata:
+.long _edata
+.LDefaultHandlerAddr:
+.long .LDefaultHandler
+// default irq handler just returns
+.LDefaultHandler:
+mov pc,r14
+end;
+
+end.
+
+
Index: rtl/embedded/Makefile.fpc
===
--- rtl/embedded/Makefile.fpc (revision 18875)
+++ rtl/embedded/Makefile.fpc (working copy)
@@ -49,13 +49,15 @@
ifeq ($(ARCH),arm)
ifeq ($(SUBARCH),armv7m)
-CPU_UNITS=lm3fury lm3tempest stm32f103 # thumb2_bare
+CPU_UNITS=lm3fury lm3tempest stm32f103 lpc1768 # thumb2_bare
endif
-
ifeq ($(SUBARCH),armv4t)
CPU_UNITS=lpc21x4 at91sam7x256
endif
+ifeq ($(SUBARCH),armv4)
+CPU_UNITS=lpc21x4 at91sam7x256
endif
+endif
ifeq ($(ARCH),avr)
CPU_UNITS=atmega128
Index: rtl/embedded/Makefile
Re: [fpc-devel] DIFF patch for changing to table driven processor definitions for ARM
need to apply this patch, like the wiki thing maybe there is a place I have to sign up to be able to check in to svn, otherwise. The lpc and sam7 parts are ARM7TDMI which is an armv4t not remotely able to support the armv7 instructions. the correction also needs to be made to allow armv7m or cortexm3. If we are going to mix the architecture (armv7m) and marketings name for the core (cortexm3) we should be consistent and start doing things like provide an arm7tdmi for the other two families. LIkewise anywhere it says if cortexm3 it should say if cortexm3 or armv7m then. if armv4 or if armv4t or if arm7tdmi then... Ideally not use the name cortexm3 and instead only use armv7m. Have a wiki page or readme that says if stellaris or stm32 or lpc1xxx then armv7m if lpc2xxx or sam7 or generic arm then armv4... Index: rtl/embedded/Makefile === --- rtl/embedded/Makefile (revision 18854) +++ rtl/embedded/Makefile (working copy) @@ -317,7 +317,7 @@ ifeq ($(SUBARCH),cortexm3) CPU_UNITS=lm3fury lm3tempest thumb2_bare stm32f103 endif -ifeq ($(SUBARCH),armv7) +ifeq ($(SUBARCH),armv4) CPU_UNITS=lpc21x4 at91sam7x256 endif endif On Fri, Aug 26, 2011 at 5:17 AM, John Clymer j...@johnclymer.net wrote: Part of what I submitted was 2 batch files in the root directory - buildarm.bat and buildthumb2.bat - that was my attempt to provide an example with the BINUTILS equates spelled out. John From: David Welch dwe...@dwelch.com To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Fri, August 26, 2011 6:17:43 AM Subject: Re: [fpc-devel] DIFF patch for changing to table driven processor definitions for ARM Can someone with the power to update the wiki (maybe we all do I dont know) change the target embedded page to reflect the SUBARCH thing? Also either put a link to http://wiki.lazarus.freepascal.org/Binutils or spell out something like this: ./configure --target=arm-linux --prefix=/something/something/ --program-prefix=arm-embedded- --disable-werror For the non-windows folks so we can play too. Too me a while to figure out why I was not even able to build per the target embedded instructions. Thanks, David On 08/25/2011 10:13 PM, David Welch wrote: cpuinfo.pas(156,2) Fatal: Can't open include file controllerunit.inc On 08/25/2011 05:50 PM, Florian Klämpfl wrote: OS_TARGET=embedded CPU_TARGET=arm SUBARCH=cortexm3 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DIFF patch for changing to table driven processor definitions for ARM
Another diff to be considered.
Index: rtl/embedded/arm/arm_bare_ram.pp
===
--- rtl/embedded/arm/arm_bare_ram.pp(revision 0)
+++ rtl/embedded/arm/arm_bare_ram.pp(revision 0)
@@ -0,0 +1,63 @@
+{
+Startup code for a simple ram-only ARM
+David Welch 2011 08 26 (dwelch at dwelch com)
+based on lpc21x4 created by Sten Larsson (sten_larsson at yahoo com)
+}
+
+unit arm_bare_ram;
+
+{$goto on}
+
+ interface
+
+ implementation
+
+procedure PASCALMAIN; external name 'PASCALMAIN';
+
+procedure _FPC_haltproc; assembler; nostackframe; public name '_haltproc';
+ asm
+ .Lhalt:
+b .Lhalt
+ end;
+
+var
+ _stack_top: record end; external name '_stack_top';
+ _bss_start: record end; external name '_bss_start';
+ _bss_end: record end; external name '_bss_end';
+
+procedure _FPC_start; assembler; nostackframe;
+ label
+_start;
+ asm
+.init
+.align 16
+.globl _start
+_start:
+ldr sp,.L_stack_top
+// clear onboard ram
+ldr r1,.L_bss_start
+ldr r2,.L_bss_end
+mov r0,#0
+.Lzeroloop:
+cmp r1,r2
+strls r0,[r1],#4
+bls .Lzeroloop
+
+bl PASCALMAIN
+bl _FPC_haltproc
+.L_hang:
+b .L_hang
+.L_bss_start:
+.long _bss_start
+.L_bss_end:
+.long _bss_end
+
+
+
+.L_stack_top:
+.long _stack_top
+.text
+ end;
+
+end.
+
Index: rtl/embedded/Makefile.fpc
===
--- rtl/embedded/Makefile.fpc (revision 18855)
+++ rtl/embedded/Makefile.fpc (working copy)
@@ -53,7 +53,7 @@
endif
ifeq ($(SUBARCH),armv7)
-CPU_UNITS=lpc21x4 at91sam7x256
+CPU_UNITS=lpc21x4 at91sam7x256 arm_bare_ram
endif
endif
Index: rtl/embedded/Makefile
===
--- rtl/embedded/Makefile (revision 18855)
+++ rtl/embedded/Makefile (working copy)
@@ -317,8 +317,8 @@
ifeq ($(SUBARCH),cortexm3)
CPU_UNITS=lm3fury lm3tempest thumb2_bare stm32f103
endif
-ifeq ($(SUBARCH),armv7)
-CPU_UNITS=lpc21x4 at91sam7x256
+ifeq ($(SUBARCH),armv4)
+CPU_UNITS=lpc21x4 at91sam7x256 arm_bare_ram
endif
endif
ifeq ($(ARCH),avr)
Index: compiler/arm/cpuinfo.pas
===
--- compiler/arm/cpuinfo.pas(revision 18855)
+++ compiler/arm/cpuinfo.pas(working copy)
@@ -61,6 +61,8 @@
tcontrollertype =
(ct_none,
+ ct_arm_bare_ram,
+
{ Phillips }
ct_lpc2114,
ct_lpc2124,
@@ -212,7 +214,19 @@
sramsize:0
),
+
(
+ controllertypestr:'ARM_BARE_RAM';
+controllerunitstr:'ARM_BARE_RAM';
+interruptvectors:8;
+ flashbase:$;
+flashsize:$;
+srambase:$D600;
+sramsize:$C000
+),
+
+
+(
controllertypestr:'LPC2114';
controllerunitstr:'LPC21x4';
interruptvectors:8;
Index: compiler/systems/t_embed.pas
===
--- compiler/systems/t_embed.pas(revision 18855)
+++ compiler/systems/t_embed.pas(working copy)
@@ -220,6 +220,7 @@
ct_none:
begin
end;
+ ct_arm_bare_ram,
ct_lpc2114,
ct_lpc2124,
ct_lpc2194,
@@ -312,16 +313,19 @@
Add('MEMORY');
Add('{');
- LinkStr := 'flash : ORIGIN = 0x' + IntToHex(flashbase,8)
-+ ', LENGTH = ' + IntToStr(flashsize div 1024)+'K';
- Add(LinkStr);
+ if(flashsize0) then
+begin
+ LinkStr := 'flash : ORIGIN = 0x' + IntToHex(flashbase,8)
++ ', LENGTH = ' + IntToStr(flashsize div 1024)+'K';
+ Add(LinkStr);
+end;
LinkStr := 'ram : ORIGIN = 0x' + IntToHex(srambase,8)
+ ', LENGTH = ' + IntToStr(sramsize div 1024)+'K';
Add(LinkStr);
Add('}');
- Add('_stack_top = 0x' + IntToHex(sramsize+srambase-4,8) + ';');
+ Add('_stack_top = 0x' + IntToHex(sramsize+srambase,8) + ';');
end;
end
else
@@ -329,6 +333,8 @@
internalerror(200902011);
end;
+
+ with embedded_controllers[current_settings.controllertype] do
with linkres do
begin
Add('SECTIONS');
@@ -341,14 +347,28 @@
Add('*(.rodata, .rodata.*)');
Add('*(.comment)');
Add('_etext = .;');
- Add('} flash');
+ if(flashsize0) then
+begin
+ Add('} flash');
+end
+ else
+begin
+ Add('} ram');
+end;
Add('.data :');
Add('{');
Add('_data = .;');
Add('*(.data, .data.*)');
Add('KEEP (*(.fpc
Re: [fpc-devel] DIFF patch for changing to table driven processor definitions for ARM
when building for SUBARCH=cortexm3, fails with:
make[3]: *** No rule to make target `thumb2_bare.ppu', needed by
`fpc_units'. Stop.
On 08/26/2011 05:09 PM, David Welch wrote:
Another diff to be considered.
Index: rtl/embedded/arm/arm_bare_ram.pp
===
--- rtl/embedded/arm/arm_bare_ram.pp(revision 0)
+++ rtl/embedded/arm/arm_bare_ram.pp(revision 0)
@@ -0,0 +1,63 @@
+{
+Startup code for a simple ram-only ARM
+David Welch 2011 08 26 (dwelch at dwelch com)
+based on lpc21x4 created by Sten Larsson (sten_larsson at yahoo com)
+}
+
+unit arm_bare_ram;
+
+{$goto on}
+
+ interface
+
+ implementation
+
+procedure PASCALMAIN; external name 'PASCALMAIN';
+
+procedure _FPC_haltproc; assembler; nostackframe; public name '_haltproc';
+ asm
+ .Lhalt:
+b .Lhalt
+ end;
+
+var
+ _stack_top: record end; external name '_stack_top';
+ _bss_start: record end; external name '_bss_start';
+ _bss_end: record end; external name '_bss_end';
+
+procedure _FPC_start; assembler; nostackframe;
+ label
+_start;
+ asm
+.init
+.align 16
+.globl _start
+_start:
+ldr sp,.L_stack_top
+// clear onboard ram
+ldr r1,.L_bss_start
+ldr r2,.L_bss_end
+mov r0,#0
+.Lzeroloop:
+cmp r1,r2
+strls r0,[r1],#4
+bls .Lzeroloop
+
+bl PASCALMAIN
+bl _FPC_haltproc
+.L_hang:
+b .L_hang
+.L_bss_start:
+.long _bss_start
+.L_bss_end:
+.long _bss_end
+
+
+
+.L_stack_top:
+.long _stack_top
+.text
+ end;
+
+end.
+
Index: rtl/embedded/Makefile.fpc
===
--- rtl/embedded/Makefile.fpc (revision 18855)
+++ rtl/embedded/Makefile.fpc (working copy)
@@ -53,7 +53,7 @@
endif
ifeq ($(SUBARCH),armv7)
-CPU_UNITS=lpc21x4 at91sam7x256
+CPU_UNITS=lpc21x4 at91sam7x256 arm_bare_ram
endif
endif
Index: rtl/embedded/Makefile
===
--- rtl/embedded/Makefile (revision 18855)
+++ rtl/embedded/Makefile (working copy)
@@ -317,8 +317,8 @@
ifeq ($(SUBARCH),cortexm3)
CPU_UNITS=lm3fury lm3tempest thumb2_bare stm32f103
endif
-ifeq ($(SUBARCH),armv7)
-CPU_UNITS=lpc21x4 at91sam7x256
+ifeq ($(SUBARCH),armv4)
+CPU_UNITS=lpc21x4 at91sam7x256 arm_bare_ram
endif
endif
ifeq ($(ARCH),avr)
Index: compiler/arm/cpuinfo.pas
===
--- compiler/arm/cpuinfo.pas(revision 18855)
+++ compiler/arm/cpuinfo.pas(working copy)
@@ -61,6 +61,8 @@
tcontrollertype =
(ct_none,
+ ct_arm_bare_ram,
+
{ Phillips }
ct_lpc2114,
ct_lpc2124,
@@ -212,7 +214,19 @@
sramsize:0
),
+
(
+ controllertypestr:'ARM_BARE_RAM';
+controllerunitstr:'ARM_BARE_RAM';
+interruptvectors:8;
+ flashbase:$;
+flashsize:$;
+srambase:$D600;
+sramsize:$C000
+),
+
+
+(
controllertypestr:'LPC2114';
controllerunitstr:'LPC21x4';
interruptvectors:8;
Index: compiler/systems/t_embed.pas
===
--- compiler/systems/t_embed.pas(revision 18855)
+++ compiler/systems/t_embed.pas(working copy)
@@ -220,6 +220,7 @@
ct_none:
begin
end;
+ ct_arm_bare_ram,
ct_lpc2114,
ct_lpc2124,
ct_lpc2194,
@@ -312,16 +313,19 @@
Add('MEMORY');
Add('{');
- LinkStr := 'flash : ORIGIN = 0x' + IntToHex(flashbase,8)
-+ ', LENGTH = ' + IntToStr(flashsize div 1024)+'K';
- Add(LinkStr);
+ if(flashsize0) then
+begin
+ LinkStr := 'flash : ORIGIN = 0x' + IntToHex(flashbase,8)
++ ', LENGTH = ' + IntToStr(flashsize div 1024)+'K';
+ Add(LinkStr);
+end;
LinkStr := 'ram : ORIGIN = 0x' + IntToHex(srambase,8)
+ ', LENGTH = ' + IntToStr(sramsize div 1024)+'K';
Add(LinkStr);
Add('}');
- Add('_stack_top = 0x' + IntToHex(sramsize+srambase-4,8) + ';');
+ Add('_stack_top = 0x' + IntToHex(sramsize+srambase,8) + ';');
end;
end
else
@@ -329,6 +333,8 @@
internalerror(200902011);
end;
+
+ with embedded_controllers[current_settings.controllertype] do
with linkres do
begin
Add('SECTIONS');
@@ -341,14 +347,28 @@
Add('*(.rodata, .rodata.*)');
Add('*(.comment)');
Add('_etext = .;');
- Add('}flash');
+ if(flashsize0) then
+begin
+ Add('}flash
Re: [fpc-devel] DIFF patch for changing to table driven processor definitions for ARM
cpuinfo.pas(156,2) Fatal: Can't open include file controllerunit.inc On 08/25/2011 05:50 PM, Florian Klämpfl wrote: OS_TARGET=embedded CPU_TARGET=arm SUBARCH=cortexm3 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DIFF patch for changing to table driven processor definitions for ARM
Can someone with the power to update the wiki (maybe we all do I dont know) change the target embedded page to reflect the SUBARCH thing? Also either put a link to http://wiki.lazarus.freepascal.org/Binutils or spell out something like this: ./configure --target=arm-linux --prefix=/something/something/ --program-prefix=arm-embedded- --disable-werror For the non-windows folks so we can play too. Too me a while to figure out why I was not even able to build per the target embedded instructions. Thanks, David On 08/25/2011 10:13 PM, David Welch wrote: cpuinfo.pas(156,2) Fatal: Can't open include file controllerunit.inc On 08/25/2011 05:50 PM, Florian Klämpfl wrote: OS_TARGET=embedded CPU_TARGET=arm SUBARCH=cortexm3 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM vs Thumb2 - can't have both
Most if not all of my references to thumb meant the original ARMv4T thumb instruction set, definitely not the thumb2 extensions, nor ARMv5 or ARMv6 extensions. If for example you had a thumb backend to fpc, you could easily solve this problem, all of these libraries would run on both platforms, one compiler, one set of libraries, compiled one time. There is no thumb backend at the moment, this is the first problem to that solution. I figure most folks would not want to sink to the lowest common denominator. I would then recommend splitting the arm/arm7/ARMv4 architecture from the cortex-m3/ARMv7m, as implemented now they are two incompatible instruction sets. One instruction set happens to share the name of the company, move beyond that sticking point and create two architectures. The third alternative is do what others do and build two sets of libraries, one for each cpu type if that is the preferred term to distinguish arm and thumb2. Even if they are in the same library file but by name the linker extracts the arm cpu whatsit function from the thumb2 cpu whatsit function it is still two compilations of the whatsit function. You really have to pick one of those solutions, same instruction set or compile the libraries twice either as two arches build one or the other but not both, or two cpus within an arch and both/all cpus for an arch get built when the arch compiler is built. David On 08/22/2011 01:15 AM, John Clymer wrote: Yes, all my references of Thumb meant Thumb2. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
As interesting is that it will assemble thumb2 code as arm code and not fail/stop during that step in the build. Thanks for the help, will try that. David On 08/21/2011 05:23 AM, Jeppe Græsdal Johansen wrote: Den 21-08-2011 00:00, David Welch skrev: A! that makes sense. I assume that is either leftover from a prior build? And how do I get a new/fresh build to look in the right place? It's installed in /fpcarm. This directory should contain a bin and units directory. You simply need to change your main fpc.cfg file to match those settings. I don't know precisely how that would be done on a unix system. Maybe it would even install directly to your current install directory, if you just run this? make buildbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 sudo make installbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 On a side note, I find it strange that it even accepts your old leftover files. I thought the linker normally would complain about interwork stuff ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM vs Thumb2 - can't have both
except for a few older ARM's both platforms support thumb code, so anything that is shared could be compiled for thumb with some target specific trampolines to get there ARM: 0x0: b _pre_start ... _pre_start: ldr r0,_start bx r0 .pool cortex-m3: 0x: _stac_top 0x0004: .word _start .thumb_func _start: limit to thumb instructions (no thumb2) same works for interrupts as well... If everything is written in an thumb interwork fashion then you can jump around from target specific block to target specific block, PASCALMAIN can be arm for the arm target and thumb2 for the cortex-m3 target for example and it all works. BTW if you add .thumb_func .thumb_func .globl _start .text _start: you dont have to do this: .long _start+1 you can do this instead: .long _start at least for gnu as, not sure if this code is targeted at different assemblers. On 08/21/2011 05:58 PM, John Clymer wrote: Been playing with the ARM / Thumb2 part - specifically for the Thumb2 line-up. The compiler proper can be built to switch between the two with a command line switch. However, the RTL gets called as ARCH-SYSTEM, this only allows the RTL to compiled for one or the other. This may be by design - in which case there should be a big BOLD note added to the Arm port page. Or it may be unintentional - in which case it should be switched to ARCH-CPU-SYSTEM OR Thumb2 should get rolled out as a separate ARCH. Not sure I will have time to get into changing ARCH, but if there is a [somewhat] easy fix to add CPU to the RTL path for architectures that support it, I may have time to dig into that. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM vs Thumb2 - can't have both
All I am saying is thumb (not thumb2) is common between many ARM cores and the cortex-m3. These lpc21xx parts use an ARM7TDMI which is an ARMv4T and supports thumb. the lpc2000 are also ARM7TDMI's and LPC1000 is cortex-m0 which is the successor to cortex-m3 so no doubt it is thumb/thumb2 based as well. All of the ARM based microcontrollers I know of (have used) str7, stm32, lpc2000, lpc1000, stellaris, sam7 (at91sam7) support thumb instructions (if you limit yourself to the original ARMv4T supported instructions). the sam9 and str9 both appear to be ARMv5T based so they support thumb as well. So long as all code modules use a thumb interwork as folks like to call it interface, then dules like PASCALMAIN can be compiled for arm, thumb or thumb2 and be called and return to arm, thumb or thumb2 code, mix and match at will. Obviously the exception table or vector table at address zero has to be different for ARM7 vs cortex-m, no way to work around that. If that is the root of the problem and that code wants to move out of the target specific rtl (stellaris.pp, lpc21x4.pp, etc) then, yeah, there is a big problem. If the exception and vector tables can be custom to the target as they are now (stellaris.pp, lpc21x4.pp, etc) then you could do a couple of things. One would be the interwork thing. The arm startup code, within the target specific rtl would have to do a two step to get from arm mode to thumb/interwork mode. The arm cores traditionally handles exceptions in arm mode. What I described in the prior email but not necessarily exactly like that. Any shared code between the ARM and cortex-m would be strictly thumb (limited to ARMv4T ideally). Any instructions like mrs/msr that thumb is lacking would want to be calls to arm code in the target specific startup area. The cortex-m vector table could simply point directly at the thumb mode shared code (and have matching named functions for mrs/msr and other instructions) The second solution, would be to use the lowest common denominator, everything except the exception/vector tables, and some architecture specific stuff (like any need for mrs/msr calls) be compiled for thumb (limited to ARMv4T). Unfortunately there is no thumb backend. With the second solution the compiler could be compiled one time, one way and so far all the targets are supported by that one compiler. I guess a third solution would be to treat the cortex-m3 as a completely different architecture, in the same way that the avr is a separate target (looks like there is at least a directory for the avr, but the code is arm so a work in progress). I would be super happy to see an msp430 target in there as well but that is another story. From what you were talking about ARCHSYSTEM becoming ARCHCPUTYPESYSTEM, cortex-m could be a separate ARCH instead of being part of the ARM architecture and ARCHSYSTEM would work. Sorry for being dense, I am a newbie here so dont know enough about the detail to know where the problem is. I still have not gotten past the problem I had trying to get that startup code to build right for the cortex-m3. Lots of arm experience, almost no fpc experience. I assume what you are calling a thumb system is the cortex-m3 based systems, you you cannot have arm code there. I assume the ARCH is for now ARM (the company not the instruction set). And SYSTEM is either ARM (the instruction set) or thumb2/cortex-m3? Am I understanding that so far? Or is ARCH ARM or cortex-m3 and SYSTEM is stellaris, lpc21x4, etc? David On 08/21/2011 10:36 PM, John Clymer wrote: Yes, I'm somewhat familiar with mixing Thumb and Arm in C. However, I believe the intent is to target FPC for the newbie market (that's what I'm getting from wanting all the hardware peripheral registers installed in the controller unit file...) A newbie is NOT going to have any luck intermixing the two. That also doesn't solve the problem of the SYSTEM unit. As the compiler is laid out now - the system unit sits in a directory of the name ARCH-SYSTEM. So, to support BOTH ARM and THUMB (i.e. Cortex and native ARM7TDMI) SYSTEM files, 2 different builds are needed. However - they can't both sit in the same directory (not with the current setup of Makefiles and code.) I've seen where the compiler inserts the system unit and controller units, so supporting both would only be a few lines of code there. I've also seen when running the compiler in verbose mode (-Va) that the -Cp processor switch is getting defined to a constant - so one could possibly massage the makefiles into supporting ARCH-CPUTYPE-SYSTEM directories to seperate the two system units. Otherwise, one has the following problem: 1) building for ARM - all the controllerunits compile (because the assembler can assemble the thumb startup code into arm startup code). However, when one builds a program with the resulting SYSTEM and controllerunit file, the startup will be in ARM mode
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Just jumping in here and maybe it was discussed but the cortex-m3 appears to have been designed so that if you match the arm abi you can put the address of handlers directly in the vector table and not have to trampoline off of a wrapper function. basically 8 well chosen register are put on the stack so you dont have to preserve them, so that the handler has the look and feel of a standard function and not the look and feel of an interrupt handler. I would not mix all cortex-m3 based devices into one definition. Perhaps lumping all the stellaris parts into one but that would still get huge. Maybe all the 800 series in one, all the 1000 series in another, and so on. That is the way the vendors tend to manage information for their parts, and it makes sense as a sub-set of a larger family is very closely related and easier to manage the subtle differences. Is it your intention to get all of the stellaris parts into this project all at once? Or build some framework, add one or a few parts from each family and then over the course of time add a part or two here and there? I would start with one family 800 series or 1000 series, one of the more simpler ones, and try to capture that series. If one series of parts is too bulky or complicated that is your answer, you may need to isolate each part by itself. I would not try to cross vendors to the stm or lpc/nxp cortex-m3 or cortex-m0 parts etc. the memory maps and peripherals across vendors are too different. boot strategies, flash programming, etc. I suspect everyone using an arm7 in a controller now will be using one of the cortex-m cores before long if they are not already. Is it st or lpc that has both cortex-m3 and cortex-m0 based parts now? I would have to look up the difference but know I bought/saw both at some point. David On 08/20/2011 02:20 AM, John Clymer wrote: Also, just peeked at current line up of STM32 controllers, there are 150 different controllers available, consisting of 33 possible combinations of FLASH memory and SRAM size. I will try to get the controller specific parts boiled up into record structures this weekend, and get some added controllers installed into cpuinfo.pas. (And fix any compiler breakages from the change.) I have the SVN download - so generated diffs should be a bit easier (still learning SVN though...) Also, I read through the ARM docs regarding the standard library - and can setup registers based on the each vendors published C library so they match the ARM/vendor docs. However, as each controller in the line-up has only certain peripherals, is it the intention that EACH controller gets it's own controller file with memory definitions for peripherals ? That's 300+ unit files between STM32 and TI's Stellaris line-ups. OR - does one try to merge as many controllers into 1 memory definition as possible. i.e. ALL of stellaris could be defined for the maximal configuration of peripherals (as they have a standard mapping layout for peripherals i.e. ALL LM3 devices have UART0 at the exact same location - and all have the same register layout.) The caveat to this that one could compile code that won't actually run on a given device. OR - we could leave the peripheral definitions to the user. (Which I'm assuming is not the preferred route.) John *From:* Florian Klämpfl flor...@freepascal.org *To:* FPC developers' list fpc-devel@lists.freepascal.org *Sent:* Fri, August 19, 2011 12:19:05 PM *Subject:* Re: [fpc-devel] Arm Thumb2 - Stellaris status Am 19.08.2011 05:28, schrieb John Clymer: Currently, everything is in a handful of giant arrays. Just wondering if it would be better to switch to a record structure for the controller entries - rather than individual arrays. (Add in a variety of STM parts and the other manufacturers, and there could easily be over 100 memory configurations in the table.) Maybe it's indeed better to have an array of records, each record describing one controller. My suggestion would be that the register definitions come in an UNIT file that only defines registers. The controller unit in the compiler source would only provide the bare minimum necessary to bring the system up and call PASCALMAIN. However, if it is deemed better to have the entire register set defined inside the RTL - that would be fine too. Well, isn't it for a user easier just to pass the controller he uses on the command line and the compiler does the rest? Why bother with addional uses etc. if the compiler knows already anything? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto:fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler. Geoffrey Not sure what you are saying here, almost none of the peripherals are the same from vendor to vendor. With the cortex-m3 the systick timer and the VNIC for example are from ARM, sure, but the majority of the items you are going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor specific and vastly different from vendor to vendor. Within a vendor they are very similar if not the same but from ti to st most of the items are not compatible, likewise from ti to lpc/nxp or ti to atmel, etc. Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood. And as with libraries you can take them or leave them, that would want to be the case here (without having to dig into the compiler proper). Would need to roll your own target to avoid/modify a library. Ideally with the compiler you want to specify the arm core to take advantages of instructions each newer core supports. Not use them to tie to boards or systems. I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. So far it seems to be very straight forward to add a platform/device to fpc arm embedded, so if the stock support is too bulky or confusing individuals can cherry pick items they want and make their own simpler target. Actually what we definitely need here in the near term is an arm generic target and a thumb2 generic target that does not have any of the vendor specific items in it, perhaps not even core specific peripherals. I understand this is a work in progress and sorting everything out will take some time. David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
right, when I build for stellaris or stm32f103re I get the cortex-m like vector table that uses arm 32 bit instruction startup code that branches to a pascalmain that is thumb2. something that wont execute on hardware. Had it been a thumb target with a traditional exeception table that would have been good and in fact desirable for some platforms (nintendo gba for example). but the arm/thumb2 combination doesnt mix very well. Maybe I need to re-try everything from scratch to see if I skipped a step or left out something and specified the wrong target or cpu. Note you are giving up a stack location by using addresses in the form 0x10007FFC instead of 0x10008000. Minor point but it stands out in the binary. This is all clearly a work in progress, I understand that... David On 08/20/2011 11:49 AM, John Clymer wrote: The thumb2 is meant to support Cortex M3 devices (STM32, Stellaris, etc.) AFAIK - the mixing of modes is not currently an option. *From:* Jeppe Græsdal Johansen jjoha...@student.aau.dk *To:* FPC developers' list fpc-devel@lists.freepascal.org *Sent:* Sat, August 20, 2011 7:23:39 PM *Subject:* Re: [fpc-devel] Arm Thumb2 - Stellaris status Den 20-08-2011 16:46, David Welch skrev: I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. Why thumb support? The choices are indeed currently only either ARM or Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length instruction set that looks like an arm+thumb mix, so I guarantee you that it works :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto:fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
I am rapidly seeing the problem, the linker script is hardcoded both by family (ARM as a whole) and by target. So for example if you wanted a ram-only ARM generic target, you are in trouble, or if you wanted a flash/ram target arm generic target you are in trouble. You have to override the compiled in maps. Once you get target specific compiled in memory maps then the compiled in register addresses make sense. At that point do the libraries, pll init, timers, etc make sense? David On 08/20/2011 11:57 AM, DaWorm wrote: I'm not sure how FPC should handle the peripherals, but I don't think it should be at the compiler level. Even if the part I'm using has, for instance, an ADC, if I'm not using it I do not want support for it built in to my app. With what I use currently (IAR C) I uncomment a #define for each peripheral I want to add support for. I'm sure something similar can be done for FPC at the unit level. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
r3, [pc, #60]
8000410: e1520003cmp r2, r3
8000414: 94910004ldrls r0, [r1], #4
8000448: 08000468stmdaeq r0, {r3, r5, r6, sl}
800044c: 2000andcs r0, r0, r0
8000450: 2048andcs r0, r0, r8, asr
0x08000468 is the word aligned address for the end of the text segment
and 0x2000 the beginning of text for this example so that is correct
as well.
and interestingly the ittt ls instruction is discarded.
The code from stm32f103.pp
ldr r1,.L_etext
ldr r2,.L_data
ldr r3,.L_edata
.Lcopyloop:
cmp r2,r3
ittt ls
ldrls r0,[r1],#4
strls r0,[r2],#4
bls .Lcopyloop
when assembled should look like this
.text:
0: 4904ldr r1, [pc, #16] ; (14 .text+0x14)
2: 4a05ldr r2, [pc, #20] ; (18 .text+0x18)
4: 4b05ldr r3, [pc, #20] ; (1c .text+0x1c)
6: 429acmp r2, r3
8: bf9eitttls
a: f851 0b04 ldrls.w r0, [r1], #4
e: f842 0b04 strls.w r0, [r2], #4
12: e7f8bls.n 6 .text+0x6
14: 0001andeq r0, r0, r1
18: 0002andeq r0, r0, r2
1c: 0003andeq r0, r0, r3
with different addresses of course...when assembled for thumb.
So it doesnt look like that is happening
Pascal main is definitely thumb+thumb2.
08000194 PASCALMAIN:
8000194: 46ecmov ip, sp
8000196: e92d 4800 stmdb sp!, {fp, lr}
800019a: f1ac 0b04 sub.w fp, ip, #4
800019e: b08asub sp, #40 ; 0x28
More info about my setup:
svn info
URL: http://svn.freepascal.org/svn/fpc/trunk
Repository Root: http://svn.freepascal.org/svn/fpc
Repository UUID: 3ad0048d-3df7-0310-abae-a5850022a9f2
Revision: 18278
Node Kind: directory
Schedule: normal
Last Changed Author: florian
Last Changed Rev: 18278
Last Changed Date: 2011-08-19 18:06:52 -0400 (Fri, 19 Aug 2011)
Ubuntu 10.4 or something like that 64 bit host.
Linux dwelch-desktop 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29
21:07:13 UTC 2011 x86_64 GNU/Linux
fpc is what you apt-get so probably a little behind but stable in the
eyes of ubuntu or debian.
fpc
Free Pascal Compiler version 2.4.0-2ubuntu1.10.04 [2011/06/17] for x86_64
Copyright (c) 1993-2009 by Florian Klaempfl
/usr/lib/fpc/2.4.0/ppcx64 [options] inputfile [options]
Put + after a boolean switch option to enable it, - to di
GNU assembler (Sourcery G++ Lite 2011.03-42) 2.20.51.20100809
Copyright 2010 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.
So what did I do wrong? and what is the unsafe thing about?
Thanks,
David
On 08/20/2011 11:23 AM, Jeppe Græsdal Johansen wrote:
Den 20-08-2011 16:46, David Welch skrev:
I was hoping for thumb support but I now see that the choices are
limited to arm and thumb+thumb2 (without any separation between thumb
and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2
mix, so I will ride this along for a while and see what comes up,
otherwise limit my use to ARM targets, or start working on a thumb
backend. Adding backends as well as arm embedded are of interest to me
so I may work on a little of both.
Why thumb support? The choices are indeed currently only either ARM or
Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length
instruction set that looks like an arm+thumb mix, so I guarantee you
that it works :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
A! that makes sense. I assume that is either leftover from a prior build? And how do I get a new/fresh build to look in the right place? If I remove the offending fpc/2.7.1 directory and rebuild. (without trying to change the prefix) it puts the same stuff back in that directory: /opt/embarm/arm-embedded-ld: warning: library search path /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/ is unsafe for cross-compilation Am I doing this wrong? make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm If I change it to this? make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=cortexm3 and provide the necessary cortexm3-embedded-* tools. make: -iVSPTPSOTO: Command not found make: -iSP: Command not found make: -iTP: Command not found make: -iSO: Command not found make: -iTO: Command not found Makefile:203: *** The Makefile doesn't support target cortexm3-embedded, please run fpcmake first. Stop. Thanks, David /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/ is unsafe for cross-compilation The problem is that you are using an RTL built for ARM. That's what the warning is about. You installed the compiler in /fpcarm, but it's using units from /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/ A correctly compiled unit would look like this: STM32F103__FPC_START: 0: f8df 1034 ldr.w r1, [pc, #52] ; 38 STM32F103__FPC_START+0x38 4: 4a0d ldr r2, [pc, #52] ; (3c STM32F103__FPC_START+0x3c) 6: 4b0e ldr r3, [pc, #56] ; (40 STM32F103__FPC_START+0x40) 8: 429a cmp r2, r3 a: bf9e ittt ls ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] thumb2 code generation
Someone pointed me at this page: http://wiki.freepascal.org/TARGET_Embedded And I started adding a device (and perhaps more after that), starting with a cortex-m3 though which is thumb/thumb2 only. Following the instructions on the page work fine: fpc -Parm -Tembedded -Wplpc2124 tled1.pp Added my device as well as tried the two other cortex-m3 devices and fpc -Parm -Tembedded -Wpdevice test.pp I tried -Parm, -Pthumb, thumb2, cortex-m3 but it just keeps generating arm instructions. I can certainly target an arm processor first but would rather try a thumb/thumb2 first. Thanks, David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] thumb2 code generation
Actually I would prefer thumb first then thumb2 cpuinfo.pas does not have an architecture tied to thumb but the cortexm3 and armv7m can be easily moved to thumb temporarily or create say a cpu_cortexm3_thumb in the tcputype list, etc... David On 08/19/2011 11:00 PM, David Welch wrote: Someone pointed me at this page: http://wiki.freepascal.org/TARGET_Embedded And I started adding a device (and perhaps more after that), starting with a cortex-m3 though which is thumb/thumb2 only. Following the instructions on the page work fine: fpc -Parm -Tembedded -Wplpc2124 tled1.pp Added my device as well as tried the two other cortex-m3 devices and fpc -Parm -Tembedded -Wpdevice test.pp I tried -Parm, -Pthumb, thumb2, cortex-m3 but it just keeps generating arm instructions. I can certainly target an arm processor first but would rather try a thumb/thumb2 first. Thanks, David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] thumb2 code generation
Sorry, figured it out -Cpcortexm3 On 08/19/2011 11:05 PM, David Welch wrote: Actually I would prefer thumb first then thumb2 cpuinfo.pas does not have an architecture tied to thumb but the cortexm3 and armv7m can be easily moved to thumb temporarily or create say a cpu_cortexm3_thumb in the tcputype list, etc... David On 08/19/2011 11:00 PM, David Welch wrote: Someone pointed me at this page: http://wiki.freepascal.org/TARGET_Embedded And I started adding a device (and perhaps more after that), starting with a cortex-m3 though which is thumb/thumb2 only. Following the instructions on the page work fine: fpc -Parm -Tembedded -Wplpc2124 tled1.pp Added my device as well as tried the two other cortex-m3 devices and fpc -Parm -Tembedded -Wpdevice test.pp I tried -Parm, -Pthumb, thumb2, cortex-m3 but it just keeps generating arm instructions. I can certainly target an arm processor first but would rather try a thumb/thumb2 first. Thanks, David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
