00:07 <Armbian-Discord> <c​lever> well, its using the strength of the PIO, you can take a stream of 32bit samples, and just clock them out some gpio at any defined rate you want, up to 1 sample per clock

00:08 <Armbian-Discord> <c​lever> hdmi/dvi is 4 differential lanes, but the rp2040 lacks differential pins, so its cheating by just bit-banging 8 pins at once and PIO can easily take 8bit chunks from each 32bit sample, and shift it out 8 pins on every clock

00:09 <Armbian-Discord> <c​lever> so the only hard part, is creating an array of 8bit samples, and keeping ahead of that playback

00:09 <Armbian-Discord> <T​onymac32> I've played with similar configurations before

00:09 <Armbian-Discord> <T​onymac32> https://www.parallax.com/propeller-1/

00:09 <ArmbianHelper> ^ Propeller 1 - Parallax

00:10 <Armbian-Discord> <T​onymac32> https://www.infineon.com/cms/en/product/microcontroller/32-bit-psoc-arm-cortex-microcontroller/32-bit-psoc-5-lp-arm-cortex-m3/

00:10 <ArmbianHelper> ^ 32-bit PSoC™ 5 LP Arm® Cortex®-M3 - Infineon Technologies

00:10 <Armbian-Discord> <c​lever> was the propeller just some arm-m cores? or something special?

00:10 <Armbian-Discord> <T​onymac32> It was a spaecial parallax-designed core

00:10 <Armbian-Discord> <c​lever> ah, same as the PIO then

00:11 <Armbian-Discord> <T​onymac32> I would guess it took some queues from the Scenix SX

00:12 <Armbian-Discord> <T​onymac32> the SX was a 50 MHz micro from forever ago that was designed to implement serial protocols in software

00:12 <Armbian-Discord> <T​onymac32> Parallax aquired it

00:13 <Armbian-Discord> <c​lever> there are ~3 things in PIO that allow continuous sample playback 1: there is the out 8 opcode, which just takes 8bits from the output shift register, and presents it on 8 gpio 2: the PIO can be configured to auto-pull from a FIFO when the OSR runs dry, so you can do 8bits on every clock, and never pause 3: there are loop start/end registers you can configure, so the processor will loop automatically without a jump

00:13 <Armbian-Discord> opcode, saving another cycle on each loop

00:13 <Armbian-Discord> <c​lever> it also has some other opcodes that let it implement more complex bi-directional protocols, but hdmi/dvi doesnt need those

00:14 <Armbian-Discord> <c​lever> the other major factor, is that while the rp2050 is rated for 125mhz usage, the dvi demo overclocked it beyond 400mhz, lol

00:17 <Armbian-Discord> <T​onymac32> luckily my monitors still have VGA ports, so I can use an ESP32 http://www.fabglib.org/

00:17 <ArmbianHelper> ^ FabGL: FabGL Library

00:17 <Armbian-Discord> <T​onymac32> in case you wanted to also emulate windows 3.0 on the same device 😄

00:18 <Armbian-Discord> <c​lever> https://www.youtube.com/watch?v=GHDh9RYg6WI

00:19 <Armbian-Discord> <c​lever> a baremetal 3d demo i wrote, running on the rpi 1

00:19 <Armbian-Discord> <T​onymac32> baremetal videocore? or arm?

00:20 <Armbian-Discord> <T​onymac32> I'm guessing the videocore. cool

00:21 <Armbian-Discord> <c​lever> yeah, running entirely on the vpu

00:21 <Armbian-Discord> <c​lever> the arm core isnt even turned on in that demo

00:28 <Armbian-Discord> <M​icroLinux (Salva)> Noiceee

00:28 <Armbian-Discord> <M​icroLinux (Salva)> Can you explain how that works, framebuffer, etc. Bc I don't know anything about that

00:29 <Armbian-Discord> <M​icroLinux (Salva)> I wasn't aware that videocores allowed such stuff neither

00:29 <Armbian-Discord> <M​icroLinux (Salva)> Also, why you mention vpu??, bc the gpu should be rendering such stuff..

00:41 <Armbian-Discord> <c​lever> the RPI has ~4 separate clusters of compute cores

00:41 <Armbian-Discord> <c​lever> the 1-4 arm cores you expect

00:41 <Armbian-Discord> <c​lever> 2 VPU cores

00:41 <Armbian-Discord> <c​lever> the V3D/QPU cores (where 3d shaders run)

00:41 <Armbian-Discord> <c​lever> and the ISP (still a blackbox to me)

00:42 <Armbian-Discord> <c​lever> the v3d is basically used to take a list of polygons, textures, and shaders, and turn it into a 2d bitmap in ram

00:42 <Armbian-Discord> <c​lever> the hvs+pv+ a random phy, is then used to a list of 2d bitmaps into a video signal, depending on which PHY is used

00:43 <Armbian-Discord> <M​icroLinux (Salva)> You are an experienced rpi ninja

00:45 <Armbian-Discord> <c​lever> https://www.youtube.com/watch?v=JFmCin3EJIs

00:45 <Armbian-Discord> <c​lever> https://www.youtube.com/watch?v=suswjbpR1HU

00:45 <Armbian-Discord> <M​icroLinux (Salva)> Well, I wasn't aware that V3D was labeled as VPU since those are use for media decoding/encoding abd gpus are for 3d/2d acceleration

00:45 <Armbian-Discord> <c​lever> the VPU and V3D are entirely seperate blocks

00:45 <Armbian-Discord> <M​icroLinux (Salva)> Ahhh, okay

00:45 <Armbian-Discord> <c​lever> the last 2 videos, are examples of what the 2d core (hvs) can do on its own

00:46 <Armbian-Discord> <M​icroLinux (Salva)> Also clever

00:46 <Armbian-Discord> <M​icroLinux (Salva)> Since you know about graphics

00:48 <Armbian-Discord> <M​icroLinux (Salva)> I was testing games that weren't meant for KMSDRM on.. KMSDRM, trying to get the best performance as possible, since glmark2 differences are stupidly high comparing x11 vs wayland, and I didn't note such jump going from x11 to wayland on real games, the same with KMSDRM... anyway, it's amazing we can do so (I tested some x86_64 games on KMSDRM)

00:49 <Armbian-Discord> <M​icroLinux (Salva)> Anyway, very few stuff run there haha but would be cool to tey to add those on batocera since we don't need xorg neither wayland, just pure KMSDRM

00:49 <Armbian-Discord> <M​icroLinux (Salva)> I use box64 emulator of course

00:49 <Armbian-Discord> <c​lever> the 2d core on the rpi very closely matches what KMSDRM does with planes and crtc stuff

00:50 <Armbian-Discord> <c​lever> basically, you generate a list of images in ram, for each image you list off its address, stride, pixel format, source w/h, dest w/h, and dest x/y

00:50 <Armbian-Discord> <M​icroLinux (Salva)> Well, my goal with KMSDRM was to improve mostly rpi4 user's experience since xorg does poop on rpi4

00:50 <Armbian-Discord> <c​lever> the hardware will then composite all of the images together on the fly, and generate a video signal from that

00:50 <Armbian-Discord> <M​icroLinux (Salva)> Do you own other pies?

00:51 <Armbian-Discord> <c​lever> yeah, i have one of every model

00:51 <Armbian-Discord> <M​icroLinux (Salva)> Noiceee

00:52 <Armbian-Discord> <M​icroLinux (Salva)> They aren't that much rpi ninjas here haha

00:52 <Armbian-Discord> <c​lever> https://cdn.discordapp.com/attachments/857944478269702214/1012887367796932708/bootflow.png

00:52 <ArmbianHelper> ^ [image/png] (59.6KiB)

00:53 <Armbian-Discord> <c​lever> when you turn on any pi in the pi0-pi3 model range, it will begin by executing a maskrom on the VPU

00:53 <Armbian-Discord> <c​lever> that rom is responsible for loading bootcode.bin from one of 8 supported boot sources

00:53 <Armbian-Discord> <c​lever> https://github.com/librerpi/rpi-open-firmware/blob/master/docs/rom.txt

00:53 <ArmbianHelper> ^ rpi-open-firmware/rom.txt at master · librerpi/rpi-open-firmware · GitHub

00:54 <Armbian-Discord> <M​icroLinux (Salva)> But rpi4 is different in which way?

00:54 <Armbian-Discord> <c​lever> on most models, only the SD card is enabled

00:54 <Armbian-Discord> <c​lever> the pi4 maskrom is massively scaled back, only supporting 3 sources, SD/SPI/USB-device

00:54 <Armbian-Discord> <c​lever> and instead of bootcode.bin on the SD card being the primary way of booting its a tagged blob in SPI flash

00:54 <Armbian-Discord> <M​icroLinux (Salva)> Ahh yeah

00:55 <Armbian-Discord> <c​lever> that change allows adding features like usb-boot after production

00:55 <Armbian-Discord> <c​lever> so i can take an original pi4 from the early days, and then add usb-boot to it

00:55 <Armbian-Discord> <M​icroLinux (Salva)> I wonder how usb boot was done on pi 3 without it

00:55 <Armbian-Discord> <c​lever> there is usb-host code, in the bloody mask rom 😛

00:56 <Armbian-Discord> <c​lever> and when bugs are found, its a ROM, you cant fix them!

00:56 <Armbian-Discord> <c​lever> make a new set of masks, and bake the fix into the next batch of chips your producing at the factory

00:56 <Armbian-Discord> <M​icroLinux (Salva)> There was a community effort trying to make an open source firmware afaik. I mean, it should be still alive

00:57 <Armbian-Discord> <c​lever> i resurrected that project 😛

00:57 <Armbian-Discord> <c​lever> https://cdn.discordapp.com/attachments/857944478269702214/1012888529350688868/bootflow.png

00:57 <ArmbianHelper> ^ [image/png] (59.6KiB)

00:57 <Armbian-Discord> <c​lever> thats the rpi-open-firmware on the right side

00:57 <Armbian-Discord> <M​icroLinux (Salva)> Even alyssa was there at that time

00:58 <Armbian-Discord> <c​lever> rpi-open-firmware compiles down to a single bootcode.bin, when loaded by the maskrom, it brings the dram online, then loads zImage and boots linux

00:58 <Armbian-Discord> <c​lever> but it wasnt very flexible in its design, and was already tight on space

00:58 <Armbian-Discord> <M​icroLinux (Salva)> And what works and what doesnt right now?

00:58 <Armbian-Discord> <c​lever> so i ported little-kernel to the VPU, and then added features to that

00:58 <Armbian-Discord> <c​lever> which is the LK line down the middle, in the above image

00:59 <Armbian-Discord> <c​lever> with LK, i can access the 2d core fully, and i have a basic demo of the 3d core as well, so 2d/3d are fully working

00:59 <Armbian-Discord> <c​lever> and with LK, i can boot linux, and then get usb-host working under linux

00:59 <Armbian-Discord> <M​icroLinux (Salva)> Good.

00:59 <Armbian-Discord> <M​icroLinux (Salva)> What about the vpu? Will it ever work?

00:59 <Armbian-Discord> <c​lever> yes

01:00 <Armbian-Discord> <c​lever> the VPU is what is responsible for turning the arm core on

01:00 <Armbian-Discord> <c​lever> without the VPU, its just a brick!

01:00 <Armbian-Discord> <M​icroLinux (Salva)> Haha okay!

01:00 <Armbian-Discord> <M​icroLinux (Salva)> Yes, but from linux

01:00 <Armbian-Discord> <M​icroLinux (Salva)> It will work?

01:00 <Armbian-Discord> <c​lever> i dont have linux driving the 2d core yet, it fails to bring PLLH online

01:00 <Armbian-Discord> <M​icroLinux (Salva)> I mean, for decoding

01:00 <Armbian-Discord> <c​lever> h264 decoding is in the VCE, another hw block

01:00 <Armbian-Discord> <c​lever> and there is no source code for driving the VCE

01:03 <Armbian-Discord> <M​icroLinux (Salva)> Warn me if you get more stuff working, bc this should be reviewed and shown on youtube. I will not do it bc I don't make rpi content anymore, but for sure jeff or @lukefrenner will be interested

01:04 <Armbian-Discord> <c​lever> i do have a discord where ive been posting news, and there is also #armbian-broadcom on this server

01:06 <Armbian-Discord> <c​lever> where did i put that link...

01:07 <Armbian-Discord> <c​lever> https://hydra.angeldsis.com/build/113294 there it is

01:07 <ArmbianHelper> ^ Hydra - Build 113294 of job flake-test:rpi-nixos:x86_64-linux.dist_deb

01:07 <Armbian-Discord> <c​lever> the most recent thing ive done, is create a .deb package of the open firmware

01:07 <Armbian-Discord> <c​lever> if you just dpkg -i that, while having the right partition layout, it should boot

01:08 <Armbian-Discord> <c​lever> @MicroLinux (Salva) https://gist.github.com/cleverca22/e218d16c5438bb8e6e7f4b48f0546e23 and here is an example of building a complete debian image and installing that firmware

01:08 <ArmbianHelper> ^ gist:e218d16c5438bb8e6e7f4b48f0546e23 · GitHub

01:08 <Armbian-Discord> <c​lever> i assume that can easily be translated into armbian

01:09 <Armbian-Discord> <M​icroLinux (Salva)> Such a nice effort

02:33 <Armbian-Discord> <M​anoftheSea> ISP? In series chip programmer?

02:35 <Armbian-Discord> <c​lever> image sensor pipeline

02:35 <Armbian-Discord> <M​anoftheSea> Okay

02:35 <Armbian-Discord> <c​lever> it deals with automatic whitebalance, lens shading, debayer, and more

02:37 <Armbian-Discord> <c​lever> @ManoftheSea https://datasheets.raspberrypi.com/camera/raspberry-pi-camera-guide.pdf page 40

02:37 <ArmbianHelper> ^ [application/pdf] (3.9MiB)

02:38 <Armbian-Discord> <c​lever> https://cdn.discordapp.com/attachments/857944478269702214/1012913879690514512/Screenshot_2022-08-26_23-37-57.png

02:38 <ArmbianHelper> ^ [image/png] (53.3KiB)

02:38 <Armbian-Discord> <c​lever> the ISP does every step shown in that image, taking some tuning parameters as inputs, and generating stats as outputs

02:38 <Armbian-Discord> <c​lever> libcamera then uses those stats to generate some control loops

02:38 <Armbian-Discord> <c​lever> software-only loops will change the tuning params for the ISP, so the next frame is corrected

02:39 <Armbian-Discord> <c​lever> hw interfacing loops adjust the analog gain within the camera sensor itself, but those have a slower response time

02:54 <Armbian-Discord> <c​lever> heads off to bed

10:20 <Armbian-Discord> <M​anoftheSea> thanks

11:19 <aasami> For those with too much money: Try emmc. 16G is enough, enlarge swap, it's really fast