building simtrace FW nowdays

historical

Hi guys,

after a long time I blew the dust off of mine SIMtrace 1.0p, went through the history of the mailing list archives and saw there were some nice fixes for fast sims but there is no released firmware that includes them (v0.5 is latest dated in 2012 - I still have some sync issues/lost bytes with v0.5 like i used to years ago).

So I got to building and oh boy :-) Back in the day arm-elf was not obsolete and all went fine, today with arm-none-eabi however, not so much. After couple days of fiddling around with building custom toolchains, trying the ones from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads <https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads> and other goodies I realized I keep running into the same issue over and over again.

Some kind of a weird boot loop - see UART log attached. Weirdly enough the DFU compiles fine with the gcc-arm-none-eabi-6-2017-q2-update toolchain and works just fine, it seem main_simtrace also compiles, links and even starts initializing but then dies somewhere in the middle.
I never got pass this "[00001E] computed Fi(1) Di(1) ratio: 372” to “ISO_SW Initializing” .. Have not managed to figure out why - any help appreciated on this.

In the end I went all the way back to gcc-4.6.4, had to apply some patches do it’d compile on a recent Debian (9.2) .. and using arm-elf toolchain produces a working firmware (after reverting commit 373c172ab858102e1818c8476ab1a2b290685cda "convert from u_int*_t to uint*_t”). For anybody in this situation see the procedure below (for reference).

Hopefully the issue can be collaboratively fixed - I’m happy to test around on 1.0p and 1.4p boards, different toolchains etc. but I don’t really know how to debug the bootloop - even a nudge in that is appreciated.

Btw - is it possible to get write access to SIMtrace wiki? There’s a bunch of stuff that could be fixed :) eg. i had to dig sam7utils from archive.org <http://archive.org/> (openpcd.org <http://openpcd.org/> no longer has it) and some other misc stuff.

IMHO if this can be fixed a v0.6 release could be made after (or even before) to bring those fast sim features to people in a simpler fashion? I have yet to test that functionality on my end - I can report back on how it seems to perform (not sure how widely tested it has been).

Lukas

GCC-4.6.4 (arm-elf) on Debian 9.2:
 - use the gnu-arm-build.3.sh script from https://osmocom.org/projects/baseband/wiki/GnuArmToolchain <https://osmocom.org/projects/baseband/wiki/GnuArmToolchain>
 - apply a patch below to the script, gcc.patch is https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00375.html <https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00375.html>, gcc.texi.patch is https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02100.html <https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02100.html>
 - voila, compile simtrace firmware (git revert —no-commit 373c172ab858102e1818c8476ab1a2b290685cda - if you’re using master).

8,9c8,9
< GCC_SRC=gcc-4.8.2.tar.bz2
< GCC_VERSION=4.8.2
---
> GCC_SRC=gcc-4.6.4.tar.bz2
> GCC_VERSION=4.6.4
20c20
< TARGET_TRIPLET=arm-none-eabi
---
> TARGET_TRIPLET=arm-elf
69a70,78
> 
> #
> # Stage 0: Patch the old gcc so it compiles on modern systems
> #
> (
> cd $SRCDIR/$GCC_DIR
> patch -p1 < ../../gcc.patch
> patch -p1 < ../../gcc.texi.patch
> ) || exit 1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20171102/42278fb6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bootloop_uart_dc2983d907a4676114eee74536ed71574571389f_gnu-arm-none-eabi-6-2017-q2-update.log
Type: application/octet-stream
Size: 4347 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20171102/42278fb6/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20171102/42278fb6/attachment-0001.htm>