December 2021 - U-Boot

[RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
by AKASHI Takahiro 06 Dec '21

06 Dec '21

The purpose of this RPC is to reignite the discussion about how UEFI subystem would best be integrated into U-Boot device model. In the past, I poposed a couple of patch series, the latest one[1], while Heinrich revealed his idea[2], and the approach taken here is something between them, with a focus on block device handlings. # The code is a PoC and not well tested yet. Disks in UEFI world: ==================== In general in UEFI world, accessing to any device is performed through a 'protocol' interface which are installed to (or associated with) the device's UEFI handle (or an opaque pointer to UEFI object data). Protocols are implemented by either the UEFI system itself or UEFI drivers. For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL (efi_disk hereafter). Currently, every efi_disk may have one of two origins: a.U-Boot's block devices or related partitions (lib/efi_loader/efi_disk.c) b.UEFI objects which are implemented as a block device by UEFI drivers. (lib/efi_driver/efi_block_device.c) All the efi_diskss as (a) will be enumelated and created only once at UEFI subsystem initialization (efi_disk_register()), which is triggered by first executing one of UEFI-related U-Boot commands, like "bootefi", "setenv -e" or "efidebug". EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using blk_desc(->ops) in the corresponding udevice(UCLASS_BLK). On the other hand, efi_disk as (b) will be created each time UEFI boot services' connect_controller() is executed in UEFI app which, as a (device) controller, gives the method to access the device's data, ie. EFI_BLOCK_IO_PROTOCOL. >>> more details >>> Internally, connect_controller() search for UEFI driver that can support this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case, then calls the driver's 'bind' interface, which eventually installs the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for * creating additional partitions efi_disk's, and * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it. <<< <<< Issues: ======= 1. While an efi_disk represents a device equally for either a whole disk or a partition in UEFI world, the device model treats only a whole disk as a real block device or udevice(UCLASS_BLK). 2. efi_disk holds and makes use of "blk_desc" data even though blk_desc in plat_data is supposed to be private and not to be accessed outside the device model. # This issue, though, exists for all the implmenetation of U-Boot # file systems as well. For efi_disk(a), 3. A block device can be enumelated dynamically by 'scanning' a device bus in U-Boot, but UEFI subsystem is not able to update efi_disks accordingly. For examples, => scsi rescan; efidebug devices => usb start; efidebug devices ... (A) (A) doesn't show any usb devices detected. => scsi rescan; efidebug boot add -b 0 TEST scsi 0:1 ... => scsi rescan ... (B) => bootefi bootmgr ... (C) (C) may de-reference a bogus blk_desc pointer which has been freed by (B). (Please note that "scsi rescan" removes all udevices/blk_desc and then re-create them even if nothing is changed on a bus.) For efi_disk(b), 4. A controller (handle), combined with efi_block driver, has no corresponding udevice as a parent of efi_disks in DM tree, unlike, say, a scsi controller, even though it provides methods for block io perations. 5. There is no way supported to remove efi_disk's even after disconnect_controller() is called. My approach in this RFC: ======================== Due to functional differences in semantics, it would be difficult to identify "udevice" structure as a handle in UEFI world. Instead, we will have to somehow maintain a relationship between a udevice and a handle. 1-1. add a dedicated uclass, UCLASS_PARTITION, for partitions Currently, the uclass for paritions is not a UCLASS_BLK. It can be possible to define partitions as UCLASS_BLK (with IF_TYPE_PARTION?), but I'm afraid that it may introduce some chaos since udevice(UCLASS_BLK) is tightly coupled with 'struct blk_desc' data which is still used as a "structure to a whole disk" in a lot of interfaces. (I hope that you understand what it means.) In DM tree, a UCLASS_PARTITON instance has a UCLASS_BLK parent: For instance, UCLASS_SCSI --- UCLASS_BLK --- UCLASS_PARTITION (IF_TYPE_SCSI) | +- struct blk_desc +- struct disk_part +- scsi_blk_ops +- blk_part_ops 1-2. create partition udevices in the context of device_probe() part_init() is already called in blk_post_probe(). See the commit d0851c893706 ("blk: Call part_init() in the post_probe() method"). Why not enumelate partitions as well in there. 2. add new block access interfaces, which takes "udevice" as a target device, in U-Boot and use those functions to implement efi_disk operations (i.e. EFI_BLOCK_IO_PROTOCOL). 3-1. maintain a bi-directional link by adding - a UEFI handle pointer in "struct udevice" - a udevice pointer in UEFI handle (in fact, in "struct efi_disk_obj") 3-2. use device model's post_probe/pre_remove hook to synchronize the lifetime of efi_disk objects in UEFI world with the device model. 4. I have no answer to issue(4) and (5) yet. Patchs: ======= For easy understandings, patches may be categorized into seperate groups of changes. Patch#1-#9: DM: create udevices for partitions Patch#11,#12: UEFI: use udevice interfaces Patch#13-#16: UEFI: sync up with the device model for adding Patch#17-#19: UEFI: sync up with the device model for removing For removal case, we may need more consideration since removing handles unconditionally may end up breaking integrity of handles (some may still be held and referenced to by a UEFI app). Patch#20-#22: UEFI: align efi_driver with changes by the integration [1] https://lists.denx.de/pipermail/u-boot/2019-February/357923.html [2] https://lists.denx.de/pipermail/u-boot/2021-June/452297.html AKASHI Takahiro (22): scsi: call device_probe() after scanning usb: storage: call device_probe() after scanning mmc: call device_probe() after scanning nvme: call device_probe() after scanning sata: call device_probe() after scanning block: ide: call device_probe() after scanning dm: blk: add UCLASS_PARTITION dm: blk: add a device-probe hook for scanning disk partitions dm: blk: add read/write interfaces with udevice efi_loader: disk: use udevice instead of blk_desc dm: add a hidden link to efi object efi_loader: remove !CONFIG_BLK code from efi_disk efi_loader: disk: a helper function to create efi_disk objects from udevice dm: blk: call efi's device-probe hook efi_loader: cleanup after efi_disk-dm integration efi_loader: add efi_remove_handle() efi_loader: efi_disk: a helper function to delete efi_disk objects dm: blk: call efi's device-removal hook efi_driver: align with efi_disk-dm integration efi_driver: cleanup after efi_disk-dm integration efi_selftest: block device: adjust dp for a test disk (TEST) let dm-tree unchanged after block_io testing is done common/usb_storage.c | 6 + drivers/ata/dwc_ahsata.c | 10 + drivers/ata/fsl_sata.c | 11 + drivers/ata/sata_mv.c | 9 + drivers/ata/sata_sil.c | 12 + drivers/block/blk-uclass.c | 249 ++++++++++++++++ drivers/block/ide.c | 6 + drivers/mmc/mmc-uclass.c | 7 + drivers/nvme/nvme.c | 6 + drivers/scsi/scsi.c | 10 + include/blk.h | 15 + include/dm/device.h | 4 + include/dm/uclass-id.h | 1 + include/efi_loader.h | 8 +- lib/efi_driver/efi_block_device.c | 30 +- lib/efi_loader/efi_boottime.c | 8 + lib/efi_loader/efi_device_path.c | 29 ++ lib/efi_loader/efi_disk.c | 286 ++++++++++--------- lib/efi_loader/efi_setup.c | 5 - lib/efi_selftest/efi_selftest_block_device.c | 28 +- 20 files changed, 566 insertions(+), 174 deletions(-) -- 2.33.0

6 156

Please pull u-boot-dm/next
by Simon Glass 06 Dec '21

06 Dec '21

Hi Tom, https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/10137 The following changes since commit f89615088fba1b1f33713ad26dbe3a3c82b692ec: Merge branch 'next' of https://source.denx.de/u-boot/custodians/u-boot-net into next (2021-12-02 07:16:04 -0500) are available in the Git repository at: git://git.denx.de/u-boot-dm.git tags/dm-pull-5nov21 for you to fetch changes up to 0dbe5a1bde643b69375b11247f751d5acedb711c: timer: Add a migration message (2021-12-05 09:26:26 -0700) ---------------------------------------------------------------- binman refactoring to imrpove section handling bloblist - allow it to be allocated sandbox config-header cleanup ---------------------------------------------------------------- Alexander Preißner (1): drivers: core: lists: fix for loop index type Heinrich Schuchardt (1): sandbox: replace putchar(ch) by fputc(ch, stdout) Simon Glass (33): dtoc: Bring in the libfdt module automatically dtoc: Add support for reading 64-bit ints dtoc: Add support for reading fixed-length bytes properties binman: Tidy up style in cmdline binman: Add a way to obtain the version binman: Correct init of entry in Entry class binman: Correct comments for ReadChildData() binman: Drop the underscore in _ReadEntries() binman: Drop the filename property in entry_Section binman: Allow overriding BuildSectionData() binman: Allow control of which entries to read binman: Update the section documentation binman: Move cbfs.ObtainContents() down a bit binman: Use normal entries in cbfs binman: cbfs: Refactor the init process binman: cfbs: Refactor ObtainContents() for consistency binman: Rename testCbfsNoCOntents() bloblist: Support allocating the bloblist binman: Allow providing tools and blob directories binman: Allow listing an image created by a newer version binman: Allow extracting a file in an alternative format dtoc: Add support for reading string-list properties binman: Support lists of external blobs binman: Rename _ReadSubnodes() to ReadEntries() trace: sandbox: Use only the Kconfig options sandbox: Drop CONFIG_HOST_MAX_DEVICES Convert CONFIG_SYS_FDT_LOAD_ADDR to Kconfig Convert CONFIG_KEYBOARD to Kconfig keyboard: Add a migration message sandbox: Drop CONFIG_SYS_TIMER_RATE ide: Drop unused CONFIG options ide: Drop ATA_PORT_ADDR timer: Add a migration message Makefile | 7 ++ README | 11 --- arch/Kconfig | 1 + arch/arm/mach-exynos/Kconfig | 1 + arch/arm/mach-kirkwood/include/mach/config.h | 2 - arch/powerpc/include/asm/config.h | 3 - arch/sandbox/Kconfig | 10 +++ arch/sandbox/cpu/os.c | 2 +- cmd/Kconfig | 2 + cmd/host.c | 2 +- common/Kconfig | 15 +++- common/bloblist.c | 16 +++- common/board_f.c | 8 +- configs/chromebit_mickey_defconfig | 1 + configs/chromebook_jerry_defconfig | 1 + configs/chromebook_minnie_defconfig | 1 + configs/chromebook_speedy_defconfig | 1 + configs/novena_defconfig | 1 + configs/smdk5250_defconfig | 1 + configs/smdk5420_defconfig | 1 + configs/tools-only_defconfig | 7 +- doc/develop/bloblist.rst | 16 ++++ doc/develop/driver-model/migration.rst | 16 ++++ doc/develop/trace.rst | 9 +- drivers/block/ide.c | 14 +-- drivers/block/sandbox.c | 6 +- drivers/core/lists.c | 2 +- drivers/input/Kconfig | 9 ++ include/configs/edminiv2.h | 2 - include/configs/exynos5-dt-common.h | 3 - include/configs/novena.h | 1 - include/configs/r2dplus.h | 1 - include/configs/sandbox.h | 20 ----- include/configs/smdk5250.h | 1 - include/configs/smdk5420.h | 2 - include/configs/veyron.h | 2 - include/sandboxblockdev.h | 3 + scripts/config_whitelist.txt | 5 -- tools/binman/binman.rst | 65 +++++++++++++- tools/binman/cmdline.py | 76 ++++++++++++---- tools/binman/control.py | 28 +++++- tools/binman/entries.rst | 172 ++++++++++++++++++++++++++++++------ tools/binman/entry.py | 109 ++++++++++++++++++----- tools/binman/entry_test.py | 9 ++ tools/binman/etype/blob.py | 16 +++- tools/binman/etype/blob_ext_list.py | 58 ++++++++++++ tools/binman/etype/blob_phase.py | 2 +- tools/binman/etype/cbfs.py | 98 +++++++++++---------- tools/binman/etype/fdtmap.py | 12 +++ tools/binman/etype/files.py | 2 +- tools/binman/etype/fit.py | 4 +- tools/binman/etype/intel_ifwi.py | 4 +- tools/binman/etype/mkimage.py | 4 +- tools/binman/etype/section.py | 214 ++++++++++++++++++++++++++++++++++----------- tools/binman/ftest.py | 78 ++++++++++++++++- tools/binman/image.py | 12 ++- tools/binman/state.py | 18 ++++ tools/binman/test/213_fdtmap_alt_format.dts | 15 ++++ tools/binman/test/214_no_alt_format.dts | 13 +++ tools/binman/test/215_blob_ext_list.dts | 14 +++ tools/binman/test/216_blob_ext_list_missing.dts | 14 +++ tools/dtoc/fdt_util.py | 76 ++++++++++++++++ tools/dtoc/test/dtoc_test_simple.dts | 1 + tools/dtoc/test_dtoc.py | 2 + tools/dtoc/test_fdt.py | 53 ++++++++++- 65 files changed, 1102 insertions(+), 273 deletions(-) create mode 100644 tools/binman/etype/blob_ext_list.py create mode 100644 tools/binman/test/213_fdtmap_alt_format.dts create mode 100644 tools/binman/test/214_no_alt_format.dts create mode 100644 tools/binman/test/215_blob_ext_list.dts create mode 100644 tools/binman/test/216_blob_ext_list_missing.dts Regards, Simon

2 1

[PATCH v4 00/34] efi: Improvements to U-Boot running on top of UEFI
by Simon Glass 05 Dec '21

05 Dec '21

At present U-Boot can be built as an EFI app, but it is really just for testing, with very few features. Instead, the payload build is used for booting on top of UEFI, where U-Boot takes over the machine immediately and supplies its own drivers. But the app could be made more useful. This series provides access to EFI block devices and the video console within U-Boot. It also restructures the app to make it possible to boot a kernel, although further work is needed to implement this. This can be thought of as making U-Boot perform a little like 'grub', in that it runs purely based on UEFI-provided services. Of course a lot more work is required, but this is a start. Note: It would be very useful to include qemu tests of the app and stub in CI. This is available at u-boot-dm/efi-working Changes in v4: - Change the patch subject to make it clear this does not build U-Boot - Make EFI_LOADER depend on !EFI_APP - Update commit message to mention that you have to build U-Boot Changes in v3: - Add new patch to show the system-table revision - Default to 256MB of RAM for U-Boot instead of 32MB - Drop comments that confuse sphinx - Fix 'complicating' typo - Move device_path path change to its own patch - Update minimum RAM to 256MB! - s/qemu/QEMU/ Changes in v2: - Add MAINTAINERS entry - Add a better boot command too - Add a note that EFI_GRAPHICS_OUTPUT_PROTOCOL is used - Add a sentence about what the patch does - Add a work-around to avoid a toolchain crash - Add new patch to drop the OF_EMBED warning for EFI - Add new patch to enable DM_ETH for the app - Add new patch to support the efi command in the app - Add support for creating a partition table with a filesystem inside - Add support for running qemu with just a serial console (no display) - Drop mention of partitions from the commit message - Expand the commit message to make things clearer - Fix 'as' typo - Show the correct interface type with 'part list' - Update documentation - Update the commit message to explain things better - Use log_info() instead of printf() Simon Glass (34): efi: Add a script to build an image for testing on UEFI efi: Enable DM_ETH for the app efi: Drop the OF_EMBED warning for EFI x86: Create a 32/64-bit selection for the app efi: Create a 64-bit app x86: Don't duplicate global_ptr in 64-bit EFI app efi: Add a way to obtain boot services in the app efi: Add video support to the app efi: Add EFI uclass for media efi: Add a media/block driver for EFI block devices efi: Locate all block devices in the app patman: Use a ValueError exception if tools.Run() fails binman: Report an error if test files fail to compile binman: Support reading the offset of an ELF-file symbol binman: Tidy up comments on _DoTestFile() binman: Support updating the dtb in an ELF file efi: serial: Support arrow keys bloblist: Support allocating the bloblist x86: Allow booting a kernel from the EFI app x86: Don't process the kernel command line unless enabled x86: efi: Add room for the binman definition in the dtb efi: Drop device_path from struct efi_priv efi: Add comments to struct efi_priv efi: Fix ll_boot_init() operation with the app efi: Add a few comments to the stub efi: Share struct efi_priv between the app and stub code efi: Move exit_boot_services into a function efi: Check for failure when initing the app efi: Mention that efi_info_get() is only used in the stub efi: Show when allocated pages are used efi: Allow easy selection of serial-only operation efi: Update efi_get_next_mem_desc() to avoid needing a map efi: Support the efi command in the app efi: Show the system-table revision MAINTAINERS | 7 + Makefile | 10 +- arch/sandbox/dts/test.dts | 4 + arch/x86/cpu/efi/payload.c | 17 +- arch/x86/cpu/intel_common/Makefile | 2 +- arch/x86/cpu/u-boot-64.lds | 2 + arch/x86/cpu/x86_64/Makefile | 4 + arch/x86/cpu/x86_64/cpu.c | 32 +- arch/x86/cpu/x86_64/misc.c | 41 +++ arch/x86/dts/Makefile | 2 +- arch/x86/dts/efi-x86_app.dts | 4 + arch/x86/lib/bootm.c | 11 +- arch/x86/lib/zimage.c | 13 +- board/efi/Kconfig | 15 +- board/efi/efi-x86_app/Kconfig | 6 +- board/efi/efi-x86_app/MAINTAINERS | 11 +- cmd/Makefile | 2 +- cmd/efi.c | 78 +++-- common/Kconfig | 15 +- common/bloblist.c | 16 +- common/board_f.c | 8 +- ..._app_defconfig => efi-x86_app32_defconfig} | 3 +- configs/efi-x86_app64_defconfig | 38 +++ disk/part.c | 5 +- doc/develop/bloblist.rst | 16 + doc/develop/uefi/u-boot_on_efi.rst | 74 ++++- drivers/block/Kconfig | 33 +++ drivers/block/Makefile | 4 + drivers/block/blk-uclass.c | 2 +- drivers/block/efi-media-uclass.c | 15 + drivers/block/efi_blk.c | 115 ++++++++ drivers/block/sb_efi_media.c | 20 ++ drivers/serial/serial_efi.c | 11 +- drivers/video/Kconfig | 2 +- drivers/video/efi.c | 45 ++- include/configs/efi-x86_app.h | 31 +- include/dm/uclass-id.h | 1 + include/efi.h | 121 +++++++- include/efi_api.h | 15 + include/init.h | 2 +- lib/efi/Kconfig | 34 ++- lib/efi/efi.c | 106 +++++++ lib/efi/efi_app.c | 276 +++++++++++++++++- lib/efi/efi_stub.c | 95 +++--- lib/efi_loader/Kconfig | 1 + scripts/build-efi.sh | 193 ++++++++++++ test/dm/Makefile | 1 + test/dm/efi_media.c | 24 ++ tools/binman/binman.rst | 36 +++ tools/binman/cmdline.py | 2 + tools/binman/control.py | 11 + tools/binman/elf.py | 74 ++++- tools/binman/elf_test.py | 45 ++- tools/binman/ftest.py | 88 +++++- tools/binman/test/Makefile | 13 +- tools/binman/test/bss_data.c | 2 +- tools/binman/test/embed_data.c | 16 + tools/binman/test/embed_data.lds | 23 ++ tools/binman/test/u_boot_binman_embed.c | 13 + tools/binman/test/u_boot_binman_embed.lds | 29 ++ tools/binman/test/u_boot_binman_embed_sm.c | 13 + tools/patman/tools.py | 2 +- 62 files changed, 1745 insertions(+), 205 deletions(-) create mode 100644 arch/x86/cpu/x86_64/misc.c rename configs/{efi-x86_app_defconfig => efi-x86_app32_defconfig} (94%) create mode 100644 configs/efi-x86_app64_defconfig create mode 100644 drivers/block/efi-media-uclass.c create mode 100644 drivers/block/efi_blk.c create mode 100644 drivers/block/sb_efi_media.c create mode 100755 scripts/build-efi.sh create mode 100644 test/dm/efi_media.c create mode 100644 tools/binman/test/embed_data.c create mode 100644 tools/binman/test/embed_data.lds create mode 100644 tools/binman/test/u_boot_binman_embed.c create mode 100644 tools/binman/test/u_boot_binman_embed.lds create mode 100644 tools/binman/test/u_boot_binman_embed_sm.c -- 2.34.0.rc0.344.g81b53c2807-goog

3 49

[PATCH 0/7] meson: Demonstration of using binman to produce the image
by Simon Glass 05 Dec '21

05 Dec '21

The Odroid-C2 is quite a complicated image with many steps. It is an ideal example for how Binman can be used. Add a binman description and update the instructions accordingly. Simon Glass (7): binman: Allow providing tools and blob directories binman: Allow listing an image created by a newer version binman: Allow extracting a file in an alternative format dtoc: Add support for reading string-list properties binman: Support lists of external blobs binman: Rename _ReadSubnodes() to ReadEntries() RFC: Move Odroid-C2 to use binman to produce the image Makefile | 2 + arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 107 +++++++++++++++ arch/arm/mach-meson/Kconfig | 1 + doc/board/amlogic/odroid-c4.rst | 127 +++++------------- scripts/pylint.base | 2 + tools/binman/binman.rst | 65 ++++++++- tools/binman/cmdline.py | 2 + tools/binman/control.py | 28 +++- tools/binman/entries.rst | 25 +++- tools/binman/entry.py | 102 +++++++++++--- tools/binman/entry_test.py | 9 ++ tools/binman/etype/aml_encrypt.py | 124 +++++++++++++++++ tools/binman/etype/atf_fip.py | 16 ++- tools/binman/etype/blob.py | 16 ++- tools/binman/etype/blob_ext_list.py | 58 ++++++++ tools/binman/etype/cbfs.py | 8 +- tools/binman/etype/fdtmap.py | 12 ++ tools/binman/etype/fit.py | 4 +- tools/binman/etype/intel_ifwi.py | 4 +- tools/binman/etype/mkimage.py | 4 +- tools/binman/etype/section.py | 26 +++- tools/binman/ftest.py | 57 ++++++++ tools/binman/image.py | 12 +- tools/binman/missing-blob-help | 6 + tools/binman/test/213_aml_encrypt.dts | 38 ++++++ tools/binman/test/213_fdtmap_alt_format.dts | 15 +++ tools/binman/test/214_list_no_dtb.dts | 23 ++++ tools/binman/test/214_no_alt_format.dts | 13 ++ tools/binman/test/215_blob_ext_list.dts | 14 ++ .../binman/test/216_blob_ext_list_missing.dts | 14 ++ tools/dtoc/fdt_util.py | 21 +++ tools/dtoc/test_fdt.py | 9 ++ 32 files changed, 822 insertions(+), 142 deletions(-) create mode 100644 tools/binman/etype/aml_encrypt.py create mode 100644 tools/binman/etype/blob_ext_list.py create mode 100644 tools/binman/test/213_aml_encrypt.dts create mode 100644 tools/binman/test/213_fdtmap_alt_format.dts create mode 100644 tools/binman/test/214_list_no_dtb.dts create mode 100644 tools/binman/test/214_no_alt_format.dts create mode 100644 tools/binman/test/215_blob_ext_list.dts create mode 100644 tools/binman/test/216_blob_ext_list_missing.dts -- 2.34.0.rc2.393.gf8c9666880-goog

2 16

[PULL] u-boot-riscv/master
by Leo Liang 04 Dec '21

04 Dec '21

Hi Tom, The following changes since commit 4a14bfffd42f968ed9d72a780a8d44a9053c5b95: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2021-11-30 08:59:22 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-riscv.git for you to fetch changes up to c0ffc12a701621dc72dfc896965cbfe5b0dbf9b4: riscv: Enable SPI flash env for SiFive Unmatched. (2021-12-02 16:43:56 +0800) CI result shows no issue: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/10128 ---------------------------------------------------------------- Leo Yu-Chi Liang (1): board: ae350: Support autoboot from RAM Padmarao Begari (5): net: macb: Remove Microchip compatible string i2c: Add Microchip PolarFire SoC I2C driver riscv: dts: Split Microchip device tree riscv: Update Microchip MPFS Icicle Kit support doc: board: Update Microchip MPFS Icicle Kit doc Thomas Skibo (2): riscv: Support booting SiFive Unmatched from SPI. riscv: Enable SPI flash env for SiFive Unmatched. arch/riscv/cpu/fu740/Kconfig | 13 + arch/riscv/dts/hifive-unmatched-a00-u-boot.dtsi | 11 + arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 518 +++++-------------- arch/riscv/dts/microchip-mpfs.dtsi | 571 +++++++++++++++++++++ board/microchip/mpfs_icicle/Kconfig | 5 + board/microchip/mpfs_icicle/mpfs_icicle.c | 17 +- board/sifive/unmatched/Kconfig | 1 + board/sifive/unmatched/spl.c | 3 + configs/microchip_mpfs_icicle_defconfig | 1 - configs/sifive_unmatched_defconfig | 6 + doc/board/microchip/mpfs_icicle.rst | 7 +- doc/board/sifive/unmatched.rst | 31 ++ drivers/i2c/Kconfig | 6 + drivers/i2c/Makefile | 1 + drivers/i2c/i2c-microchip.c | 482 +++++++++++++++++ drivers/net/macb.c | 18 +- include/configs/ax25-ae350.h | 13 +- .../interrupt-controller/microchip-mpfs-plic.h | 196 +++++++ .../dt-bindings/interrupt-controller/riscv-hart.h | 17 + 19 files changed, 1512 insertions(+), 405 deletions(-) create mode 100644 arch/riscv/dts/microchip-mpfs.dtsi create mode 100644 drivers/i2c/i2c-microchip.c create mode 100644 include/dt-bindings/interrupt-controller/microchip-mpfs-plic.h create mode 100644 include/dt-bindings/interrupt-controller/riscv-hart.h Best regards, Leo

2 1

[PATCH v5 1/1] sf: Provide a command to access memory-mapped SPI
by Simon Glass 04 Dec '21

04 Dec '21

Add a new 'sf mmap' function to show the address of a SPI offset, if the hardware supports it. This is useful on x86 systems. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- (no changes since v4) Changes in v4: - Drop patches previously applied - Fix succeded typo Changes in v3: - Add configuration and return value also arch/Kconfig | 2 ++ cmd/Kconfig | 8 ++++++ cmd/sf.c | 35 +++++++++++++++++++++++++++ doc/usage/sf.rst | 63 ++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 108 insertions(+) diff --git a/arch/Kconfig b/arch/Kconfig index 3e2cc84ab2c..6333757f0ec 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -160,6 +160,7 @@ config SANDBOX imply CMD_LZMADEC imply CMD_SATA imply CMD_SF + imply CMD_SF_MMAP imply CMD_SF_TEST imply CRC32_VERIFY imply FAT_WRITE @@ -225,6 +226,7 @@ config X86 imply CMD_IRQ imply CMD_PCI imply CMD_SF + imply CMD_SF_MMAP imply CMD_SF_TEST imply CMD_ZBOOT imply DM_ETH diff --git a/cmd/Kconfig b/cmd/Kconfig index 5b30b13e438..3627c1cbd44 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1300,6 +1300,14 @@ config CMD_SF help SPI Flash support +config CMD_SF_MMAP + bool "sf mmap - Access memory-mapped SPI flash" + depends on CMD_SF + help + On some systems part of the SPI flash is mapped into mmemory. This + command provides a way to map a SPI-flash offset to a memory address, + so that the contents can be browsed using 'md', for example. + config CMD_SF_TEST bool "sf test - Allow testing of SPI flash" depends on CMD_SF diff --git a/cmd/sf.c b/cmd/sf.c index 72246d912fe..c78cd7e6342 100644 --- a/cmd/sf.c +++ b/cmd/sf.c @@ -384,6 +384,36 @@ static int do_spi_protect(int argc, char *const argv[]) return ret == 0 ? 0 : 1; } +static int do_spi_flash_mmap(int argc, char *const argv[]) +{ + loff_t offset, len, maxsize; + uint map_offset, map_size; + ulong map_base; + int dev = 0; + int ret; + + if (argc < 2) + return CMD_RET_USAGE; + + ret = mtd_arg_off_size(argc - 1, &argv[1], &dev, &offset, &len, + &maxsize, MTD_DEV_TYPE_NOR, flash->size); + if (ret) + return ret; + + ret = dm_spi_get_mmap(flash->dev, &map_base, &map_size, &map_offset); + if (ret) { + printf("Mapping not available (err=%d)\n", ret); + return CMD_RET_FAILURE; + } + if (offset < 0 || offset + len > map_size) { + printf("Offset out of range (map size %x)\n", map_size); + return CMD_RET_FAILURE; + } + printf("%lx\n", map_base + (ulong)offset); + + return 0; +} + enum { STAGE_ERASE, STAGE_CHECK, @@ -580,6 +610,8 @@ static int do_spi_flash(struct cmd_tbl *cmdtp, int flag, int argc, ret = do_spi_flash_erase(argc, argv); else if (strcmp(cmd, "protect") == 0) ret = do_spi_protect(argc, argv); + else if (IS_ENABLED(CONFIG_CMD_SF_MMAP) && !strcmp(cmd, "mmap")) + ret = do_spi_flash_mmap(argc, argv); else if (IS_ENABLED(CONFIG_CMD_SF_TEST) && !strcmp(cmd, "test")) ret = do_spi_flash_test(argc, argv); else @@ -611,6 +643,9 @@ static const char long_help[] = " or to start of mtd `partition'\n" "sf protect lock/unlock sector len - protect/unprotect 'len' bytes starting\n" " at address 'sector'" +#ifdef CONFIG_CMD_SF_MMAP + "\nsf mmap offset len - get memory address of SPI-flash offset\n" +#endif #ifdef CONFIG_CMD_SF_TEST "\nsf test offset len - run a very basic destructive test" #endif diff --git a/doc/usage/sf.rst b/doc/usage/sf.rst index 71bd1be5175..0452a762398 100644 --- a/doc/usage/sf.rst +++ b/doc/usage/sf.rst @@ -14,6 +14,7 @@ Synopis sf erase <offset>|<partition> <len> sf update <addr> <offset>|<partition> <len> sf protect lock|unlock <sector> <len> + sf mmap <offset>|<partition> <len> sf test <offset>|<partition> <len> Description @@ -143,6 +144,16 @@ lock|unlock Number of bytes to lock/unlock +Memory-mapped flash +------------------- + +On some systems part of the SPI flash is mapped into mmemory. With *sf mmap* +you can map a SPI-flash offset to a memory address, so that the contents can be +browsed using 'md', for example. + +The command will fail if this is not supported by the hardware or driver. + + Test ~~~~ @@ -240,6 +251,58 @@ This second example is running on coral, an x86 Chromebook:: 2 write: 227 ticks, 2255 KiB/s 18.040 Mbps 3 read: 189 ticks, 2708 KiB/s 21.664 Mbps + # On coral, SPI flash offset 0 corresponds to address ff081000 in memory + => sf mmap 0 1000 + device 0 offset 0x0, size 0x1000 + ff081000 + + # See below for how this address was obtained + => sf mmap e80000 11e18 + device 0 offset 0xe80000, size 0x11e18 + fff01000 + => md fff01000 + fff01000: b2e8e089 89000030 30b4e8c4 c0310000 ....0......0..1. + fff01010: 002c95e8 2ce8e800 feeb0000 dfe8c489 ..,....,........ + fff01020: f400002c 83f4fdeb d4e80cec 3100001e ,..............1 + fff01030: 0cc483c0 f883c3c3 8b0b770a df408504 .........w....@. + fff01040: c085fef1 c8b80575 c3fef1e5 53565755 ....u.......UWVS + fff01050: 89c38951 2404c7c5 80000002 8924048b Q......$......$. + fff01060: 89a20fdf 89fb89de 75890045 084d8904 ........E..u..M. + fff01070: ff0c5589 c5832404 243c8110 80000005 .U...$....<$.... + fff01080: 43c6da75 3b800030 43037520 d889f8eb u..C0..; u.C.... + fff01090: 5f5e5b5a 80e6c35d 535657c3 e7e8c689 Z[^_]....WVS.... + fff010a0: 89000069 00a164c3 8b000000 408b4c56 i....d......VL.@ + fff010b0: 0cec837c ddb9ff6a e8fef1e5 00004e01 |...j........N.. + fff010c0: a1640389 00000000 1c80b60f 66000001 ..d............f + fff010d0: b80c4389 00000001 a20fdf89 fb89de89 .C.............. + fff010e0: 89104389 c4831453 5bc03110 56c35f5e .C..S....1.[^_.V + fff010f0: 14ec8353 ce89d389 0000a164 b60f0000 S.......d....... + + +The offset e80000 was obtained using the following binman command, to find the +location of U-Boot SPL:: + + $ binman ls -i /tmp/b/chromebook_coral/u-boot.rom + Name Image-pos Size Entry-type Offset Uncomp-size + ------------------------------------------------------------------------------------------------------ + main-section 0 1000000 section 0 + spl e80000 11e18 u-boot-spl ffe80000 + u-boot d00000 9106e u-boot ffd00000 + ... + .. _SPI documentation: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface + + +Configuration +------------- + +The *sf* command is only available if `CONFIG_CMD_SF=y`. Note that it depends on +`CONFIG_DM_SPI_FLASH`. + +Return value +------------ + +The return value $? is set to 0 (true) if the command succeeded and to 1 (false) +otherwise. -- 2.34.1.400.ga245620fadb-goog

1 0

[PATCH v5 0/1] sf: Add documentation and an 'sf mmap' command
by Simon Glass 04 Dec '21

04 Dec '21

This little series adds documentation and a few other tidy-ups to the 'sf' command. It also provides a way to access memory-mapped SPI via the command line. NOTE: I am resending this as I didn't get a response to the question on the review. I suggest we apply it as is unless there is a better idea. (no changes since v4) Changes in v4: - Drop patches previously applied - Fix succeded typo Changes in v3: - Add configuration and return value also Simon Glass (1): sf: Provide a command to access memory-mapped SPI arch/Kconfig | 2 ++ cmd/Kconfig | 8 ++++++ cmd/sf.c | 35 +++++++++++++++++++++++++++ doc/usage/sf.rst | 63 ++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 108 insertions(+) -- 2.34.1.400.ga245620fadb-goog

1 0

[PATCH v2] RFC: gitlab: x86: Add a coreboot test
by Simon Glass 03 Dec '21

03 Dec '21

Coreboot supports U-Boot as a payload and this recently got a bit of a facelist. Add a test for this. For now this uses a binary build of coreboot (v4.15). Future work could potentially build it from source, but we need to figure out the toolchain problems first, since coreboot uses its own toolchain. This needs some changes to the hooks scripts as well. An example build is at https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/359687 Signed-off-by: Simon Glass <sjg(a)chromium.org> --- Changes in v2: - Drop the local CI changes; we need the real ones applied first anyway .gitlab-ci.yml | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 4c89daeadcf..065d8d6158e 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -52,6 +52,16 @@ stages: genimage --inputpath . --config board/sifive/unleashed/genimage_spi-nor.cfg; cp images/spi-nor.img ${UBOOT_TRAVIS_BUILD_DIR}/; fi + - if [[ "${TEST_PY_BD}" == "coreboot" ]]; then + wget -O - + "https://drive.google.com/uc?id=1x6nrtWIyIRPLS2cQBwYTnT2TbOI8UjmM&export=dow…" | + xz -dc >${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom; + wget -O - + "https://drive.google.com/uc?id=149Cz-5SZXHNKpi9xg6R_5XITWohu348y&export=dow…" > + cbfstool; + chmod a+x cbfstool; + ./cbfstool ${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom add-flat-binary -f ${UBOOT_TRAVIS_BUILD_DIR}/u-boot.bin -n fallback/payload -c LZMA -l 0x1110000 -e 0x1110000; + fi - virtualenv -p /usr/bin/python3 /tmp/venv - . /tmp/venv/bin/activate - pip install -r test/py/requirements.txt @@ -61,6 +71,10 @@ stages: ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID} ${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"} --build-dir "$UBOOT_TRAVIS_BUILD_DIR" + # It seems that the files in /tmp go away, so copy out what we need + - if [[ "${TEST_PY_BD}" == "coreboot" ]]; then + cp -v /tmp/coreboot/*.{html,css} .; + fi build all 32bit ARM platforms: stage: world build @@ -366,3 +380,15 @@ xtfpga test.py: TEST_PY_TEST_SPEC: "not sleep" TEST_PY_ID: "--id qemu" <<: *buildman_and_testpy_dfn + +coreboot test.py: + variables: + TEST_PY_BD: "coreboot" + TEST_PY_TEST_SPEC: "not sleep" + TEST_PY_ID: "--id qemu" + artifacts: + paths: + - "*.html" + - "*.css" + expire_in: 1 week + <<: *buildman_and_testpy_dfn -- 2.34.0.384.gca35af8252-goog

2 4

[PATCH] doc: usage: Fix command in fdt overlay apply sequence
by Alexander Dahl 03 Dec '21

03 Dec '21

Literally adhering to the docs gave this wrong output: U-Boot> setenv fdtaddr 0x87f00000 U-Boot> fdtaddr $fdtaddr Unknown command 'fdtaddr' - try 'help' Fixes: d80162cfc559 ("doc: Document how to apply fdt overlays") Signed-off-by: Alexander Dahl <ada(a)thorsis.com> --- doc/usage/fdt_overlays.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/usage/fdt_overlays.rst b/doc/usage/fdt_overlays.rst index ea39713434..7f113edae3 100644 --- a/doc/usage/fdt_overlays.rst +++ b/doc/usage/fdt_overlays.rst @@ -102,7 +102,7 @@ Manually Loading and Applying Overlays :: - => fdtaddr $fdtaddr + => fdt addr $fdtaddr 4. Grow it enough so it can encompass all applied overlays base-commit: 5b9ee01685290653671072d0030cd7ba9da3a705 -- 2.30.2

2 1

[u-boot-test-hooks PATCH] travis-ci: Add tests for booting from coreboot
by Simon Glass 03 Dec '21

03 Dec '21

Add a means of testing a coreboot + U-Boot build using qemu. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- bin/ellesmere/conf.coreboot_qemu | 1 + bin/travis-ci/conf.coreboot_qemu | 28 ++++++++++++++++++++++++++++ 2 files changed, 29 insertions(+) create mode 120000 bin/ellesmere/conf.coreboot_qemu create mode 100644 bin/travis-ci/conf.coreboot_qemu diff --git a/bin/ellesmere/conf.coreboot_qemu b/bin/ellesmere/conf.coreboot_qemu new file mode 120000 index 0000000..c81eb3f --- /dev/null +++ b/bin/ellesmere/conf.coreboot_qemu @@ -0,0 +1 @@ +../travis-ci/conf.coreboot_qemu \ No newline at end of file diff --git a/bin/travis-ci/conf.coreboot_qemu b/bin/travis-ci/conf.coreboot_qemu new file mode 100644 index 0000000..76d6927 --- /dev/null +++ b/bin/travis-ci/conf.coreboot_qemu @@ -0,0 +1,28 @@ +# Copyright (c) 2016 Konsulko Group. All rights reserved. +# Copyright 2021 Google LLC +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice shall be included in +# all copies or substantial portions of the Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. + +console_impl=qemu +qemu_machine="pc" +qemu_binary="qemu-system-i386" +qemu_extra_args="-nographic -cpu qemu32 -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device e1000,netdev=net0" +qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/coreboot.rom" +reset_impl=none +flash_impl=none -- 2.34.0.384.gca35af8252-goog

2 1