u-boot and GRUB on ARM

[Denis 'GNUtoo' Carikli]

Hi,

I've a patch to add a new ARM computer to Guix (attached), but when I
add this to the system definition (to generate an image):
>   (bootloader (bootloader-configuration
>(bootloader u-boot-rock-4c-plus-rk3399-bootloader)
>(targets '("/dev/mmcblk0"

I then get an image that boots on GRUB and then GRUB doesn't find its
grub.cfg.

Is this behavior intended or is that a consequence of u-boot
having introduced the new bootflow way of booting?

If it's intended, how do I fix my configuration?

Also what would be the ideal way of dealing with that? Do we intend to
support both syslinux and GRUB? 

On another computer (rockpro64) I also had an issue with GRUB not
loading due to block size mismatch (I didn't investigate it yet in
depth), so it might be worth to also keep syslinux for strange cases
like that.

Note that on the rock-4c-plus, I can boot Guix but it requires messing
with u-boot by doing the following:
(1) I need to interrupt the boot in u-boot.
(2) I then need to run 'bootflow scan' and wait enough to populate the
list of ways it can boot. During the scan it also tries to see if it
can boot from the network and that is super long but it can also be
interrupted manually as this is the last option. At the end, the
'bootflow list' can then list the available boot options.
(3) I then need to run 'bootflow select 2' to use syslinux and then
   'bootflow boot'.

I've not investigated yet how to always select 2 beside adding some
bootcmd in the environment, but that would also require to run
'bootflow scan' and u-boot should be managed by the guix
system configuration anyway.

Denis.
From d11c723f7e19788e15464f11012c7cc366217504 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Denis 'GNUtoo' Carikli 
Date: Fri, 21 Mar 2025 00:48:58 +0100
Subject: [PATCH] system: Add u-boot-rock-4c-plus-rk3399.

* gnu/packages/bootloaders.scm (u-boot-rock-4c-plus-rk3399): New variable.
* gnu/bootloader/u-boot.scm (u-boot-rock-4c-plus-rk3399-bootloader):
  New exported variable.
* gnu/system/install.scm (rock-4c-plus-installation-os):
  New exported variable.

Change-Id: I37025b248178311ccf8246cb0e02ed9399f9c6ac
Signed-off-by: Denis 'GNUtoo' Carikli 
---
 gnu/bootloader/u-boot.scm|  6 ++
 gnu/packages/bootloaders.scm | 10 ++
 gnu/system/install.scm   |  5 +
 3 files changed, 21 insertions(+)

diff --git a/gnu/bootloader/u-boot.scm b/gnu/bootloader/u-boot.scm
index 64fb319f50..0e7eb95ba4 100644
--- a/gnu/bootloader/u-boot.scm
+++ b/gnu/bootloader/u-boot.scm
@@ -47,6 +47,7 @@ (define-module (gnu bootloader u-boot)
 u-boot-pinebook-bootloader
 u-boot-pinebook-pro-rk3399-bootloader
 u-boot-puma-rk3399-bootloader
+u-boot-rock-4c-plus-rk3399-bootloader
 u-boot-rock64-rk3328-bootloader
 u-boot-rockpro64-rk3399-bootloader
 u-boot-sifive-unmatched-bootloader
@@ -252,6 +253,11 @@ (define u-boot-puma-rk3399-bootloader
(package u-boot-puma-rk3399)
(disk-image-installer install-puma-rk3399-u-boot)))
 
+(define u-boot-rock-4c-plus-rk3399-bootloader
+  (bootloader
+   (inherit u-boot-rockchip-bootloader)
+   (package u-boot-rock-4c-plus-rk3399)))
+
 (define u-boot-rock64-rk3328-bootloader
   (bootloader
(inherit u-boot-rockchip-bootloader)
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 8ece61f11c..a9f70f8bf1 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -1430,6 +1430,16 @@ (define-public u-boot-rock64-rk3328
 (define-public u-boot-firefly-rk3399
   (make-u-boot-rockchip-package "firefly" 'rk3399))
 
+(define-public u-boot-rock-4c-plus-rk3399
+  (let ((base (make-u-boot-rockchip-package
+   "rock-4c-plus" 'rk3399
+   '("CONFIG_USB=y"
+ ;; Disable SPL FIT signatures, due to GPLv2 and
+ ;; OpenSSL license incompatibilities.
+ "# CONFIG_SPL_FIT_SIGNATURE is not set"
+(package
+  (inherit base
+
 (define-public u-boot-rockpro64-rk3399
   (let ((base (make-u-boot-rockchip-package
"rockpro64" 'rk3399
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 15ea401f1c..60e0825ce3 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -662,6 +662,11 @@ (define rock64-installation-os
 "/dev/mmcblk0" ; SD card/eMMC (SD priority) storage
 "ttyS2")) ; UART2 connected on the Pi2 bus
 
+(define rock-4c-plus-installation-os
+  (embedded-installation-os u-boot-rock-4c-plus-rk3399-bootloader
+"/dev/mmcblk0" ; SD card storage
+"ttyS2")) ;; Default UART as per the Linux DTS.
+
 (define rockpro64-installation-os
   (embedded-installation-os u-boot-rockpro64-rk3399-bootloader
 "/dev/mmcblk0" ; SD card/eMMC (SD priority) storage

base-commit: f7c41ab31f5023023385500f6e

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

[Hilton Chain]

On Tue, 18 Mar 2025 15:30:30 +0800,
Hilton Chain wrote:
>
> Patch series without packages sent to #77093!

Finally added the lockfile importer to rust-team branch!  #77093 is left for
documentation and will be a merge blocker.

Re: Jumping the queue: merge r-team before python-team?

[Andreas Enge]

Hello again,

I understand the frustration at our progress in branch merging being so
slow that systems like R, for instance, are already outdated when they
are finally merged.

Am Fri, Apr 11, 2025 at 05:27:05PM +0200 schrieb Andreas Enge:
> Well, there *is* flexibility. If the r-team branch is ready and built
> out on CI, say, you can merge it now (well, it would be annoying if it
> were merged right before a different branch that is also ready and at
> the top of the queue on QA, so a bit of coordination would be needed in
> any case).

So elaborating on this:
Thanks to Chris's work described in https://issues.guix.gnu.org/75894
we expect the node team branch to be merged in the next few days, and
hopefully the python-team branch is also close to completion. In any
case, QA would pick up the next branch in line.

How about profiting from our duplicate build farms by building in
parallel r-team on berlin/CI and qt-team and tex-team on bordeaux/QA?
Ricardo, I think you have good experience with cuirass to judge whether
the r-team branch will be ready for merging. The branches look
sufficiently orthogonal in scope that whatever branch is ready first
could be merged immediately, as it is unlikely that the combined updates
of R and Qt, say, would break many packages that would not already be
broken by only one of them.

What do you think?

Andreas

Re: GCD 004 deliberation

[宋文武]

Ludovic Courtès  writes:

> Hello,
>
> 宋文武  skribis:
>
>> Hello, Below is the final version of GCD for "Set search paths without
>> program wrappers", which means now this GCD start its deliberation
>> period (14 days), so team members please reply to
>> <76...@debbugs.gnu.org> with opinions.  Thanks!
>
> I just realized we’re already past the end of the deliberation.
>
> I believe only 1 team member deliberated (Florian Pelz: support).
> This is below the quorum of 25% of team members, so I believe this GCD
> is withdrawn.
>
> Could you update the ‘status’ and ‘date’ fields accordingly in the
> repo?

Done.

>
> It is disappointing that the proposal did not get more attention; we’ll
> have to assess to what extent this is due to the process itself.
>
> However I would recommend reaching out to more people, perhaps stripping
> it down to the essentials, and hopefully it can be resubmitted later
> once there’s a broader understanding of the stakes and consequences.
>

Sure, I'll try it later..  Thank you for the feedback!

Re: Jumping the queue: merge r-team before python-team?

[Ludovic Courtès]

Andreas Enge  skribis:

> How about profiting from our duplicate build farms by building in
> parallel r-team on berlin/CI and qt-team and tex-team on bordeaux/QA?

I believe ‘r-team’ is already being built:

  https://ci.guix.gnu.org/jobset/r-team

Ludo’.

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

[Gabriel Santos]

Em 12 de abril de 2025 08:46:40 BRT, Hilton Chain  
escreveu:
>On Tue, 18 Mar 2025 15:30:30 +0800,
>Hilton Chain wrote:
>>
>> Patch series without packages sent to #77093!
>
>Finally added the lockfile importer to rust-team branch!  #77093 is left for
>documentation and will be a merge blocker.
>

Can I rebase my patches[1] now to be sent for review?



-- 
Gabriel Santos

Re: Setting procedure properties for build-system builders

[Nicolas Graves]

On 2025-04-11 18:01, Simon Tournier wrote:

> Hi Nicolas,
>
> CC: core-team
>
> As more or less discussed IRL, I think it could be nice.

BTW, I did that and my local guix fork now includes them.  Those
patches are in the second part of this patch series:

https://lists.sr.ht/~ngraves/devel/%3c20250319173238.7969-1-ngra...@ngraves.fr%3E

--
Best regards,
Nicolas Graves

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

[Hilton Chain]

On Sat, 12 Apr 2025 20:55:45 +0800,
Gabriel Santos wrote:
>
> Em 12 de abril de 2025 08:46:40 BRT, Hilton Chain  
> escreveu:
> >On Tue, 18 Mar 2025 15:30:30 +0800,
> >Hilton Chain wrote:
> >>
> >> Patch series without packages sent to #77093!
> >
> >Finally added the lockfile importer to rust-team branch!  #77093 is left for
> >documentation and will be a merge blocker.
> >
>
> Can I rebase my patches[1] now to be sent for review?

No problem!