Message ID | 87y36s1r5h.fsf@ponder |
---|---|
State | Accepted |
Headers | show |
Series | [bug#34356] gnu: u-boot-novena: Allow booting from raw device offset. | expand |
Context | Check | Description |
---|---|---|
cbaines/applying patch | fail | Apply failed |
cbaines/applying patch | fail | Apply failed |
cbaines/applying patch | fail | Apply failed |
Hi Vagrant, On Wed, 06 Feb 2019 14:35:54 -0800 Vagrant Cascadian <vagrant@debian.org> wrote: > (define-public u-boot-novena [...] > + ;; Patch configuration to disable loading u-boot.img from FAT partition, > + ;; allowing it to be installed at a device offset. Hmm, why? https://www.kosagi.com/w/index.php?title=U-boot-novena specifies that it loads u-boot.img from the first partition. Is it incorrect?
On 2019-02-10, Danny Milosavljevic wrote: > On Wed, 06 Feb 2019 14:35:54 -0800 > Vagrant Cascadian <vagrant@debian.org> wrote: >> (define-public u-boot-novena > [...] >> + ;; Patch configuration to disable loading u-boot.img from FAT partition, >> + ;; allowing it to be installed at a device offset. > > Hmm, why? > > https://www.kosagi.com/w/index.php?title=U-boot-novena specifies that it > loads u-boot.img from the first partition. Is it incorrect? It's not incorrect, per se, but this was a simple way to get the install-os functionality to work without significant refactoring. I just recenty booted and refreshed the guixsd installation on the novena I had, and was reminded that installation of the bootloader required manual intervention from the user, and could potentially result in an unbootable system of the SPL/u-boot.img were sufficiently out os sync. The more complicated way would be to make novena-installation-os and/or embedded-installation-os smart enough to drop "u-boot.img" in the correct place, on the first FAT or EXT* partition of the microSD. That is certainly currently over my head to attempt that at the moment. I think we had touched on this in the bugs where I introduced u-boot-novena in #31404. live well, vagrant
Hi Vagrant, On Sun, 10 Feb 2019 17:23:28 -0800 Vagrant Cascadian <vagrant@debian.org> wrote: > The more complicated way would be to make novena-installation-os and/or > embedded-installation-os smart enough to drop "u-boot.img" in the > correct place, on the first FAT or EXT* partition of the microSD. That > is certainly currently over my head to attempt that at the moment. > > I think we had touched on this in the bugs where I introduced > u-boot-novena in #31404. Fair enough. For something as basic as a bootloader, I guess it's better for it to be contained in one place anyway. I'm now reasonably sure that it works fine in this configuration. I've amended the description and applied your patch to guix master. (If we wanted to add the original functionality anyway, grub-efi already requires something like it and could be used as a template).
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm index 5bd784f73c..40b14fcce8 100644 --- a/gnu/packages/bootloaders.scm +++ b/gnu/packages/bootloaders.scm @@ -624,7 +624,20 @@ board-independent tools."))) (make-u-boot-package "mx6cuboxi" "arm-linux-gnueabihf")) (define-public u-boot-novena - (make-u-boot-package "novena" "arm-linux-gnueabihf")) + (let ((base (make-u-boot-package "novena" "arm-linux-gnueabihf"))) + (package + (inherit base) + (arguments + (substitute-keyword-arguments (package-arguments base) + ((#:phases phases) + `(modify-phases ,phases + (add-after 'unpack 'patch-novena-defconfig + ;; Patch configuration to disable loading u-boot.img from FAT partition, + ;; allowing it to be installed at a device offset. + (lambda _ + (substitute* "configs/novena_defconfig" + (("CONFIG_SPL_FAT_SUPPORT=y") "# CONFIG_SPL_FAT_SUPPORT is not set")) + #t))))))))) (define-public u-boot-cubieboard (make-u-boot-package "Cubieboard" "arm-linux-gnueabihf"))