guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#30371] [PATCH] system: Add Cubieboard2.


From: Danny Milosavljevic
Subject: [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
address@hidden (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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]