[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#27327] [PATCH] bootloader: Add u-boot.
From: |
Ludovic Courtès |
Subject: |
[bug#27327] [PATCH] bootloader: Add u-boot. |
Date: |
Fri, 16 Jun 2017 14:37:00 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Hello,
Danny Milosavljevic <address@hidden> skribis:
> On Fri, 16 Jun 2017 10:40:39 +0200
> address@hidden (Ludovic Courtès) wrote:
>
>> > + (package #f)
>> > + (installer #f)))
>>
>> I still find it weird to use #f for these two fields.
>>
>> I would find it more reasonable to have, say, a ‘make-u-boot-bootloader’
>> that returns a <bootloader> with all the fields appropriately set (not
>> #f). Otherwise it sounds like we’re going to have to deal with support
>> requests #about “wrong type to apply: #f”, and I’d like to avoid that.
>> :-)
>
> Yeah, but I think Mathieu added explicit support for leaving those #f.
>
>> Can’t we just say that ‘package’ is always a <package>
>
> Difficult. U-Boot is more like a BIOS is on PCs. That means in normal
> operation you'd not flash it. If there was a mistake in the flashed U-Boot
> often you can't fix it again without electronics knowledge and gear (if at
> all - serial pads must be available on the board). There's no extra BIOS.
> U-Boot does it all: RAM initialization, keyboard initialization, display
> initialization etcetc.
>
> Sometimes flashing is only possible via serial cable (or worse) from an
> external machine.
>
> Also, there are lots of forks of U-Boot. Since U-Boot is licensed under GPL
> the package should be available somewhere - but not necessarily in the U-Boot
> master branch (and often it's in fact not available there).
>
> In short, we should add U-Boot packages gradually, and only after testing
> each U-Boot package on the hardware.
>
> That means in the beginning we'd have a LOT of (package #f) - but that's
> still preferrable to bricking.
>
>>and that
>> ‘installer’ is always a procedure?
>
> Yeah, the installation procedure could probably check (if package (invoke
> "...")).
Yeah, I think so.
I mean, you could run “guix system reconfigure --no-bootloader” or, if
you want to be sure you don’t flash your device inadvertently, you could
use ‘u-boot-noop-bootloader’ or similar, which is like
‘u-boot-bootloader’ except that it never installs anything beyond its
config file.
> I've submitted this minimal patch mostly to make clear how U-Boot would
> extend extlinux. I think it's good to have it in place as a guard against
> too-much-syslinux-bias :)
Yup, makes sense!
> That said, it should actually make GuixSD boot on a machine with U-Boot
> already installed.
That’s pretty cool. Looking forward to GuixSD on ARM!
Ludo’.