From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fHonO-0006Jw-4P for guix-patches@gnu.org; Sun, 13 May 2018 07:04:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fHonL-0005Wo-12 for guix-patches@gnu.org; Sun, 13 May 2018 07:04:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:52352) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fHonK-0005We-TF for guix-patches@gnu.org; Sun, 13 May 2018 07:04:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fHonK-0001e2-Df for guix-patches@gnu.org; Sun, 13 May 2018 07:04:02 -0400 Subject: [bug#31416] [PATCH 3/4] bootloader: Add make-u-boot-bootloader. Resent-Message-ID: Date: Sun, 13 May 2018 13:03:43 +0200 From: Danny Milosavljevic Message-ID: <20180513125925.66a91367@scratchpost.org> In-Reply-To: <87603rnbi5.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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/X0O.OCNyBNFz+hRHD=I5i2w"; protocol="application/pgp-signature" 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 --Sig_/X0O.OCNyBNFz+hRHD=I5i2w Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo, > (define-record-type > (board name triplet installer) > =E2=80=A6) >=20 > Thoughts? The idea of make-u-boot-bootloader (and os-with-u-boot) was that it would f= ree us from having to play whack-a-mole regarding u-boot (except for the installation methods of which there are much fewer than boards or chip mode= ls) and also free the user from having to know anything but the board name. With your idea it would mean that we'd have to carry a huge list of = s, defining the board and architecture and installer, right? (or I guess the user would have to create it on-the-fly) That's exactly what I was trying to avoid :) I know my method isn't perfect either - I should have said "WIP" - but the = idea is that the user would just use os-with-u-boot and specify his board name -= and the rest is magically being worked out (for all boards in u-boot). I'm trying to keep to information that is available within u-boot (like .co= nfig) so we don't have to maintain the stuff ourselves. The installer was suppos= ed to read out the u-boot parts and infer the correct incantations to use by i= tself. To infer the triplet, we can search for "CONFIG_ARM64=3Dy". The SOC should be fine to infer as in this patch. No chance inferring the actual installation commands, though. Too bad... They've got all kinds of funny config entries like CONFIG_SPL_FIT_GENERATOR=3D"board/sunxi/mksunxi_fit_atf.sh" but I don't see the installation commands / info... hrmmmm... --Sig_/X0O.OCNyBNFz+hRHD=I5i2w Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlr4G48ACgkQ5xo1VCww uqUgMwf/V4cYk1sanQH+JdOeSBWxm9wmmIfBrE+yL9Tzf7LUHFeT+XvfAfz8caGr q/Zihs7SsYiCuaxqoJ/p8oYzBbuygi4NfXBcvhSj3ebBcZ/iKLxcW0mGjJvG6zyp aGdAEqq163LZlo09EMh80tonKw5lRuGo0W8k7guEeOqi4wf6kaljIPMsQwF9UqIy /HH+virEd7L4TSmAcN0rAZyehPzjfdhqiDLXCIBFgsTFyEkidUk1gE24GtHj6ZjL 12Oq5hcpZb7JIoArYgk9Ju4KRUibROhMUNg5+qtmgbqw8kkjjEQq/KGKDcRsDbLh GTZX0HQWWnBQeHxqTbDavJkA2C2Rsg== =nkRx -----END PGP SIGNATURE----- --Sig_/X0O.OCNyBNFz+hRHD=I5i2w--