GNU bug report logs - #31416
[PATCH 0/4] Generalize bootloader installer selection.

Previous Next

Package: guix-patches;

Reported by: Danny Milosavljevic <dannym <at> scratchpost.org>

Date: Fri, 11 May 2018 14:36:01 UTC

Severity: normal

Tags: patch

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 31416 <at> debbugs.gnu.org
Subject: [bug#31416] [PATCH 3/4] bootloader: Add make-u-boot-bootloader.
Date: Mon, 14 May 2018 18:29:53 +0200
Ji Ludo,

> Or do you think enumerating the SoCs would still be too painful?  

No, I think that would be a good idea.

I'm not 100% sure that the SOC's ROM loads the bootloader always in the same
way - but all SOCs I have ever seen so far do that (it also makes sense -
the factory probably has chip test rigs and they don't want to
update those every time a new chip revision comes out).

(sometimes this can even be generalized to the vendor instead of the soc,
though not always)

If it does happen that there's a config resistor or something, we can cross
that bridge when we come to it.

So yeah, let's have a table of installers, using the soc as a key (for now?).

Still to do: bikeshedding the name :)

What about

(define-record <installer>
   soc installation-procedure
...)

(I think <soc> as record name would be weird, no?)

Or just a hash table soc -> installation-procedure ?

How does the instantiation of the table data look?  Just toplevel statements?  I've caused problems with those before :)

Where do we put it? gnu/bootloader/u-boot.scm ?




This bug report was last modified 1 year and 324 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.