From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fIGMN-0001pr-Lk for guix-patches@gnu.org; Mon, 14 May 2018 12:30:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fIGMM-0007hd-R3 for guix-patches@gnu.org; Mon, 14 May 2018 12:30:03 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:54929) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fIGMM-0007hE-Fx for guix-patches@gnu.org; Mon, 14 May 2018 12:30:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fIGMM-0008Dq-6c for guix-patches@gnu.org; Mon, 14 May 2018 12:30:02 -0400 Subject: [bug#31416] [PATCH 3/4] bootloader: Add make-u-boot-bootloader. Resent-Message-ID: Date: Mon, 14 May 2018 18:29:53 +0200 From: Danny Milosavljevic 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 31416@debbugs.gnu.org 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 ?