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