bob_x2 has quit [Remote host closed the connection]
bob_x2 has joined ##raspberrypi-internals
jn has quit [Ping timeout: 256 seconds]
jn has joined ##raspberrypi-internals
jn has joined ##raspberrypi-internals
jn has quit [Changing host]
f_ridge has quit [Remote host closed the connection]
f_ridge has joined ##raspberrypi-internals
Bitweasil has quit [*.net *.split]
NightMonkey has quit [*.net *.split]
Bitweasil has joined ##raspberrypi-internals
NightMonkey has joined ##raspberrypi-internals
kbingham_ is now known as kbingham
jcea has joined ##raspberrypi-internals
Guest92 has joined ##raspberrypi-internals
<Guest92>
Hi. I have recently been doing some reverse engineering work on the SMI and GPIO hardware on the RPI Zero 2 w, and was hoping to find others to compare notes with
<clever>
Guest92: *waves*
<clever>
Guest92: ive mostly used SMI with the existing linux driver
<clever>
but these guys also RE'd it more, and wrote some proper docs
<Guest92>
I looked at the linux driver, the lean2 blog/code and the caribouLite code/design
<clever>
ah, nice
<Guest92>
and then did experiments with Circle lib and 1GHz logic analyzer
<clever>
ahhh nice, my 100mhz scope is a bit limiting
<Guest92>
things I have not seen documented by other devs:
<Guest92>
1) REQ line (SD16) is used to device-pace both reads and writes from the device
<Guest92>
2) WrREQ (SD17) is an <output> from the PI, not an input
<Guest92>
WrREQ goes high when the PI has data in the SMI write FIFO and the device deasserts REQ (ie, looks like SD17 allows SMI to request that device assert REQ to receive data)
<Guest92>
latency between device asserting REQ and SMI asserting SE is 16ns (with 500MHz SMI clock)
<clever>
i heard from one of the pistorm guys, that i think the raw data register, will stall the axi bus when in dreq mode
<clever>
so you dont have to poll a fifo status reg
<Guest92>
yes, I was trying to get the CPU to be a 'smart DMA controller', feeding the SMI fifo instead of DMA
<Guest92>
But I can only write the SMI data reg with SMI disabled. Attempting to write to SMI_D with the SMI subsystem enabled causes an error and SMI to halt
<clever>
do you have a name or github acct, so i can add credit to the txt file?
<clever>
there is also a sort of concurrent access i theorized is possible, but ive not figured out the details
<clever>
the 2d core supports an SMI based video mode
<clever>
my rough understanding, is that you just configure the device timings and address, and the 2d subsystem will just dump pixel data into the fifo
<clever>
and ive seen hints, that you can use SMI_D to talk to a second device at the same time
<Guest92>
SMI reg setup is time consuming, so I was unable to switch between read & write every ~400ns which was a design requirement
<clever>
thats why there is a SMI_A and SMI_DA
<Guest92>
My github name is JohnMBrooks, but I don't use github much. I primarily do low-level dev for videogame consoles (day job), and retro dev for Apple II (hobby)
<clever>
ahhh
<clever>
your probably aware of the pistorm guys then?
<Guest92>
no, what are they doing?
<clever>
emulating an m68k cpu in aarch64 with a JIT
<clever>
then capturing all access to a 4gig window, and bit-banging the m68k cpu socket on an amiga motherboard
<clever>
so you can just shove an entire rpi-zero2 into the m68k cpu socket, and boot the stock amiga os/kernel
<Guest92>
lol, cool
<clever>
and with the power of JIT and a modern cpu, its just screaming along
<clever>
until it has to hit slow ram or mmio
<clever>
in amiga terms, fastram is ram on the accelerator card, and chipram is on the motherboard
<clever>
and dma can only reach chipram
<Guest92>
I made a 1080p display card for retro AppleII 5 years ago, but the pandemic chip shortage killed the parts I use, so I am trying to see if RPIZ2W can work
<clever>
and even back in the day, they had accelerator cards, which was basically just some ram and a cpu, that ran at a higher clock
<Guest92>
But the timing is tight, with the card emulating a CRT beam at 980ns intervals (1mil FPS)
<clever>
and by making the fastram private to the cpu, they dont have to obey the same clock specs
<clever>
this would be running over the hdmi port on the pi
<Guest92>
Apple did something similar in 1986 with the Apple IIGS, and then a few years later with the Apple IIc+, put a faster-clocked CPU and RAM/cache alongside the legacy low-clocked video & IO
<clever>
you can see that one peripheral range has "hdmi" repeating in all of the undefined registers, and "dbus" in the other
<clever>
but when i boot under the closed firmware, that "dbus" region turns into mostly nulls
<clever>
my theory, is that half of the hdmi peripheral is just disabled entirely, and not responding to any r/w actions
<Guest92>
so if linux w/firmware is booted with no HDMI active, and then HDMI is hotplugged, can linux setup HDMI, or does it ask broadcom firmware to do it?
<clever>
i think the hdmi is already enabled, before linux even starts booting
<clever>
but i didnt actually check that
<Guest92>
even if no HDMI display is present and no EDID query?
<clever>
let me dig out a pi and see.....
<clever>
grabbed a random 02 off a shelf, its already got an sd card in it, and i think its booting....
<clever>
waiting to see if anything appears on the wifi....
<clever>
hmmm, let me pop in hdmi to see why its not booting
<clever>
i see a login prompt!, so why is it not on wifi.....
<clever>
rfkill: WLAN soft blocked
<clever>
CTRL: Invalid group 'wheel'
<clever>
Failed to initialize control interface 'DIR=/var/run/wpa_supplicant GROUP=wheel'.
<clever>
its a borked install, due to copying the wpa config from another machine
<clever>
Guest92: related to your VidHD, pistorm has 3 ways of getting HDMI out
<Guest92>
Took a look at the pistorm github. Looks like they are bitbanging GPIO (pistorm/gpio
<clever>
the main one, is to just use the rpi's internal hdmi, via the RTG driver stack, but a lot of games dont support RTG
<Guest92>
unsigned int ps_read_16(unsigned int address) {
<Guest92>
while (*(gpio + 13) & (1 << PIN_TXN_IN_PROGRESS)) {}
<clever>
yeah, but they did look into SMI at one point, not sure why they arent using SMI currently
<clever>
the second option is just rgb2hdmi
<Guest92>
I would expect the above to take about 500ns, so bus speed would be slower than real Amiga hardware
<clever>
and the 3rd is a custom rgb2csi adapter, so the pistorm pi can then capture it, and re-output it over hdmi
<clever>
i'm not sure what tricks they are pulling off, but emu68 is able to do that entire dance within a single bus transaction on the amiga motherboard
<Guest92>
ah, the good old Amiga genlock, toaster
<Guest92>
I suspect they are rarely on the bus given the slow GPIO time
<clever>
and thats part of why the pi5 isnt pistorm friendly
<clever>
the pcie bus transfers just add too much latency
<Guest92>
if the emu68 is almost always accessing internal mem, then having the bus run at 1Mhz or less may be acceptable
<clever>
one sort of ugly trick they have, there is an fpga acting as glue between the gpio and bus socket
<clever>
the fpga is clocked by the pi, via a GPCLK channel
<clever>
and i think the gpio and GPCLK are on the same clock parent
<clever>
so the edges all line up nicely
<Guest92>
Is there a way to send a screen capture on here?
<clever>
irc doesnt really support that, discord or a custom rtsp stream would work
<clever>
and after much searching, i found an OTG adapter, now i can control this zero2
<clever>
now to brute-force my own pw!
<clever>
hmmm, weird, /etc/shadow is identical between my laptop and pi, for that user, let me try that user again.....
<Guest92>
I sent the logic analyzer screenshot of 700+ns GPIO stall to you via email
<clever>
yep, i see that
<clever>
have you done anything with cpufreq?
<Guest92>
I set Turbo in the firmware, then set the ARM freq to 1000MHz
<clever>
but linux is still free to change the clocks
<Guest92>
I dedicate ARM core 1 to GPIO handling, idling cores 0,2,3
<clever>
i dont see any backwards compatability code for vchiq stuff
<clever>
i assume the mailbox property works on older models as well
<clever>
so in theory, circle can just implement the mailbox code i just linked, and then you can run `vcgencmd get_throttled` and `vcgencmd measure_clock arm` from circle
<clever>
assuming you have a more recent start.elf
<clever>
oh, and i just had a thought, can you try measuring the interval between each 700ns stall?
<clever>
how far apart are they?
<Guest92>
Yeah, I plan to do that test tonight. The stall didn't happen for 3-4 seconds, so my guess is that the firmware wakes up and does something that interferes with GPIO access
<clever>
for each sprite, you generate a 7 x 32bit structure in a special region of ram
<clever>
less of an overlay, and more, the only way to do any video output
<clever>
the hardware kinda doesnt support a framebuffer
<clever>
what you think is a framebuffer, is just a sprite covering the entire screen
<Guest92>
I thought there were multiple vram DMA sources that could be merged for video output
<clever>
nope, just 3 channels on the HVS
<clever>
there is a shared `uint32_t[4096]` that contains all of the display lists
<clever>
for each sprite, you write a 7 x 32bit entry to that memory, and cap it off with a 32bit termination code
<clever>
then you just tell the hardware what index each channel begins at
<clever>
internally, the HVS has 3 FIFO's that hold composited pixel streams
<clever>
when a FIFO has room for a scanline, the HVS will re-parse the entire display list, fetch image data from ram, composite it directly into the FIFO, and then go back to idle
<Guest92>
cool
<clever>
during that process, it can do pixel format conversions (565, 888, yuv), alpha blending, scaling, and mirroring
<clever>
the pixel valves then read that fifo, at a defined pixel clock, and turn the flow off during blanking periods
Guest92 has quit [Quit: Client closed]
<clever>
and then the PHY's take that throttled stream of pixels and hsync/vsync, and turn it into something usable
Guest92 has joined ##raspberrypi-internals
<Guest92>
I seem to get auto-logged-out periodically
<clever>
it may help if you install an irc client
<clever>
2024-02-12 18:32:06 < Guest92> cool
<clever>
2024-02-12 18:32:26 < clever> during that process, it can do pixel format conversions (565, 888, yuv), alpha blending, scaling, and mirroring
<clever>
2024-02-12 18:32:43 < clever> the pixel valves then read that fifo, at a defined pixel clock, and turn the flow off during blanking periods
<clever>
2024-02-12 18:37:18 < clever> and then the PHY's take that throttled stream of pixels and hsync/vsync, and turn it into something usable
<clever>
the last few things i said
<Guest92>
k. thx
<clever>
for some PHY's like DPI, its barely even a PHY
<clever>
it just exposes the hsync/vsync/data-valid/rgb888 raw on the gpio
Guest92 has quit [Client Quit]
<clever>
for other PHY's like hdmi and vec(ntsc/pal), it has its own view of the video timing parameters, and you get rolling artifacts (like a lost vsync) if the pixel-valve and hdmi/vec dont agree
Guest92 has joined ##raspberrypi-internals
<clever>
for other PHY's like hdmi and vec(ntsc/pal), it has its own view of the video timing parameters, and you get rolling artifacts (like a lost vsync) if the pixel-valve and hdmi/vec dont agree
<clever>
Guest92: at some point, i need to re-open ghidra, and go over the debug build with a fine toothed comb.....