From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ekBBd-0005Z6-Pn for guix-patches@gnu.org; Fri, 09 Feb 2018 11:06:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ekBBa-0000LP-Le for guix-patches@gnu.org; Fri, 09 Feb 2018 11:06:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:55949) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ekBBa-0000L7-Hr for guix-patches@gnu.org; Fri, 09 Feb 2018 11:06:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ekBBa-0007od-7P for guix-patches@gnu.org; Fri, 09 Feb 2018 11:06:02 -0500 Subject: [bug#30371] [PATCH] system: Add Cubieboard2. Resent-Message-ID: Date: Fri, 9 Feb 2018 17:05:17 +0100 From: Danny Milosavljevic Message-ID: <20180209163611.5257192d@scratchpost.org> In-Reply-To: <878tc21d48.fsf@gnu.org> References: <20180206175842.25819-1-dannym@scratchpost.org> <878tc21d48.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: 30371@debbugs.gnu.org Hi Ludo, On Fri, 09 Feb 2018 14:55:35 +0100 ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > Could you add a few words and a link to a page that describes this > board? Hmm, sure. > I=E2=80=99m afraid of having a large collection of boards listed there th= at few > people will even know about. :-) True > Also, were you able to successfully > run GuixSD on this board? Not yet. I actually want to use it for Luke's EOMA68 board. He documented that for mainline it should be booted using Cubieboard2's u-boot bootloader config. I'm still not done ruling out possible shorts on the board. It's still a prototype and I'd rather not fry it on the first power-up attempt... Can I somehow get a hold of the generic ARM 'flash-image that Hydra (suppos= edly) built? Doesn't seem to be picked up as substitute for me. > I=E2=80=99m also unsure we need to have one variable for each possible bo= ard. > We are not going to distribute installation images for each of these > boards anyway. Yeah, once (1) the agetty patch is in (2) we have an initrd-"copy modules IF they are there" functionality (3) we have glibc spawni that's not broken we can have a generic [ARM] installation-os and the user can just boot it i= n qemu. Or the user can even dd the bootloader into the image file from the outside. I'd also like to remove all these funny-installation-os blocks again eventually. > Perhaps it makes sense to have them *if* they are discoverable or listed > in the manual, *and* we provide instructions for people to build their > own installation image for these boards. >=20 > Thoughts? We could have a procedure: (define (os-with-u-boot os board bootloader-target triplet) "Given OS, amends it with the u-boot bootloader for BOARD, installed to BOOTLOADER-TARGET, compiled for TRIPLET." (operating-system (inherit os) (bootloader (bootloader-configuration (bootloader (bootloader (inherit u-boot-bootloader) (package (make-u-boot-package board triplet))= )) (target bootloader-target))))) and document that the user is supposed to "-e" that. It still wouldn't use the substitute for the flash-image then, right? I have to think about it some more. While I don't like mutating image files much, in this case it might be usef= ul.