[PATCH] arm64: zynqmp: Do not clear reset reason
There is no need to clear reset reason register because it is protected by PMUFW already which is reported when verbose log is enabled as: pm_core.c@733 APU> No write permission to 0xFF5E0220 Signed-off-by: Michal Simek --- board/xilinx/zynqmp/zynqmp.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c index a216eeb35f15..6babc0ebce3e 100644 --- a/board/xilinx/zynqmp/zynqmp.c +++ b/board/xilinx/zynqmp/zynqmp.c @@ -496,11 +496,7 @@ static int reset_reason(void) env_set("reset_reason", reason); - ret = zynqmp_mmio_write((ulong)_base->reset_reason, ~0, ~0); - if (ret) - return -EINVAL; - - return ret; + return 0; } static int set_fdtfile(void) -- 2.30.0
Re: [PATCH] efi_loader: don't load beyond VirtualSize
On 2/9/21 7:48 AM, Heinrich Schuchardt wrote: Am 9. Februar 2021 07:19:48 MEZ schrieb Asherah Connor : PE section table entries' SizeOfRawData must be a multiple of FileAlignment, and thus may be rounded up and larger than their VirtualSize. We should not load beyond the VirtualSize, which is "the total size of the section when loaded into memory" -- we may clobber real data at the target in some other section, since we load sections in reverse order and sections are usually laid out sequentially. Thank you for reporting and addressing the issue. Is this patch related to an observed problem or is it resulting from code review? Should we load in forward order? Signed-off-by: Asherah Connor CC: Heinrich Schuchardt --- lib/efi_loader/efi_image_loader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_image_loader.c b/lib/efi_loader/efi_image_loader.c index d4dd9e9433..f53ef367ec 100644 --- a/lib/efi_loader/efi_image_loader.c +++ b/lib/efi_loader/efi_image_loader.c @@ -843,7 +843,7 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle, sec->Misc.VirtualSize); memcpy(efi_reloc + sec->VirtualAddress, efi + sec->PointerToRawData, - sec->SizeOfRawData); + min(sec->Misc.VirtualSize, sec->SizeOfRawData)); } If SizeOfRawData must be >= VirtualSize, why do we have to consider both fields? The PE-COFF spec [1] says: SizeOfRawData The size of the section (for object files) or the size of the initialized data on disk (for image files). For executable images, this must be a multiple of FileAlignment from the optional header. If this is less than VirtualSize, the remainder of the section is zero-filled. Because the SizeOfRawData field is rounded but the VirtualSize field is not, it is possible for SizeOfRawData to be greater than VirtualSize as well. When a section contains only uninitialized data, this field should be zero. So SizeOfRawData can be both smaller and greater then VirtualSize. We zero the memory before copying the data. This covers the case SizeOfRawData < VirtualSize. Reviewed-by: Heinrich Schuchardt [1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format Best regards Heinrich /* Run through relocations */
RE: [PATCH 07/13] arm: aspeed: Disable ATAGs support
Hi Tom, I have tested this patch with Aspeed SDK as well as the U-Boot mainline codebase on AST2500/AST2600 EVBs. Both AST2500/AST2600 can boot to kernel normally. Thanks. Chiawei Tested-by: Chia-Wei Wang > -Original Message- > From: Tom Rini > Sent: Thursday, February 4, 2021 10:24 AM > To: u-boot@lists.denx.de > Cc: Ryan Chen ; ChiaWei Wang > ; BMC-SW > Subject: [PATCH 07/13] arm: aspeed: Disable ATAGs support > > This platform never had to support an ATAGs-based Linux kernel, so remove > the support for it. > > Cc: Ryan Chen > Cc: Chia-Wei Wang > Cc: Aspeed BMC SW team > Signed-off-by: Tom Rini > --- > I'm assuming, please correct me if I'm wrong. > --- > include/configs/aspeed-common.h | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/include/configs/aspeed-common.h > b/include/configs/aspeed-common.h index df0f5d2e76f7..8d666c6ed415 > 100644 > --- a/include/configs/aspeed-common.h > +++ b/include/configs/aspeed-common.h > @@ -12,11 +12,6 @@ > > #include > > -/* Misc CPU related */ > -#define CONFIG_CMDLINE_TAG > -#define CONFIG_SETUP_MEMORY_TAGS > -#define CONFIG_INITRD_TAG > - > #define CONFIG_SYS_SDRAM_BASEASPEED_DRAM_BASE > > #ifdef CONFIG_PRE_CON_BUF_SZ > -- > 2.17.1
Re: [PATCH v4] fastboot: add UUU command UCmd and ACmd support
Hello Patrick, On 08.02.21 17:56, Patrick DELAUNAY wrote: > Hi Heiko, > > > On 2/8/21 12:38 PM, Heiko Schocher wrote: >> add support for the UUU commands ACmd and UCmd. >> >> Enable them through the Kconfig option >> CONFIG_FASTBOOT_UUU_SUPPORT >> >> base was commit in NXP kernel >> 9b149c2a2882: ("MLK-18591-3 android: Add FSL android fastboot support") >> >> and ported it to current mainline. Tested this patch >> on imx6ul based board. >> >> Signed-off-by: Heiko Schocher >> --- >> >> azure build was fine: >> https://dev.azure.com/hs0298/hs/_build/results?buildId=59=results >> >> Changes in v4: >> - fixed missing parts from Sean Anderson patches >> lost while rebased to tree from lukasz >> >> Changes in v3: >> - rebased to https://github.com/lmajewski/u-boot-dfu/commits/testing >> as Lukasz mentioned. >> >> Changes in v2: >> - remove unused FSL_FASTBOOT option >> - add comment from Roman: >> do not enable this option per default >> add Kconfig comment that enabling this option may >> introduce a security issue. >> >> doc/android/fastboot-protocol.rst | 5 +++ >> doc/android/fastboot.rst | 2 + >> drivers/fastboot/Kconfig | 9 + >> drivers/fastboot/fb_command.c | 62 +++ >> drivers/usb/gadget/f_fastboot.c | 17 + >> include/fastboot.h | 7 >> 6 files changed, 102 insertions(+) >> > (...) >> diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c >> index 41fc8d7904d..960e73089e0 100644 >> --- a/drivers/fastboot/fb_command.c >> +++ b/drivers/fastboot/fb_command.c > (...) >> + >> +static char g_a_cmd_buff[64]; >> + >> +void fastboot_acmd_complete(void) >> +{ >> + run_command(g_a_cmd_buff, 0); >> +} >> + >> +/** >> + * run_acmd() - Execute the ACmd command >> + * >> + * @cmd_parameter: Pointer to command parameter >> + * @response: Pointer to fastboot response buffer >> + */ >> +static void run_acmd(char *cmd_parameter, char *response) >> +{ >> + if (!cmd_parameter) { >> + pr_err("missing slot suffix\n"); >> + fastboot_fail("missing command", response); >> + return; >> + } >> + >> + strcpy(g_a_cmd_buff, cmd_parameter); > > > to avoid overflow: > > > + strncpy (g_a_cmd_buff, cmd_parameter, sizeof(g_a_cmd_buff)); > > > or check strlen(cmd_parameter) ? > > > + if (check strlen(cmd_parameter) > sizeof(g_a_cmd_buff)) { > > + pr_err("too long command\n"); > > + fastboot_fail("too long command", response); > + return; > + } Yes, good catch, thanks! I send a v5 with checking the length and error message >> + fastboot_okay(NULL, response); >> +} >> +#endif >> + >> /** >> * reboot_bootloader() - Sets reboot bootloader flag. >> * >> diff --git a/drivers/usb/gadget/f_fastboot.c >> b/drivers/usb/gadget/f_fastboot.c >> index 950cc119495..8ba55aab9f8 100644 >> --- a/drivers/usb/gadget/f_fastboot.c >> +++ b/drivers/usb/gadget/f_fastboot.c >> @@ -494,6 +494,18 @@ static void do_bootm_on_complete(struct usb_ep *ep, >> struct usb_request *req) >> do_exit_on_complete(ep, req); >> } >> > (...) > > Anyway, except this remark. > > Acked-by: Patrick Delaunay bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
On 9/02/21 3:07 pm, Marek Behun wrote: > On Tue, 9 Feb 2021 01:08:54 + > Chris Packham wrote: > >> On 9/02/21 1:16 pm, Chris Packham wrote: >>> On 9/02/21 9:18 am, Marek Behun wrote: On Mon, 8 Feb 2021 20:11:06 + Chris Packham wrote: > Hi Marek, > > Do you have this in a repo I can pull from? I've got a couple of boards > I can give this a spin on. https://gitlab.nic.cz/turris/turris-omnia-uboot/ branch v2021.04-rc-mv-ddr-14.0.0 also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that one contains one more commit that is needed for Omnia with Samsung DDR chips. >>> I've tested the dm-88f6820-amc board. Training completed without >>> issue, as does memtester running from Linux. >>> >>> Hit a bit of a snag on the x530 because the changes pushed it over the >>> SPL size (it was already pretty close). I'll look to see if there's >>> anything I can drop out or maybe bump the SPL size (I never did get a >>> clear answer from Marvell as to what the size limit actually is). >> I can temporarily work around the size issue by disabling watchdog >> support in SPL (I really don't want that to be the long term solution). >> >> But then I encounter an odd problem. When I "reset" the board gets >> through the DDR training but never makes it to u-boot proper, but if I >> power cycle it boots through to the u-boot prompt. This doesn't happen >> on the db-88f6820-amc board. One difference between the x530 and the amc >> board is that the x530 has ECC so maybe something is going into the >> weeds if ECC has already been enabled by a previous boot. >> > Could you bisect which commit causes this? Seems to be the last one (ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision) not entirely sure what the problem is. So I guess you can consider the upstream update good, the fix SPLIT_OUT_MIX not so much it happens to be the thing that causes the issue and the straw that tips the build size over the limit.
Re: [PATCH] efi_loader: don't load beyond VirtualSize
Am 9. Februar 2021 07:19:48 MEZ schrieb Asherah Connor : >PE section table entries' SizeOfRawData must be a multiple of >FileAlignment, and thus may be rounded up and larger than their >VirtualSize. > >We should not load beyond the VirtualSize, which is "the total size of >the section when loaded into memory" -- we may clobber real data at the >target in some other section, since we load sections in reverse order >and sections are usually laid out sequentially. Thank you for reporting and addressing the issue. Is this patch related to an observed problem or is it resulting from code review? Should we load in forward order? > >Signed-off-by: Asherah Connor >CC: Heinrich Schuchardt >--- > lib/efi_loader/efi_image_loader.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/lib/efi_loader/efi_image_loader.c >b/lib/efi_loader/efi_image_loader.c >index d4dd9e9433..f53ef367ec 100644 >--- a/lib/efi_loader/efi_image_loader.c >+++ b/lib/efi_loader/efi_image_loader.c >@@ -843,7 +843,7 @@ efi_status_t efi_load_pe(struct >efi_loaded_image_obj *handle, > sec->Misc.VirtualSize); > memcpy(efi_reloc + sec->VirtualAddress, > efi + sec->PointerToRawData, >- sec->SizeOfRawData); >+ min(sec->Misc.VirtualSize, sec->SizeOfRawData)); > } If SizeOfRawData must be >= VirtualSize, why do we have to consider both fields? Best regards Heinrich > > /* Run through relocations */
Re: [PATCH 1/1] sandbox: allow cross-compiling sandbox
Am 9. Februar 2021 06:30:31 MEZ schrieb AKASHI Takahiro : >On Mon, Feb 08, 2021 at 09:29:43PM -0700, Simon Glass wrote: >> Hi Heinrich, >> >> On Mon, 8 Feb 2021 at 15:06, Heinrich Schuchardt >wrote: >> > >> > UEFI test files like helloworld.efi require an architecture >specific >> > PE-COFF header. >> >> architecture-specific >> >> > >> > For non-sandbox the PE-COFF header is chosen by the target >architecture. >> > For the sandbox we use the host architecture. This is not helpful >for cross >> > compiling. Allow specifying the target architecture of the sandbox >via >> > environment variable MK_ARCH, e.g. >> >> What exactly is the target arch? Is the the one that sandbox is >> running on, or something else? >> >> > >> > make sandbox_defconfig NO_SDL=1 >> > CROSS_COMPILE=aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make >> > >> > Signed-off-by: Heinrich Schuchardt >> > --- >> > Makefile | 2 +- >> > doc/arch/sandbox.rst | 14 ++ >> > 2 files changed, 15 insertions(+), 1 deletion(-) >> > >> > diff --git a/Makefile b/Makefile >> > index 23dd11f723..286e5148ae 100644 >> > --- a/Makefile >> > +++ b/Makefile >> > @@ -19,7 +19,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR) >> > >> > # Determine host architecture >> > include include/host_arch.h >> > -MK_ARCH="${shell uname -m}" >> > +MK_ARCH?="${shell uname -m}" >> > unexport HOST_ARCH >> > ifeq ("x86_64", $(MK_ARCH)) >> >export HOST_ARCH=$(HOST_ARCH_X86_64) >> > diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst >> > index 60ee1e0741..0dd9edc8cb 100644 >> > --- a/doc/arch/sandbox.rst >> > +++ b/doc/arch/sandbox.rst >> > @@ -33,6 +33,20 @@ integers can only be built on 64-bit hosts. >> > >> > Note that standalone/API support is not available at present. >> > >> > +Cross compiling >> > +--- >> > + >> > +When cross compiling the U-Boot sandbox with CONFIG_EFI_LOADER=y >the target >> > +architecture must be specified using the MK_ARCH environment >variable using one >> > +of the values aarch64, armv7l, i386, riscv32, riscv64, x86_64, >e.g. >> >> OK, but what is the target architecture? I'm just not sure from your >> comments what this actually means. > >I'm not quite sure if it is very useful to be able to cross-compile >the sandbox application. But any way, it is not very convenient Building the sandbox on ARMv7 is broken due to patch introduced in 2020. We get loads of warnings when building for 32bit. We should integrate building the sandbox for different architectures into Gitlab CI. >to always enforce users to explicitly specify "target" architecture. >How about trying the following first? >$(CC) -v | grep "Target: " | sed -e 's/-*$//' > >It will give us a hint about the architecture. >("--print-multiarch" shows a similar triple, but this option won't >work for some pre-built gcc, like aarch64 gcc from Arm.) Did you check clang? Is the output format specified? Will this be stable for compiler versions to come? Given the --print-multiarch failure probably not. When compiling Linux you also have to supply CROSS_COMPILER and ARCH. For me it is anyway a Gitlab CI thing. Nothing a user would typically use. Best regards Heinrich > >> Does MK mean make? > >I prefer another name for clarity. > >-Takahiro Akashi > >> >> > + >> > +.. code-block:: bash >> > + >> > +NO_SDL=1 make sandbox_defconfig >> > +CROSS_COMPILE=aarch64-linux-gnu- MK_ARCH=aarch64 NO_SDL=1 make >> > + >> > +NO_SDL=1 was chosen in the example to remove the dependency on the >SDL library. >> > +The graphical console will not be available. >> > >> > Prerequisites >> > - >> > -- >> > 2.30.0 >> > >> >> Regards, >> Simon
Re: [PATCH 1/1] sandbox: allow cross-compiling sandbox
Am 9. Februar 2021 05:29:43 MEZ schrieb Simon Glass : >Hi Heinrich, > >On Mon, 8 Feb 2021 at 15:06, Heinrich Schuchardt >wrote: >> >> UEFI test files like helloworld.efi require an architecture specific >> PE-COFF header. > >architecture-specific > >> >> For non-sandbox the PE-COFF header is chosen by the target >architecture. >> For the sandbox we use the host architecture. This is not helpful for >cross >> compiling. Allow specifying the target architecture of the sandbox >via >> environment variable MK_ARCH, e.g. > >What exactly is the target arch? Is the the one that sandbox is >running on, or something else? It is the architecture that the binary can be run on > >> >> make sandbox_defconfig NO_SDL=1 >> CROSS_COMPILE=aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make >> >> Signed-off-by: Heinrich Schuchardt >> --- >> Makefile | 2 +- >> doc/arch/sandbox.rst | 14 ++ >> 2 files changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/Makefile b/Makefile >> index 23dd11f723..286e5148ae 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -19,7 +19,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR) >> >> # Determine host architecture >> include include/host_arch.h >> -MK_ARCH="${shell uname -m}" >> +MK_ARCH?="${shell uname -m}" >> unexport HOST_ARCH >> ifeq ("x86_64", $(MK_ARCH)) >>export HOST_ARCH=$(HOST_ARCH_X86_64) >> diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst >> index 60ee1e0741..0dd9edc8cb 100644 >> --- a/doc/arch/sandbox.rst >> +++ b/doc/arch/sandbox.rst >> @@ -33,6 +33,20 @@ integers can only be built on 64-bit hosts. >> >> Note that standalone/API support is not available at present. >> >> +Cross compiling >> +--- >> + >> +When cross compiling the U-Boot sandbox with CONFIG_EFI_LOADER=y the >target >> +architecture must be specified using the MK_ARCH environment >variable using one >> +of the values aarch64, armv7l, i386, riscv32, riscv64, x86_64, e.g. > >OK, but what is the target architecture? I'm just not sure from your >comments what this actually means. See above. > >Does MK mean make? What name do you suggest? Best regards Heinrich > >> + >> +.. code-block:: bash >> + >> +NO_SDL=1 make sandbox_defconfig >> +CROSS_COMPILE=aarch64-linux-gnu- MK_ARCH=aarch64 NO_SDL=1 make >> + >> +NO_SDL=1 was chosen in the example to remove the dependency on the >SDL library. >> +The graphical console will not be available. >> >> Prerequisites >> - >> -- >> 2.30.0 >> > >Regards, >Simon
Re: [PATCH v4 5/9] mtd: spi-nor-core: Add the ->ready() hook
Hi Pratyush, Thank you for the feedback. I will address this in v5. On 1/30/2021 3:49 AM, Pratyush Yadav wrote: > Hi, > > On 28/01/21 01:36PM, tkuw584...@gmail.com wrote: >> From: Takahiro Kuwano >> >> For dual/quad die package devices from Spansion/Cypress, the device's >> status needs to be checked by reading status registers in all dies, by >> using Read Any Register command. To support this, a Flash specific hook >> that can overwrite the legacy status check is needed. >> >> The spansion_sr_ready() reads status register 1 by Read Any Register >> commnad. This function is called from Flash specific hook with die address >> and dummy cycles. >> >> Signed-off-by: Takahiro Kuwano >> --- >> drivers/mtd/spi/spi-nor-core.c | 32 >> include/linux/mtd/spi-nor.h| 4 +++- >> 2 files changed, 35 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c >> index 624e730524..1c0ba5abf9 100644 >> --- a/drivers/mtd/spi/spi-nor-core.c >> +++ b/drivers/mtd/spi/spi-nor-core.c >> @@ -522,6 +522,35 @@ static int set_4byte(struct spi_nor *nor, const struct >> flash_info *info, >> } >> } >> >> +#ifdef CONFIG_SPI_FLASH_SPANSION >> +/* >> + * Read status register 1 by using Read Any Register command to support >> multi >> + * die package parts. >> + */ >> +static int spansion_sr_ready(struct spi_nor *nor, u32 addr_base, u8 dummy) >> +{ >> +u32 reg_addr = addr_base + SPINOR_REG_ADDR_STR1V; >> +u8 sr; >> +int ret; >> + >> +ret = spansion_read_any_reg(nor, reg_addr, dummy, ); >> +if (ret < 0) >> +return ret; >> + >> +if (sr & (SR_E_ERR | SR_P_ERR)) { >> +if (sr & SR_E_ERR) >> +dev_dbg(nor->dev, "Erase Error occurred\n"); >> +else >> +dev_dbg(nor->dev, "Programming Error occurred\n"); >> + >> +nor->write_reg(nor, SPINOR_OP_CLSR, NULL, 0); >> +return -EIO; >> +} >> + >> +return !(sr & SR_WIP); >> +} >> +#endif >> + > > Do not add this function in this patch. Just add the hook here. Add it > in the patch that actually uses it. > >> static int spi_nor_sr_ready(struct spi_nor *nor) >> { >> int sr = read_sr(nor); >> @@ -570,6 +599,9 @@ static int spi_nor_ready(struct spi_nor *nor) >> { >> int sr, fsr; >> >> +if (nor->ready) >> +return nor->ready(nor); >> + > > Move the code below in a separate function and call it something like > spi_nor_default_ready(). Then call that function from here. > >> sr = spi_nor_sr_ready(nor); >> if (sr < 0) >> return sr; >> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h >> index e31073eb24..25234177de 100644 >> --- a/include/linux/mtd/spi-nor.h >> +++ b/include/linux/mtd/spi-nor.h >> @@ -434,8 +434,9 @@ struct flash_info; >> * @flash_lock: [FLASH-SPECIFIC] lock a region of the SPI NOR >> * @flash_unlock: [FLASH-SPECIFIC] unlock a region of the SPI NOR >> * @flash_is_locked:[FLASH-SPECIFIC] check if a region of the SPI >> NOR is >> - * @quad_enable:[FLASH-SPECIFIC] enables SPI NOR quad mode >> * completely locked >> + * @quad_enable:[FLASH-SPECIFIC] enables SPI NOR quad mode >> + * @ready: [FLASH-SPECIFIC] check if the flash is ready >> * @priv: the private data >> */ >> struct spi_nor { >> @@ -481,6 +482,7 @@ struct spi_nor { >> int (*flash_unlock)(struct spi_nor *nor, loff_t ofs, uint64_t len); >> int (*flash_is_locked)(struct spi_nor *nor, loff_t ofs, uint64_t len); >> int (*quad_enable)(struct spi_nor *nor); >> +int (*ready)(struct spi_nor *nor); >> >> void *priv; >> /* Compatibility for spi_flash, remove once sf layer is merged with mtd */ >> -- >> 2.25.1 >> > Best Regards, Takahiro
Re: [PATCH v4 4/9] mtd: spi-nor-core: Add support for volatile QE bit
Hi Pratyush, On 1/30/2021 3:40 AM, Pratyush Yadav wrote: > Hi, > > On 28/01/21 01:36PM, tkuw584...@gmail.com wrote: >> From: Takahiro Kuwano >> >> Some of Spansion/Cypress chips support volatile version of configuration >> registers and it is recommended to update volatile registers in the field >> application due to a risk of the non-volatile registers corruption by >> power interrupt. This patch adds a function to set Quad Enable bit in CFR1 >> volatile. >> >> Signed-off-by: Takahiro Kuwano >> --- >> drivers/mtd/spi/spi-nor-core.c | 53 ++ >> 1 file changed, 53 insertions(+) >> >> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c >> index 2803536ed5..624e730524 100644 >> --- a/drivers/mtd/spi/spi-nor-core.c >> +++ b/drivers/mtd/spi/spi-nor-core.c >> @@ -1576,6 +1576,59 @@ static int spansion_read_cr_quad_enable(struct >> spi_nor *nor) >> return 0; >> } >> >> +/** >> + * spansion_quad_enable_volatile() - enable Quad I/O mode in volatile >> register. >> + * @nor:pointer to a 'struct spi_nor' >> + * @addr_base: base address of register (can be >0 in multi-die parts) >> + * @dummy: number of dummy cycles for register read >> + * >> + * It is recommended to update volatile registers in the field application >> due >> + * to a risk of the non-volatile registers corruption by power interrupt. >> This >> + * function sets Quad Enable bit in CFR1 volatile. >> + * >> + * Return: 0 on success, -errno otherwise. >> + */ >> +static int spansion_quad_enable_volatile(struct spi_nor *nor, u32 addr_base, >> + u8 dummy) >> +{ >> +u32 addr = addr_base | SPINOR_REG_ADDR_CFR1V; > > Why do you OR the register offset with the base? Shouldn't you be adding > to it? > I missed it during review... I will fix. >> + >> +u8 cr; >> +int ret; >> + >> +/* Check current Quad Enable bit value. */ >> +ret = spansion_read_any_reg(nor, addr, dummy, ); >> +if (ret < 0) { >> +dev_dbg(nor->dev, >> +"error while reading configuration register\n"); >> +return -EINVAL; >> +} >> + >> +if (cr & CR_QUAD_EN_SPAN) >> +return 0; >> + >> +cr |= CR_QUAD_EN_SPAN; >> + >> +write_enable(nor); >> + >> +ret = spansion_write_any_reg(nor, addr, cr); >> + >> +if (ret < 0) { >> +dev_dbg(nor->dev, >> +"error while writing configuration register\n"); >> +return -EINVAL; >> +} >> + >> +/* Read back and check it. */ >> +ret = spansion_read_any_reg(nor, addr, dummy, ); >> +if (ret || !(cr & CR_QUAD_EN_SPAN)) { >> +dev_dbg(nor->dev, "Spansion Quad bit not set\n"); >> +return -EINVAL; >> +} >> + >> +return 0; >> +} >> + > > Rest of the patch LGTM. > >> #if CONFIG_IS_ENABLED(SPI_FLASH_SFDP_SUPPORT) >> /** >> * spansion_no_read_cr_quad_enable() - set QE bit in Configuration Register. >> -- >> 2.25.1 >> > Best Regards, Takahiro
Re: [PATCH v4 3/9] mtd: spi-nor-core: Add support for Read/Write Any Register
On 1/30/2021 3:17 AM, Pratyush Yadav wrote: > On 28/01/21 01:36PM, tkuw584...@gmail.com wrote: >> From: Takahiro Kuwano >> >> Some of Spansion/Cypress chips support Read/Write Any Register commands. >> These commands are mainly used to write volatile registers and access to >> the registers in second and subsequent die for multi-die package parts. >> >> The Read Any Register instruction (65h) is followed by register address >> and dummy cycles, then the selected register byte is returned. >> >> The Write Any Register instruction (71h) is followed by register address >> and register byte to write. >> >> Signed-off-by: Takahiro Kuwano >> --- >> drivers/mtd/spi/spi-nor-core.c | 25 + >> include/linux/mtd/spi-nor.h| 4 >> 2 files changed, 29 insertions(+) >> >> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c >> index 34c15f1561..2803536ed5 100644 >> --- a/drivers/mtd/spi/spi-nor-core.c >> +++ b/drivers/mtd/spi/spi-nor-core.c >> @@ -211,6 +211,31 @@ static int spi_nor_write_reg(struct spi_nor *nor, u8 >> opcode, u8 *buf, int len) >> return spi_nor_read_write_reg(nor, , buf); >> } >> >> +#ifdef CONFIG_SPI_FLASH_SPANSION >> +static int spansion_read_any_reg(struct spi_nor *nor, u32 addr, u8 dummy, >> + u8 *val) >> +{ >> +struct spi_mem_op op = >> +SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDAR, 1), >> + SPI_MEM_OP_ADDR(nor->addr_width, addr, 1), >> + SPI_MEM_OP_DUMMY(dummy / 8, 1), >> + SPI_MEM_OP_DATA_IN(1, NULL, 1)); >> + >> +return spi_nor_read_write_reg(nor, , val); >> +} >> + >> +static int spansion_write_any_reg(struct spi_nor *nor, u32 addr, u8 val) >> +{ >> +struct spi_mem_op op = >> +SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WRAR, 1), >> + SPI_MEM_OP_ADDR(nor->addr_width, addr, 1), >> + SPI_MEM_OP_NO_DUMMY, >> + SPI_MEM_OP_DATA_OUT(1, NULL, 1)); >> + >> +return spi_nor_read_write_reg(nor, , ); >> +} >> +#endif >> + >> static ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t from, size_t >> len, >> u_char *buf) >> { >> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h >> index 89e7a4fdcd..e31073eb24 100644 >> --- a/include/linux/mtd/spi-nor.h >> +++ b/include/linux/mtd/spi-nor.h >> @@ -121,6 +121,10 @@ >> #define SPINOR_OP_BRWR 0x17/* Bank register write */ >> #define SPINOR_OP_BRRD 0x16/* Bank register read */ >> #define SPINOR_OP_CLSR 0x30/* Clear status register 1 */ >> +#define SPINOR_OP_RDAR 0x65/* Read any register */ >> +#define SPINOR_OP_WRAR 0x71/* Write any register */ >> +#define SPINOR_REG_ADDR_STR1V 0x0080 >> +#define SPINOR_REG_ADDR_CFR1V 0x0082 > > These two defines are not used by this patch. Remove them from this one > and add them to the one that actually uses them for the first time. > I will fix it, thank you. > With this fixed, > > Reviewed-by: Pratyush Yadav > >> >> /* Used for Micron flashes only. */ >> #define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */ >> -- >> 2.25.1 >> > Best Regards, Takahiro
Re: [PATCH v4 2/9] mtd: spi-nor-ids: Add Cypress s25hl-t/s25hs-t
Hi Pratyush, On 1/30/2021 3:08 AM, Pratyush Yadav wrote: > On 28/01/21 01:36PM, tkuw584...@gmail.com wrote: >> From: Takahiro Kuwano >> >> The S25HL-T/S25HS-T family is the Cypress Semper Flash with Quad SPI. >> The datasheets can be found in the following links. >> >> https://www.cypress.com/file/424146/download (256Mb/512Mb/1Gb, single die) >> https://www.cypress.com/file/499246/download (2Gb/4Gb, dual/quad die) >> >> Tested 512Mb/1Gb/2Gb parts on Xilinx Zynq-7000 FPGA board. > > Why not test the 256 Mb and 4 Gb parts as well? They might work > perfectly well but adding support for untested hardware sounds wrong to > me. The 256Mb and 4Gb parts are not yet officially sampled, although they are described in the datasheet. They should work like other tested ones, but as you commented, only tested devices should be added. I will remove 256Mb and 4Gb in v5. > >> Signed-off-by: Takahiro Kuwano >> --- >> drivers/mtd/spi/spi-nor-ids.c | 36 +++ >> 1 file changed, 36 insertions(+) >> >> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c >> index 5bd5dd3003..b78d13e980 100644 >> --- a/drivers/mtd/spi/spi-nor-ids.c >> +++ b/drivers/mtd/spi/spi-nor-ids.c >> @@ -217,6 +217,42 @@ const struct flash_info spi_nor_ids[] = { >> { INFO("s25fl208k", 0x014014, 0, 64 * 1024, 16, SECT_4K | >> SPI_NOR_DUAL_READ) }, >> { INFO("s25fl064l", 0x016017, 0, 64 * 1024, 128, SECT_4K | >> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) }, >> { INFO("s25fl128l", 0x016018, 0, 64 * 1024, 256, SECT_4K | >> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) }, >> + >> +/* S25HL/HS-T (Semper Flash with Quad SPI) Family has overlaid 4KB > > Nitpick: Please leave first line of multi-line comments blank like so: > > /* > * S25HL/HS-T (Semper Flash with Quad SPI) Family has overlaid 4KB > * ... > */ > I will fix it. >> + * sectors at top and/or bottom, depending on the device configuration. >> + * To support this, an erase hook makes overlaid sectors appear as >> + * uniform sectors. >> + */ >> +{ INFO6("s25hl256t", 0x342a19, 0x0f0390, 256 * 1024, 128, >> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | >> +USE_CLSR) }, >> +{ INFO6("s25hl512t", 0x342a1a, 0x0f0390, 256 * 1024, 256, >> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | >> +USE_CLSR) }, >> +{ INFO6("s25hl01gt", 0x342a1b, 0x0f0390, 256 * 1024, 512, >> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | >> +USE_CLSR) }, >> +{ INFO6("s25hl02gt", 0x342a1c, 0x0f0090, 256 * 1024, 1024, >> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | >> +USE_CLSR) }, >> +{ INFO6("s25hl04gt", 0x342a1d, 0x0f0090, 256 * 1024, 2048, >> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | >> +USE_CLSR) }, >> +{ INFO6("s25hs256t", 0x342b19, 0x0f0390, 256 * 1024, 128, >> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | >> +USE_CLSR) }, >> +{ INFO6("s25hs512t", 0x342b1a, 0x0f0390, 256 * 1024, 256, >> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | >> +USE_CLSR) }, >> +{ INFO6("s25hs01gt", 0x342b1b, 0x0f0390, 256 * 1024, 512, >> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | >> +USE_CLSR) }, >> +{ INFO6("s25hs02gt", 0x342b1c, 0x0f0090, 256 * 1024, 1024, >> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | >> +USE_CLSR) }, >> +{ INFO6("s25hs04gt", 0x342b1d, 0x0f0090, 256 * 1024, 2048, >> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | >> +USE_CLSR) }, > > The datasheets you have linked do not specify a mapping between device > ID and part number. So I can't verify that you are using the correct IDs > here. But I'll trust you to get them right :-) > Thank you :-) > With the above comment addressed and 256 Mb and 4 Gb parts tested, > please add > > Reviewed-by: Pratyush Yadav > >> #endif >> #ifdef CONFIG_SPI_FLASH_SST /* SST */ >> /* SST -- large erase sizes are "overlays", "sectors" are 4K */ >> -- >> 2.25.1 >> > Best Regards, Takahiro
Re: [PATCH 1/1] sandbox: allow cross-compiling sandbox
On Mon, Feb 08, 2021 at 09:29:43PM -0700, Simon Glass wrote: > Hi Heinrich, > > On Mon, 8 Feb 2021 at 15:06, Heinrich Schuchardt wrote: > > > > UEFI test files like helloworld.efi require an architecture specific > > PE-COFF header. > > architecture-specific > > > > > For non-sandbox the PE-COFF header is chosen by the target architecture. > > For the sandbox we use the host architecture. This is not helpful for cross > > compiling. Allow specifying the target architecture of the sandbox via > > environment variable MK_ARCH, e.g. > > What exactly is the target arch? Is the the one that sandbox is > running on, or something else? > > > > > make sandbox_defconfig NO_SDL=1 > > CROSS_COMPILE=aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make > > > > Signed-off-by: Heinrich Schuchardt > > --- > > Makefile | 2 +- > > doc/arch/sandbox.rst | 14 ++ > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/Makefile b/Makefile > > index 23dd11f723..286e5148ae 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -19,7 +19,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR) > > > > # Determine host architecture > > include include/host_arch.h > > -MK_ARCH="${shell uname -m}" > > +MK_ARCH?="${shell uname -m}" > > unexport HOST_ARCH > > ifeq ("x86_64", $(MK_ARCH)) > >export HOST_ARCH=$(HOST_ARCH_X86_64) > > diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst > > index 60ee1e0741..0dd9edc8cb 100644 > > --- a/doc/arch/sandbox.rst > > +++ b/doc/arch/sandbox.rst > > @@ -33,6 +33,20 @@ integers can only be built on 64-bit hosts. > > > > Note that standalone/API support is not available at present. > > > > +Cross compiling > > +--- > > + > > +When cross compiling the U-Boot sandbox with CONFIG_EFI_LOADER=y the target > > +architecture must be specified using the MK_ARCH environment variable > > using one > > +of the values aarch64, armv7l, i386, riscv32, riscv64, x86_64, e.g. > > OK, but what is the target architecture? I'm just not sure from your > comments what this actually means. I'm not quite sure if it is very useful to be able to cross-compile the sandbox application. But any way, it is not very convenient to always enforce users to explicitly specify "target" architecture. How about trying the following first? $(CC) -v | grep "Target: " | sed -e 's/-*$//' It will give us a hint about the architecture. ("--print-multiarch" shows a similar triple, but this option won't work for some pre-built gcc, like aarch64 gcc from Arm.) > Does MK mean make? I prefer another name for clarity. -Takahiro Akashi > > > + > > +.. code-block:: bash > > + > > +NO_SDL=1 make sandbox_defconfig > > +CROSS_COMPILE=aarch64-linux-gnu- MK_ARCH=aarch64 NO_SDL=1 make > > + > > +NO_SDL=1 was chosen in the example to remove the dependency on the SDL > > library. > > +The graphical console will not be available. > > > > Prerequisites > > - > > -- > > 2.30.0 > > > > Regards, > Simon
[PATCH v1 1/1] drivers: mmc: iproc_sdhci: enable HS200 mode
From: Bharat Gooty Add tuning functionality which is needed for HS200 mode. For HS200, program the correct needed 1.8 voltage Signed-off-by: Bharat Gooty Signed-off-by: Rayagonda Kokatanur --- drivers/mmc/iproc_sdhci.c | 88 +++ 1 file changed, 79 insertions(+), 9 deletions(-) diff --git a/drivers/mmc/iproc_sdhci.c b/drivers/mmc/iproc_sdhci.c index f931e4b3c1..360ea01e21 100644 --- a/drivers/mmc/iproc_sdhci.c +++ b/drivers/mmc/iproc_sdhci.c @@ -9,6 +9,7 @@ #include #include #include +#include "mmc_private.h" #include DECLARE_GLOBAL_DATA_PTR; @@ -139,17 +140,87 @@ static void sdhci_iproc_writeb(struct sdhci_host *host, u8 val, int reg) static int sdhci_iproc_set_ios_post(struct sdhci_host *host) { - u32 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2); + struct mmc *mmc = (struct mmc *)host->mmc; + u32 ctrl; - /* Reset UHS mode bits */ - ctrl &= ~SDHCI_CTRL_UHS_MASK; + if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180) { + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2); + ctrl |= SDHCI_CTRL_VDD_180; + sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2); + } - if (host->mmc->ddr_mode) - ctrl |= UHS_DDR50_BUS_SPEED; + sdhci_set_uhs_timing(host); + return 0; +} +static void sdhci_start_tuning(struct sdhci_host *host) +{ + u32 ctrl; + + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2); + ctrl |= SDHCI_CTRL_EXEC_TUNING; sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2); - return 0; + sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_INT_ENABLE); + sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_SIGNAL_ENABLE); +} + +static void sdhci_end_tuning(struct sdhci_host *host) +{ + /* Enable only interrupts served by the SD controller */ + sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK, +SDHCI_INT_ENABLE); + /* Mask all sdhci interrupt sources */ + sdhci_writel(host, 0x0, SDHCI_SIGNAL_ENABLE); +} + +static int sdhci_iproc_execute_tuning(struct mmc *mmc, u8 opcode) +{ +#define MAX_TUNING_LOOP40 + struct mmc_cmd cmd; + u32 ctrl; + u32 blocksize = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 64); + struct sdhci_host *host = dev_get_priv(mmc->dev); + char tuning_loop_counter = MAX_TUNING_LOOP; + int ret = 0; + + sdhci_start_tuning(host); + + cmd.cmdidx = opcode; + cmd.resp_type = MMC_RSP_R1; + cmd.cmdarg = 0; + + if (opcode == MMC_CMD_SEND_TUNING_BLOCK_HS200 && mmc->bus_width == 8) + blocksize = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 128); + + sdhci_writew(host, blocksize, SDHCI_BLOCK_SIZE); + sdhci_writew(host, 1, SDHCI_BLOCK_COUNT); + sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE); + + do { + mmc_send_cmd(mmc, , NULL); + if (opcode == MMC_CMD_SEND_TUNING_BLOCK) + udelay(1); + + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2); + + if (tuning_loop_counter-- == 0) + break; + + } while (ctrl & SDHCI_CTRL_EXEC_TUNING); + + if (tuning_loop_counter < 0 || (!(ctrl & SDHCI_CTRL_TUNED_CLK))) { + ctrl &= ~(SDHCI_CTRL_TUNED_CLK | SDHCI_CTRL_EXEC_TUNING); + sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL2); + printf("%s:Tuning failed, opcode = 0x%02x\n", __func__, opcode); + ret = -EIO; + } + + udelay(1); + + sdhci_end_tuning(host); + + return ret; } static struct sdhci_ops sdhci_platform_ops = { @@ -162,6 +233,7 @@ static struct sdhci_ops sdhci_platform_ops = { .write_b = sdhci_iproc_writeb, #endif .set_ios_post = sdhci_iproc_set_ios_post, + .platform_execute_tuning = sdhci_iproc_execute_tuning, }; struct iproc_sdhci_plat { @@ -189,9 +261,7 @@ static int iproc_sdhci_probe(struct udevice *dev) host->name = dev->name; host->ioaddr = dev_read_addr_ptr(dev); - host->voltages = MMC_VDD_165_195 | -MMC_VDD_32_33 | MMC_VDD_33_34; - host->quirks = SDHCI_QUIRK_BROKEN_VOLTAGE | SDHCI_QUIRK_BROKEN_R1B; + host->quirks = SDHCI_QUIRK_BROKEN_R1B; host->host_caps = MMC_MODE_DDR_52MHz; host->index = fdtdec_get_uint(gd->fdt_blob, node, "index", 0); host->ops = _platform_ops; -- 2.17.1 smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH u-boot-dm + u-boot-spi 1/6] dm: add non-translating version of ofnode_get_addr_size_index
Hi Marek, On Mon, 8 Feb 2021 at 19:49, Marek Behún wrote: > > Add functions ofnode_get_addr_size_index_notrans(), which is a > non-translating version of ofnode_get_addr_size_index(). > > Some addresses are not meant to be translated, for example those of MTD > fixed-partitions. > > Signed-off-by: Marek Behún > Cc: Dario Binacchi > Cc: Simon Glass > --- > drivers/core/ofnode.c | 19 --- > include/dm/ofnode.h | 17 + > 2 files changed, 33 insertions(+), 3 deletions(-) Please add a test for this in test/dm/ofnode.c Regards, Simon
Re: [PATCH 1/1] sandbox: allow cross-compiling sandbox
Hi Heinrich, On Mon, 8 Feb 2021 at 15:06, Heinrich Schuchardt wrote: > > UEFI test files like helloworld.efi require an architecture specific > PE-COFF header. architecture-specific > > For non-sandbox the PE-COFF header is chosen by the target architecture. > For the sandbox we use the host architecture. This is not helpful for cross > compiling. Allow specifying the target architecture of the sandbox via > environment variable MK_ARCH, e.g. What exactly is the target arch? Is the the one that sandbox is running on, or something else? > > make sandbox_defconfig NO_SDL=1 > CROSS_COMPILE=aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make > > Signed-off-by: Heinrich Schuchardt > --- > Makefile | 2 +- > doc/arch/sandbox.rst | 14 ++ > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 23dd11f723..286e5148ae 100644 > --- a/Makefile > +++ b/Makefile > @@ -19,7 +19,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR) > > # Determine host architecture > include include/host_arch.h > -MK_ARCH="${shell uname -m}" > +MK_ARCH?="${shell uname -m}" > unexport HOST_ARCH > ifeq ("x86_64", $(MK_ARCH)) >export HOST_ARCH=$(HOST_ARCH_X86_64) > diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst > index 60ee1e0741..0dd9edc8cb 100644 > --- a/doc/arch/sandbox.rst > +++ b/doc/arch/sandbox.rst > @@ -33,6 +33,20 @@ integers can only be built on 64-bit hosts. > > Note that standalone/API support is not available at present. > > +Cross compiling > +--- > + > +When cross compiling the U-Boot sandbox with CONFIG_EFI_LOADER=y the target > +architecture must be specified using the MK_ARCH environment variable using > one > +of the values aarch64, armv7l, i386, riscv32, riscv64, x86_64, e.g. OK, but what is the target architecture? I'm just not sure from your comments what this actually means. Does MK mean make? > + > +.. code-block:: bash > + > +NO_SDL=1 make sandbox_defconfig > +CROSS_COMPILE=aarch64-linux-gnu- MK_ARCH=aarch64 NO_SDL=1 make > + > +NO_SDL=1 was chosen in the example to remove the dependency on the SDL > library. > +The graphical console will not be available. > > Prerequisites > - > -- > 2.30.0 > Regards, Simon
Re: Contributor meeting notes 19-Jan-21
Hi Stefano. On Thu, 28 Jan 2021 at 02:24, Stefano Babic wrote: > > Hi Simon, > > On 27.01.21 22:31, Simon Glass wrote: > > Hi Stefano, > > > > Thank you for the offer! > > > > What are the advantages of hosting the meeting on a private server? > > No, I do not see any special advantage - I will just be happy (as Marek) > if we can nuse a FOSS project as Jitsi for communication. IMHO it is ok > to use the public server provided by jitsi. OK well we tried a jitsi call last week and it seemed to work fine. Regards, Simon
Re: [PATCH v4 10/16] dm: gpio: Add a way to update flags
Hi Patrick, On Mon, 8 Feb 2021 at 10:33, Patrick DELAUNAY wrote: > > Hi Simon, > > 2 minor remarks, > > On 2/5/21 5:22 AM, Simon Glass wrote: > > It is convenient to be able to adjust some of the flags for a GPIO while > > leaving others alone. Add a function for this. > > > > Update dm_gpio_set_dir_flags() to make use of this. > > > > Also update dm_gpio_set_value() to use this also, since this allows the > > open-drain / open-source features to be implemented directly in the > > driver, rather than using the uclass workaround. > > > > Update the sandbox tests accordingly. This involves a lot of changes to > > dm_test_gpio_opendrain_opensource() since we no-longer have the direciion > > being reported differently depending on the open drain/open source flags. > > > > Also update the STM32 drivers to let the uclass handle the active low/high > > logic. > > > > Drop the GPIOD_FLAGS_OUTPUT() macro which is no-longer used. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v4: > > - Update dm_gpio_set_dir_flags() to clear direction flags first > > > > Changes in v3: > > - Incorporate GPIOD_FLAGS_OUTPUT() changes from Patrick Delaunay > > > > drivers/gpio/gpio-uclass.c | 75 ++ > > drivers/gpio/stm32_gpio.c | 3 +- > > drivers/pinctrl/pinctrl-stmfx.c | 5 +- > > include/asm-generic/gpio.h | 31 ++-- > > test/dm/gpio.c | 132 > > 5 files changed, 203 insertions(+), 43 deletions(-) > > (...) > > > diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c > > index c2d7046c0dd..125c237551c 100644 > > --- a/drivers/gpio/stm32_gpio.c > > +++ b/drivers/gpio/stm32_gpio.c > > @@ -203,12 +203,13 @@ static int stm32_gpio_set_flags(struct udevice *dev, > > unsigned int offset, > > return idx; > > > > if (flags & GPIOD_IS_OUT) { > > - int value = GPIOD_FLAGS_OUTPUT(flags); > > + bool value = flags & GPIOD_IS_OUT_ACTIVE; > > here the bool variable valeu can be 0 or GPIOD_IS_OUT_ACTIVE = BIT(4), > so it should have > > + bool value = !!(flags & GPIOD_IS_OUT_ACTIVE); > > or > > + int value = flags & GPIOD_IS_OUT_ACTIVE; > > PS: not functional impact as > > #define BSRR_BIT(gpio_pin, value)BIT((gpio_pin) + (value ? 0 : 16)) > > > > > if (flags & GPIOD_OPEN_DRAIN) > > stm32_gpio_set_otype(regs, idx, STM32_GPIO_OTYPE_OD); > > else > > stm32_gpio_set_otype(regs, idx, STM32_GPIO_OTYPE_PP); > > + > > stm32_gpio_set_moder(regs, idx, STM32_GPIO_MODE_OUT); > > writel(BSRR_BIT(idx, value), >bsrr); > > > > diff --git a/drivers/pinctrl/pinctrl-stmfx.c > > b/drivers/pinctrl/pinctrl-stmfx.c > > index 8ddbc3dc281..711b1a5d8c4 100644 > > --- a/drivers/pinctrl/pinctrl-stmfx.c > > +++ b/drivers/pinctrl/pinctrl-stmfx.c > > @@ -169,6 +169,8 @@ static int stmfx_gpio_set_flags(struct udevice *dev, > > unsigned int offset, > > int ret = -ENOTSUPP; > > > > if (flags & GPIOD_IS_OUT) { > > + bool value = flags & GPIOD_IS_OUT_ACTIVE; > > + > > > same here > > + int value = flags & GPIOD_IS_OUT_ACTIVE; > or > + bool value = !!(flags & GPIOD_IS_OUT_ACTIVE); The bool type should do this automatically. I tested this and it seems to do the right thing. > > > But no impact > > > > if (flags & GPIOD_OPEN_SOURCE) > > return -ENOTSUPP; > > if (flags & GPIOD_OPEN_DRAIN) > > @@ -177,8 +179,7 @@ static int stmfx_gpio_set_flags(struct udevice *dev, > > unsigned int offset, > > ret = stmfx_conf_set_type(dev, offset, 1); > > if (ret) > > return ret; > > - ret = stmfx_gpio_direction_output(dev, offset, > > - GPIOD_FLAGS_OUTPUT(flags)); > > + ret = stmfx_gpio_direction_output(dev, offset, value); > > } else if (flags & GPIOD_IS_IN) { > > ret = stmfx_gpio_direction_input(dev, offset); > > if (ret) > > > (...) > > > With the 2 remarks > > Reviewed-by: Patrick Delaunay > Tested-by: Patrick Delaunay > Regards, SImon
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
Hi Heinrich, On Mon, 8 Feb 2021 at 15:18, Heinrich Schuchardt wrote: > > On 2/8/21 6:56 PM, Heinrich Schuchardt wrote: > > On 2/8/21 6:08 PM, Simon Glass wrote: > >> HI Marek, > >> > >> On Mon, 8 Feb 2021 at 09:10, Marek Szyprowski > >> wrote: > >>> > >>> Hi Simon, > >>> > >>> On 06.02.2021 17:21, Simon Glass wrote: > On Thu, 4 Feb 2021 at 03:36, Marek Szyprowski > wrote: > > ... > > Could you give me a bit more hints or point where to start? I've tried > > to build sandbox, but it fails for v2021.01 release (I've did make > > sandbox_defconfig && make all). I assume I would need to add adc and > > adc-keys devices to some sandbox dts and some code triggering and > > checking the key values, but that's all I know now. > Well you do need to be able to build sandbox or you will get > nowhere...what error did you get? Once we understand what went wrong > we can update the docs. Maybe it is missing a dependency. > >>> > >>> $ gcc --version > >>> gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 > >>> Copyright (C) 2017 Free Software Foundation, Inc. > >>> This is free software; see the source for copying conditions. There > >>> is NO > >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > >>> PURPOSE. > >>> > >>> $ git checkout v2021.01 > >>> > >>> $ make sandbox_defconfig > >>> # > >>> # configuration written to .config > >>> # > >>> > >>> $ make > >>> scripts/kconfig/conf --syncconfig Kconfig > >>> CFG u-boot.cfg > >>> GEN include/autoconf.mk > >>> GEN include/autoconf.mk.dep > >>> CFGCHK u-boot.cfg > >>> UPD include/generated/timestamp_autogenerated.h > >>> HOSTCC tools/mkenvimage.o > >>> HOSTLD tools/mkenvimage > >>> HOSTCC tools/fit_image.o > >>> HOSTCC tools/image-host.o > >>> HOSTCC tools/dumpimage.o > >>> HOSTLD tools/dumpimage > >>> HOSTCC tools/mkimage.o > >>> HOSTLD tools/mkimage > >>> HOSTLD tools/fit_info > >>> HOSTLD tools/fit_check_sign > >>> > >>> ... > >>> > >>> CC arch/sandbox/cpu/cpu.o > >>> In file included from include/common.h:26:0, > >>>from arch/sandbox/cpu/cpu.c:6: > >>> include/asm/global_data.h:112:58: warning: call-clobbered register used > >>> for global register variable > >>>#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm > >>> ("r9") > >>> ^ > >>> include/dm/of.h:86:1: note: in expansion of macro > >>> ‘DECLARE_GLOBAL_DATA_PTR’ > >>>DECLARE_GLOBAL_DATA_PTR; > >> > >> This is pretty mysterious. Are you sure you are using an x86_64 machine? > > > > r9 relates to ARMv7. > > > > You have to unset CROSS_COMPILE when you build the sandbox. > > > > The sandbox runs fine on aarch64. > > > > There are a bunch of errors currently when building on 32bit > > architectures. Simon has a lot of patches pending. > > Hello Simon, > > it was your patch > > 091401131085 ("command: Remove the cmd_tbl_t typedef") 2020-05-10 > > that broke building the sandbox on ARMv7. Oh dear. > > Once your 32bit corrections are merged we should try to add > cross-compiling the sandbox for aarch64 and armv7 to Gitlab CI. Yes, what we don't test doesn't work :-) Regards, Simon
[PATCH v9] Add support for stack-protector
Add support for stack protector for UBOOT, SPL, and TPL as well as new pytest for stackprotector Signed-off-by: Joel Peshkin --- Cc: Simon Glass Cc: Heinrich Schuchardt Changes for v9: - Fix pytest script post-test reboot Changes for v8: - Fix commit message - Force canary to UL type Changes for v7: - Fix commit message - add __builtin_extract_return_addr() calls Changes for v6: - Fix commit message Changes for v5: - Rebase Changes for v4: - Exclude EFI from stackprotector - Cleanups of extra includes and declaration Changes for v3: - Move test command to cmd/ - Update Kconfig names and depends - clean up default canary initialization Changes for v2: - Add test command and corresponding config - Fixed incorrect description in Kconfig - Add unit test --- MAINTAINERS | 7 +++ Makefile | 5 + cmd/Kconfig | 10 ++ cmd/Makefile | 1 + cmd/stackprot_test.c | 21 + common/Kconfig | 17 + common/Makefile | 2 ++ common/stackprot.c | 19 +++ configs/sandbox_defconfig| 14 +++--- scripts/Makefile.spl | 6 ++ test/py/tests/test_stackprotector.py | 15 +++ 11 files changed, 110 insertions(+), 7 deletions(-) create mode 100644 cmd/stackprot_test.c create mode 100644 common/stackprot.c create mode 100644 test/py/tests/test_stackprotector.py diff --git a/MAINTAINERS b/MAINTAINERS index 26dd254..d3971e8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1024,6 +1024,13 @@ F: include/sqfs.h F: cmd/sqfs.c F: test/py/tests/test_fs/test_squashfs/ +STACKPROTECTOR +M: Joel Peshkin +S: Maintained +F: common/stackprot.c +F: cmd/stackprot_test.c +F: test/py/tests/test_stackprotector.py + TARGET_BCMNS3 M: Bharat Gooty M: Rayagonda Kokatanur diff --git a/Makefile b/Makefile index 902a976..65c5cb8 100644 --- a/Makefile +++ b/Makefile @@ -677,7 +677,12 @@ else KBUILD_CFLAGS += -O2 endif +ifeq ($(CONFIG_STACKPROTECTOR),y) +KBUILD_CFLAGS += $(call cc-option,-fstack-protector-strong) +CFLAGS_EFI += $(call cc-option,-fno-stack-protector) +else KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector) +endif KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks) # disable stringop warnings in gcc 8+ diff --git a/cmd/Kconfig b/cmd/Kconfig index da86a94..054b2f3 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -2280,6 +2280,16 @@ config CMD_AVB avb read_part_hex - read data from partition and output to stdout avb write_part - write data to partition avb verify - run full verification chain + +config CMD_STACKPROTECTOR_TEST + bool "Test command for stack protector" + depends on STACKPROTECTOR + default n + help + Enable stackprot_test command + The stackprot_test command will force a stack overrun to test + the stack smashing detection mechanisms. + endmenu config CMD_UBI diff --git a/cmd/Makefile b/cmd/Makefile index 5b3400a..1d7afea 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -142,6 +142,7 @@ obj-$(CONFIG_CMD_SPI) += spi.o obj-$(CONFIG_CMD_STRINGS) += strings.o obj-$(CONFIG_CMD_SMC) += smccc.o obj-$(CONFIG_CMD_SYSBOOT) += sysboot.o pxe_utils.o +obj-$(CONFIG_CMD_STACKPROTECTOR_TEST) += stackprot_test.o obj-$(CONFIG_CMD_TERMINAL) += terminal.o obj-$(CONFIG_CMD_TIME) += time.o obj-$(CONFIG_CMD_TIMER) += timer.o diff --git a/cmd/stackprot_test.c b/cmd/stackprot_test.c new file mode 100644 index 000..6ad287e --- /dev/null +++ b/cmd/stackprot_test.c @@ -0,0 +1,21 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2021 Broadcom + */ + +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +static int do_test_stackprot_fail(struct cmd_tbl *cmdtp, int flag, int argc, + char *const argv[]) +{ + char a[128]; + + memset(a, 0xa5, 512); + return 0; +} + +U_BOOT_CMD(stackprot_test, 1, 1, do_test_stackprot_fail, + "test stack protector fail", ""); diff --git a/common/Kconfig b/common/Kconfig index 2bce8c9..6a94045 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -595,6 +595,23 @@ config TPL_HASH and the algorithms it supports are defined in common/hash.c. See also CMD_HASH for command-line access. +config STACKPROTECTOR + bool "Stack Protector buffer overflow detection" + default n + help + Enable stack smash detection through compiler's stack-protector + canary logic + +config SPL_STACKPROTECTOR + bool "Stack Protector buffer overflow detection for SPL" + depends on STACKPROTECTOR && SPL + default n + +config TPL_STACKPROTECTOR + bool "Stack Protector buffer overflow detection for TPL" +
Re: [PATCH 5/6] usb: xhci-dwc3: Add support for clocks/resets
On 2/8/21 7:42 PM, Andre Przywara wrote: > On Sun, 7 Feb 2021 23:57:23 -0600 > Samuel Holland wrote: > > (CC:ing Simon and Kever) > >> Some platforms, like the Allwinner H6, do not have a separate glue layer >> around the dwc3. Instead, they rely on the clocks/resets/phys referenced >> from the dwc3 DT node itself. Add support for enabling the clocks/resets >> referenced from the dwc3 DT node. >> >> Signed-off-by: Samuel Holland > > That looks alright on a first glance, but have you checked how this > interacts with and relates to dwc3-of-simple.c? > This seems to do similar things? Yes, they do the same thing, but with a different DT binding. dwc3-of-simple binds to, and expects the clocks/resets to be in, the DT node _containing_ the snps,dwc3 node. The xhci-dwc3 driver binds to the snps,dwc3 node itself. This is why other platforms were not affected by the change I don't think there's any way to attach two drivers to the same DT node at the same time, so we cannot take advantage of the dwc3-of-simple code without rearranging the device tree. Interestingly, Linux has supported the H6 in its version of dwc3-of-simple since commit e362098f0e12 ("usb: dwc3: of-simple: Add compatible for Allwinner H6 platform"). But the device tree ended up not using a glue layer node or this compatible. Maybe a better forward is to modify the device tree to be more similar to most other platforms? On the other hand, as you found, Hisilicon and Unipher platforms use the same binding as Allwinner. It's unfortunate that there are two distinct but equally "correct" ways to represent the same hardware. Cheers, Samuel
[PATCH u-boot-dm + u-boot-spi 5/6] mtd: remove mtd_probe function
The device_probe() function does the same thing as mtd_probe() and mtd_probe() is only used in mtd_probe_uclass_mtd_devs(), where the probing can be made simpler by using uclass_foreach_dev_probe macro. Signed-off-by: Marek Behún Cc: Jagan Teki Cc: Priyanka Jain Cc: Simon Glass Cc: Heiko Schocher Cc: Jagan Teki --- drivers/mtd/mtd-uclass.c | 15 --- drivers/mtd/mtd_uboot.c | 9 +++-- include/mtd.h| 1 - 3 files changed, 3 insertions(+), 22 deletions(-) diff --git a/drivers/mtd/mtd-uclass.c b/drivers/mtd/mtd-uclass.c index 9f5f672ba3..4ab84de553 100644 --- a/drivers/mtd/mtd-uclass.c +++ b/drivers/mtd/mtd-uclass.c @@ -9,21 +9,6 @@ #include #include -/** - * mtd_probe - Probe the device @dev if not already done - * - * @dev: U-Boot device to probe - * - * @return 0 on success, an error otherwise. - */ -int mtd_probe(struct udevice *dev) -{ - if (device_active(dev)) - return 0; - - return device_probe(dev); -} - /* * Implement a MTD uclass which should include most flash drivers. * The uclass private is pointed to mtd_info. diff --git a/drivers/mtd/mtd_uboot.c b/drivers/mtd/mtd_uboot.c index 7fb72eb1f4..865e9ae4cb 100644 --- a/drivers/mtd/mtd_uboot.c +++ b/drivers/mtd/mtd_uboot.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -105,13 +106,9 @@ int mtd_search_alternate_name(const char *mtdname, char *altname, static void mtd_probe_uclass_mtd_devs(void) { struct udevice *dev; - int idx = 0; - /* Probe devices with DM compliant drivers */ - while (!uclass_find_device(UCLASS_MTD, idx, ) && dev) { - mtd_probe(dev); - idx++; - } + uclass_foreach_dev_probe(UCLASS_MTD, dev) + ; } #else static void mtd_probe_uclass_mtd_devs(void) { } diff --git a/include/mtd.h b/include/mtd.h index b0f8693386..b569331edb 100644 --- a/include/mtd.h +++ b/include/mtd.h @@ -8,7 +8,6 @@ #include -int mtd_probe(struct udevice *dev); int mtd_probe_devices(void); void board_mtdparts_default(const char **mtdids, const char **mtdparts); -- 2.26.2
[PATCH u-boot-dm + u-boot-spi 4/6] mtd: spi-nor: fill-in mtd->dev member
Fill in mtd->dev member with nor->dev. This can be used by MTD OF partition parser. Signed-off-by: Marek Behún Cc: Jagan Teki Cc: Priyanka Jain Cc: Simon Glass Cc: Heiko Schocher Cc: Jagan Teki --- drivers/mtd/spi/sf_mtd.c | 1 + drivers/mtd/spi/spi-nor-core.c | 1 + drivers/mtd/spi/spi-nor-tiny.c | 1 + 3 files changed, 3 insertions(+) diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c index 94854fbfc4..04de868080 100644 --- a/drivers/mtd/spi/sf_mtd.c +++ b/drivers/mtd/spi/sf_mtd.c @@ -125,6 +125,7 @@ int spi_flash_mtd_register(struct spi_flash *flash) sf_mtd_info.size = flash->size; sf_mtd_info.priv = flash; + sf_mtd_info.dev = flash->dev; /* Only uniform flash devices for now */ sf_mtd_info.numeraseregions = 0; diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index ef426dac02..57b7fa3b37 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -2532,6 +2532,7 @@ int spi_nor_scan(struct spi_nor *nor) if (!mtd->name) mtd->name = info->name; + mtd->dev = nor->dev; mtd->priv = nor; mtd->type = MTD_NORFLASH; mtd->writesize = 1; diff --git a/drivers/mtd/spi/spi-nor-tiny.c b/drivers/mtd/spi/spi-nor-tiny.c index 07c8c7b82b..80cc091469 100644 --- a/drivers/mtd/spi/spi-nor-tiny.c +++ b/drivers/mtd/spi/spi-nor-tiny.c @@ -751,6 +751,7 @@ int spi_nor_scan(struct spi_nor *nor) return ret; mtd->name = "spi-flash"; + mtd->dev = nor->dev; mtd->priv = nor; mtd->type = MTD_NORFLASH; mtd->writesize = 1; -- 2.26.2
[PATCH u-boot-dm + u-boot-spi 6/6] mtd: probe SPI NOR devices in mtd_probe_devices()
In order for `mtd list` U-Boot command to list SPI NOR devices without the need to run `sf probe` before, we have to probe SPI NOR devices in mtd_probe_devices(). Signed-off-by: Marek Behún Cc: Jagan Teki Cc: Priyanka Jain Cc: Simon Glass Cc: Heiko Schocher Cc: Jagan Teki --- drivers/mtd/mtd_uboot.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/mtd/mtd_uboot.c b/drivers/mtd/mtd_uboot.c index 865e9ae4cb..5dc3a3351b 100644 --- a/drivers/mtd/mtd_uboot.c +++ b/drivers/mtd/mtd_uboot.c @@ -114,6 +114,18 @@ static void mtd_probe_uclass_mtd_devs(void) static void mtd_probe_uclass_mtd_devs(void) { } #endif +#if IS_ENABLED(CONFIG_DM_SPI_FLASH) && IS_ENABLED(CONFIG_SPI_FLASH_MTD) +static void mtd_probe_uclass_spi_nor_devs(void) +{ + struct udevice *dev; + + uclass_foreach_dev_probe(UCLASS_SPI_FLASH, dev) + ; +} +#else +static void mtd_probe_uclass_spi_nor_devs(void) { } +#endif + #if defined(CONFIG_MTD_PARTITIONS) #define MTDPARTS_MAXLEN 512 @@ -309,6 +321,7 @@ int mtd_probe_devices(void) struct mtd_info *mtd; mtd_probe_uclass_mtd_devs(); + mtd_probe_uclass_spi_nor_devs(); /* * Check if mtdparts/mtdids changed, if the MTD dev list was updated -- 2.26.2
[PATCH u-boot-dm + u-boot-spi 2/6] mtd: add support for parsing partitions defined in OF
Add support for parsing partitions defined in device-trees via the `partitions` node with `fixed-partitions` compatible. The `mtdparts`/`mtdids` mechanism takes precedence. If some partitions are defined for a MTD device via this mechanism, the code won't register partitions for that MTD device from OF, even if they are defined. Signed-off-by: Marek Behún Cc: Simon Glass Cc: Heiko Schocher Cc: Jagan Teki --- drivers/mtd/mtd_uboot.c | 106 +++- drivers/mtd/mtdpart.c | 60 +++ include/linux/mtd/mtd.h | 9 3 files changed, 131 insertions(+), 44 deletions(-) diff --git a/drivers/mtd/mtd_uboot.c b/drivers/mtd/mtd_uboot.c index 9360d4ed17..7fb72eb1f4 100644 --- a/drivers/mtd/mtd_uboot.c +++ b/drivers/mtd/mtd_uboot.c @@ -197,53 +197,11 @@ static void mtd_del_all_parts(void) } while (ret > 0); } -int mtd_probe_devices(void) +static int parse_mtdparts(const char *mtdparts, const char *mtdids) { - static char *old_mtdparts; - static char *old_mtdids; - const char *mtdparts = get_mtdparts(); - const char *mtdids = get_mtdids(); - const char *mtdparts_next = mtdparts; + const char *mtdparts_next; struct mtd_info *mtd; - mtd_probe_uclass_mtd_devs(); - - /* -* Check if mtdparts/mtdids changed, if the MTD dev list was updated -* or if our previous attempt to delete existing partititions failed. -* In any of these cases we want to update the partitions, otherwise, -* everything is up-to-date and we can return 0 directly. -*/ - if ((!mtdparts && !old_mtdparts && !mtdids && !old_mtdids) || - (mtdparts && old_mtdparts && mtdids && old_mtdids && -!mtd_dev_list_updated() && !mtd_del_all_parts_failed && -!strcmp(mtdparts, old_mtdparts) && -!strcmp(mtdids, old_mtdids))) - return 0; - - /* Update the local copy of mtdparts */ - free(old_mtdparts); - free(old_mtdids); - old_mtdparts = strdup(mtdparts); - old_mtdids = strdup(mtdids); - - /* -* Remove all old parts. Note that partition removal can fail in case -* one of the partition is still being used by an MTD user, so this -* does not guarantee that all old partitions are gone. -*/ - mtd_del_all_parts(); - - /* -* Call mtd_dev_list_updated() to clear updates generated by our own -* parts removal loop. -*/ - mtd_dev_list_updated(); - - /* If either mtdparts or mtdids is empty, then exit */ - if (!mtdparts || !mtdids) - return 0; - /* Start the parsing by ignoring the extra 'mtdparts=' prefix, if any */ if (!strncmp(mtdparts, "mtdparts=", sizeof("mtdparts=") - 1)) mtdparts += 9; @@ -342,6 +300,66 @@ int mtd_probe_devices(void) put_mtd_device(mtd); } + return 0; +} + +int mtd_probe_devices(void) +{ + static char *old_mtdparts; + static char *old_mtdids; + const char *mtdparts = get_mtdparts(); + const char *mtdids = get_mtdids(); + struct mtd_info *mtd; + + mtd_probe_uclass_mtd_devs(); + + /* +* Check if mtdparts/mtdids changed, if the MTD dev list was updated +* or if our previous attempt to delete existing partititions failed. +* In any of these cases we want to update the partitions, otherwise, +* everything is up-to-date and we can return 0 directly. +*/ + if ((!mtdparts && !old_mtdparts && !mtdids && !old_mtdids) || + (mtdparts && old_mtdparts && mtdids && old_mtdids && +!mtd_dev_list_updated() && !mtd_del_all_parts_failed && +!strcmp(mtdparts, old_mtdparts) && +!strcmp(mtdids, old_mtdids))) + return 0; + + /* Update the local copy of mtdparts */ + free(old_mtdparts); + free(old_mtdids); + old_mtdparts = strdup(mtdparts); + old_mtdids = strdup(mtdids); + + /* +* Remove all old parts. Note that partition removal can fail in case +* one of the partition is still being used by an MTD user, so this +* does not guarantee that all old partitions are gone. +*/ + mtd_del_all_parts(); + + /* +* Call mtd_dev_list_updated() to clear updates generated by our own +* parts removal loop. +*/ + mtd_dev_list_updated(); + + /* If both mtdparts and mtdids are non-empty, parse */ + if (mtdparts && mtdids) { + if (parse_mtdparts(mtdparts, mtdids) < 0) + printf("Failed parsing MTD partitions from mtdparts!\n"); + } + + /* Fallback to OF partitions */ + mtd_for_each_device(mtd) { + if (list_empty(>partitions)) { + if (add_mtd_partitions_of(mtd) < 0) + printf("Failed parsing
[PATCH u-boot-dm + u-boot-spi 3/6] mtd: spi-nor: allow registering multiple MTDs when DM is enabled
Currently when the SPI_FLASH_MTD config option is enabled, only one SPI can be registered as MTD at any time - it is the last one probed (since with old non-DM model only one SPI NOR could be probed at any time). When DM is enabled, allow for registering multiple SPI NORs as MTDs by utilizing the nor->mtd structure, which is filled in by spi_nor_scan anyway, instead of filling a separate struct mtd_info. Signed-off-by: Marek Behún Cc: Jagan Teki Cc: Priyanka Jain Cc: Simon Glass Cc: Heiko Schocher Cc: Jagan Teki --- drivers/mtd/spi/sf_internal.h | 4 ++-- drivers/mtd/spi/sf_mtd.c | 18 +- drivers/mtd/spi/sf_probe.c| 6 -- 3 files changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h index 9ceff0e7c1..865955124c 100644 --- a/drivers/mtd/spi/sf_internal.h +++ b/drivers/mtd/spi/sf_internal.h @@ -77,14 +77,14 @@ extern const struct flash_info spi_nor_ids[]; #if CONFIG_IS_ENABLED(SPI_FLASH_MTD) int spi_flash_mtd_register(struct spi_flash *flash); -void spi_flash_mtd_unregister(void); +void spi_flash_mtd_unregister(struct spi_flash *flash); #else static inline int spi_flash_mtd_register(struct spi_flash *flash) { return 0; } -static inline void spi_flash_mtd_unregister(void) +static inline void spi_flash_mtd_unregister(struct spi_flash *flash) { } #endif diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c index 987fac2501..94854fbfc4 100644 --- a/drivers/mtd/spi/sf_mtd.c +++ b/drivers/mtd/spi/sf_mtd.c @@ -10,6 +10,20 @@ #include #include +#if CONFIG_IS_ENABLED(DM_SPI_FLASH) + +int spi_flash_mtd_register(struct spi_flash *flash) +{ + return add_mtd_device(>mtd); +} + +void spi_flash_mtd_unregister(struct spi_flash *flash) +{ + del_mtd_device(>mtd); +} + +#else /* !CONFIG_IS_ENABLED(DM_SPI_FLASH) */ + static struct mtd_info sf_mtd_info; static bool sf_mtd_registered; static char sf_mtd_name[8]; @@ -123,7 +137,7 @@ int spi_flash_mtd_register(struct spi_flash *flash) return ret; } -void spi_flash_mtd_unregister(void) +void spi_flash_mtd_unregister(struct spi_flash *flash) { int ret; @@ -146,3 +160,5 @@ void spi_flash_mtd_unregister(void) printf("Failed to unregister MTD %s and the spi_flash object is going away: you're in deep trouble!", sf_mtd_info.name); } + +#endif /* !CONFIG_IS_ENABLED(DM_SPI_FLASH) */ diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c index 6c87434867..3bf2ecd51a 100644 --- a/drivers/mtd/spi/sf_probe.c +++ b/drivers/mtd/spi/sf_probe.c @@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs, void spi_flash_free(struct spi_flash *flash) { if (CONFIG_IS_ENABLED(SPI_FLASH_MTD)) - spi_flash_mtd_unregister(); + spi_flash_mtd_unregister(flash); spi_free_slave(flash->spi); free(flash); @@ -143,8 +143,10 @@ int spi_flash_std_probe(struct udevice *dev) static int spi_flash_std_remove(struct udevice *dev) { + struct spi_flash *flash = dev_get_uclass_priv(dev); + if (CONFIG_IS_ENABLED(SPI_FLASH_MTD)) - spi_flash_mtd_unregister(); + spi_flash_mtd_unregister(flash); return 0; } -- 2.26.2
[PATCH u-boot-dm + u-boot-spi 1/6] dm: add non-translating version of ofnode_get_addr_size_index
Add functions ofnode_get_addr_size_index_notrans(), which is a non-translating version of ofnode_get_addr_size_index(). Some addresses are not meant to be translated, for example those of MTD fixed-partitions. Signed-off-by: Marek Behún Cc: Dario Binacchi Cc: Simon Glass --- drivers/core/ofnode.c | 19 --- include/dm/ofnode.h | 17 + 2 files changed, 33 insertions(+), 3 deletions(-) diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c index 7a5f4c0a73..88266e2641 100644 --- a/drivers/core/ofnode.c +++ b/drivers/core/ofnode.c @@ -298,7 +298,8 @@ ofnode ofnode_get_by_phandle(uint phandle) return node; } -fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, fdt_size_t *size) +static fdt_addr_t __ofnode_get_addr_size_index(ofnode node, int index, + fdt_size_t *size, bool translate) { int na, ns; @@ -316,7 +317,7 @@ fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, fdt_size_t *size) ns = of_n_size_cells(ofnode_to_np(node)); - if (IS_ENABLED(CONFIG_OF_TRANSLATE) && + if (translate && IS_ENABLED(CONFIG_OF_TRANSLATE) && (ns > 0 || gd_size_cells_0())) { return of_translate_address(ofnode_to_np(node), prop_val); } else { @@ -328,12 +329,24 @@ fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, fdt_size_t *size) ns = ofnode_read_simple_size_cells(ofnode_get_parent(node)); return fdtdec_get_addr_size_fixed(gd->fdt_blob, ofnode_to_offset(node), "reg", - index, na, ns, size, true); + index, na, ns, size, + translate); } return FDT_ADDR_T_NONE; } +fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, fdt_size_t *size) +{ + return __ofnode_get_addr_size_index(node, index, size, true); +} + +fdt_addr_t ofnode_get_addr_size_index_notrans(ofnode node, int index, + fdt_size_t *size) +{ + return __ofnode_get_addr_size_index(node, index, size, false); +} + fdt_addr_t ofnode_get_addr_index(ofnode node, int index) { fdt_size_t size; diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h index 5b088650d3..6ab6fc5586 100644 --- a/include/dm/ofnode.h +++ b/include/dm/ofnode.h @@ -487,6 +487,23 @@ int ofnode_read_size(ofnode node, const char *propname); phys_addr_t ofnode_get_addr_size_index(ofnode node, int index, fdt_size_t *size); +/** + * ofnode_get_addr_size_index_notrans() - get an address/size from a node + * based on index, without address + * translation + * + * This reads the register address/size from a node based on index. + * The resulting address is not translated. Useful for example for on-disk + * addresses. + * + * @node: node to read from + * @index: Index of address to read (0 for first) + * @size: Pointer to size of the address + * @return address, or FDT_ADDR_T_NONE if not present or invalid + */ +phys_addr_t ofnode_get_addr_size_index_notrans(ofnode node, int index, + fdt_size_t *size); + /** * ofnode_get_addr_index() - get an address from a node * -- 2.26.2
[PATCH u-boot-dm + u-boot-spi 0/6] Support SPI NORs and OF partitions in `mtd list`
Hello, this patchset adds support for U-Boot to parse MTD partitions from device-tree, and also improves support for SPI NOR access via the `mtd` command. Marek Cc: Tom Rini Cc: Dario Binacchi Cc: Jagan Teki Cc: Priyanka Jain Cc: Simon Glass Cc: Heiko Schocher Cc: Jagan Teki Marek Behún (6): dm: add non-translating version of ofnode_get_addr_size_index mtd: add support for parsing partitions defined in OF mtd: spi-nor: allow registering multiple MTDs when DM is enabled mtd: spi-nor: fill-in mtd->dev member mtd: remove mtd_probe function mtd: probe SPI NOR devices in mtd_probe_devices() drivers/core/ofnode.c | 19 - drivers/mtd/mtd-uclass.c | 15 drivers/mtd/mtd_uboot.c| 128 - drivers/mtd/mtdpart.c | 60 drivers/mtd/spi/sf_internal.h | 4 +- drivers/mtd/spi/sf_mtd.c | 19 - drivers/mtd/spi/sf_probe.c | 6 +- drivers/mtd/spi/spi-nor-core.c | 1 + drivers/mtd/spi/spi-nor-tiny.c | 1 + include/dm/ofnode.h| 17 + include/linux/mtd/mtd.h| 9 +++ include/mtd.h | 1 - 12 files changed, 206 insertions(+), 74 deletions(-) -- 2.26.2
[PATCH u-boot-marvell] ARM: dts: armada-385-turris-omnia: rename node in -u-boot.dtsi file
The SPI NOR flash node name in main device tree for Turris Omnia is called `spi-nor@0`. Rename node spi-flash@0 in Turris Omnia's -u-boot.dtsi file to spi-nor@0 so that U-Boot does not try to probe the same SPI NOR device multiple times. Signed-off-by: Marek Behún Cc: Stefan Roese --- arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi b/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi index 1b46797583..af0655daaa 100644 --- a/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi +++ b/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi @@ -41,10 +41,7 @@ { u-boot,dm-pre-reloc; - spi-flash@0 { - compatible = "jedec,spi-nor"; - reg = <0>; - spi-max-frequency = <4000>; + spi-nor@0 { u-boot,dm-pre-reloc; }; }; -- 2.26.2
Re: [PATCH 4/6] usb: xhci-pci: Move reset logic out of XHCI core
On 2/8/21 8:27 PM, Samuel Holland wrote: > On 2/8/21 5:43 AM, Marek Vasut wrote: >> On 2/8/21 6:57 AM, Samuel Holland wrote: >>> Resetting an XHCI controller inside xhci_register undoes any register >>> setup performed by the platform driver. And at least on the Allwinner >>> H6, resetting the XHCI controller also resets the PHY, which prevents >>> the controller from working. That means the controller must be taken out >>> of reset before initializing the PHY, which must be done before calling >>> xhci_register. >>> >>> The logic in the XHCI core was added to support the Raspberry Pi 4 >>> (although this was not mentioned in the commit log!), which uses the >>> xhci-pci platform driver. Move the reset logic to the platform driver, >>> where it belongs, and where it cannot interfere with other platform >>> drivers. >> >> Are there any other XHCI drivers using the XHCI core code which might >> stop resetting correctly due to this patch ? > > Since commit 0b80371b350e was merged, the only new call to xhci_register > is in USB_MTU3. Neither the binding for "mediatek,mtu3" nor any device > tree node containing that compatible string has a "resets" property. And > there have been no calls to reset_(de)assert since then, either. So I do ...no calls to reset_(de)assert *removed from any driver* since then... > not see any other drivers that would be likely to break. > > Samuel >
Re: [PATCH 4/6] usb: xhci-pci: Move reset logic out of XHCI core
On 2/8/21 5:43 AM, Marek Vasut wrote: > On 2/8/21 6:57 AM, Samuel Holland wrote: >> Resetting an XHCI controller inside xhci_register undoes any register >> setup performed by the platform driver. And at least on the Allwinner >> H6, resetting the XHCI controller also resets the PHY, which prevents >> the controller from working. That means the controller must be taken out >> of reset before initializing the PHY, which must be done before calling >> xhci_register. >> >> The logic in the XHCI core was added to support the Raspberry Pi 4 >> (although this was not mentioned in the commit log!), which uses the >> xhci-pci platform driver. Move the reset logic to the platform driver, >> where it belongs, and where it cannot interfere with other platform >> drivers. > > Are there any other XHCI drivers using the XHCI core code which might > stop resetting correctly due to this patch ? Since commit 0b80371b350e was merged, the only new call to xhci_register is in USB_MTU3. Neither the binding for "mediatek,mtu3" nor any device tree node containing that compatible string has a "resets" property. And there have been no calls to reset_(de)assert since then, either. So I do not see any other drivers that would be likely to break. Samuel
Re: [PATCH v2 2/3] board: freescale: undef CONFIG_SPL_DM_I2C for SPL
On Tue, Feb 09, 2021 at 01:37:54AM +0200, Igor Opaniuk wrote: > From: Igor Opaniuk > > Replace CONFIG_DM_I2C undefs with CONFIG_SPL_DM_I2C for the SPL build > case. This should be moved to appropriate board defconfigs > in the future. > > Signed-off-by: Igor Opaniuk > --- > > (no changes since v1) > > include/configs/T104xRDB.h | 2 +- > include/configs/imx8mp_evk.h | 2 +- > include/configs/ls1021atwr.h | 2 +- > include/configs/ls1046a_common.h | 2 +- > include/configs/phycore_imx8mp.h | 2 +- > 5 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h > index aee00a86cf..f4d0aec42b 100644 > --- a/include/configs/T104xRDB.h > +++ b/include/configs/T104xRDB.h > @@ -30,7 +30,7 @@ > #define CONFIG_SPL_SKIP_RELOCATE > #define CONFIG_SPL_COMMON_INIT_DDR > #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE > -#undef CONFIG_DM_I2C > +#undef CONFIG_SPL_DM_I2C > #endif > #define RESET_VECTOR_OFFSET 0x27FFC > #define BOOT_PAGE_OFFSET 0x27000 > diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h > index 4850b1b934..33c5759b46 100644 > --- a/include/configs/imx8mp_evk.h > +++ b/include/configs/imx8mp_evk.h > @@ -37,7 +37,7 @@ > #define CONFIG_POWER_I2C > #define CONFIG_POWER_PCA9450 > > -#undef CONFIG_DM_I2C > +#undef CONFIG_SPL_DM_I2C > #define CONFIG_SYS_I2C > > #endif > diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h > index 3e85bb3850..f2bf35ffa5 100644 > --- a/include/configs/ls1021atwr.h > +++ b/include/configs/ls1021atwr.h > @@ -435,7 +435,7 @@ > > #ifdef CONFIG_SPL_BUILD > #define CONFIG_SYS_MONITOR_BASE CONFIG_SPL_TEXT_BASE > -#undef CONFIG_DM_I2C > +#undef CONFIG_SPL_DM_I2C > #else > #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE/* start of monitor > */ > #endif > diff --git a/include/configs/ls1046a_common.h > b/include/configs/ls1046a_common.h > index d44a7f105e..b5bbb636da 100644 > --- a/include/configs/ls1046a_common.h > +++ b/include/configs/ls1046a_common.h > @@ -16,7 +16,7 @@ > #define SPL_NO_QSPI > #define SPL_NO_USB > #define SPL_NO_SATA > -#undef CONFIG_DM_I2C > +#undef CONFIG_SPL_DM_I2C > #endif > #if defined(CONFIG_SPL_BUILD) && \ > (defined(CONFIG_NAND_BOOT) || defined(CONFIG_QSPI_BOOT)) > diff --git a/include/configs/phycore_imx8mp.h > b/include/configs/phycore_imx8mp.h > index 889dd36e6e..dcd320f746 100644 > --- a/include/configs/phycore_imx8mp.h > +++ b/include/configs/phycore_imx8mp.h > @@ -33,7 +33,7 @@ > #define CONFIG_POWER_I2C > #define CONFIG_POWER_PCA9450 > > -#undef CONFIG_DM_I2C > +#undef CONFIG_SPL_DM_I2C > #define CONFIG_SYS_I2C > > #endif This is somewhere between "doesn't actually work" and "works by chance". Since you're adding the symbol to Kconfig, keep it disabled on these boards in the defconfig please. -- Tom signature.asc Description: PGP signature
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
On 9/02/21 3:07 pm, Marek Behun wrote: > On Tue, 9 Feb 2021 01:08:54 + > Chris Packham wrote: > >> On 9/02/21 1:16 pm, Chris Packham wrote: >>> On 9/02/21 9:18 am, Marek Behun wrote: On Mon, 8 Feb 2021 20:11:06 + Chris Packham wrote: > Hi Marek, > > Do you have this in a repo I can pull from? I've got a couple of boards > I can give this a spin on. https://gitlab.nic.cz/turris/turris-omnia-uboot/ branch v2021.04-rc-mv-ddr-14.0.0 also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that one contains one more commit that is needed for Omnia with Samsung DDR chips. >>> I've tested the dm-88f6820-amc board. Training completed without >>> issue, as does memtester running from Linux. >>> >>> Hit a bit of a snag on the x530 because the changes pushed it over the >>> SPL size (it was already pretty close). I'll look to see if there's >>> anything I can drop out or maybe bump the SPL size (I never did get a >>> clear answer from Marvell as to what the size limit actually is). >> I can temporarily work around the size issue by disabling watchdog >> support in SPL (I really don't want that to be the long term solution). >> >> But then I encounter an odd problem. When I "reset" the board gets >> through the DDR training but never makes it to u-boot proper, but if I >> power cycle it boots through to the u-boot prompt. This doesn't happen >> on the db-88f6820-amc board. One difference between the x530 and the amc >> board is that the x530 has ECC so maybe something is going into the >> weeds if ECC has already been enabled by a previous boot. >> > Could you bisect which commit causes this? I'll give it a try. I've kind of done my dash for u-boot stuff for today but I'll try and get to it later tonight.
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
On Tue, 9 Feb 2021 01:08:54 + Chris Packham wrote: > On 9/02/21 1:16 pm, Chris Packham wrote: > > On 9/02/21 9:18 am, Marek Behun wrote: > >> On Mon, 8 Feb 2021 20:11:06 + > >> Chris Packham wrote: > >> > >>> Hi Marek, > >>> > >>> Do you have this in a repo I can pull from? I've got a couple of boards > >>> I can give this a spin on. > >> https://gitlab.nic.cz/turris/turris-omnia-uboot/ > >> branch v2021.04-rc-mv-ddr-14.0.0 > >> > >> also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that > >> one contains one more commit that is needed for Omnia with Samsung DDR > >> chips. > > > > I've tested the dm-88f6820-amc board. Training completed without > > issue, as does memtester running from Linux. > > > > Hit a bit of a snag on the x530 because the changes pushed it over the > > SPL size (it was already pretty close). I'll look to see if there's > > anything I can drop out or maybe bump the SPL size (I never did get a > > clear answer from Marvell as to what the size limit actually is). > > I can temporarily work around the size issue by disabling watchdog > support in SPL (I really don't want that to be the long term solution). > > But then I encounter an odd problem. When I "reset" the board gets > through the DDR training but never makes it to u-boot proper, but if I > power cycle it boots through to the u-boot prompt. This doesn't happen > on the db-88f6820-amc board. One difference between the x530 and the amc > board is that the x530 has ECC so maybe something is going into the > weeds if ECC has already been enabled by a previous boot. > Could you bisect which commit causes this? Marek
Re: [PATCH 0/6] Allwinner H6 USB3 support
On Sun, 7 Feb 2021 23:57:18 -0600 Samuel Holland wrote: Hi Samuel, > This series adds clock, PHY, and XHCI driver support for the USB3 > controller found in the Allwinner H6 SoC. Below is a log showing it > functioning on the Orange Pi 3. Many thanks for sharing this! The lack of USB 3.0 support annoyed me for a while (not so much for SuperSpeed, but more for another usable USB port). I had some patches myself, but stopped with some hacks after I realised the resets properties blunder. So many thanks for finding a much better solution for this! There might be still some discussion around this, but at least we have something in a working and non-hackish state. I commented on the individual patches! Cheers, Andre > U-Boot 2021.04-rc1-00068-g6b8f4e0d060 (Jan 01 1970 - 00:00:00 +) > Allwinner Technology > > CPU: Allwinner H6 (SUN50I) > Model: OrangePi 3 > DRAM: 2 GiB > MMC: mmc@402: 0, mmc@4021000: 2, mmc@4022000: 1 > Loading Environment from FAT... Unable to use mmc 1:0... In:serial@500 > Out: serial@500 > Err: serial@500 > Net: No ethernet found. > starting USB... > Bus usb@5101000: USB EHCI 1.00 > Bus usb@5101400: USB OHCI 1.0 > Bus usb@520: Register 2000140 NbrPorts 2 > Starting the controller > USB XHCI 1.00 > Bus usb@5311000: USB EHCI 1.00 > Bus usb@5311400: USB OHCI 1.0 > scanning bus usb@5101000 for devices... 1 USB Device(s) found > scanning bus usb@5101400 for devices... 1 USB Device(s) found > scanning bus usb@520 for devices... 4 USB Device(s) found > scanning bus usb@5311000 for devices... 1 USB Device(s) found > scanning bus usb@5311400 for devices... 1 USB Device(s) found >scanning usb for storage devices... 1 Storage Device(s) found > Hit any key to stop autoboot: 0 > => usb tree > USB device tree: > 1 Hub (480 Mb/s, 0mA) > u-boot EHCI Host Controller > > 1 Hub (12 Mb/s, 0mA) > U-Boot Root Hub > > 1 Hub (5 Gb/s, 0mA) > | U-Boot XHCI Host Controller > | > +-2 Hub (5 Gb/s, 0mA) > | | GenesysLogic USB3.1 Hub > | | > | +-4 Mass Storage (5 Gb/s, 224mA) > |071044991D8D6A81 > | > +-3 Hub (480 Mb/s, 100mA) >GenesysLogic USB2.1 Hub > > 1 Hub (480 Mb/s, 0mA) > u-boot EHCI Host Controller > > 1 Hub (12 Mb/s, 0mA) > U-Boot Root Hub > > Samuel Holland (6): > clk: sunxi: Add a dummy clock driver for the RTC > clk: sunxi: h6: Add XHCI clocks > phy: sun50i-usb3: Add a driver for the H6 USB3 PHY > usb: xhci-pci: Move reset logic out of XHCI core > usb: xhci-dwc3: Add support for clocks/resets > configs: Enable USB3 on Allwinner H6 boards > > configs/orangepi_3_defconfig| 5 + > configs/pine_h64_defconfig | 5 + > drivers/clk/sunxi/Makefile | 2 + > drivers/clk/sunxi/clk_h6.c | 2 + > drivers/clk/sunxi/clk_sun6i_rtc.c | 35 + > drivers/phy/allwinner/Kconfig | 8 ++ > drivers/phy/allwinner/Makefile | 1 + > drivers/phy/allwinner/phy-sun50i-usb3.c | 171 > drivers/usb/host/xhci-dwc3.c| 56 > drivers/usb/host/xhci-mem.c | 2 - > drivers/usb/host/xhci-pci.c | 38 +- > drivers/usb/host/xhci.c | 35 - > include/usb/xhci.h | 2 - > 13 files changed, 321 insertions(+), 41 deletions(-) > create mode 100644 drivers/clk/sunxi/clk_sun6i_rtc.c > create mode 100644 drivers/phy/allwinner/phy-sun50i-usb3.c >
Re: [PATCH 6/6] configs: Enable USB3 on Allwinner H6 boards
On Sun, 7 Feb 2021 23:57:24 -0600 Samuel Holland wrote: Hi, (CC:ing Maxime and Chen-Yu) > Pine H64 and Orange Pi 3 both provide a USB3 type A port. > Enable it in U-Boot. > > Signed-off-by: Samuel Holland That looks good to me, but the Pine H64 does not enable the USB 3.0 controller in its .dts file. I just added status = "okay"; to the dwc3 and PHY nodes and it worked, though. Does anyone know a reason this is not enabled in the mainline DT (which we just synced)? Cheers, Andre > --- > configs/orangepi_3_defconfig | 5 + > configs/pine_h64_defconfig | 5 + > 2 files changed, 10 insertions(+) > > diff --git a/configs/orangepi_3_defconfig b/configs/orangepi_3_defconfig > index 82b9815205e..eb25bd9f504 100644 > --- a/configs/orangepi_3_defconfig > +++ b/configs/orangepi_3_defconfig > @@ -8,5 +8,10 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=2 > CONFIG_BLUETOOTH_DT_DEVICE_FIXUP="brcm,bcm4345c5" > CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-orangepi-3" > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > +CONFIG_PHY_SUN50I_USB3=y > +CONFIG_USB_XHCI_HCD=y > +CONFIG_USB_XHCI_DWC3=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_DWC3=y > +# CONFIG_USB_DWC3_GADGET is not set > diff --git a/configs/pine_h64_defconfig b/configs/pine_h64_defconfig > index 2fa66f38343..0095fb222e6 100644 > --- a/configs/pine_h64_defconfig > +++ b/configs/pine_h64_defconfig > @@ -12,5 +12,10 @@ CONFIG_SPL_SPI_SUNXI=y > CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-pine-h64" > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SUN8I_EMAC=y > +CONFIG_PHY_SUN50I_USB3=y > +CONFIG_USB_XHCI_HCD=y > +CONFIG_USB_XHCI_DWC3=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_DWC3=y > +# CONFIG_USB_DWC3_GADGET is not set
Re: [PATCH 5/6] usb: xhci-dwc3: Add support for clocks/resets
On Sun, 7 Feb 2021 23:57:23 -0600 Samuel Holland wrote: (CC:ing Simon and Kever) > Some platforms, like the Allwinner H6, do not have a separate glue layer > around the dwc3. Instead, they rely on the clocks/resets/phys referenced > from the dwc3 DT node itself. Add support for enabling the clocks/resets > referenced from the dwc3 DT node. > > Signed-off-by: Samuel Holland That looks alright on a first glance, but have you checked how this interacts with and relates to dwc3-of-simple.c? This seems to do similar things? Cheers, Andre > --- > drivers/usb/host/xhci-dwc3.c | 56 > 1 file changed, 56 insertions(+) > > diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c > index 3e0ae80cece..5b12d1358e4 100644 > --- a/drivers/usb/host/xhci-dwc3.c > +++ b/drivers/usb/host/xhci-dwc3.c > @@ -7,10 +7,12 @@ > * Author: Ramneek Mehresh > */ > > +#include > #include > #include > #include > #include > +#include > #include > #include > #include > @@ -21,7 +23,9 @@ > #include > > struct xhci_dwc3_plat { > + struct clk_bulk clks; > struct phy_bulk phys; > + struct reset_ctl_bulk resets; > }; > > void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode) > @@ -111,6 +115,46 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val) > } > > #if CONFIG_IS_ENABLED(DM_USB) > +static int xhci_dwc3_reset_init(struct udevice *dev, > + struct xhci_dwc3_plat *plat) > +{ > + int ret; > + > + ret = reset_get_bulk(dev, >resets); > + if (ret == -ENOTSUPP || ret == -ENOENT) > + return 0; > + else if (ret) > + return ret; > + > + ret = reset_deassert_bulk(>resets); > + if (ret) { > + reset_release_bulk(>resets); > + return ret; > + } > + > + return 0; > +} > + > +static int xhci_dwc3_clk_init(struct udevice *dev, > + struct xhci_dwc3_plat *plat) > +{ > + int ret; > + > + ret = clk_get_bulk(dev, >clks); > + if (ret == -ENOSYS || ret == -ENOENT) > + return 0; > + if (ret) > + return ret; > + > + ret = clk_enable_bulk(>clks); > + if (ret) { > + clk_release_bulk(>clks); > + return ret; > + } > + > + return 0; > +} > + > static int xhci_dwc3_probe(struct udevice *dev) > { > struct xhci_hcor *hcor; > @@ -122,6 +166,14 @@ static int xhci_dwc3_probe(struct udevice *dev) > u32 reg; > int ret; > > + ret = xhci_dwc3_reset_init(dev, plat); > + if (ret) > + return ret; > + > + ret = xhci_dwc3_clk_init(dev, plat); > + if (ret) > + return ret; > + > hccr = (struct xhci_hccr *)((uintptr_t)dev_remap_addr(dev)); > hcor = (struct xhci_hcor *)((uintptr_t)hccr + > HC_LENGTH(xhci_readl(&(hccr)->cr_capbase))); > @@ -171,6 +223,10 @@ static int xhci_dwc3_remove(struct udevice *dev) > > dwc3_shutdown_phy(dev, >phys); > > + clk_release_bulk(>clks); > + > + reset_release_bulk(>resets); > + > return xhci_deregister(dev); > } >
Re: [PATCH 4/6] usb: xhci-pci: Move reset logic out of XHCI core
On Mon, 8 Feb 2021 12:43:52 +0100 Marek Vasut wrote: (CC:ing Masahiro, Manni and Kever) > On 2/8/21 6:57 AM, Samuel Holland wrote: > > Resetting an XHCI controller inside xhci_register undoes any register > > setup performed by the platform driver. And at least on the Allwinner > > H6, resetting the XHCI controller also resets the PHY, which prevents > > the controller from working. That means the controller must be taken out > > of reset before initializing the PHY, which must be done before calling > > xhci_register. > > > > The logic in the XHCI core was added to support the Raspberry Pi 4 > > (although this was not mentioned in the commit log!), which uses the > > xhci-pci platform driver. Move the reset logic to the platform driver, > > where it belongs, and where it cannot interfere with other platform > > drivers. > > Are there any other XHCI drivers using the XHCI core code which might > stop resetting correctly due to this patch ? That's a fair point. I grep'ed all .dts[i] files in both the kernel and U-Boot for snps,dwc3 users, and there various Uniphier .dtsi files that have resets properties, also the Hisilicon 3660 (HiKey960). The HiKey doesn't seem to enable DWC3 in its defconfig, and from what I can see the Uniphier boards have hardcoded reset deasserts in their glue driver? Masahiro, Manni, Kever, can you confirm that your boards still work, after this whole series? I put a branch here for testing: https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi.git test-usb3-h6 As an added bonus, it would be interesting to see if USB 3.0 still works just after this patch. If not, we might need to squash the next patch into this one. Many thanks! Andre
Re: [PATCH 3/6] phy: sun50i-usb3: Add a driver for the H6 USB3 PHY
On Sun, 7 Feb 2021 23:57:21 -0600 Samuel Holland wrote: Hi, > This driver is needed for XHCI to work on the Allwinner H6 SoC. The > driver is copied from Linux v5.10. > > Signed-off-by: Samuel Holland Compared against the Linux driver, also against the version I made myself a few months ago (in which I spotted two bugs now ;-) Reviewed-by: Andre Przywara Cheers, Andre > --- > drivers/phy/allwinner/Kconfig | 8 ++ > drivers/phy/allwinner/Makefile | 1 + > drivers/phy/allwinner/phy-sun50i-usb3.c | 171 > 3 files changed, 180 insertions(+) > create mode 100644 drivers/phy/allwinner/phy-sun50i-usb3.c > > diff --git a/drivers/phy/allwinner/Kconfig b/drivers/phy/allwinner/Kconfig > index dba3bae61c4..6bfb79cbcad 100644 > --- a/drivers/phy/allwinner/Kconfig > +++ b/drivers/phy/allwinner/Kconfig > @@ -11,3 +11,11 @@ config PHY_SUN4I_USB > > This driver controls the entire USB PHY block, both the USB OTG > parts, as well as the 2 regular USB 2 host PHYs. > + > +config PHY_SUN50I_USB3 > + bool "Allwinner sun50i USB3 PHY driver" > + depends on ARCH_SUNXI > + select PHY > + help > + Enable this to support the USB3 transceiver that is part of > + Allwinner sun50i SoCs. > diff --git a/drivers/phy/allwinner/Makefile b/drivers/phy/allwinner/Makefile > index e709fca643c..f2b60ce1a64 100644 > --- a/drivers/phy/allwinner/Makefile > +++ b/drivers/phy/allwinner/Makefile > @@ -4,3 +4,4 @@ > # > > obj-$(CONFIG_PHY_SUN4I_USB) += phy-sun4i-usb.o > +obj-$(CONFIG_PHY_SUN50I_USB3)+= phy-sun50i-usb3.o > diff --git a/drivers/phy/allwinner/phy-sun50i-usb3.c > b/drivers/phy/allwinner/phy-sun50i-usb3.c > new file mode 100644 > index 000..e5a3d2d92ea > --- /dev/null > +++ b/drivers/phy/allwinner/phy-sun50i-usb3.c > @@ -0,0 +1,171 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Allwinner sun50i(H6) USB 3.0 phy driver > + * > + * Copyright (C) 2020 Samuel Holland > + * > + * Based on the Linux driver, which is: > + * > + * Copyright (C) 2017 Icenowy Zheng > + * > + * Based on phy-sun9i-usb.c, which is: > + * > + * Copyright (C) 2014-2015 Chen-Yu Tsai > + * > + * Based on code from Allwinner BSP, which is: > + * > + * Copyright (c) 2010-2015 Allwinner Technology Co., Ltd. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Interface Status and Control Registers */ > +#define SUNXI_ISCR 0x00 > +#define SUNXI_PIPE_CLOCK_CONTROL 0x14 > +#define SUNXI_PHY_TUNE_LOW 0x18 > +#define SUNXI_PHY_TUNE_HIGH 0x1c > +#define SUNXI_PHY_EXTERNAL_CONTROL 0x20 > + > +/* USB2.0 Interface Status and Control Register */ > +#define SUNXI_ISCR_FORCE_VBUS(3 << 12) > + > +/* PIPE Clock Control Register */ > +#define SUNXI_PCC_PIPE_CLK_OPEN (1 << 6) > + > +/* PHY External Control Register */ > +#define SUNXI_PEC_EXTERN_VBUS(3 << 1) > +#define SUNXI_PEC_SSC_EN (1 << 24) > +#define SUNXI_PEC_REF_SSP_EN (1 << 26) > + > +/* PHY Tune High Register */ > +#define SUNXI_TX_DEEMPH_3P5DB(n) ((n) << 19) > +#define SUNXI_TX_DEEMPH_3P5DB_MASK GENMASK(24, 19) > +#define SUNXI_TX_DEEMPH_6DB(n) ((n) << 13) > +#define SUNXI_TX_DEEMPH_6GB_MASK GENMASK(18, 13) > +#define SUNXI_TX_SWING_FULL(n) ((n) << 6) > +#define SUNXI_TX_SWING_FULL_MASK GENMASK(12, 6) > +#define SUNXI_LOS_BIAS(n)((n) << 3) > +#define SUNXI_LOS_BIAS_MASK GENMASK(5, 3) > +#define SUNXI_TXVBOOSTLVL(n) ((n) << 0) > +#define SUNXI_TXVBOOSTLVL_MASK GENMASK(2, 0) > + > +struct sun50i_usb3_phy_priv { > + void __iomem *regs; > + struct reset_ctl reset; > + struct clk clk; > +}; > + > +static void sun50i_usb3_phy_open(struct sun50i_usb3_phy_priv *phy) > +{ > + u32 val; > + > + val = readl(phy->regs + SUNXI_PHY_EXTERNAL_CONTROL); > + val |= SUNXI_PEC_EXTERN_VBUS; > + val |= SUNXI_PEC_SSC_EN | SUNXI_PEC_REF_SSP_EN; > + writel(val, phy->regs + SUNXI_PHY_EXTERNAL_CONTROL); > + > + val = readl(phy->regs + SUNXI_PIPE_CLOCK_CONTROL); > + val |= SUNXI_PCC_PIPE_CLK_OPEN; > + writel(val, phy->regs + SUNXI_PIPE_CLOCK_CONTROL); > + > + val = readl(phy->regs + SUNXI_ISCR); > + val |= SUNXI_ISCR_FORCE_VBUS; > + writel(val, phy->regs + SUNXI_ISCR); > + > + /* > + * All the magic numbers written to the PHY_TUNE_{LOW_HIGH} > + * registers are directly taken from the BSP USB3 driver from > + * Allwiner. > + */ > + writel(0x0047fc87, phy->regs + SUNXI_PHY_TUNE_LOW); > + > + val = readl(phy->regs + SUNXI_PHY_TUNE_HIGH); > + val &= ~(SUNXI_TXVBOOSTLVL_MASK | SUNXI_LOS_BIAS_MASK | > + SUNXI_TX_SWING_FULL_MASK | SUNXI_TX_DEEMPH_6GB_MASK | > + SUNXI_TX_DEEMPH_3P5DB_MASK); > + val |= SUNXI_TXVBOOSTLVL(0x7); > + val |=
Re: [PATCH 2/6] clk: sunxi: h6: Add XHCI clocks
On Sun, 7 Feb 2021 23:57:20 -0600 Samuel Holland wrote: > The XHCI controller has its own clock and reset. Add them. > > Signed-off-by: Samuel Holland Checked against the manual: Reviewed-by: Andre Przywara Cheers, Andre > --- > drivers/clk/sunxi/clk_h6.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/clk/sunxi/clk_h6.c b/drivers/clk/sunxi/clk_h6.c > index ac8656fe895..df93d96b3b0 100644 > --- a/drivers/clk/sunxi/clk_h6.c > +++ b/drivers/clk/sunxi/clk_h6.c > @@ -43,6 +43,7 @@ static struct ccu_clk_gate h6_gates[] = { > [CLK_BUS_OHCI0] = GATE(0xa8c, BIT(0)), > [CLK_BUS_OHCI3] = GATE(0xa8c, BIT(3)), > [CLK_BUS_EHCI0] = GATE(0xa8c, BIT(4)), > + [CLK_BUS_XHCI] = GATE(0xa8c, BIT(5)), > [CLK_BUS_EHCI3] = GATE(0xa8c, BIT(7)), > [CLK_BUS_OTG] = GATE(0xa8c, BIT(8)), > }; > @@ -71,6 +72,7 @@ static struct ccu_reset h6_resets[] = { > [RST_BUS_OHCI0] = RESET(0xa8c, BIT(16)), > [RST_BUS_OHCI3] = RESET(0xa8c, BIT(19)), > [RST_BUS_EHCI0] = RESET(0xa8c, BIT(20)), > + [RST_BUS_XHCI] = RESET(0xa8c, BIT(21)), > [RST_BUS_EHCI3] = RESET(0xa8c, BIT(23)), > [RST_BUS_OTG] = RESET(0xa8c, BIT(24)), > };
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
On 9/02/21 1:16 pm, Chris Packham wrote: > On 9/02/21 9:18 am, Marek Behun wrote: >> On Mon, 8 Feb 2021 20:11:06 + >> Chris Packham wrote: >> >>> Hi Marek, >>> >>> Do you have this in a repo I can pull from? I've got a couple of boards >>> I can give this a spin on. >> https://gitlab.nic.cz/turris/turris-omnia-uboot/ >> branch v2021.04-rc-mv-ddr-14.0.0 >> >> also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that >> one contains one more commit that is needed for Omnia with Samsung DDR >> chips. > > I've tested the dm-88f6820-amc board. Training completed without > issue, as does memtester running from Linux. > > Hit a bit of a snag on the x530 because the changes pushed it over the > SPL size (it was already pretty close). I'll look to see if there's > anything I can drop out or maybe bump the SPL size (I never did get a > clear answer from Marvell as to what the size limit actually is). I can temporarily work around the size issue by disabling watchdog support in SPL (I really don't want that to be the long term solution). But then I encounter an odd problem. When I "reset" the board gets through the DDR training but never makes it to u-boot proper, but if I power cycle it boots through to the u-boot prompt. This doesn't happen on the db-88f6820-amc board. One difference between the x530 and the amc board is that the x530 has ECC so maybe something is going into the weeds if ECC has already been enabled by a previous boot.
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
On 9/02/21 9:18 am, Marek Behun wrote: > On Mon, 8 Feb 2021 20:11:06 + > Chris Packham wrote: > >> Hi Marek, >> >> Do you have this in a repo I can pull from? I've got a couple of boards >> I can give this a spin on. > https://gitlab.nic.cz/turris/turris-omnia-uboot/ > branch v2021.04-rc-mv-ddr-14.0.0 > > also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that > one contains one more commit that is needed for Omnia with Samsung DDR > chips. I've tested the dm-88f6820-amc board. Training completed without issue, as does memtester running from Linux. Hit a bit of a snag on the x530 because the changes pushed it over the SPL size (it was already pretty close). I'll look to see if there's anything I can drop out or maybe bump the SPL size (I never did get a clear answer from Marvell as to what the size limit actually is).
[PATCH v2 3/3] dm: i2c: use CONFIG_IS_ENABLED macro for DM_I2C/DM_I2C_GPIO
From: Igor Opaniuk Use CONFIG_IS_ENABLED() macro, which provides more convenient way to check $(SPL)DM_I2C/$(SPL)DM_I2C_GPIO configs for both SPL and U-Boot proper. CONFIG_IS_ENABLED(DM_I2C) expands to: - 1 if CONFIG_SPL_BUILD is undefined and CONFIG_DM_I2C is set to 'y', - 1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_DM_I2C is set to 'y', - 0 otherwise. All occurences were replaced automatically using these bash cmds: $ find . -type f -exec sed -i 's/ifndef CONFIG_DM_I2C/if !CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/ifdef CONFIG_DM_I2C/if CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/defined(CONFIG_DM_I2C)/CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/ifndef CONFIG_DM_I2C_GPIO/if !CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + $ find . -type f -exec sed -i 's/ifdef CONFIG_DM_I2C_GPIO/if CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + $ find . -type f -exec sed -i 's/defined(CONFIG_DM_I2C_GPIO)/CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + Reviewed-by: Heiko Schocher Reviewed-by: Simon Glass Signed-off-by: Igor Opaniuk --- Changes v2: - R-b tags applied .../include/asm/arch-fsl-layerscape/config.h | 2 +- arch/arm/include/asm/arch-lpc32xx/i2c.h | 2 +- arch/arm/include/asm/mach-imx/mxc_i2c.h | 2 +- arch/arm/include/asm/omap_i2c.h | 2 +- arch/arm/mach-imx/i2c-mxv7.c | 2 +- arch/arm/mach-keystone/ddr3_spd.c | 2 +- arch/arm/mach-kirkwood/include/mach/config.h | 2 +- arch/arm/mach-omap2/am33xx/board.c| 2 +- arch/arm/mach-omap2/am33xx/clk_synthesizer.c | 6 +- arch/arm/mach-omap2/boot-common.c | 2 +- arch/arm/mach-omap2/clocks-common.c | 2 +- arch/arm/mach-sunxi/board.c | 2 +- arch/powerpc/include/asm/fsl_i2c.h| 2 +- board/freescale/common/dcu_sii9022a.c | 2 +- board/freescale/common/diu_ch7301.c | 2 +- board/freescale/common/emc2305.c | 4 +- board/freescale/common/qixis.c| 4 +- board/freescale/common/sys_eeprom.c | 20 ++-- board/freescale/common/vid.c | 24 ++--- board/freescale/common/vsc3316_3308.c | 10 +- board/freescale/ls1012aqds/ls1012aqds.c | 2 +- board/freescale/ls1012ardb/eth.c | 2 +- board/freescale/ls1012ardb/ls1012ardb.c | 12 +-- board/freescale/ls1021aqds/dcu.c | 6 +- board/freescale/ls1021aqds/ls1021aqds.c | 2 +- board/freescale/ls1021atwr/ls1021atwr.c | 2 +- board/freescale/ls1028a/ls1028a.c | 2 +- board/freescale/ls1043aqds/ls1043aqds.c | 4 +- board/freescale/ls1046afrwy/ls1046afrwy.c | 2 +- board/freescale/ls1046aqds/ls1046aqds.c | 2 +- board/freescale/ls1088a/eth_ls1088aqds.c | 16 +-- board/freescale/ls1088a/ls1088a.c | 60 ++-- board/freescale/ls2080aqds/eth.c | 14 +-- board/freescale/ls2080aqds/ls2080aqds.c | 4 +- board/freescale/ls2080ardb/ls2080ardb.c | 2 +- board/freescale/lx2160a/lx2160a.c | 2 +- board/freescale/p1010rdb/p1010rdb.c | 8 +- board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 2 +- board/freescale/t102xrdb/t102xrdb.c | 2 +- board/freescale/t208xqds/t208xqds.c | 2 +- board/friendlyarm/nanopi2/onewire.c | 6 +- board/keymile/common/ivm.c| 2 +- board/samsung/common/misc.c | 2 +- board/samsung/trats/trats.c | 10 +- board/samsung/trats2/trats2.c | 10 +- board/sunxi/board.c | 2 +- board/ti/am335x/board.c | 8 +- board/ti/am335x/mux.c | 2 +- board/ti/am43xx/board.c | 12 +-- board/ti/common/board_detect.c| 4 +- board/ti/ks2_evm/board_k2g.c | 2 +- board/wandboard/wandboard.c | 4 +- cmd/eeprom.c | 6 +- cmd/i2c.c | 98 +-- doc/driver-model/i2c-howto.rst| 2 +- drivers/ddr/fsl/main.c| 8 +- drivers/i2c/davinci_i2c.c | 4 +- drivers/i2c/designware_i2c.c | 4 +- drivers/i2c/fsl_i2c.c | 6 +- drivers/i2c/ihs_i2c.c | 42 drivers/i2c/lpc32xx_i2c.c | 4 +- drivers/i2c/mv_i2c.c | 2 +- drivers/i2c/mvtwsi.c | 16 +-- drivers/i2c/mxc_i2c.c | 4 +- drivers/i2c/omap24xx_i2c.c| 2 +- drivers/power/palmas.c| 2 +- drivers/power/pmic/pmic_tps62362.c| 6 +- drivers/power/pmic/pmic_tps65217.c| 14 +-- drivers/power/pmic/pmic_tps65218.c| 4 +-
[PATCH v2 0/3] Allow disabling driver model for I2C in SPL
From: Igor Opaniuk At present if U-Boot proper uses driver model for I2C, then SPL has to also. While this is desirable, it places a significant barrier to moving to driver model in some cases. For example, with a space-constrained SPL it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves adjusting some drivers. This patch introduces a separate Kconfig symbols for enabling DM_I2C and DM_I2C_GPIO support in SPL. This will also help to get away from dirty workarounds to achieve non-DM I2C support for SPL, which is currently used in some board header files like: ifdef CONFIG_SPL_BUILD undef CONFIG_DM_I2C endif All occurences were replaced automatically using these bash cmds: $ find . -type f -exec sed -i 's/ifndef CONFIG_DM_I2C/if !CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/ifdef CONFIG_DM_I2C/if CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/defined(CONFIG_DM_I2C)/CONFIG_IS_ENABLED(DM_I2C)/g' {} + $ find . -type f -exec sed -i 's/ifndef CONFIG_DM_I2C_GPIO/if !CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + $ find . -type f -exec sed -i 's/ifdef CONFIG_DM_I2C_GPIO/if CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + $ find . -type f -exec sed -i 's/defined(CONFIG_DM_I2C_GPIO)/CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} + Azure CI results: https://dev.azure.com/igoropaniuk/u-boot/_build/results?buildId=5=results Changes in v2: - Applied R-b tags from Simon and Heiko - Added additional patches that replace CONFIG_DM_I2C undefs with CONFIG_SPL_DM_I2C for SPL build case (this should be moved to board defconfigs by board maintainers) Igor Opaniuk (3): dm: i2c: allow disabling driver model in SPL board: freescale: undef CONFIG_SPL_DM_I2C for SPL dm: i2c: use CONFIG_IS_ENABLED macro for DM_I2C/DM_I2C_GPIO .../include/asm/arch-fsl-layerscape/config.h | 2 +- arch/arm/include/asm/arch-lpc32xx/i2c.h | 2 +- arch/arm/include/asm/mach-imx/mxc_i2c.h | 2 +- arch/arm/include/asm/omap_i2c.h | 2 +- arch/arm/mach-imx/i2c-mxv7.c | 2 +- arch/arm/mach-keystone/ddr3_spd.c | 2 +- arch/arm/mach-kirkwood/include/mach/config.h | 2 +- arch/arm/mach-omap2/am33xx/board.c| 2 +- arch/arm/mach-omap2/am33xx/clk_synthesizer.c | 6 +- arch/arm/mach-omap2/boot-common.c | 2 +- arch/arm/mach-omap2/clocks-common.c | 2 +- arch/arm/mach-sunxi/board.c | 2 +- arch/powerpc/include/asm/fsl_i2c.h| 2 +- board/freescale/common/dcu_sii9022a.c | 2 +- board/freescale/common/diu_ch7301.c | 2 +- board/freescale/common/emc2305.c | 4 +- board/freescale/common/qixis.c| 4 +- board/freescale/common/sys_eeprom.c | 20 ++-- board/freescale/common/vid.c | 24 ++--- board/freescale/common/vsc3316_3308.c | 10 +- board/freescale/ls1012aqds/ls1012aqds.c | 2 +- board/freescale/ls1012ardb/eth.c | 2 +- board/freescale/ls1012ardb/ls1012ardb.c | 12 +-- board/freescale/ls1021aqds/dcu.c | 6 +- board/freescale/ls1021aqds/ls1021aqds.c | 2 +- board/freescale/ls1021atwr/ls1021atwr.c | 2 +- board/freescale/ls1028a/ls1028a.c | 2 +- board/freescale/ls1043aqds/ls1043aqds.c | 4 +- board/freescale/ls1046afrwy/ls1046afrwy.c | 2 +- board/freescale/ls1046aqds/ls1046aqds.c | 2 +- board/freescale/ls1088a/eth_ls1088aqds.c | 16 +-- board/freescale/ls1088a/ls1088a.c | 60 ++-- board/freescale/ls2080aqds/eth.c | 14 +-- board/freescale/ls2080aqds/ls2080aqds.c | 4 +- board/freescale/ls2080ardb/ls2080ardb.c | 2 +- board/freescale/lx2160a/lx2160a.c | 2 +- board/freescale/p1010rdb/p1010rdb.c | 8 +- board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 2 +- board/freescale/t102xrdb/t102xrdb.c | 2 +- board/freescale/t208xqds/t208xqds.c | 2 +- board/friendlyarm/nanopi2/onewire.c | 6 +- board/keymile/common/ivm.c| 2 +- board/samsung/common/misc.c | 2 +- board/samsung/trats/trats.c | 10 +- board/samsung/trats2/trats2.c | 10 +- board/sunxi/board.c | 2 +- board/ti/am335x/board.c | 8 +- board/ti/am335x/mux.c | 2 +- board/ti/am43xx/board.c | 12 +-- board/ti/common/board_detect.c| 4 +- board/ti/ks2_evm/board_k2g.c | 2 +- board/wandboard/wandboard.c | 4 +- cmd/eeprom.c | 6 +- cmd/i2c.c | 98 +-- doc/driver-model/i2c-howto.rst| 2 +- drivers/ddr/fsl/main.c| 8 +- drivers/i2c/Kconfig | 21 drivers/i2c/Makefile
Re: [PATCH v4 16/16] gpio: Add a way to read 3-way strapping pins
Hi Patrick, On Mon, 8 Feb 2021 at 11:13, Patrick DELAUNAY wrote: > > Hi Simon, > > On 2/5/21 5:22 AM, Simon Glass wrote: > > Using the internal vs. external pull resistors it is possible to get > > 27 different combinations from 3 strapping pins. Add an implementation > > of this. > > > > This involves updating the sandbox GPIO driver to model external and > > (weaker) internal pull resistors. The get_value() method now takes account > > of what is driving a pin: > > > > sandbox: GPIOD_EXT_DRIVEN - in which case GPIO_EXT_HIGH provides the > >value > > outside source - in which case GPIO_EXT_PULL_UP/DOWN indicates the > >external state and we work the final state using those flags and > >the internal GPIOD_PULL_UP/DOWN flags > > > > Of course the outside source does not really exist in sandbox. We are just > > modelling it for test purpose. > > > > Signed-off-by: Simon Glass > > --- > > > > (no changes since v3) > > > > Changes in v3: > > - Use bits 28, 29 for the new flags > > - Assert that count parameter is within range > > - Redo digit logic to be easier to understand > > - Update function comment to explain the meaning of the digits > > - Fix 'compare' typo > > > > arch/sandbox/include/asm/gpio.h | 5 +- > > drivers/gpio/gpio-uclass.c | 81 +++ > > drivers/gpio/sandbox.c | 13 +++-- > > include/asm-generic/gpio.h | 40 ++ > > test/dm/gpio.c | 98 + > > 5 files changed, 232 insertions(+), 5 deletions(-) > > > (...) > > diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c > > index 700098446b5..d008fdd2224 100644 > > --- a/drivers/gpio/sandbox.c > > +++ b/drivers/gpio/sandbox.c > > @@ -19,7 +19,6 @@ > > #include > > #include > > > > - > > struct gpio_state { > > const char *label; /* label given by requester */ > > ulong flags;/* flags (GPIOD_...) */ > > @@ -81,10 +80,16 @@ int sandbox_gpio_get_value(struct udevice *dev, > > unsigned offset) > > if (get_gpio_flag(dev, offset, GPIOD_IS_OUT)) > > debug("sandbox_gpio: get_value on output gpio %u\n", offset); > > > > - if (state->flags & GPIOD_EXT_DRIVEN) > > + if (state->flags & GPIOD_EXT_DRIVEN) { > > val = state->flags & GPIOD_EXT_HIGH; > > bool here, not int > > + val = !!(state->flags & GPIOD_EXT_HIGH); > > > > - else > > - val = false; > > + } else { > > + if (state->flags & GPIOD_EXT_PULL_UP) > > + val = true; > > + else if (state->flags & GPIOD_EXT_PULL_DOWN) > > + val = false; > > + else > > + val = state->flags & GPIOD_PULL_UP; > > bool also > > + val = !!(state->flags & GPIOD_PULL_UP ); > > > > + } > > > > return val; > > } > > > (...) > > Just to be sure that the sandbox gpio value is 0 or 1 > > with the current code, sandbox_gpio_get_value can return GPIOD_EXT_HIGH > or GPIOD_PULL_UP, and it is strange (even if result in int). I think that is a hack to work around not having a 'bool' type, but we do have one in U-Boot, so I feel it is better to use it, instead using !! See the 'bool val;' in that function. > > > with these 2 changes, you can add my Reviewed-by Regards, Simon
[PATCH v2 1/3] dm: i2c: allow disabling driver model in SPL
From: Igor Opaniuk At present if U-Boot proper uses driver model for I2C, then SPL has to also. While this is desirable, it places a significant barrier to moving to driver model in some cases. For example, with a space-constrained SPL it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves adjusting some drivers. This patch introduces a separate Kconfig symbols for enabling DM_I2C and DM_I2C_GPIO support in SPL. This will also help to get away from dirty workarounds to achieve non-DM I2C support for SPL, which is currently used in some board header files like: ifdef CONFIG_SPL_BUILD undef CONFIG_DM_I2C endif Reviewed-by: Simon Glass Reviewed-by: Heiko Schocher Signed-off-by: Igor Opaniuk --- Changes v2: - R-b tags applied drivers/i2c/Kconfig | 21 + drivers/i2c/Makefile | 4 ++-- drivers/misc/Makefile | 2 +- 3 files changed, 24 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 403602fddf..5fce14122d 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -14,6 +14,17 @@ config DM_I2C device (bus child) info is kept as parent plat. The interface is defined in include/i2c.h. +config SPL_DM_I2C + bool "Enable Driver Model for I2C drivers in SPL" + depends on SPL_DM && DM_I2C + default y + help + Enable driver model for I2C. The I2C uclass interface: probe, read, + write and speed, is implemented with the bus drivers operations, + which provide methods for bus setting and data transfer. Each chip + device (bus child) info is kept as parent platdata. The interface + is defined in include/i2c.h. + config I2C_CROS_EC_TUNNEL tristate "Chrome OS EC tunnel I2C bus" depends on CROS_EC @@ -61,6 +72,16 @@ config DM_I2C_GPIO bindings are supported. Binding info: doc/device-tree-bindings/i2c/i2c-gpio.txt +config SPL_DM_I2C_GPIO + bool "Enable Driver Model for software emulated I2C bus driver in SPL" + depends on SPL_DM && DM_I2C_GPIO && SPL_DM_GPIO && SPL_GPIO_SUPPORT + default y + help + Enable the i2c bus driver emulation by using the GPIOs. The bus GPIO + configuration is given by the device tree. Kernel-style device tree + bindings are supported. + Binding info: doc/device-tree-bindings/i2c/i2c-gpio.txt + config SYS_I2C_AT91 bool "Atmel I2C driver" depends on DM_I2C && ARCH_AT91 diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index 29aab0f9e3..acd27ac29d 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -2,9 +2,9 @@ # # (C) Copyright 2000-2007 # Wolfgang Denk, DENX Software Engineering, w...@denx.de. -obj-$(CONFIG_DM_I2C) += i2c-uclass.o +obj-$(CONFIG_$(SPL_)DM_I2C) += i2c-uclass.o ifdef CONFIG_ACPIGEN -obj-$(CONFIG_DM_I2C) += acpi_i2c.o +obj-$(CONFIG_$(SPL_)DM_I2C) += acpi_i2c.o endif obj-$(CONFIG_$(SPL_)DM_I2C_GPIO) += i2c-gpio.o obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index d737203704..1a49396007 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -17,7 +17,7 @@ obj-$(CONFIG_SANDBOX) += p2sb_sandbox.o p2sb_emul.o obj-$(CONFIG_SANDBOX) += swap_case.o endif -ifdef CONFIG_DM_I2C +ifdef CONFIG_$(SPL_)DM_I2C ifndef CONFIG_SPL_BUILD obj-$(CONFIG_SANDBOX) += i2c_eeprom_emul.o endif -- 2.25.1
[PATCH v2 2/3] board: freescale: undef CONFIG_SPL_DM_I2C for SPL
From: Igor Opaniuk Replace CONFIG_DM_I2C undefs with CONFIG_SPL_DM_I2C for the SPL build case. This should be moved to appropriate board defconfigs in the future. Signed-off-by: Igor Opaniuk --- (no changes since v1) include/configs/T104xRDB.h | 2 +- include/configs/imx8mp_evk.h | 2 +- include/configs/ls1021atwr.h | 2 +- include/configs/ls1046a_common.h | 2 +- include/configs/phycore_imx8mp.h | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h index aee00a86cf..f4d0aec42b 100644 --- a/include/configs/T104xRDB.h +++ b/include/configs/T104xRDB.h @@ -30,7 +30,7 @@ #define CONFIG_SPL_SKIP_RELOCATE #define CONFIG_SPL_COMMON_INIT_DDR #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE -#undef CONFIG_DM_I2C +#undef CONFIG_SPL_DM_I2C #endif #define RESET_VECTOR_OFFSET0x27FFC #define BOOT_PAGE_OFFSET 0x27000 diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h index 4850b1b934..33c5759b46 100644 --- a/include/configs/imx8mp_evk.h +++ b/include/configs/imx8mp_evk.h @@ -37,7 +37,7 @@ #define CONFIG_POWER_I2C #define CONFIG_POWER_PCA9450 -#undef CONFIG_DM_I2C +#undef CONFIG_SPL_DM_I2C #define CONFIG_SYS_I2C #endif diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 3e85bb3850..f2bf35ffa5 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -435,7 +435,7 @@ #ifdef CONFIG_SPL_BUILD #define CONFIG_SYS_MONITOR_BASE CONFIG_SPL_TEXT_BASE -#undef CONFIG_DM_I2C +#undef CONFIG_SPL_DM_I2C #else #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE/* start of monitor */ #endif diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h index d44a7f105e..b5bbb636da 100644 --- a/include/configs/ls1046a_common.h +++ b/include/configs/ls1046a_common.h @@ -16,7 +16,7 @@ #define SPL_NO_QSPI #define SPL_NO_USB #define SPL_NO_SATA -#undef CONFIG_DM_I2C +#undef CONFIG_SPL_DM_I2C #endif #if defined(CONFIG_SPL_BUILD) && \ (defined(CONFIG_NAND_BOOT) || defined(CONFIG_QSPI_BOOT)) diff --git a/include/configs/phycore_imx8mp.h b/include/configs/phycore_imx8mp.h index 889dd36e6e..dcd320f746 100644 --- a/include/configs/phycore_imx8mp.h +++ b/include/configs/phycore_imx8mp.h @@ -33,7 +33,7 @@ #define CONFIG_POWER_I2C #define CONFIG_POWER_PCA9450 -#undef CONFIG_DM_I2C +#undef CONFIG_SPL_DM_I2C #define CONFIG_SYS_I2C #endif -- 2.25.1
Re: [RFC PATCH v2 1/2] optee: obtain emmc rpmb info from dt
Hi Patrick, On Mon, Feb 8, 2021 at 5:06 PM Patrick DELAUNAY wrote: > > Hi Igor, > > On 1/24/21 10:39 AM, Igor Opaniuk wrote: > > From: Igor Opaniuk > > > > Add support for rpmb-dev property in optee node. > > Prioritize that provided eMMC info from DT for RPMB operations over > > the one provided by OP-TEE OS core in RPC calls. > > > > Signed-off-by: Igor Opaniuk > > --- > > > > Changes in v2: > > - Return NULL instead of ERR_PTR(-ENXIO) in get_rpmb_dev in case there > >is no rpmb-dev property or somemithing went wrong > > > > drivers/tee/optee/core.c | 33 + > > drivers/tee/optee/optee_private.h | 2 +- > > drivers/tee/optee/rpmb.c | 60 ++- > > 3 files changed, 70 insertions(+), 25 deletions(-) > > > > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c > > index b898c32edc..828ab9b00a 100644 > > --- a/drivers/tee/optee/core.c > > +++ b/drivers/tee/optee/core.c > > @@ -12,6 +12,7 @@ > > #include > > #include > > #include > > +#include > > > > #include "optee_smc.h" > > #include "optee_msg.h" > > @@ -607,14 +608,46 @@ static optee_invoke_fn *get_invoke_func(struct > > udevice *dev) > > return ERR_PTR(-EINVAL); > > } > > > > +static struct mmc *get_rpmb_dev(struct udevice *dev) > > +{ > > + struct udevice *mmc_dev; > > + const fdt32_t *phandle_p; > > + u32 phandle; > > + int ret = 0; > > + > > + debug("optee: looking for rpmb device in DT.\n"); > > + > > + phandle_p = ofnode_get_property(dev_ofnode(dev), > > + "rpmb-dev", NULL); > > + if (!phandle_p) { > > + debug("optee: missing \"rpmb-dev\" property\n"); > > + return NULL; > > + } > > + > > + phandle = fdt32_to_cpu(*phandle_p); > > + > > + ret = uclass_get_device_by_phandle_id(UCLASS_MMC, phandle, _dev); > > + if (ret) { > > + printf("optee: invalid phandle value in \"rpmb-dev\".\n"); > > + return NULL; > > + } > > + > > + debug("optee: using phandle %d from \"rpmd-dev\" property.\n", > > + phandle); > > + return mmc_get_mmc_dev(mmc_dev); > > +} > > + > > static int optee_of_to_plat(struct udevice *dev) > > { > > struct optee_pdata *pdata = dev_get_plat(dev); > > + struct optee_private *priv = dev_get_priv(dev); > > > > pdata->invoke_fn = get_invoke_func(dev); > > if (IS_ERR(pdata->invoke_fn)) > > return PTR_ERR(pdata->invoke_fn); > > > > Normally optee_of_to_plat should initialized only the platdata and not the > private date > (initialized during probe or driver execution) To be honest that was my initial intention to do that way, but that would have required a complete overhaul of all functions in optee/rpmb.c, so I just tried to find a "golden mean" between the approach you described and something less intrusive. > > And no need to initialize rpmb_mmcif CONFIG_CMD_OPTEE_RPMBI is not activated, Yeah, will fix that. > > I proposed: > > struct optee_pdata { > optee_invoke_fn *invoke_fn; > struct mmc *rpmb_mmc; > }; > > + if (IS_ENABLED(CONFIG_CMD_OPTEE_RPMBI)) > > +pdata->rpmb_mmc = get_rpmb_dev(dev); > > > + priv->rpmb_mmc = get_rpmb_dev(dev); > > + > > return 0; > > } > > > > diff --git a/drivers/tee/optee/optee_private.h > > b/drivers/tee/optee/optee_private.h > > index 1f07a27ee4..8e5a280622 100644 > > --- a/drivers/tee/optee/optee_private.h > > +++ b/drivers/tee/optee/optee_private.h > > @@ -19,8 +19,8 @@ > >*/ > > struct optee_private { > > struct mmc *rpmb_mmc; > > - int rpmb_dev_id; > > int rpmb_original_part; > > + bool rpmb_inited; > > }; > > > > struct optee_msg_arg; > > diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c > > index 0804fc963c..0137c44be1 100644 > > --- a/drivers/tee/optee/rpmb.c > > +++ b/drivers/tee/optee/rpmb.c > > @@ -45,55 +45,67 @@ static void release_mmc(struct optee_private *priv) > > { > > int rc; > > > > - if (!priv->rpmb_mmc) > > + if (!priv->rpmb_mmc || !priv->rpmb_inited) > > return; > > > > - rc = blk_select_hwpart_devnum(IF_TYPE_MMC, priv->rpmb_dev_id, > > - priv->rpmb_original_part); > > + rc = mmc_switch_part(priv->rpmb_mmc, priv->rpmb_original_part); > > if (rc) > > debug("%s: blk_select_hwpart_devnum() failed: %d\n", > > __func__, rc); > > > > - priv->rpmb_mmc = NULL; > > + priv->rpmb_inited = false; > > +} > > + > > +static int check_mmc(struct mmc *mmc) > > +{ > > + if (!mmc) { > > + debug("Cannot find RPMB device\n"); > > + return -ENODEV; > > + } > > + if (!(mmc->version & MMC_VERSION_MMC)) { > > + debug("Device id is not an eMMC device\n"); > > + return -ENODEV; > > + } > > + if (mmc->version < MMC_VERSION_4_41) { > > + debug("RPMB is
Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it
On Monday 08 February 2021 23:45:37 Marek Vasut wrote: > On 2/8/21 11:34 PM, Pali Rohár wrote: > > On Monday 08 February 2021 23:21:38 Pali Rohár wrote: > > > On Monday 08 February 2021 23:15:33 Lukasz Majewski wrote: > > > > Hi Pali, > > > > > > > > > Resended v2 patch series with fixed commit messages > > > > > > > > > > This patch series fix usbtty code (serial console via USB peripheral > > > > > mode), fix underlying musb peripheral code, fix compilation of > > > > > CONFIG_USB_DEVICE (used by usbtty), remove unused Nokia RX-51 code to > > > > > decrease size of U-Boot binary and finally enable usbtty serial > > > > > console for Nokia RX-51. > > > > > > > > > > With this patch series debugging of Nokia RX-51 can be done also via > > > > > USB serial console. > > > > > > > > > > It fixes also stability of musb code and allows usage of file > > > > > transfers via Kermit protocol on Nokia RX-51. Kermit file transfer > > > > > via U-Boot loadb command is stable on Nokia N900 and gives about > > > > > 52kB/s transfer rate. > > > > > > > > > > On computer this serial console is accessible via /dev/ttyACM0 device. > > > > > > > > > > > > > I've integrated your patchset and now it turns out that the u-boot size > > > > is too big: > > > > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=results > > > > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67=f9a6b761-daa3-500f-4840-65a939c5040d > > > > > > Ah :-( > > > In November when I sent these patches, U-Boot binary was smaller. > > > > > > > The branch is https://github.com/lmajewski/u-boot-dfu/tree/testing > > > > > > > > Have you experienced similar issues? > > > > > > Yes, memory for U-Boot is limited. It is needed to decrease size of > > > U-Boot binary and then it will work. > > > > > > I will try to look at it later and find some dead code which can be > > > commented or removed to decrease binary size... > > > > Just a quick test, could you try to add > > > > CONFIG_OPTIMIZE_INLINING=y > > > > into configs/nokia_rx51_defconfig file, if it helps? > > Surely you can try build-testing the patches yourself ? :-) They are working fine on my two testes machines. I do not have this problem which Lukasz described. Otherwise I would not send patches to mailing list for upstream. Also I have tested CONFIG_OPTIMIZE_INLINING and it decreased size of u-boot binary on my machine. But I already figured out that "working on my machine" does not mean that it would also on other machines... In past I hit compiler bugs which caused that on my machine gcc compiled code correctly but on other machine with older (buggy) gcc code was compiled incorrectly and result of computation was incorrect. That is why I'm asking if people who triggered mentioned issue can check if proposed fix helps. Btw, if I understood correctly without CONFIG_OPTIMIZE_INLINING U-Boot redefine "inline" to "always inline". And with CONFIG_OPTIMIZE_INLINING "inline" is "inline". From past I know that gcc is very smart and can decide that it is better to ignore inlining some functions for -Os size optimizations.
Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it
On 2/8/21 11:34 PM, Pali Rohár wrote: On Monday 08 February 2021 23:21:38 Pali Rohár wrote: On Monday 08 February 2021 23:15:33 Lukasz Majewski wrote: Hi Pali, Resended v2 patch series with fixed commit messages This patch series fix usbtty code (serial console via USB peripheral mode), fix underlying musb peripheral code, fix compilation of CONFIG_USB_DEVICE (used by usbtty), remove unused Nokia RX-51 code to decrease size of U-Boot binary and finally enable usbtty serial console for Nokia RX-51. With this patch series debugging of Nokia RX-51 can be done also via USB serial console. It fixes also stability of musb code and allows usage of file transfers via Kermit protocol on Nokia RX-51. Kermit file transfer via U-Boot loadb command is stable on Nokia N900 and gives about 52kB/s transfer rate. On computer this serial console is accessible via /dev/ttyACM0 device. I've integrated your patchset and now it turns out that the u-boot size is too big: https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=results https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67=f9a6b761-daa3-500f-4840-65a939c5040d Ah :-( In November when I sent these patches, U-Boot binary was smaller. The branch is https://github.com/lmajewski/u-boot-dfu/tree/testing Have you experienced similar issues? Yes, memory for U-Boot is limited. It is needed to decrease size of U-Boot binary and then it will work. I will try to look at it later and find some dead code which can be commented or removed to decrease binary size... Just a quick test, could you try to add CONFIG_OPTIMIZE_INLINING=y into configs/nokia_rx51_defconfig file, if it helps? Surely you can try build-testing the patches yourself ? :-)
Re: [PATCH 4/4] timer: imx-gpt: Add basic timer support for i.MX SoCs family
Hi Jesse, this patch should have been squashed with patch 1/4 as already suggested. On 2/8/21 1:24 AM, Jesse Taube wrote: Signed-off-by: Jesse Taube Cc: Stefano Babic Cc: Giulio Benetti Cc: Jesse Taube This timer driver is using GPT Timer (General Purpose Timer) available on almost all i.MX SoCs family. Add code to enable timer. Add code get a defualt prescaler. Add defines for register masks. --- drivers/timer/imx-gpt-timer.c | 50 +-- 1 file changed, 36 insertions(+), 14 deletions(-) diff --git a/drivers/timer/imx-gpt-timer.c b/drivers/timer/imx-gpt-timer.c index c4e8c12a42..ed6487af97 100644 --- a/drivers/timer/imx-gpt-timer.c +++ b/drivers/timer/imx-gpt-timer.c @@ -13,8 +13,29 @@ #include -#define GPT_CR_SWR 0x8000 +#define GPT_CR_SWR 0x8000 +#define GPT_CR_CLKSRC 0x01C0 +#define GPT_CR_EN_24M 0x4000 +#define GPT_CR_EN 0x0001 +#define GPT_PR_PRESCALER 0x0FFF +#define GPT_PR_PRESCALER24M0xF000 + + Please avoid one whiteline +#define NO_CLOCK (0) +#define IPG_CLK(1<<6) +#define IPG_CLK_HF (2<<6) +#define IPG_EXT(3<<6) +#define IPG_CLK_32K(4<<6) +#define IPG_CLK_24M(5<<6) + + ditto +/* +ipg_clk ipg_clk_root Peripheral clock +ipg_clk_32k ckil_sync_clk_root Low-frequency reference clock (32 kHz) +ipg_clk_highfreq perclk_clk_root High-frequency reference clock +ipg_clk_s ipg_clk_root Peripheral access clock +*/ struct imx_gpt_timer_regs { u32 cr; u32 pr; @@ -32,14 +53,12 @@ struct imx_gpt_timer_priv { struct imx_gpt_timer_regs *base; }; -static int imx_gpt_timer_get_count(struct udevice *dev, u64 *count) +static u64 imx_gpt_timer_get_count(struct udevice *dev) { struct imx_gpt_timer_priv *priv = dev_get_priv(dev); struct imx_gpt_timer_regs *regs = priv->base; - *count = readl(>cnt); - - return 0; + return readl(>cnt); } static int imx_gpt_timer_probe(struct udevice *dev) @@ -50,7 +69,7 @@ static int imx_gpt_timer_probe(struct udevice *dev) struct clk clk; fdt_addr_t addr; u32 prescaler; - u32 rate, pr; + u32 rate; int ret; addr = dev_read_addr(dev); @@ -84,16 +103,20 @@ static int imx_gpt_timer_probe(struct udevice *dev) /* Get timer clock rate */ rate = clk_get_rate(); + if((int)rate <= 0){ + debug("Could not get clock rate, setting to default value...\n"); + rate = 105600UL; + } Here I don't agree, having a timer ticking at 1ms(1Khz) doesn't justify having a parent clock of 1Ghz. What I've thought here was using 24M crystal directly. But obviously this is determined by clk_get_rate(). So IMHO I would keep 24M only as source and only if needed I would make it different. Using only that reference you make this driver accepting only a 24M clock, but to begin it's enough for me. Most of i.MX* SoC setup exactly timer using 24M source clock. Also using ipg clock implies that clock drivers supports it, but it doesn't so this driver shouldn't work as is. Best regards -- Giulio Benetti Benetti Engineering sas /* we set timer prescaler to obtain a 1MHz timer counter frequency */ -// pr = (rate / CONFIG_SYS_HZ_CLOCK) - 1; - writel(pr, >pr); - + prescaler = (rate / CONFIG_SYS_HZ_CLOCK) - 1; + writel(GPT_PR_PRESCALER, >pr); /* Set timer frequency to 1MHz */ - uc_priv->clock_rate = rate / prescaler; - + uc_priv->clock_rate = CONFIG_SYS_HZ_CLOCK; + clrbits_le32(>cr,GPT_CR_CLKSRC); + setbits_le32(>cr, IPG_CLK); /* start timer */ -// setbits_le32(>cr1, CR1_CEN); + setbits_le32(>cr, GPT_CR_EN); return 0; } @@ -111,8 +134,7 @@ U_BOOT_DRIVER(imx_gpt_timer) = { .name = "imx_gpt_timer", .id = UCLASS_TIMER, .of_match = imx_gpt_timer_ids, - .priv_auto_alloc_size = sizeof(struct imx_gpt_timer_priv), + .priv_auto = sizeof(struct imx_gpt_timer_priv), .probe = imx_gpt_timer_probe, .ops = _gpt_timer_ops, }; -
Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it
On Monday 08 February 2021 23:21:38 Pali Rohár wrote: > On Monday 08 February 2021 23:15:33 Lukasz Majewski wrote: > > Hi Pali, > > > > > Resended v2 patch series with fixed commit messages > > > > > > This patch series fix usbtty code (serial console via USB peripheral > > > mode), fix underlying musb peripheral code, fix compilation of > > > CONFIG_USB_DEVICE (used by usbtty), remove unused Nokia RX-51 code to > > > decrease size of U-Boot binary and finally enable usbtty serial > > > console for Nokia RX-51. > > > > > > With this patch series debugging of Nokia RX-51 can be done also via > > > USB serial console. > > > > > > It fixes also stability of musb code and allows usage of file > > > transfers via Kermit protocol on Nokia RX-51. Kermit file transfer > > > via U-Boot loadb command is stable on Nokia N900 and gives about > > > 52kB/s transfer rate. > > > > > > On computer this serial console is accessible via /dev/ttyACM0 device. > > > > > > > I've integrated your patchset and now it turns out that the u-boot size > > is too big: > > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=results > > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67=f9a6b761-daa3-500f-4840-65a939c5040d > > Ah :-( > In November when I sent these patches, U-Boot binary was smaller. > > > The branch is https://github.com/lmajewski/u-boot-dfu/tree/testing > > > > Have you experienced similar issues? > > Yes, memory for U-Boot is limited. It is needed to decrease size of > U-Boot binary and then it will work. > > I will try to look at it later and find some dead code which can be > commented or removed to decrease binary size... Just a quick test, could you try to add CONFIG_OPTIMIZE_INLINING=y into configs/nokia_rx51_defconfig file, if it helps? > If you have an idea what increased U-Boot side it could help. > > > > Pali Rohár (16): > > > serial: usbtty: Fix puts function > > > serial: usbtty: Send urb data in correct order > > > usb: musb: Fix compilation of gadget code > > > usb: musb: Always clear the data toggle bit when configuring ep > > > usb: musb: Fix configuring FIFO for endpoints > > > usb: musb: Read value of PERI_RXCSR to 16bit variable > > > usb: musb: Fix transmission of bigger buffers > > > usb: musb: Fix receiving of bigger buffers > > > usb: musb: Fix handling interrupts for EP0 and SET ADDRESS commmand > > > usb: musb: Ensure that we set musb dynamic FIFO buffer for every > > > endpoint > > > usb: gadget: Use dbg_ep0() macro instead of serial_printf() > > > arm: omap3: Compile lowlevel_init() function only when it is used > > > arm: omap3: Compile s_init() function only when it is used > > > Nokia RX-51: Remove function set_muxconf_regs() > > > Nokia RX-51: Move content of rx51.h to rx51.c > > > Nokia RX-51: Enable usbtty serial console by default > > > > > > Makefile | 1 + > > > arch/arm/mach-omap2/omap3/board.c | 3 + > > > arch/arm/mach-omap2/omap3/lowlevel_init.S | 6 +- > > > board/nokia/rx51/rx51.c | 28 +- > > > board/nokia/rx51/rx51.h | 377 > > > -- configs/nokia_rx51_defconfig | > > > 7 +- doc/README.nokia_rx51 | 15 +- > > > drivers/serial/usbtty.c | 16 +- > > > drivers/usb/gadget/ep0.c | 16 +- > > > drivers/usb/musb/musb_core.c | 12 +- > > > drivers/usb/musb/musb_udc.c | 61 ++-- > > > include/configs/nokia_rx51.h | 21 +- > > > 12 files changed, 82 insertions(+), 481 deletions(-) > > > delete mode 100644 board/nokia/rx51/rx51.h > > > > > > > > > > > > > Best regards, > > > > Lukasz Majewski > > > > -- > > > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de > >
Re: [PATCH 1/2] efi: Add ESRT to the EFI system table
On 2/8/21 11:18 PM, Heinrich Schuchardt wrote: On 2/8/21 1:52 PM, Jose Marinho wrote: The ESRT is initialised during efi_init_objlist after efi_initialize_system_table(). The ESRT is initially created with size for 50 FW image entries. The ESRT is resized when it runs out of space. Every resize adds 50 additional entries. The ESRT is populated from information provided by FMP instances only. Signed-off-by: Jose Marinho one limitation is, if any FMP instance is installed and then uninstalled during the same boottime flow, the ESRT entries will not be removed this limitation is because I cannot find a proper UEFI way to hook to a FMP protocol uninstall. register an event with RegisterProtocolNotify(). EFI_CALL(efi_register_protocol_notify(...)) after exporting the function in /include/efi_loader The event can be created with efi_create_event(). RegisterProtocolNotifiy() only tells you that a protocol is newly installed, or reinstalled. If you open the protocol with EFI_OPEN_PROTOCOL_BY_DRIVER, than EFI_BOOT_SERVICES.UninstallProtocolInterface() will call EFI_BOOT_SERVICES.DisconnectController() for the driver which will end up in calling the Stop() function of the driver binding protocol. Instead of using RegisterProtocolNotifiy() it would be better if the FMP driver would call ConnectController() after installing its protocol. This project is gone to show you all delights of EFI driver development. Best regards Heinrich
Re: [PATCH 3/4] imxrt1050 dtsi gpt1 node
Subject should be: ARM: dts: imxrt1050: add gpt1 node Please try to: # git log arch/arm/dts/imxrt1050.dtsi this is to see the form already used to begin commit. In general, try to imitate what others do in commited patches. Best regards -- Giulio Benetti Benetti Engineering sas On 2/8/21 1:24 AM, Jesse Taube wrote: Signed-off-by: Jesse Taube Cc: Stefano Babic Cc: Giulio Benetti Cc: Jesse Taube --- arch/arm/dts/imxrt1050.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/dts/imxrt1050.dtsi b/arch/arm/dts/imxrt1050.dtsi index a9281001e5..47a1d24973 100644 --- a/arch/arm/dts/imxrt1050.dtsi +++ b/arch/arm/dts/imxrt1050.dtsi @@ -154,5 +154,13 @@ clock-names = "per"; status = "disabled"; }; + + gpt1: gpt1@401ec000 { + compatible = "fsl,imxrt-gpt"; + reg = <0x401ec000 0x4000>; + interrupts = <100>; + clocks = < IMXRT1050_CLK_PIT_GPT>; + status = "disabled"; + }; }; };
Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it
On Monday 08 February 2021 23:15:33 Lukasz Majewski wrote: > Hi Pali, > > > Resended v2 patch series with fixed commit messages > > > > This patch series fix usbtty code (serial console via USB peripheral > > mode), fix underlying musb peripheral code, fix compilation of > > CONFIG_USB_DEVICE (used by usbtty), remove unused Nokia RX-51 code to > > decrease size of U-Boot binary and finally enable usbtty serial > > console for Nokia RX-51. > > > > With this patch series debugging of Nokia RX-51 can be done also via > > USB serial console. > > > > It fixes also stability of musb code and allows usage of file > > transfers via Kermit protocol on Nokia RX-51. Kermit file transfer > > via U-Boot loadb command is stable on Nokia N900 and gives about > > 52kB/s transfer rate. > > > > On computer this serial console is accessible via /dev/ttyACM0 device. > > > > I've integrated your patchset and now it turns out that the u-boot size > is too big: > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=results > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67=f9a6b761-daa3-500f-4840-65a939c5040d Ah :-( In November when I sent these patches, U-Boot binary was smaller. > The branch is https://github.com/lmajewski/u-boot-dfu/tree/testing > > Have you experienced similar issues? Yes, memory for U-Boot is limited. It is needed to decrease size of U-Boot binary and then it will work. I will try to look at it later and find some dead code which can be commented or removed to decrease binary size... If you have an idea what increased U-Boot side it could help. > > Pali Rohár (16): > > serial: usbtty: Fix puts function > > serial: usbtty: Send urb data in correct order > > usb: musb: Fix compilation of gadget code > > usb: musb: Always clear the data toggle bit when configuring ep > > usb: musb: Fix configuring FIFO for endpoints > > usb: musb: Read value of PERI_RXCSR to 16bit variable > > usb: musb: Fix transmission of bigger buffers > > usb: musb: Fix receiving of bigger buffers > > usb: musb: Fix handling interrupts for EP0 and SET ADDRESS commmand > > usb: musb: Ensure that we set musb dynamic FIFO buffer for every > > endpoint > > usb: gadget: Use dbg_ep0() macro instead of serial_printf() > > arm: omap3: Compile lowlevel_init() function only when it is used > > arm: omap3: Compile s_init() function only when it is used > > Nokia RX-51: Remove function set_muxconf_regs() > > Nokia RX-51: Move content of rx51.h to rx51.c > > Nokia RX-51: Enable usbtty serial console by default > > > > Makefile | 1 + > > arch/arm/mach-omap2/omap3/board.c | 3 + > > arch/arm/mach-omap2/omap3/lowlevel_init.S | 6 +- > > board/nokia/rx51/rx51.c | 28 +- > > board/nokia/rx51/rx51.h | 377 > > -- configs/nokia_rx51_defconfig | > > 7 +- doc/README.nokia_rx51 | 15 +- > > drivers/serial/usbtty.c | 16 +- > > drivers/usb/gadget/ep0.c | 16 +- > > drivers/usb/musb/musb_core.c | 12 +- > > drivers/usb/musb/musb_udc.c | 61 ++-- > > include/configs/nokia_rx51.h | 21 +- > > 12 files changed, 82 insertions(+), 481 deletions(-) > > delete mode 100644 board/nokia/rx51/rx51.h > > > > > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
Re: [PATCH 1/4] timer: imx-gpt: Add timer support for i.MX SoCs family
Hi Jesse, On 2/8/21 1:24 AM, Jesse Taube wrote: This timer driver is using GPT Timer (General Purpose Timer) available on almost all i.MX SoCs family. Signed-off-by: Giulio Benetti Cc: Stefano Babic Cc: Giulio Benetti Cc: Jesse Taube All these ^^^ Cc in commit log are useless in this case, they are useful only in the case people are not listed when calling get_maintainers.pl or because you specifically need them to be in Cc. Your name/e-mail should be present as SoB and not as Cc because you're sending the patch, so add Signed-off-by instead of Cc for you entry and in case you did some modification write it like: Signed-off-by: Giulio Benetti Signed-off-by: Jesse Taube [Jesse: changed this, set this to etc.] This way authorship is kept, but you write what you have done on this patch. --- drivers/timer/Kconfig | 7 ++ drivers/timer/Makefile| 1 + drivers/timer/imx-gpt-timer.c | 118 ++ 3 files changed, 126 insertions(+) create mode 100644 drivers/timer/imx-gpt-timer.c diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig index 80743a2551..ee81dfa776 100644 --- a/drivers/timer/Kconfig +++ b/drivers/timer/Kconfig @@ -227,4 +227,11 @@ config MCHP_PIT64B_TIMER Select this to enable support for Microchip 64-bit periodic interval timer. +config IMX_GPT_TIMER + bool "NXP i.MX GPT timer support" + depends on TIMER + help + Select this to enable support for the timer found on + NXP i.MX devices. + endmenu diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile index eb5c48cc6c..e214ba7268 100644 --- a/drivers/timer/Makefile +++ b/drivers/timer/Makefile @@ -25,3 +25,4 @@ obj-$(CONFIG_STM32_TIMER) += stm32_timer.o obj-$(CONFIG_X86_TSC_TIMER) += tsc_timer.o obj-$(CONFIG_MTK_TIMER) += mtk_timer.o obj-$(CONFIG_MCHP_PIT64B_TIMER) += mchp-pit64b-timer.o +obj-$(CONFIG_IMX_GPT_TIMER)+= imx-gpt-timer.o diff --git a/drivers/timer/imx-gpt-timer.c b/drivers/timer/imx-gpt-timer.c new file mode 100644 index 00..c4e8c12a42 --- /dev/null +++ b/drivers/timer/imx-gpt-timer.c @@ -0,0 +1,118 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2020 + * Author(s): Giulio Benetti + */ + +#include +#include +#include +#include +#include +#include + +#include + +#define GPT_CR_SWR 0x8000 + +struct imx_gpt_timer_regs { + u32 cr; + u32 pr; + u32 sr; + u32 ir; + u32 ocr1; + u32 ocr2; + u32 ocr3; + u32 icr1; + u32 icr2; + u32 cnt; +}; + +struct imx_gpt_timer_priv { + struct imx_gpt_timer_regs *base; +}; + +static int imx_gpt_timer_get_count(struct udevice *dev, u64 *count) +{ + struct imx_gpt_timer_priv *priv = dev_get_priv(dev); + struct imx_gpt_timer_regs *regs = priv->base; + + *count = readl(>cnt); + + return 0; +} + +static int imx_gpt_timer_probe(struct udevice *dev) +{ + struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev); + struct imx_gpt_timer_priv *priv = dev_get_priv(dev); + struct imx_gpt_timer_regs *regs; + struct clk clk; + fdt_addr_t addr; + u32 prescaler; + u32 rate, pr; + int ret; + + addr = dev_read_addr(dev); + if (addr == FDT_ADDR_T_NONE) + return -EINVAL; + + priv->base = (struct imx_gpt_timer_regs *)addr; + + /* TODO: Retrieve clock-source */ This is something that prevents driver from working so a patch like this should not be accepted. + + /* TODO: Retrieve prescaler */ ditto + + ret = clk_get_by_index(dev, 0, ); + if (ret < 0) + return ret; + + ret = clk_enable(); + if (ret) { + dev_err(dev, "failed to enable clock\n"); + return ret; + } + + regs = priv->base; + + /* Reset the timer */ + setbits_le32(>cr, GPT_CR_SWR); + + /* Wait for timer to finish reset */ + while(readl(>cr) & GPT_CR_SWR) + ; + + /* Get timer clock rate */ + rate = clk_get_rate(); + + /* we set timer prescaler to obtain a 1MHz timer counter frequency */ +// pr = (rate / CONFIG_SYS_HZ_CLOCK) - 1; This ^^^ was another TODO: I've put there, ditto. Also take care to never leave commented code. + writel(pr, >pr); + + /* Set timer frequency to 1MHz */ + uc_priv->clock_rate = rate / prescaler; + + /* start timer */ +// setbits_le32(>cr1, CR1_CEN); ditto + + return 0; +} + +static const struct timer_ops imx_gpt_timer_ops = { + .get_count = imx_gpt_timer_get_count, +}; + +static const struct udevice_id imx_gpt_timer_ids[] = { + { .compatible = "fsl,imxrt-gpt" }, + {} +}; + +U_BOOT_DRIVER(imx_gpt_timer) = { + .name = "imx_gpt_timer", + .id = UCLASS_TIMER, + .of_match = imx_gpt_timer_ids, + .priv_auto_alloc_size = sizeof(struct
Re: [PATCH 1/2] efi: Add ESRT to the EFI system table
On 2/8/21 1:52 PM, Jose Marinho wrote: The ESRT is initialised during efi_init_objlist after efi_initialize_system_table(). The ESRT is initially created with size for 50 FW image entries. The ESRT is resized when it runs out of space. Every resize adds 50 additional entries. The ESRT is populated from information provided by FMP instances only. Signed-off-by: Jose Marinho one limitation is, if any FMP instance is installed and then uninstalled during the same boottime flow, the ESRT entries will not be removed this limitation is because I cannot find a proper UEFI way to hook to a FMP protocol uninstall. register an event with RegisterProtocolNotify(). EFI_CALL(efi_register_protocol_notify(...)) after exporting the function in /include/efi_loader The event can be created with efi_create_event().
Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it
Hi Pali, > Resended v2 patch series with fixed commit messages > > This patch series fix usbtty code (serial console via USB peripheral > mode), fix underlying musb peripheral code, fix compilation of > CONFIG_USB_DEVICE (used by usbtty), remove unused Nokia RX-51 code to > decrease size of U-Boot binary and finally enable usbtty serial > console for Nokia RX-51. > > With this patch series debugging of Nokia RX-51 can be done also via > USB serial console. > > It fixes also stability of musb code and allows usage of file > transfers via Kermit protocol on Nokia RX-51. Kermit file transfer > via U-Boot loadb command is stable on Nokia N900 and gives about > 52kB/s transfer rate. > > On computer this serial console is accessible via /dev/ttyACM0 device. > I've integrated your patchset and now it turns out that the u-boot size is too big: https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=results https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67=f9a6b761-daa3-500f-4840-65a939c5040d The branch is https://github.com/lmajewski/u-boot-dfu/tree/testing Have you experienced similar issues? > Pali Rohár (16): > serial: usbtty: Fix puts function > serial: usbtty: Send urb data in correct order > usb: musb: Fix compilation of gadget code > usb: musb: Always clear the data toggle bit when configuring ep > usb: musb: Fix configuring FIFO for endpoints > usb: musb: Read value of PERI_RXCSR to 16bit variable > usb: musb: Fix transmission of bigger buffers > usb: musb: Fix receiving of bigger buffers > usb: musb: Fix handling interrupts for EP0 and SET ADDRESS commmand > usb: musb: Ensure that we set musb dynamic FIFO buffer for every > endpoint > usb: gadget: Use dbg_ep0() macro instead of serial_printf() > arm: omap3: Compile lowlevel_init() function only when it is used > arm: omap3: Compile s_init() function only when it is used > Nokia RX-51: Remove function set_muxconf_regs() > Nokia RX-51: Move content of rx51.h to rx51.c > Nokia RX-51: Enable usbtty serial console by default > > Makefile | 1 + > arch/arm/mach-omap2/omap3/board.c | 3 + > arch/arm/mach-omap2/omap3/lowlevel_init.S | 6 +- > board/nokia/rx51/rx51.c | 28 +- > board/nokia/rx51/rx51.h | 377 > -- configs/nokia_rx51_defconfig | > 7 +- doc/README.nokia_rx51 | 15 +- > drivers/serial/usbtty.c | 16 +- > drivers/usb/gadget/ep0.c | 16 +- > drivers/usb/musb/musb_core.c | 12 +- > drivers/usb/musb/musb_udc.c | 61 ++-- > include/configs/nokia_rx51.h | 21 +- > 12 files changed, 82 insertions(+), 481 deletions(-) > delete mode 100644 board/nokia/rx51/rx51.h > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpfOBJ3SyXsQ.pgp Description: OpenPGP digital signature
Re: [PATCH 0/3] timer: imx-gpt: Add timer support for i.MX SoCs family
Hi Jesse, first of all thank you for helping me with this porting :-) On 2/8/21 1:24 AM, Jesse Taube wrote: Add basic driver support for the IMX General Purpose Timer (GPT) available on almost all i.MX SoCs family. Giulio Benetti (3): timer: imx-gpt: Add timer support for i.MX SoCs family dt-bindings: clock: imxrt1050: add PIT GPT clock imxrt1050 dtsi gpt1 node Jesse Taube (1): timer: imx-gpt: Add basic timer support for i.MX SoCs family Cover letter subject indicates [PATCH 0/3] as you're sending cover letter plus 3 patches but actually you're sending 4. You should retry to: # git format-patch -s -M -o outgoing -4 --cover-letter and then: # cd outgoing edit cover-letter(patch-) # cd .. # ./scripts/get_maintainers.pl outgoing/* # git send-mail --to "..." --cc "u-boot..." outgoing/*.patch This way works, obviously you have to substitute "Names " on --to --cc Best regards -- Giulio Benetti Benetti Engineering sas
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
On 2/8/21 6:56 PM, Heinrich Schuchardt wrote: On 2/8/21 6:08 PM, Simon Glass wrote: HI Marek, On Mon, 8 Feb 2021 at 09:10, Marek Szyprowski wrote: Hi Simon, On 06.02.2021 17:21, Simon Glass wrote: On Thu, 4 Feb 2021 at 03:36, Marek Szyprowski wrote: ... Could you give me a bit more hints or point where to start? I've tried to build sandbox, but it fails for v2021.01 release (I've did make sandbox_defconfig && make all). I assume I would need to add adc and adc-keys devices to some sandbox dts and some code triggering and checking the key values, but that's all I know now. Well you do need to be able to build sandbox or you will get nowhere...what error did you get? Once we understand what went wrong we can update the docs. Maybe it is missing a dependency. $ gcc --version gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ git checkout v2021.01 $ make sandbox_defconfig # # configuration written to .config # $ make scripts/kconfig/conf --syncconfig Kconfig CFG u-boot.cfg GEN include/autoconf.mk GEN include/autoconf.mk.dep CFGCHK u-boot.cfg UPD include/generated/timestamp_autogenerated.h HOSTCC tools/mkenvimage.o HOSTLD tools/mkenvimage HOSTCC tools/fit_image.o HOSTCC tools/image-host.o HOSTCC tools/dumpimage.o HOSTLD tools/dumpimage HOSTCC tools/mkimage.o HOSTLD tools/mkimage HOSTLD tools/fit_info HOSTLD tools/fit_check_sign ... CC arch/sandbox/cpu/cpu.o In file included from include/common.h:26:0, from arch/sandbox/cpu/cpu.c:6: include/asm/global_data.h:112:58: warning: call-clobbered register used for global register variable #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r9") ^ include/dm/of.h:86:1: note: in expansion of macro ‘DECLARE_GLOBAL_DATA_PTR’ DECLARE_GLOBAL_DATA_PTR; This is pretty mysterious. Are you sure you are using an x86_64 machine? r9 relates to ARMv7. You have to unset CROSS_COMPILE when you build the sandbox. The sandbox runs fine on aarch64. There are a bunch of errors currently when building on 32bit architectures. Simon has a lot of patches pending. Hello Simon, it was your patch 091401131085 ("command: Remove the cmd_tbl_t typedef") 2020-05-10 that broke building the sandbox on ARMv7. Once your 32bit corrections are merged we should try to add cross-compiling the sandbox for aarch64 and armv7 to Gitlab CI. Best regards Heinrich
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
Stefan, these patches should probably have a different From: - i.e. the original authors should be preserved (from the first Signed-off-by tags), for example: motib Baruch Siach heaterC But some of these are not full names, so I don't know whether I should resend this or not. What do you think? Marek
[PATCH 1/1] sandbox: allow cross-compiling sandbox
UEFI test files like helloworld.efi require an architecture specific PE-COFF header. For non-sandbox the PE-COFF header is chosen by the target architecture. For the sandbox we use the host architecture. This is not helpful for cross compiling. Allow specifying the target architecture of the sandbox via environment variable MK_ARCH, e.g. make sandbox_defconfig NO_SDL=1 CROSS_COMPILE=aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make Signed-off-by: Heinrich Schuchardt --- Makefile | 2 +- doc/arch/sandbox.rst | 14 ++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 23dd11f723..286e5148ae 100644 --- a/Makefile +++ b/Makefile @@ -19,7 +19,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR) # Determine host architecture include include/host_arch.h -MK_ARCH="${shell uname -m}" +MK_ARCH?="${shell uname -m}" unexport HOST_ARCH ifeq ("x86_64", $(MK_ARCH)) export HOST_ARCH=$(HOST_ARCH_X86_64) diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst index 60ee1e0741..0dd9edc8cb 100644 --- a/doc/arch/sandbox.rst +++ b/doc/arch/sandbox.rst @@ -33,6 +33,20 @@ integers can only be built on 64-bit hosts. Note that standalone/API support is not available at present. +Cross compiling +--- + +When cross compiling the U-Boot sandbox with CONFIG_EFI_LOADER=y the target +architecture must be specified using the MK_ARCH environment variable using one +of the values aarch64, armv7l, i386, riscv32, riscv64, x86_64, e.g. + +.. code-block:: bash + +NO_SDL=1 make sandbox_defconfig +CROSS_COMPILE=aarch64-linux-gnu- MK_ARCH=aarch64 NO_SDL=1 make + +NO_SDL=1 was chosen in the example to remove the dependency on the SDL library. +The graphical console will not be available. Prerequisites - -- 2.30.0
Re: [PATCH 3/4] arm: mvebu: turris_mox: Enable CONFIG_USB_XHCI_PCI
Reviewed-by: Marek Behún
Re: [PATCH 4/4] arm: mvebu: turris_mox: Enable NVMe support
Reviewed-by: Marek Behún
Re: [PATCH 2/4] arm: mvebu: turris_mox: Enable CONFIG_PCI_PNP
Reviewed-by: Marek Behún
Re: [PATCH 1/4] arm: a37xx: pci: Set Max Payload Size and Max Read Request Size to 512 bytes
Reviewed-by: Marek Behún
[PATCH u-boot-marvell 4/5] pci: pci_mvebu: refactor validation of addresses for config access
Refactor validation of bdf parameter in mvebu_pcie_read/write_config functions. We can simplify the code by putting the validation into separate function. Also there are always only two devices visible on local bus: * on slot configured by function mvebu_pcie_set_local_dev_nr() (by default this register is set to 0) there is a "Marvell Memory controller", which isn't useful in root complex mode, * on all other slots the real PCIe card connected to the PCIe slot. We can simplify the code even more by simply allowing access only to the real PCIe card. Signed-off-by: Marek Behún Cc: Stefan Roese Cc: Phil Sutter Cc: Mario Six Cc: Baruch Siach --- drivers/pci/pci_mvebu.c | 59 ++--- 1 file changed, 31 insertions(+), 28 deletions(-) diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c index 4ad73512a6..2d923b7d8d 100644 --- a/drivers/pci/pci_mvebu.c +++ b/drivers/pci/pci_mvebu.c @@ -78,7 +78,8 @@ struct mvebu_pcie { u32 lane; int devfn; u32 lane_mask; - pci_dev_t dev; + int first_busno; + int local_dev; char name[16]; unsigned int mem_target; unsigned int mem_attr; @@ -143,27 +144,36 @@ static inline struct mvebu_pcie *hose_to_pcie(struct pci_controller *hose) return container_of(hose, struct mvebu_pcie, hose); } +static int mvebu_pcie_valid_addr(struct mvebu_pcie *pcie, pci_dev_t bdf) +{ + /* +* There are two devices visible on local bus: +* * on slot configured by function mvebu_pcie_set_local_dev_nr() +* (by default this register is set to 0) there is a +* "Marvell Memory controller", which isn't useful in root complex +* mode, +* * on all other slots the real PCIe card connected to the PCIe slot. +* +* We therefore allow access only to the real PCIe card. +*/ + if (PCI_BUS(bdf) == pcie->first_busno && + PCI_DEV(bdf) != !pcie->local_dev) + return 0; + + return 1; +} + static int mvebu_pcie_read_config(const struct udevice *bus, pci_dev_t bdf, uint offset, ulong *valuep, enum pci_size_t size) { struct mvebu_pcie *pcie = dev_get_plat(bus); - int local_bus = PCI_BUS(pcie->dev); - int local_dev = PCI_DEV(pcie->dev); u32 data; - debug("PCIE CFG read: loc_bus=%d loc_dev=%d (b,d,f)=(%2d,%2d,%2d) ", - local_bus, local_dev, PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf)); + debug("PCIE CFG read: (b,d,f)=(%2d,%2d,%2d) ", + PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf)); - /* Don't access the local host controller via this API */ - if (PCI_BUS(bdf) == local_bus && PCI_DEV(bdf) == local_dev) { - debug("- skipping host controller\n"); - *valuep = pci_get_ff(size); - return 0; - } - - /* If local dev is 0, the first other dev can only be 1 */ - if (PCI_BUS(bdf) == local_bus && local_dev == 0 && PCI_DEV(bdf) != 1) { + if (!mvebu_pcie_valid_addr(pcie, bdf)) { debug("- out of range\n"); *valuep = pci_get_ff(size); return 0; @@ -185,22 +195,13 @@ static int mvebu_pcie_write_config(struct udevice *bus, pci_dev_t bdf, enum pci_size_t size) { struct mvebu_pcie *pcie = dev_get_plat(bus); - int local_bus = PCI_BUS(pcie->dev); - int local_dev = PCI_DEV(pcie->dev); u32 data; - debug("PCIE CFG write: loc_bus=%d loc_dev=%d (b,d,f)=(%2d,%2d,%2d) ", - local_bus, local_dev, PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf)); + debug("PCIE CFG write: (b,d,f)=(%2d,%2d,%2d) ", + PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf)); debug("(addr,size,val)=(0x%04x, %d, 0x%08lx)\n", offset, size, value); - /* Don't access the local host controller via this API */ - if (PCI_BUS(bdf) == local_bus && PCI_DEV(bdf) == local_dev) { - debug("- skipping host controller\n"); - return 0; - } - - /* If local dev is 0, the first other dev can only be 1 */ - if (PCI_BUS(bdf) == local_bus && local_dev == 0 && PCI_DEV(bdf) != 1) { + if (!mvebu_pcie_valid_addr(pcie, bdf)) { debug("- out of range\n"); return 0; } @@ -286,9 +287,11 @@ static int mvebu_pcie_probe(struct udevice *dev) readl(pcie->base), mvebu_pcie_get_local_bus_nr(pcie), mvebu_pcie_get_local_dev_nr(pcie)); + pcie->first_busno = bus; + pcie->local_dev = 0; + mvebu_pcie_set_local_bus_nr(pcie, bus); - mvebu_pcie_set_local_dev_nr(pcie, 0); - pcie->dev = PCI_BDF(bus, 0, 0); + mvebu_pcie_set_local_dev_nr(pcie, pcie->local_dev); pcie->mem.start = (u32)mvebu_pcie_membase; pcie->mem.end = pcie->mem.start +
[PATCH u-boot-marvell 3/5] pci: pci_mvebu: debug rd/wr config as other drivers do
Other drivers (aardvark, intel_fpga) print "(addr,size,val)" when debugging is enabled. Print size for pci_mvebu as well. Signed-off-by: Marek Behún Cc: Stefan Roese Cc: Phil Sutter Cc: Mario Six Cc: Baruch Siach --- drivers/pci/pci_mvebu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c index abc6e9e6e0..4ad73512a6 100644 --- a/drivers/pci/pci_mvebu.c +++ b/drivers/pci/pci_mvebu.c @@ -174,7 +174,7 @@ static int mvebu_pcie_read_config(const struct udevice *bus, pci_dev_t bdf, /* read data */ data = readl(pcie->base + PCIE_CONF_DATA_OFF); - debug("(addr,val)=(0x%04x, 0x%08x)\n", offset, data); + debug("(addr,size,val)=(0x%04x, %d, 0x%08x)\n", offset, size, data); *valuep = pci_conv_32_to_size(data, offset, size); return 0; @@ -191,7 +191,7 @@ static int mvebu_pcie_write_config(struct udevice *bus, pci_dev_t bdf, debug("PCIE CFG write: loc_bus=%d loc_dev=%d (b,d,f)=(%2d,%2d,%2d) ", local_bus, local_dev, PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf)); - debug("(addr,val)=(0x%04x, 0x%08lx)\n", offset, value); + debug("(addr,size,val)=(0x%04x, %d, 0x%08lx)\n", offset, size, value); /* Don't access the local host controller via this API */ if (PCI_BUS(bdf) == local_bus && PCI_DEV(bdf) == local_dev) { -- 2.26.2
[PATCH u-boot-marvell 2/5] pci: pci_mvebu: cosmetic fix
Write bdf address in a same way in mvebu_pcie_read/write_config. Signed-off-by: Marek Behún Cc: Stefan Roese Cc: Phil Sutter Cc: Mario Six Cc: Baruch Siach --- drivers/pci/pci_mvebu.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c index 5c55a76d0e..abc6e9e6e0 100644 --- a/drivers/pci/pci_mvebu.c +++ b/drivers/pci/pci_mvebu.c @@ -150,7 +150,6 @@ static int mvebu_pcie_read_config(const struct udevice *bus, pci_dev_t bdf, struct mvebu_pcie *pcie = dev_get_plat(bus); int local_bus = PCI_BUS(pcie->dev); int local_dev = PCI_DEV(pcie->dev); - u32 reg; u32 data; debug("PCIE CFG read: loc_bus=%d loc_dev=%d (b,d,f)=(%2d,%2d,%2d) ", @@ -171,8 +170,9 @@ static int mvebu_pcie_read_config(const struct udevice *bus, pci_dev_t bdf, } /* write address */ - reg = PCIE_CONF_ADDR(bdf, offset); - writel(reg, pcie->base + PCIE_CONF_ADDR_OFF); + writel(PCIE_CONF_ADDR(bdf, offset), pcie->base + PCIE_CONF_ADDR_OFF); + + /* read data */ data = readl(pcie->base + PCIE_CONF_DATA_OFF); debug("(addr,val)=(0x%04x, 0x%08x)\n", offset, data); *valuep = pci_conv_32_to_size(data, offset, size); @@ -205,7 +205,10 @@ static int mvebu_pcie_write_config(struct udevice *bus, pci_dev_t bdf, return 0; } + /* write address */ writel(PCIE_CONF_ADDR(bdf, offset), pcie->base + PCIE_CONF_ADDR_OFF); + + /* write data */ data = pci_conv_size_to_32(0, value, offset, size); writel(data, pcie->base + PCIE_CONF_DATA_OFF); -- 2.26.2
[PATCH u-boot-marvell 5/5] pci: pci_mvebu: set local dev to number 1
Linux displays the real PCIe card connected to a mvebu PCIe slot as device 0, not 1. This is done by setting local dev number to 1, so that the local "Marvell Memory controller" device is on address 1. Let's do it also in U-Boot. With this commit the pci command in U-Boot prints something like: => pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x168c 0x003c Network controller 0x80 Signed-off-by: Marek Behún Cc: Stefan Roese Cc: Phil Sutter Cc: Mario Six Cc: Baruch Siach --- drivers/pci/pci_mvebu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c index 2d923b7d8d..11b590617d 100644 --- a/drivers/pci/pci_mvebu.c +++ b/drivers/pci/pci_mvebu.c @@ -288,7 +288,7 @@ static int mvebu_pcie_probe(struct udevice *dev) mvebu_pcie_get_local_dev_nr(pcie)); pcie->first_busno = bus; - pcie->local_dev = 0; + pcie->local_dev = 1; mvebu_pcie_set_local_bus_nr(pcie, bus); mvebu_pcie_set_local_dev_nr(pcie, pcie->local_dev); -- 2.26.2
[PATCH u-boot-marvell 1/5] pci: pci_mvebu: use dev_seq instead of static variable
PCI uclass maps PCI bus numbers to the seq member of struct udevice. Use dev_seq(dev) as the bus number in mvebu_pcie_probe instead of an incrementing a static variable. Signed-off-by: Marek Behún Cc: Stefan Roese Cc: Phil Sutter Cc: Mario Six Cc: Baruch Siach --- drivers/pci/pci_mvebu.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c index 3ab03e3675..5c55a76d0e 100644 --- a/drivers/pci/pci_mvebu.c +++ b/drivers/pci/pci_mvebu.c @@ -272,7 +272,7 @@ static int mvebu_pcie_probe(struct udevice *dev) struct mvebu_pcie *pcie = dev_get_plat(dev); struct udevice *ctlr = pci_get_controller(dev); struct pci_controller *hose = dev_get_uclass_priv(ctlr); - static int bus; + int bus = dev_seq(dev); u32 reg; debug("%s: PCIe %d.%d - up, base %08x\n", __func__, @@ -335,8 +335,6 @@ static int mvebu_pcie_probe(struct udevice *dev) writel(SOC_REGS_PHY_BASE, pcie->base + PCIE_BAR_LO_OFF(0)); writel(0, pcie->base + PCIE_BAR_HI_OFF(0)); - bus++; - return 0; } -- 2.26.2
[PATCH u-boot-marvell 0/5] pci_mvebu changes
Hi Stefan, this patchset continues to address the issue you tried to solve with commit "pci: pci_mvebu: Disable config access to PCI host bridge ports". Some code refactoring is done here so that the code looks more sane and the underlying information is documenter. The last patch changes the local device (which presents itself as a "Memory controller" to device number 1, so that the pci command in U-Boot lists the real PCIe card as device 0, as Linux does. Marek Marek Behún (5): pci: pci_mvebu: use dev_seq instead of static variable pci: pci_mvebu: cosmetic fix pci: pci_mvebu: debug rd/wr config as other drivers do pci: pci_mvebu: refactor validation of addresses for config access pci: pci_mvebu: set local dev to number 1 drivers/pci/pci_mvebu.c | 76 ++--- 1 file changed, 40 insertions(+), 36 deletions(-) -- 2.26.2
Re: [PATCH 3/5] arm: stm32mp: Implement support for TZC 400 controller
On 2/7/21 8:37 AM, Simon Glass wrote: Hi Alexandru, On Thu, 4 Feb 2021 at 12:56, Alexandru Gagniuc wrote: The purpose of this change is to allow configuring TrustZone (TZC) memory permissions. For example, OP-TEE expects TZC regions to be configured in a very particular way. The API presented here is intended to allow exactly that. UCLASS support is not implemented, because it would not be too useful. Changing TZC permissions needs to be done with care, so as not to cut off access to memory we are currently using. One place where we can use this is at the end of SPL, right before jumping to OP-TEE. Signed-off-by: Alexandru Gagniuc --- arch/arm/mach-stm32mp/Makefile | 1 + arch/arm/mach-stm32mp/include/mach/tzc.h | 33 ++ arch/arm/mach-stm32mp/tzc400.c | 135 +++ 3 files changed, 169 insertions(+) create mode 100644 arch/arm/mach-stm32mp/include/mach/tzc.h create mode 100644 arch/arm/mach-stm32mp/tzc400.c If this is an API you should add comments to the header file structs and functions. Is this API specific to just this chip? I've designed and validated this to set up stm32mp for starting up OP-TEE. It's a narrow use case. I can't speak for other chips. Alex
Re: Please pull u-boot-marvell/master
On Mon, Feb 08, 2021 at 12:41:45PM +0100, Stefan Roese wrote: > Hi Tom, > > please pull the 2nd batch of Marvell MVEBU related patches. Here the > summary log: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: pull request of u-boot-fsl-qoriq for v2021.04
On Mon, Feb 08, 2021 at 11:10:09AM +, Priyanka Jain wrote: > Dear Tom, > > Please find my pull-request for u-boot-fsl-qoriq/master > https://github.com/u-boot/u-boot/pull/52/checks > > Summary > Layerscape: Enable gpio > Bug fixes & updates related to dspi, qspi, pciep, SVR mask, > stream-id, env variables, mdio for LAyerscape Platforms > Add SATA, network variant 1, 2 support on sl28 > powerpc: T1042: drop CONFIG_VIDEO, Add kmcent2 board supporrt, keymile > Bug fixes and updates for keymile, Kontron > > Thanks > Priyanka Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/master
On Sun, Feb 07, 2021 at 09:41:32PM +0100, Marek Vasut wrote: > The following changes since commit 3936fd998668846f77468d8f6a662e906920969c: > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86 (2021-02-06 > 09:45:58 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 0099dfd5e53703ff94677ec3490134ae436fc8f1: > > ARM: rmobile: Add Beacon EmbeddedWorks RZG2H Dev Kit (2021-02-07 21:12:57 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/master
On Sun, Feb 07, 2021 at 09:10:43PM +0100, Marek Vasut wrote: > The following changes since commit 8308a28af821d6498186b3dd7463db9874cd2daf: > > Merge tag 'ti-v2021.04-rc2' of > https://gitlab.denx.de/u-boot/custodians/u-boot-ti (2021-02-05 09:39:31 > -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to adb5daf0905a190375e46d59f1244b13c3cdc640: > > fastboot: reinit partition after storing GPT or MBR (2021-02-07 19:22:55 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
On Mon, 8 Feb 2021 20:14:26 + Chris Packham wrote: > On 9/02/21 8:15 am, Marek Behun wrote: > > This patch is needed on some Turris Omnia boards with Samsung DDR chips, > > otherwise DDR training fails in ~60% of cases. > > > > Marvell send us this patch for testing, I have updated it a little. > > > > Please test this on other A38x boards. > > > > If it doesn't break anything on other boards, we can apply it and send > > it to mv-ddr-marvell upstream. > They gave us the same patch. I was hoping their SoC team would get it > into mv-ddr-marvell (or even their vendor USP) but obviously they're > still sitting on it. I know it improved matters for some of our boards > but it didn't totally fix them we still had yield problems when we > ramped up production. There is a bug in the version they sent us: in file ddr3_training_ip_engine.c there is a line added: if ((bit_bit_mask[sybphy_id] & (1 << bit_id)) == 1) try chaning it to if (bit_bit_mask[sybphy_id] & (1 << bit_id)) This is fixed in the version I sent to mailing list
Re: [PATCH 2/3] cmd: SCP03: enable and provision command
On 08/02/21, Simon Glass wrote: > Hi Jorge, > > On Sun, 7 Feb 2021 at 11:11, Jorge Ramirez-Ortiz, Foundries > wrote: > > > > On 07/02/21, Simon Glass wrote: > > > Hi Jorge, > > > > > > On Sat, 6 Feb 2021 at 16:05, Jorge Ramirez-Ortiz > > > wrote: > > > > > > > > Enable and provision the SCP03 keys on a TEE controlled secured elemt > > > > from the U-Boot shell. > > > > > > > > Signed-off-by: Jorge Ramirez-Ortiz > > > > --- > > > > cmd/Kconfig | 9 > > > > cmd/Makefile | 3 +++ > > > > cmd/scp03.c | 64 > > > > 3 files changed, 76 insertions(+) > > > > create mode 100644 cmd/scp03.c > > > > > > Can we have a test for this please? See mem_search.c for an example. > > > > you mean other than what I posted already (the sandbox test using the > > TEE emulator)? > > > > I am not really sure what else can it do: this command sends a request > > to a TEE and waits to a response (and both are emulated on the sandbox). > > It should just be a few lines of code to test the basics. E.g.: > > https://github.com/u-boot/u-boot/blob/3936fd998668846f77468d8f6a662e906920969c/test/cmd/test_echo.c#L42 ah ok I see what you mean. I'll have a look > > Regards, > Simon
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
On Mon, 8 Feb 2021 20:11:06 + Chris Packham wrote: > Hi Marek, > > Do you have this in a repo I can pull from? I've got a couple of boards > I can give this a spin on. https://gitlab.nic.cz/turris/turris-omnia-uboot/ branch v2021.04-rc-mv-ddr-14.0.0 also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that one contains one more commit that is needed for Omnia with Samsung DDR chips. Marek
Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
On 9/02/21 8:15 am, Marek Behun wrote: > This patch is needed on some Turris Omnia boards with Samsung DDR chips, > otherwise DDR training fails in ~60% of cases. > > Marvell send us this patch for testing, I have updated it a little. > > Please test this on other A38x boards. > > If it doesn't break anything on other boards, we can apply it and send > it to mv-ddr-marvell upstream. They gave us the same patch. I was hoping their SoC team would get it into mv-ddr-marvell (or even their vendor USP) but obviously they're still sitting on it. I know it improved matters for some of our boards but it didn't totally fix them we still had yield problems when we ramped up production.
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
Hi Marek, On 9/02/21 7:34 am, Marek Behún wrote: > This syncs drivers/ddr/marvell/a38x/ with the mv-ddr-devel branch > of https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git. > > There are some commits regarding DDR3 on top of version 14.0.0 in the > mv-ddr-marvell repository (from Chris Packham), but these changes > already are in U-Boot. Do you have this in a repo I can pull from? I've got a couple of boards I can give this a spin on. > Marek > > Marek Behún (18): >ddr: marvell: a38x: fix write leveling suplementary algo >ddr: marvell: a38x: import header change from upstream >ddr: marvell: a38x: add ddr32 support >ddr: marvell: a38x: add ddr 32bit ECC support >ddr: marvell: a38x: import header change from upstream >ddr: marvell: a38x: fix 32bit >ddr: marvell: a38x: fix memory size calculation using 32bit bus width >ddr: marvell: a38x: import header change from upstream >ddr: marvell: a38x: allow board specific ODT configuration >ddr: marvell: a38x: add 16Gbit memory devices support >ddr: marvell: a38x: add support for twin-die combined memory device >ddr: marvell: a38x: disable WL phase correction stage in case of > bus_width=16bit >ddr: marvell: a38x: import header change from upstream >ddr: marvell: a38x: fix memory cs size function >ddr: marvell: a38x: import code change from upstream >ddr: marvell: a38x: enum mv_ddr_twin_die: change order >ddr: marvell: a38x: bump version to 14.0.0 >ddr: marvell: a38x: fix comment in conditional macro > > board/CZ.NIC/turris_omnia/turris_omnia.c | 2 ++ > board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 1 + > board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 1 + > board/alliedtelesis/x530/x530.c | 1 + > board/gdsys/a38x/controlcenterdc.c| 1 + > board/kobol/helios4/helios4.c | 1 + > board/solidrun/clearfog/clearfog.c| 1 + > drivers/ddr/marvell/a38x/ddr3_init.c | 5 > drivers/ddr/marvell/a38x/ddr3_training.c | 5 +++- > drivers/ddr/marvell/a38x/ddr3_training_db.c | 3 +++ > .../ddr/marvell/a38x/ddr3_training_ip_def.h | 2 ++ > .../marvell/a38x/ddr3_training_ip_engine.c| 5 +++- > drivers/ddr/marvell/a38x/ddr_topology_def.h | 23 ++- > .../ddr/marvell/a38x/mv_ddr_build_message.c | 2 +- > drivers/ddr/marvell/a38x/mv_ddr_plat.c| 9 ++-- > drivers/ddr/marvell/a38x/mv_ddr_topology.c| 14 --- > drivers/ddr/marvell/a38x/mv_ddr_topology.h| 2 ++ > drivers/ddr/marvell/a38x/xor.c| 6 ++--- > 18 files changed, 72 insertions(+), 12 deletions(-) >
Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
This patch is needed on some Turris Omnia boards with Samsung DDR chips, otherwise DDR training fails in ~60% of cases. Marvell send us this patch for testing, I have updated it a little. Please test this on other A38x boards. If it doesn't break anything on other boards, we can apply it and send it to mv-ddr-marvell upstream. Marek
[PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
From: motib In each pattern cycle the bus state can be changed. In order to avoid it, we need to switch back to the same bus state on each pattern cycle. Signed-off-by: motib Fixed code style, removed commented code, switched to use DEBUG macros instead of printf. Signed-off-by: Marek Behún --- .../a38x/ddr3_training_centralization.c | 25 +++ .../marvell/a38x/ddr3_training_ip_engine.c| 8 -- 2 files changed, 31 insertions(+), 2 deletions(-) diff --git a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c index 648b37ef6f..a92760681e 100644 --- a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c +++ b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c @@ -24,6 +24,8 @@ u8 bus_start_window[NUM_OF_CENTRAL_TYPES][MAX_INTERFACE_NUM][MAX_BUS_NUM]; u8 centralization_state[MAX_INTERFACE_NUM][MAX_BUS_NUM]; static u8 ddr3_tip_special_rx_run_once_flag; +extern u8 byte_status[MAX_INTERFACE_NUM][MAX_BUS_NUM]; + static int ddr3_tip_centralization(u32 dev_num, u32 mode); /* @@ -110,6 +112,7 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode) (max_win_size - 1) + cons_tap; bus_start_window[mode][if_id][bus_id] = 0; centralization_result[if_id][bus_id] = 0; + byte_status[if_id][bus_id] = BYTE_NOT_DEFINED; } } @@ -166,6 +169,12 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode) result[search_dir_id][7])); } + DEBUG_CENTRALIZATION_ENGINE + (DEBUG_LEVEL_TRACE, +("byte_status[%d][%d] = 0x%x\n", +if_id, +bus_id, +byte_status[if_id][bus_id])); for (bit_id = 0; bit_id < BUS_WIDTH_IN_BITS; bit_id++) { /* check if this code is valid for 2 edge, probably not :( */ @@ -174,11 +183,27 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode) [HWS_LOW2HIGH] [bit_id], EDGE_1); + if ((byte_status[if_id][bus_id] & BYTE_SPLIT_OUT_MIX) || + (byte_status[if_id][bus_id] & BYTE_HOMOGENEOUS_SPLIT_OUT)) { + if (cur_start_win[bit_id] >= 64) + cur_start_win[bit_id] -= 64; + else + cur_start_win[bit_id] = 0; + DEBUG_CENTRALIZATION_ENGINE + (DEBUG_LEVEL_TRACE, + ("--\n")); + } cur_end_win[bit_id] = GET_TAP_RESULT(result [HWS_HIGH2LOW] [bit_id], EDGE_1); + if (cur_end_win[bit_id] >= 64 && (byte_status[if_id][bus_id] & BYTE_SPLIT_OUT_MIX)) { + cur_end_win[bit_id] -= 64; + DEBUG_CENTRALIZATION_ENGINE + (DEBUG_LEVEL_TRACE, + ("++\n")); + } /* window length */ current_window[bit_id] = cur_end_win[bit_id] - diff --git a/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c b/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c index 5fd9a052fa..3d1fa1e74e 100644 --- a/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c +++ b/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c @@ -1174,7 +1174,6 @@ int ddr3_tip_ip_training_wrapper(u32 dev_num, enum hws_access_type access_type, /* zero the data base */ bit_bit_mask[sybphy_id] = 0; - byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED; for (bit_id = 0; bit_id <
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
btw tested on Turris Omnia
[PATCH u-boot-marvell 16/18] ddr: marvell: a38x: enum mv_ddr_twin_die: change order
commit 56db5d1464b44df10a02b99e615ebd6f6a35c428 upstream. @pali suggested this change In commit 6285efb ("mv_ddr: add support for twin-die combined memory device") was added support for twin-die combined memory device and default value for explicitly uninitialized structure members is zero, s also twin_die_combined is initialized to zero. Which means COMBINED value. As prior this commit there was no support for twin-die combined memory device, default value for twin_die_combined should be NOT_COMBINED. This change change order of enum mv_ddr_twin_die to ensure that NOT_COMBINED has value zero. Signed-off-by: heaterC Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/ddr_topology_def.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h b/drivers/ddr/marvell/a38x/ddr_topology_def.h index 2cca5676a0..7f2317edfa 100644 --- a/drivers/ddr/marvell/a38x/ddr_topology_def.h +++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h @@ -15,8 +15,8 @@ #define MV_DDR_MAX_IFACE_NUM 1 enum mv_ddr_twin_die { - COMBINED, NOT_COMBINED, + COMBINED, }; struct bus_params { -- 2.26.2
[PATCH u-boot-marvell 17/18] ddr: marvell: a38x: bump version to 14.0.0
Bump version of a38x DDR3 trianing to version 14.0.0 to reflect the version in the mv-ddr-devel branch of upstream repository https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git. There is a new version numbering system, where after 18.12.0 came 1.0.0, 2.0.0, and so on until 14.0.0. So 14.0.0 is newer than 18.12.0. Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/mv_ddr_build_message.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ddr/marvell/a38x/mv_ddr_build_message.c b/drivers/ddr/marvell/a38x/mv_ddr_build_message.c index cc6234fd40..a2bb8a96a6 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_build_message.c +++ b/drivers/ddr/marvell/a38x/mv_ddr_build_message.c @@ -1,3 +1,3 @@ // SPDX-License-Identifier: GPL-2.0 const char mv_ddr_build_message[] = ""; -const char mv_ddr_version_string[] = "mv_ddr: mv_ddr-armada-18.09.2"; +const char mv_ddr_version_string[] = "mv_ddr: 14.0.0"; -- 2.26.2
[PATCH u-boot-marvell 18/18] ddr: marvell: a38x: fix comment in conditional macro
The code was processed with unifdef utility to omit portions not relevant to A38x and DDR3. This removes usage of many macros, including A70X0, A80X0 and A3900. It seems that the unifdef utility did not remove the macros from #else comment. Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/ddr3_training.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ddr/marvell/a38x/ddr3_training.c b/drivers/ddr/marvell/a38x/ddr3_training.c index 0358f6287a..2b3af23202 100644 --- a/drivers/ddr/marvell/a38x/ddr3_training.c +++ b/drivers/ddr/marvell/a38x/ddr3_training.c @@ -219,7 +219,7 @@ static int ddr3_tip_pad_inv(void) DDR_PHY_CONTROL, PHY_CTRL_PHY_REG, data, data); -#else /* !CONFIG_ARMADA_38X && !CONFIG_ARMADA_39X && !A70X0 && !A80X0 && !A3900 */ +#else /* !CONFIG_ARMADA_38X && !CONFIG_ARMADA_39X */ #pragma message "unknown platform to configure ddr clock swap" #endif } -- 2.26.2
[PATCH u-boot-marvell 15/18] ddr: marvell: a38x: import code change from upstream
commit 2bdd12dd68b1f8e27a03a3443ae49a09a14c18e4 upstream. The commit mentioned above changes non-DDR3 stuff in upstream, but it also changes code in ddr3_training.c. Import this change to remain consistent with upstream. Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/ddr3_training.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/ddr/marvell/a38x/ddr3_training.c b/drivers/ddr/marvell/a38x/ddr3_training.c index 34cc170910..0358f6287a 100644 --- a/drivers/ddr/marvell/a38x/ddr3_training.c +++ b/drivers/ddr/marvell/a38x/ddr3_training.c @@ -143,6 +143,7 @@ static struct reg_data odpg_default_value[] = { {0x15a4, 0x0, MASK_ALL_BITS}, {0x15a8, 0x0, MASK_ALL_BITS}, {0x15ac, 0x0, MASK_ALL_BITS}, + {0x1600, 0x0, MASK_ALL_BITS}, {0x1604, 0x0, MASK_ALL_BITS}, {0x1608, 0x0, MASK_ALL_BITS}, {0x160c, 0x0, MASK_ALL_BITS}, @@ -1569,6 +1570,8 @@ int ddr3_tip_freq_set(u32 dev_num, enum hws_access_type access_type, val = ((cl_mask_table[cl_value] & 0x1) << 2) | ((cl_mask_table[cl_value] & 0xe) << 3); + cs_mask[0] = 0xc; + CHECK_STATUS(ddr3_tip_write_mrs_cmd(dev_num, cs_mask, MR_CMD0, val, (0x7 << 4) | (0x1 << 2))); -- 2.26.2
[PATCH u-boot-marvell 14/18] ddr: marvell: a38x: fix memory cs size function
commit c8b301463d508c807a33f7b7eaea98bbda4aa35e upstream. The funtion returnd cs size in byte instead of MB, that cause calculation error since the caller was expected to get u32 and when he got above 4G it refers it as 0. The fix was to get the cs memory size from function as in MB and then multiply it by 1MB. Signed-off-by: Moti Buskila Reviewed-by: Kostya Porotchkin Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/mv_ddr_plat.c | 9 +++-- drivers/ddr/marvell/a38x/xor.c | 6 +++--- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.c b/drivers/ddr/marvell/a38x/mv_ddr_plat.c index 72f0df..0d1df189e8 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_plat.c +++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.c @@ -4,6 +4,7 @@ */ #include "ddr3_init.h" +#include "mv_ddr_common.h" #include "mv_ddr_training_db.h" #include "mv_ddr_regs.h" #include "mv_ddr_sys_env_lib.h" @@ -1016,7 +1017,7 @@ int ddr3_calc_mem_cs_size(u32 cs, uint64_t *cs_size) return MV_BAD_VALUE; } - *cs_size = cs_mem_size << 20; /* write cs size in bytes */ + *cs_size = cs_mem_size; return MV_OK; } @@ -1025,9 +1026,11 @@ static int ddr3_fast_path_dynamic_cs_size_config(u32 cs_ena) { u32 reg, cs; uint64_t mem_total_size = 0; + uint64_t cs_mem_size_mb = 0; uint64_t cs_mem_size = 0; uint64_t mem_total_size_c, cs_mem_size_c; + #ifdef DEVICE_MAX_DRAM_ADDRESS_SIZE u32 physical_mem_size; u32 max_mem_size = DEVICE_MAX_DRAM_ADDRESS_SIZE; @@ -1038,8 +1041,9 @@ static int ddr3_fast_path_dynamic_cs_size_config(u32 cs_ena) for (cs = 0; cs < MAX_CS_NUM; cs++) { if (cs_ena & (1 << cs)) { /* get CS size */ - if (ddr3_calc_mem_cs_size(cs, _mem_size) != MV_OK) + if (ddr3_calc_mem_cs_size(cs, _mem_size_mb) != MV_OK) return MV_FAIL; + cs_mem_size = cs_mem_size_mb * _1M; #ifdef DEVICE_MAX_DRAM_ADDRESS_SIZE /* @@ -1088,6 +1092,7 @@ static int ddr3_fast_path_dynamic_cs_size_config(u32 cs_ena) */ mem_total_size_c = (mem_total_size >> 16) & 0x; cs_mem_size_c = (cs_mem_size >> 16) & 0x; + /* if the sum less than 2 G - calculate the value */ if (mem_total_size_c + cs_mem_size_c < 0x1) mem_total_size += cs_mem_size; diff --git a/drivers/ddr/marvell/a38x/xor.c b/drivers/ddr/marvell/a38x/xor.c index 5fb9e216d3..98fb39eaf0 100644 --- a/drivers/ddr/marvell/a38x/xor.c +++ b/drivers/ddr/marvell/a38x/xor.c @@ -340,7 +340,7 @@ void ddr3_new_tip_ecc_scrub(void) { u32 cs_c, max_cs; u32 cs_ena = 0; - uint64_t total_mem_size, cs_mem_size = 0; + uint64_t total_mem_size, cs_mem_size_mb = 0, cs_mem_size = 0; printf("DDR Training Sequence - Start scrubbing\n"); max_cs = mv_ddr_cs_num_get(); @@ -349,9 +349,9 @@ void ddr3_new_tip_ecc_scrub(void) #if defined(CONFIG_ARMADA_38X) || defined(CONFIG_ARMADA_39X) /* all chip-selects are of same size */ - ddr3_calc_mem_cs_size(0, _mem_size); + ddr3_calc_mem_cs_size(0, _mem_size_mb); #endif - + cs_mem_size = cs_mem_size_mb * _1M; mv_sys_xor_init(max_cs, cs_ena, cs_mem_size, 0); total_mem_size = max_cs * cs_mem_size; mv_xor_mem_init(0, 0, total_mem_size, 0xdeadbeef, 0xdeadbeef); -- 2.26.2
[PATCH u-boot-marvell 11/18] ddr: marvell: a38x: add support for twin-die combined memory device
commit 6285efb8a118940877522c4c07bd7c64569b4f5f upstream. the twin-die combined memory device should be treatened as X8 device and not as X16 one Signed-off-by: Moti Buskila Reviewed-by: Kostya Porotchkin The default value for twin_die_combined is set to NOT_COMBINED for all boards, as this was default behaviour prior this change. Signed-off-by: Marek Behún --- board/CZ.NIC/turris_omnia/turris_omnia.c | 2 ++ board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 1 + board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 1 + board/alliedtelesis/x530/x530.c | 1 + board/gdsys/a38x/controlcenterdc.c| 1 + board/kobol/helios4/helios4.c | 1 + board/solidrun/clearfog/clearfog.c| 1 + drivers/ddr/marvell/a38x/ddr_topology_def.h | 12 drivers/ddr/marvell/a38x/mv_ddr_topology.c| 6 +- 9 files changed, 25 insertions(+), 1 deletion(-) diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c b/board/CZ.NIC/turris_omnia/turris_omnia.c index 2da878d364..78b125edfe 100644 --- a/board/CZ.NIC/turris_omnia/turris_omnia.c +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c @@ -285,6 +285,7 @@ static struct mv_ddr_topology_map board_topology_map_1g = { MV_DDR_TIM_2T} }, /* timing */ BUS_MASK_32BIT, /* Busses mask */ MV_DDR_CFG_DEFAULT, /* ddr configuration data source */ + NOT_COMBINED, /* ddr twin-die combined */ { {0} },/* raw spd data */ {0} /* timing parameters */ }; @@ -307,6 +308,7 @@ static struct mv_ddr_topology_map board_topology_map_2g = { MV_DDR_TIM_2T} }, /* timing */ BUS_MASK_32BIT, /* Busses mask */ MV_DDR_CFG_DEFAULT, /* ddr configuration data source */ + NOT_COMBINED, /* ddr twin-die combined */ { {0} },/* raw spd data */ {0} /* timing parameters */ }; diff --git a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c index 9cd9ea2c06..acc8a5ec6d 100644 --- a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c +++ b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c @@ -72,6 +72,7 @@ static struct mv_ddr_topology_map board_topology_map = { MV_DDR_TIM_DEFAULT} }, /* timing */ BUS_MASK_32BIT, /* Busses mask */ MV_DDR_CFG_DEFAULT, /* ddr configuration data source */ + NOT_COMBINED, /* ddr twin-die combined */ { {0} },/* raw spd data */ {0} /* timing parameters */ }; diff --git a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c index 2bdd55329d..a1d0104526 100644 --- a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c +++ b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c @@ -93,6 +93,7 @@ static struct mv_ddr_topology_map board_topology_map = { MV_DDR_TIM_DEFAULT} }, /* timing */ BUS_MASK_32BIT, /* Busses mask */ MV_DDR_CFG_DEFAULT, /* ddr configuration data source */ + NOT_COMBINED, /* ddr twin-die combined */ { {0} },/* raw spd data */ {0} /* timing parameters */ }; diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c index c7438aeaf1..6caba24196 100644 --- a/board/alliedtelesis/x530/x530.c +++ b/board/alliedtelesis/x530/x530.c @@ -67,6 +67,7 @@ static struct mv_ddr_topology_map board_topology_map = { MV_DDR_TIM_2T} }, /* timing */ BUS_MASK_32BIT_ECC, /* subphys mask */ MV_DDR_CFG_DEFAULT, /* ddr configuration data source */ + NOT_COMBINED, /* ddr twin-die combined */ { {0} },/* raw spd data */ {0},/* timing parameters */ { {0} },/* electrical configuration */ diff --git a/board/gdsys/a38x/controlcenterdc.c b/board/gdsys/a38x/controlcenterdc.c index a2287f9deb..66a0d769ce 100644 --- a/board/gdsys/a38x/controlcenterdc.c +++ b/board/gdsys/a38x/controlcenterdc.c @@ -70,6 +70,7 @@ static struct mv_ddr_topology_map ddr_topology_map = { MV_DDR_TIM_DEFAULT} }, /* timing */ BUS_MASK_32BIT, /* Busses mask */ MV_DDR_CFG_DEFAULT, /* ddr configuration data source */ + NOT_COMBINED, /* ddr twin-die combined */ { {0} },/* raw spd data */ {0} /* timing parameters */ diff --git a/board/kobol/helios4/helios4.c b/board/kobol/helios4/helios4.c index 17d2489415..5007194a52 100644 --- a/board/kobol/helios4/helios4.c
[PATCH u-boot-marvell 12/18] ddr: marvell: a38x: disable WL phase correction stage in case of bus_width=16bit
commit 20c89a28548cdab11f88d2ec8936344af0686a1e upstream. WL phase correcion stage is failing while using bus_width of 16bit, not to be fix this stage is un-necessary when working with bus_width of 16 bit. Signed-off-by: Moti Buskila Reviewed-by: Kostya Porotchkin Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/ddr3_training_db.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/ddr/marvell/a38x/ddr3_training_db.c b/drivers/ddr/marvell/a38x/ddr3_training_db.c index b2f11a8399..6aa7b6069e 100644 --- a/drivers/ddr/marvell/a38x/ddr3_training_db.c +++ b/drivers/ddr/marvell/a38x/ddr3_training_db.c @@ -833,6 +833,9 @@ u32 pattern_table_get_word(u32 dev_num, enum hws_pattern type, u8 index) pattern = pattern_table_get_isi_word16(index); break; default: + if (((int)type == 29) || ((int)type == 30)) + break; + printf("error: %s: unsupported pattern type [%d] found\n", __func__, (int)type); pattern = 0; -- 2.26.2
[PATCH u-boot-marvell 13/18] ddr: marvell: a38x: import header change from upstream
commit d653b305d0b3da9727c49124683f1a6d95d5c9a5 upstream. The commit mentioned above changes non-DDR3 stuff in upstream, but it also changes header ddr_topology_def.h. Import this header change to remain consistent with upstream. Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/ddr_topology_def.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h b/drivers/ddr/marvell/a38x/ddr_topology_def.h index 461f091472..2cca5676a0 100644 --- a/drivers/ddr/marvell/a38x/ddr_topology_def.h +++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h @@ -52,9 +52,6 @@ struct if_params { /* The DDR frequency for each interfaces */ enum mv_ddr_freq memory_freq; -/* ddr twin-die */ - enum mv_ddr_twin_die twin_die_combined; - /* * delay CAS Write Latency * - 0 for using default value (jedec suggested) -- 2.26.2
[PATCH u-boot-marvell 10/18] ddr: marvell: a38x: add 16Gbit memory devices support
commit 994509eb4fe6771d92cd06314c37895098ac48fa upstream. Signed-off-by: Moti Buskila Reviewed-by: Kostya Porotchkin Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/ddr3_training_ip_def.h | 2 ++ drivers/ddr/marvell/a38x/mv_ddr_topology.c | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h b/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h index 2a68669f36..8765df7cfb 100644 --- a/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h +++ b/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h @@ -80,6 +80,8 @@ #define ADDR_SIZE_2GB 0x1000 #define ADDR_SIZE_4GB 0x2000 #define ADDR_SIZE_8GB 0x4000 +#define ADDR_SIZE_16GB 0x8000 + enum hws_edge_compare { EDGE_PF, diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c b/drivers/ddr/marvell/a38x/mv_ddr_topology.c index 31711fdd49..c4c3ab72b2 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c +++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c @@ -248,7 +248,8 @@ static unsigned int mem_size[] = { ADDR_SIZE_1GB, ADDR_SIZE_2GB, ADDR_SIZE_4GB, - ADDR_SIZE_8GB + ADDR_SIZE_8GB, + ADDR_SIZE_16GB /* TODO: add capacity up to 256GB */ }; -- 2.26.2
[PATCH u-boot-marvell 07/18] ddr: marvell: a38x: fix memory size calculation using 32bit bus width
commit ab9240402a70cc02496683971779e75eff410ab4 upstream. - function mv_ddr_spd_die_capacity_user_get() has a bug, since it insert a user memory enum to it, instead of SPD memory enum (which are different) - fix: remove mv_ddr_spd_die_capacity_user_get() function. - memory size with 64 and 32 bit already calculated correctly at mv_ddr_mem_sz_per_cs_get() function Signed-off-by: motib Reviewed-by: Stefan Chulski Reviewed-by: Alex Leibovich Reviewed-by: Kostya Porotchkin Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/mv_ddr_spd.c | 5 - drivers/ddr/marvell/a38x/mv_ddr_spd.h | 1 - drivers/ddr/marvell/a38x/mv_ddr_topology.c | 4 3 files changed, 10 deletions(-) diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.c b/drivers/ddr/marvell/a38x/mv_ddr_spd.c index cb90d30a6a..04dbfe94d6 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_spd.c +++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.c @@ -217,11 +217,6 @@ enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union mv_ddr_spd_data *spd_ return ret_val; } -void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum mv_ddr_die_capacity capacity) -{ - spd_data->byte_fields.byte_4.bit_fields.die_capacity = capacity; -} - unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data) { unsigned char mem_mirror = spd_data->byte_fields.byte_131.bit_fields.rank_1_mapping; diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.h b/drivers/ddr/marvell/a38x/mv_ddr_spd.h index ee35377af5..b4bfef3103 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_spd.h +++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.h @@ -277,7 +277,6 @@ union mv_ddr_spd_data { int mv_ddr_spd_timing_calc(union mv_ddr_spd_data *spd_data, unsigned int timing_data[]); enum mv_ddr_dev_width mv_ddr_spd_dev_width_get(union mv_ddr_spd_data *spd_data); enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union mv_ddr_spd_data *spd_data); -void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum mv_ddr_die_capacity capacity); unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data); unsigned char mv_ddr_spd_cs_bit_mask_get(union mv_ddr_spd_data *spd_data); unsigned char mv_ddr_spd_dev_type_get(union mv_ddr_spd_data *spd_data); diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c b/drivers/ddr/marvell/a38x/mv_ddr_topology.c index 3feb65ea46..31711fdd49 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c +++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c @@ -74,10 +74,6 @@ int mv_ddr_topology_map_update(void) /* update device width in topology map */ iface_params->bus_width = mv_ddr_spd_dev_width_get(>spd_data); - /* overwrite SPD configuration, with what the user set */ - if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK) - mv_ddr_spd_die_capacity_user_get(>spd_data, tm->interface_params[0].memory_size); - /* update die capacity in topology map */ iface_params->memory_size = mv_ddr_spd_die_capacity_get(>spd_data); -- 2.26.2
[PATCH u-boot-marvell 08/18] ddr: marvell: a38x: import header change from upstream
commit 3908e20c6c520339e9bddb566823ae5e065d5218 upstream. The commit mentioned above changes non-DDR3 stuff in upstream, but it also changes header ddr_topology_def.h. Import this header change to remain consistent with upstream. Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/ddr_topology_def.h | 8 1 file changed, 8 insertions(+) diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h b/drivers/ddr/marvell/a38x/ddr_topology_def.h index c55e3b57e4..342c2cf451 100644 --- a/drivers/ddr/marvell/a38x/ddr_topology_def.h +++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h @@ -152,6 +152,11 @@ enum mv_ddr_validation { MV_DDR_MEMORY_CHECK }; +enum mv_ddr_sscg { + SSCG_EN, + SSCG_DIS, +}; + struct mv_ddr_iface { /* base addr of ap ddr interface belongs to */ unsigned int ap_base; @@ -180,6 +185,9 @@ struct mv_ddr_iface { /* ddr interface validation mode */ enum mv_ddr_validation validation; + /* ddr interface validation mode */ + enum mv_ddr_sscg sscg; + /* ddr interface topology map */ struct mv_ddr_topology_map tm; }; -- 2.26.2
[PATCH u-boot-marvell 09/18] ddr: marvell: a38x: allow board specific ODT configuration
commit 2d3b9437cf38c06c4330e0de07f29476197f5e04 upstream. The ODT enable heuristic based on active chip-selects is not always correct. Some board might use two chip-selects, but have only one ODT line connected. Allow board specific mv_ddr_topology_map to directly set the ODT configuration register value. Signed-off-by: Baruch Siach Reviewed-by: Moti Buskila Reviewed-by: Nadav Haklai Reviewed-by: Kostya Porotchkin Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/ddr3_init.c| 5 + drivers/ddr/marvell/a38x/ddr_topology_def.h | 3 +++ 2 files changed, 8 insertions(+) diff --git a/drivers/ddr/marvell/a38x/ddr3_init.c b/drivers/ddr/marvell/a38x/ddr3_init.c index a971cc155a..7488770268 100644 --- a/drivers/ddr/marvell/a38x/ddr3_init.c +++ b/drivers/ddr/marvell/a38x/ddr3_init.c @@ -104,6 +104,7 @@ int ddr3_init(void) static int mv_ddr_training_params_set(u8 dev_num) { struct tune_train_params params; + struct mv_ddr_topology_map *tm = mv_ddr_topology_map_get(); int status; u32 cs_num; int ck_delay; @@ -136,6 +137,10 @@ static int mv_ddr_training_params_set(u8 dev_num) if (ck_delay > 0) params.ck_delay = ck_delay; + /* Use platform specific override ODT value */ + if (tm->odt_config) + params.g_odt_config = tm->odt_config; + status = ddr3_tip_tune_training_params(dev_num, ); if (MV_OK != status) { printf("%s Training Sequence - FAILED\n", ddr_type); diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h b/drivers/ddr/marvell/a38x/ddr_topology_def.h index 342c2cf451..3991fec272 100644 --- a/drivers/ddr/marvell/a38x/ddr_topology_def.h +++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h @@ -125,6 +125,9 @@ struct mv_ddr_topology_map { /* electrical parameters */ unsigned int electrical_data[MV_DDR_EDATA_LAST]; + /* ODT configuration */ + u32 odt_config; + /* Clock enable mask */ u32 clk_enable; -- 2.26.2
[PATCH u-boot-marvell 06/18] ddr: marvell: a38x: fix 32bit
commit 0b5adedd4ced9b8f528faad1957d4d69e95759ef upstream. Signed-off-by: motib Reviewed-by: Alex Leibovich Reviewed-by: Kostya Porotchkin Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/mv_ddr_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c b/drivers/ddr/marvell/a38x/mv_ddr_topology.c index 0cbe8d3d1e..3feb65ea46 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c +++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c @@ -149,7 +149,7 @@ unsigned short mv_ddr_bus_bit_mask_get(void) if (tm->cfg_src == MV_DDR_CFG_SPD) { if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK) - tm->spd_data.byte_fields.byte_13.all_bits = MV_DDR_PRI_BUS_WIDTH_32; + tm->spd_data.byte_fields.byte_13.bit_fields.primary_bus_width = MV_DDR_PRI_BUS_WIDTH_32; enum mv_ddr_pri_bus_width pri_bus_width = mv_ddr_spd_pri_bus_width_get(>spd_data); enum mv_ddr_bus_width_ext bus_width_ext = mv_ddr_spd_bus_width_ext_get(>spd_data); -- 2.26.2
[PATCH u-boot-marvell 04/18] ddr: marvell: a38x: add ddr 32bit ECC support
commit 61a8910998d7b553e80f600ebe8147a8b98f0945 upstream. Required changes made for 32bit ddr support. An update is made to the topology map, according to bus_act_mask, set in the dram_port.c Signed-off-by: Alex Leibovich Reviewed-by: Kostya Porotchkin Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/mv_ddr_spd.c | 5 + drivers/ddr/marvell/a38x/mv_ddr_spd.h | 1 + drivers/ddr/marvell/a38x/mv_ddr_topology.c | 6 +- 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.c b/drivers/ddr/marvell/a38x/mv_ddr_spd.c index 04dbfe94d6..cb90d30a6a 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_spd.c +++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.c @@ -217,6 +217,11 @@ enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union mv_ddr_spd_data *spd_ return ret_val; } +void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum mv_ddr_die_capacity capacity) +{ + spd_data->byte_fields.byte_4.bit_fields.die_capacity = capacity; +} + unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data) { unsigned char mem_mirror = spd_data->byte_fields.byte_131.bit_fields.rank_1_mapping; diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.h b/drivers/ddr/marvell/a38x/mv_ddr_spd.h index b4bfef3103..ee35377af5 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_spd.h +++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.h @@ -277,6 +277,7 @@ union mv_ddr_spd_data { int mv_ddr_spd_timing_calc(union mv_ddr_spd_data *spd_data, unsigned int timing_data[]); enum mv_ddr_dev_width mv_ddr_spd_dev_width_get(union mv_ddr_spd_data *spd_data); enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union mv_ddr_spd_data *spd_data); +void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum mv_ddr_die_capacity capacity); unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data); unsigned char mv_ddr_spd_cs_bit_mask_get(union mv_ddr_spd_data *spd_data); unsigned char mv_ddr_spd_dev_type_get(union mv_ddr_spd_data *spd_data); diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c b/drivers/ddr/marvell/a38x/mv_ddr_topology.c index f2cd7c0ef3..0cbe8d3d1e 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c +++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c @@ -74,6 +74,10 @@ int mv_ddr_topology_map_update(void) /* update device width in topology map */ iface_params->bus_width = mv_ddr_spd_dev_width_get(>spd_data); + /* overwrite SPD configuration, with what the user set */ + if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK) + mv_ddr_spd_die_capacity_user_get(>spd_data, tm->interface_params[0].memory_size); + /* update die capacity in topology map */ iface_params->memory_size = mv_ddr_spd_die_capacity_get(>spd_data); @@ -144,7 +148,7 @@ unsigned short mv_ddr_bus_bit_mask_get(void) unsigned int octets_per_if_num = ddr3_tip_dev_attr_get(0, MV_ATTR_OCTET_PER_INTERFACE); if (tm->cfg_src == MV_DDR_CFG_SPD) { - if (tm->bus_act_mask == BUS_MASK_32BIT) + if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK) tm->spd_data.byte_fields.byte_13.all_bits = MV_DDR_PRI_BUS_WIDTH_32; enum mv_ddr_pri_bus_width pri_bus_width = mv_ddr_spd_pri_bus_width_get(>spd_data); -- 2.26.2
[PATCH u-boot-marvell 05/18] ddr: marvell: a38x: import header change from upstream
commit 6c705ebc0d70f67ed7cae83ad1978c3305ef25be upstream. The commit mentioned above changes non-DDR3 stuff in upstream, but it also changes header mv_ddr_topology.h. Import this header change to remain consistent with upstream. Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/mv_ddr_topology.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.h b/drivers/ddr/marvell/a38x/mv_ddr_topology.h index 4fca47689f..1cb69ad085 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_topology.h +++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.h @@ -179,7 +179,9 @@ enum mv_ddr_dic_evalue { /* phy electrical configuration values */ enum mv_ddr_ohm_evalue { + MV_DDR_OHM_20 = 20,/*relevant for Synopsys C/A Drive strength only*/ MV_DDR_OHM_30 = 30, + MV_DDR_OHM_40 = 40,/*relevant for Synopsys C/A Drive strength only*/ MV_DDR_OHM_48 = 48, MV_DDR_OHM_60 = 60, MV_DDR_OHM_80 = 80, -- 2.26.2