Reading the Unique ID from flash is a rather tricky procedure: After the
STUI command has been issued, we cannot read normal flash anymore.
Rather, the unique ID is mapped at 0x00000000. This is unfortuantely
also where the exception vector table is stored.
EEFC_ReadUniqueID() is already linked to RAM, which is good. Hoewver,
if an Interrupt happens between STUI and SPUI, then we try to access
the vector table and code from flash, which is illegal. We run into
a hardfault and stay there until the watchdog resets the processor.
Change-Id: I3c4fad55b47e9013f6615a331983b3989ca805a7
Closes: OS#4428
In Change-Id I7cdd3f9171dbed45de0089defe29d2b59044bd84 we introduced
firmware support for SIMTRACE_MSGT_BD_CEMU_CONFIG. The respective
host part was so far only implemented in osmo-remsim-client-st2,
but not in libosmo-simtrace2. Let's fix that.
Change-Id: Ia4822d360a271d2ce9725f761cb95de58663ac3b
cardem on the st2 has been broken forever and still does not work, so
stop uploading cardem binaries
Change-Id: I33828f799d41386afb3f8dcd9bb510902877e03f
As reported in https://osmocom.org/issues/4335, there appear to
be some cards / use cases in which the 512 byte sized ringbuffer is
insufficient. As we do have free RAM available, we can easily
increase the buffer size, despite not entirely knowing yet why
it needs to be *that* large.
Change-Id: Ie713d614ec5b334e9058d5d430e4bb660f5b8b69
Closes: OS#4335
this python script lists the SIMtrace 2 devices connected to USB
and will flash the latest version of the application (if necessary).
it requires pyusb and dfu-util.
it is intended for end users so they don't need to read the length
and error-prone instructions provided in the wiki.
TODO:
- support updating bootloader (once dfu-ram image exists)
- use python implementation of dfu-util to be python only
Change-Id: I3ebe0f54b6e3b7b45478603cc0a5b56e87b1f461
this adds the DFU as application, allowing to flash the bootloader.
a USB DFU alternative is added to flash the bootloader partition.
when the DFU is started as bootloader, the partition/alternative
to flash the bootloader is marked as "not available", and
ineffective.
the same happens for the application partition when DFU is started
as application.
this distinction is make at compile time, not at runtime, because
of size restrictions (the bootloader was already close to the
16 kB limit).
*_dfu_flash.bin should not be mixed with *_dfu_dfu.bin.
*_dfu_dfu.bin should be flashed as application using the already
existing DFU bootloader.
once this images is started (as application), the *_dfu_flash.bin
should be flashed as bootloader using the DFU application.
once the DFU bootloader has been flashed, soft resetting
(not re-powering) will cause the bootloader to start, allowing to
flash the application with a normal image (e.g. not DFU),
replacing the DFU application.
this switch to DFU only happens after downloading (e.g. flashing).
it is planned to have the DFU application erase itself after
flashing, but this is currently not implemented.
Change-Id: Ic273bb593a7669111b0219fe301d7897419167c8
In the end we want to share most of this, irrespective of the "APP".
Let's avoid unnecessary differences.
Change-Id: Icf063d4ca79edf66ffbe8e87a915deb77dec478a
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
the code we used to have in libusb_util.c has been migrated to
libosmousb, a new part of libosmocore.git. Let's remove our historic
copy and use the new shared library instead.
Change-Id: Ib588c08f873c4da8f3a02815ee2767674a6a5061
The printing was always only done at the end of osmo_apdu_segment_in(),
so let's leave the decision up to the user if he wants to print the
state at every iteration or not.
We now provide osmo_apdu_dump_context_buf() to the user so he can obtain
a string representation of the internal state for logging at any time he
requires.
Change-Id: Id3e3cf1605dec84077b158c1c5715f8eef2641d5
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'
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: Iee905c744065df1dc54f04be752a65700897a92c
ERROR: file contains unterminated value_string 'struct value_string change_flags[]': './deps/simtrace2/host/src/simtrace2-sniff.c'
ERROR: file contains unterminated value_string 'struct value_string data_flags[]': './deps/simtrace2/host/src/simtrace2-sniff.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
As of Change-Id I1c8cca2f7f0f0070d7bf1ade676e035c45e4d5ab, a firmware
compiled without ALLOW_PEER_ERASE will not support resetting the hub or
writing to its EEPROM. Let's make sure to remove those options also
from the menu.
Change-Id: I3071332d85e6168947384ddc230298d3293e4668
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
the USB trace now respects the global setting.
the verbosity is also decreased, not showing USB activity unless
debugging.
this also saves some space.
the reset cause is now printed.
the strings increase the bootloader size, but it already exceeded
the 16 kB limit when trace level is set to info.
Change-Id: I9ba08d4bb4f188f6e7a202ea86acb7a42a2054f3
now both partitions (bootloader and application) use a commonly
defined memory location to shared the DFU state (which includes
the magic value to know which part to start), instead of using
a hard coded value.
the bootloader size has now also been restricted to 16 kB.
this limitation is enforced so to not be able to create larger
images, which could be corrupted when flashing the application.
bootloader and application flashing have been successfully tested
on qmod st12 and st34.
Change-Id: I204bed7e9391602672ed894decec1fc12e879275
