When Lc>0 (command TPDU), our response always copied the command
data in front of the response (which is a SW of 2 bytes in this case).
This of course confuses the hell out of users. The response to a Lc>0
TPDU should be just the two-bytes status word.
Introduce the use of msgb->l4h for the point in the buffer from where
we receive data from the card. all bytes before l4h are transmitted
to the card.
Change-Id: Ie3fc7437d39dc330b9f2b7d7960ad2560b6be4b7
* fix run-tests so it can return != 0
* bail out if prepare fails
* add more sanity checks to prepare
* generalize usb-ids, paths
* add test for flashing from application mode
* add test reading simcards via pysim
Change-Id: I246224e29e5936b4fe40cf7d7a5ff83c9940d121
dfu-util -l says
Found Runtime: [1d50:60e3] ver=0002, devnum=72, cfg=1, intf=1,
path="1-2", alt=0, name="UNKNOWN", serial="12345"
Found Runtime: [1d50:6141] ver=0000, devnum=71, cfg=1, intf=3,
path="1-3", alt=0, name="DFU (Runtime)", serial="6789"
One is a simtrace2, one is the octsim - let's make flashing less
exciting by at least telling the user which one is the octsim...
Change-Id: Ifa37c63c97824ce42b3476f53626323cb40b879e
Let's stick to one set of headers, the hand-crafted usb descriptor structs
are prettier than the asf define galore.
Change-Id: I689d7122872b28444b6c5343df3bac0c30f23b1d
This makes flashing a bit more convenient, because pushing the button is
not required. It can be disabled using make DISABLE_DFU_DETACH=1.
Change-Id: I04d05054d1c0e3988b8eafd93c6524f4a0489cb7
this changes the linker script so the first word (smallest unit
since the data needs to be 4 baty aligned) is not reserved for
the RAM section.
this allows the application to write any data at this address
without the rest of the code messing with the content.
since the SRAM is preserved after reset, this allows to share
data between firmware.
in particular it allows the application to tell the bootloader it
should start the flashing procedure.
this is already implemented in the osmo-asf4-dfu DFU bootloader.
if the application wants to switch to the DFU bootloader, write
the DFU magic 0x44465521 (DFU!) at the beginning of RAM at address
(uint32_t*)HSRAM_ADDR, and perform a system reset.
Change-Id: Ibafd08429b05fd3cab6af060904201db83186a4e
libosmocore.git after I656a1a38cbb5b1f3a9145d2869d3b4d0adefcae3
includes support for USB (and a new dependency to libusb).
But there's no libusb1 in the Cortex-M4 anyway :)
Change-Id: I68da7985001f4f9018995166458006ee47cdf216
both the host and the firmware build require a global talloc context
with external linkage, so let's agree on one name.
Change-Id: Idced24869863983bfde0c9c438498999717f2042
Going for __ARM__ to distinguish host and firmware builds is not
sufficient here, since we might be building on a ARM host, so there is
now a OCTSIMFWBUILD define.
Change-Id: Ib07a58b6102b1709f295d08a764c6f118a2d0b9e
The debug uart is shared with slot 7, so in order to use sim slot 7 the
pin config and the uart config needs to be changed. Going back to using
the debug uart works by defining ENABLE_DBG_UART7
Change-Id: I8f3c7c60306941159c35307a5c1e38c2a2bd2fe1
The general idea is to provide hints to cuart so it can calculate
a reasonable timeout value when receiving multiple bytes instead of
having per-byte timeouts
Change-Id: Ia6ad2d83cea48a8661ed2e4eb50f9bcb85218454
The main loop will now poll for finished/failed transactions and handle
them, this was previously handled during the last rx interrupt of a
transaction, which was bad for timing. This does also fix malloc/free
while handling interrupts.
Change-Id: I055110720089e20e65db592eccc3ce4d618e8c63
The previous value would allow using the device
without external power, i.e. on a hub, which leads
to silent failures trying to power up the slots
(nothing happens, no atr will be received)
Change-Id: I40c48ea56151d13de362b8f73cae5b21aba0ebfa
FIXME: The device should offer at least one 100mA configuration.
printing to the buffer is faster than getting the data out, so let's
increase it a bit to drop less information
Change-Id: I343b03d5b06962b90f0c1aaceda03aa871a2f98b
must be be a power of 2, and should be at least as large as the largest
transfer that we might be waiting for - revisit this, is 256 enough?
Change-Id: Id4b4691dd32d465f627ba42c0ba3d509dcf8f42c