| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
These partitions are now generated on the first boot by systemd-repart.
The second rootfs is not needed for booting, and overwritten by RAUC
when a bundle is installed, so it can as well be empty. Remove the two
partitions to save space in the generated images.
Signed-off-by: Roland Hieber <rhi@pengutronix.de>
Link: https://lore.pengutronix.de/20231103225253.1349209-9-rhi@pengutronix.de
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GUID Partition Table format has several advantages over the legacy
MBR format. Especially when we want to make use of systemd-repart
functionality later, the GPT format is a necessity. Therefore, migrate
all images to the GPT format.
For some platforms (Raspberry Pi, AM355x, AT91), we still need a legacy
MBR partition table so that the ROM code can find a bootable partition
(which contains our barebox image). For those cases, transform the image
into a hybrid format containing an MBR at offset 0, which contains the
VFAT boot partition for the ROM loader, and a protective GPT partition
of partition type 0xEE after it to claim the remaining space on the
storage medium for GPT purposes. Then a GPT header is added at the
default GPT offset of 0x200, which defines the boot partition as well as
the root partition, and which is read by Barebox and Linux to boot the
system.
For images that contain a raw barebox image at a fixed offset outside of
a GPT partition, make sure that the GPT does not conflict with the
barebox image, and write only the primary GPT header into the hole
specified by the barebox image (offset 440 to 1K), but move the GPT
partition array to an offset behind the barebox image. (genimage will
then also offset the following partitions accordingly.)
Remove any 'disk-signature' options, which are not compatible with GPT;
genimage will generate a random Disk UUID instead. Also remove any
'partition-type' options, and set the respective partition type GUIDs
specified by the Discoverable Partitions Specification [1], or let
genimage default to the 'linux-generic' partition type.
For the rpi1 image-hdimg, overwrite the upstream hd.config with a
hardcoded genimage config file since it is not possible to build a
hybrid MBR/GPT image with the image recipe from upstream PTXdist.
For the v7a image-hdimg, enable GPT support in the platformconfig menu,
and re-add the respective config lines from the upstream version of the
config file in order to make GPT work.
The images with fixed partition sizes for qemu need to stay below the
size specified in the 'size' option, so decrease the size of the last
partition further to make space for the secondary GPT header, which will
reside in the last block of the image.
Link: [1] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Signed-off-by: Roland Hieber <rhi@pengutronix.de>
Link: https://lore.pengutronix.de/20231020090519.3320460-6-rhi@pengutronix.de
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As the 'reason' checker analyzes all <*>.dtb files in the imagedir and
assumes they are all kernel dtbs, rename the barebox dtb from
barebox-*.dtb to *.dtb-bb.
This silences a warning that kernel devicetrees should not contain
barebox,state nodes.
For a similar fix, see commit d16f98c910e20ee5a29da6ca0636b0fbad14f1b2.
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Enable barebox bootchooser framework
* Add a redundant root partition to the genimage config. The state and
environment partitions can live in the first 4 MiB of the SD card, so
move the the boot partition by the same amount.
* Add appropriate variables to the barebox defaultenv so the bootchooser
can decide into which partition to boot
* Add a state backend to the device tree fragment
* Map partitions in rauc-udev compatibility layer
Signed-off-by: Roland Hieber <rhi@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a somewhat ugly hack. The VideoCore will pass this device tree
to barebox, which doesn't care much for it. As a side effect of the
device tree passing, the VideoCore parses the device tree and will
detect that the mini-uart is enabled and take care not to scale clock
rate on the VideoCore, which the mini-uart is sourced from as that would
upset the baudrate.
There may be some config.txt entry we can use to avoid this, but for
now, just place the device tree into the boot partition.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.pengutronix.de/20220930162159.814389-10-a.fatoum@pengutronix.de
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generic barebox-dt-2nd.img mimics Linux and allows booting barebox
with an external device tree as if it were a kernel. We employ this for
using the same image for Rpi 2 and 3 by placing barebox device trees
into the FAT boot partition and having the VideoCore pass the correct
device tree to barebox.
While this works, it means the VideoCore won't patch the kernel device
tree, but many users depend on the VideoCore to apply overlays for
kernel consumption. While this could be done in barebox instead, it
doesn't have the familiar config.txt interface and it doesn't cover some
of the more obscure magic the videocore does: e.g. when applying an
overlay configuring the USBOTG, the VideCore will reconfigure clocks as
a side effect of applying the overlay.
For this reason, barebox now also has a barebox-raspberry-pi.img that
behaves the same as barebox-dt-2nd.img with the difference that it has
the multiple device trees built-in. It's already being generated since
updating to the new release, so let's make use of this.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.pengutronix.de/20220930162159.814389-6-a.fatoum@pengutronix.de
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
barebox has had the ability to generate an extra image that's bootable
like a kernel for a while now. With small adjustment, we can let the
videocore use this image and pass it the appropriate device tree
depending on the board used. Moving this decision into the VideoCore
allows us to use the same image for both Raspberry Pi 2, Rasperry Pi 3
and Raspberry Pi CM3.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.pengutronix.de/20220426083821.1829442-3-a.fatoum@pengutronix.de
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For partitions that are filled by another image, it does not make sense
to make partitions larger or smaller than their containing file system.
In those cases, genimage can already determine the partition sizes from
the referenced images, and calculates the partition offsets accordingly,
so in most cases we don't have to keep track of the sizes at all.
(A special case is vexpress.hdimg, which needs to have an empty block at
the end as a workaround for qemu, in which case it is clearer to have
all partition sizes and offsets explicitely in the config file. So don't
touch vexpress.hdimg here.)
Signed-off-by: Roland Hieber <rhi@pengutronix.de>
Link: https://lore.pengutronix.de/20210426060526.32029-2-rhi@pengutronix.de
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
|
| |
|
|
|
|
| |
It's not needed and now the files are actually removed during 'clean'.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
|
| |
|
|
| |
Signed-off-by: Rouven Czerwinski <rouven@czerwinskis.de>
|
| |
|
|
|
|
| |
This should help keeping the code-formatting consistent in this files.
Signed-off-by: Chris Fiege <c.fiege@pengutronix.de>
|
|
|
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
