lets start hypotetical fw dev thread

Q3, there are not many docs available. But the firmware is split in a few components based on my research in the past: Buildroot: The baseOS, provides the Rust version, Kernel etc. Is supported with custom patches to enable the Realtek switch. Supporting components: The uboot config and DTS for the Alwinner SOC BMCD: The Rust daemon and API to facilitate the frontend and sit 'in between' the BaseOS and GUI Third party components: usbboot: to flash the CM4 Rockusb :to flash rockchip based SoC's

Q1: depends what we want Q2: same Q3: from none to less, I reversed how to turn on a Node and put it into MSD mode, for now. I like to get manualla the usb-storage-gadget for RPIs working at first as a PoC. Q: I would love to see the kernel and DTB ported to OpenWRT as the curation of abondoned hardware works quite good after the initial patches are accepted and as one of the most imprtant things if the switch ASIC is getting supported, it will be high likely in OpenWRT.

IIRC, when Raspberry Pi retired their original mass-storage facility for an updated 64bit one, this broke the current BMC facility (for RPI5 only I believe – which doesn't work well at a hardware level right now in any case). Upgrading this component to the latest upstream Raspberry Pi release might be a good starter for firmware development, though?

Well dev for rpi can be done with someone who has the hw n9?. For me the starter issue is how to start, whats needed, how to flash, how to recover, debug, etc. Basicaly docs for dev to reduce the slopnes of the learning curve for people like me with different skillset.

One benefit here is that the BMC will automatically boot from micro-SD if a bootable card is present – so firmware dev is very safe with little risk of bricking anything.

the new mass-storage gadget also increases requeirements, as they 'RPIBOOT' a full kernel and small userland. So this might be something to be sideloaded onto MMC card as the NAND might get to small. I get MSD manually run with RK1 devices but still no luck with CM4/5 (see https://discord.com/channels/754950670175436841/1179360051442487427/1486177702254874654)

Q: if its possible to connect from bmc to any node via serial, its also possible to connecto from node to bmc?

"connect" via serial line is a bit strange wording. A serial line of the BMC is "connected" to a serial line of the SBC. So you can write from both sides data in. If you mean connect more in a "networkish" way, there a ways to do it. What you are imagining?

Never mind i will test it later.

@casey I have here: * a tasmota plug, which I can control PowerOn/Off via network * a small router with an embedded switch and some usb ports where I connected side-by-side to the Turing Pi2 a USB to serial dongle for emergency access to serial console and uboot, for manaually booting to NAND even if an MMC card is inserted * in the NAND is a known working config with BMCD service disabled * development happends on the MMC card inserted. If I brick the MMC install or kill the network connectivity I use the serial console to revive and for emergencies I have the Tasmota Plug (or any other sensible PDU)

thanks, i was thinkiung about similar setup, mosthly how to connect bmc serial to have backup access. Obvius solution is a cable to external machine, but one thout was how to access bmc from one of its nodes. AKA to have setup i dont need to stand up everytime i fokup something

nice, the switch driver needs to be adaped and the DTB, too. Currently in HEAD we have with latest 6.8 an issue with the DTB. https://github.com/turing-machines/BMC-Firmware/issues/249

i used this issue to test what skills i would need to learn or re-learn and uff boii its a lot. Like i never worked with kernel or kernel patches, didnt touched c/c++ in like 20 years. The newer kernel has changes in i2c code, so sams patches are failing. Maeybe better strategy would be to build clean linux with latest lts kernel and try what happens. According to this latest integration for t113 was in kernel 6.8 https://linux-sunxi.org/Linux_mainlining_effort

in 6.10 you have LDO support merged for T113, unsure if it is relevant to Tpi2

i saw that, but i have no idea if its something important or not so i stayed focused on the main matrix.