From: Sascha Hauer <s.hauer@pengutronix.de>
To: Robert Karszniewicz <r.karszniewicz@phytec.de>
Cc: barebox@lists.infradead.org
Subject: Re: [RFC PATCH 0/4] Introduce global.bootm.root env var for booting via PARTUUID
Date: Wed, 1 Jul 2020 07:58:34 +0200 [thread overview]
Message-ID: <20200701055834.GK15485@pengutronix.de> (raw)
In-Reply-To: <1a2cb925-dccd-8de7-08da-c4abe76d473c@phytec.de>
Hi Robert,
On Tue, Jun 30, 2020 at 04:20:17PM +0200, Robert Karszniewicz wrote:
> The problem is that we want to be able to have the rootfs and kernel on
> separate partitions.
Why do you want to have that? It's kind of traditional to have the
kernel separated from the rootfs in some extra "kernel" partition, but
are there good reasons for it? There's an overhead in that the
bootloader has to read from a filesystem instead of only a raw
partition. Is that the reason?
Here at Pengutronix we are happy that we only have one partition image
that has everything needed to boot, including a description how to boot
it and including the kernel. No extra items that the bootloader has to
take care of, just put one thing somewhere and be done with it.
> We've looked into the Boot Loader Specification, but
> from what we saw, it makes A-B systems difficult (according to the spec,
> there can only be one "$BOOT" filesystem on a device).
barebox is more relaxed here. What we do here is to put two full root
filesystems into two different partitions on a SD/MMC. Each of the
partitions has one or more /loader/entries/*.conf file(s) and kernels.
You can then boot with "boot mmc0.0" into the first rootfs or with "boot
mmc0.1" into the second.
This may not be really conform to the specification, but works in
barebox and is a supported usecase. We do this for A/B Boot scenarios in
many projects.
Regards,
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2020-07-01 5:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-30 13:48 Robert Karszniewicz
2020-06-30 13:48 ` [RFC PATCH 1/4] bootm: add env var root_dev Robert Karszniewicz
2020-06-30 13:48 ` [RFC PATCH 2/4] globalvar: add bootm.root Robert Karszniewicz
2020-06-30 13:48 ` [RFC PATCH 3/4] bootm: handle global.bootm.root Robert Karszniewicz
2020-06-30 13:48 ` [RFC PATCH 4/4] bootm: mount root device before accessing linux_rootarg Robert Karszniewicz
2020-06-30 14:20 ` [RFC PATCH 0/4] Introduce global.bootm.root env var for booting via PARTUUID Robert Karszniewicz
2020-07-01 5:58 ` Sascha Hauer [this message]
2020-07-08 6:55 ` Stefan Riedmüller
2020-07-09 14:14 ` Sascha Hauer
2020-07-13 11:18 ` Robert Karszniewicz
2020-07-14 18:37 ` Sascha Hauer
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200701055834.GK15485@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=r.karszniewicz@phytec.de \
/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