GNU bug report logs - #30371
[PATCH] system: Add Cubieboard2.

Previous Next

Full log

Message #11 received at 30371 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 30371 <at> debbugs.gnu.org
Subject: Re: [bug#30371] [PATCH] system: Add Cubieboard2.
Date: Fri, 9 Feb 2018 17:05:17 +0100

Hi Ludo,

On Fri, 09 Feb 2018 14:55:35 +0100
ludo <at> gnu.org (Ludovic Courtès) wrote:
> Could you add a few words and a link to a page that describes this
> board?

Hmm, sure.

> I’m afraid of having a large collection of boards listed there that 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 (supposedly)
built?  Doesn't seem to be picked up as substitute for me.

> I’m also unsure we need to have one variable for each possible board.
> 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 in 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.
> 
> 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 useful.

Previous Next

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