Call the script from the proper directory, and cd into the topdir on top
of the script. Fixes:
/build/contrib/jenkins.sh: line 71: contrib/prepare_upload.sh: No such file or directory
Related: OS#4413
Change-Id: Icbfaa5579aab887830ca90b24a2e322df8d98f4f
Don't create copies of firmware files with version strings appended in
the normal build. Only do this before uploading the firmware files.
I have verified that "make" before this change and
"make; contrib/prepare_upload.sh" after produce the same files.
Close: OS#4413
Change-Id: I118a4ff397a178281c26a6b98112fa66b6f049ab
Use .tarball-version from the topdir, because it only gets written there
when generating the OBS package. Remove the duplicate git-version-gen
script and use the one from the topdir to generate a version string if
building from the git tree.
Related: OS#4413
Change-Id: I4b197a218ab44632ff182ffbd72e15c2b20db341
Fix having the version set to UNKNOWN in all packages built by OBS. The
osmo-ci.git scripts generating the source packages to be built by OBS
generate a ".tarball-version" file with a version string like
"0.7.0.70-657c", but it did not get used because the path was wrong.
Related: OS#4413
Related: https://osmocom.org/projects/cellular-infrastructure/wiki/Git-version-gen
Change-Id: Ic0b06011a604beec7c1c907c2c6e4ae927456e2e
Fixes:
dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1)
Related: OS#4413
Change-Id: I4c474547233ebb87a1246b01fbd7ff8879921c21
dfu flashing the ST12 was easy, but i was never able to
get ST34 into dfu mode. Changing the firmware so it resets
itself just like the octsim instead of starting a timer and
waiting for a reset from the host made it work every time for me.
Change-Id: Ida636ec925f40d6d56551f170150181350d03bbd
This renaming is to avoid any confusion with the osmo-remsim
project, living in its separate git repository.
The simtrace2-cardem-pcsc doesn't feature any 'remote' part. Rather,
it emulates the SIM card interface towards the device/phone/modem,
and forwards it to a local PC/SC card reader.
Change-Id: Ic15f0a89964a72fe3ab7a5145a073720f6207e24
The UDP based forwarding really only ever was a quick hack to
demonstrate the capabilities.
Meanwhile, we've had the proper osmo-remsim project implemented,
which provides a much more reliable and comprehensive way of
managing SIM card emulation devices (SIMtrace2, sysmoQMOD, ...)
and collection of card readers (sysmoOCTSIM or any other PC/SC
supported readers).
Hence, remove the "UDP forwarding part.
Change-Id: Ia4b9447b95872b6e0dda6dca644f1ed4a87355a0
We are not using any PIO interrupts from DFU mode. It's only used in
the main application firmware (verified by "git grep PIO_ConfigureIt")
Change-Id: Id1447af519df3183061f3d3f156a8dd84789af16
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
libosmo-simtrace2 traditionally had only supported blocking, synchronous
I/O, while other osmocom programs such as remsim-client used
asynchronous USB I/O.
Using async USB I/O for IRQ + IN transfers while using blocking I/O for
OUT transfers doesn't seem to work reliably, so we have to offer a way
to perform the OUT transfers generated within libosmo-simtrace2 in async
mode.
Change-Id: Ib8939bdb7f533cd20a34a30a97f12b782b9816c2
Remove OpenSUSE bug report link, set version to 0.0.0, make it build with CentOS 8 etc.
Related: OS#4550
Change-Id: I8595642bc07bf3044720942a0f1802448920cb50
This may be causing unwanted behavior while parsing the command
line arguments, as reported by some Raspi users.
Change-Id: I5b7db0795d16ab071e255c2c689e3b4872a933bb
Related: OS#4223
The original code assumes that calls to PIO_ConfigureIt() are only
made once e.g. during board start-up. Hoewever, we call those
at USB SetConfiguration time, when we know which particular hardware
function we are supposed to perform. This means that after the host
has issued SetConfiguration more than a given number of times, the
code will assert() due to overflow of the static array.
Let's check if we already have allocated an array slot for a given pin
and reuse that allocated array bucket rather than allocating new ones
for the same pin.
Change-Id: I0c46d4b51eeebd58a8786d65e31e7a84e65b6a8e
Related: OS#4454
If we do this, the resulting USB code will fail on any of the
USB-IF Chapter 9 tests. EP0 should not be reset.
Change-Id: I070faf4cb7029d3ccfa6c63f8f04aa0f02657536
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
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
Kevin Redon
Oliver Smith
Eric Wild
Harald Welte
Leonard Hübner