This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
laforge gerrit-no-reply at lists.osmocom.orglaforge has posted comments on this change. ( https://gerrit.osmocom.org/c/simtrace2/+/23620 )
Change subject: cardem: Use USART timeout for waiting time
......................................................................
Patch Set 2:
(5 comments)
https://gerrit.osmocom.org/c/simtrace2/+/23620/2//COMMIT_MSG
Commit Message:
https://gerrit.osmocom.org/c/simtrace2/+/23620/2//COMMIT_MSG@1
PS2, Line 1: Parent: d6005fcd (make sim switch board specific)
actaully, the clock signal is connected (TCLK1). It's the I/O signal which is not connected to any TIO{A,B}1 so we cannot determine when exactly a bit starts or ends on the I/O line.
https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/apps/cardem/main.c
File firmware/apps/cardem/main.c:
https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/apps/cardem/main.c@a168
PS2, Line 168: #if 0
unrelated change.
https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/include/simtrace_prot.h
File firmware/libcommon/include/simtrace_prot.h:
https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/include/simtrace_prot.h@236
PS2, Line 236: uint3
waiting_time to wt rename should be one purely cosmetic patch (if at all)
https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/source/card_emu.c
File firmware/libcommon/source/card_emu.c:
https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/source/card_emu.c@424
PS2, Line 424: if (ISO_S_WAIT_POWER == new_state) {
the UART I/O related changes are independent of the USART timer changes.
To be honest, I don't see how those do anything at all. The UART I/O lines are all routed to the peripheral function via the PIO_PER (peripheral enable register). Unless you disable the peripheral via PIO_PDR, the changes to the GPIO output data via PIO_SODR / PIO_CODR done here are no-ops as the alternate function always overrides any configured output levels. How was this tested/validated? Maybe there are some hardware bugs I'm unaware of?
https://gerrit.osmocom.org/c/simtrace2/+/23620/1/firmware/libcommon/source/mode_cardemu.c
File firmware/libcommon/source/mode_cardemu.c:
https://gerrit.osmocom.org/c/simtrace2/+/23620/1/firmware/libcommon/source/mode_cardemu.c@217
PS1, Line 217: ("%
> not sure we want to make this a non-fatal error. Clearly this should never happen...
Done
--
To view, visit https://gerrit.osmocom.org/c/simtrace2/+/23620
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: simtrace2
Gerrit-Branch: master
Gerrit-Change-Id: Ibcb2c8cace9137695adf5fb3de43566f7cfb93b5
Gerrit-Change-Number: 23620
Gerrit-PatchSet: 2
Gerrit-Owner: laforge <laforge at osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: tsaitgaist <kredon at sysmocom.de>
Gerrit-Comment-Date: Mon, 05 Apr 2021 12:25:41 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge at osmocom.org>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210405/b0623f5e/attachment.htm>