[Top][All Lists]

[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)


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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]