On 11/25/2013 05:21 PM, Robert Yates wrote:
Two problems to fix in order to allow compiling for ARM.
The first was to add the proper "Boost::Context assembly wrapper" files
for ARM, and modify common/system/fcontext.s to include them. The files
'jump_arm_aapcs_elf_gas.S' and 'make_arm_aapcs_elf_gas.S' I acquired
from the boost_1_55_0.tar.bz2 download from http://www.boost.org/
The second parch is for a fake rdtsc() function in include/profile.h to
make the compiler happy. I'm not a c++ programmer so I don't actually
know what the right thing to do is, but I'm sure returning the number
'42' isn't it. ;-) There seems to be a cycle counter register built
into ARM CPUs similar to the TSC register in x86 CPUs, but reading it is
not trivial just google 'arm cycle counter' to see what I mean.
But with these two patches I'm able to compile under Arch linux ARM on
my Chromebook
(http://archlinuxarm.org/platforms/armv7/samsung/samsung-chromebook) and
it seems to be running well.
Both patches are against revision 4499 of the lp:kicad branch.
On 11/25/13 11:54, Maciej Sumiński wrote:
Thank you for sharing the solution. I have to admit that the ARM build
happened faster than I thought it will. Regarding rdtsc() - in fact, you
may return 42, but the proper function would be great. As the header
name says - it is only for execution time measurements and it is not
critical for the application operation. By the way - did not you have
any problems with OpenGL?
Kind regards,
Orson
I've done some more digging and this is what I've found.
Although there is a cycle counter built into ARM devices, you have to
have kernel level access to enable it and to enable permission for the
user-mode code to read the register. Apparently the Linux kernel does
not do this by default so in order to use it you would have to write
some init code into a kernel module or hack it directly into the kernel
to make cycle level profiling work in Kicad. That seems a bit too much
effort to go to for a little profiling.
References here:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211h/Bihcgfcf.html
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344b/Bgbjjhaj.html
http://stackoverflow.com/questions/3247373/how-to-measure-program-execution-time-in-arm-cortex-a8-processor
Then sniffing around with grep I learned that rdtsc() is only being
called by prof_start() and prof_end() in profile.h, and depending on how
you call prof_start() determines whether the timing source rdtsc() or
get_tics() is used for profiling. (Also as an interesting aside it
would seem right now all instances of prof_start() are being called
"prof_start( &totalTime, false );" which means rdtsc() is never actually
being called at all.) All that being said it would seem that the
functions rdtsc() and get_tics() are at least somewhat interchangeable.
If you still want a working timing function when rdtsc() is called on an
ARM processor I would suggest just copying the get_tics() function's
code to the __arm__ version of the rdtsc() function. I'll go ahead and
attach a patch that does just that since it's at least a much less ugly
hack then the first patch I sent in, and it's just about within my
abilities as a person who doesn't really know much about programming in
C++.
Oh and as far as problems with OpenGL. The 3D display in pcbnew does not
work, when I try to use it I get a delay where the program does not
respond for a short time and then the 3D display window finally comes up
but there is no 3D image, just black where the image should be. Also in
pcbnew the default display canvas works fine, the Cairo canvas also
works but is much slower, and the OpenGL canvas does not work, there is
just black where the board should be displayed. I'm really not sure if
the accelerated graphics drivers are installed properly glxgears runs
but with a distorted image at about 90fps. I can send you the output
from glxinfo or glewinfo or whatever else if you're interested.
