Add support to run 800Mhz speed grade parts at 650MHz by neerajdantu · Pull Request #2 · STMicroelectronics/u-boot

neerajdantu · 2022-12-04T20:24:59Z

This patch allows running 800MHz speed grade superset devices at 650MHz by adding OPP hardware ID of 800MHz speed grade parts to 650MHz OPP table.

ST-dot-com · 2022-12-04T20:25:03Z

This pull request has been refused, the Contribution License Agreement must be signed.

Add support for the USB 3.0 devices in rk3588: - USB DRD(dual role device) 3.0 #0 as usbdrd3_0 which is available in rk3588s - USB DRD(dual role device) 3.0 #1 as usbdrd3_1 which is available in rk3588 only - USB DP PHY (combo USB3.0 and DisplayPort Alt Mode ) #0 phy interface as usbdp_phy0 - USB DP PHY (combo USB3.0 and DisplayPort Alt Mode ) #1 phy interface as usbdp_phy1 - USB 2.0 phy #2 , the USB 3.0 device can work with this phy in USB 2.0 mode - associated GRFs (general register files) for the devices. Signed-off-by: Joseph Chen <chenjh@rock-chips.com> [eugen.hristev@collabora.com: move nodes to right place, adapt from latest linux kernel] Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Raymond Mao <raymond.mao@linaro.org> says: Motivations for changes: Current SMBIOS library and command-line tool is not fully matching with the requirements: 1. Missing support for other mandatory types (u-boot#7, u-boot#9, u-boot#16, u-boot#17, u-boot#19). 2. Only a few platforms support SMBIOS node from the device tree. 3. Values of some fields are hardcoded in the library other than fetching from the device hardware. 4. Embedded data with dynamic length is not supported (E.g. Contained Object Handles in Type #2 and Contained Elements in Type #3) Changes: 1. Refactor the SMBIOS library and command-line tool to better align with the SMBIOS spec. 2. Create an arch-specific driver for all aarch64-based platforms to fetch SMBIOS private data from the device hardware (processor and cache). 3. Create a sysinfo driver to poppulate platform SMBIOS private data. 4. Add generic SMBIOS DTS file for arm64 platforms for those common strings and values which cannot be retrieved from the system registers. Vendors can create their own SMBIOS node using this as an example. For those boards without SMBIOS nodes, this DTS file can be included to have a generic SMBIOS information of the system. 5. Add support for Type u-boot#7 (Cache Information) and link its handles to Type #4. 6. To minimize size-growth for those platforms which have not sufficient ROM spaces or the platforms which don't need detailed SMBIOS information, new added fields are only being built when kconfig GENERATE_SMBIOS_TABLE_VERBOSE is selected. Once this patch is acceptted, subsequent patch sets will add other missing types (u-boot#9, u-boot#16, u-boot#17, u-boot#19). Tests: To test this with QEMU arm64, please follow the guide on dt_qemu.rst to get a merged DT to run with. ``` qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \ | dtc - -o merged.dtb qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \ -dtb merged.dtb ``` Link: https://lore.kernel.org/r/20241206225438.13866-1-raymond.mao@linaro.org

The mtd device is got in setup_mtd_device(), we must put the mtd device before exiting the function to update the mtd use count. This patch fixes the following env error: > Removing MTD device #2 (u-boot-env) with use count 1 > Error when deleting partition "u-boot-env" (-16) Fixes: 03fb08d ("env: Introduce support for MTD") Signed-off-by: Shiji Yang <yangshiji66@outlook.com>

An UMS session with eMMC device specifier "ums C mmc dev.part1,dev.part2" exposes the same eMMC HW partition 'part2' twice instead of exposing both HW partitions 'part1' and 'part2'. Fix this by switching the eMMC HW partition before block device read/write access. An eMMC is represented by a single struct blk_desc, with the currently selected HW partition being stored in this struct blk_desc. Each call to part_get_info_by_dev_and_name_or_num() with partition string dev[.partN] does trigger HW partition switch by calling blk_get_device_part_str() -> blk_get_device_part_str() -> get_dev_hwpart() -> get_dev_hwpart() -> blk_dselect_hwpart(). The ums_init() iterates over the device specifier string and calls part_get_info_by_dev_and_name_or_num() in a loop for each dev[.partN] entry used as the partition string. If the device specifier string contains more than one dev[.partN] partition strings for the same dev device, then it is the HW partition described in the last dev[.partN] partition string entry that is accessed for all dev device partition strings in the device specifier string, because that last dev[.partN] partition string entry was the last one that triggered blk_dselect_hwpart() call for that device. To access the expected HW partition for every dev[.partN] partition string entry, it is necessary to call blk_dselect_hwpart() before each block read or write. Store HW partition described for each dev[.partN] partition string in struct ums and use the stored value to make it so. The blk_dselect_hwpart() does test whether the currently selected HW partition is already configured in hardware and does not reconfigure the hardware if that is the case, therefore for the majority of block reads and writes, blk_dselect_hwpart() is a no-op with negligible performance impact. Example reproducer is listed below. The last sector of both eMMC HW BOOT partitions is populated with distinct test pattern and UMS is launched: " => mmc dev 1 1 ; mmc read $loadaddr 0x1fff 1 ; md $loadaddr 4 switch to partitions #1, OK mmc1(part 1) is current device MMC read: dev # 1, block # 8191, count 1 ... 1 blocks read: OK 84000000: 1234abcd 1234abcd 1234abcd 1234abcd ..4...4...4...4. => mmc dev 1 2 ; mmc read $loadaddr 0x1fff 1 ; md $loadaddr 4 switch to partitions #2, OK mmc1(part 2) is current device MMC read: dev # 1, block # 8191, count 1 ... 1 blocks read: OK 84000000: 567890ef 567890ef 567890ef 567890ef ..xV..xV..xV..xV => ums 0 mmc 1.1,1.2 UMS: LUN 0, dev mmc 1, hwpart 1, sector 0x0, count 0x2000 UMS: LUN 1, dev mmc 1, hwpart 2, sector 0x0, count 0x2000 " Read of the two block devices on host without this fix produces identical data present in HW BOOT partition 2: " $ dd if=/dev/sdX of=mmc-a.bin ; dd if=/dev/sdY of=mmc-b.bin $ hexdump -C mmc-a.bin | tail -n 3 | head -n 1 ; \ hexdump -C mmc-b.bin | tail -n 3 | head -n 1 003ffe00 ef 90 78 56 ef 90 78 56 ef 90 78 56 ef 90 78 56 |..xV..xV..xV..xV| 003ffe00 ef 90 78 56 ef 90 78 56 ef 90 78 56 ef 90 78 56 |..xV..xV..xV..xV| " Read of the two block devices on host with this fix produces the expected distinct data from either HW BOOT partition 1 or 2: " $ dd if=/dev/sdX of=mmc-a.bin ; dd if=/dev/sdY of=mmc-b.bin $ hexdump -C mmc-a.bin | tail -n 3 | head -n 1 ; \ hexdump -C mmc-b.bin | tail -n 3 | head -n 1 003ffe00 cd ab 34 12 cd ab 34 12 cd ab 34 12 cd ab 34 12 |..4...4...4...4.| 003ffe00 ef 90 78 56 ef 90 78 56 ef 90 78 56 ef 90 78 56 |..xV..xV..xV..xV| " Reported-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by: Marek Vasut <marex@nabladev.com> Reviewed-by: Simon Glass <sjg@chromium.org>

Add a bootmeth that finds and boots Boot Loader Specification (BLS) type #1 entry files [1]. On each block-device partition it scans, the bootmeth looks for files matching '<prefix>loader/entries/*.conf' (where <prefix> comes from bootstd_get_prefixes(), typically '/' and '/boot/'), picks the highest-sorting filename, parses it, and exposes it as a bootflow. Implementation reuses the existing pxelinux infrastructure. For now the entry chosen on a partition is purely the lexicographic maximum of *.conf filenames; sort-key / version field handling (spec-mandated tiebreakers) and boot-counting (the '+TRIES_LEFT' filename suffix) are left as TODOs. Likewise, only the top-sorted entry is surfaced because the bootstd framework currently allows one bootflow per (bootmeth, partition); exposing every discovered entry will require a framework extension. The driver takes no number prefix, unlike bootmeth_1extlinux and bootmeth_2script which carry one to pin the ordering the old distro boot scripts had. BLS has no such legacy to preserve, so leave the choice to boards via 'bootmeths' or the devicetree. Type #2 BLS (drop-in directory of EFI binaries) is out of scope here; existing EFI bootmeths cover that use case. Link: https://uapi-group.org/specifications/specs/boot_loader_specification/ [1] Signed-off-by: Alexey Charkov <alchark@flipper.net> [trini: Rephrase a commit to avoid adding UTF-16 characters] Signed-off-by: Tom Rini <trini@konsulko.com>

Make verbose DRAM layout print on boot configurable via newly introduced CONFIG_DISPLAY_DRAM_CONFIG_VERBOSE Kconfig option. This reuses existing DRAM layout debug print, but with additional rework to place the output at the end of DRAM size listing, print both bank start and end addresses, and skip empty banks. In case DEBUG is defined, the DRAM layout print is triggered unconditionally. The original debug print looked as follows, which puts the layout print between DRAM: size announcement (1) and duplicate DRAM: size print (2), does not skip empty banks (3), and does not print DRAM bank end (4). " Model: Renesas Ironhide board based on r8a78000 DRAM: <----------------------------------------------------------- (1) RAM Configuration: Bank #0: 1080000000 2 GiB Bank #1: 1200000000 4 GiB <---------------------------------------- (4) ... Bank u-boot#8: 40000000 2 GiB Bank u-boot#9: 0 0 Bytes <----------------------------------------------- (3) ... Bank u-boot#15: 0 0 Bytes DRAM: 2 GiB (total 32 GiB) <-------------------------------------- (2) Core: 68 devices, 26 uclasses, devicetree: separate " The new debug print and optionally verbose print looks as follows, the duplicate DRAM: prefix is removed (1), the layout is printed after the DRAM size print (3), the DRAM end address is printed (3) and there are no more empty banks printed (4): " Model: Renesas Ironhide board based on r8a78000 DRAM: 2 GiB (total 32 GiB) <-------------------------------------- (1) RAM Configuration: <----------------------------------------------- (2) Bank #0: 0x1080000000 - 0x10ffffffff, 2 GiB <---------------------- (4) Bank #1: 0x1200000000 - 0x12ffffffff, 4 GiB Bank #2: 0x1400000000 - 0x14ffffffff, 4 GiB Bank #3: 0x1600000000 - 0x16ffffffff, 4 GiB Bank #4: 0x1800000000 - 0x18ffffffff, 4 GiB Bank #5: 0x1a00000000 - 0x1affffffff, 4 GiB Bank #6: 0x1c00000000 - 0x1cffffffff, 4 GiB Bank u-boot#7: 0x1e00000000 - 0x1effffffff, 4 GiB Bank u-boot#8: 0x40000000 - 0xbfffffff, 2 GiB <-------------------------- (3) Core: 68 devices, 26 uclasses, devicetree: separate " Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Add support to run 800Mhz speed grade parts at 650MHz

228348b

ST-dot-com closed this Dec 4, 2022

Navigation Menu

Repository navigation

Add support to run 800Mhz speed grade parts at 650MHz - #2

Add support to run 800Mhz speed grade parts at 650MHz#2
neerajdantu wants to merge 1 commit into
STMicroelectronics:v2021.10-stm32mpfrom
octavosystems:octavo-opp

neerajdantu commented Dec 4, 2022

Uh oh!

ST-dot-com commented Dec 4, 2022

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

neerajdantu commented Dec 4, 2022

Uh oh!

ST-dot-com commented Dec 4, 2022

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants