DFU flashing of apps sometimes aborts, and although rare this leads to
broken devices if no boot button or serial/jtag access exists, because
the bootloader will keep trying to start a half-flashed app that then
crashes at some point.
The easiest fix that works with existing bootloaders is to prepend a
small 512 byte stub that calculcates the crc and compares it with the
crc calculated at build time, and then either starts the actual app, or
sets the dfu flag and resets. This ensures we either have a working,
running app, or end up in the bootloader, ready to flash again.
For obvious reasons this only applies to dfu apps, and not to flash
targets like the actual bootloader itself.
Change-Id: Id6df0486c8b779889d21800dc2441b3aa9af8a5f
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: Ie0a3b2273383adbb3303faffd6ff96be7f4cae99
Apply various improvements from Martin Hauke, thanks!
* Put sover into a variable
* Sync BuildRequires with configure.ac
* Update libosmo-simtrace2 summary
* Use %make_build instead of make %{?_smp_mflags}
Change-Id: I35ce3865702f72365b38b0eaa8b28f332dabcd1f
Adjust the soname in the rpm recipe too, to fix:
error: File not found: /home/abuild/rpmbuild/BUILDROOT/simtrace2-0.8.0.202112100026-1.1.x86_64/usr/lib64/libosmo-simtrace2.so.0*
Change-Id: I748f44409ac736abbd5c18e31ae02d025dee2c77
The previous value was way too low and led to reenumeration issues when
switching from app to bl because the hosts are fairly lenient and
feature long delays until they accept disappearing devices as gone for
good instead of ignoring a presuambly flaky usb cable or connection.
Related: SYS5061
Change-Id: I9b8c8bf794ad5b94fc7ea2a01d1ebf4e36862c36
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
This bl updater can be flashed as app and will update the bootloader and
then
delete itself before resetting the sam3, so the device will end up in
the newly
updated dfu bootloader afterwards, without having to press the
bootloader button
or requring any other manual interaction, ready to receive a new
application image.
Building the blupdater requires a previously built dfu-flash bootloader
bin file that
will then be embedded into the app during building.
Related: OS#1704
Related: SYS5061
Change-Id: I53dea57bba790a2ab3245d9483e0ff1c8d19d5e3
This led to occasional crashes for targets with leds since it was
introduced 3 years ago
The interesting thing is that most of the time it didn't crash...
Change-Id: Ia6a1b1fc0e44a301b4fb1d9c9fdbc27d61dcab97
Supposed to be used with https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm
+ distro provided binutils-arm-none-eabi package, might provide better and more reliable
binary sizes, especially for the bootloader.
Just run USE_CLANG=1 make
Change-Id: I1a19f40d44797efad5c46121e73115ed738a095b
This avoids
ERROR: osmo_log_info == NULL! You must call log_init() before using logging in log_check_level()
Change-Id: Id355ef33e10164f8e8eb40c2fd0b606bc8e9b6f7
This code already calls osmo_libusb_init further above in the top
of the main() function, so there's no use of calling libusb_init()
directly in the same function lines below.
Change-Id: I2e0c7446aaa644c5aae1059ce91ff9f729903cbc
We use other osmo_libusb_* functions later in the code, so it is best
to initialize the library via libosmousb, and not directly.
Change-Id: I2fd981935e1420e529f5dd8a98edd347c317284c
Let's create and publish binary builds for 'trace' on BOARD=ngff_carde.
According to SYS#5525 this is verified working since two months ago, so
there's no reason to withhold the binary builds for it.
Change-Id: I8a98002ef5aa58e5a3d49627323fe11505508bc8
Related: SYS#5525
This reverts commit e6a76c7bf4.
Might or might not cause weird issues depending on gcc and binutils
versions, let's see if this helps.
Change-Id: I2f593fd5e0f1494aae6b9fcfb2160a6c9168f5b8
We keep running out of rom space, so reduce tracing to nothing for alle
dfu targets, and let's hope newer gcc versions stop producing more
code...
Change-Id: I7d2947c84097035bed00ad489a175d614b4c388e
It does fit with some compiler versions, while others overflow the bl region,
so just reduce the trace level a bit to make it fits all the time.
Change-Id: I168a847da8dfc585aaeef0030f95fc225a713147
This makes sure downloads.osmocom.org will get cardem images
for the new ngff_cardem board.
The dfu loader was not enabled as it currently overflows the ROM
region by 200 bytes, see OS#5210.
Change-Id: Id2b7925c823fb19f880e06a205764d2b19de4ad4
Related: OS#5210
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
There is no obvious reason why the st should be stuck in cardem mode
without a working running util on the host side since there is no state
that is being kept, so switch back to using the local sim upon reset.
Change-Id: Ib622af0027d40b4e8afbb0fa0d3689f0dbfcac92
Single threaded evaluation is (assumed to be!) left to right, depth
first - but with concurrent make using -j this breaks, because the
actual usb string header is generated after the attempt to concurrently
compile the code that needs it, since there is no explicit order among
the all: dependencies.
This is fixed by properly adding a dependency on that header.
Change-Id: I0bdf915deabeda861f6398e654764918e58a64c2
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 simtrace-tool is a command line tool which can be used to e.g.
manually request a modem reset.
Change-Id: I3a8896ac2b3caef7590b51118359e5caed820a40
we shouldn't use a local copy of the device id list, which is already
outdated now that OCTSIMTEST support has been added to libosmo-st2
Change-Id: I2231006b94c33fe3b28ce37b0d54c67206751058
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
See Help->About Wireshark->Folders tab,the usual place this should go is
~/.local/lib/wireshark/plugins
Hot reload possible after editing using Analyze->Reload Lua Plugins
Change-Id: I360ab522dabc3a378969df36efd3b48fc4cade3c