Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
чт, 11 авг. 2022 г. в 01:52, Nishanth Menon :
>
> On 11:40-20220807, Matwey V. Kornilov wrote:
> > пт, 5 авг. 2022 г. в 18:01, Robert Nelson :
> > >
> > > On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov
> > > wrote:
> > > >
> > > > пт, 29 июл. 2022 г. в 19:46, Tom Rini :
> > > > >
> > > > > On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
> > > > > > пт, 29 июл. 2022 г. в 19:32, Tom Rini :
> > > > > > >
> > > > > > > On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I've tried to build an am335x_evm_defconfig u-boot to use it on
> > > > > > > > my
> > > > > > > > BeagleBone Black board. Surprisingly, I've found that it
> > > > > > > > doesn't work,
> > > > > > > > I see the silent console: no messages even from SPL.
> > > > > > > >
> > > > > > > > Using bisect I've found that the following commit breaks the
> > > > > > > > booting:
> > > > > > > >
> > > > > > > > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte
> > > > > > > > address
> > > > > > > > checks first.")
> > > > > > > >
> > > > > > > > Could you please help me?
> > > > > > >
> > > > > > > Can you share some more details about which BeagleBone Black you
> > > > > > > have,
> > > > > > > specifically the revision?
> > > > > >
> > > > > > It is an ordinary C revision. Unfortunately, I cannot remember who
> > > > > > the
> > > > > > producer was. As far as I know many companies made BeagleBone Black
> > > > > > and EEPROM content can be different.
> > > > >
> > > > > OK, that'll help some. Can you see what the specific part number of
> > > > > the
> > > > > EEPROM is? That might also help Nishanth figure out what to do here.
> > > >
> > > > Attached here is the EEPROM dump.
> > >
> > > .U3.A335BNLT00C0
> > >
> > > Ah, the "CO"... i'm pretty sure that board was made by Element14,
> > > (they messed up the position of the "C") not that it really mattered
> > > as the A335BNLT is only used..
> >
> > Hi Robert,
> >
> > I have BBB from different vendors, and I do remember that I've
> > purchased the Element14 version at some point. However, I've messed
> > everything up and cannot figure out which board from which vendor. You
> > are the most probably right, but still I cannot confirm the origin.
> >
> > >
> > > Can you please take a quick snapshot of the eeprom, it should be...
> > > 24LC32AT-I/OT but maybe they used another variation..
> >
> > Attached here is U7. It says M67E. 24AA32A/24LC32A datasheet page 14
> > says that it should be 24LC32AI.
> >
>
> Wierd.. took me a bit of digging, but I did get the element14 beaglebone
> rev C black board as well.. but it boots fine for me.
>
> https://gist.github.com/nmenon/104f040a67a6af0b0418c95ad83ad50b
>
> I tested the very tip of master:
> 3dd4e916324e Merge https://source.denx.de/u-boot/custodians/u-boot-marvell
3dd4e916324e doesn't work,
3dd4e916324e + reverted a58147c2dbbf boots:
U-Boot SPL 2022.10-rc2-00029-g3dd4e91632-dirty (Aug 11 2022 - 09:50:59 +0300)
Trying to boot from MMC1
U-Boot 2022.10-rc2-00029-g3dd4e91632-dirty (Aug 11 2022 - 09:50:59 +0300)
CPU : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM: 512 MiB
Core: 160 devices, 18 uclasses, devicetree: separate
WDT: Started wdt@44e35000 with servicing (60s timeout)
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
not set. Validating first E-fuse MAC
Net: eth2: ethernet@4a10, eth3: usb_ether
Hit any key to stop autoboot: 0
=> i2c dev 0 ; i2c md 0x50 0x00.2 400
Setting bus to 0
: aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 30 43 30.U3.A335BNLT00C0
0010: 34 34 31 34 42 42 42 4b 31 30 30 30 ff ff ff ff4414BBBK1000
0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0050: 58 41 4e 30 30 31 30 30 30 58 58 58 58 58 58 58XAN001000XXX
0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> Seemed to boot fine. Apparently it is supposed to be the same type as
> your board as well and it boots just fine on master.
>
> U7, however, on my board, is unmarked.
>
> Not really sure what to make of this.
>
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
> 849D 1736 249D
--
With best regards,
Matwey V. Kornilov
RE: [PATCH 05/31] mmc: mediatek: add support for MediaTek MT7891/MT7986 SoCs
> -Original Message-
> From: Weijie Gao [mailto:weijie@mediatek.com]
> Sent: Thursday, August 4, 2022 12:35 PM
> To: u-boot@lists.denx.de
> Cc: GSS_MTK_Uboot_upstream; Peng Fan; Jaehoon Chung; Weijie Gao
> Subject: [PATCH 05/31] mmc: mediatek: add support for MediaTek MT7891/MT7986
> SoCs
>
> This patch adds eMMC and SDXC support for MediaTek MT7981/MT7986 SoCs
>
> Signed-off-by: Weijie Gao
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/mtk-sd.c | 68 ++--
> 1 file changed, 53 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
> index e61e8cf4b9..b206b0a085 100644
> --- a/drivers/mmc/mtk-sd.c
> +++ b/drivers/mmc/mtk-sd.c
> @@ -1496,7 +1496,12 @@ static void msdc_init_hw(struct msdc_host *host)
> /* Enable data & cmd interrupts */
> writel(DATA_INTS_MASK | CMD_INTS_MASK, &host->base->msdc_inten);
>
> - writel(0, tune_reg);
> + if (host->top_base) {
> + writel(0, &host->top_base->emmc_top_control);
> + writel(0, &host->top_base->emmc_top_cmd);
> + } else {
> + writel(0, tune_reg);
> + }
> writel(0, &host->base->msdc_iocon);
>
> if (host->r_smpl)
> @@ -1507,9 +1512,14 @@ static void msdc_init_hw(struct msdc_host *host)
> writel(0x403c0046, &host->base->patch_bit0);
> writel(0x4089, &host->base->patch_bit1);
>
> - if (host->dev_comp->stop_clk_fix)
> + if (host->dev_comp->stop_clk_fix) {
> clrsetbits_le32(&host->base->patch_bit1, MSDC_PB1_STOP_DLY_M,
> 3 << MSDC_PB1_STOP_DLY_S);
> + clrbits_le32(&host->base->sdc_fifo_cfg,
> + SDC_FIFO_CFG_WRVALIDSEL);
> + clrbits_le32(&host->base->sdc_fifo_cfg,
> + SDC_FIFO_CFG_RDVALIDSEL);
> + }
>
> if (host->dev_comp->busy_check)
> clrbits_le32(&host->base->patch_bit1, (1 << 7));
> @@ -1544,15 +1554,28 @@ static void msdc_init_hw(struct msdc_host *host)
> }
>
> if (host->dev_comp->data_tune) {
> - setbits_le32(tune_reg,
> - MSDC_PAD_TUNE_RD_SEL | MSDC_PAD_TUNE_CMD_SEL);
> - clrsetbits_le32(&host->base->patch_bit0,
> - MSDC_INT_DAT_LATCH_CK_SEL_M,
> - host->latch_ck <<
> - MSDC_INT_DAT_LATCH_CK_SEL_S);
> + if (host->top_base) {
> + setbits_le32(&host->top_base->emmc_top_control,
> + PAD_DAT_RD_RXDLY_SEL);
> + clrbits_le32(&host->top_base->emmc_top_control,
> + DATA_K_VALUE_SEL);
> + setbits_le32(&host->top_base->emmc_top_cmd,
> + PAD_CMD_RD_RXDLY_SEL);
> + } else {
> + setbits_le32(tune_reg,
> + MSDC_PAD_TUNE_RD_SEL |
> MSDC_PAD_TUNE_CMD_SEL);
> + clrsetbits_le32(&host->base->patch_bit0,
> + MSDC_INT_DAT_LATCH_CK_SEL_M,
> + host->latch_ck <<
> + MSDC_INT_DAT_LATCH_CK_SEL_S);
> + }
> } else {
> /* choose clock tune */
> - setbits_le32(tune_reg, MSDC_PAD_TUNE_RXDLYSEL);
> + if (host->top_base)
> + setbits_le32(&host->top_base->emmc_top_control,
> + PAD_RXDLY_SEL);
> + else
> + setbits_le32(tune_reg, MSDC_PAD_TUNE_RXDLYSEL);
> }
>
> if (host->dev_comp->builtin_pad_ctrl) {
> @@ -1604,12 +1627,6 @@ static void msdc_init_hw(struct msdc_host *host)
> clrsetbits_le32(&host->base->sdc_cfg, SDC_CFG_DTOC_M,
> 3 << SDC_CFG_DTOC_S);
>
> - if (host->dev_comp->stop_clk_fix) {
> - clrbits_le32(&host->base->sdc_fifo_cfg,
> - SDC_FIFO_CFG_WRVALIDSEL);
> - clrbits_le32(&host->base->sdc_fifo_cfg,
> - SDC_FIFO_CFG_RDVALIDSEL);
> - }
>
> host->def_tune_para.iocon = readl(&host->base->msdc_iocon);
> host->def_tune_para.pad_tune = readl(&host->base->pad_tune);
> @@ -1792,6 +1809,25 @@ static const struct msdc_compatible mt7623_compat = {
> .enhance_rx = false
> };
>
> +static const struct msdc_compatible mt7986_compat = {
> + .clk_div_bits = 12,
> + .pad_tune0 = true,
> + .async_fifo = true,
> + .data_tune = true,
> + .busy_check = true,
> + .stop_clk_fix = true,
> + .enhance_rx = true,
> +};
> +
> +static const struct msdc_compatible mt7981_compat = {
> + .clk_div_bits = 12,
> + .pad_tune0 = true,
> + .async_fifo = true,
> + .data_tune = true,
> + .busy_check = true,
> + .stop_clk_fix = true,
> +};
> +
>
RE: [PATCH v3 3/3] mmc: fsl_esdhc_spl: Add support for builds without CONFIG_SYS_MMC_U_BOOT_OFFS
Hi,
> -Original Message-
> From: Pali Rohar [mailto:p...@kernel.org]
> Sent: Saturday, August 6, 2022 5:10 AM
> To: Jaehoon Chung; Peng Fan; Marek Behun
> Cc: Sinan Akman; u-boot@lists.denx.de
> Subject: [PATCH v3 3/3] mmc: fsl_esdhc_spl: Add support for builds without
> CONFIG_SYS_MMC_U_BOOT_OFFS
>
> When fixed offset via CONFIG_SYS_MMC_U_BOOT_OFFS is not specified then
> expects that U-Boot proper is placed immediately after SPL without any
> additional padding.
>
> This allows to generate smaller SPL+U-Boot final binary as it is not
> required to specify fixed offset to U-Boot proper at SPL compile time.
>
> In this case offset to U-Boot proper is calculated at SPL compile time in
> linker script.
>
> Signed-off-by: Pali Rohar
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> arch/powerpc/cpu/mpc85xx/u-boot-spl.lds | 10 ++
> drivers/mmc/fsl_esdhc_spl.c | 8
> 2 files changed, 18 insertions(+)
>
> diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
> b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
> index 89df4b5f6f07..f775f6bc4d06 100644
> --- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
> +++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
> @@ -62,6 +62,13 @@ SECTIONS
> __init_begin = .;
> __init_end = .;
> _end = .;
> +
> +#ifdef CONFIG_SYS_MPC85XX_NO_RESETVEC
> +#if defined(CONFIG_SDCARD) && !defined(CONFIG_SYS_MMC_U_BOOT_OFFS)
> + mmc_u_boot_offs = .;
> +#endif
> +#endif
> +
> #ifdef CONFIG_SPL_SKIP_RELOCATE
> . = ALIGN(4);
> __bss_start = .;
> @@ -94,6 +101,9 @@ SECTIONS
> .resetvec IMAGE_TEXT_BASE + RESET_VECTOR_OFFSET : {
> KEEP(*(.resetvec))
> } = 0x
> +#if defined(CONFIG_SDCARD) && !defined(CONFIG_SYS_MMC_U_BOOT_OFFS)
> + mmc_u_boot_offs = .;
> +#endif
> #endif
>
> #ifndef CONFIG_SPL_SKIP_RELOCATE
> diff --git a/drivers/mmc/fsl_esdhc_spl.c b/drivers/mmc/fsl_esdhc_spl.c
> index dd6d5fa81ea6..aa00d7e2014d 100644
> --- a/drivers/mmc/fsl_esdhc_spl.c
> +++ b/drivers/mmc/fsl_esdhc_spl.c
> @@ -9,6 +9,10 @@
> #include
> #include
>
> +#ifndef CONFIG_SYS_MMC_U_BOOT_OFFS
> +extern uchar mmc_u_boot_offs[];
> +#endif
> +
> /*
> * The environment variables are written to just after the u-boot image
> * on SDCard, so we must read the MBR to get the start address and code
> @@ -149,7 +153,11 @@ again:
> val = *(tmp_buf + blk_off + ESDHC_BOOT_IMAGE_ADDR + i);
> offset = (offset << 8) + val;
> }
> +#ifndef CONFIG_SYS_MMC_U_BOOT_OFFS
> + offset += (ulong)&mmc_u_boot_offs - CONFIG_SPL_TEXT_BASE;
> +#else
> offset += CONFIG_SYS_MMC_U_BOOT_OFFS;
> +#endif
> #endif
> /*
> * Load U-Boot image from mmc into RAM
> --
> 2.20.1
RE: [v4 00/12] Add ASPEED SPI controller driver
Hi Jagan, > -Original Message- > From: Jagan Teki > Sent: Friday, July 1, 2022 7:57 PM > To: Chin-Ting Kuo > Subject: Re: [v4 00/12] Add ASPEED SPI controller driver > > On Tue, May 24, 2022 at 11:27 AM Chin-Ting Kuo > wrote: > > > > This patch series aims to porting ASPEED FMC/SPI memory controller > > driver with spi-mem interface. spi-mem dirmap framework is also > > synchronized from Linux. These patches have been verified on both > > AST2600 and AST2500 EVBs. > > > > Changes in v2: > > - Separate defconfig files from the SPI driver patch. > > - Use "if (CONFIG_IS_ENABLED(SPI_DIRMAP))" to wrap > > spi_dirmap related functions. > > - Add Winbond w25q512jv flash ID. > > > > Changes in v3: > > - Get AHB bus clock frequency from the function parameter. > > - Fix a grammatical error in spi-mem.h. > > > > Changes in v4: > > - Fix bug when SPI_NOR_4B_OPCODES flag is set. > > > > Chin-Ting Kuo (12): > > clk: aspeed: Get HCLK frequency support > > pinctrl: aspeed: FWSPICS1 and SPI1CS1 pin support > > spi: aspeed: Add ASPEED SPI controller driver > > configs: aspeed: Enable SPI flash features > > MAINTAINERS: Add ASPEED SPI driver file > > arm: dts: aspeed: Update SPI flash node settings > > spi-mem: Add dirmap API from Linux > > mtd: spi-nor: Use spi-mem dirmap API > > spi: aspeed: SPI dirmap read support > > configs: aspeed: Enable CONFIG_SPI_DIRMAP > > mtd: spi-nor-ids: Add Winbond W25Q512JV ID > > spi: aspeed: Fix bug when SPI_NOR_4B_OPCODES flag is set > > Sperate series for spi changes would really make it easier for review. > please send it. > The patches in this series depend on each other. Patch with higher number relies on the one with lower number. Thus, I think they cannot be separated into different series. Chin-Ting > Jagan.
RE: [v4 05/12] MAINTAINERS: Add ASPEED SPI driver file
Hi Jagan, > -Original Message- > From: Jagan Teki > Sent: Friday, July 1, 2022 7:53 PM > To: Chin-Ting Kuo > Subject: Re: [v4 05/12] MAINTAINERS: Add ASPEED SPI driver file > > On Tue, May 24, 2022 at 11:28 AM Chin-Ting Kuo > wrote: > > > > Add spi-aspeed.c file for ARM ASPEED. > > > > Signed-off-by: Chin-Ting Kuo > > --- > > MAINTAINERS | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS index 56be0bfad0..f2cd707eda > > 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -688,6 +688,13 @@ S: Maintained > > F: drivers/pci/pcie_phytium.c > > F: arch/arm/dts/phytium-durian.dts > > > > +ASPEED FMC SPI DRIVER > > +M: Chin-Ting Kuo > > +M: Cédric Le Goater > > +R: Aspeed BMC SW team > > +S: Maintained > > +F: drivers/spi/spi-aspeed.c > > Squash this part of spi-aspeed.c driver patch Okay and will be updated in the next patch version. Chin-Ting
RE: [v4 07/12] spi-mem: Add dirmap API from Linux
Hi Jagan,
> -Original Message-
> From: Jagan Teki
> Sent: Friday, July 1, 2022 8:05 PM
> To: Chin-Ting Kuo
> Subject: Re: [v4 07/12] spi-mem: Add dirmap API from Linux
>
> On Tue, May 24, 2022 at 11:28 AM Chin-Ting Kuo
> wrote:
> >
> > This adds the dirmap API originally introduced in Linux commit aa167f3
> > ("spi: spi-mem: Add a new API to support direct mapping"). This also
> > includes several follow-up patches and fixes.
> >
> > Changes from Linux include:
> > * Added Kconfig option
> > * Changed struct device to struct udevice
> > * Changed struct spi_mem to struct spi_slave
> >
> > This patch is obtained from the following patch
> > https://patchwork.ozlabs.org/project/uboot/patch/20210205043924.149504
> > -3-sean...@gmail.com/
> >
> > Signed-off-by: Chin-Ting Kuo
> > Signed-off-by: Sean Anderson
> > Acked-by: Pratyush Yadav
> > ---
> > v2: Remove "#if CONFIG_SPI_DIRMAP" compile wrapper.
> > v3: Fix a grammatical error in spi-mem.h.
> >
> > drivers/spi/Kconfig | 10 ++
> > drivers/spi/spi-mem.c | 268
> ++
> > include/spi-mem.h | 79 +
> > 3 files changed, 357 insertions(+)
> >
> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index
> > a616294910..297253714a 100644
> > --- a/drivers/spi/Kconfig
> > +++ b/drivers/spi/Kconfig
> > @@ -40,6 +40,16 @@ config SPI_MEM
> > This extension is meant to simplify interaction with SPI
> memories
> > by providing an high-level interface to send memory-like
> commands.
> >
> > +config SPI_DIRMAP
>
> Look like the following code is not part of this if construct, we need that to
> build only when SPI_DIRMAP is defined otherwise it footprint increase for
> non-DIRMAPs. Also please take care of unnecessary code while copying from
> Linux and add SHA1 in the commit message.
>
Okay and I will take care the footprint for non-DITMAPs.
Chin-Ting
> Jagan.
Please pull u-boot-dm
Hi Tom, I've dropped the setuptools patch and will look at it later. https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/13113 The following changes since commit 3dd4e916324efc825a7ee8e412f5cf1ded839021: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2022-08-09 08:16:14 -0400) are available in the Git repository at: git://git.denx.de/u-boot-dm.git tags/dm-pull-9aug22-take2 for you to fetch changes up to be43a35bff17550fa707795a06eaed6114eb1742: boot: allow bootmeth-distro without CONFIG_NET (2022-08-10 13:42:56 -0600) dtoc fixes with pylint, tests John Keeping (1): boot: allow bootmeth-distro without CONFIG_NET Simon Glass (6): dtoc: Tidy up fdt_tests RunTestCoverage() args dtoc: Tidy up fdt_tests RunTests() dtoc: Fix fdt test coverage dtoc: Move main program into its own function test_fdt: Convert to use argparse dtoc: Correct remaining pylint problems in test_fdt boot/Kconfig | 8 +- boot/Makefile | 3 +- boot/pxe_utils.c | 3 +- cmd/Kconfig| 4 +- include/command.h | 2 +- scripts/pylint.base| 2 +- tools/dtoc/test_fdt.py | 326 + 7 files changed, 197 insertions(+), 151 deletions(-) Regards, Simon
Re: [PATCH v3] common: Drop display_options.h from common header
On Sun, Jul 31, 2022 at 12:28:48PM -0600, Simon Glass wrote: > Move this out of the common header and include it only where needed. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Makefile: Correct the rule removing old of-platdata files
On Wed, Aug 03, 2022 at 12:08:29PM -0600, Simon Glass wrote:
> This makes use of makefile variables that don't exist anymore. Fix it and
> also remove the object files in that directory.
>
> Also add FORCE as a dependency as required by the if_changed macro.
>
> Fixes 354d2324635 ("Makefile: Remove old of-platdata files before
> regenerating")
> Reported-by: Heinrich Schuchardt
> Signed-off-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] lmb: Fix LMB_MEMORY_REGIONS flag usage
On Tue, Aug 02, 2022 at 10:21:35AM +0200, Patrice Chotard wrote:
> This patch is fixing a broken boot observed on stm32mp157c-dk2 board.
>
> IS_ENABLED macro should be used to check if a compilation flag is set
> to "y" or "m".
> LMB_MEMORY_REGIONS is set to a numerical value, IS_ENABLED macro is not
> suitable in this case.
>
> Fixes: 7c1860fce4e3 ("lmb: Fix lmb property's defination under struct lmb")
> Signed-off-by: Patrice Chotard
> Acked-by: Michal Simek
> Reviewed-by: Tom Rini
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v5 1/1] test: Add some tests for kconfig.h
On Mon, Aug 01, 2022 at 07:57:59AM -0600, Simon Glass wrote: > The macros in this file are a little confusing and we currently have no > tests to check that they work as expected. > > Add some tests which check the macros in C code. Add a few tests which > check that the build errors are generated correctly too, using buildman's > -a option. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] cmd: inconsistent return type of command_process()
On Mon, Aug 01, 2022 at 03:17:49PM +0200, Heinrich Schuchardt wrote: > The declarations in the header and in the implementation must match. > > Reported-by: Sergei Antonov > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] power: regulator: Remove i2c header from gpio regulator
On Mon, Aug 01, 2022 at 02:19:06PM +0200, Michal Simek wrote: > i2c is not used that's why header is not needed. > > Signed-off-by: Michal Simek Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] Makefile: avoid false positive -Wmaybe-uninitialized
On Sun, Jul 31, 2022 at 10:06:13AM +0200, Heinrich Schuchardt wrote: > When compiling with -Og gcc reports false positive -Wmaybe-uninitialized as > reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394. > > Silence these warnings when building with CONFIG_CC_OPTIMIZE_FOR_DEBUG. > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] scripts/config: pick config script from kernel scripts
On Wed, Jul 27, 2022 at 07:09:20PM +0200, Milan P. Stanić wrote: > pulled from kernel tag v5.18 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] lz4: Fix compile warning comparison of distinct pointer types
On Wed, Jul 27, 2022 at 05:24:23PM +0200, Pali Rohár wrote: > In file included from include/linux/bitops.h:22, > from include/log.h:15, > from include/linux/printk.h:4, > from include/common.h:20, > from lib/lz4_wrapper.c:6: > lib/lz4_wrapper.c: In function ‘ulz4fn’: > include/linux/kernel.h:184:17: warning: comparison of distinct pointer types > lacks a cast > (void) (&_min1 == &_min2); \ > ^~ > lib/lz4_wrapper.c:104:18: note: in expansion of macro ‘min’ > size_t size = min((ptrdiff_t)block_size, end - out); > ^~~ > > Signed-off-by: Pali Rohár Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS: Update e-mail address
On Sun, Jul 24, 2022 at 05:13:34PM +0200, Joao Marcos Costa wrote: > Replace former professional address by my personal e-mail. > > Signed-off-by: Joao Marcos Costa Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] mmc: Do not send status of send_status is false
On Fri, Jul 15, 2022 at 01:58:24AM +0200, Marek Vasut wrote:
> Commit 44645f87de5 ("mmc: Fix mmc_switch excessive timeout") introduced
> a side effect where CMD13 SEND_STATUS is issued in case mmc_wait_dat0()
> does not return -ENOSYS and $send_status is not set. This happens on all
> hardware which does implement .mmc_wait_dat0 callback, e.g. i.MX8M .
>
> This leads to lengthy timeout before booting OS in case of eMMC in one
> of the HS200/HS400 modes, since the card cannot respond to CMD13 while
> downgrading from HS200/HS400 to regular HS mode.
>
> Fix this by adding the missing conditional.
>
> Fixes: 44645f87de5 ("mmc: Fix mmc_switch excessive timeout")
> Signed-off-by: Marek Vasut
> Cc: Jaehoon Chung
> Cc: Kirill Kapranov
> Cc: Marek Behún
> Cc: Pantelis Antoniou
> Cc: Ye Li
> Reviewed-by: Jaehoon Chung
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 1/1] usb: storage: continue probe on "Invalid device"
On Wed, 10 Aug 2022 at 13:54, Janne Grunau wrote: > > Fixes a crash during probing of sd card readers without medium present. > > Link: https://github.com/AsahiLinux/linux/issues/44 > Link: https://lists.denx.de/pipermail/u-boot/2022-July/489717.html > Signed-off-by: Janne Grunau > --- > Changes since v1: > - changed unconditiona return to "continue" as proposed by AKASHI Takahiro > > common/usb_storage.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Simon Glass > > diff --git a/common/usb_storage.c b/common/usb_storage.c > index eaa31374ef73..f9204552a683 100644 > --- a/common/usb_storage.c > +++ b/common/usb_storage.c > @@ -239,6 +239,7 @@ static int usb_stor_probe_device(struct usb_device *udev) > ret = device_unbind(dev); > if (ret) > return ret; > + continue; > } > > ret = blk_probe_or_unbind(dev); > -- > 2.35.1 >
Re: [PATCH v2 01/10] binman: Skip elf tests if python elftools is not available
Hi Stefan, On Tue, 9 Aug 2022 at 13:51, Simon Glass wrote: > > On Mon, 8 Aug 2022 at 04:51, Stefan Herbrechtsmeier > wrote: > > > > From: Stefan Herbrechtsmeier > > > > Skip tests which requires python elftools if the tool is not available. > > > > Signed-off-by: Stefan Herbrechtsmeier > > > > > > --- > > > > Changes in v2: > > - Added > > > > tools/binman/elf_test.py | 14 ++ > > tools/binman/ftest.py| 18 ++ > > 2 files changed, 32 insertions(+) > > Reviewed-by: Simon Glass The rest of this series is going to need more investigation and thought on my part. I will come back to you by the end of next week. Regards, SImon
Re: [PATCH] arm: mvebu: mbus: Fix mbus driver to work also after U-Boot relocation
Hi Pali,
On 11/08/22 00:46, Pali Rohár wrote:
> mbus driver is initialized from arch_cpu_init() callback which is called
> before relocation. This driver stores lot of functions and structure
> pointers into global variables, so it is data position dependent.
>
> Therefore after relocations all pointers are invalid and driver does not
> work anymore as all pointers referes to the old memory, which overlaps with
> CONFIG_SYS_LOAD_ADDR and ${loadaddr}.
>
> For example U-Boot fuse command crashes if loadaddr memory is cleared or
> rewritten by some image loaded by U-Boot load command.
>
>mw.w ${loadaddr} 0x0 1
>fuse read 0 1 2
>
> Fix this issue by removing of all mbus global variables in which are stored
> pointers to structures or functions which changes during relocation. And
> replace it by direct function calls (not via pointers). With this change
> fuse command finally works.
>
> Signed-off-by: Pali Rohár
Reviewed-by: Chris Packham
> ---
> arch/arm/mach-kirkwood/include/mach/cpu.h | 3 -
> arch/arm/mach-mvebu/include/mach/cpu.h| 3 -
> arch/arm/mach-mvebu/mbus.c| 167 +-
> board/alliedtelesis/x530/x530.c | 2 +-
> board/maxbcm/maxbcm.c | 8 +-
> board/theadorable/theadorable.c | 4 +-
> include/linux/mbus.h | 13 +-
> 7 files changed, 75 insertions(+), 125 deletions(-)
>
> diff --git a/arch/arm/mach-kirkwood/include/mach/cpu.h
> b/arch/arm/mach-kirkwood/include/mach/cpu.h
> index 71c546f9acf6..d8639c60352b 100644
> --- a/arch/arm/mach-kirkwood/include/mach/cpu.h
> +++ b/arch/arm/mach-kirkwood/include/mach/cpu.h
> @@ -144,9 +144,6 @@ struct kwgpio_registers {
> u32 irq_level;
> };
>
> -/* Needed for dynamic (board-specific) mbus configuration */
> -extern struct mvebu_mbus_state mbus_state;
> -
> /*
>* functions
>*/
> diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> b/arch/arm/mach-mvebu/include/mach/cpu.h
> index 689c96bd4eac..d9fa1f32aa52 100644
> --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> @@ -122,9 +122,6 @@ struct sar_freq_modes {
> u32 d_clk;
> };
>
> -/* Needed for dynamic (board-specific) mbus configuration */
> -extern struct mvebu_mbus_state mbus_state;
> -
> /*
>* functions
>*/
> diff --git a/arch/arm/mach-mvebu/mbus.c b/arch/arm/mach-mvebu/mbus.c
> index 3b1b9f73ebf6..7092f6cc10c2 100644
> --- a/arch/arm/mach-mvebu/mbus.c
> +++ b/arch/arm/mach-mvebu/mbus.c
> @@ -88,31 +88,34 @@
>
> #define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
>
> -struct mvebu_mbus_state;
> -
> -struct mvebu_mbus_soc_data {
> - unsigned int num_wins;
> - unsigned int num_remappable_wins;
> - unsigned int (*win_cfg_offset)(const int win);
> - void (*setup_cpu_target)(struct mvebu_mbus_state *s);
> -};
> -
> -struct mvebu_mbus_state mbus_state
> - __section(".data");
> static struct mbus_dram_target_info mbus_dram_info
> __section(".data");
>
> +#if defined(CONFIG_ARCH_MVEBU)
> + #define MVEBU_MBUS_NUM_WINS 20
> + #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 8
> + #define MVEBU_MBUS_WIN_CFG_OFFSET(win)
> armada_370_xp_mbus_win_offset(win)
> +#elif defined(CONFIG_ARCH_KIRKWOOD)
> + #define MVEBU_MBUS_NUM_WINS 8
> + #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 4
> + #define MVEBU_MBUS_WIN_CFG_OFFSET(win) orion5x_mbus_win_offset(win)
> +#else
> + #error "No supported architecture"
> +#endif
> +
> +static unsigned int armada_370_xp_mbus_win_offset(int win);
> +static unsigned int orion5x_mbus_win_offset(int win);
> +
> /*
>* Functions to manipulate the address decoding windows
>*/
>
> -static void mvebu_mbus_read_window(struct mvebu_mbus_state *mbus,
> -int win, int *enabled, u64 *base,
> +static void mvebu_mbus_read_window(int win, int *enabled, u64 *base,
> u32 *size, u8 *target, u8 *attr,
> u64 *remap)
> {
> - void __iomem *addr = mbus->mbuswins_base +
> - mbus->soc->win_cfg_offset(win);
> + void __iomem *addr = (void __iomem *)MVEBU_CPU_WIN_BASE +
> + MVEBU_MBUS_WIN_CFG_OFFSET(win);
> u32 basereg = readl(addr + WIN_BASE_OFF);
> u32 ctrlreg = readl(addr + WIN_CTRL_OFF);
>
> @@ -133,7 +136,7 @@ static void mvebu_mbus_read_window(struct
> mvebu_mbus_state *mbus,
> *attr = (ctrlreg & WIN_CTRL_ATTR_MASK) >> WIN_CTRL_ATTR_SHIFT;
>
> if (remap) {
> - if (win < mbus->soc->num_remappable_wins) {
> + if (win < MVEBU_MBUS_NUM_REMAPPABLE_WINS) {
> u32 remap_low = readl(addr + WIN_REMAP_LO_OFF);
> u32 remap_hi = readl(addr + WIN_REMAP_HI_OFF);
> *remap = ((u64)remap_hi << 32) | remap_low;
> @@ -143,27 +146,25 @@ static void mvebu_mbus_read_window(struct
> mvebu_mbus_state *mbus,
>
[PATCH v2 1/1] usb: storage: continue probe on "Invalid device"
Fixes a crash during probing of sd card readers without medium present. Link: https://github.com/AsahiLinux/linux/issues/44 Link: https://lists.denx.de/pipermail/u-boot/2022-July/489717.html Signed-off-by: Janne Grunau --- Changes since v1: - changed unconditiona return to "continue" as proposed by AKASHI Takahiro common/usb_storage.c | 1 + 1 file changed, 1 insertion(+) diff --git a/common/usb_storage.c b/common/usb_storage.c index eaa31374ef73..f9204552a683 100644 --- a/common/usb_storage.c +++ b/common/usb_storage.c @@ -239,6 +239,7 @@ static int usb_stor_probe_device(struct usb_device *udev) ret = device_unbind(dev); if (ret) return ret; + continue; } ret = blk_probe_or_unbind(dev); -- 2.35.1
Re: [PATCH] arm: mvebu: turris_mox: Set "sfp" label in eth1 DT node when only Mox SFP is detected
On Wed, 10 Aug 2022 12:54:11 +0200 Pali Rohár wrote: > When Mox SFP module is connected after Topaz or Peridot module then port DT > node already contains "sfp" label. But Mox SFP module can be connected also > without Topaz or Peridot module in which case it is connected directly into > he eth1 DT node, which is without any label. So add "sfp" label into eth1 > DT node in this case. > > Signed-off-by: Pali Rohár Reviewed-by: Marek Behún
Re: default environment append from kconfig
Hi Tom, On Wed, 10 Aug 2022 at 08:36, Tom Rini wrote: > > On Tue, Aug 09, 2022 at 01:02:24PM +0200, Rasmus Villemoes wrote: > > On 09/08/2022 12.47, Francesco Dolcini wrote: > > > Hello all, > > > is there any kconfig mechanism in u-boot to append environment variable > > > to the > > > default one? > > > > > > > Well, despite the name, CONFIG_EXTRA_ENV_SETTINGS is not settable via > > kconfig, but only from board header file. And while it works, it's > > rather cumbersome to maintain that macro expanding to a string with all > > the embedded \0 and the required \ continuations etc. > > I just want to chime in here to note that the biggest blocker to > removing CONFIG_EXTRA_ENV_SETTINGS and migrating it to board.env files > is how to handle, exactly, distroboot support. Aside from that, I will get back to that before long. > whatever is done in CONFIG_EXTRA_ENV_SETTINGS can be done in the .env > file (unless there's some other fancy macro work being done that I've > missed). > > -- > Tom Regards, SImon
Re: [PATCH] arm: mvebu: turris_omnia: Show MCU version
On Wed, 10 Aug 2022 11:00:25 +0200 Pali Rohár wrote: > +static const char * const omnia_get_mcu_version(void) why the second const? Marek
Re: default environment append from kconfig
On Wed, Aug 10, 2022 at 05:09:45PM +0200, Francesco Dolcini wrote: > On Wed, Aug 10, 2022 at 10:34:26AM -0400, Tom Rini wrote: > > On Tue, Aug 09, 2022 at 12:47:39PM +0200, Francesco Dolcini wrote: > > > Hello all, > > > is there any kconfig mechanism in u-boot to append environment variable > > > to the > > > default one? > > > > > > I am aware of CONFIG_USE_DEFAULT_ENV_FILE, but this will completely > > > replace it, looking into the code I was not able to find anything, but I > > > wonder if something from this > > > https://lore.kernel.org/all/20211022030852.1986718-1-...@chromium.org/ > > > can be used. > > > > Yes, you can use the series above, which has been merged for some time, > > to append to the environment via board/..//.env and you > > can look at the existing .env files for examples of how it works. > Am I wrong or this just override the whole environment? My need here is > to just add|override some env variables to the default env to an in-tree > u-boot board from an out-of-tree configuration. > > Think about a specific network or boot configuration, for example. It doesn't override the whole environment. As of the link you posted, it did override all of (or rather, conflicted with) CONFIG_EXTRA_ENV_SETTINGS, but I changed that more recently as it was hindering adoption of the feature overall. -- Tom signature.asc Description: PGP signature
Re: ethernet dt aliases implications in U-Boot and Linux
On Wed, Aug 10, 2022 at 05:17:56PM +0200, Andrew Lunn wrote: > > > I guess you are new to the netdev list :-) > > > > > > This is one of those FAQ sort of things, discussed every > > > year. Anything like this is always NACKed. I don't see why this time > > > should be any different. > > > > > > DSA is somewhat special because it is very old. It comes from before > > > the times of DT. Its DT binding was proposed relatively earl in DT > > > times, and would be rejected in modern days. But the rules of ABI mean > > > the label property will be valid forever. But i very much doubt it > > > will spread to interfaces in general. > > > > And if this is a FAQ maybe you can point to a summary (perhaps in > > previous mail discusssion) that explains how to provide stable interface > > names for Ethernet devices on a DT based platform? > > As far so the kernel is concerned, interface names are unstable. They > have never been truly stable, but they have got more unstable in the > past decade with multiple busses being probed in parallel, which did > not happen before so much. > > > On x86 there is a name derived from the device location in the bus > > topology > > This is nothing to do with x86. That is userspace, e.g. systemd, > renaming the interfaces. This applies for any architecture for which > systemd runs on. > > > which may be somewhat stable but it is not clear that it > > cannot change, and there is an optional BIOS provided table that can > > asssign meaningful names to the interfaces. > > I doubt the kernel is looking at ACPI tables. It is user space which > does that. > > The kernel provides udev with a bunch of information about the > interface, its bus location, MAC address, etc. Userspace can then > decide what it wants to call it, and what its alternative names are, > etc. > > Also, this is not just a network interface name problem. Any device > with a number/letter in it is unstable. I2C bus devices: i2c0, > i2c1... SPI bus deviceS: spi0, spi1..., Thees do have numbered aliases in the DT. I don't know if the kernel uses them for anything. > Block devices, sda, sdb, sdc, These too, at least mmc. Thanks Michal
Re: ethernet dt aliases implications in U-Boot and Linux
> > I guess you are new to the netdev list :-) > > > > This is one of those FAQ sort of things, discussed every > > year. Anything like this is always NACKed. I don't see why this time > > should be any different. > > > > DSA is somewhat special because it is very old. It comes from before > > the times of DT. Its DT binding was proposed relatively earl in DT > > times, and would be rejected in modern days. But the rules of ABI mean > > the label property will be valid forever. But i very much doubt it > > will spread to interfaces in general. > > And if this is a FAQ maybe you can point to a summary (perhaps in > previous mail discusssion) that explains how to provide stable interface > names for Ethernet devices on a DT based platform? As far so the kernel is concerned, interface names are unstable. They have never been truly stable, but they have got more unstable in the past decade with multiple busses being probed in parallel, which did not happen before so much. > On x86 there is a name derived from the device location in the bus > topology This is nothing to do with x86. That is userspace, e.g. systemd, renaming the interfaces. This applies for any architecture for which systemd runs on. > which may be somewhat stable but it is not clear that it > cannot change, and there is an optional BIOS provided table that can > asssign meaningful names to the interfaces. I doubt the kernel is looking at ACPI tables. It is user space which does that. The kernel provides udev with a bunch of information about the interface, its bus location, MAC address, etc. Userspace can then decide what it wants to call it, and what its alternative names are, etc. Also, this is not just a network interface name problem. Any device with a number/letter in it is unstable. I2C bus devices: i2c0, i2c1... SPI bus deviceS: spi0, spi1..., Block devices, sda, sdb, sdc, TPM device, tpm0, tpm1. Nothing is stable in the kernel. Andrew
Re: Please pull u-boot-dm
On Tue, Aug 09, 2022 at 04:51:19PM -0600, Simon Glass wrote: > Hi Tom, > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/13097 > > > The following changes since commit 3dd4e916324efc825a7ee8e412f5cf1ded839021: > > Merge https://source.denx.de/u-boot/custodians/u-boot-marvell > (2022-08-09 08:16:14 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-pull-9aug22 > > for you to fetch changes up to 6dbca84cc9420a327ccb67719afac976237a9490: > > boot: allow bootmeth-distro without CONFIG_NET (2022-08-09 11:55:41 -0600) > OK, I know I had said yesterday that we could take the fdt series to start updating to setuptools as-is, but now I'm looking harder (and saw in my local HW testing this time) and see: https://source.denx.de/u-boot/u-boot/-/jobs/481502#L1738 on basically every board, when building on something older that doesn't complain about our previous setup.py stuff. So we need to get this solved all the way. -- Tom signature.asc Description: PGP signature
Re: default environment append from kconfig
On Tue, Aug 09, 2022 at 01:02:24PM +0200, Rasmus Villemoes wrote: > On 09/08/2022 12.47, Francesco Dolcini wrote: > > Hello all, > > is there any kconfig mechanism in u-boot to append environment variable to > > the > > default one? > > > > Well, despite the name, CONFIG_EXTRA_ENV_SETTINGS is not settable via > kconfig, but only from board header file. And while it works, it's > rather cumbersome to maintain that macro expanding to a string with all > the embedded \0 and the required \ continuations etc. I just want to chime in here to note that the biggest blocker to removing CONFIG_EXTRA_ENV_SETTINGS and migrating it to board.env files is how to handle, exactly, distroboot support. Aside from that, whatever is done in CONFIG_EXTRA_ENV_SETTINGS can be done in the .env file (unless there's some other fancy macro work being done that I've missed). -- Tom signature.asc Description: PGP signature
Re: default environment append from kconfig
On Tue, Aug 09, 2022 at 12:47:39PM +0200, Francesco Dolcini wrote: > Hello all, > is there any kconfig mechanism in u-boot to append environment variable to the > default one? > > I am aware of CONFIG_USE_DEFAULT_ENV_FILE, but this will completely > replace it, looking into the code I was not able to find anything, but I > wonder if something from this > https://lore.kernel.org/all/20211022030852.1986718-1-...@chromium.org/ > can be used. Yes, you can use the series above, which has been merged for some time, to append to the environment via board/..//.env and you can look at the existing .env files for examples of how it works. -- Tom signature.asc Description: PGP signature
[PATCH 1/2] Convert CONFIG_SYS_I2C_EEPROM_CCID et al to Kconfig
This converts the following to Kconfig: CONFIG_SYS_I2C_EEPROM_CCID CONFIG_SYS_I2C_EEPROM_NXID CONFIG_SYS_EEPROM_BUS_NUM Signed-off-by: Tom Rini --- common/Kconfig| 21 +++ configs/MPC8548CDS_36BIT_defconfig| 1 + configs/MPC8548CDS_defconfig | 1 + configs/MPC8548CDS_legacy_defconfig | 1 + configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 1 + configs/ls1021atwr_nor_defconfig | 1 + configs/ls1021atwr_nor_lpuart_defconfig | 1 + configs/ls1021atwr_qspi_defconfig | 1 + ...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 1 + configs/ls1021atwr_sdcard_ifc_defconfig | 1 + configs/ls1021atwr_sdcard_qspi_defconfig | 1 + include/configs/MPC8548CDS.h | 3 --- include/configs/P1010RDB.h| 4 include/configs/P2041RDB.h| 4 include/configs/T102xRDB.h| 4 include/configs/T208xQDS.h| 4 include/configs/T208xRDB.h| 4 include/configs/corenet_ds.h | 4 include/configs/ls1012aqds.h | 4 include/configs/ls1021aiot.h | 4 include/configs/ls1021aqds.h | 4 include/configs/ls1021atsn.h | 4 include/configs/ls1021atwr.h | 4 include/configs/ls1028a_common.h | 4 include/configs/ls1043aqds.h | 4 include/configs/ls1043ardb.h | 6 -- include/configs/ls1046afrwy.h | 2 -- include/configs/ls1046aqds.h | 4 include/configs/ls1046ardb.h | 2 -- include/configs/ls1088aqds.h | 4 include/configs/ls1088ardb.h | 4 include/configs/ls2080aqds.h | 4 include/configs/ls2080ardb.h | 4 include/configs/lx2160a_common.h | 4 include/configs/lx2160aqds.h | 4 include/configs/lx2160ardb.h | 4 include/configs/lx2162aqds.h | 4 include/configs/sifive-unmatched.h| 2 -- 38 files changed, 31 insertions(+), 103 deletions(-) diff --git a/common/Kconfig b/common/Kconfig index e7914ca750a3..2c3f7f4274d2 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -671,6 +671,27 @@ config ID_EEPROM A number of different systems and vendors enable a vendor-specified EEPROM that contains various identifying features. +config SYS_EEPROM_BUS_NUM + int "I2C bus number of the system identifier EEPROM" + depends on ID_EEPROM + default 0 + +choice + prompt "EEPROM starts with 'CCID' or 'NXID'" + depends on ID_EEPROM && (PPC || ARCH_LS1021A || FSL_LAYERSCAPE) + default SYS_I2C_EEPROM_NXID + help + Specify if the Freescale / NXP ID EEPROM starts with 'CCID' or 'NXID' + ASCII literal string. + +config SYS_I2C_EEPROM_CCID + bool "EEPROM starts with 'CCID'" + +config SYS_I2C_EEPROM_NXID + bool "EEPROM starts with 'NXID'" + +endchoice + config PCI_INIT_R bool "Enumerate PCI buses during init" depends on PCI diff --git a/configs/MPC8548CDS_36BIT_defconfig b/configs/MPC8548CDS_36BIT_defconfig index def5d6fdf44b..feb0be5a4949 100644 --- a/configs/MPC8548CDS_36BIT_defconfig +++ b/configs/MPC8548CDS_36BIT_defconfig @@ -21,6 +21,7 @@ CONFIG_USE_BOOTCOMMAND=y CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr" # CONFIG_MISC_INIT_R is not set CONFIG_ID_EEPROM=y +CONFIG_SYS_I2C_EEPROM_CCID=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PBSIZE=276 CONFIG_CMD_IMLS=y diff --git a/configs/MPC8548CDS_defconfig b/configs/MPC8548CDS_defconfig index 881fca912b9b..945347941b41 100644 --- a/configs/MPC8548CDS_defconfig +++ b/configs/MPC8548CDS_defconfig @@ -20,6 +20,7 @@ CONFIG_USE_BOOTCOMMAND=y CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr" # CONFIG_MISC_INIT_R is not set CONFIG_ID_EEPROM=y +CONFIG_SYS_I2C_EEPROM_CCID=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PBSIZE=276 CONFIG_CMD_IMLS=y diff --git a/configs/MPC8548CDS_legacy_defconfig b/configs/MPC8548CDS_legacy_defconfig index 99a63300af90..f069451697dd 100644 --- a/configs/MPC8548CDS_legacy_defconfig +++ b/configs/MPC8548CDS_legacy_defconfig @@ -21,6 +21,7 @@ CONFIG_USE_BOOTCOMMAND=y CONFIG_BOOTCOMMAND="setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr
[PATCH 2/2] Remove CONFIG_SYS_I2C_EEPROM_PAGE_WRITE_BITS et al
This removes the following symbols: CONFIG_SYS_I2C_EEPROM_PAGE_WRITE_BITS CONFIG_SYS_I2C_EEPROM_PAGE_WRITE_DELAY_MS CONFIG_SYS_I2C_LDI_ADDR CONFIG_SYS_I2C_DVI_ADDR CONFIG_SYS_I2C_DVI_BUS_NUM They are unused by any code in tree at this time. Signed-off-by: Tom Rini --- include/configs/T104xRDB.h | 5 - include/configs/tqma6.h| 4 2 files changed, 9 deletions(-) diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h index 7983a71953d4..1a1b813bd4ea 100644 --- a/include/configs/T104xRDB.h +++ b/include/configs/T104xRDB.h @@ -292,11 +292,6 @@ #if defined(CONFIG_TARGET_T1042RDB_PI) || \ defined(CONFIG_TARGET_T1040D4RDB) || \ defined(CONFIG_TARGET_T1042D4RDB) -/* LDI/DVI Encoder for display */ -#define CONFIG_SYS_I2C_LDI_ADDR0x38 -#define CONFIG_SYS_I2C_DVI_ADDR0x75 -#define CONFIG_SYS_I2C_DVI_BUS_NUM 0 - /* * RTC configuration */ diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h index a782e3d02bdb..9498dbeadf41 100644 --- a/include/configs/tqma6.h +++ b/include/configs/tqma6.h @@ -37,10 +37,6 @@ /* I2C Configs */ #define CONFIG_I2C_MULTI_BUS -/* I2C EEPROM (M24C64) */ -#define CONFIG_SYS_I2C_EEPROM_PAGE_WRITE_BITS 5 /* 32 Bytes */ -#define CONFIG_SYS_I2C_EEPROM_PAGE_WRITE_DELAY_MS 20 - #if !defined(CONFIG_DM_PMIC) #define CONFIG_POWER_PFUZE100 #define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08 -- 2.25.1
Re: [PATCH] pci: Sort resources before assignment
Hi Leo,
On Wed, 10 Aug 2022 at 06:58, Leo Yan wrote:
>
> A PCI device can request resource for multiple memory regions, e.g. a
> PCI device tries to allocate prefetchable memory for two regions, one
> region size is 0x1000_ and another is 0x1__. And the PCIe
> controller provides prefetchable memory window size is 0x1_8000_,
> thus in theory the PCIe controller can meet the memory requirement for
> the PCI device:
>
> 0x1_8000_ > 0x1_1000_ (0x1000_ + 0x1__)
>
> When allocate the memory region, pciauto_region_allocate() applies the
> alignment for the start address, we can see the memory regions are
> allocated as:
>
> => pci bar 1.0.0
> ID BaseSizeWidth Type
> --
>0 0x8800 0x0400 32 MEM
>1 0x8c00 0x0010 32 MEM
>2 0x0010 0x1000 64 MEM Prefetchable
>3 0x0011 0x0001 64 MEM Prefetchable
>
> The problem is for the last memory region, we can see its start address
> is 0x11__ and the size is 0x1__, therefore, these two
> memory regions occupy memory size is:
>
> 0x11__ + 0x1__ - 0x10__ = 0x2__
>
> The allocated memory region (0x2__) is out of the range, because
> the maximum space provided by PCI controller is only 0x1_8000_.
>
> To fix this issue, this patch sorts resources with descending, this can
> give the priority for big chunk memory region, the big memory region is
> allocated ahead before a small region, so that its start address does
> not necessarily introduce big hole caused by the alignment, which is
> finished by function pdev_sort_resources().
>
> And we use another function pdev_assign_resources() to set BARs based on
> the sorted list.
>
> As result, we can see the updated memory regions are altered as below;
> the end address is: 0x11__ + 0x1000_, which falls into the
> permitted memory window.
>
> => pci bar 1.0.0
> ID BaseSizeWidth Type
> --
>0 0x8800 0x0400 32 MEM
>1 0x8c00 0x0010 32 MEM
>2 0x0011 0x1000 64 MEM Prefetchable
>3 0x0010 0x0001 64 MEM Prefetchable
>
> Reported-by: Matsumoto Misako
> Signed-off-by: Leo Yan
> ---
> drivers/pci/pci_auto.c | 104 +++--
> 1 file changed, 79 insertions(+), 25 deletions(-)
Pease add a test for this to test/dm/pci.c
>
> diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
> index c7968926a1..69c801fc62 100644
> --- a/drivers/pci/pci_auto.c
> +++ b/drivers/pci/pci_auto.c
> @@ -14,6 +14,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include "pci_internal.h"
>
> /* the user can define CONFIG_SYS_PCI_CACHE_LINE_SIZE to avoid problems */
> @@ -21,6 +23,69 @@
> #define CONFIG_SYS_PCI_CACHE_LINE_SIZE 8
> #endif
>
> +struct pci_dev_resource {
> + struct list_head list;
> + int bar;
> + pci_size_t bar_size;
> + int found_mem64;
> + struct pci_region *bar_res;
> +};
Please add full comments. Should this be named pci_dev_node?
> +
> +/* Sort resources by bar size */
> +static void pdev_sort_resources(struct pci_dev_resource *new,
> + struct list_head *head)
> +{
> + struct pci_dev_resource *dev_res;
> + struct list_head *n;
> +
> + /* Fallback is smallest one or list is empty */
> + n = head;
> + list_for_each_entry(dev_res, head, list) {
> + if (new->bar_size > dev_res->bar_size) {
> + n = &dev_res->list;
> + break;
> + }
> + }
> +
> + /* Insert it just before n */
> + list_add_tail(&new->list, n);
> +}
> +
> +static void pdev_assign_resources(struct udevice *dev, struct list_head
> *head)
> +{
> + struct pci_dev_resource *dev_res;
> + int bar;
> + pci_addr_t bar_value;
> + int ret = 0;
> +
> + list_for_each_entry(dev_res, head, list) {
> + ret = pciauto_region_allocate(dev_res->bar_res,
> dev_res->bar_size,
> + &bar_value,
> dev_res->found_mem64);
> + if (ret)
> + printf("PCI: Failed autoconfig bar %x\n",
> dev_res->bar);
> +
> + bar = dev_res->bar;
> + if (!ret) {
> + /* Write it out and update our limit */
> + dm_pci_write_config32(dev, bar, (u32)bar_value);
> +
> + if (dev_res->found_mem64) {
> + bar += 4;
> + if (IS_ENABLED(CONFIG_SY
Re: [PATCH 3/3] CI: Move to Ubuntu 2022.04 "Jammy" for CI base
On Tue, 9 Aug 2022 at 19:09, Tom Rini wrote: > > - We now have a new enough sbsigntools in the distro, stop building. > - Use the 20220801 tag for Jammy. > - Move to pygit2 1.9.2 (current version) as the old one doesn't build on > "Jammy". > - Add the working directory to the list of safe directories for git. > - Move to pytest 6.2.5 to address other issues. > - This move exposed a number of minor issues in the existing scripts we > used within CI to perform the jobs themselves. The most notable changes > here involve using 'set +e / set -e' to enforce when we should or should > not make non-zero buildman status be a fatal error. > > Signed-off-by: Tom Rini > --- > .azure-pipelines.yml | 14 +++--- > .gitlab-ci.yml | 8 +++- > test/py/requirements.txt | 4 ++-- > tools/docker/Dockerfile | 14 ++ > 4 files changed, 18 insertions(+), 22 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 1/3] CI: Azure: Merge PowerPC jobs in to one
On Tue, 9 Aug 2022 at 19:09, Tom Rini wrote: > > At this point given the number of PowerPC platforms we have, a single > job to build them all fits within the time limit we have in Azure. > > Signed-off-by: Tom Rini > --- > This reduces the overall build time marginally due to freeing up some > parallel build slots. However, it needs the DM_ETH series to be applied > first as that removes a handful of PowerPC platforms and when we do them > all at once we're very close to the maximum run time limit. > --- > .azure-pipelines.yml | 16 ++-- > 1 file changed, 2 insertions(+), 14 deletions(-) Reviewed-by: Simon Glass > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml > index 053f816db59c..4f01598dbb28 100644 > --- a/.azure-pipelines.yml > +++ b/.azure-pipelines.yml > @@ -514,20 +514,8 @@ stages: >BUILDMAN: "m68k" > mips: >BUILDMAN: "mips" > -non_fsl_ppc: > - BUILDMAN: "powerpc -x freescale" > -mpc85xx_freescale: > - BUILDMAN: "mpc85xx&freescale -x t208xrdb -x t102* -x p1_p2_rdb_pc > -x p1010rdb -x corenet_ds -x bsc91*" > -t208xrdb_corenet_ds: > - BUILDMAN: "t208xrdb corenet_ds" > -fsl_ppc: > - BUILDMAN: "mpc83xx&freescale" > -t102x: > - BUILDMAN: "t102*" > -p1_p2_rdb_pc: > - BUILDMAN: "p1_p2_rdb_pc" > -p1010rdb_bsc91: > - BUILDMAN: "p1010rdb bsc91" > +powerpc: > + BUILDMAN: "powerpc" > siemens: >BUILDMAN: "siemens" > tegra: > -- > 2.25.1 >
Re: [PATCH 2/3] CI: Azure: Further condense jobs
On Tue, 9 Aug 2022 at 19:09, Tom Rini wrote: > > We have a maximum of 10 parallel build jobs, and each job must complete > in less than 60 minutes. The overall run time must also be less than 6 > hours. Condense a number of jobs so that we have less potential > bottlenecks in terms of waiting for a parallel slot to open up for a job > to be run. > > Signed-off-by: Tom Rini > --- > .azure-pipelines.yml | 125 +-- > 1 file changed, 37 insertions(+), 88 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 2/2] patman: Add documentation to doc/
Hi Heinrich,
On Wed, 10 Aug 2022 at 00:47, Heinrich Schuchardt wrote:
>
> On 8/9/22 21:49, Simon Glass wrote:
> > Link to patman's documentation from the doc/ directory so that it appears
> > in the 'make htmldocs' output.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > Changes in v2:
> > - Fix up access to help from patman tool
> >
> > doc/develop/index.rst | 1 +
> > doc/develop/patman.rst | 1 +
> > doc/develop/sending_patches.rst | 16 +
> > tools/patman/README.rst | 1 +
> > tools/patman/main.py| 3 +-
> > tools/patman/{README => patman.rst} | 526 ++--
> > 6 files changed, 287 insertions(+), 261 deletions(-)
> > create mode 12 doc/develop/patman.rst
> > create mode 100644 doc/develop/sending_patches.rst
> > create mode 12 tools/patman/README.rst
> > rename tools/patman/{README => patman.rst} (52%)
> >
> > diff --git a/doc/develop/index.rst b/doc/develop/index.rst
> > index 7c41e3f1b6e..7476f9ca0eb 100644
> > --- a/doc/develop/index.rst
> > +++ b/doc/develop/index.rst
> > @@ -14,6 +14,7 @@ General
> > process
> > release_cycle
> > system_configuration
> > + sending_patcheshis
> >
> > Implementation
> > --
> > diff --git a/doc/develop/patman.rst b/doc/develop/patman.rst
> > new file mode 12
> > index 000..0fcb7d61d40
> > --- /dev/null
> > +++ b/doc/develop/patman.rst
> > @@ -0,0 +1 @@
> > +../../tools/patman/patman.rst
> > \ No newline at end of file
> > diff --git a/doc/develop/sending_patches.rst
> > b/doc/develop/sending_patches.rst
> > new file mode 100644
> > index 000..0542adeaed9
> > --- /dev/null
> > +++ b/doc/develop/sending_patches.rst
>
> Thanks for moving this to the HTML documentation.
>
> This files contains numerous formatting errors which are not covered by
> your diff. It is worthwhile to look at the output of 'make htmldocs'.
Yes that's how I found the problems, but clearly not all of them and I
have not bothered with the bash code-block thing. I will start using
it more.
>
> May I apply the following when merging?
Yes, thanks.
>
> Do we need the incomplete changelog?
I prefer to keep it.
>
> By the way, Independence Day 2020 depends on the country the reader
> lives in, August 15th in India.
Thanks for the info but I don't live in India :-)
Regards,
Simon
Re: [PATCH 1/1] git-mailrc: remove invalid entry 'efi'
Hi Heinrich, On Tue, 9 Aug 2022 at 23:26, Heinrich Schuchardt wrote: > > > > On 8/9/22 21:51, Simon Glass wrote: > > Hi Heinrich, > > > > On Mon, 8 Aug 2022 at 13:51, Heinrich Schuchardt > > wrote: > >> > >> Remove alias 'efi' with invalid data. > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> doc/git-mailrc | 1 - > >> 1 file changed, 1 deletion(-) > > > > Sorry for the dumb questions, but what is invalid about it? > > I cannot find agraf as maintainer for EFI in file /MAINTAINERS. > We should avoid misdirected mails. I personally don't use patman. So "Remove agraf as a maintainer for efi"? Reviewed-by: Simon Glass > > Best regards > > Heinrich > > > > >> > >> diff --git a/doc/git-mailrc b/doc/git-mailrc > >> index b00c278190..96623c3b4e 100644 > >> --- a/doc/git-mailrc > >> +++ b/doc/git-mailrc > >> @@ -111,7 +111,6 @@ alias x86uboot, sjg, bmeng > >> alias dm uboot, sjg > >> alias cfiuboot, stroese > >> alias dfuuboot, lukma > >> -alias efiuboot, agraf > >> alias ethuboot, jhersh > >> alias kerneldoc uboot, marex > >> alias fdtuboot, sjg > >> -- > >> 2.36.1 > >> > > > > Regards, > > Simon
Re: [PATCH] Restore pcm051_rev3_defconfig config
On Mon, Aug 08, 2022 at 11:16:19PM +0300, Matwey V. Kornilov wrote:
> pcm051_rev3_defconfig config (Phytec Wega board) has been dropped in
>
> 64efd11d ("arm: Remove pcm051 board")
>
> due to expired migration deadlines. Here, pcm051_rev3_defconfig support is
> reintroduced.
>
> Signed-off-by: Matwey V. Kornilov
> ---
> arch/arm/dts/am335x-wega-rdk-u-boot.dtsi | 12
> board/phytec/phycore_am335x_r2/board.c | 26 +
> configs/pcm051_rev3_defconfig| 70
> scripts/config_whitelist.txt | 1 +
You cannot add symbols to the whitelist, it must be handled in Kconfig
or at runtime.
--
Tom
signature.asc
Description: PGP signature
[PATCH 2/2] rpi: Copy eth PHY address from fw DT to loaded DT
Some Raspberry Pi 400 boards, specifically rev 1.1, have a different address for the ethernet PHY device than what is provided by the kernel DTB. The correct address is provided by the firmware, so we should carry it over into the loaded device tree so that ethernet works on such boards. Signed-off-by: Antoine Mazeas --- board/raspberrypi/rpi/rpi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 28b6f52506..793fd1aa30 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -548,6 +548,9 @@ void update_fdt_from_fw(void *fdt, void *fw_fdt) /* kernel address randomisation seed as provided by the firmware */ copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed"); + + /* address of the PHY device as provided by the firmware */ + copy_property(fdt, fw_fdt, "ethernet0/mdio@e14/ethernet-phy@1", "reg"); } int ft_board_setup(void *blob, struct bd_info *bd) -- 2.37.1
[PATCH 1/2] rpi: Copy properties from firmware dtb to the loaded dtb
The RPI firmware adjusts several property values in the dtb it passes
to u-boot depending on the board/SoC revision. Inherit some of these
when u-boot loads a dtb itself. Specificaly copy:
* /model: The firmware provides a more specific string
* /memreserve: The firmware defines a reserved range, better keep it
* emmc2bus and pcie0 dma-ranges: The C0T revision of the bcm2711 Soc (as
present on rpi 400 and some rpi 4B boards) has different values for
these then the B0T revision. So these need to be adjusted to boot on
these boards
* blconfig: The firmware defines the memory area where the blconfig
stored. Copy those over so it can be enabled.
* /chosen/kaslr-seed: The firmware generates a kaslr seed, take advantage
of that.
Signed-off-by: Sjoerd Simons
---
board/raspberrypi/rpi/rpi.c | 48 +
1 file changed, 48 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 17b8108cc8..28b6f52506 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -504,10 +504,58 @@ void *board_fdt_blob_setup(int *err)
return (void *)fw_dtb_pointer;
}
+int copy_property(void *dst, void *src, char *path, char *property)
+{
+ int dst_offset, src_offset;
+ const fdt32_t *prop;
+ int len;
+
+ src_offset = fdt_path_offset(src, path);
+ dst_offset = fdt_path_offset(dst, path);
+
+ if (src_offset < 0 || dst_offset < 0)
+ return -1;
+
+ prop = fdt_getprop(src, src_offset, property, &len);
+ if (!prop)
+ return -1;
+
+ return fdt_setprop(dst, dst_offset, property, prop, len);
+}
+
+/* Copy tweaks from the firmware dtb to the loaded dtb */
+void update_fdt_from_fw(void *fdt, void *fw_fdt)
+{
+ /* Using dtb from firmware directly; leave it alone */
+ if (fdt == fw_fdt)
+ return;
+
+ /* The firmware provides a more precie model; so copy that */
+ copy_property(fdt, fw_fdt, "/", "model");
+
+ /* memory reserve as suggested by the firmware */
+ copy_property(fdt, fw_fdt, "/", "memreserve");
+
+ /* Adjust dma-ranges for the SD card and PCI bus as they can depend on
+* the SoC revision
+*/
+ copy_property(fdt, fw_fdt, "emmc2bus", "dma-ranges");
+ copy_property(fdt, fw_fdt, "pcie0", "dma-ranges");
+
+ /* Bootloader configuration template exposes as nvmem */
+ if (copy_property(fdt, fw_fdt, "blconfig", "reg") == 0)
+ copy_property(fdt, fw_fdt, "blconfig", "status");
+
+ /* kernel address randomisation seed as provided by the firmware */
+ copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");
+}
+
int ft_board_setup(void *blob, struct bd_info *bd)
{
int node;
+ update_fdt_from_fw(blob, (void *)fw_dtb_pointer);
+
node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
if (node < 0)
fdt_simplefb_add_node(blob);
--
2.37.1
[PATCH 0/2] rpi: Copy properties from firmware DT to loaded DT
Sjoerd Simons submitted the original patch (0001) to carry over some firmware-provided properties into the loaded device tree. This did not fix an issue with Raspberry Pi 400 rev 1.1 boards which would not be able to find the ethernet PHY device at the address specified by the kernel device tree. Patch 0002 expands on Sjoerd's design to also carry over the real ethernet PHY address, enabling the kernel to find and enable a working ethernet on pi 400 rev 1.1 boards. Antoine Mazeas (2): rpi: Copy properties from firmware dtb to the loaded dtb rpi: Copy eth PHY address from fw DT to loaded DT board/raspberrypi/rpi/rpi.c | 51 + 1 file changed, 51 insertions(+) base-commit: 3dd4e916324efc825a7ee8e412f5cf1ded839021 -- 2.37.1
[PATCH] pci: Sort resources before assignment
A PCI device can request resource for multiple memory regions, e.g. a
PCI device tries to allocate prefetchable memory for two regions, one
region size is 0x1000_ and another is 0x1__. And the PCIe
controller provides prefetchable memory window size is 0x1_8000_,
thus in theory the PCIe controller can meet the memory requirement for
the PCI device:
0x1_8000_ > 0x1_1000_ (0x1000_ + 0x1__)
When allocate the memory region, pciauto_region_allocate() applies the
alignment for the start address, we can see the memory regions are
allocated as:
=> pci bar 1.0.0
ID BaseSizeWidth Type
--
0 0x8800 0x0400 32 MEM
1 0x8c00 0x0010 32 MEM
2 0x0010 0x1000 64 MEM Prefetchable
3 0x0011 0x0001 64 MEM Prefetchable
The problem is for the last memory region, we can see its start address
is 0x11__ and the size is 0x1__, therefore, these two
memory regions occupy memory size is:
0x11__ + 0x1__ - 0x10__ = 0x2__
The allocated memory region (0x2__) is out of the range, because
the maximum space provided by PCI controller is only 0x1_8000_.
To fix this issue, this patch sorts resources with descending, this can
give the priority for big chunk memory region, the big memory region is
allocated ahead before a small region, so that its start address does
not necessarily introduce big hole caused by the alignment, which is
finished by function pdev_sort_resources().
And we use another function pdev_assign_resources() to set BARs based on
the sorted list.
As result, we can see the updated memory regions are altered as below;
the end address is: 0x11__ + 0x1000_, which falls into the
permitted memory window.
=> pci bar 1.0.0
ID BaseSizeWidth Type
--
0 0x8800 0x0400 32 MEM
1 0x8c00 0x0010 32 MEM
2 0x0011 0x1000 64 MEM Prefetchable
3 0x0010 0x0001 64 MEM Prefetchable
Reported-by: Matsumoto Misako
Signed-off-by: Leo Yan
---
drivers/pci/pci_auto.c | 104 +++--
1 file changed, 79 insertions(+), 25 deletions(-)
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index c7968926a1..69c801fc62 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include "pci_internal.h"
/* the user can define CONFIG_SYS_PCI_CACHE_LINE_SIZE to avoid problems */
@@ -21,6 +23,69 @@
#define CONFIG_SYS_PCI_CACHE_LINE_SIZE 8
#endif
+struct pci_dev_resource {
+ struct list_head list;
+ int bar;
+ pci_size_t bar_size;
+ int found_mem64;
+ struct pci_region *bar_res;
+};
+
+/* Sort resources by bar size */
+static void pdev_sort_resources(struct pci_dev_resource *new,
+ struct list_head *head)
+{
+ struct pci_dev_resource *dev_res;
+ struct list_head *n;
+
+ /* Fallback is smallest one or list is empty */
+ n = head;
+ list_for_each_entry(dev_res, head, list) {
+ if (new->bar_size > dev_res->bar_size) {
+ n = &dev_res->list;
+ break;
+ }
+ }
+
+ /* Insert it just before n */
+ list_add_tail(&new->list, n);
+}
+
+static void pdev_assign_resources(struct udevice *dev, struct list_head *head)
+{
+ struct pci_dev_resource *dev_res;
+ int bar;
+ pci_addr_t bar_value;
+ int ret = 0;
+
+ list_for_each_entry(dev_res, head, list) {
+ ret = pciauto_region_allocate(dev_res->bar_res,
dev_res->bar_size,
+ &bar_value, dev_res->found_mem64);
+ if (ret)
+ printf("PCI: Failed autoconfig bar %x\n", dev_res->bar);
+
+ bar = dev_res->bar;
+ if (!ret) {
+ /* Write it out and update our limit */
+ dm_pci_write_config32(dev, bar, (u32)bar_value);
+
+ if (dev_res->found_mem64) {
+ bar += 4;
+ if (IS_ENABLED(CONFIG_SYS_PCI_64BIT))
+ dm_pci_write_config32(dev, bar,
+ (u32)(bar_value
>> 32));
+ else
+ /*
+* If we are a 64-bit decoder then
increment to
+* the upper 32 bits of
[PATCH] arm: mvebu: mbus: Fix mbus driver to work also after U-Boot relocation
mbus driver is initialized from arch_cpu_init() callback which is called
before relocation. This driver stores lot of functions and structure
pointers into global variables, so it is data position dependent.
Therefore after relocations all pointers are invalid and driver does not
work anymore as all pointers referes to the old memory, which overlaps with
CONFIG_SYS_LOAD_ADDR and ${loadaddr}.
For example U-Boot fuse command crashes if loadaddr memory is cleared or
rewritten by some image loaded by U-Boot load command.
mw.w ${loadaddr} 0x0 1
fuse read 0 1 2
Fix this issue by removing of all mbus global variables in which are stored
pointers to structures or functions which changes during relocation. And
replace it by direct function calls (not via pointers). With this change
fuse command finally works.
Signed-off-by: Pali Rohár
---
arch/arm/mach-kirkwood/include/mach/cpu.h | 3 -
arch/arm/mach-mvebu/include/mach/cpu.h| 3 -
arch/arm/mach-mvebu/mbus.c| 167 +-
board/alliedtelesis/x530/x530.c | 2 +-
board/maxbcm/maxbcm.c | 8 +-
board/theadorable/theadorable.c | 4 +-
include/linux/mbus.h | 13 +-
7 files changed, 75 insertions(+), 125 deletions(-)
diff --git a/arch/arm/mach-kirkwood/include/mach/cpu.h
b/arch/arm/mach-kirkwood/include/mach/cpu.h
index 71c546f9acf6..d8639c60352b 100644
--- a/arch/arm/mach-kirkwood/include/mach/cpu.h
+++ b/arch/arm/mach-kirkwood/include/mach/cpu.h
@@ -144,9 +144,6 @@ struct kwgpio_registers {
u32 irq_level;
};
-/* Needed for dynamic (board-specific) mbus configuration */
-extern struct mvebu_mbus_state mbus_state;
-
/*
* functions
*/
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 689c96bd4eac..d9fa1f32aa52 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -122,9 +122,6 @@ struct sar_freq_modes {
u32 d_clk;
};
-/* Needed for dynamic (board-specific) mbus configuration */
-extern struct mvebu_mbus_state mbus_state;
-
/*
* functions
*/
diff --git a/arch/arm/mach-mvebu/mbus.c b/arch/arm/mach-mvebu/mbus.c
index 3b1b9f73ebf6..7092f6cc10c2 100644
--- a/arch/arm/mach-mvebu/mbus.c
+++ b/arch/arm/mach-mvebu/mbus.c
@@ -88,31 +88,34 @@
#define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
-struct mvebu_mbus_state;
-
-struct mvebu_mbus_soc_data {
- unsigned int num_wins;
- unsigned int num_remappable_wins;
- unsigned int (*win_cfg_offset)(const int win);
- void (*setup_cpu_target)(struct mvebu_mbus_state *s);
-};
-
-struct mvebu_mbus_state mbus_state
- __section(".data");
static struct mbus_dram_target_info mbus_dram_info
__section(".data");
+#if defined(CONFIG_ARCH_MVEBU)
+ #define MVEBU_MBUS_NUM_WINS 20
+ #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 8
+ #define MVEBU_MBUS_WIN_CFG_OFFSET(win)
armada_370_xp_mbus_win_offset(win)
+#elif defined(CONFIG_ARCH_KIRKWOOD)
+ #define MVEBU_MBUS_NUM_WINS 8
+ #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 4
+ #define MVEBU_MBUS_WIN_CFG_OFFSET(win) orion5x_mbus_win_offset(win)
+#else
+ #error "No supported architecture"
+#endif
+
+static unsigned int armada_370_xp_mbus_win_offset(int win);
+static unsigned int orion5x_mbus_win_offset(int win);
+
/*
* Functions to manipulate the address decoding windows
*/
-static void mvebu_mbus_read_window(struct mvebu_mbus_state *mbus,
- int win, int *enabled, u64 *base,
+static void mvebu_mbus_read_window(int win, int *enabled, u64 *base,
u32 *size, u8 *target, u8 *attr,
u64 *remap)
{
- void __iomem *addr = mbus->mbuswins_base +
- mbus->soc->win_cfg_offset(win);
+ void __iomem *addr = (void __iomem *)MVEBU_CPU_WIN_BASE +
+ MVEBU_MBUS_WIN_CFG_OFFSET(win);
u32 basereg = readl(addr + WIN_BASE_OFF);
u32 ctrlreg = readl(addr + WIN_CTRL_OFF);
@@ -133,7 +136,7 @@ static void mvebu_mbus_read_window(struct mvebu_mbus_state
*mbus,
*attr = (ctrlreg & WIN_CTRL_ATTR_MASK) >> WIN_CTRL_ATTR_SHIFT;
if (remap) {
- if (win < mbus->soc->num_remappable_wins) {
+ if (win < MVEBU_MBUS_NUM_REMAPPABLE_WINS) {
u32 remap_low = readl(addr + WIN_REMAP_LO_OFF);
u32 remap_hi = readl(addr + WIN_REMAP_HI_OFF);
*remap = ((u64)remap_hi << 32) | remap_low;
@@ -143,27 +146,25 @@ static void mvebu_mbus_read_window(struct
mvebu_mbus_state *mbus,
}
}
-static void mvebu_mbus_disable_window(struct mvebu_mbus_state *mbus,
- int win)
+static void mvebu_mbus_disable_window(int win)
{
void __iomem *addr;
- addr = mbus->mbuswins_base + mbus->soc->win_cfg_offset(win);
+ addr = (vo
Re: [PATCH 17/31] i2c: add support for MediaTek I2C interface
Hi
On Thu, Aug 4, 2022 at 5:38 AM Weijie Gao wrote:
>
> This patch adds support for MediaTek I2C interface
>
> Signed-off-by: Weijie Gao
> ---
> drivers/i2c/Kconfig | 9 +
> drivers/i2c/Makefile | 1 +
> drivers/i2c/mtk_i2c.c | 822 ++
> 3 files changed, 832 insertions(+)
> create mode 100644 drivers/i2c/mtk_i2c.c
>
> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> index be4724bf8e..08b6c7bdcc 100644
> --- a/drivers/i2c/Kconfig
> +++ b/drivers/i2c/Kconfig
> @@ -261,6 +261,15 @@ config SYS_I2C_MESON
> internal buffer holding up to 8 bytes for transfers and supports
> both 7-bit and 10-bit addresses.
>
> +config SYS_I2C_MTK
> + bool "MediaTek I2C driver"
> + help
> + This selects the MediaTek Integrated Inter Circuit bus driver.
> + The I2C bus adapter is the base for some other I2C client,
> + eg: touch, sensors.
> + If you want to use MediaTek I2C interface, say Y here.
> + If unsure, say N.
> +
> config SYS_I2C_MICROCHIP
> bool "Microchip I2C driver"
> help
> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
> index 7e046f809a..920aafb91c 100644
> --- a/drivers/i2c/Makefile
> +++ b/drivers/i2c/Makefile
> @@ -32,6 +32,7 @@ obj-$(CONFIG_SYS_I2C_MICROCHIP) += i2c-microchip.o
> obj-$(CONFIG_SYS_I2C_MV) += mv_i2c.o
> obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o
> obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
> +obj-$(CONFIG_SYS_I2C_MTK) += mtk_i2c.o
> obj-$(CONFIG_SYS_I2C_NEXELL) += nx_i2c.o
> obj-$(CONFIG_SYS_I2C_NPCM) += npcm_i2c.o
> obj-$(CONFIG_SYS_I2C_OCORES) += ocores_i2c.o
> diff --git a/drivers/i2c/mtk_i2c.c b/drivers/i2c/mtk_i2c.c
> new file mode 100644
> index 00..1d4a93f8c9
> --- /dev/null
> +++ b/drivers/i2c/mtk_i2c.c
> @@ -0,0 +1,822 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2022 MediaTek Inc. All Rights Reserved.
> + *
> + * Author: Mingming Lee
> + *
> + * MediaTek I2C Interface driver
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define I2C_RS_TRANSFERBIT(4)
> +#define I2C_HS_NACKERR BIT(2)
> +#define I2C_ACKERR BIT(1)
> +#define I2C_TRANSAC_COMP BIT(0)
> +#define I2C_TRANSAC_START BIT(0)
> +#define I2C_RS_MUL_CNFGBIT(15)
> +#define I2C_RS_MUL_TRIGBIT(14)
> +#define I2C_DCM_DISABLE0x
> +#define I2C_IO_CONFIG_OPEN_DRAIN 0x0003
> +#define I2C_IO_CONFIG_PUSH_PULL0x
> +#define I2C_SOFT_RST 0x0001
> +#define I2C_FIFO_ADDR_CLR 0x0001
> +#define I2C_DELAY_LEN 0x0002
> +#define I2C_ST_START_CON 0x8001
> +#define I2C_FS_START_CON 0x1800
> +#define I2C_TIME_CLR_VALUE 0x
> +#define I2C_TIME_DEFAULT_VALUE 0x0003
> +#define I2C_WRRD_TRANAC_VALUE 0x0002
> +#define I2C_RD_TRANAC_VALUE0x0001
> +
> +#define I2C_DMA_CON_TX 0x
> +#define I2C_DMA_CON_RX 0x0001
> +#define I2C_DMA_START_EN 0x0001
> +#define I2C_DMA_INT_FLAG_NONE 0x
> +#define I2C_DMA_CLR_FLAG 0x
> +#define I2C_DMA_TX_RX 0x
> +#define I2C_DMA_HARD_RST 0x0002
> +
> +#define MAX_ST_MODE_SPEED 10
> +#define MAX_FS_MODE_SPEED 40
> +#define MAX_HS_MODE_SPEED 340
> +#define MAX_SAMPLE_CNT_DIV 8
> +#define MAX_STEP_CNT_DIV 64
> +#define MAX_HS_STEP_CNT_DIV8
> +#define I2C_DEFAULT_CLK_DIV4
> +
> +#define MAX_I2C_ADDR 0x7f
> +#define MAX_I2C_LEN0xff
> +#define TRANS_ADDR_ONLYBIT(8)
> +#define TRANSFER_TIMEOUT 5 /* us */
> +#define I2C_FIFO_STAT1_MASK0x001f
> +#define TIMING_SAMPLE_OFFSET 8
> +#define HS_SAMPLE_OFFSET 12
> +#define HS_STEP_OFFSET 8
> +
> +#define I2C_CONTROL_WRAPPERBIT(0)
> +#define I2C_CONTROL_RS BIT(1)
> +#define I2C_CONTROL_DMA_EN BIT(2)
> +#define I2C_CONTROL_CLK_EXT_EN BIT(3)
> +#define I2C_CONTROL_DIR_CHANGE BIT(4)
> +#define I2C_CONTROL_ACKERR_DET_EN BIT(5)
> +#define I2C_CONTROL_TRANSFER_LEN_CHANGE BIT(6)
> +#define I2C_CONTROL_DMAACK BIT(8)
> +#define I2C_CONTROL_ASYNC BIT(9)
> +
> +enum I2C_REGS_OFFSET {
> + REG_PORT,
> + REG_SLAVE_ADDR,
> + REG_INTR_MASK,
> + REG_INTR_STAT,
> + REG_CONTROL,
> + REG_TRANSFER_LEN,
> + REG_TRANSAC_LEN,
> + REG_DELAY_LEN,
> + REG_TIMING,
> + REG_START,
> + REG_EXT_CONF,
> + REG_FIFO_STAT1,
> + REG_LTIMING,
> + REG_FI
Re: [PATCH 17/31] i2c: add support for MediaTek I2C interface
Hello Weijie Gao, On 04.08.22 05:36, Weijie Gao wrote: > This patch adds support for MediaTek I2C interface > > Signed-off-by: Weijie Gao > --- > drivers/i2c/Kconfig | 9 + > drivers/i2c/Makefile | 1 + > drivers/i2c/mtk_i2c.c | 822 ++ > 3 files changed, 832 insertions(+) > create mode 100644 drivers/i2c/mtk_i2c.c beside comment from Simon Reviewed-by: Heiko Schocher Thanks! 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
[PATCH] arm: mvebu: turris_mox: Set "sfp" label in eth1 DT node when only Mox SFP is detected
When Mox SFP module is connected after Topaz or Peridot module then port DT node already contains "sfp" label. But Mox SFP module can be connected also without Topaz or Peridot module in which case it is connected directly into he eth1 DT node, which is without any label. So add "sfp" label into eth1 DT node in this case. Signed-off-by: Pali Rohár --- board/CZ.NIC/turris_mox/turris_mox.c | 5 + 1 file changed, 5 insertions(+) diff --git a/board/CZ.NIC/turris_mox/turris_mox.c b/board/CZ.NIC/turris_mox/turris_mox.c index 28259e71405f..3dbd68e52366 100644 --- a/board/CZ.NIC/turris_mox/turris_mox.c +++ b/board/CZ.NIC/turris_mox/turris_mox.c @@ -821,6 +821,11 @@ int ft_board_setup(void *blob, struct bd_info *bd) "sgmii"); if (res < 0) return res; + + res = fdt_setprop_string(blob, node, "label", +"sfp"); + if (res < 0) + return res; } res = fdt_status_okay_by_compatible(blob, "cznic,moxtet-gpio"); -- 2.20.1
[PATCH] arm: ARMv4 assembly compatibility
There is currently a problem that U-Boot can not work on ARMv4
because assembly imlementations of memcpy() and some other functions
use "bx lr" instruction that is not available on ARMv4 ("mov pc, lr"
should be used instead).
A working preprocessor-based solution to this problem is found in
arch/arm/lib/relocate.S. Move it to the "ret" macro in
arch/arm/include/asm/assembler.h and change all "bx lr" code
to "ret lr" in functions that may run on ARMv4. Linux source code
deals with this problem in the same manner.
Signed-off-by: Sergei Antonov
CC: Samuel Holland
CC: Ye Li
CC: Simon Glass
CC: Andre Przywara
CC: Marek Vasut
CC: Sean Anderson
CC: Tom Rini
CC: Wolfgang Denk
---
arch/arm/include/asm/assembler.h | 6 ++
arch/arm/lib/lib1funcs.S | 8
arch/arm/lib/memcpy.S| 6 +++---
arch/arm/lib/relocate.S | 10 ++
arch/arm/lib/setjmp.S| 4 ++--
5 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index b146918586..911f7a1b49 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -63,11 +63,17 @@
*/
.irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
.macro ret\c, reg
+
+ /* ARMv4- don't know bx lr but the assembler fails to see that */
+#ifdef __ARM_ARCH_4__
+ mov\c pc, \reg
+#else
.ifeqs "\reg", "lr"
bx\c\reg
.else
mov\c pc, \reg
.endif
+#endif
.endm
.endr
diff --git a/arch/arm/lib/lib1funcs.S b/arch/arm/lib/lib1funcs.S
index 700eee5fbb..7ff4446dd6 100644
--- a/arch/arm/lib/lib1funcs.S
+++ b/arch/arm/lib/lib1funcs.S
@@ -377,7 +377,7 @@ ENTRY(__gnu_thumb1_case_sqi)
lslsr1, r1, #1
add lr, lr, r1
pop {r1}
- bx lr
+ ret lr
ENDPROC(__gnu_thumb1_case_sqi)
.popsection
@@ -391,7 +391,7 @@ ENTRY(__gnu_thumb1_case_uqi)
lslsr1, r1, #1
add lr, lr, r1
pop {r1}
- bx lr
+ ret lr
ENDPROC(__gnu_thumb1_case_uqi)
.popsection
@@ -406,7 +406,7 @@ ENTRY(__gnu_thumb1_case_shi)
lslsr1, r1, #1
add lr, lr, r1
pop {r0, r1}
- bx lr
+ ret lr
ENDPROC(__gnu_thumb1_case_shi)
.popsection
@@ -421,7 +421,7 @@ ENTRY(__gnu_thumb1_case_uhi)
lslsr1, r1, #1
add lr, lr, r1
pop {r0, r1}
- bx lr
+ ret lr
ENDPROC(__gnu_thumb1_case_uhi)
.popsection
#endif
diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index eee7a219ce..a1c996f94e 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -59,7 +59,7 @@
#endif
ENTRY(memcpy)
cmp r0, r1
- bxeqlr
+ reteq lr
enter r4, lr
@@ -148,7 +148,7 @@ ENTRY(memcpy)
str1b r0, ip, cs, abort=21f
exitr4, lr
- bx lr
+ ret lr
9: rsb ip, ip, #4
cmp ip, #2
@@ -258,7 +258,7 @@ ENTRY(memcpy)
.macro copy_abort_end
ldmfd sp!, {r4, lr}
- bx lr
+ ret lr
.endm
ENDPROC(memcpy)
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 5102bfabde..dd6f2e3bd5 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -61,7 +61,7 @@ ENTRY(relocate_vectors)
stmia r1!, {r2-r8,r10}
#endif
#endif
- bx lr
+ ret lr
ENDPROC(relocate_vectors)
@@ -127,13 +127,7 @@ relocate_done:
mcr p15, 0, r0, c7, c10, 4 /* drain write buffer */
#endif
- /* ARMv4- don't know bx lr but the assembler fails to see that */
-
-#ifdef __ARM_ARCH_4__
- mov pc, lr
-#else
- bx lr
-#endif
+ ret lr
ENDPROC(relocate_code)
diff --git a/arch/arm/lib/setjmp.S b/arch/arm/lib/setjmp.S
index 176a1d5315..2f041aeef0 100644
--- a/arch/arm/lib/setjmp.S
+++ b/arch/arm/lib/setjmp.S
@@ -17,7 +17,7 @@ ENTRY(setjmp)
mov ip, sp
stm a1, {v1-v8, ip, lr}
mov a1, #0
- bx lr
+ ret lr
ENDPROC(setjmp)
.popsection
@@ -31,6 +31,6 @@ ENTRY(longjmp)
bne 1f
mov a1, #1
1:
- bx lr
+ ret lr
ENDPROC(longjmp)
.popsection
--
2.32.0
[PATCH] arm: mvebu: turris_omnia: Show MCU version
There are already more MCU firmware versions for Turris Omnia in
production, so display git commit (version) of the MCU firmware during
U-Boot startup. It will help to identify what version of MCU firmware is
Turris Omnia using.
MCU firmware for Turris Omnia is open source and available at website:
https://gitlab.nic.cz/turris/hw/omnia_hw_ctrl
It can be updated from running system via i2c bus with this tool:
https://gitlab.nic.cz/turris/omnia-mcutool
Signed-off-by: Pali Rohár
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 36
1 file changed, 36 insertions(+)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 5ddd873d0250..caae8ce44695 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -61,7 +62,9 @@ DECLARE_GLOBAL_DATA_PTR;
enum mcu_commands {
CMD_GET_STATUS_WORD = 0x01,
CMD_GET_RESET = 0x09,
+ CMD_GET_FW_VERSION_APP = 0x0a,
CMD_WATCHDOG_STATE = 0x0b,
+ CMD_GET_FW_VERSION_BOOT = 0x0e,
/* available if STS_FEATURES_SUPPORTED bit set in status word */
CMD_GET_FEATURES= 0x10,
@@ -428,6 +431,38 @@ static const char * const omnia_get_mcu_type(void)
return mcu_types[stsword & STS_MCU_TYPE_MASK];
}
+static const char * const omnia_get_mcu_version(void)
+{
+ static char version[82];
+ u8 version_app[20];
+ u8 version_boot[20];
+ int ret;
+
+ ret = omnia_mcu_read(CMD_GET_FW_VERSION_APP, &version_app,
sizeof(version_app));
+ if (ret)
+ return "unknown";
+
+ ret = omnia_mcu_read(CMD_GET_FW_VERSION_BOOT, &version_boot,
sizeof(version_boot));
+ if (ret)
+ return "unknown";
+
+ /*
+* If git commits of MCU bootloader and MCU application are same then
+* show version only once. If they are different then show both commits.
+*/
+ if (!memcmp(version_app, version_boot, 20)) {
+ bin2hex(version, version_app, 20);
+ version[40] = '\0';
+ } else {
+ bin2hex(version, version_boot, 20);
+ version[40] = '/';
+ bin2hex(version + 41, version_app, 20);
+ version[81] = '\0';
+ }
+
+ return version;
+}
+
/*
* Define the DDR layout / topology here in the board file. This will
* be used by the DDR3 init code in the SPL U-Boot version to configure
@@ -944,6 +979,7 @@ int show_board_info(void)
err = turris_atsha_otp_get_serial_number(&version_num, &serial_num);
printf("Model: Turris Omnia\n");
printf(" MCU type: %s\n", omnia_get_mcu_type());
+ printf(" MCU version: %s\n", omnia_get_mcu_version());
printf(" RAM size: %i MiB\n", omnia_get_ram_size_gb() * 1024);
if (err)
printf(" Serial Number: unknown\n");
--
2.20.1
Re: [PATCH] spl: opensbi: convert scratch options to config
On Mon, Aug 08, 2022 at 01:28:52PM +0300, Nikita Shubin wrote: > From: Nikita Shubin > > Convert hardcoded "opensbi_info.options" to config provided value, this > allows changing options passed to OpenSBI. > > SPL_OPENSBI_SCRATCH_OPTIONS is defaulted to SBI_SCRATCH_NO_BOOT_PRINTS. > > Link: > https://github.com/riscv-software-src/opensbi/blob/master/docs/firmware/fw_dynamic.md > Signed-off-by: Nikita Shubin > --- > common/spl/Kconfig | 8 > common/spl/spl_opensbi.c | 2 +- > 2 files changed, 9 insertions(+), 1 deletion(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH] spl: opensbi: fix typo
On Mon, Aug 08, 2022 at 01:24:25PM +0300, Nikita Shubin wrote: > From: Nikita Shubin > > s/obensbi_info/opensbi_info/ > > Signed-off-by: Nikita Shubin > --- > common/spl/spl_opensbi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c > index 1c0abf8553..7fe0b5e158 100644 > --- a/common/spl/spl_opensbi.c > +++ b/common/spl/spl_opensbi.c > @@ -66,7 +66,7 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image) > if (ret) > ret = fit_image_get_load(spl_image->fdt_addr, uboot_node, > &uboot_entry); > > - /* Prepare obensbi_info object */ > + /* Prepare opensbi_info object */ > opensbi_info.magic = FW_DYNAMIC_INFO_MAGIC_VALUE; > opensbi_info.version = FW_DYNAMIC_INFO_VERSION; > opensbi_info.next_addr = uboot_entry; > -- > 2.35.1 > Reviewed-by: Leo Yu-Chi Liang
Re: ethernet dt aliases implications in U-Boot and Linux
On Wed, Aug 10, 2022 at 03:11:48AM +0200, Andrew Lunn wrote:
> > Is something like the following really that crazy of an idea?
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index e0878a500aa9..a679c74a63c6 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -1151,6 +1151,15 @@ static int dev_alloc_name_ns(struct net *net,
> > int ret;
> >
> > BUG_ON(!net);
> > +#ifdef CONFIG_OF
> > + if (dev->dev.parent && dev->dev.parent->of_node) {
> > + const char *name =
> > of_get_property(dev->dev.parent->of_node, "label", NULL);
> > + if (name) {
> > + strlcpy(dev->name, name, IFNAMSIZ);
> > + return 0;
> > + }
> > + }
> > +#endif
> > ret = __dev_alloc_name(net, name, buf);
> > if (ret >= 0)
> > strlcpy(dev->name, buf, IFNAMSIZ);
> >
> > I still like using the index from aliases/ethernet* instead as there
> > is a precedence for that in other Linux drivers as well as U-Boot
>
> I guess you are new to the netdev list :-)
>
> This is one of those FAQ sort of things, discussed every
> year. Anything like this is always NACKed. I don't see why this time
> should be any different.
>
> DSA is somewhat special because it is very old. It comes from before
> the times of DT. Its DT binding was proposed relatively earl in DT
> times, and would be rejected in modern days. But the rules of ABI mean
> the label property will be valid forever. But i very much doubt it
> will spread to interfaces in general.
And if this is a FAQ maybe you can point to a summary (perhaps in
previous mail discusssion) that explains how to provide stable interface
names for Ethernet devices on a DT based platform?
On x86 there is a name derived from the device location in the bus
topology which may be somewhat stable but it is not clear that it
cannot change, and there is an optional BIOS provided table that can
asssign meaningful names to the interfaces.
What are the equivalents for DT?
Thanks
Michal
