Re: [U-Boot] [PATCH] omap34xx: SPL: enable MMC raw boot with u-boot.img
On 10/11/19 6:18 AM, Denis 'GNUtoo' Carikli wrote:
> The following commit enabled raw SPL booting:
> 22d90d560a omap3: Use raw SPL by default for mmc1
> but it was reverted by the following commit:
> 821c89d38c Revert "omap3: Use raw SPL by default for mmc1"
> because SPL is unable to distinguish between RAW images and
> garbage.
>
> However if CONFIG_SPL_RAW_IMAGE_SUPPORT is disabled, SPL does
> identify if there is a valid image with spl_parse_image_header.
>
> With this change, and CONFIG_SPL_RAW_IMAGE_SUPPORT disabled,
> raw MMC boot will be tried first, and if it fails, it FS will
> be tried.
This means that if FS boot is required then SPL_RAW_IMAGE_SUPPORT should be
disabled. So with this patch applied, the default omap3_defconfig will fail to
boot with FS mode. It is difficult to support this unless ROM passes some
information on the bootmode.
Thanks and regards,
Lokesh
>
> The two scenarios have been tested on a BeagleBoard XM Revision C1.
>
> Signed-off-by: Denis 'GNUtoo' Carikli
> ---
> arch/arm/mach-omap2/boot-common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/boot-common.c
> b/arch/arm/mach-omap2/boot-common.c
> index 734fa9d9e6..a48244e1c5 100644
> --- a/arch/arm/mach-omap2/boot-common.c
> +++ b/arch/arm/mach-omap2/boot-common.c
> @@ -132,8 +132,10 @@ void save_omap_boot_params(void)
> (boot_device <= MMC_BOOT_DEVICES_END)) {
> switch (boot_device) {
> case BOOT_DEVICE_MMC1:
> +#ifdef CONFIG_SPL_RAW_IMAGE_SUPPORT
> boot_mode = MMCSD_MODE_FS;
> break;
> +#endif
> case BOOT_DEVICE_MMC2:
> boot_mode = MMCSD_MODE_RAW;
> break;
>
Re: [PATCH v2 00/21] Refactor the architecture parts of mt7628
On Mon, 2020-01-20 at 08:08 +0100, Stefan Roese wrote: > Hi Weijie, > > On 19.01.20 03:12, Weijie Gao wrote: > > On Fri, 2020-01-17 at 15:40 +0100, Stefan Roese wrote: > >> Hi Weijie, > >> > >> I've added another of my mail addresses to cc (m...@roese.nl) as the > >> sending to the other 2 addresses does not seem to work. > >> > >> On 17.01.20 08:45, Weijie Gao wrote: > >>> This patch series are divided into two parts: > >>> > >>> The main part is to rewrite the whole architecture code of mt7628: > >>> 1. Lock parts of the d-cache for initial stack so the rest of the code can > >>> be reimplemented in C. > >>> 2. Memory controller & DDR initialization have been fully written to > >>> support > >>> detecting DDR size automatically. > >>> 3. DDR calibration has also been reimplemented with a clear logic. > >>> 4. Implemented a new sysreset driver to take advantage of the reset > >>> controller so we can drop the use of syscon-based sysreset to reduce > >>> size. > >>> > >>> The second part is to add SPL support for mt7628: > >>> 1. With SPL enabled we can build the ROM-bootable and RAM-bootable binary > >>> simultaneously, and we can drop RAM boot related configs and > >>> defconfig > >>> files. > >>> 2. Generate compressed u-boot.bin image for SPL to reduce size of final > >>> combined binary. > >>> 3. Enable DM support for SPL for a more flexible device probing. > >>> 4. Add a demo board (mt7628_rfb) aims at router application. > >>> > >>> Changes since v1: > >>> 1. Split 'mips: mtmips: rewrite lowlevel codes of mt7628' into multiple > >>> patches. > >>> 2. Dropped a patch which tried to use customized get_tbclk(). > >>> 3. Dropped a patch which tried to rename mt7628a.dtsi to mt7628.dtsi > >>> 4. Refactor the patch which restores exception vector base before booting > >>> linux. > >>> 5. Define a new option to enable u_boot_list in SPL. > >>> 6. Enable compressed spl payload for all boards. > >>> 7. Enable DM and DT support for linkit and gardena-smart-gateway. > >>> 8. Complete pinmux for all three UARTs for SPL. > >>> 9. Rewrite u_boot_lzma_img.py. > >>> > >>> Weijie Gao (21): > >> > >> It seems that patch 09/21 is missing on the list. Is it stuck in > >> moderation? Or is the patch numbering corrupt? > >> > >> Thanks, > >> Stefan > > > > It's missing on my list. I've resent it. > > Thanks. Applying this patchset on top of current mainline results in > this compilation error (using linkit-smart-7688_defconfig): > > arch/mips/mach-mtmips/built-in.o: In function `get_tbclk': > /home/stefan/git/u-boot/u-boot/arch/mips/mach-mtmips/mt7628/init.c:108: > multiple definition of `get_tbclk' > arch/mips/cpu/built-in.o:/home/stefan/git/u-boot/u-boot/arch/mips/cpu/time.c:18: > first defined here > make: *** [Makefile:1695: u-boot] Error 1 > > Is something else missing? > > Thanks, > Stefan Daniel said he has merged a patch which makes the original get_tbclk weak (arch/mips/cpu/time.c), and let me drop a related patch. https://patchwork.ozlabs.org/patch/1215073/ I haven't seen it shown in mainline yet.
Re: [PATCH v2 00/21] Refactor the architecture parts of mt7628
On 20.01.20 08:08, Stefan Roese wrote: Hi Weijie, On 19.01.20 03:12, Weijie Gao wrote: On Fri, 2020-01-17 at 15:40 +0100, Stefan Roese wrote: Hi Weijie, I've added another of my mail addresses to cc (m...@roese.nl) as the sending to the other 2 addresses does not seem to work. On 17.01.20 08:45, Weijie Gao wrote: This patch series are divided into two parts: The main part is to rewrite the whole architecture code of mt7628: 1. Lock parts of the d-cache for initial stack so the rest of the code can be reimplemented in C. 2. Memory controller & DDR initialization have been fully written to support detecting DDR size automatically. 3. DDR calibration has also been reimplemented with a clear logic. 4. Implemented a new sysreset driver to take advantage of the reset controller so we can drop the use of syscon-based sysreset to reduce size. The second part is to add SPL support for mt7628: 1. With SPL enabled we can build the ROM-bootable and RAM-bootable binary simultaneously, and we can drop RAM boot related configs and defconfig files. 2. Generate compressed u-boot.bin image for SPL to reduce size of final combined binary. 3. Enable DM support for SPL for a more flexible device probing. 4. Add a demo board (mt7628_rfb) aims at router application. Changes since v1: 1. Split 'mips: mtmips: rewrite lowlevel codes of mt7628' into multiple patches. 2. Dropped a patch which tried to use customized get_tbclk(). 3. Dropped a patch which tried to rename mt7628a.dtsi to mt7628.dtsi 4. Refactor the patch which restores exception vector base before booting linux. 5. Define a new option to enable u_boot_list in SPL. 6. Enable compressed spl payload for all boards. 7. Enable DM and DT support for linkit and gardena-smart-gateway. 8. Complete pinmux for all three UARTs for SPL. 9. Rewrite u_boot_lzma_img.py. Weijie Gao (21): It seems that patch 09/21 is missing on the list. Is it stuck in moderation? Or is the patch numbering corrupt? Thanks, Stefan It's missing on my list. I've resent it. Thanks. Applying this patchset on top of current mainline results in this compilation error (using linkit-smart-7688_defconfig): arch/mips/mach-mtmips/built-in.o: In function `get_tbclk': /home/stefan/git/u-boot/u-boot/arch/mips/mach-mtmips/mt7628/init.c:108: multiple definition of `get_tbclk' arch/mips/cpu/built-in.o:/home/stefan/git/u-boot/u-boot/arch/mips/cpu/time.c:18: first defined here make: *** [Makefile:1695: u-boot] Error 1 Is something else missing? Okay, I think I found it. This patch here is missing: https://patchwork.ozlabs.org/patch/1215073/ Thanks, Stefan
Re: [PATCH v2 00/21] Refactor the architecture parts of mt7628
Hi Weijie, On 19.01.20 03:12, Weijie Gao wrote: On Fri, 2020-01-17 at 15:40 +0100, Stefan Roese wrote: Hi Weijie, I've added another of my mail addresses to cc (m...@roese.nl) as the sending to the other 2 addresses does not seem to work. On 17.01.20 08:45, Weijie Gao wrote: This patch series are divided into two parts: The main part is to rewrite the whole architecture code of mt7628: 1. Lock parts of the d-cache for initial stack so the rest of the code can be reimplemented in C. 2. Memory controller & DDR initialization have been fully written to support detecting DDR size automatically. 3. DDR calibration has also been reimplemented with a clear logic. 4. Implemented a new sysreset driver to take advantage of the reset controller so we can drop the use of syscon-based sysreset to reduce size. The second part is to add SPL support for mt7628: 1. With SPL enabled we can build the ROM-bootable and RAM-bootable binary simultaneously, and we can drop RAM boot related configs and defconfig files. 2. Generate compressed u-boot.bin image for SPL to reduce size of final combined binary. 3. Enable DM support for SPL for a more flexible device probing. 4. Add a demo board (mt7628_rfb) aims at router application. Changes since v1: 1. Split 'mips: mtmips: rewrite lowlevel codes of mt7628' into multiple patches. 2. Dropped a patch which tried to use customized get_tbclk(). 3. Dropped a patch which tried to rename mt7628a.dtsi to mt7628.dtsi 4. Refactor the patch which restores exception vector base before booting linux. 5. Define a new option to enable u_boot_list in SPL. 6. Enable compressed spl payload for all boards. 7. Enable DM and DT support for linkit and gardena-smart-gateway. 8. Complete pinmux for all three UARTs for SPL. 9. Rewrite u_boot_lzma_img.py. Weijie Gao (21): It seems that patch 09/21 is missing on the list. Is it stuck in moderation? Or is the patch numbering corrupt? Thanks, Stefan It's missing on my list. I've resent it. Thanks. Applying this patchset on top of current mainline results in this compilation error (using linkit-smart-7688_defconfig): arch/mips/mach-mtmips/built-in.o: In function `get_tbclk': /home/stefan/git/u-boot/u-boot/arch/mips/mach-mtmips/mt7628/init.c:108: multiple definition of `get_tbclk' arch/mips/cpu/built-in.o:/home/stefan/git/u-boot/u-boot/arch/mips/cpu/time.c:18: first defined here make: *** [Makefile:1695: u-boot] Error 1 Is something else missing? Thanks, Stefan
Re: [PATCH v2 00/10] ClearFog Base static variant support
Hi Joel, On 19.01.20 17:16, Joel Johnson wrote: On 2020-01-19 09:11, Baruch Siach wrote: Hi Joel, On Sun, Jan 19 2020, Joel Johnson wrote: On 2020-01-19 01:38, Baruch Siach wrote: On Sun, Jan 19 2020, Joel Johnson wrote: This patch series adds support for ClearFog Base static configuration, as well as updating and fixing the ClearFog support for MMC and SPI booting. V2 changes: - updated against, and dependent on, https://patchwork.ozlabs.org/cover/1200324 Thanks for the update. Next time please Cc at least me and Stefan on the entire series. baruch I certainly intended to, and based on the email headers it appears that I did... Actually, I see what you're saying, not all of the patches in the series were delivered to you. I neglected to add (or notice during sending) the Series-cc line for patman. My apologizes - I've added it for my local branch on this series and I'll keep an eye out for that in the future. Relatedly, I've been directing the series to Prafulla Wadaskar as noted in the custodians listing for marvell, but am getting email delivery failures. Any updated guidance or contact updates would be appreciated. Prafulla has been removed from the Marvell entry in MAINTAINERS in commit 1579faf52b9f4 (February 2019). I don't think you need to Cc him on Marvell SoC related patches. baruch Indeed, thanks. I had pulled his information from the Custodians wiki page at http://www.denx.de/wiki/U-Boot/Custodians, so perhaps something that Stefan or editor can update accordingly. Yes, thanks for the notification. We'll update this page accordingly soon. Thanks, Stefan
Re: [U-Boot] [PATCH] arm: zynq: zybo z7: fix MIO init issue
On 20. 01. 20 2:33, Luis Araneda wrote:
> From: Milan Obuch
>
> The board has two push button connected to MIO pins
> 50 and 51, which have a pull-down resistor and are
> connected to 1.8V when pressed.
>
> These two pins are wrongly initialized with internal
> pull-up enabled so they are reported as 1 all the time
> with no change when pressed.
>
> Disable the internal pull-up to fix the issue.
>
> Signed-off-by: Milan Obuch
> Signed-off-by: Luis Araneda
> ---
>
> This changes were originally sent by Milan Obuch using a diff format.
> As he didn't know how to properly send git patches to the mailing list,
> I converted them to a git commit, rephrased the commit message and added
> the Signed-off-by tags.
>
> Milan Obuch then review and approved the current state of the patch.
>
> Tested on a zybo z7-20 board by me
>
> board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
> b/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
> index 7c6bc9fa3f..a376ba574e 100644
> --- a/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
> +++ b/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
> @@ -219,8 +219,8 @@ static unsigned long ps7_mio_init_data_3_0[] = {
> EMIT_MASKWRITE(0xF80007BC, 0x3F01U, 0x1201U),
> EMIT_MASKWRITE(0xF80007C0, 0x3FFFU, 0x12E0U),
> EMIT_MASKWRITE(0xF80007C4, 0x3FFFU, 0x12E1U),
> - EMIT_MASKWRITE(0xF80007C8, 0x3FFFU, 0x1200U),
> - EMIT_MASKWRITE(0xF80007CC, 0x3FFFU, 0x1200U),
> + EMIT_MASKWRITE(0xF80007C8, 0x3FFFU, 0x0200U),
> + EMIT_MASKWRITE(0xF80007CC, 0x3FFFU, 0x0200U),
> EMIT_MASKWRITE(0xF80007D0, 0x3FFFU, 0x1280U),
> EMIT_MASKWRITE(0xF80007D4, 0x3FFFU, 0x1280U),
> EMIT_MASKWRITE(0xF8000830, 0x003F003FU, 0x002F0037U),
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
signature.asc
Description: OpenPGP digital signature
Re: [U-Boot] [PATCH] arm: zynq: zybo z7: fix SPL uart init bitrate
On 20. 01. 20 2:32, Luis Araneda wrote: > From: Milan Obuch > > The board uses 100 MHz clock for UART bitrate generator, > but is configured as 50 MHz on defconfig. > > This produces wrong console output. > The first message, "Debug uart enabled" is received as: > "��b" > > Fix the issue by configuring the correct clock for the > UART baudrate generator > > Signed-off-by: Milan Obuch > Signed-off-by: Luis Araneda > --- > > This changes were originally sent by Milan Obuch using a diff format. > As he didn't know how to properly send git patches to the mailing list, > I converted them to a git commit, rephrased the commit message and added > the Signed-off-by tags. > > Milan Obuch then review and approved the current state of the patch. > > Tested on a zybo z7-20 board by me > > configs/zynq_zybo_z7_defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configs/zynq_zybo_z7_defconfig b/configs/zynq_zybo_z7_defconfig > index 7129e2b5f3..f41d6574f7 100644 > --- a/configs/zynq_zybo_z7_defconfig > +++ b/configs/zynq_zybo_z7_defconfig > @@ -5,7 +5,7 @@ CONFIG_SYS_TEXT_BASE=0x400 > CONFIG_SPL_STACK_R_ADDR=0x20 > CONFIG_SPL=y > CONFIG_DEBUG_UART_BASE=0xe0001000 > -CONFIG_DEBUG_UART_CLOCK=5000 > +CONFIG_DEBUG_UART_CLOCK=1 > CONFIG_DEBUG_UART=y > CONFIG_DISTRO_DEFAULTS=y > CONFIG_SYS_CUSTOM_LDSCRIPT=y > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 9/9] doc: update FU540 RISC-V documentation
Hi Pragnesh > From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] > Sent: Friday, January 17, 2020 8:46 PM > To: u-boot@lists.denx.de > Cc: atish.pa...@wdc.com; palmerdabb...@google.com; bmeng...@gmail.com; > paul.walms...@sifive.com; ja...@amarulasolutions.com; > troy.benjeger...@sifive.com; anup.pa...@wdc.com; sagar.ka...@sifive.com; > Pragnesh Patel; Anup Patel; Rick Jian-Zhi Chen(陳建志) > Subject: [PATCH v2 9/9] doc: update FU540 RISC-V documentation > > Add descriptions about U-Boot SPL feature and how to build and run. > > Signed-off-by: Pragnesh Patel > --- > doc/board/sifive/fu540.rst | 370 + > 1 file changed, 370 insertions(+) > > diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst index > 3937222c6c..e15427414d 100644 > --- a/doc/board/sifive/fu540.rst > +++ b/doc/board/sifive/fu540.rst > @@ -363,3 +363,373 @@ load uImage. > > Please press Enter to activate this console. > / # > + > + > +Running U-Boot SPL > +-- > +The U-Boot SPL will boot in M mode and load the FIT image which include > +OpenSBI and U-Boot proper images. After loading progress, it will jump > +to OpenSBI first and then U-Boot proper which will run in S mode. > + > + > +How to build U-Boot SPL > +--- > +Before building U-Boot SPL, OpenSBI must be build first. OpenSBI can be > +cloned and build for FU540 as below: > + Please add .. code-block:: console > +git clone https://github.com/riscv/opensbi.git > +cd opensbi > +make PLATFORM=sifive/fu540 > + > +Copy OpenSBI FW_DYNAMIC image > +(build/platform/sifive/fu540/firmware/fw_dynamic.bin) > +into U-Boot root directory > + > + > +How to build U-Boot SPL booting from MMC > + > +With sifive_fu540_spl_defconfig: > + > +1. Add the RISC-V toolchain to your PATH. > +2. Setup ARCH & cross compilation enviornment variable: > + > +.. code-block:: none > + > + export ARCH=riscv > + export CROSS_COMPILE= > + > +3. make sifive_fu540_spl_defconfig > +4. make > + > + > +Flashing > + > + > +The current U-Boot port is supported in S-mode only. > + > +A prior stage M-mode firmware/bootloader (e.g OpenSBI) is required to > +boot the u-boot.bin in S-mode and provide M-mode runtime services. > + > +First partition of the sdcard should contain "u-boot.itb" and Partition > +type should be of "8300 Linux filesystem". > + > +.. code-block:: none > + > +sudo dd if=spl/u-boot-spl.bin of=/dev/disk2s4 bs=1024 > +sudo dd if=u-boot.itb of=/dev/disk2s1 bs=1024 > + > +Booting > +--- > +Once you plugin the sdcard and power up, you should see the U-Boot prompt. > + > +Sample boot log from HiFive Unleashed board > +--- > + > +.. code-block:: none > + > + U-Boot SPL 2020.01-00176-gfb5af3c225 (Jan 16 2020 - 19:23:14 +0530) > + Trying to boot from MMC1 > + > + > + U-Boot 2020.01-00176-gfb5af3c225 (Jan 16 2020 - 19:23:14 +0530) > + > + CPU: rv64imafdc > + Model: SiFive HiFive Unleashed A00 > + DRAM: 8 GiB > + MMC: spi@1005:mmc@0: 0 > + In:serial@1001 > + Out: serial@1001 > + Err: serial@1001 > + Board serial number should not be 0 !! > + Net: Please fix ERROR: trailing whitespace #98: FILE: doc/board/sifive/fu540.rst:443: > + Warning: ethernet@1009 (eth0) using random MAC address - > 9e:33:74:04:6a:eb > + eth0: ethernet@1009 > + Hit any key to stop autoboot: 0 > + => version > + U-Boot 2020.01-00176-gfb5af3c225 (Jan 16 2020 - 19:23:14 +0530) > + > + riscv64-unknown-linux-gnu-gcc (crosstool-NG 1.24.0.37-3f461da) 9.2.0 > + GNU ld (crosstool-NG 1.24.0.37-3f461da) 2.32 > + => mmc info > + Device: spi@1005:mmc@0 > + Manufacturer ID: 3 > + OEM: 5344 > + Name: SC16G > + Bus Speed: 2000 > + Mode: SD Legacy > + Rd Block Len: 512 > + SD version 2.0 > + High Capacity: Yes > + Capacity: 14.8 GiB > + Bus Width: 1-bit > + Erase Group Size: 512 Bytes > + => mmc part > + > + Partition Map for MMC device 0 -- Partition Type: EFI > + > + PartStart LBA End LBA Name > + Attributes > + Type GUID > + Partition GUID > + 1 0x0800 0x000107ff "Linux filesystem" > + attrs: 0x > + type: 0fc63daf-8483-4772-8e79-3d69d8477de4 > + guid: 36aab838-b418-4342-929e-678d85fb4438 > + 2 0x00040800 0x00ecdfde "Linux filesystem" > + attrs: 0x > + type: 0fc63daf-8483-4772-8e79-3d69d8477de4 > + guid: 118ac296-e3ff-4ef2-b435-ec6a7bebdd6e > + > +Now you can configure your networking, tftp server and use tftp boot > +method to load uImage. > + > +.. code-block:: none > + > + => setenv serverip 172.16.35.74 > + => setenv ipaddr 172.16.35.40 > + => tftpboot 0x8300 fit.itb > + ethernet@1009: PHY present at 0 > + ethernet@1009: Starting autonegotiation... > + ethernet@1009: Autonegotiation complete > +
Re: [PATCH] arm: omap: fix MPU DPLL divisor for 800MHz clock
On 04/12/19 1:25 AM, Dario Binacchi wrote:
> In locked condition CLKOUT = CLKINP * [M / (N + 1)].
>
> Signed-off-by: Dario Binacchi
Merged into u-boot-ti.
Thanks and regards,
Lokesh
> ---
>
> arch/arm/mach-omap2/am33xx/clock_am33xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/am33xx/clock_am33xx.c
> b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
> index 32cdf63e3d..f2cd496607 100644
> --- a/arch/arm/mach-omap2/am33xx/clock_am33xx.c
> +++ b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
> @@ -77,7 +77,7 @@ const struct dpll_params
> dpll_mpu_opp[NUM_CRYSTAL_FREQ][NUM_OPPS] = {
> {-1, -1, -1, -1, -1, -1, -1}, /* OPP RESERVED */
> {25, 0, 1, -1, -1, -1, -1}, /* OPP 100 */
> {30, 0, 1, -1, -1, -1, -1}, /* OPP 120 */
> - {100, 3, 1, -1, -1, -1, -1},/* OPP TB */
> + {100, 2, 1, -1, -1, -1, -1},/* OPP TB */
> {125, 2, 1, -1, -1, -1, -1} /* OPP NT */
> },
> { /* 25 MHz */
>
Re: [PATCH v2 8/9] riscv: sifive: fu540: add SPL configuration
On Fri, Jan 17, 2020 at 6:18 PM Pragnesh Patel
wrote:
>
> This patch provides sifive_fu540_spl_defconfig which can support
> U-boot SPL to boot from L2 LIM (0x0800_) and then boot U-boot
> FIT image including OpenSBI FW_DYNAMIC firmware and U-Boot proper
> images from MMC boot devices.
>
> With sifive_fu540_spl_defconfig:
>
> U-Boot SPL will be loaded by ZSBL from SD card (replace fsbl.bin with
> u-boot-spl.bin) and runs in L2 LIM in machine mode and then load FIT
> image u-boot.itb from SD card (replace fw_payload.bin with u-boot.itb)
> into RAM.
>
> SPL related code is leverage from FSBL
> (https://github.com/sifive/freedom-u540-c000-bootloader.git)
Please look at my comments in PATCH7 regarding patch break-up.
>
> Signed-off-by: Pragnesh Patel
> ---
> arch/riscv/include/asm/csr.h | 2 +
> board/sifive/fu540/Kconfig | 8 +
> board/sifive/fu540/MAINTAINERS | 1 +
> board/sifive/fu540/Makefile| 5 +
> board/sifive/fu540/ddrregs.c | 625 +
> board/sifive/fu540/fu540.c | 27 +-
> board/sifive/fu540/spl.c | 307 ++
> configs/sifive_fu540_spl_defconfig | 26 ++
> include/configs/sifive-fu540.h | 18 +
> 9 files changed, 1018 insertions(+), 1 deletion(-)
> create mode 100644 board/sifive/fu540/ddrregs.c
> create mode 100644 board/sifive/fu540/spl.c
> create mode 100644 configs/sifive_fu540_spl_defconfig
>
> diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
> index d1520743a2..125c05dd8a 100644
> --- a/arch/riscv/include/asm/csr.h
> +++ b/arch/riscv/include/asm/csr.h
> @@ -103,6 +103,8 @@
> #define CSR_TIMEH 0xc81
> #define CSR_INSTRETH 0xc82
> #define CSR_MHARTID0xf14
> +#define CSR_MCYCLE 0xb00
> +#define CSR_MCYCLEH0xb80
This is a totally unrelated change. Please remove this change OR
send it as separate patch.
>
> #ifndef __ASSEMBLY__
>
> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
> index 816a135b21..ac7c6bff37 100644
> --- a/board/sifive/fu540/Kconfig
> +++ b/board/sifive/fu540/Kconfig
> @@ -16,12 +16,20 @@ config SYS_SOC
> default "fu540"
>
> config SYS_TEXT_BASE
> + default 0x8020 if SPL
> default 0x8000 if !RISCV_SMODE
> default 0x8020 if RISCV_SMODE
>
> +config SPL_TEXT_BASE
> + default 0x0800
> +
> +config SPL_OPENSBI_LOAD_ADDR
> + default 0x8000
> +
> config BOARD_SPECIFIC_OPTIONS # dummy
> def_bool y
> select GENERIC_RISCV
> + select SUPPORT_SPL
> imply CMD_DHCP
> imply CMD_EXT2
> imply CMD_EXT4
> diff --git a/board/sifive/fu540/MAINTAINERS b/board/sifive/fu540/MAINTAINERS
> index 702d803ad8..42c3f3deb0 100644
> --- a/board/sifive/fu540/MAINTAINERS
> +++ b/board/sifive/fu540/MAINTAINERS
> @@ -7,3 +7,4 @@ S: Maintained
> F: board/sifive/fu540/
> F: include/configs/sifive-fu540.h
> F: configs/sifive_fu540_defconfig
> +F: configs/sifive_fu540_spl_defconfig
Palmer's email address is incorrect in this file.
I suggest to have separate patch for updating fu540/MAINTAINERS
file and not change fu540/MAINTAINERS here:
1. Add configs/sifive_fu540_spl_defconfig
2. Update Palmer's email address
3. Add yourself as first/primary maintainer for sifive/fu540 board support.
Other folks (including Me and Atish) are busy with other things so they
we are slow on U-Boot patch reviewes.
> diff --git a/board/sifive/fu540/Makefile b/board/sifive/fu540/Makefile
> index 6e1862c475..f01e731913 100644
> --- a/board/sifive/fu540/Makefile
> +++ b/board/sifive/fu540/Makefile
> @@ -3,3 +3,8 @@
> # Copyright (c) 2019 Western Digital Corporation or its affiliates.
>
> obj-y += fu540.o
> +
> +ifdef CONFIG_SPL_BUILD
> +obj-y += spl.o
> +obj-y += ddrregs.o
> +endif
> diff --git a/board/sifive/fu540/ddrregs.c b/board/sifive/fu540/ddrregs.c
> new file mode 100644
> index 00..5c9c238aa1
> --- /dev/null
> +++ b/board/sifive/fu540/ddrregs.c
> @@ -0,0 +1,625 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2019 SiFive, Inc
> + *
> + * Authors:
> + * Pragnesh Patel
> + * Troy Benjegerdes
> + */
> +
> +#include
> +
> +#include "regconfig-ctl.h"
> +#include "regconfig-phy.h"
> +
> +u32 ddr_phy_settings[1215] = {
> + DENALI_PHY_00_DATA, DENALI_PHY_01_DATA, DENALI_PHY_02_DATA,
> + DENALI_PHY_03_DATA, DENALI_PHY_04_DATA, DENALI_PHY_05_DATA,
> + DENALI_PHY_06_DATA, DENALI_PHY_07_DATA, DENALI_PHY_08_DATA,
> + DENALI_PHY_09_DATA,
> + DENALI_PHY_10_DATA, DENALI_PHY_11_DATA, DENALI_PHY_12_DATA,
> + DENALI_PHY_13_DATA, DENALI_PHY_14_DATA, DENALI_PHY_15_DATA,
> + DENALI_PHY_16_DATA, DENALI_PHY_17_DATA, DENALI_PHY_18_DATA,
> + DENALI_PHY_19_DATA,
> + DENALI_PHY_20_DATA, DENALI_PHY_21_DATA, DENALI_PHY_22_DATA,
> + DENALI_PHY_23_DATA, DENALI_PHY_24_DATA, DENALI_PHY_25_DATA,
> +
Re: [PATCH v2 0/8] AM654: Add USB support
On 09/12/19 10:37 AM, Vignesh Raghavendra wrote: > This series adds USB support for AM654 SoC that has DWC3 USB controller. > > Patch 1 adds new compatible for DWC3 driver. Patch 2 and 3 adds PHY > related changes and remaining patches add DT and configs related to USB > host,device and DFU support. > > v2: > Rebase onto the latest master > Collect Reviewed-bys Merged into u-boot-ti Thanks and regards, Lokesh > > Vignesh Raghavendra (8): > dwc3-generic: Add support for AM654 USB controller > phy: omap-usb2-phy: Fix warnings when built for ARM64 > phy: omap-usb2-phy: Add support for AM654 USB2 PHY > arm: dts: k3-am65-main: add USB support > arm: dts: k3-am654-base-board: enable USB1 > configs: am65x_evm: Add DFU related env variables > am65x_evm_a53_defconfig: Enable configs to support USB and DFU > configs: am65x_evm: Enable USB keyboard as second stdin > > arch/arm/dts/k3-am65-main.dtsi | 78 > arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 4 + > arch/arm/dts/k3-am654-base-board.dts | 28 +++ > configs/am65x_evm_a53_defconfig | 22 ++ > drivers/phy/omap-usb2-phy.c | 22 +- > drivers/usb/dwc3/dwc3-generic.c | 1 + > include/configs/am65x_evm.h | 11 ++- > 7 files changed, 162 insertions(+), 4 deletions(-) >
Re: [U-Boot] [PATCH v2 0/6] J721e HS device support
On 11/01/20 1:05 AM, Andrew F. Davis wrote: > Hello all, > > This series brings up High-Security (HS) device support on the J721e > platform. Support for this K3 HS device is much like the existing > AM65x HS and this series leverages much of that support. > > There are also a couple tangentially related fixups that I noticed while > adding this support and testing. Although not strictly needed they > do allow J721e HS to just work out-of-box by the time the last patch > adds the defconfigs. Updated the Maintainers file and synced HS defconfig with HS and merged to u-boot-ti Thanks and regards, Lokesh > > Thanks, > Andrew > > Changes from v1: > - Rebase on master and re-sync defconfigs > > Andrew F. Davis (6): > configs: j721e_evm.h: Sync J721e environment configuration with AM65x > configs: ti: Factor out call to 'args_mmc' into MMC common environment > arm: K3: Fix header comment match AM6 specific file function > arm: K3: Disable ROM configured firewalls > arm: K3: Increase default SYSFW image size allocation > configs: Add configs for J721e High Security EVM > > arch/arm/mach-k3/Kconfig | 2 +- > arch/arm/mach-k3/am6_init.c| 28 ++- > arch/arm/mach-k3/common.c | 30 > arch/arm/mach-k3/common.h | 7 ++ > arch/arm/mach-k3/j721e_init.c | 52 + > configs/j721e_hs_evm_a72_defconfig | 116 + > configs/j721e_hs_evm_r5_defconfig | 105 ++ > include/configs/j721e_evm.h| 16 +++- > include/configs/ti_armv7_common.h | 1 - > include/environment/ti/mmc.h | 5 +- > 10 files changed, 354 insertions(+), 8 deletions(-) > create mode 100644 configs/j721e_hs_evm_a72_defconfig > create mode 100644 configs/j721e_hs_evm_r5_defconfig >
Re: [U-Boot] [PATCH] defconfigs: am43xx_hs_evm: Sync HS and non-HS defconfigs
On 08/01/20 2:57 AM, Andrew F. Davis wrote: > Sync new additions to non-HS defconfig with HS defconfig. > > Signed-off-by: Andrew F. Davis Merged into u-boot-ti Thanks and regards, Lokesh
Re: [U-Boot] [PATCH] defconfigs: am335x_hs_evm: Sync HS and non-HS defconfigs
On 08/01/20 2:54 AM, Andrew F. Davis wrote: > Sync new additions to non-HS defconfig with HS defconfig. > > Signed-off-by: Andrew F. Davis Merged into u-boot-ti Thanks and regards, Lokesh
Re: [PATCH v2 0/5] board: ti: j721e: Enable I2C and EEPROM
On 07/01/20 1:15 PM, Lokesh Vutla wrote: > This series enable I2C and EEPROM support on J721e common processor > board. > > Logs: https://pastebin.ubuntu.com/p/HTrQk3VnZm/ Merged into u-boot-ti Thanks and regards, Lokesh > > Changes since v1: > - Fixed board_is_j721e_som() to use the right apis. > > Andreas Dannenberg (3): > ti: common: board_detect: Handle EEPROM probe more gracefully > board: ti: j721e: Use EEPROM-based board detection > arm64: dts: k3-j721e-common-proc-board: Fully enable wkup_i2c0 use > > Lokesh Vutla (1): > board: ti: j721e: Print board name and version during boot > > Vignesh Raghavendra (1): > configs: j721e_evm_a72_defconfig: Enable I2C and EEPROM support > > .../k3-j721e-common-proc-board-u-boot.dtsi| 8 + > arch/arm/dts/k3-j721e-common-proc-board.dts | 15 + > .../arm/mach-k3/include/mach/j721e_hardware.h | 3 + > arch/arm/mach-k3/j721e_init.c | 3 + > board/ti/common/board_detect.c| 11 +- > board/ti/common/board_detect.h| 9 + > board/ti/j721e/Kconfig| 7 + > board/ti/j721e/evm.c | 264 ++ > configs/j721e_evm_a72_defconfig | 4 + > 9 files changed, 323 insertions(+), 1 deletion(-) >
Re: [PATCH v3 0/5] board: ti: beagleboneai: add initial support
On 02/01/20 7:47 PM, Caleb Robey wrote: > The following patches > > 1) Introduce the emmc based board detection for BBAI due to a lack of > eeprom onboard the BBAI (to be fixed in future revision of the board). > 2) Add structures in the pinctrl to detect the beaglebone AI and add checks > for the beaglebone AI in the board detection scheme > 3) Minor changes to files to support dts and bbai boot overall > 4) Add device tree file for BeagleBone AI > 5) Enable beaglebone ai in am57xx_evm_defconfig > > Device tree has gone to mainline kernel found here: > https://patchwork.kernel.org/patch/11254903/ Merged into u-boot-ti. Thanks and regards, Lokesh > > v2 Changes: > - Introduced missed additions in board.c that allow the actual > configuration of the BBAI when detected. I also removed the > hardcoded change of uart0 serial confirution and added a > CONFIG_PREBOOT variable to do the board detect and setenv of > the console variable > > v3 Changes: > - Swapped order of 2 and 3 to assure no patch breaks the build > - aligned dts file with the one found in the latest release of psdk > 06.02 > > Caleb Robey (5): > board: ti: beagleboneai: emmc read changes > board: ti: beagleboneai: IODELAY and pinmux > board: ti: beagleboneai: add initial support > board: ti: beagleboneai: add dts file > board: ti: beagleboneai: enable in am57xx_evm_defconfig > > arch/arm/dts/Makefile| 1 + > arch/arm/dts/am5729-beagleboneai.dts | 576 +++ > arch/arm/mach-omap2/omap5/hw_data.c | 1 + > board/ti/am57xx/board.c | 61 ++- > board/ti/am57xx/mux_data.h | 280 + > board/ti/common/board_detect.c | 76 > board/ti/common/board_detect.h | 9 + > configs/am57xx_evm_defconfig | 3 +- > include/configs/am57xx_evm.h | 1 - > include/environment/ti/boot.h| 2 + > 10 files changed, 1007 insertions(+), 3 deletions(-) > create mode 100644 arch/arm/dts/am5729-beagleboneai.dts >
Re: [PATCH v2 0/7] Add Support for MMC/SD in J721e
On 16/01/20 7:42 PM, Faiz Abbas wrote: > The following patches add support for MMC/SD in J721e. Currently, SD > card is capped at 25 MBps and eMMC is capped at 50 MBps. Support for > higher speeds and eMMC boot support will be added in futures series. > > v2: > 1. Dropped FAT_WRITE patch because its already merged. > 2. Fixed up environment patch to support latest CONFIGS. > 3. Rebased to the latest u-boot-ti next branch Merged into u-boot-ti Thanks and regards, Lokesh > > Faiz Abbas (7): > mmc: am654_sdhci: Get Xin clock by name > mmc: am654_sdhci: Add Support for configuring PHY in J721e > arm: dts: k3-j721e-common-proc-board: Remove voltage-ranges from sdhci > nodes > arm: dts: k3-j721e-common-proc-board: Add pinmux for SD card > configs: j721e_evm: Add configs for ADMA Support > configs: j721e_evm_a72: Add Support for GPT partitions > configs: j721e_evm: Add configs for environment in eMMC > > arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 3 +- > .../k3-j721e-common-proc-board-u-boot.dtsi| 4 + > arch/arm/dts/k3-j721e-common-proc-board.dts | 22 ++- > .../arm/dts/k3-j721e-r5-common-proc-board.dts | 16 +++ > configs/j721e_evm_a72_defconfig | 9 +- > configs/j721e_evm_r5_defconfig| 7 +- > drivers/mmc/am654_sdhci.c | 129 ++ > include/configs/j721e_evm.h | 12 ++ > 8 files changed, 166 insertions(+), 36 deletions(-) >
Re: [PATCH v4 00/10] dma: ti: k3-udma: Add support for J721e
On 09/12/19 10:25 AM, Vignesh Raghavendra wrote: > This series adds DMA support for J721e using exist K3 UDMA driver. > > One main change is thati, on J721e, DMA resources such as DMA channels are > shared between different entities running on different cores of the SoC. > Therefore, U-Boot running on A72 core should request range of resources > allocated to it from centralized resource management core (DMSC) and use > only the allocated resource. > > First two patches adds support for dynamically querying and using > allocated resources. Remaining patches fix issues when using UDMA driver > on a 32 bit core like R5. Last patch adds a new compatible for J721e Merged into u-boot-ti. Thanks and regards, Lokesh > > v4: > Rebase onto latest master and fix a compliation error due to recent > changes in master. > > v3: > Address comments by Grygorii and add R-by > > Vignesh Raghavendra (10): > lib: Import few bitmap functions from Linux > dma: ti: k3-udma: Query DMA channels allocated from Resource Manager > soc: ti: k3-navss-ringacc: Flush/invalidate caches on ring push/pop > soc: ti: k3-navss-ringacc: Get SYSFW reference from DT phandle > dma: ti: k3-udma: Remove coherency check for cache ops > dma: ti: k3-udma: Fix debug prints during enabling MEM_TO_DEV > transfers > dma: ti: k3-udma: Switch to exposed ring mode > dma: ti: k3-udma: Fix ring push operation for 32 bit cores > dma: ti: k3-udma: Fix build warnings when building for 32 bit > platforms > dma: ti: k3-udma: Add new compatible to J721e > > drivers/dma/ti/k3-udma.c | 365 -- > drivers/soc/ti/k3-navss-ringacc.c | 14 +- > include/linux/bitmap.h| 133 +++ > include/linux/bitops.h| 12 + > 4 files changed, 404 insertions(+), 120 deletions(-) >
Re: [PATCH v2 7/9] riscv: sifive: fu540: Add U-boot SPL header files
On Fri, Jan 17, 2020 at 6:18 PM Pragnesh Patel
wrote:
>
> Add header files needed for U-boot SPL
>
> Signed-off-by: Pragnesh Patel
First of all, PATCH7 and PATCH8 does not make sense.
Instead of PATCH7 and PATCH8, we should have following
patch breakup:
1. A PATCH for adding ddrregs.c,required headers and required
Makefile/Kconfig changes
2. A PATCH for adding spl.c, required headers and required
Makefile/Kconfig changes
3. A PATCH for SPL defconfig
By "required headers", I mean the headers by this patch only.
> ---
> board/sifive/fu540/ccache.h | 43 +
> board/sifive/fu540/fu540-memory-map.h | 59 ++
> board/sifive/fu540/regconfig-ctl.h| 274 ++
> board/sifive/fu540/regconfig-phy.h| 1224 +
> board/sifive/fu540/ux00ddr.h | 276 ++
> board/sifive/fu540/ux00prci.h | 69 ++
> 6 files changed, 1945 insertions(+)
> create mode 100644 board/sifive/fu540/ccache.h
> create mode 100644 board/sifive/fu540/fu540-memory-map.h
> create mode 100644 board/sifive/fu540/regconfig-ctl.h
> create mode 100644 board/sifive/fu540/regconfig-phy.h
> create mode 100644 board/sifive/fu540/ux00ddr.h
> create mode 100644 board/sifive/fu540/ux00prci.h
>
> diff --git a/board/sifive/fu540/ccache.h b/board/sifive/fu540/ccache.h
> new file mode 100644
> index 00..0e5e40a1ef
> --- /dev/null
> +++ b/board/sifive/fu540/ccache.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2019 SiFive, Inc
> + *
> + * Authors:
> + * Pragnesh Patel
> + * Troy Benjegerdes
> + */
> +
> +#ifndef FU540_CCACHE_H
> +#define FU540_CCACHE_H
> +
> +#include
> +
> +#ifndef __ASSEMBLER__
> +
> +#include
> +#include
> +
> +/* Block memory access until operation completed */
> +static inline void ccache_barrier_0(void)
> +{
> + asm volatile("fence rw, io" : : : "memory");
> +}
> +
> +static inline void ccache_barrier_1(void)
> +{
> + asm volatile("fence io, rw" : : : "memory");
> +}
> +
> +/* Enable ways; allow cache to use these ways */
> +static inline void ccache_enable_ways(u64 base_addr, u8 value)
> +{
> + volatile u32 *enable = (volatile u32 *)(base_addr +
> + CCACHE_ENABLE);
> + ccache_barrier_0();
> + (*enable) = value;
> + ccache_barrier_1();
> +}
> +
> +#endif
> +
> +#endif /* FU540_CCACHE_H */
> diff --git a/board/sifive/fu540/fu540-memory-map.h
> b/board/sifive/fu540/fu540-memory-map.h
> new file mode 100644
> index 00..c0df07d6fd
> --- /dev/null
> +++ b/board/sifive/fu540/fu540-memory-map.h
> @@ -0,0 +1,59 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2019 SiFive, Inc
> + *
> + * Authors:
> + * Pragnesh Patel
> + * Troy Benjegerdes
> + */
> +
> +#ifndef FU540_MEMORY_MAP
> +#define FU540_MEMORY_MAP
> +
> +#include
> +#include
> +#include
> +#include "ccache.h"
> +#include "i2c.h"
> +#include "spi.h"
> +#include "ux00prci.h"
Remove unused includes
> +
> +/
> + * Platform definitions
> +
> */
> +
> +/* Memory map */
> +#define CCACHE_CTRL_ADDR _AC(0x201, UL)
> +#define CCACHE_CTRL_SIZE _AC(0x1000, UL)
> +
> +#define GPIO_CTRL_ADDR _AC(0x1006, UL)
> +#define GPIO_CTRL_SIZE _AC(0x1000, UL)
GPIO_xyz defines are not used anywhere remove it.
> +
> +#define PHYSICAL_FILTER_CTRL_ADDR _AC(0x100b8000, UL)
> +#define PHYSICAL_FILTER_CTRL_SIZE _AC(0x1000, UL)
> +
> +#define UART0_CTRL_ADDR_AC(0x1001, UL)
> +#define UART0_CTRL_SIZE_AC(0x1000, UL)
> +#define UART1_CTRL_ADDR_AC(0x10011000, UL)
> +#define UART1_CTRL_SIZE_AC(0x1000, UL)
> +#ifndef UART_CTRL_ADDR
> +#define UART_CTRL_ADDR UART0_CTRL_ADDR
> +#endif
> +#ifndef UART_CTRL_SIZE
> +#define UART_CTRL_SIZE UART0_CTRL_SIZE
> +#endif
These UARTx_ defines can be removed if we can get rid of
UART clock scaling from init_clk_and_ddr(). The rationale is that
UART driver of U-Boot is supposed to set correct divider values
based on current clk setting so we don't need to do UART clock
scaling in init_clk_and_ddr()
> +#define UX00DDR_CTRL_ADDR _AC(0x100b, UL)
> +#define UX00DDR_CTRL_SIZE _AC(0x4000, UL)
> +#define UX00PRCI_CTRL_ADDR _AC(0x1000, UL)
> +#define UX00PRCI_CTRL_SIZE _AC(0x1000, UL)
> +
> +/* Helper functions */
> +#define _REG32(p, i)(*(volatile uint32_t *)((p) + (i)))
> +
> +#define UX00PRCI_REG(offset) \
> + _REG32(UX00PRCI_CTRL_ADDR, \
> + offset)
> +#define GPIO_REG(offset) _REG32(GPIO_CTRL_ADDR, offset)
> +#define UART0_REG(offset)_REG32(UART0_CTRL_ADDR, offset)
Remove GPIO_REG() and UART0_REG() as well.
> +
> +#endif
Re: [U-Boot] [PATCH] ARM: dts: da850-lcdk: Update DTS files for SPL device tree support
On 13/11/19 9:16 PM, Adam Ford wrote: > Currently, the da850-lcdk uses SPL_OF_PLATDATA and manually loads > the necessary source code instead of using the auto-generated, > because the drivers don't properly autogenerate the code. > > This patch simply enables the various device tree options to > mimic the da850-evm which doesn't need or use OF_PLATDATA for > device tree support. It does not disable OF_PLATDATA. > > Signed-off-by: Adam Ford Merged into u-boot-ti. Thanks and regards, Lokesh
Re: [U-Boot] [PATCH] thermal: ti-bandgap: Fix adc value datatype
On 11/11/19 3:15 PM, Faiz Abbas wrote: > The CORE_TEMP_SENSOR_MPU register gives a raw adc value which needs to > be indexed into a lookup table to get the actual temperature. Fix the > naming and datatype of the adc value variable. > > Signed-off-by: Faiz Abbas Merged into u-boot-ti. Thanks and regards, Lokesh
Re: [PATCH 0/4] J721e: Add USB support
On 18/11/19 7:16 PM, Vignesh Raghavendra wrote: > Add USB support for J721e SoC. > First patch fixes a compile issue with Cadence USB driver. Rest of the > patches add env, DT and configs related to USB. patches 2,3,4 merged into u-boot-ti. Thanks and regards, Lokesh > > Vignesh Raghavendra (4): > usb: cdns3: Fix include file path > environment: ti: Add DFU environment variables k3_dfu.h > arm: dts: k3-j721e: Add DT nodes for USB > configs: j721e_evm_a72_defconfig: Enable USB related configs > > .../k3-j721e-common-proc-board-u-boot.dtsi| 14 > arch/arm/dts/k3-j721e-common-proc-board.dts | 37 ++ > arch/arm/dts/k3-j721e-main.dtsi | 70 +++ > .../arm/dts/k3-j721e-r5-common-proc-board.dts | 7 ++ > configs/j721e_evm_a72_defconfig | 28 > drivers/usb/cdns3/core.c | 2 +- > drivers/usb/cdns3/host.c | 2 +- > include/configs/j721e_evm.h | 10 +++ > include/environment/ti/k3_dfu.h | 46 > 9 files changed, 214 insertions(+), 2 deletions(-) > create mode 100644 include/environment/ti/k3_dfu.h >
Re: [PATCH v2 6/9] riscv: sifive: dts: fu540: Add board -u-boot.dtsi files
On Fri, Jan 17, 2020 at 6:18 PM Pragnesh Patel
wrote:
>
> Devicetree files in FU540 platform is synced from Linux, like other
> platforms does. Apart from these u-boot in FU540 would also require
> some u-boot specific node like clint.
>
> So, create board specific -u-boot.dtsi files. This would help of
> maintain u-boot specific changes separately without touching Linux
> dts(i) files which indeed easy for syncing from Linux between
> releases.
>
> Signed-off-by: Pragnesh Patel
> ---
> arch/riscv/dts/fu540-c000-u-boot.dtsi | 43 +++
> .../dts/hifive-unleashed-a00-u-boot.dtsi | 18
> 2 files changed, 61 insertions(+)
>
> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> index 615a68c0e9..e9b2799a7b 100644
> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> @@ -4,10 +4,53 @@
> */
>
> / {
> + cpus {
> + u-boot,dm-spl;
> + cpu0: cpu@0 {
> + u-boot,dm-spl;
> + status = "okay";
> + cpu0_intc: interrupt-controller {
> + u-boot,dm-spl;
> + };
> + };
> + cpu1: cpu@1 {
> + u-boot,dm-spl;
> + };
> + cpu2: cpu@2 {
> + u-boot,dm-spl;
> + };
> + cpu3: cpu@3 {
> + u-boot,dm-spl;
> + };
> + cpu4: cpu@4 {
> + u-boot,dm-spl;
> + };
> + };
> +
> soc {
> + u-boot,dm-spl;
> otp: otp@1007 {
> compatible = "sifive,fu540-otp";
> reg = <0x0 0x1007 0x0 0x0FFF>;
> };
> + clint@200 {
> + compatible = "riscv,clint0";
> + interrupts-extended = <_intc 3 _intc 7 >;
> + reg = <0x0 0x200 0x0 0xc>;
> + u-boot,dm-spl;
> + };
> };
> +
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> };
> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> index bec0d19134..9b59f4ee14 100644
> --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> @@ -4,3 +4,21 @@
> */
>
> #include "fu540-c000-u-boot.dtsi"
> +
> +/ {
> + hfclk {
> + u-boot,dm-spl;
> + };
> +
> + rtcclk {
> + u-boot,dm-spl;
> + };
> +};
> +
> + {
> +
> + mmc@0 {
> + u-boot,dm-spl;
> + };
> +
> +};
> --
> 2.17.1
>
LGTM.
Reviewed-by: Anup Patel
Regards,
Anup
Re: [PATCH v2 5/9] lib: Makefile: build crc7.c when CONFIG_MMC_SPI
On Fri, Jan 17, 2020 at 6:18 PM Pragnesh Patel wrote: > > When build U-boot SPL, meet an issue of undefined reference to > 'crc7' for drivers/mmc/mmc_spi.c, so let's compile crc7.c when > CONFIG_MMC_SPI selected. > > Signed-off-by: Pragnesh Patel > --- > lib/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/Makefile b/lib/Makefile > index 6b7b9ce85c..8e3a071786 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -77,6 +77,7 @@ endif > > ifdef CONFIG_SPL_BUILD > obj-$(CONFIG_SPL_YMODEM_SUPPORT) += crc16.o > +obj-$(CONFIG_MMC_SPI) += crc7.o > obj-$(CONFIG_$(SPL_TPL_)HASH_SUPPORT) += crc16.o > obj-y += net_utils.o > endif > -- > 2.17.1 > LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: [PATCH v2 4/9] riscv: Add _image_binary_end for SPL
On Fri, Jan 17, 2020 at 6:17 PM Pragnesh Patel
wrote:
>
> For SPL_SEPARATE_BSS, Device tree will put at _image_binary_end
>
> Signed-off-by: Pragnesh Patel
> ---
> arch/riscv/cpu/u-boot-spl.lds | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/riscv/cpu/u-boot-spl.lds b/arch/riscv/cpu/u-boot-spl.lds
> index 955dd3106d..d0495ce248 100644
> --- a/arch/riscv/cpu/u-boot-spl.lds
> +++ b/arch/riscv/cpu/u-boot-spl.lds
> @@ -72,6 +72,7 @@ SECTIONS
> . = ALIGN(4);
>
> _end = .;
> + _image_binary_end = .;
>
> .bss : {
> __bss_start = .;
> --
> 2.17.1
>
LGTM.
Reviewed-by: Anup Patel
Regards,
Anup
Re: [PATCH v2 3/9] Sifive: FU540: Add header files for SoC
On Fri, Jan 17, 2020 at 6:17 PM Pragnesh Patel wrote: > > Add fu540 SoC specific header files > > Signed-off-by: Pragnesh Patel > --- > arch/riscv/include/asm/arch-fu540/cache.h | 42 ++ > arch/riscv/include/asm/arch-fu540/gpio.h | 14 > arch/riscv/include/asm/arch-fu540/otp.h| 80 +++ > arch/riscv/include/asm/arch-fu540/spi.h| 15 > arch/riscv/include/asm/arch-fu540/uart.h | 14 > arch/riscv/include/asm/arch-generic/gpio.h | 32 +--- > arch/riscv/include/asm/arch-sifive/gpio.h | 42 ++ > arch/riscv/include/asm/arch-sifive/spi.h | 93 ++ > arch/riscv/include/asm/arch-sifive/uart.h | 35 > drivers/spi/spi-sifive.c | 81 +-- > 10 files changed, 339 insertions(+), 109 deletions(-) > create mode 100644 arch/riscv/include/asm/arch-fu540/cache.h > create mode 100644 arch/riscv/include/asm/arch-fu540/gpio.h > create mode 100644 arch/riscv/include/asm/arch-fu540/otp.h > create mode 100644 arch/riscv/include/asm/arch-fu540/spi.h > create mode 100644 arch/riscv/include/asm/arch-fu540/uart.h > create mode 100644 arch/riscv/include/asm/arch-sifive/gpio.h > create mode 100644 arch/riscv/include/asm/arch-sifive/spi.h > create mode 100644 arch/riscv/include/asm/arch-sifive/uart.h > > diff --git a/arch/riscv/include/asm/arch-fu540/cache.h > b/arch/riscv/include/asm/arch-fu540/cache.h > new file mode 100644 > index 00..e84d56774c > --- /dev/null > +++ b/arch/riscv/include/asm/arch-fu540/cache.h > @@ -0,0 +1,42 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright (C) 2019 SiFive, Inc. > + * > + * Authors: > + * Pragnesh Patel > + */ > + > +#ifndef _CACHE_FU540_H > +#define _CACHE_FU540_H > + > +/* Register offsets */ > +#define CCACHE_INFO 0x000 > +#define CCACHE_ENABLE 0x008 > +#define CCACHE_INJECT 0x040 > +#define CCACHE_META_FIX 0x100 > +#define CCACHE_DATA_FIX 0x140 > +#define CCACHE_DATA_FAIL0x160 > +#define CCACHE_FLUSH64 0x200 > +#define CCACHE_FLUSH32 0x240 > +#define CCACHE_WAYS 0x800 > + > +/* Bytes inside the INFO field */ > +#define CCACHE_INFO_BANKS 0 > +#define CCACHE_INFO_WAYS1 > +#define CCACHE_INFO_LG_SETS 2 > +#define CCACHE_INFO_LG_BLOCKBYTES 3 > + > +/* INJECT types */ > +#define CCACHE_ECC_TOGGLE_DATA 0x0 > +#define CCACHE_ECC_TOGGLE_META 0x1 > + > +/* Offsets per FIX/FAIL */ > +#define CCACHE_ECC_ADDR 0x0 > +#define CCACHE_ECC_COUNT0x8 > + > +/* Interrupt Number offsets from Base */ > +#define CCACHE_INT_META_FIX 0 > +#define CCACHE_INT_DATA_FIX 1 > +#define CCACHE_INT_DATA_FAIL2 > + > +#endif /* _CACHE_FU540_H */ > diff --git a/arch/riscv/include/asm/arch-fu540/gpio.h > b/arch/riscv/include/asm/arch-fu540/gpio.h > new file mode 100644 > index 00..8210ff8551 > --- /dev/null > +++ b/arch/riscv/include/asm/arch-fu540/gpio.h > @@ -0,0 +1,14 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright (C) 2019 SiFive, Inc. > + * > + * Authors: > + * Pragnesh Patel > + */ > + > +#ifndef _GPIO_FU540_H > +#define _GPIO_FU540_H > + > +#include > + > +#endif /* _GPIO_FU540_H */ > diff --git a/arch/riscv/include/asm/arch-fu540/otp.h > b/arch/riscv/include/asm/arch-fu540/otp.h > new file mode 100644 > index 00..a498593d39 > --- /dev/null > +++ b/arch/riscv/include/asm/arch-fu540/otp.h > @@ -0,0 +1,80 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright (C) 2019 SiFive, Inc. > + * > + * Authors: > + * Pragnesh Patel > + * Troy Benjegerdes > + */ > + > +#ifndef _OTP_FU540_H > +#define _OTP_FU540_H > + > +/* Register offsets */ > +#define EMEMORYOTP_PA 0x00 > +#define EMEMORYOTP_PAIO0x04 > +#define EMEMORYOTP_PAS 0x08 > +#define EMEMORYOTP_PCE 0x0C > +#define EMEMORYOTP_PCLK0x10 > +#define EMEMORYOTP_PDIN0x14 > +#define EMEMORYOTP_PDOUT 0x18 > +#define EMEMORYOTP_PDSTB 0x1C > +#define EMEMORYOTP_PPROG 0x20 > +#define EMEMORYOTP_PTC 0x24 > +#define EMEMORYOTP_PTM 0x28 > +#define EMEMORYOTP_PTM_REP 0x2C > +#define EMEMORYOTP_PTR 0x30 > +#define EMEMORYOTP_PTRIM 0x34 > +#define EMEMORYOTP_PWE 0x38 > + > +/* Timing delays (in us) > + * MIN indicates that there is no maximum. > + * TYP indicates that there is a maximum > + * that should not be exceeded. > + * When the minimums are < 1us, I just put 1us. > + */ > + > +#define EMEMORYOTP_MIN_TVDS1 > +#define EMEMORYOTP_MIN_TSAS2 > +#define EMEMORYOTP_MIN_TTAS50 > +#define EMEMORYOTP_MIN_TTAH1 > +#define EMEMORYOTP_MIN_TASH1 > +#define EMEMORYOTP_MIN_TMS 1 > +#define EMEMORYOTP_MIN_TCS 10 > +#define EMEMORYOTP_MIN_TMH 1 > +#define EMEMORYOTP_MIN_TAS 50 > + > +#define EMEMORYOTP_MAX_TCD 1 > +#define EMEMORYOTP_MIN_TKH
Re: [PATCH v2 2/9] Sifive: FU540: Add place-holder for FU540 clk
On Fri, Jan 17, 2020 at 6:17 PM Pragnesh Patel wrote: > > Added FU540 place-holder so that SoC specific values > will be kept here. > > Signed-off-by: Pragnesh Patel > --- > arch/riscv/include/asm/arch-fu540/clk.h | 14 ++ > board/sifive/fu540/Kconfig | 3 +++ > 2 files changed, 17 insertions(+) > create mode 100644 arch/riscv/include/asm/arch-fu540/clk.h > > diff --git a/arch/riscv/include/asm/arch-fu540/clk.h > b/arch/riscv/include/asm/arch-fu540/clk.h > new file mode 100644 > index 00..b39f5b55c9 > --- /dev/null > +++ b/arch/riscv/include/asm/arch-fu540/clk.h > @@ -0,0 +1,14 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright (c) 2019 SiFive, Inc. > + * > + * Authors: > + * Pragnesh Patel > + */ > + > +#ifndef _CLK_FU540_H > +#define _CLK_FU540_H > + > +/* Note: This is a placeholder header for driver compilation. */ > + > +#endif > diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig > index 5ca21474de..816a135b21 100644 > --- a/board/sifive/fu540/Kconfig > +++ b/board/sifive/fu540/Kconfig > @@ -12,6 +12,9 @@ config SYS_CPU > config SYS_CONFIG_NAME > default "sifive-fu540" > > +config SYS_SOC > + default "fu540" > + > config SYS_TEXT_BASE > default 0x8000 if !RISCV_SMODE > default 0x8020 if RISCV_SMODE > -- > 2.17.1 > LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: [PATCH v2 1/9] misc: add driver for the Sifive otp controller
On Fri, Jan 17, 2020 at 6:17 PM Pragnesh Patel
wrote:
>
> Added a misc driver to handle OTP memory in FU540.
>
> Signed-off-by: Pragnesh Patel
> ---
> arch/riscv/dts/fu540-c000-u-boot.dtsi | 13 ++
> .../dts/hifive-unleashed-a00-u-boot.dtsi | 6 +
> board/sifive/fu540/fu540.c| 113 --
> configs/sifive_fu540_defconfig| 2 +
> drivers/misc/Kconfig | 7 +
> drivers/misc/Makefile | 1 +
> drivers/misc/ememory-otp.c| 209 ++
> 7 files changed, 278 insertions(+), 73 deletions(-)
> create mode 100644 arch/riscv/dts/fu540-c000-u-boot.dtsi
> create mode 100644 arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> create mode 100644 drivers/misc/ememory-otp.c
>
> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> new file mode 100644
> index 00..615a68c0e9
> --- /dev/null
> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2019 SiFive, Inc
> + */
> +
> +/ {
> + soc {
> + otp: otp@1007 {
> + compatible = "sifive,fu540-otp";
> + reg = <0x0 0x1007 0x0 0x0FFF>;
> + };
> + };
> +};
> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> new file mode 100644
> index 00..bec0d19134
> --- /dev/null
> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 SiFive, Inc
> + */
> +
> +#include "fu540-c000-u-boot.dtsi"
> diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
> index 47a2090251..3a5e74f1fb 100644
> --- a/board/sifive/fu540/fu540.c
> +++ b/board/sifive/fu540/fu540.c
> @@ -10,94 +10,61 @@
> #include
> #include
> #include
> +#include
>
> -#ifdef CONFIG_MISC_INIT_R
> -
> -#define FU540_OTP_BASE_ADDR0x1007
> -
> -struct fu540_otp_regs {
> - u32 pa; /* Address input */
> - u32 paio; /* Program address input */
> - u32 pas;/* Program redundancy cell selection input */
> - u32 pce;/* OTP Macro enable input */
> - u32 pclk; /* Clock input */
> - u32 pdin; /* Write data input */
> - u32 pdout; /* Read data output */
> - u32 pdstb; /* Deep standby mode enable input (active low) */
> - u32 pprog; /* Program mode enable input */
> - u32 ptc;/* Test column enable input */
> - u32 ptm;/* Test mode enable input */
> - u32 ptm_rep;/* Repair function test mode enable input */
> - u32 ptr;/* Test row enable input */
> - u32 ptrim; /* Repair function enable input */
> - u32 pwe;/* Write enable input (defines program cycle) */
> -} __packed;
> -
> -#define BYTES_PER_FUSE 4
> -#define NUM_FUSES 0x1000
> -
> -static int fu540_otp_read(int offset, void *buf, int size)
> -{
> - struct fu540_otp_regs *regs = (void __iomem *)FU540_OTP_BASE_ADDR;
> - unsigned int i;
> - int fuseidx = offset / BYTES_PER_FUSE;
> - int fusecount = size / BYTES_PER_FUSE;
> - u32 fusebuf[fusecount];
> -
> - /* check bounds */
> - if (offset < 0 || size < 0)
> - return -EINVAL;
> - if (fuseidx >= NUM_FUSES)
> - return -EINVAL;
> - if ((fuseidx + fusecount) > NUM_FUSES)
> - return -EINVAL;
> -
> - /* init OTP */
> - writel(0x01, >pdstb); /* wake up from stand-by */
> - writel(0x01, >ptrim); /* enable repair function */
> - writel(0x01, >pce); /* enable input */
> -
> - /* read all requested fuses */
> - for (i = 0; i < fusecount; i++, fuseidx++) {
> - writel(fuseidx, >pa);
> -
> - /* cycle clock to read */
> - writel(0x01, >pclk);
> - mdelay(1);
> - writel(0x00, >pclk);
> - mdelay(1);
> -
> - /* read the value */
> - fusebuf[i] = readl(>pdout);
> - }
> -
> - /* shut down */
> - writel(0, >pce);
> - writel(0, >ptrim);
> - writel(0, >pdstb);
> -
> - /* copy out */
> - memcpy(buf, fusebuf, size);
> +/*
> + * This define is a value used for error/unknown serial.
> + * If we really care about distinguishing errors and 0 is
> + * valid, we'll need a different one.
> + */
> +#define ERROR_READING_SERIAL_NUMBER 0
>
> - return 0;
> -}
> +#ifdef CONFIG_MISC_INIT_R
>
> -static u32 fu540_read_serialnum(void)
> +#if CONFIG_IS_ENABLED(EMEMORY_OTP)
> +static u32 otp_read_serialnum(struct udevice *dev)
> {
> int ret;
> u32 serial[2] = {0};
>
> for (int i = 0xfe * 4; i > 0; i -= 8) {
> - ret =
Re: [PATCH v2 0/2] spi: cadence-qspi: Move to spi-mem APIs
Hi Jagan, On 19/11/19 3:43 pm, Vignesh Raghavendra wrote: > First patch moves driver over to spi-mem framework and implement > spi_mem_ops. This is require to support more SPI Flash opcodes like SFDP > parsing etc. Series is in prepartion to add Octal mode for support for > the same driver to support OSPI version of the controller. > > Second patch adds DAC mode that provide memory mapped access to flash. > This greatly increases the read throughput. > > Tested with mt25qu512 flash and s25fl512 flash > Could you please merge this series? > Note: Depends on [1][2] that adds stubs for dma_memcpy() to be used on > platforms without CONFIG_DMA enabled. > > [1]http://patchwork.ozlabs.org/patch/1195557/ > [2]http://patchwork.ozlabs.org/patch/1195556/ > > > Vignesh Raghavendra (2): > spi: cadence_qspi: Move to spi-mem framework > spi: cadence-qspi: Add direct mode support > > drivers/spi/cadence_qspi.c | 148 +++--- > drivers/spi/cadence_qspi.h | 24 +++-- > drivers/spi/cadence_qspi_apb.c | 185 - > 3 files changed, 164 insertions(+), 193 deletions(-) > -- Regards Vignesh
Re: [PATCH v2 9/9] doc: update FU540 RISC-V documentation
On Fri, Jan 17, 2020 at 6:18 PM Pragnesh Patel wrote: > > Add descriptions about U-Boot SPL feature and how to build and run. > > Signed-off-by: Pragnesh Patel > --- > doc/board/sifive/fu540.rst | 370 + > 1 file changed, 370 insertions(+) > > diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst > index 3937222c6c..e15427414d 100644 > --- a/doc/board/sifive/fu540.rst > +++ b/doc/board/sifive/fu540.rst > @@ -363,3 +363,373 @@ load uImage. > > Please press Enter to activate this console. > / # > + > + > +Running U-Boot SPL > +-- > +The U-Boot SPL will boot in M mode and load the FIT image which include > +OpenSBI and U-Boot proper images. After loading progress, it will jump > +to OpenSBI first and then U-Boot proper which will run in S mode. > + > + > +How to build U-Boot SPL > +--- > +Before building U-Boot SPL, OpenSBI must be build first. OpenSBI can be > +cloned and build for FU540 as below: > + > +git clone https://github.com/riscv/opensbi.git > +cd opensbi > +make PLATFORM=sifive/fu540 > + > +Copy OpenSBI FW_DYNAMIC image > (build/platform/sifive/fu540/firmware/fw_dynamic.bin) > +into U-Boot root directory > + > + > +How to build U-Boot SPL booting from MMC > + > +With sifive_fu540_spl_defconfig: > + > +1. Add the RISC-V toolchain to your PATH. > +2. Setup ARCH & cross compilation enviornment variable: > + > +.. code-block:: none > + > + export ARCH=riscv > + export CROSS_COMPILE= > + > +3. make sifive_fu540_spl_defconfig > +4. make > + > + > +Flashing > + > + > +The current U-Boot port is supported in S-mode only. > + > +A prior stage M-mode firmware/bootloader (e.g OpenSBI) is required to > +boot the u-boot.bin in S-mode and provide M-mode runtime services. > + > +First partition of the sdcard should contain "u-boot.itb" and > +Partition type should be of "8300 Linux filesystem". > + > +.. code-block:: none > + > +sudo dd if=spl/u-boot-spl.bin of=/dev/disk2s4 bs=1024 > +sudo dd if=u-boot.itb of=/dev/disk2s1 bs=1024 > + > +Booting > +--- > +Once you plugin the sdcard and power up, you should see the U-Boot prompt. > + > +Sample boot log from HiFive Unleashed board > +--- > + > +.. code-block:: none > + > + U-Boot SPL 2020.01-00176-gfb5af3c225 (Jan 16 2020 - 19:23:14 +0530) > + Trying to boot from MMC1 > + > + > + U-Boot 2020.01-00176-gfb5af3c225 (Jan 16 2020 - 19:23:14 +0530) > + > + CPU: rv64imafdc > + Model: SiFive HiFive Unleashed A00 > + DRAM: 8 GiB > + MMC: spi@1005:mmc@0: 0 > + In:serial@1001 > + Out: serial@1001 > + Err: serial@1001 > + Board serial number should not be 0 !! > + Net: > + Warning: ethernet@1009 (eth0) using random MAC address - > 9e:33:74:04:6a:eb > + eth0: ethernet@1009 > + Hit any key to stop autoboot: 0 > + => version > + U-Boot 2020.01-00176-gfb5af3c225 (Jan 16 2020 - 19:23:14 +0530) > + > + riscv64-unknown-linux-gnu-gcc (crosstool-NG 1.24.0.37-3f461da) 9.2.0 > + GNU ld (crosstool-NG 1.24.0.37-3f461da) 2.32 > + => mmc info > + Device: spi@1005:mmc@0 > + Manufacturer ID: 3 > + OEM: 5344 > + Name: SC16G > + Bus Speed: 2000 > + Mode: SD Legacy > + Rd Block Len: 512 > + SD version 2.0 > + High Capacity: Yes > + Capacity: 14.8 GiB > + Bus Width: 1-bit > + Erase Group Size: 512 Bytes > + => mmc part > + > + Partition Map for MMC device 0 -- Partition Type: EFI > + > + PartStart LBA End LBA Name > + Attributes > + Type GUID > + Partition GUID > + 1 0x0800 0x000107ff "Linux filesystem" > + attrs: 0x > + type: 0fc63daf-8483-4772-8e79-3d69d8477de4 > + guid: 36aab838-b418-4342-929e-678d85fb4438 > + 2 0x00040800 0x00ecdfde "Linux filesystem" > + attrs: 0x > + type: 0fc63daf-8483-4772-8e79-3d69d8477de4 > + guid: 118ac296-e3ff-4ef2-b435-ec6a7bebdd6e > + > +Now you can configure your networking, tftp server and use tftp boot method > to > +load uImage. > + > +.. code-block:: none > + > + => setenv serverip 172.16.35.74 > + => setenv ipaddr 172.16.35.40 > + => tftpboot 0x8300 fit.itb > + ethernet@1009: PHY present at 0 > + ethernet@1009: Starting autonegotiation... > + ethernet@1009: Autonegotiation complete > + ethernet@1009: link up, 100Mbps full-duplex (lpa: 0x41e1) > + Using ethernet@1009 device > + TFTP from server 172.16.35.74; our IP address is 172.16.35.40 > + Filename 'fit.itb'. > + Load address: 0x8300 > + Loading: # > + # > + # > + # > +
Re: [PATCH v2 0/9] RISC-V SiFive FU540 support SPL
On Fri, Jan 17, 2020 at 6:16 PM Pragnesh Patel wrote: > > This series add support for SPL to FU540. This series depends on > https://patchwork.ozlabs.org/patch/1196703/ > (riscv: dts: Add hifive-unleashed-a00 dts from Linux) > > U-Boot SPL can boot from L2 LIM (0x0800_) and jump to > OpenSBI(FW_DYNAMIC firmware) and U-Boot proper from MMC devices. > > How to test this patch: > 1) Go to OpenSBI-dir : make PLATFORM=sifive/fu540 O=build_dir I=install_dir > FW_DYNAMIC=y install > 2) cp install_dir/platform/sifive/fu540/firmware/fw_dynamic.bin / > 3) Change to u-boot-dir > 4) make sifive_fu540_spl_defconfig > 5) make all > 6) SD card partition which contains "fw_payload.bin" previously > /dev/sdc1 - SiFive bare-metal (or s ->5202) >should be now of > /dev/sdc1 - 8300 Linux filesystem. The ZSBL loads next stage (i.e. FSBL or U-Boot SPL) from a partition with GUID type 2e54b353-1271-4842-806f-e436d6af6985 You need to document how U-Boot SPL will detect a partition containtaining u-boot.itb image. I have same comment in your documentation patch as well. Regards, Anup > 6) sudo dd if=spl/u-boot-spl.bin of=/dev/sdc4 bs=1M > 7) sudo dd if=u-boot.itb of=/dev/sdc1 bs=1M > > Following are the boot messages on FU540 five cores SMP platform: > > U-Boot SPL 2020.01-00177-ga3fabe50f9 (Jan 17 2020 - 14:20:12 +0530) > Trying to boot from MMC1 > > > U-Boot 2020.01-00177-ga3fabe50f9 (Jan 17 2020 - 14:20:12 +0530) > > CPU: rv64imafdc > Model: SiFive HiFive Unleashed A00 > DRAM: 8 GiB > MMC: spi@1005:mmc@0: 0 > In:serial@1001 > Out: serial@1001 > Err: serial@1001 > Board serial number should not be 0 !! > Net: > Warning: ethernet@1009 (eth0) using random MAC address - c6:3a:5b:53:64:8b > eth0: ethernet@1009 > Hit any key to stop autoboot: 0 > => setenv serverip 172.16.35.74;setenv ipaddr 172.16.35.40;tftpboot > 0x8300 fit.itb;bootm 0x8300 > ethernet@1009: PHY present at 0 > ethernet@1009: Starting autonegotiation... > ethernet@1009: Autonegotiation complete > ethernet@1009: link up, 100Mbps full-duplex (lpa: 0x41e1) > Using ethernet@1009 device > TFTP from server 172.16.35.74; our IP address is 172.16.35.40 > Filename 'fit.itb'. > Load address: 0x8300 > Loading: # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # > # >
Re: [PATCH 0/3] sunxi: Sync H3/H5 DT and add ALL-H3-IT and ALL-H5-CC
Hi Jagan, On Sun, Jan 12, 2020 at 11:36 PM Chen-Yu Tsai wrote: > > From: Chen-Yu Tsai > > Hi everyone, > > This patch series syncs up the device tree files and header files for > Allwinner H3/H5 SoCs and related boards to linux-next-20200108, and > then adds support for Libre Computer ALL-H3-IT H5 and ALL-H5-CC H5 > boards. > > Patch 1 syncs up the device tree files and related device tree binding > header files for the Allwinner H3 and H5 SoCs, and boards using these > chips. These were compile tested. > > Patch 2 adds a defconfig and MAINTAINERS entry for the ALL-H3-IT's H5 > variant. Other variants will be added as they are made available. > > Patch 3 adds a defconfig and MAINTAINERS entry for the ALL-H5-CC's H5 > variant. Other variants will be added as they are made available. > > Please have a look. One week left in the merge window. Any thoughts on this series? Thanks ChenYu > Regards > ChenYu > > > Chen-Yu Tsai (3): > sunxi: H3/H5 Sync DT files from upstream Linux kernel as of > next-20200108 > sunxi: Add Libre Computer ALL-H3-IT H5 board > sunxi: Add Libre Computer ALL-H5-CC H5 board > > arch/arm/dts/Makefile | 9 +- > .../dts/sun50i-h5-bananapi-m2-plus-v1.2.dts | 11 ++ > .../sun50i-h5-emlid-neutis-n5-devboard.dts| 137 ++--- > arch/arm/dts/sun50i-h5-emlid-neutis-n5.dtsi | 95 + > .../arm/dts/sun50i-h5-libretech-all-h3-cc.dts | 10 +- > .../arm/dts/sun50i-h5-libretech-all-h3-it.dts | 11 ++ > .../arm/dts/sun50i-h5-libretech-all-h5-cc.dts | 61 ++ > arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts | 53 + > arch/arm/dts/sun50i-h5-nanopi-neo2.dts| 45 + > arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 47 + > arch/arm/dts/sun50i-h5-orangepi-prime.dts | 52 + > arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts | 11 +- > .../arm/dts/sun50i-h5-orangepi-zero-plus2.dts | 46 + > arch/arm/dts/sun50i-h5.dtsi | 186 +- > .../dts/sun8i-h2-plus-bananapi-m2-zero.dts| 40 +++- > arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts| 2 - > arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 22 ++- > .../dts/sun8i-h3-bananapi-m2-plus-v1.2.dts| 13 ++ > arch/arm/dts/sun8i-h3-beelink-x2.dts | 11 +- > .../sun8i-h3-emlid-neutis-n5h3-devboard.dts | 72 +++ > arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi | 11 ++ > arch/arm/dts/sun8i-h3-mapleboard-mp130.dts| 152 ++ > arch/arm/dts/sun8i-h3-nanopi-duo2.dts | 173 > arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts | 28 ++- > arch/arm/dts/sun8i-h3-nanopi-m1.dts | 2 +- > arch/arm/dts/sun8i-h3-nanopi-neo-air.dts | 2 +- > arch/arm/dts/sun8i-h3-nanopi.dtsi | 25 +-- > arch/arm/dts/sun8i-h3-orangepi-2.dts | 34 +--- > arch/arm/dts/sun8i-h3-orangepi-lite.dts | 27 +-- > arch/arm/dts/sun8i-h3-orangepi-one.dts| 28 +-- > arch/arm/dts/sun8i-h3-orangepi-pc.dts | 27 +-- > arch/arm/dts/sun8i-h3-orangepi-plus.dts | 23 ++- > arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts | 2 +- > arch/arm/dts/sun8i-h3-rervision-dvk.dts | 114 +++ > arch/arm/dts/sun8i-h3.dtsi| 86 +++- > arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 30 +++ > arch/arm/dts/sunxi-bananapi-m2-plus.dtsi | 7 +- > arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi| 170 > arch/arm/dts/sunxi-h3-h5.dtsi | 137 - > arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi | 65 +- > arch/arm/dts/sunxi-libretech-all-h3-it.dtsi | 180 + > board/sunxi/MAINTAINERS | 10 + > configs/libretech_all_h3_it_h5_defconfig | 22 +++ > configs/libretech_all_h5_cc_h5_defconfig | 23 +++ > include/dt-bindings/clock/sun8i-h3-ccu.h | 11 +- > include/dt-bindings/reset/sun8i-h3-ccu.h | 5 +- > 46 files changed, 1605 insertions(+), 723 deletions(-) > create mode 100644 arch/arm/dts/sun50i-h5-bananapi-m2-plus-v1.2.dts > create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h3-it.dts > create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h5-cc.dts > create mode 100644 arch/arm/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts > create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3-devboard.dts > create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi > create mode 100644 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts > create mode 100644 arch/arm/dts/sun8i-h3-nanopi-duo2.dts > create mode 100644 arch/arm/dts/sun8i-h3-rervision-dvk.dts > create mode 100644 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi > create mode 100644 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi > create mode 100644 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi > create mode 100644 configs/libretech_all_h3_it_h5_defconfig > create mode 100644 configs/libretech_all_h5_cc_h5_defconfig > > -- > 2.24.1 >
Pull request: u-boot-rockchip-20200120
Hi Tom, Please pull the rockchip updates: - Support SPI boot and redundant boot for rk3399 - Support binman for rockchip platform - Update ram driver and add ddr4 support for rk3328 Travis: https://travis-ci.org/keveryang/u-boot/builds/639069624 Thanks, - Kever The following changes since commit d7bb6aceb2e99a832efbb96f9bf480bf95602192: Merge tag 'mmc-1-16-2020' of https://gitlab.denx.de/u-boot/custodians/u-boot-mmc (2020-01-16 13:20:51 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git tags/u-boot-rockchip-20200120 for you to fetch changes up to f9a0f5b83e9eabf4d064c7ec46fe2f9b9b694b4e: configs: firefly-rk3399: Enable CONFIG_MISC_INIT_R and ROCKCHIP_EFUSE (2020-01-19 15:19:03 +0800) Jagan Teki (21): distro_bootcmd: Add SF support rockchip: Include SF on distrocmd devices rk3399: Add boot flash script offet, size rk3399: Check MMC env while defining it env: kconfig: Restrict rockchip env for MMC env: Enable SPI flash env for rockchip rockchip: dts: Sync ROC-RK3399-PC changes from Linux roc-pc-rk3399: Enable SPI Flash rockpro-rk3399: Enable SPI Flash rockchip: Add cpu-info rockchip: rk3399: Enable DISPLAY_CPUINFO arm: rockchip: Add common cru.h rockchip: Add common reset cause rockchip: rk3399: Add bootcount support Makefile: Add rockchip image type Makefile: rockchip: Suffix platform type with tpl name Makefile: rockchip: Support SPL-alone mkimage arm: dts: rk3036: Add rk3036-u-boot.dtsi arm: dts: rk3188: Add rk3188-u-boot.dtsi rockchip: Add Single boot image (with binman, pad_cat) doc: boards: Add rockchip documentation Kever Yang (3): ram: rk3328: only do data traning for cs0 rockchip: px30: remove CONFIG_OPTEE support rockchip: rk3308: add alias for emmc/sdmmc Mark Kettenis (1): configs: firefly-rk3399: Enable CONFIG_MISC_INIT_R and ROCKCHIP_EFUSE Thomas Hebb (1): ram: rk3399: don't assume phy_io_config() uses real regs YouMin Chen (2): ram: rk3328: add support ddr4 init ram: rk3328: update lpddr3 setting Makefile| 36 +- arch/arm/Kconfig| 1 + arch/arm/dts/rk3036-sdk-u-boot.dtsi | 2 + arch/arm/dts/rk3036-u-boot.dtsi | 6 + arch/arm/dts/rk3188-radxarock-u-boot.dtsi | 2 + arch/arm/dts/rk3188-u-boot.dtsi | 6 + arch/arm/dts/rk3288-u-boot.dtsi | 2 + arch/arm/dts/rk3308-u-boot.dtsi | 7 + arch/arm/dts/rk3328-sdram-ddr4-666.dtsi | 216 +++ arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi | 8 +- arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 + arch/arm/dts/rk3399-roc-pc.dts | 673 +--- arch/arm/dts/rk3399-roc-pc.dtsi | 813 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 + arch/arm/dts/rockchip-u-boot.dtsi | 21 + arch/arm/include/asm/arch-rockchip/clock.h | 4 +- arch/arm/include/asm/arch-rockchip/cru.h| 30 + arch/arm/include/asm/arch-rockchip/cru_rk3288.h | 20 +- arch/arm/include/asm/arch-rockchip/cru_rk3399.h | 11 +- arch/arm/mach-rockchip/Kconfig | 2 + arch/arm/mach-rockchip/Makefile | 1 + arch/arm/mach-rockchip/cpu-info.c | 65 ++ arch/arm/mach-rockchip/rk3288/clk_rk3288.c | 2 +- arch/arm/mach-rockchip/rk3288/rk3288.c | 41 +- arch/arm/mach-rockchip/rk3399/Kconfig | 10 + arch/arm/mach-rockchip/rk3399/clk_rk3399.c | 2 +- arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +- configs/evb-px30_defconfig | 1 - configs/evb-rk3288_defconfig| 1 - configs/evb-rk3399_defconfig| 1 - configs/ficus-rk3399_defconfig | 1 - configs/firefly-px30_defconfig | 1 - configs/firefly-rk3288_defconfig| 1 - configs/firefly-rk3399_defconfig| 4 +- configs/khadas-edge-captain-rk3399_defconfig| 1 - configs/khadas-edge-rk3399_defconfig| 1 - configs/khadas-edge-v-rk3399_defconfig | 1 - configs/leez-rk3399_defconfig | 1 - configs/miqi-rk3288_defconfig | 1 - configs/nanopc-t4-rk3399_defconfig | 1 - configs/nanopi-m4-rk3399_defconfig | 1 - configs/nanopi-neo4-rk3399_defconfig| 1 - configs/orangepi-rk3399_defconfig | 1 - configs/phycore-rk3288_defconfig| 3 - configs/popmetal-rk3288_defconfig | 1 - configs/puma-rk3399_defconfig | 1 - configs/roc-pc-rk3399_defconfig | 3 +-
[U-Boot] [PATCH] arm: zynq: zybo z7: fix SPL uart init bitrate
From: Milan Obuch The board uses 100 MHz clock for UART bitrate generator, but is configured as 50 MHz on defconfig. This produces wrong console output. The first message, "Debug uart enabled" is received as: "��b" Fix the issue by configuring the correct clock for the UART baudrate generator Signed-off-by: Milan Obuch Signed-off-by: Luis Araneda --- This changes were originally sent by Milan Obuch using a diff format. As he didn't know how to properly send git patches to the mailing list, I converted them to a git commit, rephrased the commit message and added the Signed-off-by tags. Milan Obuch then review and approved the current state of the patch. Tested on a zybo z7-20 board by me configs/zynq_zybo_z7_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/zynq_zybo_z7_defconfig b/configs/zynq_zybo_z7_defconfig index 7129e2b5f3..f41d6574f7 100644 --- a/configs/zynq_zybo_z7_defconfig +++ b/configs/zynq_zybo_z7_defconfig @@ -5,7 +5,7 @@ CONFIG_SYS_TEXT_BASE=0x400 CONFIG_SPL_STACK_R_ADDR=0x20 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xe0001000 -CONFIG_DEBUG_UART_CLOCK=5000 +CONFIG_DEBUG_UART_CLOCK=1 CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y CONFIG_SYS_CUSTOM_LDSCRIPT=y -- 2.25.0
[U-Boot] [PATCH] arm: zynq: zybo z7: fix MIO init issue
From: Milan Obuch
The board has two push button connected to MIO pins
50 and 51, which have a pull-down resistor and are
connected to 1.8V when pressed.
These two pins are wrongly initialized with internal
pull-up enabled so they are reported as 1 all the time
with no change when pressed.
Disable the internal pull-up to fix the issue.
Signed-off-by: Milan Obuch
Signed-off-by: Luis Araneda
---
This changes were originally sent by Milan Obuch using a diff format.
As he didn't know how to properly send git patches to the mailing list,
I converted them to a git commit, rephrased the commit message and added
the Signed-off-by tags.
Milan Obuch then review and approved the current state of the patch.
Tested on a zybo z7-20 board by me
board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
index 7c6bc9fa3f..a376ba574e 100644
--- a/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c
@@ -219,8 +219,8 @@ static unsigned long ps7_mio_init_data_3_0[] = {
EMIT_MASKWRITE(0xF80007BC, 0x3F01U, 0x1201U),
EMIT_MASKWRITE(0xF80007C0, 0x3FFFU, 0x12E0U),
EMIT_MASKWRITE(0xF80007C4, 0x3FFFU, 0x12E1U),
- EMIT_MASKWRITE(0xF80007C8, 0x3FFFU, 0x1200U),
- EMIT_MASKWRITE(0xF80007CC, 0x3FFFU, 0x1200U),
+ EMIT_MASKWRITE(0xF80007C8, 0x3FFFU, 0x0200U),
+ EMIT_MASKWRITE(0xF80007CC, 0x3FFFU, 0x0200U),
EMIT_MASKWRITE(0xF80007D0, 0x3FFFU, 0x1280U),
EMIT_MASKWRITE(0xF80007D4, 0x3FFFU, 0x1280U),
EMIT_MASKWRITE(0xF8000830, 0x003F003FU, 0x002F0037U),
--
2.25.0
Re: [PATCH] mx7ulp: soc: s_init should only be executed once
Hi Jorge, On Sun, Jan 19, 2020 at 3:52 PM Jorge Ramirez-Ortiz, Foundries wrote: > hi Favio/all > > plese could you confirm if this patch will be merged (just so we dont have to > carry it separately in our product branches) Yes, I think it makes sense to apply it. I have already given my Reviewed-by tag.
[PATCH v2] cmd: Ensure sf operates on spi flash
Currently, the sf command will probe anything attached to an spi bus, regardless
of whether it is UCLASS_SPI_FLASH. This came up when testing the mmc_spi driver,
which is accessed via spi but is UCLASS_MMC. If the uclass is not what sf
expects, then the "flash" variable will not actually have type spi_nor. This
patch adds a check so we don't clobber any data if the user requests us to probe
a device which is not an spi flash.
Signed-off-by: Sean Anderson
---
Changes for v2:
Fixed Signed-off-by line
Fix typo (SPU_FLASH -> SPI_FLASH)
cmd/sf.c | 4
1 file changed, 4 insertions(+)
diff --git a/cmd/sf.c b/cmd/sf.c
index e993b3e5ad..39d05ae229 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -132,6 +132,10 @@ static int do_spi_flash_probe(int argc, char * const
argv[])
printf("Failed to initialize SPI flash at %u:%u (error %d)\n",
bus, cs, ret);
return 1;
+ } else if (new->driver->id != UCLASS_SPI_FLASH) {
+ printf("SPI device is not SPI flash: uclass is %d, expected
%d\n",
+ new->driver->id, UCLASS_SPI_FLASH);
+ return 1;
}
flash = dev_get_uclass_priv(new);
--
2.25.0
[PATCH] cmd: Ensure sf operates on spi flash
Currently, the sf command will probe anything attached to an spi bus, regardless
of whether it is UCLASS_SPI_FLASH. This came up when testing the mmc_spi driver,
which is accessed via spi but is UCLASS_MMC. If the uclass is not what sf
expects, then the "flash" variable will not actually have type spi_nor. This
patch adds a check so we don't clobber any data if the user requests us to probe
a device which is not an spi flash.
Signed-off-by Sean Anderson
---
cmd/sf.c | 4
1 file changed, 4 insertions(+)
diff --git a/cmd/sf.c b/cmd/sf.c
index e993b3e5ad..21a410c40f 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -132,6 +132,10 @@ static int do_spi_flash_probe(int argc, char * const
argv[])
printf("Failed to initialize SPI flash at %u:%u (error %d)\n",
bus, cs, ret);
return 1;
+ } else if (new->driver->id != UCLASS_SPI_FLASH) {
+ printf("SPI device is not SPI flash: uclass is %d, expected
%d\n",
+ new->driver->id, UCLASS_SPU_FLASH);
+ return 1;
}
flash = dev_get_uclass_priv(new);
--
2.25.0
Re: [PATCH] arm: dts: imx7ulp-evk: remove mux value from pad configuration
On 17/01/20 08:51:45, Fabio Estevam wrote: > On Thu, Jan 16, 2020 at 4:40 AM Jorge Ramirez-Ortiz, Foundries > wrote: > > > > On 16/01/20 02:22:35, Peng Fan wrote: > > > > Subject: [PATCH] arm: dts: imx7ulp-evk: remove mux value from pad > > > > configuration > > > > > > > > The mux mode is embedded in the PAD definition and therefore there is no > > > > need to repeat it in the PAD configuration value (more over since this > > > > information will be masked out when the configuration value is applied). > > > > > > Has this been accepted by Shawn? > > > > added to DL now > > Mainline dts does not have backlight support, so this only affects U-Boot. yes, the dts is only incorrect in uboot (ie, any of the mux values that could be specified in the pad configuration field are just ignored)
Re: [PATCH] mx7ulp: soc: s_init should only be executed once
On 17/01/20 13:08:44, Jorge Ramirez-Ortiz, Gmail wrote: > On 17/01/20 08:53:03, Fabio Estevam wrote: > > Hi Jorge, > > > > On Fri, Jan 17, 2020 at 6:50 AM Jorge Ramirez-Ortiz > > wrote: > > > > > > On SPL enabled systems, the current s_init code (wdog, clock and ldo > > > init) is executed twice (by SPL and u-boot). This is not necessary and > > > might lead to boot issues (ie, starting PMC1 when it is already running). > > > > > > Signed-off-by: Jorge Ramirez-Ortiz > > > > The target I use to test LDO-enabled mode does not use SPL, so that's > > why I did not notice the problem. > > > > Thanks for the fix: > > Hi Favio, > > sorry I forgot to mention: this does not fix the issue I see when executing > the LDO init code - that still locks when run from SPL or U-Boot. > This commit is just because I noticed that s_init was being called twice (for > SPL and U-Boot) and I dont think it makes sense. > > > > > Reviewed-by: Fabio Estevam hi Favio/all plese could you confirm if this patch will be merged (just so we dont have to carry it separately in our product branches) thanks! Jorge
[PATCH 1/1] crypto: make mod_exp_sw() static
Function mod_exp_sw() is only used via the operators of the uclass.
It is not defined in any include.
Make mod_exp_sw() static.
Signed-off-by: Heinrich Schuchardt
---
drivers/crypto/rsa_mod_exp/mod_exp_sw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
b/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
index 5a098f83cc..46b9f1825c 100644
--- a/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
+++ b/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
@@ -9,8 +9,8 @@
#include
#include
-int mod_exp_sw(struct udevice *dev, const uint8_t *sig, uint32_t sig_len,
- struct key_prop *prop, uint8_t *out)
+static int mod_exp_sw(struct udevice *dev, const uint8_t *sig, uint32_t
sig_len,
+ struct key_prop *prop, uint8_t *out)
{
int ret = 0;
--
2.24.1
[PATCH v2 1/1] lib: Kconfig dependencies for pseudo-random library
drivers/rng/sandbox_rng.c requires rand() to be defined but configuration option CONFIG_CONFIG_LIB_RAND selected in drivers/rng/Kconfig does not exist. test/lib/test_aes.c requires rand() to be defined. Fix the selection criteria for choice "Pseudo-random library support type". Signed-off-by: Heinrich Schuchardt --- v2: fix typo in title --- drivers/rng/Kconfig | 1 - lib/Kconfig | 3 ++- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig index 35a3bd192a..893b89d49b 100644 --- a/drivers/rng/Kconfig +++ b/drivers/rng/Kconfig @@ -9,7 +9,6 @@ config DM_RNG config RNG_SANDBOX bool "Sandbox random number generator" depends on SANDBOX && DM_RNG - select CONFIG_LIB_RAND help Enable random number generator for sandbox. This is an emulation of a rng device. diff --git a/lib/Kconfig b/lib/Kconfig index d040a87d26..ab6aff710d 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -150,7 +150,8 @@ config REGEX choice prompt "Pseudo-random library support type" - depends on NET_RANDOM_ETHADDR || RANDOM_UUID || CMD_UUID + depends on NET_RANDOM_ETHADDR || RANDOM_UUID || CMD_UUID || \ + RNG_SANDBOX || UT_LIB && AES default LIB_RAND help Select the library to provide pseudo-random number generator -- 2.24.1
Re: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset driver for SPL
On 1/19/20 8:48 AM, Peng Fan wrote: [...] Because, I believe we can both agree that dumping such ad-hoc code which implements reset in board code is not the right way, esp. nowadays with all the DM/DT stuff in. >>> >>> Alought we still have ocram space, but our SPL is huge now, 100KB+ >> >> How so ? >> >> How much does DM sysreset add to that ? > > currently I am a bit hesitated about DM SPL, > but it let us not to maintain two drivers for one module. > Just some complaining words:) > I am fine to add DM sysreset currently. > Not sure how much it will add after DM usb. I have two things to say about this. 1) I share your concern about DM SPL, we have a massive size problem. Thus far, we don't have a solution. Patches welcome. One option might be to optimize out frameworks which only have one driver instance in SPL, like MMC_TINY does and have subsystem API directly call that one driver instance. 2) Hacking ad-hoc drivers in board/ files is broken design, so we need a solution, which does not do that. If we want to disregard DM sysreset in SPL for this board, we can only do that based on hard numbers, that is, measure the size impact and determine if that's an issue. If so, we need another solution. Otherwise, we enable DM sysreset and go back to solving 1) as a separate topic. -- Best regards, Marek Vasut
[PATCH 1/1] lib: Kconfig dependencies for seudo-random library
drivers/rng/sandbox_rng.c requires rand() to be defined but configuration option CONFIG_CONFIG_LIB_RAND selected in drivers/rng/Kconfig does not exist. test/lib/test_aes.c requires rand() to be defined. Fix the selection criteria for choice "Pseudo-random library support type". Signed-off-by: Heinrich Schuchardt --- drivers/rng/Kconfig | 1 - lib/Kconfig | 3 ++- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig index 35a3bd192a..893b89d49b 100644 --- a/drivers/rng/Kconfig +++ b/drivers/rng/Kconfig @@ -9,7 +9,6 @@ config DM_RNG config RNG_SANDBOX bool "Sandbox random number generator" depends on SANDBOX && DM_RNG - select CONFIG_LIB_RAND help Enable random number generator for sandbox. This is an emulation of a rng device. diff --git a/lib/Kconfig b/lib/Kconfig index d040a87d26..ab6aff710d 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -150,7 +150,8 @@ config REGEX choice prompt "Pseudo-random library support type" - depends on NET_RANDOM_ETHADDR || RANDOM_UUID || CMD_UUID + depends on NET_RANDOM_ETHADDR || RANDOM_UUID || CMD_UUID || \ + RNG_SANDBOX || UT_LIB && AES default LIB_RAND help Select the library to provide pseudo-random number generator -- 2.24.1
Re: [PATCH v2 00/10] ClearFog Base static variant support
On 2020-01-19 09:11, Baruch Siach wrote: Hi Joel, On Sun, Jan 19 2020, Joel Johnson wrote: On 2020-01-19 01:38, Baruch Siach wrote: On Sun, Jan 19 2020, Joel Johnson wrote: This patch series adds support for ClearFog Base static configuration, as well as updating and fixing the ClearFog support for MMC and SPI booting. V2 changes: - updated against, and dependent on, https://patchwork.ozlabs.org/cover/1200324 Thanks for the update. Next time please Cc at least me and Stefan on the entire series. baruch I certainly intended to, and based on the email headers it appears that I did... Actually, I see what you're saying, not all of the patches in the series were delivered to you. I neglected to add (or notice during sending) the Series-cc line for patman. My apologizes - I've added it for my local branch on this series and I'll keep an eye out for that in the future. Relatedly, I've been directing the series to Prafulla Wadaskar as noted in the custodians listing for marvell, but am getting email delivery failures. Any updated guidance or contact updates would be appreciated. Prafulla has been removed from the Marvell entry in MAINTAINERS in commit 1579faf52b9f4 (February 2019). I don't think you need to Cc him on Marvell SoC related patches. baruch Indeed, thanks. I had pulled his information from the Custodians wiki page at http://www.denx.de/wiki/U-Boot/Custodians, so perhaps something that Stefan or editor can update accordingly. Joel
Re: [PATCH 0/4] Updates for ClearFog EEPROM
On 2020-01-19 01:41, Baruch Siach wrote: Hi Joel, On Sun, Jan 19 2020, Joel Johnson wrote: On 2020-01-19 00:22, Baruch Siach wrote: On Sun, Jan 19 2020, Joel Johnson wrote: This set of patches applies on top of https://patchwork.ozlabs.org/cover/1200324/, based on testing using the static configuration fallback updates in a related patch series. Thank you very much. I'm currently working on an updated series with some significant changes. These include rename of sys_eeprom to tlv_eeprom; move of TLV parse code to board/solidrun/common/; and support for TLV read in pre-relocation phase. I'll add your fixes where applicable. I hope to post v2 in the coming week. baruch Sounds good, thanks! I'm also getting ready to shoot out a V2 of my static ClearFog Base support which based on prior review I've rebased on your run-time config series. If it works for you, I'll go ahead and still send that out for review, modulo your further changes. Are you expecting the TLV/EEPROM change updates to be included in time for the current merge window? I hope to have TLV EEPROM ready for v2020.04. baruch Hmm, I was hoping to have the static config for ClearFog Base merged in the current merge window, so just to be clear is that what you're targeting by v2020.04 as well? With my recent rebasing, I believe I made the changes compatible between static and runtime configuration, but it's less important what order they're applied in - i.e. I can rebase again back on master and retain the alignment. Perhaps it would be possible to merge the static changes and then update the static config entries' help text with a subsequent merge of your runtime work? Joel
Re: [PATCH v2 00/10] ClearFog Base static variant support
Hi Joel,
On Sun, Jan 19 2020, Joel Johnson wrote:
> On 2020-01-19 01:38, Baruch Siach wrote:
>> On Sun, Jan 19 2020, Joel Johnson wrote:
>>> This patch series adds support for ClearFog Base static configuration,
>>> as well as updating and fixing the ClearFog support for MMC and SPI
>>> booting.
>>>
>>> V2 changes:
>>> - updated against, and dependent on,
>>> https://patchwork.ozlabs.org/cover/1200324
>>
>> Thanks for the update.
>>
>> Next time please Cc at least me and Stefan on the entire series.
>>
>> baruch
>
> I certainly intended to, and based on the email headers it appears that I
> did...
>
> Actually, I see what you're saying, not all of the patches in the series were
> delivered to you. I neglected to add (or notice during sending) the Series-cc
> line for patman. My apologizes - I've added it for my local branch on this
> series and I'll keep an eye out for that in the future.
>
> Relatedly, I've been directing the series to Prafulla Wadaskar as noted in the
> custodians listing for marvell, but am getting email delivery failures. Any
> updated guidance or contact updates would be appreciated.
Prafulla has been removed from the Marvell entry in MAINTAINERS in
commit 1579faf52b9f4 (February 2019). I don't think you need to Cc him
on Marvell SoC related patches.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH v2 00/10] ClearFog Base static variant support
On 2020-01-19 01:38, Baruch Siach wrote: Hi Joel, On Sun, Jan 19 2020, Joel Johnson wrote: This patch series adds support for ClearFog Base static configuration, as well as updating and fixing the ClearFog support for MMC and SPI booting. V2 changes: - updated against, and dependent on, https://patchwork.ozlabs.org/cover/1200324 Thanks for the update. Next time please Cc at least me and Stefan on the entire series. baruch I certainly intended to, and based on the email headers it appears that I did... Actually, I see what you're saying, not all of the patches in the series were delivered to you. I neglected to add (or notice during sending) the Series-cc line for patman. My apologizes - I've added it for my local branch on this series and I'll keep an eye out for that in the future. Relatedly, I've been directing the series to Prafulla Wadaskar as noted in the custodians listing for marvell, but am getting email delivery failures. Any updated guidance or contact updates would be appreciated. Joel
Re: [PATCH v2 01/21] mips: add support to restore exception vector base before booting linux
On Sun, 2020-01-19 at 12:18 +0800, Weijie Gao wrote:
> On Fri, 2020-01-17 at 13:15 +0100, Daniel Schwierzeck wrote:
> >
> > Am 17.01.20 um 08:45 schrieb Weijie Gao:
> > > In U-Boot the exception vector base will be moved to top of memory, to be
> > > used to display register dump when exception occurs.
> > >
> > > But some old linux kernel does not honor the base set in CP0_EBASE. A
> > > modified exception vector base will cause kernel crash.
> > >
> > > This patch adds an option to enable reset exception vector base to its
> > > previous value, or a user configured value before booting linux kernel.
> > >
> > > Signed-off-by: Weijie Gao
> > > ---
> > > Changes since v1:
> > > Moved core operations to trap_restore() in arch/mips/lib/traps.c.
> > > Save previous ebase instead of using 0x8000 directly.
> > > Add options to use customized ebase.
> > > ---
> > > arch/mips/Kconfig | 30 +
> > > arch/mips/include/asm/u-boot-mips.h | 2 ++
> > > arch/mips/lib/bootm.c | 3 +++
> > > arch/mips/lib/traps.c | 19 ++
> > > 4 files changed, 54 insertions(+)
> > >
> > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> > > index a3ae603044..5e20feeefb 100644
> > > --- a/arch/mips/Kconfig
> > > +++ b/arch/mips/Kconfig
> > > @@ -287,6 +287,36 @@ config MIPS_RELOCATION_TABLE_SIZE
> > >
> > > If unsure, leave at the default value.
> > >
> > > +config RESTORE_EXCEPTION_VECTOR_BASE
> > > + bool "Restore exception vector base before booting linux kernel"
> > > + default n
> > > + help
> > > + In U-Boot the exception vector base will be moved to top of memory,
> > > + to be used to display register dump when exception occurs.
> > > + But some old linux kernel does not honor the base set in CP0_EBASE.
> > > + A modified exception vector base will cause kernel crash.
> > > +
> > > + This option will restore the exception vector base to its previous
> > > + value.
> > > +
> > > + If unsure, say N.
> > > +
> > > +config OVERRIDE_EXCEPTION_VECTOR_BASE
> > > + bool "Override the exception vector base to be restored"
> > > + depends on RESTORE_EXCEPTION_VECTOR_BASE
> > > + default n
> > > + help
> > > + Enable this option if you want to use a different exception vector
> > > + base rather than the previously saved one.
> > > +
> > > +config NEW_EXCEPTION_VECTOR_BASE
> > > + hex "New exception vector base"
> > > + depends on OVERRIDE_EXCEPTION_VECTOR_BASE
> > > + range 0x8000 0xb000
> > > + default 0x8000
> > > + help
> > > + The exception vector base to be restored before booting linux kernel
> > > +
> > > endmenu
> > >
> > > menu "OS boot interface"
> > > diff --git a/arch/mips/include/asm/u-boot-mips.h
> > > b/arch/mips/include/asm/u-boot-mips.h
> > > index 88438b9576..8b37cc4029 100644
> > > --- a/arch/mips/include/asm/u-boot-mips.h
> > > +++ b/arch/mips/include/asm/u-boot-mips.h
> > > @@ -9,4 +9,6 @@ void except_vec_ejtag_debug(void);
> > >
> > > int arch_misc_init(void);
> > >
> > > +void trap_restore(void);
> > > +
> > > #endif /* _U_BOOT_MIPS_H_ */
> > > diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
> > > index 8c0d7672f2..f1db6d23b8 100644
> > > --- a/arch/mips/lib/bootm.c
> > > +++ b/arch/mips/lib/bootm.c
> > > @@ -294,6 +294,9 @@ static void boot_jump_linux(bootm_headers_t *images)
> > > bootstage_report();
> > > #endif
> > >
> > > + if (CONFIG_IS_ENABLED(RESTORE_EXCEPTION_VECTOR_BASE))
> > > + trap_restore();
> > > +
> > > if (images->ft_len)
> > > kernel(-2, (ulong)images->ft_addr, 0, 0);
> > > else
> > > diff --git a/arch/mips/lib/traps.c b/arch/mips/lib/traps.c
> > > index 6fe8ebd16b..20f45fc4ed 100644
> > > --- a/arch/mips/lib/traps.c
> > > +++ b/arch/mips/lib/traps.c
> > > @@ -19,6 +19,8 @@
> > >
> > > DECLARE_GLOBAL_DATA_PTR;
> > >
> > > +static unsigned long saved_ebase;
> > > +
> > > static void show_regs(const struct pt_regs *regs)
> > > {
> > > const int field = 2 * sizeof(unsigned long);
> > > @@ -101,7 +103,24 @@ void trap_init(ulong reloc_addr)
> > > set_handler(0x180, _vec3_generic, 0x80);
> > > set_handler(0x280, _vec_ejtag_debug, 0x80);
> > >
> > > + saved_ebase = read_c0_ebase() & 0xf000;
> > > +
> > > write_c0_ebase(ebase);
> > > clear_c0_status(ST0_BEV);
> > > execution_hazard_barrier();
> > > }
> > > +
> > > +void trap_restore(void)
> > > +{
> > > + set_c0_status(ST0_BEV);
> > > + execution_hazard_barrier();
> > > +
> > > +#ifdef CONFIG_OVERRIDE_EXCEPTION_VECTOR_BASE
> > > + write_c0_ebase(CONFIG_NEW_EXCEPTION_VECTOR_BASE & 0xf000);
> > > +#else
> > > + write_c0_ebase(saved_ebase);
> > > +#endif
> > > +
> > > + clear_c0_status(ST0_BEV);
> > > + execution_hazard_barrier();
> > > +}
> > >
> >
> > looks actually good now, thanks. But now I'm thinking that it should be
> > enough to simply set ST0_BEV to use the CPU's default EBase. Restoring
> > the original EBase and
Re: [PATCH 0/4] Updates for ClearFog EEPROM
Hi Joel,
On Sun, Jan 19 2020, Joel Johnson wrote:
> On 2020-01-19 00:22, Baruch Siach wrote:
>> On Sun, Jan 19 2020, Joel Johnson wrote:
>>> This set of patches applies on top of
>>> https://patchwork.ozlabs.org/cover/1200324/,
>>> based on testing using the static configuration fallback updates in a
>>> related patch series.
>>
>> Thank you very much.
>>
>> I'm currently working on an updated series with some significant
>> changes. These include rename of sys_eeprom to tlv_eeprom; move of TLV
>> parse code to board/solidrun/common/; and support for TLV read in
>> pre-relocation phase. I'll add your fixes where applicable.
>>
>> I hope to post v2 in the coming week.
>>
>> baruch
>
> Sounds good, thanks! I'm also getting ready to shoot out a V2 of my static
> ClearFog Base support which based on prior review I've rebased on your
> run-time config series. If it works for you, I'll go ahead and still send that
> out for review, modulo your further changes. Are you expecting the TLV/EEPROM
> change updates to be included in time for the current merge window?
I hope to have TLV EEPROM ready for v2020.04.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH v2 00/10] ClearFog Base static variant support
Hi Joel,
On Sun, Jan 19 2020, Joel Johnson wrote:
> This patch series adds support for ClearFog Base static configuration,
> as well as updating and fixing the ClearFog support for MMC and SPI
> booting.
>
> V2 changes:
> - updated against, and dependent on,
> https://patchwork.ozlabs.org/cover/1200324
Thanks for the update.
Next time please Cc at least me and Stefan on the entire series.
baruch
> Joel Johnson (10):
> arm: mvebu: fix SerDes table alignment
> arm: mvebu: solidrun: remove hardcoded DTS MAC address
> arm: mvebu: clearfog: initial ClearFog Base variant
> arm: mvebu: clearfog: Use Pro DT by default
> arm: mvebu: clearfog: Add SATA mode flags
> arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
> arm: mvebu: clearfog: add SPI offsets
> arm: mvebu: enable working default boot support
> arm: mvebu: clearfog: move ENV params to Kconfig
> arm: mvebu: clearfog: reduce MMC boot assumptions
>
> .../arm/dts/armada-38x-solidrun-microsom.dtsi | 1 -
> arch/arm/mach-mvebu/Kconfig | 13
> .../serdes/a38x/high_speed_env_spec.c | 6 +-
> board/solidrun/clearfog/Kconfig | 62 +++
> board/solidrun/clearfog/clearfog.c| 26 +++-
> configs/clearfog_defconfig| 5 --
> include/configs/clearfog.h| 1 -
> 7 files changed, 103 insertions(+), 11 deletions(-)
> create mode 100644 board/solidrun/clearfog/Kconfig
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] lib: rsa: consider CONFIG_SPL_RSA
CONFIG_SPL_RSA is meant to control if lib/rsa/* is used for SPL. Adjust
lib/Makefile to consider this setting.
This was correctly setup with commit 51c14cd128f4 ("verified-boot: Minimal
support for booting U-Boot proper from SPL") and got lost with commit
089df18bfe9d ("lib: move hash CONFIG options to Kconfig").
Fixes: 089df18bfe9d ("lib: move hash CONFIG options to Kconfig")
Signed-off-by: Heinrich Schuchardt
---
There currently is no CONFIG_TPL_RSA. I guess it is save to leave the
TPL case unchanged.
---
lib/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Makefile b/lib/Makefile
index 51eba80b89..15259d0473 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -58,7 +58,7 @@ obj-$(CONFIG_TPM_V1) += tpm-v1.o
obj-$(CONFIG_TPM_V2) += tpm-v2.o
endif
-obj-$(CONFIG_RSA) += rsa/
+obj-$(CONFIG_$(SPL_)RSA) += rsa/
obj-$(CONFIG_SHA1) += sha1.o
obj-$(CONFIG_SHA256) += sha256.o
--
2.24.1
