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

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

[Danny Milosavljevic]

* gnu/bootloader/u-boot.scm (u-boot-cubieboard2-bootloader): New
exported variable.
* gnu/packages/bootloaders.scm (u-boot-cubieboard2): New exported
variable.
* gnu/system/install.scm (cubieboard2-installation-os): New exported
variable.
---
 gnu/bootloader/u-boot.scm    | 6 ++++++
 gnu/packages/bootloaders.scm | 3 +++
 gnu/system/install.scm       | 6 ++++++
 3 files changed, 15 insertions(+)

diff --git a/gnu/bootloader/u-boot.scm b/gnu/bootloader/u-boot.scm
index 21d0aecce..c88dba10f 100644
--- a/gnu/bootloader/u-boot.scm
+++ b/gnu/bootloader/u-boot.scm
@@ -33,6 +33,7 @@
             u-boot-a20-olinuxino-micro-bootloader
             u-boot-banana-pi-m2-ultra-bootloader
             u-boot-beaglebone-black-bootloader
+            u-boot-cubieboard2-bootloader
             u-boot-nintendo-nes-classic-edition-bootloader))
 
 (define install-u-boot
@@ -106,6 +107,11 @@
    (inherit u-boot-allwinner-bootloader)
    (package u-boot-a20-olinuxino-micro)))
 
+(define u-boot-cubieboard2-bootloader
+  (bootloader
+   (inherit u-boot-allwinner-bootloader)
+   (package u-boot-cubieboard2)))
+
 (define u-boot-banana-pi-m2-ultra-bootloader
   (bootloader
    (inherit u-boot-allwinner-bootloader)
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 498b807ce..4a800e87e 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -439,6 +439,9 @@ also initializes the boards (RAM etc).")
 (define-public u-boot-a20-olinuxino-micro
   (make-u-boot-package "A20-OLinuXino_MICRO" "arm-linux-gnueabihf"))
 
+(define-public u-boot-cubieboard2
+  (make-u-boot-package "Cubieboard2" "arm-linux-gnueabihf"))
+
 (define-public u-boot-nintendo-nes-classic-edition
   (make-u-boot-package "Nintendo_NES_Classic_Edition" "arm-linux-gnueabihf"))
 
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index e4b2e8237..87ab57c48 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -49,6 +49,7 @@
             a20-olinuxino-micro-installation-os
             banana-pi-m2-ultra-installation-os
             beaglebone-black-installation-os
+            cubieboard2-installation-os
             nintendo-nes-classic-edition-installation-os))
 
 ;;; Commentary:
@@ -437,6 +438,11 @@ The bootloader BOOTLOADER is installed to BOOTLOADER-TARGET."
                             "/dev/mmcblk1" ; eMMC storage
                             "ttyS0"))
 
+(define cubieboard2-installation-os
+  (embedded-installation-os u-boot-cubieboard2-bootloader
+                            "/dev/mmcblk0" ; SD card storage
+                            "ttyS0"))
+
 (define nintendo-nes-classic-edition-installation-os
   (embedded-installation-os u-boot-nintendo-nes-classic-edition-bootloader
                             "/dev/mmcblk0" ; SD card (solder it yourself)

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

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> * gnu/bootloader/u-boot.scm (u-boot-cubieboard2-bootloader): New
> exported variable.
> * gnu/packages/bootloaders.scm (u-boot-cubieboard2): New exported
> variable.
> * gnu/system/install.scm (cubieboard2-installation-os): New exported
> variable.

[...]

> +(define u-boot-cubieboard2-bootloader
> +  (bootloader
> +   (inherit u-boot-allwinner-bootloader)
> +   (package u-boot-cubieboard2)))

[...]

> +(define-public u-boot-cubieboard2
> +  (make-u-boot-package "Cubieboard2" "arm-linux-gnueabihf"))

Could you add a few words and a link to a page that describes this
board?

I’m afraid of having a large collection of boards listed there that few
people will even know about.  :-)  Also, were you able to successfully
run GuixSD on this board?

> +(define cubieboard2-installation-os
> +  (embedded-installation-os u-boot-cubieboard2-bootloader
> +                            "/dev/mmcblk0" ; SD card storage
> +                            "ttyS0"))
> +
>  (define nintendo-nes-classic-edition-installation-os
>    (embedded-installation-os u-boot-nintendo-nes-classic-edition-bootloader
>                              "/dev/mmcblk0" ; SD card (solder it yourself)

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.

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?

Ludo’.

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

[Danny Milosavljevic]

Hi Ludo,

On Fri, 09 Feb 2018 14:55:35 +0100
ludo@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.

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

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> 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...

Right, neat.  (You should email the list about that EOMA68 thing
BTW. :-))

> 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.

Dunno!  Can you find the job in the Hydra Web UI?

>> 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.

OK.

>> 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.

Yes, that’s what I had in mind.

> It still wouldn't use the substitute for the flash-image then, right?

That would be a different derivation, so the image itself would still
need to be built.  However, all its dependencies would already be
available as substitutes.

Thanks,
Ludo’.