From lukash at backstep.net Fri Nov 3 00:44:29 2017 From: lukash at backstep.net (Lukas Kuzmiak) Date: Thu, 2 Nov 2017 17:44:29 -0700 Subject: building simtrace FW nowdays Message-ID: 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 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 (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 - apply a patch below to the script, gcc.patch is 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 - 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: -------------- 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: -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukash at backstep.net Fri Nov 3 07:59:16 2017 From: lukash at backstep.net (Lukas Kuzmiak) Date: Fri, 3 Nov 2017 00:59:16 -0700 Subject: Min Xu patches testing Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From min.xu at min-info.net Fri Nov 3 08:37:11 2017 From: min.xu at min-info.net (Min Xu) Date: Thu, 2 Nov 2017 22:37:11 -1000 Subject: Min Xu patches testing (Lukas Kuzmiak) Message-ID: 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. From lukash at backstep.net Fri Nov 3 08:52:44 2017 From: lukash at backstep.net (Lukas Kuzmiak) Date: Fri, 3 Nov 2017 01:52:44 -0700 Subject: Min Xu patches testing (Lukas Kuzmiak) In-Reply-To: References: Message-ID: Hi Min Xu, I just sent you an e-mail a minute ago after finding this thread ( https://lists.osmocom.org/pipermail/simtrace/2014-January/000621.html). I somehow missed that before - I will try to get the changes merged as Harald mentioned here ( https://lists.osmocom.org/pipermail/simtrace/2014-October/000644.html) in a way that will not break openocd. Thanks for such quick response. Lukas On Fri, Nov 3, 2017 at 1:37 AM, Min Xu wrote: > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From min.xu at min-info.net Fri Nov 3 09:04:34 2017 From: min.xu at min-info.net (Min Xu) Date: Thu, 2 Nov 2017 23:04:34 -1000 Subject: Min Xu patches testing (Lukas Kuzmiak) In-Reply-To: References: Message-ID: Another follow up. We did discover there is a difference in how to power sim card. The power should ALWAYS be coming from PHONE, not from the SIMtrace board. Otherwise, a 3.3V may be fed back into the phone and "may" cause damage to the phone/device. This means that ONLY PWR_PASS should be used. Depending on the parts (BOM) used on the board (our board has a different part in FPF2108.pdf which I think had a different Active mode from the one used /shipped from osmocom) you may have to check the configuration when setting the PWR_PASS code. So be sure to check your call, and the best way to confirm this is by disconnecting the SIMtrace from the phone, then power up the SIMtrace (plug-in the USB) WHILE having a digital multimeter probe the PINs on the VCC/GND pad of the SIM PCB connected to the SIMTrace. THERE SHOULD NOT BE A VOLTAGE ACROSS THE PADS. On Thu, Nov 2, 2017 at 10:37 PM, Min Xu wrote: > 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. From tchen at on-go.com Fri Nov 10 01:59:45 2017 From: tchen at on-go.com (Thomas Chen) Date: Thu, 9 Nov 2017 20:59:45 -0500 Subject: remote sim network delay Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Nov 10 06:38:34 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 10 Nov 2017 15:38:34 +0900 Subject: remote sim network delay In-Reply-To: References: Message-ID: <20171110063834.fm7dzheahekxz6mx@nataraja> Hi Thomas, On Thu, Nov 09, 2017 at 08:59:45PM -0500, Thomas Chen wrote: > 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 you don't hold off the ME at that point. Presuming it is "RUN GSM ALGORITHM" command, then the actual command from ME to card continues here with the random challenge. Later, a GET RESPONSE is issued from ME to SIM to obtain the SRES + Kc values, and this is where we can delay with waiting time extension (0x60) until we have the result. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Fri Nov 10 07:11:08 2017 From: holger at freyther.de (Holger Freyther) Date: Fri, 10 Nov 2017 15:11:08 +0800 Subject: remote sim network delay In-Reply-To: <20171110063834.fm7dzheahekxz6mx@nataraja> References: <20171110063834.fm7dzheahekxz6mx@nataraja> Message-ID: <8D429B99-52D7-402F-B1AC-69F7BC05DCF2@freyther.de> > On 10. Nov 2017, at 14:38, Harald Welte wrote: Hey, > Later, a GET RESPONSE is issued from ME to SIM to obtain the SRES + Kc values, > and this is where we can delay with waiting time extension (0x60) until we > have the result. and maybe to make this more clear. The 0x60 will not be transmitted by the remote SIM but by the card emulation firmware. The expiration of a hardware timer will lead to "tc_etu_wtime_half_expired" being called and if the states are right the 0x60[1] will be transmitted. cheers holger http://git.osmocom.org/simtrace2/tree/firmware/libcommon/source/card_emu.c#n937 From tchen at on-go.com Fri Nov 10 12:51:56 2017 From: tchen at on-go.com (Thomas Chen) Date: Fri, 10 Nov 2017 07:51:56 -0500 Subject: remote sim network delay In-Reply-To: <20171110063834.fm7dzheahekxz6mx@nataraja> References: <20171110063834.fm7dzheahekxz6mx@nataraja> Message-ID: got it....? i thought you meant that in a general term, for other APDU commands such as GET RECORD or BINARY READ sending PROCEDURE would not help as REMOTE SIM side will not start sending data until after we ACK with INS and subsequent bytes are obtained and relayed to remote before it will start answering On 11/10/17 1:38 AM, Harald Welte wrote: > Hi Thomas, > > On Thu, Nov 09, 2017 at 08:59:45PM -0500, Thomas Chen wrote: >> 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 > you don't hold off the ME at that point. Presuming it is "RUN GSM ALGORITHM" > command, then the actual command from ME to card continues here with the random > challenge. > > Later, a GET RESPONSE is issued from ME to SIM to obtain the SRES + Kc values, > and this is where we can delay with waiting time extension (0x60) until we > have the result. > From tchen at on-go.com Sat Nov 25 02:53:39 2017 From: tchen at on-go.com (Thomas Chen) Date: Fri, 24 Nov 2017 21:53:39 -0500 Subject: strange status In-Reply-To: <20171110063834.fm7dzheahekxz6mx@nataraja> References: <20171110063834.fm7dzheahekxz6mx@nataraja> Message-ID: <0ec3fa2b-d059-087b-e946-c861c61a3521@on-go.com> i am seeing some strnge stuff with SIMTRACE .. when i have a modem communicating with SIM, and simtrace in sniffer mode i see a command 0x00 0xa4 0x04 0x04 0x10 + data (0xa0 0x00 0x00 0x00 0x87 0x10 0x02 0xff 0xff 0xff 0xff 0x89 0x06 0x19 0x00 0x00) and got response + status? (0x61, 0x44) but in remote SIM environment. this SIM card return 0x69 0x99 do you know what that mean ???? i dont know whether it is timing or something else ? all previous commands seem to work just fine thanks From lukash at backstep.net Sat Nov 25 04:28:24 2017 From: lukash at backstep.net (Lukas Kuzmiak) Date: Fri, 24 Nov 2017 20:28:24 -0800 Subject: strange status In-Reply-To: <0ec3fa2b-d059-087b-e946-c861c61a3521@on-go.com> References: <20171110063834.fm7dzheahekxz6mx@nataraja> <0ec3fa2b-d059-087b-e946-c861c61a3521@on-go.com> Message-ID: Hi Thomas, remote SIM environment as in OTA? Selecting an AID remotely might not make sense, that's what TARs are for .. but not sure what you're trying to achieve and what context do you send the SELECT in.. Lukas On Fri, Nov 24, 2017 at 6:53 PM, Thomas Chen wrote: > > i am seeing some strnge stuff with SIMTRACE .. > when i have a modem communicating with SIM, and simtrace in sniffer mode > i see a command > 0x00 0xa4 0x04 0x04 0x10 + data (0xa0 0x00 0x00 0x00 0x87 0x10 0x02 0xff > 0xff 0xff 0xff 0x89 0x06 0x19 0x00 0x00) > and got response + status (0x61, 0x44) > > but in remote SIM environment. > this SIM card return > 0x69 0x99 > > do you know what that mean ??? i dont know whether it is timing or > something else ? > > all previous commands seem to work just fine > > thanks > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tchen at on-go.com Mon Nov 27 00:36:25 2017 From: tchen at on-go.com (Thomas Chen) Date: Sun, 26 Nov 2017 19:36:25 -0500 Subject: strange status In-Reply-To: References: <20171110063834.fm7dzheahekxz6mx@nataraja> <0ec3fa2b-d059-087b-e946-c861c61a3521@on-go.com> Message-ID: <59fbf6a6-807a-bba4-6c34-6c780a5b9e20@on-go.com> i am only trying to test whether the remote sim, and i observed mPCIe GSM modem ==> simtrace ======(local lan)====> card reader i see about 20-30 apdu flying back and forth... and everything looks normal and then the modem issue a RESET what can be the problem ???? how does one find out whether modem is not happy ??? From tchen at on-go.com Thu Nov 30 04:09:33 2017 From: tchen at on-go.com (Thomas Chen) Date: Wed, 29 Nov 2017 23:09:33 -0500 Subject: SAM3 DFU Message-ID: 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 ? From ml at mail.tsaitgaist.info Thu Nov 30 08:41:59 2017 From: ml at mail.tsaitgaist.info (=?iso-8859-1?Q?K=E9vin?= Redon) Date: Thu, 30 Nov 2017 09:41:59 +0100 Subject: SAM3 DFU In-Reply-To: References: Message-ID: <20171130084159.GA27899@coil> On Wed, Nov 29, 2017 at 11:09:33PM -0500, Thomas Chen wrote: > 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 ??) Are you trying to flash the DFU image/bootloader using DFU? This is not possible (at least not with this DFU implementation). The DFU bootloader only allows to conveniently (re)flash the main application image. The DFU image can't overwrite itself. Once the DFU bootloader is working and fulfilling its purpose (flashing the main firmware/application) there is no need to re-flash it. If you are developing on the DFU image you will have to flash it using SAMBA From tchen at on-go.com Thu Nov 30 12:42:06 2017 From: tchen at on-go.com (thomas chen) Date: Thu, 30 Nov 2017 07:42:06 -0500 Subject: SAM3 DFU In-Reply-To: <20171130084159.GA27899@coil> References: <20171130084159.GA27899@coil> Message-ID: i am trying to flash APPLICATION... however, after reboot/power up, it always go backl to the DFU.... instead of starting with APPLCIATION with SAM7, the same step will result in booting up application after power cycle.... but with SAM3 DFU, always go back to DFU On 11/30/2017 3:41 AM, K?vin Redon wrote: > On Wed, Nov 29, 2017 at 11:09:33PM -0500, Thomas Chen wrote: >> 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 ??) > Are you trying to flash the DFU image/bootloader using DFU? This is not possible (at least not with this DFU implementation). > The DFU bootloader only allows to conveniently (re)flash the main application image. The DFU image can't overwrite itself. > Once the DFU bootloader is working and fulfilling its purpose (flashing the main firmware/application) there is no need to re-flash it. > If you are developing on the DFU image you will have to flash it using SAMBA