From 4860ee9b09e00ded5e9dfb5d418283dc2840bf1e Mon Sep 17 00:00:00 2001 From: Lars Feyaerts Date: Mon, 2 Oct 2023 10:00:14 +0200 Subject: mkimage: allow internalization of data-position Make it possible for data that was externalized using a static external position (-p) to be internalized. Enables the ability to convert existing FIT images built with -p to be converted to a FIT image where the data is internal, to be converted to a FIT image where the data is external relative to the end of the FIT (-E) or change the initial static external position to a different static external position (-p). Removing the original external-data-related properties ensures that they're not present after conversion. Without this, they would still be present in the resulting FIT even if the FIT has been, for example, internalized. Signed-off-by: Lars Feyaerts Reviewed-by: Simon Glass --- doc/mkimage.1 | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'doc') diff --git a/doc/mkimage.1 b/doc/mkimage.1 index 76c7859bb03..d0a038a880a 100644 --- a/doc/mkimage.1 +++ b/doc/mkimage.1 @@ -860,6 +860,25 @@ verify signatures is added to u\-boot.dtb with required = "conf" property. \-K u\-boot.dtb -r kernel.itb .EE .RE +.P +Convert an existing FIT image from any of the three types of data storage +(internal, external data-offset or external data-position) to another type +of data storage. +.RS +.P +.EX +\fB// convert FIT from internal data to data-position +\fBmkimage -p 0x20000 -F internal_data.itb +.EE +.EX +\fB// convert FIT from data-position to data-offset +\fBmkimage -E -F external_data-position.itb +.EE +.EX +\fB// convert FIT from data-offset to internal data +\fBmkimage -F external_data-offset.itb +.EE +.RE . .SH SEE ALSO .BR dtc (1), -- cgit v1.3.1 From 0501c997a0aa647ec6995a6e662b677db037ee5c Mon Sep 17 00:00:00 2001 From: Andrii Chepurnyi Date: Tue, 3 Oct 2023 08:58:28 +0000 Subject: board: xen: introduce virtio-blk support Added new xenguest_arm64_virtio_defconfig which enables support for virtio-blk using various types of transport like virtio-pci, vrtio-mmio. Currently supported: up to 2 PCI host bridges and 10 MMIO devices. Note: DT parsing code was partly taken from pci-uclass.c Limitation: All memory regions should be below 4GB address space. Signed-off-by: Andrii Chepurnyi --- board/xen/xenguest_arm64/MAINTAINERS | 1 + board/xen/xenguest_arm64/xenguest_arm64.c | 108 +++++++++++++++++++++++++++++- configs/xenguest_arm64_virtio_defconfig | 63 +++++++++++++++++ doc/board/xen/xenguest_arm64.rst | 2 + include/configs/xenguest_arm64.h | 10 ++- 5 files changed, 181 insertions(+), 3 deletions(-) create mode 100644 configs/xenguest_arm64_virtio_defconfig (limited to 'doc') diff --git a/board/xen/xenguest_arm64/MAINTAINERS b/board/xen/xenguest_arm64/MAINTAINERS index 264920e240f..7a317366ec4 100644 --- a/board/xen/xenguest_arm64/MAINTAINERS +++ b/board/xen/xenguest_arm64/MAINTAINERS @@ -6,3 +6,4 @@ F: board/xen/xenguest_arm64/ F: doc/board/xen/ F: include/configs/xenguest_arm64.h F: configs/xenguest_arm64_defconfig +F: configs/xenguest_arm64_virtio_defconfig diff --git a/board/xen/xenguest_arm64/xenguest_arm64.c b/board/xen/xenguest_arm64/xenguest_arm64.c index 6e10bba76b7..244070a242d 100644 --- a/board/xen/xenguest_arm64/xenguest_arm64.c +++ b/board/xen/xenguest_arm64/xenguest_arm64.c @@ -8,12 +8,15 @@ */ #include +#include #include #include #include #include #include #include +#include +#include #include #include @@ -49,7 +52,14 @@ void *board_fdt_blob_setup(int *err) return (void *)rom_pointer[0]; } -#define MAX_MEM_MAP_REGIONS 5 +/* + * MAX_MEM_MAP_REGIONS should respect to: + * 3 Xen related regions + * 6 regions for 2 PCI Host bridges + * 10 regions for MMIO devices + * 2 memory regions + */ +#define MAX_MEM_MAP_REGIONS 22 static struct mm_region xen_mem_map[MAX_MEM_MAP_REGIONS]; struct mm_region *mem_map = xen_mem_map; @@ -63,6 +73,93 @@ static int get_next_memory_node(const void *blob, int mem) return mem; } +#ifdef CONFIG_VIRTIO_BLK +#ifdef CONFIG_VIRTIO_PCI +static void add_pci_mem_map(const void *blob, int *cnt) +{ + struct fdt_resource reg_res; + int node = -1, len = 0, cells_per_record = 0, max_regions = 0; + int pci_addr_cells = 0, addr_cells = 0, size_cells = 0; + + while ((node = fdt_node_offset_by_prop_value(blob, node, "compatible", + "pci-host-ecam-generic", + sizeof("pci-host-ecam-generic"))) >= 0) { + if ((*cnt) >= MAX_MEM_MAP_REGIONS || + fdt_get_resource(blob, node, "reg", 0, ®_res) < 0) + return; + + xen_mem_map[*cnt].virt = reg_res.start; + xen_mem_map[*cnt].phys = reg_res.start; + xen_mem_map[*cnt].size = fdt_resource_size(®_res); + xen_mem_map[*cnt].attrs = (PTE_BLOCK_MEMTYPE(MT_NORMAL) | + PTE_BLOCK_INNER_SHARE); + (*cnt)++; + + const u32 *prop = fdt_getprop(blob, node, "ranges", &len); + + if (!prop) + return; + + pci_addr_cells = fdt_address_cells(blob, node); + addr_cells = fdt_address_cells(blob, 0); + size_cells = fdt_size_cells(blob, node); + + /* PCI addresses are always 3-cells */ + len /= sizeof(u32); + cells_per_record = pci_addr_cells + addr_cells + size_cells; + max_regions = len / cells_per_record + CONFIG_NR_DRAM_BANKS; + + for (int i = 0; i < max_regions; i++, len -= cells_per_record) { + u64 pci_addr, addr, size; + int space_code; + u32 flags; + + if (((*cnt) >= MAX_MEM_MAP_REGIONS) || len < cells_per_record) + return; + + flags = fdt32_to_cpu(prop[0]); + space_code = (flags >> 24) & 3; + pci_addr = fdtdec_get_number(prop + 1, 2); + prop += pci_addr_cells; + addr = fdtdec_get_number(prop, addr_cells); + prop += addr_cells; + size = fdtdec_get_number(prop, size_cells); + prop += size_cells; + + xen_mem_map[*cnt].virt = addr; + xen_mem_map[*cnt].phys = addr; + xen_mem_map[*cnt].size = size; + xen_mem_map[*cnt].attrs = (PTE_BLOCK_MEMTYPE(MT_NORMAL) | + PTE_BLOCK_INNER_SHARE); + (*cnt)++; + } + } +} +#endif + +#ifdef CONFIG_VIRTIO_MMIO +static void add_mmio_mem_map(const void *blob, int *cnt) +{ + int node = -1; + struct fdt_resource reg_res; + + if ((*cnt) >= MAX_MEM_MAP_REGIONS) + return; + while ((node = fdt_node_offset_by_prop_value(blob, node, "compatible", "virtio,mmio", + sizeof("virtio,mmio"))) >= 0) { + if (fdt_get_resource(blob, node, "reg", 0, ®_res) < 0) + return; + xen_mem_map[*cnt].virt = reg_res.start; + xen_mem_map[*cnt].phys = reg_res.start; + xen_mem_map[*cnt].size = roundup(fdt_resource_size(®_res), PAGE_SIZE); + xen_mem_map[*cnt].attrs = (PTE_BLOCK_MEMTYPE(MT_NORMAL) | + PTE_BLOCK_INNER_SHARE); + (*cnt)++; + } +} +#endif +#endif + static int setup_mem_map(void) { int i = 0, ret, mem, reg = 0; @@ -72,6 +169,7 @@ static int setup_mem_map(void) phys_addr_t gnttab_base; phys_size_t gnttab_sz; + memset(xen_mem_map, 0, sizeof(xen_mem_map)); /* * Add "magic" region which is used by Xen to provide some essentials * for the guest: we need console and xenstore. @@ -143,6 +241,14 @@ static int setup_mem_map(void) xen_mem_map[i].attrs = (PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_INNER_SHARE); } +#ifdef CONFIG_VIRTIO_BLK +#ifdef CONFIG_VIRTIO_PCI + add_pci_mem_map(blob, &i); +#endif +#ifdef CONFIG_VIRTIO_MMIO + add_mmio_mem_map(blob, &i); +#endif +#endif return 0; } diff --git a/configs/xenguest_arm64_virtio_defconfig b/configs/xenguest_arm64_virtio_defconfig new file mode 100644 index 00000000000..b812cf4fe84 --- /dev/null +++ b/configs/xenguest_arm64_virtio_defconfig @@ -0,0 +1,63 @@ +CONFIG_ARM=y +CONFIG_POSITION_INDEPENDENT=y +CONFIG_TARGET_XENGUEST_ARM64=y +CONFIG_TEXT_BASE=0x40080000 +CONFIG_SYS_MALLOC_LEN=0x2000000 +CONFIG_SYS_MALLOC_F_LEN=0x400 +CONFIG_NR_DRAM_BANKS=1 +CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64" +CONFIG_SYS_PROMPT="xenguest# " +CONFIG_IDENT_STRING=" xenguest" +CONFIG_SYS_LOAD_ADDR=0x40000000 +CONFIG_OF_SYSTEM_SETUP=y +CONFIG_BOOTDELAY=10 +CONFIG_SYS_MAXARGS=64 +CONFIG_SYS_PBSIZE=1051 +#CONFIG_SYS_CBSIZE=512 +# CONFIG_CMD_BDI is not set +# CONFIG_CMD_BOOTD is not set +CONFIG_SYS_BOOTM_LEN=0x800000 +# CONFIG_CMD_ELF is not set +# CONFIG_CMD_GO is not set +# CONFIG_CMD_IMI is not set +# CONFIG_CMD_XIMG is not set +# CONFIG_CMD_EXPORTENV is not set +# CONFIG_CMD_IMPORTENV is not set +# CONFIG_CMD_EDITENV is not set +# CONFIG_CMD_SAVEENV is not set +# CONFIG_CMD_ENV_EXISTS is not set +# CONFIG_CMD_CRC32 is not set +# CONFIG_CMD_LZMADEC is not set +# CONFIG_CMD_UNZIP is not set +# CONFIG_CMD_LOADB is not set +# CONFIG_CMD_LOADS is not set +# CONFIG_CMD_ECHO is not set +# CONFIG_CMD_ITEST is not set +# CONFIG_CMD_SOURCE is not set +# CONFIG_CMD_SETEXPR is not set +# CONFIG_CMD_SLEEP is not set +CONFIG_CMD_EXT4=y +CONFIG_CMD_FAT=y +# CONFIG_NET is not set +# CONFIG_MMC is not set +# CONFIG_REQUIRE_SERIAL_CONSOLE is not set +CONFIG_DM_SERIAL=y +CONFIG_PHYS_64BIT=y +CONFIG_PCI=y +CONFIG_CMD_PCI=y +CONFIG_PCIE_ECAM_GENERIC=y +CONFIG_PCI_REGION_MULTI_ENTRY=y +CONFIG_PCI_INIT_R=y +CONFIG_PCI_PNP=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_SYS_PCI_64BIT=y +CONFIG_VIRTIO=y +CONFIG_VIRTIO_MMIO=y +CONFIG_VIRTIO_PCI=y +CONFIG_VIRTIO_BLK=y +CONFIG_CMD_VIRTIO=y +# CONFIG_VIRTIO_PCI_LEGACY is not set +# CONFIG_VIRTIO_NET is not set +# CONFIG_VIRTIO_RNG is not set +CONFIG_CMD_GPT=y +CONFIG_PARTITION_TYPE_GUID=y diff --git a/doc/board/xen/xenguest_arm64.rst b/doc/board/xen/xenguest_arm64.rst index e9bdaf7ffb2..92be9d43769 100644 --- a/doc/board/xen/xenguest_arm64.rst +++ b/doc/board/xen/xenguest_arm64.rst @@ -23,6 +23,7 @@ previously done by NXP [4]: - PV block device frontend driver with XenStore based device enumeration and UCLASS_PVBLOCK class; - PV serial console device frontend driver; +- Virtio block device support; - Xen hypervisor support with minimal set of the essential headers adapted from the Linux kernel; - Xen grant table support; @@ -34,6 +35,7 @@ previously done by NXP [4]: define any start addresses at compile time which is up to Xen to choose at run-time; - new defconfig introduced: xenguest_arm64_defconfig. +- new defconfig introduced: xenguest_arm64_virtio_defconfig. Board limitations diff --git a/include/configs/xenguest_arm64.h b/include/configs/xenguest_arm64.h index bc268d25dc3..3dce25b60e7 100644 --- a/include/configs/xenguest_arm64.h +++ b/include/configs/xenguest_arm64.h @@ -14,9 +14,15 @@ #undef CFG_SYS_SDRAM_BASE #undef CFG_EXTRA_ENV_SETTINGS + +#ifdef CONFIG_VIRTIO_BLK +#define CFG_EXTRA_ENV_SETTINGS \ + "virtioboot=virtio scan; ext4load virtio 0 0x90000000 /boot/Image;" \ + "booti 0x90000000 - ${fdtcontroladdr};\0" +#else #define CFG_EXTRA_ENV_SETTINGS \ - "loadimage=ext4load pvblock 0 0x90000000 /boot/Image;\0" \ - "pvblockboot=run loadimage;" \ + "pvblockboot=ext4load pvblock 0 0x90000000 /boot/Image;" \ "booti 0x90000000 - 0x88000000;\0" +#endif #endif /* __XENGUEST_ARM64_H */ -- cgit v1.3.1 From 6442434d5184188871a33154b610f7ffdb13a406 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 24 Aug 2023 19:39:24 -0600 Subject: bootstd: Drop some TODOs The existing TODOs are done, so remove them. Add another that came up today. Signed-off-by: Simon Glass --- doc/develop/bootstd.rst | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst index 6172dc906bd..51cd5736627 100644 --- a/doc/develop/bootstd.rst +++ b/doc/develop/bootstd.rst @@ -781,9 +781,7 @@ To do Some things that need to be done to completely replace the distro-boot scripts: -- add bootdev drivers for dhcp, sata, scsi, ide, virtio -- PXE boot for EFI -- support for loading U-Boot scripts +- implement extensions (devicetree overlays with add-on boards) Other ideas: -- cgit v1.3.1 From 4fb7e570d6bc3658e581937940de8cde52bd4103 Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes Date: Mon, 25 Sep 2023 10:09:09 +0200 Subject: doc: use .dtso as extension for device tree overlay sources Moving towards using .dtso for overlay sources, update the documentation examples to follow that pattern. Signed-off-by: Rasmus Villemoes Reviewed-by: Simon Glass --- doc/develop/uefi/uefi.rst | 4 ++-- doc/usage/fdt_overlays.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index 68f9b332d15..f8510d31d7a 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -594,10 +594,10 @@ To insert the lowest supported version into a dtb .. code-block:: console - $ dtc -@ -I dts -O dtb -o version.dtbo version.dts + $ dtc -@ -I dts -O dtb -o version.dtbo version.dtso $ fdtoverlay -i orig.dtb -o new.dtb -v version.dtbo -where version.dts looks like:: +where version.dtso looks like:: /dts-v1/; /plugin/; diff --git a/doc/usage/fdt_overlays.rst b/doc/usage/fdt_overlays.rst index 7f113edae37..81d0d37f3f1 100644 --- a/doc/usage/fdt_overlays.rst +++ b/doc/usage/fdt_overlays.rst @@ -43,7 +43,7 @@ traditional binary device-tree. For example: $ dtc -@ -I dts -O dtb -o base.dtb base.dts -**overlay.dts** +**overlay.dtso** :: @@ -63,7 +63,7 @@ traditional binary device-tree. For example: .. code-block:: console - $ dtc -@ -I dts -O dtb -o overlay.dtbo overlay.dts + $ dtc -@ -I dts -O dtb -o overlay.dtbo overlay.dtso Ways to Utilize Overlays in U-Boot ---------------------------------- -- cgit v1.3.1 From 4cb6c8e5f0de3c4c5f9eba51c6a1610934a8cf77 Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes Date: Thu, 28 Sep 2023 10:02:57 +0200 Subject: mkimage: update man page and -h output The man page correctly said that -B was ignored without -E, while the `mkimage -h` output suggested otherwise. Now that -B can actually be used by itself, update the man page. While at it, also amend the `mkimage -h` line to mention the connection with -E. The FDT header is a fixed 40 bytes, so its size cannot (and is not) modified, while its alignment is a property of the address in RAM one loads the FIT to, so not something mkimage can affect in any way. (In the file itself, the header is of course at offset 0, which has all possible alignments already.) Reported-by: Sean Anderson Signed-off-by: Rasmus Villemoes Reviewed-by: Simon Glass --- doc/mkimage.1 | 6 ++++-- tools/mkimage.c | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/mkimage.1 b/doc/mkimage.1 index d0a038a880a..c1903896f3d 100644 --- a/doc/mkimage.1 +++ b/doc/mkimage.1 @@ -281,8 +281,10 @@ properties. A \(oqdata-offset\(cq of 0 indicates that it starts in the first .BI \-B " alignment" .TQ .BI \-\-alignment " alignment" -The alignment, in hexadecimal, that external data will be aligned to. This -option only has an effect when \-E is specified. +The alignment, in hexadecimal, that the FDT structure will be aligned +to. With +.BR \-E , +also specifies the alignment for the external data. . .TP .BI \-p " external-position" diff --git a/tools/mkimage.c b/tools/mkimage.c index 6dfe3e1d42d..a5979fa6fd7 100644 --- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -112,7 +112,7 @@ static void usage(const char *msg) " -f => input filename for FIT source\n" " -i => input filename for ramdisk file\n" " -E => place data outside of the FIT structure\n" - " -B => align size in hex for FIT structure and header\n" + " -B => align size in hex for FIT structure and, with -E, for the external data\n" " -b => append the device tree binary to the FIT\n" " -t => update the timestamp in the FIT\n"); #ifdef CONFIG_FIT_SIGNATURE -- cgit v1.3.1