Re: [U-Boot] [Resend RFC PATCH v1 0/3] GPT over MTD
Hi Ladislav, > > Hi Patrick, > > On Thu, Nov 24, 2016 at 02:14:22PM +, Patrick DELAUNAY wrote: > > Hi Ladislav, > > > > > > > > Hi, > > > > > > On Tue, Nov 22, 2016 at 02:24:39PM +0100, Patrick Delaunay wrote: > > > > > > > > I have a request to support GPT over MTD to be able to have > > > > dynamic MTD informations without u-Boot > > > environment(CONFIG_ENV_IS_NOWHERE is a > > > > 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... > > > 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? Not necessarily, we may have a first stage boot loader (let's say ARM Trusted Firmware) loaded by the ROM code before SPL execution. Then SPL is executed as plugin, without Flash driver only to initialize DDR (as FEL for sunxi platform or bootrom plugin for mvebu) The HW used is a board based on the STMicroelectronics 96Board with STiH410 soc (ARM core). > > 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. > With SPL executed as plugin, U-Boot is loaded by first boot loader, which support GPT but not UBI... > > 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. > > > > > 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? Not necessary, SPL is loaded and executed as plugin by first boot stage... > > > > > 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... > > > 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 :-) In our case, when SPL is loaded as plugin, without file system and flash driver support, the FALCON mode is not possible :-< The expected Flash layout is MTD partition1 => First Boot stage (with Flash driver / GPT support) MTD partition2 => U-Boot SPL (only DDR init) MTD partition3 => U-Boot (UBI / UBIFS stage) MTD partition4 => UBI (several volume : boot, kernel used by u-boot) - First boot stage is loaded by ROM in internal RAM - SPL is loaded as plugin to initialize DDR - Uboot is loaded in DDR by First Boot Stage / found UBI volume => my issue is : how to found MTD offset if they are not hardcoded in U-Boot and First Boot Stage ? > Best regards, >
Re: [U-Boot] [Resend RFC PATCH v1 0/3] GPT over MTD
Hi Patrick, On Thu, Nov 24, 2016 at 02:14:22PM +, Patrick DELAUNAY wrote: > Hi Ladislav, > > > > > Hi, > > > > On Tue, Nov 22, 2016 at 02:24:39PM +0100, Patrick Delaunay wrote: > > > > > > I have a request to support GPT over MTD to be able to have dynamic > > > MTD informations without u-Boot > > environment(CONFIG_ENV_IS_NOWHERE is a > > > 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... > 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? > 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. > 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. > > > 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? > > > 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... > 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Resend RFC PATCH v1 0/3] GPT over MTD
Hi Ladislav, > > Hi, > > On Tue, Nov 22, 2016 at 02:24:39PM +0100, Patrick Delaunay wrote: > > > > I have a request to support GPT over MTD to be able to have dynamic > > MTD informations without u-Boot > environment(CONFIG_ENV_IS_NOWHERE is a > > 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). 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. 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 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. > > 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. > > 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 Kernel and device tree will be found in a UBIFS volume > > - added code is under a new CONFIG : CONFIG_EFI_PARTITION_MTD > > - for implementation details, see doc/README.gpt.mtd > > > > TODO: > > - split patch between core impact (disk/part_efi.c) > > and command update > > - full support for modified command > > (today I limit the support for the command used by DISTRO macro) > > - DISTRO macro update for automatic boot on GPT bootable partition > > found in MTD devices > > Best regards, > ladis Best regards Patrick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Resend RFC PATCH v1 0/3] GPT over MTD
Hi, On Tue, Nov 22, 2016 at 02:24:39PM +0100, Patrick Delaunay wrote: > > I have a request to support GPT over MTD to be able to have dynamic > MTD informations without u-Boot environment(CONFIG_ENV_IS_NOWHERE > is a other requirement of my project). I'm just curious, could you provide some reasoning, why this is a requirement? > 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 :-) > 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? > - added code is under a new CONFIG : CONFIG_EFI_PARTITION_MTD > - for implementation details, see doc/README.gpt.mtd > > TODO: > - split patch between core impact (disk/part_efi.c) > and command update > - full support for modified command > (today I limit the support for the command used by DISTRO macro) > - DISTRO macro update for automatic boot on GPT bootable partition > found in MTD devices Best regards, ladis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Resend RFC PATCH v1 0/3] GPT over MTD
I have a request to support GPT over MTD to be able to have dynamic MTD informations without u-Boot environment(CONFIG_ENV_IS_NOWHERE is a other requirement of my project). 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. 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 ? - added code is under a new CONFIG : CONFIG_EFI_PARTITION_MTD - for implementation details, see doc/README.gpt.mtd TODO: - split patch between core impact (disk/part_efi.c) and command update - full support for modified command (today I limit the support for the command used by DISTRO macro) - DISTRO macro update for automatic boot on GPT bootable partition found in MTD devices the current level is tested manually on sandbox with : > make O=sandbox > sandbox/u-boot -d sandbox/arch/sandbox/dts/test.dtb => sf probe SF: Detected M25P16 with page size 256 Bytes, erase size 64 KiB, total 2 MiB => setenv nor_part "name=part1,size=64KiB;name=part2,size=128KiB;\ name=boot,type=linux,bootable,size=512KiB" => gpt write nor 0 $nor_part Writing GPT: success! => part list nor 0 PartStart LBA End LBA Name Attributes Type GUID Partition GUID 1 0x0080 0x00ff "part1" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-0040-00b2-331a19f91cb2 2 0x0100 0x01ff "part2" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 25718777-d0ad--8060-02cb591c9737 3 0x0200 0x05ff "boot" attrs: 0x0004 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 8a4bb8b4-e304-0040-0036-aff5c9c495b1 => setenv mtdids "nor0=nor0" => setenv mtdparts "mtdparts=" => mtdparts gpt nor0 => mtdparts device nor0 , # parts = 3 #: namesizeoffset mask_flags 0: part1 0x0001 0x0001 0 1: part2 0x0002 0x0002 0 2: boot0x0008 0x0004 0 active partition: nor0,0 - (part1) 0x0001 @ 0x0001 defaults: mtdids : none mtdparts: none => part list nor 0 -bootable nor_boot_part => printenv nor_boot_part nor_boot_part=3 Patrick Delaunay (3): add support of GPT partitioning over MTD uuid: remove dependency with io.h sandbox: GPT over MTD test Kconfig | 12 ++ cmd/gpt.c | 98 +++-- cmd/mtdparts.c| 103 - cmd/part.c| 48 - configs/sandbox_defconfig | 2 + disk/part_efi.c | 526 +- doc/README.gpt.mtd| 189 + include/configs/sandbox.h | 7 + include/part.h| 13 +- include/uuid.h| 1 + lib/uuid.c| 46 +++- 11 files changed, 959 insertions(+), 86 deletions(-) create mode 100644 doc/README.gpt.mtd -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
