Output audio format still unknown, not sure if it's garbage (see lpai
commit) or some weird packed float encoding I'm not figuring out.
Signed-off-by: Eileen Yoon <eyn@gmx.com>
Make the ringbuffer class robust to various block sizes to generalize to
both DCP and AOP.
The first three blocks of the ringbuffer is reserved for exchanging size,
rptr, wptr:
```
bufsize unk
00000000 00007e80 00070006 00000000 00000000 00000000 00000000 00000000 00000000
00000020 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000040 * rptr
00000080 00000600 00000000 00000000 00000000 00000000 00000000 00000000 00000000
000000a0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
000000c0 * wptr
00000100 00000680 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000120 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000140 *
```
Each block is spread out by some block_size multiple of 0x40 (step). The
0th block holds the size of the ringbuffer contents, the 1st block holds
the rptr, and the 2nd block holds the wptr. The actual contents of the
ringbuffer starts after the first three blocks, which will be
collectively called the "header".
However, this block_size isn't constant. DCP seems to consistently use
0x40, but AOP can use both 0x40/0x80. Since we're not given the block_size,
so wemust bootstrap it. Recall we are given the total size of the
rinbuffer in the mailbox message. Since we're always given the size of
the ringbuffer `bufsize` at offset +block_size * 0 (or simply 0), and we
can find the header size by subtracting `bufsize` from the total size.
Since we also know that the header is always 3 blocks wide, we can
divide the header size by 3 to obtain the block_size.
Signed-off-by: Eileen Yoon <eyn@gmx.com>
DCP only gets two reply types: a u32 retcode or a command reply. It
previously checked for retcode by checking length(data) == 4 and
assuming command otherwise. AOP can get other reply types (e.g. STRING
after probing device). It actually sends us the reply subtype in the
EPICSubHeader, so use that information and handle replies accordingly.
Signed-off-by: Eileen Yoon <eyn@gmx.com>
Consistently use an enum for EPICSubtype (used later) and support the v2
EPICService intializer protocol used by AOP.
Signed-off-by: Eileen Yoon <eyn@gmx.com>
Not much to see here, most of the juice is over at:
https://github.com/eiln/avd.git
The kernel driver (m1n1.fw.avd) only really pipes the instruction stream
into the respective hardware FIFOs and then hushes the interrupt lines.
Most of the work (bitstream syntax parsing and instruction generation)
is done in the avid repo above.
I'm hoping to keep this userland-kernel separation in the very imminent
actual driver.
experiments/avd.py: Decode on the command line. Read file for usage.
experiments/avd_e.py: Decode via emulated instruction stream.
experiments/avd_f.py: Decode via Cortex-M3 firmware (for debugging).
hv/trace_avd.py: Tracer. Read file for usage.
m1n1/fw/avd/__init__.py: Driver base class (power, tunables, etc).
m1n1/fw/avd/decoder.py: Codec-specific decode logic + mini media player.
Signed-off-by: Eileen Yoon <eyn@gmx.com>
On m3, these previouly expected-to-be-constant fields have exciting
non-constant values. This updates adt.py to allow them to be
non-constant. The second field is also really a flags field,
though i could not tell you all the flags involved.
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
Only observed with dcp/dptx in linux after initialisation and reset in
m1n1. On the initial startup dcp sends two D576 (hotPlug_notify_gated)
presumendly due to state confusion due to the multiple dptx
connections.
Signed-off-by: Janne Grunau <j@jannau.net>
Same functionality as the readline shell, but based on
ipython so that it has nicer help/autocomplete/etc
Signed-off-by: Daniel Berlin <dberlin@dberlin.org>
When I tried to use the proxyclient shell, I got:
"Exception parsing /device-tree/arm-io/dart-dcp.dapf-instance-0 value […]"
I laid out the hex dump in a text editor, and added line breaks every
56 bytes (the former size of DAPFT8110B):
0000703b020000000080713b0200000020000000000000000000000000000000000000000000000000000000000000000003010000000000
40723b020000000080723b020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000
003b020000007f73073b02000000200000000000000000000000000000000000000000000000000000000000000000030100000000000028
3d020000000040283d020000002000000000000000000000000000000000000000000000000000000000000000000301000000000080003d
020000000380003d020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000e03f02
000000ffffef3f0200000020000000000000000000000000000000000000000000000000000000000000000003010000000000c0403e0200
0000ffff403e020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000433e020000
00ff3f433e020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000783d02000000
03417a3d0200000020000000000000000000000000000000000000000000000000000000000000000003010000000000003c3b0200000000
003e3b020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000403c02000000ffff
473c020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000103c020000004f0c10
3c020000002000000000000000000000000000000000000000000000000000000000000000000301000000000000703d020000000341723d
02000000200000000000000000000000000000000000000000000000000000000000000000030100000000
Looking at the patterns shared by all struct instances
(r0h = 3, r0l = 1, for example), each row appeared to be shifted one
byte to the left compared to its predecessor. This suggests that
DAPFT8110B has only three extra bytes of padding compared to
DAPFT8110.
So, here I introduce DAPFT8110C, a new variant, one byte shorter than
DAPFT8110B. Unlike DAPFT8110, there's no flag to differentiate
between these two variants, so we just have to guess based on what
divisor makes whole structs.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
