The previous mechanism of retrying a failed write could become a
infinite blocking loop (until watchdog tiemout).
Also the array size is used to know how much data to write and verify
instead of a constant.
Change-Id: I8d2d090c5f4d1195f4c7eb29b3958a7bb05f56ec
The Atmel AT24C02 defines a maximum tWR waiting time after a byte
write of 5 ms before a next write.
Enforcing this wait time also fixed the failed verification in qmod,
where it was reading 0xffff instead of the written value.
Change-Id: I42c90b8d0329e425f275067e87d584212a43a90b
The qmod does not have a separate force button as simtrace has.
Instead it check is TX and RX of UART are shorted using PIO.
If the pins are not set back to the UART peripheral, the TRACE/debug
console output will not work anymore.
Change-Id: Id434b49909d6395a2f93a00f39d2d770a5725466
the curent local copies of libosmocore headers + source is a temporary
hack anyway. We should instead rely on a system-wide install of
libosmocore cross-compiled for arm-none-eabi. But leave that as a
second (later) step beyond this patch.
Change-Id: Ia63fd842d45a2b404233b4326050e7eda0604cf0
Each board can define its own conditions on which the controller should
boot into DFU mode rather than normal application mode. Let's move the
"UART loopback jumper" to QMOD specific part. For SIMtrace we have an
actual button and can use that in a future patch.
The logic to detect if the respective module is already initialized
or not was broken. When performing initialization, we of course need
to set initialized=1.
We now generalize the USB communiction and abandon the 'req_ctx'
structure inherited from openpcd. Instead we use the libosmocore 'msgb'
structure to handle incoming and outgoing USB tranfers. We also use
linuxlist-based msgb-queues for each endpoint.
the default boot state should be to use the local SIM, until the user
changes it (currently only possible via entering '!' or '@' on the
serial console). The code so far had this completely inverted.
The port mapping is now as follows:
* port 1: ST12
* port 2: modem 1
* port 3: modem 2
* port 4: ST34
* port 5: modem 3
* port 6: modem 4
* port 7: daisy-chaining port
This makes sure that we'll re-enumerate on the USB, as a CPU reset
apparently doesn't automatically release the pull-up and notify the hub
that we were gone?
For some strange reason my output is garbled in both the 'screen' and
'cu' teerminal programs and 'raw' terminal (stty) mode. I fail to
understand why, but let's simply adjust the code as needed for now.
This way we can easily check with 'diff' for differences in our code and
Atmel softpack. Also, this layout is more suitable for building various
different firmware images (e.g. factory-test, dfu-loader, main
application) for a variety of different boards (simtrace, owhw, qmod).
