[Top][All Lists]

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

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

From: Ludovic Courtès
Subject: [bug#30371] [PATCH] system: Add Cubieboard2.
Date: Fri, 09 Feb 2018 17:42:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Danny Milosavljevic <address@hidden> 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.


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


reply via email to

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