f_ changed the topic of ##raspberrypi-internals to: The inner workings of the Raspberry Pi (Low level VPU/HW) -- for general queries please visit #raspberrypi -- open firmware: https://librerpi.github.io/ -- VC4 VPU Programmers Manual: https://github.com/hermanhermitage/videocoreiv/wiki -- chat logs: https://libera.irclog.whitequark.org/~h~raspberrypi-internals -- bridged to matrix and discord
<clever> gotta run now, talk to you later
<bonda_000> ok no worries
bonda_000 has quit [Quit: Leaving]
jcea has quit [Ping timeout: 240 seconds]
bonda_000 has joined ##raspberrypi-internals
hackkitten has quit [Ping timeout: 246 seconds]
hackkitten has joined ##raspberrypi-internals
f_ has joined ##raspberrypi-internals
jcea has joined ##raspberrypi-internals
<f_> bonda_000: f_ridge is a bridge bot, the actual message author is in < and >
<f_ridge> <f​_[mtrx]/M> For example
<bonda_000> Oh I didn't know that
<bonda_000> clever: testing my horizontal clocks today, found out if I kill the GPCLK01 for some reason Pi freeezes
<bonda_000> haven't had that with GPCLK0
<bonda_000> for some reason GPCLK1 is acting weird
<bonda_000> GPCLK0 produces a 29.5MHz
<bonda_000> GPCLK1 seems to already be enabled for some reason, once I change the GPFSEL oscilloscope shows it's already a 25MHz wave
<bonda_000> and then it won't go above 25MHz after I change the divisor
<bonda_000> both run from PLLD
<bonda_000> at least that's what I write to the register
<bonda_000> I was going to see if I set the FLIP bit on GPCLK1, if it's gonna give me an inverted GPCLK0 if I source them from the same PLL
<bonda_000> with the rest of the config equivalent
Stromeko has quit [Ping timeout: 268 seconds]
Stromeko has joined ##raspberrypi-internals
<clever> bonda_000: the 25mhz gpclk is to run the ethernet/usbhub chip
<clever> while the 32khz gpclk is to run the wifi/bt chip
<bonda_000> That's what I was thinking
<bonda_000> Strangely it is not <reserved> in the datasheet
<clever> which datasheet?
<bonda_000> bcm2835
<bonda_000> the colored table
<clever> thats pi1, it never had wifi
<clever> and they didnt update the datasheet when newer models came out
<bonda_000> yeah if I kill it I have to reboot
<bonda_000> soldered the run header today! its so nice now I don't have to mess with the wires
<bonda_000> wired the camera
<bonda_000> The horizontal clocks seem to be 5V though
<bonda_000> don't know if 3.3 can drive it
<bonda_000> but the vertical clocks are shaped from 3.3V
<bonda_000> worked with GPCLK2
<bonda_000> but the FLIP didn't do anything
<bonda_000> just added a bit of delay
<clever> why does the camera need hsync and vsync?
<clever> you might be able to abuse DPI to get those signals
<bonda_000> It says about FLIP "Switching this control will generate an edge on the clock generator output" seemingly that's where the slight delay comes from
<bonda_000> maybe I have to flip it until they are opposite way
<bonda_000> there is a book by Nakamura about ccd sensors
<bonda_000> the electronic shutter makes the charge-couple device accumulated charge leak into vertical analog shift registers
<bonda_000> each of these feed into a single horizontal analog shift register
<bonda_000> so if your horizontal line is, say 625 pixels, the vertical clock is horizontal clock divided by 625
<bonda_000> sony icx415aq there is a nice diagram in the datasheet
<bonda_000> that's the one that I got
<bonda_000> they sell a vertical driver for it but I decided I can make my own with microcontroller timers
<bonda_000> but it all has to be synced to a master clock
<clever> definitely sounds like a job for DPI
<bonda_000> I don't know how crucial synchronization is on the VPU side, but in the datasheet in the timing charts you can see they insert dead lines
<bonda_000> so your signals reach the image processing software I guess
<clever> DPI is altmode 2 i believe
<bonda_000> is that for the VPU?
<bonda_000> yeah I know
<bonda_000> DPI/CSI and you have to order documentation from MIPI
<clever> no, your thinking of DSI
<bonda_000> I'd rather just use SMI
<clever> DPI is far simpler
<clever> gpio0 is the pixel clock
<clever> gpio 1 is data valid/enable, it tell you if your in a blanking period or not
<clever> gpio 2/3 is vsync and hsync
<clever> gpio4-27 is the raw 24bit color, according to the chosen mode from https://i.imgur.com/9IqVbUp.png
<clever> now, what happens if you only set gpio 2/3 to alt2, and dont configure the rest?
<clever> it will emit hsync and vsync pulses, of the desired length, at the desired rate....
<bonda_000> is this also not in the bcm2835 datasheet?
<bonda_000> most pins alt2 is <reserved>
<clever> its not in the datasheet
<clever> it got released later on
<bonda_000> in fact, all of them
<clever> and RPF never goes back to update the old datasheets
<bonda_000> oh well
<bonda_000> I did go some lengths to get this v-sync but that's okay
<bonda_000> dpi is what?
<clever> a video output port
<bonda_000> display peripheral interface?
<clever> not sure what it stands for
<bonda_000> well I need to read pixels
<bonda_000> I'm not at the output stage yet
<clever> 2024-05-14 12:42:49 < clever> now, what happens if you only set gpio 2/3 to alt2, and dont configure the rest?
<clever> 2024-05-14 12:43:04 < clever> it will emit hsync and vsync pulses, of the desired length, at the desired rate....
<clever> and it will only emit vsync and hsync
<bonda_000> ah I see what you mean
<bonda_000> its like for those parallel LCDs
<clever> exactly
<clever> but you can abuse it, as a vsync/hsync generator for your camera
<bonda_000> true
<clever> this has all of the video timing parameters, and the desired frame rate
<bonda_000> I do have a display connector and I think it is a MIPI DPI
<bonda_000> on my pi 3B
<clever> this does all of the math to figure out the pixel clock and clock divisors
<clever> line 140 puts the video timing parameters into the pixel valve
<bonda_000> so you are saying this onboard DPI can be re-routed to the 40 pin GPIO header?
<clever> DPI is only ever on the 40 pin header
<clever> DPI and DSI are totally different things
<bonda_000> oh
<bonda_000> gotcha
<clever> DPI is a raw parallel interface
<clever> DSI is a high speed serial interface
<bonda_000> there's a CPI
<bonda_000> in the brcm_usrlib
<clever> ive not heard of that one before
<bonda_000> cpi.h
<clever> but there is a fishy AVEOUT and AVEIN on alt3 and alt4, that have never been explained
<bonda_000> has some cryptic register names S,R,F,W
<clever> i see, yeah, that is weird
<bonda_000> at peripheral address 0x7e800000
<bonda_000> yeah there's a dpi.h and cpi.h
<bonda_000> I wonder if they have anything in common
<bonda_000> this dpi.h has only one 'C' register which is probably a horse crap like the ISP that has only an "ID" register in this lib
<clever> https://i.imgur.com/jn5nEo3.jpeg this would be DPI
<clever> nope, that truely is all DPI needs
<bonda_000> is that an analog oscilloscope?
<clever> tektronix 2232, analog/digital
<bonda_000> I've only ever worked with digital
<clever> in digital mode, it captures with an adc, stores it to ram, then reproduces the signal with a dac to draw to the crt
<clever> in analog mode, it just generates a sweep, and feeds the raw signal into the crt
<clever> analog mode can get pretty dim when the signal doesnt repeat often enough, and has no storage at all
<clever> digital mode can maintain the waveform between triggers
<clever> and even save it to flash, or a plotter, lol
<bonda_000> so does it have any advantages to the digital version?
<clever> cant think of any
<bonda_000> my digital pretty much a university physics class has more than I need
<bonda_000> I got the cheapeast one there was of those I know are reliable
<bonda_000> with unreliable, had some expensive boards fried with ground difference
<bonda_000> its 50MHz so my 29.5MHz square wave looks almost like a sine wave
<bonda_000> anything 10MHz and below looks like it should
<bonda_000> although it says 1GSa/s
<clever> bonda_000: https://imgur.com/a/elgTNmP
<clever> the first image is a pi5, playing a bit-stream out a gpio at 200mhz
<clever> because it takes 2 bits to go from high to low, that produces a "square" wave at 100mhz, which is the analog limit of my scope
<clever> the 2nd image is a pi4 bit-banging the gpio from pure VPU assembly, with some busy loops to delay it
<clever> and the 3rd image is the same VPU assembly, but with the busy loops removed, it reaches 125mhz
<clever> you can also clearly see, how the peak2peak amplitude is suffering, the scope cant handle such high frequencies
<bonda_000> I guess it's the computer within it
<bonda_000> it samples at 1GSa/s but the computer isnt calculating it at resolutions smaller than 5ns
<bonda_000> so skips samples
<clever> i think in my case, its an analog problem
<clever> the voltage just cant rise that fast
<bonda_000> so I just noticed that subsequent FLIP murders the clock
<clever> yeah, you dont want to be using flip
<clever> give dpi a try
<bonda_000> so
<bonda_000> can it generated inverted clocks?
<bonda_000> mine needs two horizontal clocks that are inverse of each other
<bonda_000> when one is high, the other must be low
<bonda_000> 3 vertical clocks and 1 substrate clock, 2 horizontal clocks, 1 reset gate clock
<bonda_000> is what this sensor requires
<bonda_000> I don't even know if it can accept 3.3V horizontal clocks
<bonda_000> if VHL of its logic is at 3.3 or below
<bonda_000> VLH*
<bonda_000> I had a NAND for that but it's too slow
<bonda_000> 60 ns propagation delay
<bonda_000> the datasheet doesn't specify the Vhl and Vlh for horizontal clock, only the overlap of two
<bonda_000> I'll come back in a bit
bonda_000 has quit [Quit: Leaving]
bonda_000 has joined ##raspberrypi-internals
<bonda_000> back here
<bonda_000> clever: oh yeah flips do the thing
<bonda_000> clever: 2 flip its almost half period overlapping
<bonda_000> don't have that software that I had on windows to capture a screenshot
Stromeko has quit [Ping timeout: 256 seconds]
Stromeko has joined ##raspberrypi-internals
f_ has quit [Quit: To contact me, send a memo using MemoServ, PM f_[xmpp], or send an email. See https://vitali64.duckdns.org/.]
<bonda_000> Not quite sure how that it works though
<bonda_000> it does shift the phase of the second waveform and they are in sync, since both are driven from the same PLL
<bonda_000> but it's different every time I restart the clock
<bonda_000> do it 3-5 times and I randomly get inverted clock
<bonda_000> Not sure if that's because I'm running on linux or what but it doesn't seem to be deterministic
<bonda_000> clever: do you happen to have one of those official raspberry pi cameras or know anyone that has?
<bonda_000> it seems that cpi a "camera parallel interface" is a thing and it may be on ALT3/ALT4 of the first 16 gpio pin
<bonda_000> CAM0_MISC has a CPI enable bit
<bonda_000> and the only mention within the .elf is here:
<bonda_000> undefined4 unicam_reset_cpi(int param_1)