On Wednesday, 30 August 2023 16:35:46 CEST Vagrant Cascadian wrote: > > You can add me as tester for Quartz64 Model A + B, but I don't have a > > SoQuartz (or a base/carrier board). > > Ok, if we ever get there... but I would not want to enable new boards > that nobody has ever offered to test.
I can probably get one or more people to test, but I doubt I can get them listed as 'official testers'. > >> > https://source.denx.de/u-boot/u-boot/-/tree/master/board/pine64/quartz6 > >> > 4_rk3566 > >> > > >> > Hereby the request to package them for Debian. > > This is going to require quite a bit of work: > > * package "rkbin" in non-free-firmware, if the license permits > > * get appropriate rk35xx builds for TF-A (a.k.a. arm-trusted-firmware) > merged upstream, and then uploaded to the debian package (can possibly > cheat and instead only use the bl31.elf from rkbin). > > * figure out the complicated dance between packages in "contrib" > depending on packages in "non-free-firmware" and not polluting > packages built from the same source in "main" AFAIK, which isn't much in this case, it should be the same/similar to rk3328/ rk3399? They also use a file similar to `rk3568_ddr_1056MHz_v1.18.bin`, but then ofc tailored for their platform. I'll ask the upstream maintainer/reviewer; this bug is probably not the place to document my learning experiences ;) > > In some build instructions for u-boot that I've seen there was a reference > > to an `bl31.elf` file from https://github.com/rockchip-linux/rkbin but I > > guess that's what TF-A would provide (too), but then built from source? > > Yes. Ok, thanks. > > I also recall seeing references to a `rk3568_ddr_1056MHz_v1.18.bin` file > > from https://github.com/rockchip-linux/rkbin/tree/master/bin/rk35. AFAIK > > that's only available as a BLOB? Is that file needed? And is it a problem > > if that's only available as a BLOB? > > If upstream u-boot requires that to work it is... more complicated. > > Looks like it does probably require it, based on the trustedfirmware > thread you linked to above. As mentioned above, AFAIK it's no different from rk3328/rk3399, but I'll ask. > Someone had briefly explored doing something similar for imx8* > platforms, and it was a maze of complications... though the imx8* blobs > turned out to not even be suitible for non-free-firmware, in the end, so > it stalled out. > > Because of all these complications, I have so far tried to stick to > platforms which are strictly suitable for debian "main", although > technically the requirements are a bit looser than they used to > be... but I have little experience with or enthusiasm for the > complexities such a setup would bring for the u-boot and > arm-trusted-firmware packaging in Debian. Let's for now assume that what I said was inaccurate. Trying to make it work, assuming it's similar to rk3328, is going to be a challenge enough. If it'll require some 'hustling' between main/contrib/non- free/non-free-firmware, I'll probably bail out. Cheers, Diederik
signature.asc
Description: This is a digitally signed message part.
