June 2023 - U-Boot

[PATCH 1/1] cmd: loads man-page
by Heinrich Schuchardt 26 Jun '23

26 Jun '23

Provide a man-page for the loads command. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- doc/usage/cmd/loads.rst | 96 +++++++++++++++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + 2 files changed, 97 insertions(+) create mode 100644 doc/usage/cmd/loads.rst diff --git a/doc/usage/cmd/loads.rst b/doc/usage/cmd/loads.rst new file mode 100644 index 0000000000..5dd0ed70b6 --- /dev/null +++ b/doc/usage/cmd/loads.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +loads command +============= + +Synopsis +-------- + +:: + + loads [offset [baud]] + +Description +----------- + +The loads command is used to transfer a file to the device via the serial line +using the Motorola S-record file format. + +offset + offset added to the addresses in the S-record file + +baud + baud rate to use for download. This parameter is only available if + CONFIG_SYS_LOADS_BAUD_CHANGE=y + +Example +------- + +As example file to be transferred we use a script printing 'hello s-record'. +Here are the commands to create the S-record file: + +.. code-block:: bash + + $ echo 'echo hello s-record' > script.txt + $ mkimage -T script -d script.txt script.scr + Image Name: + Created: Sun Jun 25 10:35:02 2023 + Image Type: PowerPC Linux Script (gzip compressed) + Data Size: 28 Bytes = 0.03 KiB = 0.00 MiB + Load Address: 00000000 + Entry Point: 00000000 + Contents: + Image 0: 20 Bytes = 0.02 KiB = 0.00 MiB + $ srec_cat script.scr -binary -CRLF -Output script.srec + $ echo -e "S9030000FC\r" >> script.srec + $ cat script.srec + S0220000687474703A2F2F737265636F72642E736F75726365666F7267652E6E65742F1D + S1230000270519566D773EB6649815E30000001700000000000000003DE3D97005070601E2 + S12300200000000000000000000000000000000000000000000000000000000000000000BC + S11A00400000000F0000000068656C6C6F20732D7265636F72640A39 + S5030003F9 + S9030000FC + $ + +The load address in the first S1 record is 0x0000. + +The terminal emulation program picocom is invoked with *cat* as the send +command to transfer the file. + +.. code-block:: + + picocom --send-cmd 'cat' --baud 115200 /dev/ttyUSB0 + +After entering the *loads* command the key sequence <CTRL-A><CTRL-S> is used to +let picocom prompt for the file name. Picocom invokes the program *cat* for the +file transfer. The loaded script is executed using the *source* command. + +.. code-block:: + + => loads $scriptaddr + ## Ready for S-Record download ... + + *** file: script.srec + $ cat script.srec + + *** exit status: 0 *** + + ## First Load Addr = 0x4FC00000 + ## Last Load Addr = 0x4FC0005B + ## Total Size = 0x0000005C = 92 Bytes + ## Start Addr = 0x00000000 + => source $scriptaddr + ## Executing script at 4fc00000 + hello s-record + => + +Configuration +------------- + +The command is only available if CONFIG_CMD_LOADS=y. The parameter to set the +baud rate is only available if CONFIG_SYS_LOADS_BAUD_CHANGE=y + +Return value +------------ + +The return value $? is 0 (true) on success, 1 (false) otherwise. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 29ae8a176e..ef3e87fed0 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -68,6 +68,7 @@ Shell commands cmd/load cmd/loadb cmd/loadm + cmd/loads cmd/loadx cmd/loady cmd/mbr -- 2.40.1

2 1

[PATCH 1/1] doc: bind man-page
by Heinrich Schuchardt 26 Jun '23

26 Jun '23

provide a man-page for the bind command Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- doc/usage/cmd/bind.rst | 103 +++++++++++++++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + 2 files changed, 104 insertions(+) create mode 100644 doc/usage/cmd/bind.rst diff --git a/doc/usage/cmd/bind.rst b/doc/usage/cmd/bind.rst new file mode 100644 index 0000000000..1a5cffcb72 --- /dev/null +++ b/doc/usage/cmd/bind.rst @@ -0,0 +1,103 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +bind command +============ + +Synopsis +-------- + +:: + + bind <node path> <driver> + bind <class> <index> <driver> + +Description +----------- + +The bind command is used to bind a device to a driver. This makes the +device available in U-Boot. + +While binding to a *node path* typically provides a working device +binding by parent node and driver may lead to a device that is only +partially initialized. + +node path + path of the device's device-tree node + +class + device class name + +index + index of the parent device in the device class + +driver + device driver name + +Example +------- + +Given a system with a real time clock device with device path */pl031@9010000* +and using driver rtc-pl031 unbinding and binding of the device is demonstrated +using the two alternative bind syntaxes. + +.. code-block:: + + => dm tree + Class Index Probed Driver Name + ----------------------------------------------------------- + root 0 [ + ] root_driver root_driver + ... + rtc 0 [ ] rtc-pl031 |-- pl031@9010000 + ... + => fdt addr $fdtcontroladdr + Working FDT set to 7ed7fdb0 + => fdt print + / { + interrupt-parent = <0x00008003>; + model = "linux,dummy-virt"; + #size-cells = <0x00000002>; + #address-cells = <0x00000002>; + compatible = "linux,dummy-virt"; + ... + pl031@9010000 { + clock-names = "apb_pclk"; + clocks = <0x00008000>; + interrupts = <0x00000000 0x00000002 0x00000004>; + reg = <0x00000000 0x09010000 0x00000000 0x00001000>; + compatible = "arm,pl031", "arm,primecell"; + }; + ... + } + => unbind /pl031@9010000 + => date + Cannot find RTC: err=-19 + => dm tree + Class Index Probed Driver Name + ----------------------------------------------------------- + root 0 [ + ] root_driver root_driver + ... + => bind /pl031@9010000 rtc-pl031 + => dm tree + Class Index Probed Driver Name + ----------------------------------------------------------- + root 0 [ + ] root_driver root_driver + ... + rtc 0 [ ] rtc-pl031 |-- pl031@9010000 + => date + Date: 2023-06-22 (Thursday) Time: 15:14:51 + => unbind rtc 0 rtc-pl031 + => bind root 0 rtc-pl031 + => date + Date: 1980-08-19 (Tuesday) Time: 14:45:30 + +Obviously the device is not initialized correctly by the last bind command. + +Configuration +------------- + +The bind command is only available if CONFIG_CMD_BIND=y. + +Return code +----------- + +The return code $? is 0 (true) on success and 1 (false) on failure. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 95532782e0..a11c5756f0 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -25,6 +25,7 @@ Shell commands cmd/askenv cmd/base cmd/bdinfo + cmd/bind cmd/blkcache cmd/bootd cmd/bootdev -- 2.40.1

2 1

Re: [PATCH 2/6] ARM: at91: Switch sama5d2_icp_mmc to simple malloc in SPL
by Tom Rini 26 Jun '23

26 Jun '23

On Sat, Jun 24, 2023 at 12:34:54AM +0200, Marek Vasut wrote: > To avoid SRAM overflow in the SPL build, use simple malloc implementation. > > Signed-off-by: Marek Vasut <marex(a)denx.de> Applied to u-boot/master, thanks! -- Tom

2 1

Re:[PATCH] mmc:Remove thr legacy mode clock setting operation
by 谢飞 26 Jun '23

26 Jun '23

Hi，Peng.： Has you meet any issues without removing this line? or this is just code inpsection? In practical use, when some EMMC particles switch to the hs mode below, an error message cmd8 may appear. The reason for this is that the clock operation of setting the legacy mode was performed before switching to the hs mode, which caused the clock to switch too early. At this time, the communication between the host and card is abnormal That is to say, switching the clocks of the host and card to high speed before switching to hs mode can cause communication issues between the host and card BTW the upper "else" will met issue if you directly remove this line. Delete this line directly. There will indeed be issues with the else above. I did not find it on my end because I did not open the compilation macro definition above. This is the patch I resubmitted Best wishes Thanks 在 2023-06-26 16:59:42，xf_hqu@163.com 写道： >From: xiefei <xf_hqu(a)163.com> > >Due to the need to read the register value before >switching to hs mode, the standard protocol does >not explicitly specify that the setting before >switching to hs mode is in legacy mode. Therefore, >the code at this point may cause communication >abnormalities between the host and card > >Signed-off-by: xiefei <xf_hqu(a)163.com> >--- > drivers/mmc/mmc.c | 2 -- > 1 file changed, 2 deletions(-) > >diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c >index 1af6af82e6..96cc7e7332 100644 >--- a/drivers/mmc/mmc.c >+++ b/drivers/mmc/mmc.c >@@ -2136,9 +2136,7 @@ static int mmc_select_mode_and_width(struct mmc *mmc, uint card_caps) > mmc->selected_mode == MMC_HS_400 || > mmc->selected_mode == MMC_HS_400_ES) > mmc_set_card_speed(mmc, MMC_HS, true); >- else > #endif >- mmc_set_clock(mmc, mmc->legacy_speed, MMC_CLK_ENABLE); > > for_each_mmc_mode_by_pref(card_caps, mwt) { > for_each_supported_width(card_caps & mwt->widths, >-- >2.17.1

1 0

Re:[PATCH] mmc:Remove thr legacy mode clock setting operation
by 谢飞 26 Jun '23

26 Jun '23

Hi，Peng.： Has you meet any issues without removing this line? or this is just code inpsection? In practical use, when some EMMC particles switch to the hs mode below, an error message cmd8 may appear. The reason for this is that the clock operation of setting the legacy mode was performed before switching to the hs mode, which caused the clock to switch too early. At this time, the communication between the host and card is abnormal That is to say, switching the clocks of the host and card to high speed before switching to hs mode can cause communication issues between the host and card BTW the upper "else" will met issue if you directly remove this line. Delete this line directly. There will indeed be issues with the else above. I did not find it on my end because I did not open the compilation macro definition above. This is the patch I resubmitted Best wishes Thanks At 2023-06-26 14:54:47, xf_hqu(a)163.com wrote: >From: xiefei <xf_hqu(a)163.com> > >Due to the need to read the register value before >switching to hs mode, the standard protocol does >not explicitly specify that the setting before >switching to hs mode is in legacy mode. Therefore, >the code at this point may cause communication >abnormalities between the host and card > >Signed-off-by: xiefei <xf_hqu(a)163.com> >--- > drivers/mmc/mmc.c | 2 -- > 1 file changed, 2 deletions(-) > >diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c >index 1af6af82e6..96cc7e7332 100644 >--- a/drivers/mmc/mmc.c >+++ b/drivers/mmc/mmc.c >@@ -2136,9 +2136,7 @@ static int mmc_select_mode_and_width(struct mmc *mmc, uint card_caps) > mmc->selected_mode == MMC_HS_400 || > mmc->selected_mode == MMC_HS_400_ES) > mmc_set_card_speed(mmc, MMC_HS, true); >- else > #endif >- mmc_set_clock(mmc, mmc->legacy_speed, MMC_CLK_ENABLE); > > for_each_mmc_mode_by_pref(card_caps, mwt) { > for_each_supported_width(card_caps & mwt->widths, >-- >2.17.1

1 0

[PATCH] arch: arm: dts: k3-am625-sk: Update timings node name for panel-lvds
by Nikhil M Jain 26 Jun '23

26 Jun '23

Update the name of timing parameter node to panel-timing from panel-timngs. Signed-off-by: Nikhil M Jain <n-jain1(a)ti.com> --- arch/arm/dts/k3-am625-sk.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/k3-am625-sk.dts b/arch/arm/dts/k3-am625-sk.dts index 73dec8781c..a87b48bfed 100644 --- a/arch/arm/dts/k3-am625-sk.dts +++ b/arch/arm/dts/k3-am625-sk.dts @@ -168,7 +168,7 @@ width-mm = <217>; height-mm = <136>; data-mapping = "vesa-24"; - panel-timings { + panel-timing { bootph-pre-ram; clock-frequency = <150274>; hactive = <1920>; -- 2.34.1

2 2

[PATCH] clk: sifive: only build sifive-prci.o for CONFIG_CLK_SIFIVE_PRCI
by Ben Dooks 26 Jun '23

26 Jun '23

If we're building non FU540/FU740 SoC drivers, then the sifive-prci.o is not needed. Only build this when CONFIG_CLK_SIFIVE_PRCI is selected. Signed-off-by: Ben Dooks <ben.dooks(a)sifive.com> --- drivers/clk/sifive/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile index 51348b1ddc..84859d92ab 100644 --- a/drivers/clk/sifive/Makefile +++ b/drivers/clk/sifive/Makefile @@ -1,5 +1,3 @@ # SPDX-License-Identifier: GPL-2.0+ -obj-y += sifive-prci.o - -obj-$(CONFIG_CLK_SIFIVE_PRCI) += fu540-prci.o fu740-prci.o +obj-$(CONFIG_CLK_SIFIVE_PRCI) += sifive-prci.o fu540-prci.o fu740-prci.o -- 2.39.2

2 1

Re: [PATCH v2 1/3] riscv: timer: Update the sifive clint timer driver to support aclint
by Rick Chen 26 Jun '23

26 Jun '23

> From: Bin Meng <bmeng(a)tinylab.org> > Sent: Wednesday, June 21, 2023 11:12 PM > To: u-boot(a)lists.denx.de > Cc: Anup Patel <anup(a)brainfault.org>; Atish Patra <atishp(a)atishpatra.org>; Bin Meng <bmeng.cn(a)gmail.com>; Palmer Dabbelt <palmer(a)dabbelt.com>; Paul Walmsley <paul.walmsley(a)sifive.com>; Rick Jian-Zhi Chen(陳建志) <rick(a)andestech.com> > Subject: [PATCH v2 1/3] riscv: timer: Update the sifive clint timer driver to support aclint > > This RISC-V ACLINT specification [1] defines a set of memory mapped devices which provide inter-processor interrupts (IPI) and timer functionalities for each HART on a multi-HART RISC-V platform. > > The RISC-V ACLINT specification is defined to be backward compatible with the SiFive CLINT specification, however the device tree binding is a new one. This change updates the sifive clint timer driver to support ACLINT mtimer device, using a per-driver data field to hold the mtimer offset to the base address encoded in the mtimer node. > > [1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc > > Signed-off-by: Bin Meng <bmeng(a)tinylab.org> > > --- > > Changes in v2: > - drop ae350.h changes > > drivers/timer/sifive_clint_timer.c | 16 +++++++++++----- > include/configs/qemu-riscv.h | 2 +- > include/configs/sifive-unleashed.h | 2 +- > include/configs/starfive-visionfive2.h | 1 + > 4 files changed, 14 insertions(+), 7 deletions(-) Reviewed-by: Rick Chen <rick(a)andestech.com>

1 0

[PATCH v2 0/7] Enable DM_SERIAL for the LS104xA RDB/FRWY boards
by Camelia Groza 26 Jun '23

26 Jun '23

This series enables DM_SERIAL for ls1043ardb, ls1046ardb and ls1046afrwy. First, the device tree serial nodes are synced with their counterpart descriptions in Linux v6.3. Secondly, the serial nodes are tagged with 'bootph-all' to guarantee the drivers are initialized before relocation. New board specific *-u-boot.dtsi files are created to store these properties. We do this in order to keep serial node descriptions in sync with Linux. Lastly, CONFIG_DM_SERIAL is enabled in the relevant defconfigs. Changes in v2: - mention the Linux kernel version the serial nodes are synced with in 1/7 and 4/7 - create *-u-boot.dtsi files to store u-boot specific dts properties in 2/7 and 5/7 - pick up the status properties of the serial nodes from Linux in 4/7 Camelia Groza (7): arch: arm: dts: ls1043a: sync serial nodes with Linux arch: arm: dts: ls1043a: tag serial nodes with bootph-all configs: ls1043ardb: enable DM_SERIAL arch: arm: dts: ls1046a: sync serial nodes with Linux arch: arm: dts: ls1046a: tag serial nodes with bootph-all configs: ls1046ardb: enable DM_SERIAL configs: ls1046afrwy: enable DM_SERIAL arch/arm/dts/fsl-ls1043a-qds.dtsi | 2 +- arch/arm/dts/fsl-ls1043a-rdb-u-boot.dtsi | 5 ++++ arch/arm/dts/fsl-ls1043a-rdb.dts | 6 +++- arch/arm/dts/fsl-ls1043a-u-boot.dtsi | 19 +++++++++++++ arch/arm/dts/fsl-ls1043a.dtsi | 16 +++++++---- arch/arm/dts/fsl-ls1046a-frwy-u-boot.dtsi | 5 ++++ arch/arm/dts/fsl-ls1046a-frwy.dts | 22 ++++++++++++++- arch/arm/dts/fsl-ls1046a-qds.dtsi | 2 +- arch/arm/dts/fsl-ls1046a-rdb-u-boot.dtsi | 5 ++++ arch/arm/dts/fsl-ls1046a-rdb.dts | 14 +++++++++- arch/arm/dts/fsl-ls1046a-u-boot.dtsi | 19 +++++++++++++ arch/arm/dts/fsl-ls1046a.dtsi | 28 +++++++++++++------ configs/ls1043ardb_SECURE_BOOT_defconfig | 4 ++- configs/ls1043ardb_defconfig | 4 ++- configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 4 ++- configs/ls1043ardb_nand_defconfig | 3 +- .../ls1043ardb_sdcard_SECURE_BOOT_defconfig | 4 ++- configs/ls1043ardb_sdcard_defconfig | 3 +- configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 4 ++- configs/ls1043ardb_tfa_defconfig | 4 ++- configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig | 4 ++- configs/ls1046afrwy_tfa_defconfig | 4 ++- configs/ls1046ardb_emmc_defconfig | 3 +- configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 4 ++- configs/ls1046ardb_qspi_defconfig | 4 ++- configs/ls1046ardb_qspi_spl_defconfig | 3 +- .../ls1046ardb_sdcard_SECURE_BOOT_defconfig | 4 ++- configs/ls1046ardb_sdcard_defconfig | 3 +- configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 4 ++- configs/ls1046ardb_tfa_defconfig | 4 ++- 30 files changed, 173 insertions(+), 37 deletions(-) create mode 100644 arch/arm/dts/fsl-ls1043a-rdb-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-ls1043a-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-ls1046a-frwy-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-ls1046a-rdb-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-ls1046a-u-boot.dtsi -- 2.17.1

2 8

imx8m optee load address?
by Tim Harvey 26 Jun '23

26 Jun '23

Greetings, I've seen several IMX8M boards include a firmware/optee node in the U-Boot dt (git grep optee arch/arm/dts/imx8m*.dtsi) yet but none that I see configure binman to actually add the binary in the u-boot.dtsi, do anything to keep U-Boot from accessing the OPTEE memory, or document how to configure and build OPTEE for imx8m. I would like to add such support but I find it odd that OPTEE needs to be built differently depending on the dram size. Prior to switching to binman (v2021.10) arch/arm/mach-imx/mkimage_fit_atf.sh [1] would include tee.bin in the FIT image if it was found in the current directory and it was expected that you provide a proper TEE_LOAD_ADDR via the env (commit a9eed6e1b8d8 ("imx: imx8m: introduce script to generate fit image"). According to the IMX OPTEE documentation [2] the size and location of OPTEE is hard coded (CFG_TZDRAM_START and CFG_TZDRAM_SIZE) but looking at the imx-optee source [3] this is calculated based off of CFG_DDR_SIZE (which you can provide via env at build time or just provide CFG_TZDRAM_START and CFG_TZDRAM_SIZE via env directly). This results in the OPTEE location of 0x7e000000 for 1GiB systems, 0xbe000000 for 2GiB systems, and 0x13e000000 for 4GiB systems for example. This dependence on dram size causes a couple of issues: - OPTEE location depends on build-time configuration and several boards have run-time identification of their memory size - for 4GiB systems the address 0x13e000000 crosses the 32bit address boundary and U-Boot hangs Is there any reason OPTEE can't be located wherever you want and not depend on dram size? I've tried to set it to 0x7e000000 (for a 1GiB board) on a 4GiB board and U-Boot hangs near the DRAM banner which is likely due to get_ram_size() stepping on OPTEE's memory range but then I'm not clear why that doesn't occur when OPTEE is located at the top of dram on a 1GiB and 2GiB system. How would I go about adding a carevout for this? Best Regards, Tim [1] https://elixir.bootlin.com/u-boot/v2021.10/source/arch/arm/mach-imx/mkimage… [2] https://www.nxp.com/docs/en/user-guide/IMX_PORTING_GUIDE.pdf [3] https://github.com/nxp-imx/imx-optee-os

3 6