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

Previous Next

Full log

View this message in rfc822 format

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

Danny Milosavljevic <dannym <at> 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’.

Previous Next

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