@foone The GPU searches for the SD card, loads and parses the config.txt file, sets many of the required options, parses device tree overlays, etc. etc.
And yes, it loads kernel and initramfs into memory and then resets/enables the main ARM CPU.
A classic Broadcom move 😹 (with the GPU core being a highly proprietary VideoCore IV architecture)
@ann3nova Do you have special requirements (such as closed captioning, teletext, special timing/interlacing, etc.)? If so: The "older" Pi 3, 4, Zero 2, etc. might be a good choice. The newer Pi 5 does video a completely different way (generated in the RP1 I/O controller, connected via PCIe), which works as well, but everything is still a bit new and the really cool features/tricks aren't yet supported.
@mntmn just compiling, insmod, rmmod'ing kernel modules to do this in a loop would probably also work and be quicker than rebooting... but more work, ofc :)
@mntmn at work I have written a very violent kernel module we lovingly call "holzhammer.ko", which allows you to call functions in kernel space (like the ones to set those tuning parameters) directly, but I'm afraid I can't share that one 😆
@mntmn then that's probably related. yeah, tuning those values "blindly" can be a bit of a tricky job.In the past, I've written a script to change the value, recompile the device-tree and reboot, then test UDP packet loss in a big loop (iperf3/udp). Ideally you do this on a direct link against another NIC which can receive packets with CRC errors. If you look at the test results of that across the values, it should look somewhat like a bell curve and then you'll get an idea of the best values.
nyaa~~your friendly neighborhood infrastructure cat, late-20s, 🏳️🌈 :trans_flag: :blahaj: posts may contain old computers, networking, arm64 or ham radio, will bite :3 kitten of @Toble_Miner#searchable