question about DFU...
working with AT91SAM3 board,
i tried,
1. use sam-ba to flash the DFU image (works fine)
2. try to use dfu-util to flash the APP, but it does not seem to write
into flash (after reboot
we still have the initial DFU image ??)
(i am using the same argument as SAM7
-a0 -D filename -R
is there any tips you can provide before i start digging ?
i am not clear about how simtrace2, specifically
libcommon/source/card_emu.c
seems to handle the network delay for remote sim response
however, i dont understand how that would help ???
my understand of the protocol is that
ME => SIM (first 5 bytes of APDU)
SIM <=== PROCEDURE (either INS as ack, or 0x60 to hold up the protocol)
but that does not help remote sim, as remote SIM would need the susequent bytes
which will not come until we send back INS, so just holding off ME with 0x60
does not alleviate the problem of network delay
Hi Lukas
I saw your email to my @sanjole.com address but since this address is
on the mailing list I'll just reply here so everyone can see.
--- your email below ---
Hi Min Xu,
first of all thanks for all the work you put into simtrace.
I’ve been testing your patches last couple days, they have not yet
been in any release which I think is a shame, so I’d like to push the
community to fix that so it can be even further tested (by testing,
reporting back, fixing building the firmware with latest
arm-none-eabi, etc.)
I have found one bug for which I fail to identify the source .. The
whole trace is fine except sometimes there are 4 bytes inside the data
which seems to be the simtrace_hdr (first line is my debug):
USB MSG: sh->cmd: 1, sh->flags: 0, sh->res[9, 5], payload: 00 a4 00 04
02 a4 6f 07 61 2a 00 c0 00 00 2a c0 62 28 82 02 41 21 83 02 6f 07 a5
0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06
03 80 02 00 09 88 01 38 90 00 01 00 09 05 00 b0 00 00 09 b0 08 29 03
30 10 66 03 91 12 90 00
APDU: 00 a4 00 04 02 6f 07 61 2a
APDU: 00 c0 00 00 2a 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0
01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09
88 01 38 90 00
APDU: 01 00 09 05 00 b0 00
APDU: 00 09 b0 08 29 03 30
APDU: 10 66 03 91 12 90 00
The 01 00 09 05 (which seems to be sh->cmd, sh->flags and Fi/Di (9/5)
just randomly appear in APDU data every now and then. If those 4 bytes
were not there apdu_split would split it fine .. like this it breaks
this into nonsense pieces and breaks the trace.
I’ve gone through your patches in the firmware, fiddled around with
some of them but didn’t manage to find the root cause yet - seems like
the simtrace_hdr is inserted in the middle (but that does not seem
possible), so perhaps 2 USB messages somehow get merged into one?
So I figured I’ll try to write you, maybe it will ring a bell - I have
not fully verified the merge of your patches went correctly but from a
fast compare it seems like it.
If you’ll find a minute to give me a few tips I’ll appreciate that, in
the meantime I’ll keep digging.
PS: the version of FW I’m using is latest master in the git
(https://git.osmocom.org/openpcd).
Thanks!
Lukas
--- END ---
I believe the reason for this is actually in an email I sent to the
list on Sep 10, 2013.
Basically, the ATMEL chip can break up the req_ctx ( the usb response
) and combine as it see fit (if there's a large burst etc). So you
cannot rely on the "natural break" between the calls to transmit.
Therefore, since it's a stream you'll get on receiving side, then a
natural packet header that accounts of subsequent bytes must be added.
So I added extra bytes into the simtrace_hdr header so that the actual
data payload can be correctly accounted for.
The changes are:
struct simtrace_hdr {
u_int8_t cmd;
u_int8_t flags;
u_int8_t res[2];
+ u_int16_t seq_num;
+ u_int16_t offset;
+ u_int16_t tot_len;
u_int8_t data[0];
} __attribute__ ((packed));
So the desktop client will have to have equivalent changes to account
for these extra fields.
Let me know if this answers your question. If not I can try send
you the full code I have for the firmware and a sample of the desktop
receiving / parsing code so you'll have a baseline.
Hi again guys,
I've been testing the latest firmware (git master) to see how patches from
Min Xu made it better and tracing of fast sims (lost bytes, broken tracing,
etc.) seems to be a lot improved.
I have found one bug - somehow simtrace_hdr makes it into the APDU
payloads, I've been trying to find the root cause of this but have not
managed yet - seems like the FW sends 2 messages but they arrive as a
single message into the host software thus the header is considered APDU
payload.
I've reported the issue here: https://osmocom.org/issues/2614 along with
all the tracing/investigation I've performed so far - anybody got further
ideas how this might happen?
Other than this and the painful building of the firmware in today's world
it seems tracing modern phones is not such a pain as it used to be, yay!
Lukas
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
