Am 11.02.2015 um 13:36 schrieb Jonas Maebe:
instruction. The Cortex-A5 is an ARMv7 class cpu, so adding -Cparmv7
to your cross-options when building the RTL should work.
Thanks for the info, I will give it a try.
Greetings,
Björn
--
Björn Schreiber
DRIGUS GmbH
__
Small correction: -Cparmv7a
-- Oprindelig besked--Fra: Jonas MaebeDato: ons., 11. feb. 2015
13:36Til: FPC-Pascal users discussions;Emne:Re: [fpc-pascal] access violations
on new ARM hardware
On 11 Feb 2015, at 12:48, Björn Schreiber wrote:> Some new information:
On 11 Feb 2015, at 12:48, Björn Schreiber wrote:
Some new information: the manufacturer of the SOM did a analysis of
the compiled program. We were told that the program makes use of the
SWP instruction which is deprecated since ARMv6 and was deactivated
in the kernel we used. They build a
Am 28.01.2015 um 16:44 schrieb Björn Schreiber:
--- Schnipp On ---
program test;
var
AString: String;
function AFunction: String;
var
S: WideString;
begin
S := 'Test';
AFunction := S;
end;
begin
AString := AFunction;
end.
--- Schnipp Off ---
Some new information: the
Am 28.01.2015 um 17:24 schrieb Sven Barth:
Could be a bug in the conversion routines from WideString to AnsiString.
Since we are currently preparing release 3.0.0 it might be best to test
with that as well (cause string handling was changed in 2.7.1). It
shouldn't be hard to compile for WinCE eit
Am 28.01.2015 16:45 schrieb "Björn Schreiber" :
>
> Am 28.01.2015 um 11:21 schrieb Sven Barth:
>
>> As said by Marco: please try to reproduce it by copying parts of
>> SysUtils (e.g. GetLocaleStr) into an empty program (and using that code
>> of course ^^) to find an example code that shows the pro
Am 28.01.2015 um 11:21 schrieb Sven Barth:
As said by Marco: please try to reproduce it by copying parts of
SysUtils (e.g. GetLocaleStr) into an empty program (and using that code
of course ^^) to find an example code that shows the problem.
I narrowed it down to the following minimal program
Am 28.01.2015 10:08 schrieb "Björn Schreiber" :
>
> Am 27.01.2015 um 17:58 schrieb Marco van de Voort:
>
>
>> First narrow it down to the exact line that causes the problem. E.g. copy
>> relevant parts of sysutils into a program that only uses system, and then
>> start testing, till you know which
Am 27.01.2015 um 17:58 schrieb Marco van de Voort:
First narrow it down to the exact line that causes the problem. E.g. copy
relevant parts of sysutils into a program that only uses system, and then
start testing, till you know which line provokes the problem.
What I can say at this time is
In our previous episode, Bj?rn Schreiber said:
> Am 26.01.2015 um 21:15 schrieb Mark Morgan Lloyd:
> > Since nobody else has suggested anything: is the new hardware
> > susceptible to alignment errors in a way that the old hardware wasn't?
>
>The question is: how can we know? The ARM documenta
Björn Schreiber wrote:
Am 26.01.2015 um 21:15 schrieb Mark Morgan Lloyd:
Since nobody else has suggested anything: is the new hardware
susceptible to alignment errors in a way that the old hardware wasn't?
The question is: how can we know? The ARM documentation says only "The
processor supp
Am 26.01.2015 um 21:15 schrieb Mark Morgan Lloyd:
Since nobody else has suggested anything: is the new hardware
susceptible to alignment errors in a way that the old hardware wasn't?
The question is: how can we know? The ARM documentation says only
"The processor supports unaligned accesses.
Björn Schreiber wrote:
Hi *.*,
we use an ARM based SOM for a device developed by us, the software is
developed using Lazarus. Now we are testing a new version of the SOM and
can't get our software to work.
Old SOM:
Samsung S5PV210
one Cortex-A8 (?) core
Windows CE 6.0 R3 kernel
New SOM:
F
Hi *.*,
we use an ARM based SOM for a device developed by us, the software is
developed using Lazarus. Now we are testing a new version of the SOM and
can't get our software to work.
Old SOM:
Samsung S5PV210
one Cortex-A8 (?) core
Windows CE 6.0 R3 kernel
New SOM:
Freescale Vybrid dual cor
14 matches
Mail list logo
