All the parts are DNP and never existed on the simtrace2 with sam3; the
sam3 has internal pullups that are part of the usb peripheral.
Change-Id: I04a703a2eba6ff1dc64692c089213389d0c1066d
The "wait time extension timer" was apparently not being reset during
normal tx operations, which led to occasional NULL (0x60) bytes getting
injected into transfers, which in turn led to more tx bytes than what
the reader side expects...
The odd thing is that this was only noticeable with high baud rates,
probably due to the very long default WT of 9600 ETU, and even then only
because it led to weird ngff modem resets after benign transfers.
Change-Id: I15b0b83b7d93b8e5589f3640bd6eb2fc82f93394
Related: SYS#5553
This adds support for the new ngff_cardem board, a board that
basically combines a ngff breakout board with a built-in SIMtrace2.
Cardem works, but depending on the modem it might need a adjusted ATR to
ensure a lower baud rate is used by the modem, high rates might lead
to weird power cycling of the card after a few transfers.
Trace was also tested and appears to work as expected.
Change-Id: Ia96124fbe8a752c98e7fd4096d542a3b2b9bc255
The tester has shifters, while the original simtrace relies upon the
reader restarting the powerup attempt with > 1v8 after not respondig due
to a lack of shifters and therefore 1v8 support.
Change-Id: I520aa26c6e0fb34568a4f632943efa59a0da831c
The octsimtest board can control the card-insert contact of the OCTSIM
under test via an external I2C gpio multiplexer; let's add support for
that.
Change-Id: I8c9b0c3d862a967832134b24252577739182da62
octsimtest has a resistive voltage divider in front of the VCC ADC
in order to also detect 5V. We must make the thresholds board-specific
and adjust them for octsimtest.
Change-Id: I9e4adb4f349d2d838ea4100eb49271f3a0e7a2a5
Contrary to other hardware designs, octsimtest has a level-shifter in
the I/O line to support testing with 1.8, 3 and 5V. This level shifter
is bi-directional, but the direction needs to be explicitly specified
via the SIM_IO_DIR signal attached to PA26.
Change-Id: I44171363b5bd69d6049b12c86f8143be83557cb2
As we store the waiting time (WT) in 'etu', we must adjust the formula
from ISO 7816-3. The 'Fi' component in the formula only exists to
compute clock cycles from the etu, which we don't need here.
Without this patch, the waiting time would be way too large (by a factor
of 372 in the default case).
Change-Id: Ia21bc7303f9b38834b5b1753983ed2a99bfc7d95
Related: OS#1704
The existing code started the timer once (and expired once) but didn't
properly handle re-starting of the timer. Neither did it handle
the 'half time expiration' case. If we want to call a function after
half the WT expiring, we must of course program the hardware for half
the timeout, and not the full timeout...
Change-Id: Ia999d97f835c27597fcd1cf7ac78bac0ab9c98c1
Related: OS#1704
Instead of using the timer/counter peripheral to handle the waiting time
and corresponding timeout, the USART peripheral internal timeout
mechanism is used.
This is particularly important for the SIMtrace board since there
(contrary to other boards) the I/O signal is not wired to a TIO pin
of the timer/counter block, and hence Rx/Tx data cannot reset that
timer/counter.
As a result of this migration, cardem is now supported not only on
owhw + qmod, but also on the simtrace board.
The guts of this change have been lifted out of Change-Id
Ibcb2c8cace9137695adf5fb3de43566f7cfb93b5 by Kevin Redon, which was
unfortunately touching various different topics at the same time and
hence was split up. Some improvements are the introduction of the
ENABLE_TX_TIMER_ONLY mode, which avoids the USART interrupt handler
getting hammered with TXRDY between release of RST and start of the ATR.
Change-Id: Ibcb2c8cace9137695adf5fb3de43566f7cfb93b5
Related: OS#1704
Those are already initialized at various transitions of the master
7816 FSM, but let's properly initialize them at start-up, too.
Change-Id: I81b2a8ef3284559164700d94717e4ccf008f53df
* enter ISO_S_WAIT_RST when RST is asserted
* enter ISO_S_WAIT_ATR only when we RST is released while in state ISO_S_WAIT_RST
Change-Id: I620333aa8d45561a8028b948955a27f667b58406
Fi/Di are not the index into the table, but the contents of the table
as resolved by Fi_index / Di_index. Let's clarify the terminology.
Change-Id: If364e08e7c9a3a9707e6d54b9267c6a7c088e415
The ISO7816 spec terms are well-defined, let's not abuse them. We used
to consider "Fi" as the "index into the table of F values", while the
spec actually considers Fi as the initial value for F.
Let's make sure we use the terms quite clearly:
* Fi and Di are the initial values for F and D
* F*_index and D*_index are the indexes into the ISO7816-3 Tables
Furthermore, let's track Fi separately from F, as e.g. the waiting
time definition only considers Fi as indicated in the ATR, despite
an actually different F value might have been negotiated via PTS
meanwhile.
Change-Id: Ieb2425e8380a81b79df7b2bd072902994e9c3ee7
Related: OS##1704
As we will soon introduce the distinction between Fi and F, we should
use uppercase letters, as lower-case 'f' is defined in ISO7816-3 as
the frequency, which is different from the upper-case 'F'.
Change-Id: Iaede621551520576e9b9af878fa46fbc88e59c2a
The comment didn't reflect the source. I checked all users and
the code consistently stores the waiting time in units of 'etu'.
Change-Id: I2bc4a7c19cee5fb487ad639ee48ecaea706f6172
This reverts commit 4a29f64cbe.
The code replicates to a large extent what is already present in iso7816_fidi.c
and I have serious doubts about the correctness of the computation in
its iso7816_3_calculate_wt() function.
Change-Id: I80dab4401d13306d573a6a35ce8729d2acc141e4
this will become part of libosmocore since it it common to smart
card related projects (such as osmo-ccid-firmware)
Change-Id: I3d4c65d137fc4555fcb256443feadd1c695de73d
On Ubuntu 20.04 when builiding dpkg packages, even when cross-compiling
firmware, gcc stack smashing protection is enabled. Let's provide what
is minimally required in order to sucessfully complete builds on such
platforms.
Change-Id: Ic2f68f16b0730e7b5db17c30effc29a2909d1997
Closes: OS#4687
In dispatch_received_usb_msg(), we ran into an infinite loop if a
too long messages was received on the OUT EP. Let's break the loop.
Change-Id: I5325ed15d3dd79a42f8dac34d618e86b9334c301
Closes: OS#4429
This unifies the printing of the welcome banner, and it also ensures
that all modes print all information (serial number, reset cause).
Furthermore the APP and BOARD #defines from the make environment are
also printed.
Change-Id: I7e6bc05cee4b9ec0fd9a05dc90ce0b26a5763e5a
This is a purely cosmetic change in terms of coding style, but it
fixes an [invalid] detection for unterminated value_string arrays
by our verify_value_string_arrays_are_terminated.py script:
Change-Id: I2f2370a673074f6bf5380106b6254b4aa1e8a792
ERROR: file contains unterminated value_string 'struct value_string iso7816_3_card_state_names[]': './deps/simtrace2/firmware/libcommon/source/card_emu.c'
ERROR: file contains unterminated value_string 'struct value_string tpdu_state_names[]': './deps/simtrace2/firmware/libcommon/source/card_emu.c'
If this feature flag is set by the host application, we will start
generating SIMTRACE_MSGT_BD_CEMU_STATUS towards the interrupt endpoint
on any changes to the SIM card status, such as change of VCC/CLK/RST
Change-Id: I832b4ac4aeb6152195d985067ffdd64fa5a7d4cc
Related: OS#4330
The new SIMTRACE_MSGT_BD_CEMU_CONFIG command can be used to set/change
a bitmask of optional features that can be enabled in the simtrace
by the host software. This is useful for enabling features in the
firmware which are not supported by older host utilities.
The firmware will return the actually set/configured features in
response.
The feature bitmask is not yet used anywhere; it will be by subequent
patches.
Change-Id: I7cdd3f9171dbed45de0089defe29d2b59044bd84
ch->pts.state is initialized every time we enter ISO_S_WAIT_TPDU
state, so there's no need to reset it at other locations. KISS.
Change-Id: I5ff8b2671c3c893cc5f6542d48b65487ae8c5be1
card_set_state(ch, ISO_S_WAIT_ATR) internally calls tc_etu_enable(),
so there's no need for the caller to do the same, too.
Change-Id: I2a2b4d64c40264623313a867957ffcefe57748f9
A function that is called to set the state should not in itself
contain logic to issue further state changes.
Let's shift the related block out to the end of card_emu_io_statechg(),
which is the only source of card_set_state() calls for the
WAIT_{POWER,CLK,RST} states anyway.
As an added benefit, the block of statements is now also executed if
there's no state change - something that was prevented by the
"if old == new" state guard at the top of card_set_state(). I believe
this may help us to cover more (non-standard) card activation sequences.
Change-Id: Ieefa1807099eb234cfd994bca83caaa0dcc919b6
We need to send zero-length packets on bulk endpoints whenever the
transfer size is exactly a multiple of the wMaxPacketSize.
See USB 2.0 Specification Section 5.8.3 titled "Bulk Transfer Packet
Size constraints."
Change-Id: Ice3842399d5a5c4a18383860f81074497c6e7c9b
Closes: OS#4331
When the Modem is asserting RST, the emulated card should set all
of its state back to default/initial values and release any buffers
it may still hold in its state.
Change-Id: I66eca6afe4ff7d900c5b75df1e3ec6d52f6ef214
Related: OS#4251
So far, we called card_emu_io_statechg() from interrupt context, which
was safe with the current code. However, as we want to trigger a more
comprehensive reset of data structures, including the flushing of
message queues, it is best to shift this processing from interrupt
context to main loop context.
Change-Id: I3983078396538f32bdff55611c41d2163be4d796
Related: OS#4251
Let's move all initialization of state that may change at runtime
to a separate function: card_handle_reset().
This has the advantage that the related function may also be called
at later/other instances, not just during initialization of card_emu.
Change-Id: I0954d192d001a3af5592010cc84a3a22aaf4b030
Related: OS#4251
We need at least one per IN/IRQ endpoint, as well as at least 3 for
every OUT endpoint. Plus some more depending on the application,
in case of cardem there could be one in uart_tx and one in uart_rx.
So for cardem, it should be 7 per slot, resulting 14 for dual-slot
devices like OWHW and QMOD.
Given that we have plenty of RAM available (utilization up from 49%
to 56% with this change), we can be on the comfortable size and
easily have 20 buffers for now.
Future MITM / triple-play applications likely need more.
Change-Id: I022ba3bb3e1f5fd0c364aafe1a23f8fd9b2d8499
Related: OS#4251
In Change-ID Ie15183f16b22193ffdaf01845db2eae4c7f43c17 we wanted
to limit the number of queue elements to 3, but actually implemented 4.
Change-Id: Ic5fb164f2dfd1c293c51bee8184fc34552267a54
Some boards like QMOD cannot simulate a virtual card insert signal
towards the modem (as the mPCIe connector doesn't have that signal).
In these situations, we were aborting processing of the related OUT
endpoint command and forgot to release the related memory.
Change-Id: I489097b7e332004e0f2beca0b22fa36d5d1d31b5
Related: OS#4251
This helps when debugging the firmware, as it shows the current
utliization of the 10-msgb-talloc pool.
Change-Id: Ib10c4396cd4c9c4a6257cf45886e367214787927
Related: OS#4251
If there are already three elements in the to-be-transmitted queue
for the EP, let's free the first element of the queue. This is a
clear indication that the USB host is not polling the endpoint
regularly. Maybe there's no host application running at all?
This should obsolete Change-Id Ie9ebdd2ff966f67c9afd1ed760f106558f0091ad
Change-Id: Ie15183f16b22193ffdaf01845db2eae4c7f43c17
Closes: OS#4251
Eric Wild
Harald Welte
Kevin Redon