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>
It seems this model does not need it *and* it somehow causes
nondeterministic problems.
Also add a delay to the poweroff/on sequence to be more conservative.
Fixes: #406
Signed-off-by: Hector Martin <marcan@marcan.st>
Unlike gcc, clang enforces -mgeneral-regs-only when used as the assembler so
this removes that flag to fix the error in #393. This is only needed for
utils_asm.S which has code saving/restoring SIMD state, but this commit applies
it to all asm files for simplicity since code for fp regs shouldn't be generated
unless they're explicitly used anyway.
Signed-off-by: Ayrton Munoz <a.munoz3327@gmail.com>
This registers a log buffer IODEV similar to the frame buffer IODEV. It
is using a console IODEV to allow writing to the buffer until m1n1 jumps
to the next stage. This allows also to increase the buffer size without
increasing m1n1's size. The current CONSOLE_BUFFER_SIZE of 8k is not
large enough to hold the entire log of executing m1n1 under the
hypervisor on the M1 Ultra Mac Studio.
Signed-off-by: Janne Grunau <j@jannau.net>
fb_console_reserve_lines() in mmu_shutdown() was causing a blit from the
freed framebuffer, putting heap metadata junk at the top left corner.
Signed-off-by: Hector Martin <marcan@marcan.st>
t8103 and t600x use "asc-dram-mask" in iop-dcp-nub to mask bits out of
DMA addresses. This needs to be used in the firmware mappings
check/remap since the segments have maskable bits sets.
Fixes: 8332e24 ("dcp: Undo carnage from bad stage1 DART code")
Signed-off-by: Janne Grunau <j@jannau.net>
