Resurrecting an old thread since I've finally gotten some time I can spend on this.
It looks like Kurva's merge requests haven't been merged yet. I'm wondering if there's anything further that needs done (besides reminding the right people) to get those merged? If there is, or even if there isn't, I'd be happy to help with that. As for changes to raspi-firmware, I looked at the code again just now and don't really see why I thought disabling the regeneration of config.txt was a good idea... maybe instead it would be acceptable to expand the configuration options available in /etc/default/raspi-firmware, and add a configuration directory (i.e. /etc/default/raspi-firmware.d) for users to add custom configuration without risking conffile conflicts? Then it would be possible for an upstream like Kicksecure to simply ship a file that says "boot U-Boot with these options, skip copying the kernel", and then raspi-firmware could rebuild config.txt with the desired options. This would also allow users to change those options freely without conflicting with us. I'd also be interested in helping with getting the daily image builds working again. Right now I'm using grml-debootstrap with a patch I wrote (and filed a PR for, it's currently awaiting review, see [1]) to create Debian RPi installations. It works, but having the images back would be nice. I'm also still interested in implementing [2] if there aren't any blockers there, though I expect getting the images building again first will be a blocker or at least a higher priority. -- Aaron On Mon, 28 Jul 2025 17:17:16 -0500 Aaron Rainbolt <[email protected]> wrote: > On Mon, 28 Jul 2025 11:13:13 -0600 > Gunnar Wolf <[email protected]> wrote: > > > Hello Aaron, > > > > Aaron Rainbolt dijo [Thu, Jun 12, 2025 at 02:31:02PM -0500]: > > >Some time ago, I did a lot of work on getting a U-Boot + > > >grub-efi-arm64 boot flow to work on the Raspberry Pi 4 with Debian. > > >I was able to get a proof-of-concept implementation to work > > >correctly, and was interested in upstreaming my work to Debian if > > >it was welcome. To that end, I attempted to reach the team taking > > >care of Raspberry Pi support maintenance in Debian in a few > > >different ways. [1] [2] [3] [4] So far I haven't gotten much of a > > >response on any platform. > > > (...) > > > > I'm sorry for not having replied in all of this time; I would be the > > person that took charge of building the RPi images and getting them > > to support all of the (then-)available platforms. In my defense, > > FWIW, I asked the community⢠at large for help adopting it close to > > two years ago: > > > > > > https://gwolf.org/2023/08/interested-in-adopting-the-rpi-images-for-debian.html > > > > I am sure I also offered it in several Debian-hosted places, but > > this is the one I found first. > > > > >Obviously, I would like to see this feature in upstream Debian at > > >some point, which is why I did the work to see if it could be > > >done. > > > > The good news is... We have good news! đ I am Cc:ing this mail to > > Kurva Prashanth, our GSoC contributor who is working in getting the > > RPi images generation back in shape. And the good news is that he > > has already implemented the bits you need, using flash-kernel and > > u-boot. > > Nice, that sounds awesome! > > > And, thanks to the work Andrew Cater and Steve McIntyre have been > > doing and that we took time to iron out together, I have a clear > > view of what do we need to do to get the images building again in a > > reliable fashion soonâ˘. > > > > Of course... What does "soonâ˘" mean? I would like to tie it to the > > GSoC project duration, so that would be in the next couple of > > months. Naturally, if you want to work closer together with > > Kurva... it's a net win for us all! > > I'm not entirely sure my job can allocate my time to that, but I can > ask. Thanks for offering to let me help! > > -- > Aaron > > > Please note I'm answering to this first mail (I had mostly not read > > debian-devel since mid-June as I was preparing many things for our > > trip to DebConf); I am aware several people have answered, and will > > be reading up on their answers as well shortly.
pgpKV1ttP3Ahj.pgp
Description: OpenPGP digital signature
