On 2023-08-31, Christopher Obbard wrote: > Let me rephrase myself. My suggestion is to ship in u-boot-rockchip U-Boot > for these devices > *without* any closed bits and ship rkbin in non-free-firmware in > non-free-firmware. > > We need to simply combine those into an image file to flash to the device, > that could be done > in flash-kernel (or as my original suggestion in a script in the image > building process but I am > not fussy). > > So that script would "just" combine rkbin and the "open" parts of > u-boot-rockchip into idbloader.img and u-boot.itb. > And once the DDR init and AT-F bits are merged into mainline, we can remove > those bits from flash-kernel > and u-boot-rockchip package can be extended to use the mainline code. > > @Vagrant, does that sound like a solution which you'd be interested in? I > could > try to carve out some time to post a patch for u-boot, flash-kernel and > package rkbin if so ;-).
That is definitely one approach, although we would need a u-boot-rockchip-something variant that goes to "contrib" instead of "main". Packages in "main" need to be functional without anything outside of "main", and obviously missing the rkbin bits would be of limited use. :) There is at least one existing u-boot variant that need to move to contrib for this very reason... Another option would be to ship a u-boot-source.deb, which contains the upstream sources, much like the linux-source package. Then you can maybe ship u-boot-contrib and/or u-boot-non-free-firmware that builds the source and can depend on rkbin. I was so glad rk3328 and rk3399 and earlier rk3288 did not have these sorts of issues, and was sad to see new ones for rk35xx ... jo...@debian.org and I (mostly josch) hashed out some similar ideas for an imx8* platform with similar issues (although the licensing ended up being even worse than for rkbin such that it could not even go to "non-free-firmware"): https://salsa.debian.org/debian/u-boot/-/merge_requests/29 live well, vagrant
signature.asc
Description: PGP signature
