unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Vagrant Cascadian <vagrant@debian.org>
To: Simon South <simon@simonsouth.net>
Cc: help-guix@gnu.org
Subject: Re: Building installation image for ROCK64
Date: Mon, 27 Apr 2020 10:22:27 -0700	[thread overview]
Message-ID: <87o8rcvo6k.fsf@ponder> (raw)
In-Reply-To: <87ees99icv.fsf@simonsouth.net>

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

On 2020-04-27, Simon South wrote:
> Vagrant Cascadian <vagrant@debian.org> writes:
>> With your current layout, parts of the bootloader may be written to the
>> same offsets as files in your first partition...
>
> Yes, my mistake. Thanks for pointing that out.
>
>> You really want to have the loader1 (start sector 64, 2.5MB size) and
>> loader2 (start sector 16384, 4MB size) partitions...
>
> I'm not sure how literally you meant this to be interpreted, but after a
> bit of experimentation it seems the most sensible arrangement for now is
> just to have a single partition starting at sector 32,768 for the root
> filesystem. This is because

That also should work fine.


> - If real partitions are created for the bootloader stages and the
>   trusted firmware, U-Boot will fail to start the OS (with "Unrecognized
>   filesystem type") when it scans for bootable partitions. (It probably
>   ought to just skip over partitions without a recognizable filesystem,
>   but it doesn't seem to behave that way.)

It's possible to mark the partition as bootable (I think "ESP Boot" or
something like that).


> - It seems Guix System does not yet support having /boot on a separate
>   partition and will fail at startup if the store isn't available on the
>   same filesystem as extlinux.conf. Consequently reserving 112 MB for a
>   separate boot partition accomplishes nothing.

Right; I wouldn't suggest using such a tiny boot partition anyways (I
think they suggest a 112MB /boot ?).


> At least this way the root filesystem is safe from being overwritten by
> the bootloader, and as Guix's support for multiple partitions improves
> over time it'll be possible to more closely follow Rockchip's
> conventions.

Yeah, anything after sector 32768 is, in my opinion, fair game to do
whatever you want with. :)


>> It would be nice to eventually be able to create installer images for
>> aarch64/armhf...
>
> Yes, absolutely. In the meantime just making available a
> minimal-but-complete image for writing to a microSD card would be a big
> help to people looking to get started quickly with Guix on the ROCK64.

I'm tempted to make armhf and aarch64 one-off images using
linux-image-arm64-generic and linux-image-arm-generic kernels, and
include instructions for updating the bootloader, to support an
arbitrary number of different systems... this should be doable.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

  reply	other threads:[~2020-04-27 17:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-11 19:48 Building installation image for ROCK64 Simon South
2020-04-11 21:12 ` Vagrant Cascadian
2020-04-12 16:19   ` Simon South
2020-04-26 14:31   ` Simon South
2020-04-26 17:09     ` Vagrant Cascadian
2020-04-27 13:19       ` Simon South
2020-04-27 17:22         ` Vagrant Cascadian [this message]
2020-04-12 10:18 ` Pierre Langlois
2020-04-12 10:27   ` Pierre Langlois
2020-04-12 16:25   ` Simon South

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8rcvo6k.fsf@ponder \
    --to=vagrant@debian.org \
    --cc=help-guix@gnu.org \
    --cc=simon@simonsouth.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).