Hi there,

On Thu, May 22, 2025 at 01:39:04AM -0700, Roger Shimizu wrote:
> 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.

Cool, probably something we can share efforts on!

> 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.

Yup, that makes sense; I guess when you get a PC, you don't flash the
BIOS on it though, but another possible analogy is with Raspberry Pis
and we have rpi-firmware in the archive.

> > 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.

I've only done basic testing so far, but I could get a pretty decent
Xfce experience: RB3 Gen2 boots in UEFI mode, WiFi works, GPU works with
Freedreno, I've got display output on type-C port, USB devices work on
type-C port...

With a small number of patches from linux-arm-msm@ and an external
firmware from Renesas, it's possible to get the type-A USB ports and the
USB-attached Ethernet to work. With a small number of patches from
linux-arm-msm@, it's possible get raw camera sensor data with libcamera.

> > 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.

I don't have a list for 6.12; I believe there will be support in a 6.12
based Qualcomm tree, but the patchset will likely be massive and the
QCM6490 patches wont be isolated.

> > 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?

Let's unite! :-) I think a lot of people in Cc: are contributing
improvements to Qualcomm hardware enablement in Debian already.

I would also like to host a BoF at DebConf, do you plan to attend by
any chance?

Once thing I wanted to follow up on from your original ITP: you mention
a code.linaro.org link with an Ubuntu flavor of the boot firmware. I've
compared it with the general purpose one that Qualcomm releases, and I
saw no specific improvement.


Once thing I wanted to follow up on from your original ITP: you mention
a code.linaro.org link with an Ubuntu flavor of the boot firmware. I've
compared it with the general purpose one that Qualcomm releases, and I
saw no specific improvement.

This is the boot firmware I'm using in the qcom-deb-images repository:
https://softwarecenter.qualcomm.com/download/software/chip/qualcomm_linux-spf-1-0/qualcomm-linux-spf-1-0_test_device_public/r1.0_00075.0/qcm6490-le-1-0/common/build/ufs/bin/QCM6490_bootbinaries.zip

I've diffed the files in the tarball in tarball present in the link from
your original ITP bug:
% diff 
QLI.1.4-Ver.1.1-ubuntu-nhlos-bins/QLI.1.4-Ver.1.1-ubuntu-nhlos-bins.tar_/SHA256SUMS
 QCM6490_bootbinaries/SHA256SUMS
4,16d3
< 5f985b6ea0fef53f5b91a9339d2b7f48b51d1f944adf348b7b8c56954e129020  dtb.bin
< 35b19d59a23b14bcaa21bfced362e167cbd5ef1d5329ce6d316ac2df5ffd710f  
gpt_backup0.bin
< 8800769ab85f60ecd0754eb708e1529944abe10b2ecb19bcd42c0948b0185ac3  
gpt_backup1.bin
< f02965cb017542047078546050794ab615f41159e88231c2abb08c6931829e02  
gpt_backup2.bin
< 46228da1b46d69e4763c607e39f8b870ca8944504841c68533c192f89f55a91f  
gpt_backup3.bin
< dcdf683f3b5e393c9051d557ab71e315284765299fd9515a20730767e4c202dd  
gpt_backup4.bin
< 85b86004acbf7a6c40940a34607b1890cafb151245310cc0a60b5ce4f5248454  
gpt_backup5.bin
< 1d176c506e22ac1c7cba126796a06249ce7403c0640b1461d310e46f08ac004d  
gpt_main0.bin
< dc08119c3e3c4616eb4bcac51d305c8a28cc20a6bd7ccc115d2b583b8fbc3514  
gpt_main1.bin
< 22024c443d8b4ecc65a58bc2e56c77e22a54ea910140a8e8a2804c9588f29724  
gpt_main2.bin
< 8d625a704ca2c0a35a7d33b194fdc7990730dd6ff7bece6a7cb6d9c5dea4bce4  
gpt_main3.bin
< af563e74cb3324dc29c616b07272f80adb58f3b5911e2122fb77ef95f16b303c  
gpt_main4.bin
< 1daedcf0dbf00157388d2ba526c1679501d319f06e624a9a8b8abdda1f3b0379  
gpt_main5.bin
20,25c7,8
< 29c00bf4214bb212403b817e00c47568415ee249fe07e6e6756773caf6662ee4  Notice.txt
< b6269add7ddfc0bec68e1780f5b437b7c44a0d8bb266f90e678eae042d72e21b  patch1.xml
< ae392f62c30cd879c8f704bee9b08918008e6a40e5c6f0882228f2f84a8a2739  patch2.xml
< a56dae5943a13d2042b5a6eb42bb7bee3ed6370dd88ffa9ec2dd159029cdf4f4  patch3.xml
< 142db6cedc00f20f87cffb439d6e4d191b548ed6fc255d8f1bfe80431c6db09f  patch4.xml
< fc748598cb02eb8843535505b17bb2dc4aafabd7c5888a4f35587c9e156adaab  patch5.xml
---
> 184497f264cdb72f0085d852a2e49c7d85d381e6ee7e82180cd928c66709cde7  
> partition_emmc.xml
> 1237ebb5860397ef0de82634f2a4fab9eb544d2983f8e9b83e2b156d6c0e5fec  
> partition_ufs.xml
27a11
> a4ba15e9d0b73fdc14f0d5756d46d98c8ecf52a43b390093696177b8cae8b7c4  
> Qualcomm-Technologies-Inc.-Proprietary
29,34d12
< 8a7d9b5dc28c2cfb3d5547dd48720d71c8b1e6bd728c978a5e359936c95ac706  
rawprogram0.xml
< 38f201dcc71691f39e0f9379e8a7633baf5c2be8d060734826cbd63a28719d3d  
rawprogram1.xml
< 302187af6dcbf86bc48fba2859b2ea360d647d71115209d8f382a5ff190ab331  
rawprogram2.xml
< a17cad74006ea51b9f4e0eed9fd6289161697a0ca276e5ed8a47e39989834b10  
rawprogram3.xml
< 1dd0c3d6eddd41dafbe258172cc829f6c1cc6bf079361391216904940dcab5a5  
rawprogram4.xml
< d472d0cb7402d135e2e15aafc6328c37eb1ce5a7190a39698c3963961da02c6c  
rawprogram5.xml
39a18,19
> d3f5c709e2a941210f562485cb7ed20a1933cc32d502cd6a29edfaaced4b52a4  
> xbl_config_gunyah.elf
> d3f5c709e2a941210f562485cb7ed20a1933cc32d502cd6a29edfaaced4b52a4  
> xbl_config_kvm.elf
43d22
< cc61635da46b2c9974335ea37e0b5fd660a5c8a42a89b271fa7ec2ac4b8b26f6  
zeros_5sectors.bin


The gpt and *.xml files are generated. dtb.bin is a partition with
device trees for different platforms that I'm personally extracting from
the kernel deb (in the Ubuntu boot firmware it's provided). Then there
are two extra xbl flavors in the boot binaries I'm tracking, but you'll
notice that they are identical to the one in the Ubuntu boot firmware
and 3 copies of the same file.

So I'd suggest tracking the qualcomm.com released boot binaries instead,
these seem to make more sense as an upstream to me.

Best,
-- 
Loïc Minier

Reply via email to