RFC GPT over MTD
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [Resend RFC PATCH v1 0/3] GPT over MTD
Hi Patrick,
Quoted 9 lines · Patrick DELAUNAY
Hi Ladislav,
Quoted 7 lines
Hi,
Quoted 3 lines · Patrick Delaunay
I have a request to support GPT over MTD to be able to have dynamic MTD informations without u-Boot
Quoted 7 lines
Quoted 5 lines
environment(CONFIG_ENV_IS_NOWHERE is a
Quoted 1 line
other requirement of my project).
I'm just curious, could you provide some reasoning, why this is a requirement?
One platform requirement is to boot from any supported device (NOR, NAND, eMMC, ...) with the same boot chain (including SPL and U-Boot) WITHOUT recompilation and only by changing the hardware boot configuration (OTP).
Ok, the very same requirement here...
Quoted 8 lines
So I can't use environment (
CONFIG_ENV_IS_NOWHERE), because I don't know which device is expected for tests (boot from NAND, eMMC, NOR).
PS: I agree that in final client board, the u-boot will be optimized and u-boot env could be used.For block device(eMMC), it is not an issue
- first boot stage uses the GPT header in block device, to found, load and execute SPL and U-Boot.
- U-Boot Generic Distro feature is used in U-Boot to load kernel (found extlinux.conf in bootable partition)For Flash Device, the offset for SPL and U-Boot can't be determined easily by first boot stage.
Offset of SPL? Isn't that determined by boot ROM code? So you actually cannot do much with that. What hardware are you planning to use your solution with?
Quoted 2 lines
It is why GPT is re-used to save MTD partition offset without hardcoded part in first boot stage or in SPL (and without U-Boot env). => partition offsets are determined dynamically
As SPL offset is given and only U-Boot offset can be changed (is that assumption right?), you can store U-Boot in UBI volume.
Quoted 2 lines
So it should be easier to have the same behavior, based on GPT, for every boot device, block or flash. And the same tools (programmer) or command in U-Boot will use to update/read every device, based on GPT header.
I have to admit, that UBI solution would not let you use the same scenario for eMMC and NAND in terms of U-Boot commands used, but otherwise it is more robust.
Quoted 10 lines
Quoted 7 lines
Quoted 3 lines
The idea is to use the GPT header to save partitioning information directly in flash device (NOR or NAND), then the MTD variables are rebuild from these GPT partitions and can be used by DISTRO to search
bootable binary.
Ok, so you stored partitioning information on flash... That seems to be some kind of limited environment saved :-)
Yes I use standard GPT to save partitioning information, to save offset of MTD partition in flash device. So it is limited environment :-) but limited to partition offset and it can be discovered dynamically by first boot stage.
First boot stage is SPL here?
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
I make a first prototyping for this request but I want ask you if this feature is acceptable for u-boot and if this patches, after some update and cleanups, would be merged in u-boot mainline.
Do you see already some blocking points ?Is there any reason why you cannot use UBI?
UBIFS will be used in U-Boot not in previous boot stage
Just to make it completely clear: UBIFS is a filesystem used on the top of UBI volume...
Quoted 1 line
Kernel and device tree will be found in a UBIFS volume
...so kernel and DTB are stored as a files inside UBIFS (filesystem)?
Both SPL and U-Boot can load images from UBI volumes. Also you'll get Falcon mode for free :-)
Best regards,
ladis