Dear Loïc, Thanks for your feedback!
On Mon, May 19, 2025 at 5:37 AM Loïc Minier <loic.min...@oss.qualcomm.com> wrote: > > Hi Roger and all! > > On Mon, May 19, 2025 at 12:45:49AM +0300, Dmitry Baryshkov wrote: > > > * non-free: > > > - Software that runs on the host must go here > > > - Firmware that runs on peripheral devices can go here, but should > > > not because most Debian systems do not have this archive section > > > enabled > > > > I've added Loïc, he has been looking at providing Debian images for those > > boards. He might have suggestions regarding packages he might need for that > > (or he might have some WiP with boot files). > > > > But as have had this question beforehand, I see a little value in packaging > > BSP files (at least at this point). If you want to improve Debian support on > > those boards, I'd really suggest looking at D-I or at sorting out dtb vs > > bootloader situation (Christopher and I did a presentation at FOSDEM this > > year). > > Indeeed, I've literally discussed the same idea as what's proposed in > this ITP with others in my team, but ended up deferring it :-) > > To echo what Ben and Dmitry wrote on boot firmware vs linux-firmware: > - whenever possible, it's nicer to load firmware for peripherals when > Linux is up, and then it should come through > kernel-firmware/linux-firmware > - in some cases, the firmware is running on peripherals but is loaded > before Linux even starts; this is either due to architectural > decisions/constraints, or signatures > - for the Qualcomm IoT boards (which are originally Android designs), a > few of these firmware have already been moved from boot firmware to > linux firmware and have been contributed to kernel-firmware upstream; > what we're seeing here is the remainder which can't be moved, at least > in the short-term I agree it's better to upstream everything to linux-firmware, if cannot upstream to linux, probably due to non-free license. But the reality is there're always some blobs are required, but not accepted by linux-firmware, yet. > I'm guessing Roger is proposing this new source package as to be able to > provide directly flashable images of Debian for these platforms – Roger, if > you > could share your high-level goals to confirm, that would be helpful to > prioritize our options! Yes, my ultimate goal is to make a official D-I image for those QCOM IoT boards. That means those boards can be supported by Debian officially. > I've started working on Debian images for Qualcomm IoT platforms earlier this > year. This is where I'm keeping the debos recipes: > https://github.com/qualcomm-linux/qcom-deb-images > (I should mention Linaro has been building self-standing Debian-based > flashable > images ("rescue" images) for these platforms semi-regularly, and Mobian > also seems to have some similar debos recipes!) > > The (currently slightly kludgy) boot firmware handling is here: > https://github.com/qualcomm-linux/qcom-deb-images/blob/main/debos-recipes/qualcomm-linux-debian-flash.yaml#L85 > > The main thing I want to underline is that the input for images for the > RB3 Gen2 boards are general purpose boot binaries for the QCM6490 > platform and the board-specific CDT. Thanks for the links! I'll book at it. I guess it's a good start to mirage some code to D-I. > IMHO, since these are UEFI (+ DT) capable platforms, Debian should focus > on providing great support for UEFI images. I don't know if Debian > should also ambition to package/host/build/distribute the mostly > non-free boot firmware files, I can see how it would allow delivering > rescue images or self-standing Debian images with boot firmware + OS, > but another option is to leave the boot firmware to be distributed by > Linaro/Qualcomm and focus the Debian efforts on the OS images. Those QCOM board should be able to bootstrap by Debian images. For example if you get a Intel based PC from the neighbor, you should be able to install / run Debian on it. The same thing should apply to QCOM board as well. > For QCM6490 specifically, I found that many things just worked with a > plain Debian image. A few patches were already merged in trixie, some > immediate gaps that we could focus on: > 1) we don't have pre-installed UEFI images - only installer images - and > it's not trivial to convince these platforms to boot to an installer > on USB/SD / over the network; it would be great to have UFS-friendly > (4k sector size) pre-installed Debian images that could be flashed > with qdl on UFS LUN0 Can you kindly share what's working for QCM6490 (RB3 Gen2?) from Debian perspective? I'd love to try. > 2) 6.12 doesn't work well on 6490, a few critical bug fixes went into > 6.13 and 6.14; but recent kernels work great, so using linux from > backports would be a good experience; perhaps we can identify select > bug fixes to make 6.12 a least boot to upgrade to a new kernel If any patch is upstreamed, we can backport to sid, based on wiki: * https://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines So if you have the list of patches necessary for QCM6490, please let me know. > 3) we need a mechanism to provide updated device trees from time to time > on these platforms; systemd-boot lets one configure a per-board > device tree override, or u-boot-efi-dtb will copy the DTBs to the > ESP, but we probably want something friendlier out of the box > (flash-kernel entries? GRUB default config as done in the Ubuntu > images?) I'm not sure it's one time work, or need to maintain from time to time. Are you suggesting to create a QCOM enablement team in Debian, if it's the latter case? Cheers, Roger
