From debbugs-submit-bounces@debbugs.gnu.org Mon May 14 12:30:00 2018 Received: (at 31416) by debbugs.gnu.org; 14 May 2018 16:30:00 +0000 Received: from localhost ([127.0.0.1]:34593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fIGMJ-0008D6-Ry for submit@debbugs.gnu.org; Mon, 14 May 2018 12:30:00 -0400 Received: from dd26836.kasserver.com ([85.13.145.193]:51332) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fIGMG-0008Cp-Mw for 31416@debbugs.gnu.org; Mon, 14 May 2018 12:29:58 -0400 Received: from localhost (178.113.244.9.wireless.dyn.drei.com [178.113.244.9]) by dd26836.kasserver.com (Postfix) with ESMTPSA id EAE043360252; Mon, 14 May 2018 18:29:54 +0200 (CEST) Date: Mon, 14 May 2018 18:29:53 +0200 From: Danny Milosavljevic To: ludo@gnu.org (Ludovic =?ISO-8859-1?Q?Court=E8s?=) Subject: Re: [bug#31416] [PATCH 3/4] bootloader: Add make-u-boot-bootloader. Message-ID: <20180514182953.3d4c4f3c@scratchpost.org> In-Reply-To: <87in7qbppv.fsf@gnu.org> References: <20180511143515.23435-1-dannym@scratchpost.org> <20180511143652.26935-1-dannym@scratchpost.org> <20180511143652.26935-3-dannym@scratchpost.org> <87603rnbi5.fsf@gnu.org> <20180513125925.66a91367@scratchpost.org> <87in7qbppv.fsf@gnu.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 31416 Cc: 31416@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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 soc installation-procedure ...) (I think 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 ?