The id1 field used on oder SoCs is not constant 0 for all devices on
t8122. Instead just compare the id1 fields of the two first devices.
Fixes "pmgr: Failed to find parent #36 for IOA0\n" errors in
pmgr_init().
Fixes: fb59dc03ca ("pmgr: Fix struct for older SoCs")
Signed-off-by: Janne Grunau <j@jannau.net>
At some point Apple ran out of bits and have to widen the device field
to 16-bit. This adds support for the old 8-bit layout.
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
Account for the differences between the iOS ADT and macOS ADT, and also
some physical differences between Apple Silicon Macs and A7-A11 devoces,
reflected in the ADT.
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
This includes:
- Do not treat iPhone 5 buffer as dummy on 5s
- Added support for 24-bit framebuffer
- When we have a vertical display, use whole fb as console
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
Add support for 4K page sizes, supported by A7-A8X.
Co-developed-by: fenfenS <104295404+fenfenS@users.noreply.github.com>
Signed-off-by: fenfenS <104295404+fenfenS@users.noreply.github.com>
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
This includes
- GXF
- SPRR
- PAN (A7-A9)
- Atomics (A7-A10)
- FIPI (A7-A10)
- DCP
SPRR on T8030 seems to be quite different from M1 (at least according to
qemu-t8030), so keep it disabled for those CPU parts.
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
Cyclone and Typhoon are similar enough to share a file.
Hurricane and Zephyr are the physical cores on A10 backing the
Hurricane-Zephyr logical core.
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
The FreeBSD script added in #185 required patching u-boot since it specified the
loader base/size in a non-standard way. This changes the way arguments are
passed to the bootefi command so it works with the asahi u-boot fork which I've
been using. I also changed the case where the loader isn't specified to have
u-boot boot from the nvme since I have that driver functional enough to have it
mount the root fs now.
Signed-off-by: Ayrton Munoz <a.munoz3327@gmail.com>
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>
