From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id UPXMKUWqcmIeGwEAbAwnHQ (envelope-from ) for ; Wed, 04 May 2022 18:31:01 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id aOITKUWqcmIdSAEAG6o9tA (envelope-from ) for ; Wed, 04 May 2022 18:31:01 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3BDB51151F for ; Wed, 4 May 2022 18:16:39 +0200 (CEST) Received: from localhost ([::1]:39518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmHg3-0003aO-0u for larch@yhetil.org; Wed, 04 May 2022 12:16:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45210) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmHeR-0003Zv-Nw for guix-devel@gnu.org; Wed, 04 May 2022 12:14:56 -0400 Received: from cascadia.aikidev.net ([2600:3c01:e000:267:0:a171:de7:c]:52816) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmHeP-0003bX-0J for guix-devel@gnu.org; Wed, 04 May 2022 12:14:55 -0400 Received: from localhost (unknown [IPv6:2600:3c01:e000:21:7:77:0:20]) (Authenticated sender: vagrant@cascadia.debian.net) by cascadia.aikidev.net (Postfix) with ESMTPSA id ADA9E1ABCA; Wed, 4 May 2022 09:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=debian.org; s=1.vagrant.user; t=1651680885; bh=zcnQVJI/L3MpJ71O6lbj/EMXmnBSpz5AA/pqAqDaYzk=; h=From:To:Subject:In-Reply-To:References:Date:From; b=AxmgZEqepEeMzjzN+2ZeJV0L5ifWafOWFAmMVz9uh1WXc1kP0j7MIYHRzzBXsE0mR wZRA4MP9jzyHYNQE6srFiQa73cnhp2h/7Vy2j3rKjpSNv6QujhGJ0vU2Z3FKXp8ChO TjNm8TtDMYyoNy9/wxwSV0s8BEewcXpxBRx4Yoixu/prRGBAhElHFqB9qeC64k5DRf VBIz9wkvC1G19cqTrRQwIDcDWmZcBIHZ/LPpI1K0kLnaTMFrOGbPAP3VqfzBP7s7Pe VTk+B3FGgGfutm18oyTWqw8FPoNL/lj5nTzKqAAnF5ImIdlGbYgu1Pf0Ve+pPqrOHG cgHH6JaEm1rSQ== From: Vagrant Cascadian To: Tom Fitzhenry , Tobias Platen , guix-devel Subject: Re: Guix System on RockPro64 In-Reply-To: <6cba8f1d-eca8-bbcd-a98f-1e6348491b0b@tom-fitzhenry.me.uk> References: <9b8600147c093bbcf99e6d085f380b72c15399b2.camel@platen-software.de> <6cba8f1d-eca8-bbcd-a98f-1e6348491b0b@tom-fitzhenry.me.uk> Date: Wed, 04 May 2022 09:14:40 -0700 Message-ID: <87r159w9zj.fsf@contorta> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: none client-ip=2600:3c01:e000:267:0:a171:de7:c; envelope-from=vagrant@debian.org; helo=cascadia.aikidev.net X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1651680999; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=wttr6S9wZhs3A7W550NwwURXV2uVybbn3yXCjWp73lU=; b=oKoKVUVmkStGLp+dE8seoM1toKGcm90E5mTudm3Rxryq/PXZ0IxcIioZNVE6YeqJgCONTr 25GKXyzH2Vx1Hoj7uJLUjk6ncc8GWhfMuH0bYEC6gacCkQ2W1ItqSwAdNxIex2j/rjNT2I ltCTKUV+XgcanZF+1eIa7PnJXztfZDFso3wKdXKeCfyDYXgPdRrtQ43T9u3qYd64rFPlaq S4L3X539aN5hzKAnd7wYx47HTnugJ63rirXZJ4j5CNrdSEEiKkuPpnkSjgK0DVWAejpuCF MtqvTgwY/J3QANViw0Ata4cTlw32ciVrDfF9nST9XrBqv8TeeQZE3J0ZHB3fmg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1651680999; a=rsa-sha256; cv=none; b=u6aicQw4DbSIekVCUhkXCcMhy9gQRgLZna4pibDxd0LlE0Za7Gb0KD++dtOWgpomQUgZvk MnOIXZkLXFiFEeHBZIeJbqW7WomM2k9bSZUm4vKNif/sRQi+49p/Yf1dwIYYYLxV8g0RcN MiGoJlVzcTbVWCOhFjL69ka2Tijs7c01Ju5YBoajuXBYREuXQBwuCeF2zat7LrYNU5AsE6 NX9AU5ki7ugf1ehauI5d4dZKSN4V+U3M9U6gfvfQq/i7rAoLIOZkjGc2YKhqywxUtVzRXQ ViC1e6nKL13RX315Gty80xxTjGHwcX2Xwk5Nnx1L/RaAuunoFO8sQBnVUHvpPw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=debian.org header.s=1.vagrant.user header.b=AxmgZEqe; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -8.08 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=debian.org header.s=1.vagrant.user header.b=AxmgZEqe; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 3BDB51151F X-Spam-Score: -8.08 X-Migadu-Scanner: scn0.migadu.com X-TUID: 9uxEypHkrCqk --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 2022-05-04, Tom Fitzhenry wrote: > On 4/5/22 04:53, Tobias Platen wrote: >> I had a look at the guix page, there is a latest version image for the >> PineBook Pro, which uses the same SoC. > The SoC is the same, but the PineBook Pro and RockPro64 have different=20 > u-boot bootloaders: u-boot-rockpro64-rk3399-bootloader and=20 > u-boot-pinebook-pro-rk3399-bootloader, both in gnu/bootloader/u-boot.scm . ... > However, it's inconvenient that each aarch64 platform needs its own=20 > aarch64 image. You could create a "generic" image that supports UEFI or standard u-boot methods, and the user can bring-their-own UEFI implementation (e.g. tianocore, recent versions of u-boot with EFI) or install u-boot or barebox or whatever manually. Another approach used by debian-installer images is to ship the image that is used by all the platforms, and then a small firmware portion that is device-specific: https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/RE= ADME.concatenateable_images It's a little more cumbersome to download two images and dump them onto the media, although I imagine guix could implement this part and make it relatively simple, while still having a shared substitute for the bulk of the image. > To improve on this, I'm working on Tow-Boot[0] support=20 > for Guix. The result is that a single generic aarch64 image will work=20 > across all Tow-Boot supported devices[1], including the RockPro64. > > 0. https://tow-boot.org/ > 1. https://tow-boot.org/devices/index.html My understanding was tow-boot was mostly, at this point, something to avoid installing as part of the distro image. You can basically do the same thing with mainline u-boot, if you install u-boot to media other than the distro media. Or does tow-boot have fancier features working yet (e.g. menu interfaces from the firmware) ? > + (initrd-modules '()) > + (kernel linux-libre-arm64-generic) I've managed to get the default linux-libre working, installed with rootfs on SATA. It does require a fairly extensive list of modules to load in the initrd: (kernel linux-libre-5.17) ;; from before it was default (initrd-modules (append = (list ;; scsi modules "ahci" "libata" "sd_mod" "scsi_common" "t10_pi" ;; regulators and clocks "rk808-regulator" "clk-rk808" "fixed" "fan53555" "rk808" "i2c-rk3x" "pl330" "dwc3" "rtc-rk808" "sdhci" "sdhci-pltfm" "dw_mmc" "dw_mmc-pltfm" ;; "dw_mmc-rockchip" "phy_rockchip_pcie" "pcie_rockchip_host" "nvme"))) I've recently noticed it taking a long time on shutdown or reboot with "dw_mmc_rockchip" still loaded, but I don't use the mmc bus for anything other than the bootloader itself installed on microSD. If you're using microSD or eMMC I'd be curious if that still happened. Although using the generic kernel, with guix's primitive module handling from the initrd (essentially looping through the list and manually loading each one), it might be easier to support a single image with linux-libre-arm64-generic kernel, where most features are built-in rather than modular. live well, vagrant --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYnKmcQAKCRDcUY/If5cW qibiAQDByaQvBWJcGqEDj1eTY5udRqfYPBeMiAWqMLvql/GlSQEA1SWWr2EOVSaY L3GJSBLfRgDP/4nvaNJfoeKicKQfcQU= =82cL -----END PGP SIGNATURE----- --=-=-=--