November 2020 - U-Boot

[PATCH 1/2] test: Avoid assuming sandbox board for bloblist test
by Simon Glass 11 Nov '20

11 Nov '20

This tests assumes it is running on sandbox. Add a few functions to handle silencing the console on any board and use those instead. Reported-by: Kever Yang <kever.yang(a)rock-chips.com> Signed-off-by: Simon Glass <sjg(a)chromium.org> --- include/test/ut.h | 18 ++++++++++++++++++ test/bloblist.c | 13 ++++--------- test/ut.c | 18 ++++++++++++++++++ 3 files changed, 40 insertions(+), 9 deletions(-) diff --git a/include/test/ut.h b/include/test/ut.h index 3f2ee7514b8..17400c73ea9 100644 --- a/include/test/ut.h +++ b/include/test/ut.h @@ -338,4 +338,22 @@ ulong ut_check_free(void); */ long ut_check_delta(ulong last); +/** + * ut_silence_console() - Silence the console if requested by the user + * + * This stops test output from appear on the console. It is the default on + * sandbox, unless the -v flag is given. For other boards, this does nothing. + * + * @uts: Test state (in case in future we want to keep state here) + */ +void ut_silence_console(struct unit_test_state *uts); + +/** + * ut_unsilence_console() - Unsilence the console after a test + * + * This restarts console output again and turns off console recording. This + * happens on all boards, including sandbox. + */ +void ut_unsilence_console(struct unit_test_state *uts); + #endif diff --git a/test/bloblist.c b/test/bloblist.c index 0bb9e2d81e7..900299dd68e 100644 --- a/test/bloblist.c +++ b/test/bloblist.c @@ -7,7 +7,6 @@ #include <bloblist.h> #include <log.h> #include <mapmem.h> -#include <asm/state.h> #include <test/suites.h> #include <test/test.h> #include <test/ut.h> @@ -240,7 +239,6 @@ BLOBLIST_TEST(bloblist_test_checksum, 0); /* Test the 'bloblist info' command */ static int bloblist_test_cmd_info(struct unit_test_state *uts) { - struct sandbox_state *state = state_get_current(); struct bloblist_hdr *hdr; char *data, *data2; @@ -250,8 +248,7 @@ static int bloblist_test_cmd_info(struct unit_test_state *uts) data2 = bloblist_ensure(TEST_TAG2, TEST_SIZE2); console_record_reset_enable(); - if (!state->show_test_output) - gd->flags |= GD_FLG_SILENT; + ut_silence_console(uts); console_record_reset(); run_command("bloblist info", 0); ut_assert_nextline("base: %lx", (ulong)map_to_sysmem(hdr)); @@ -259,7 +256,7 @@ static int bloblist_test_cmd_info(struct unit_test_state *uts) ut_assert_nextline("alloced: 70 112 Bytes"); ut_assert_nextline("free: 390 912 Bytes"); ut_assert_console_end(); - gd->flags &= ~(GD_FLG_SILENT | GD_FLG_RECORD); + ut_unsilence_console(uts); return 0; } @@ -268,7 +265,6 @@ BLOBLIST_TEST(bloblist_test_cmd_info, 0); /* Test the 'bloblist list' command */ static int bloblist_test_cmd_list(struct unit_test_state *uts) { - struct sandbox_state *state = state_get_current(); struct bloblist_hdr *hdr; char *data, *data2; @@ -278,8 +274,7 @@ static int bloblist_test_cmd_list(struct unit_test_state *uts) data2 = bloblist_ensure(TEST_TAG2, TEST_SIZE2); console_record_reset_enable(); - if (!state->show_test_output) - gd->flags |= GD_FLG_SILENT; + ut_silence_console(uts); console_record_reset(); run_command("bloblist list", 0); ut_assert_nextline("Address Size Tag Name"); @@ -288,7 +283,7 @@ static int bloblist_test_cmd_list(struct unit_test_state *uts) ut_assert_nextline("%08lx %8x 2 SPL hand-off", (ulong)map_to_sysmem(data2), TEST_SIZE2); ut_assert_console_end(); - gd->flags &= ~(GD_FLG_SILENT | GD_FLG_RECORD); + ut_unsilence_console(uts); return 0; } diff --git a/test/ut.c b/test/ut.c index 95bdd66de6a..44ed1ba2d31 100644 --- a/test/ut.c +++ b/test/ut.c @@ -8,6 +8,9 @@ #include <common.h> #include <console.h> #include <malloc.h> +#ifdef CONFIG_SANDBOX +#include <asm/state.h> +#endif #include <test/test.h> #include <test/ut.h> @@ -114,3 +117,18 @@ int ut_check_console_dump(struct unit_test_state *uts, int total_bytes) return upto == total_bytes ? 0 : 1; } + +void ut_silence_console(struct unit_test_state *uts) +{ +#ifdef CONFIG_SANDBOX + struct sandbox_state *state = state_get_current(); + + if (!state->show_test_output) + gd->flags |= GD_FLG_SILENT; +#endif +} + +void ut_unsilence_console(struct unit_test_state *uts) +{ + gd->flags &= ~(GD_FLG_SILENT | GD_FLG_RECORD); +} -- 2.29.2.222.g5d2a92d10f8-goog

2 3

drivers/ram/rockchip/sdram_common.c :: sdram_detect_dbw() LPDDR3/2 calculations seem wrong
by Bjoern A. Zeeb 11 Nov '20

11 Nov '20

Hi, I got a nanopc-t4 amongst others which shipped with: DDR Version 1.15 20181010 Channel 0: LPDDR3, 933MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=2048MB .. I have since upgraded to more recent u-boot versions: U-Boot TPL 2020.07 (Sep 27 2020 - 12:34:15) Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB U-Boot TPL 2020.10 (Nov 10 2020 - 13:37:45) Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB The machine was highly instable showing memory and locking issues. When only using two little cores, it was a lot more stable. I went and also tried: DDR Version 1.24 20191016 Channel 0: LPDDR3, 933MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB which seems to match recent u-boot but all of them are different to the original Die BW of 32 which I currently assume to be correct for the Samsung K4E6E304EC-EGCG (so possibly the error also migrated into rokchip-linux/rkbin ?). Looking at sdram_common.c::sdram_detect_dbw() 300 cs_cap = (1 << (row + col + bk + bw - 20)); 301 if (bw == 2) { 302 if (cs_cap <= 0x2000000) /* 256Mb */ 303 die_bw_0 = (col < 9) ? 2 : 1; 304 else if (cs_cap <= 0x10000000) /* 2Gb */ 305 die_bw_0 = (col < 10) ? 2 : 1; 306 else if (cs_cap <= 0x40000000) /* 8Gb */ 307 die_bw_0 = (col < 11) ? 2 : 1; 308 else 309 die_bw_0 = (col < 12) ? 2 : 1; 310 if (cs > 1) { 311 row = cap_info->cs1_row; 312 cs_cap = (1 << (row + col + bk + bw - 20)); 313 if (cs_cap <= 0x2000000) /* 256Mb */ 314 die_bw_0 = (col < 9) ? 2 : 1; 315 else if (cs_cap <= 0x10000000) /* 2Gb */ 316 die_bw_0 = (col < 10) ? 2 : 1; 317 else if (cs_cap <= 0x40000000) /* 8Gb */ 318 die_bw_0 = (col < 11) ? 2 : 1; 319 else 320 die_bw_0 = (col < 12) ? 2 : 1; 321 } 322 } else { ca_cap is off by 20 bits compared to the values you are comparing to; in my case 0x400 and not 0x40000000: type 6 row 15 col 10 bk 3 cs 2 bw 2 cs_cap 8 cs1_row 15 1 << (15 + 10 + 3 + 2 - 20) == 1 << 10 == 0x400 And similar in the 2nd case with cs1_row given cs > 1. Now I know very little about all the memory chips out there but it seems very unlikely to regain these 20 bits in these calculations. So either the “-20” goes or the cs_cap <= values need adjustment. The problem now comes from the fact that cap_info->dbw gets the wrong value from die_bw_0 this way and given it is LPDDR3 I assume that set_cap_relate_config() in sdram_rk3399.c later restores the wrong values for the “memdata_ratio”. There might be more problems lingering, but changing this, my machine got a lot more reliable, though I still see memory errors when I push it to its (temperature) limits running on all 6 cores, even with decent cooling, but that might be a secondary problem. Can someone with a lot more insight into this magic have a look and if needed please fix it? /bz

1 0

Re: [RESEND,PATCH v2 1/1] riscv: Add timer_get_us() for tracing
by Rick Chen 11 Nov '20

11 Nov '20

> From: Pragnesh Patel [mailto:pragnesh.patel@sifive.com] > Sent: Thursday, November 05, 2020 7:31 PM > To: u-boot(a)lists.denx.de > Cc: atish.patra(a)wdc.com; palmerdabbelt(a)google.com; bmeng.cn(a)gmail.com; paul.walmsley(a)sifive.com; anup.patel(a)wdc.com; sagar.kadam(a)sifive.com; Rick Jian-Zhi Chen(陳建志); Pragnesh Patel; Sean Anderson; Claudiu Beznea; Simon Glass > Subject: [RESEND,PATCH v2 1/1] riscv: Add timer_get_us() for tracing > > Add timer_get_us() which is useful for tracing. > For S-mode U-Boot, CSR_TIMEH and CSR_TIME will provide > a timer ticks and For M-mode U-Boot, mtime register will > provide the same. > > Signed-off-by: Pragnesh Patel <pragnesh.patel(a)sifive.com> > --- > drivers/timer/andes_plmt_timer.c | 16 +++++++++++++++- > drivers/timer/riscv_timer.c | 14 +++++++++++++- > drivers/timer/sifive_clint_timer.c | 16 +++++++++++++++- > 3 files changed, 43 insertions(+), 3 deletions(-) > I verify it fail as below: U-Boot 2020.10-20532-g0910882 (Nov 09 2020 - 15:51:31 +0800) DRAM: 1 GiB trace: enabled Do you have any suggestion ? Thanks, Rick > diff --git a/drivers/timer/andes_plmt_timer.c b/drivers/timer/andes_plmt_timer.c > index cec86718c7..9d663e036e 100644 > --- a/drivers/timer/andes_plmt_timer.c > +++ b/drivers/timer/andes_plmt_timer.c > @@ -13,11 +13,12 @@ > #include <timer.h> > #include <asm/io.h> > #include <linux/err.h> > +#include <div64.h> > > /* mtime register */ > #define MTIME_REG(base) ((ulong)(base)) > > -static u64 andes_plmt_get_count(struct udevice *dev) > +static u64 notrace andes_plmt_get_count(struct udevice *dev) > { > return readq((void __iomem *)MTIME_REG(dev->priv)); > } > @@ -26,12 +27,25 @@ static const struct timer_ops andes_plmt_ops = { > .get_count = andes_plmt_get_count, > }; > > +#if CONFIG_IS_ENABLED(RISCV_MMODE) > +unsigned long notrace timer_get_us(void) > +{ > + u64 ticks; > + > + /* FIXME: gd->arch.plic should contain valid base address */ > + ticks = andes_plmt_get_count(gd->arch.plic); > + do_div(ticks, CONFIG_SYS_HZ); > + return ticks; > +} > +#endif > + > static int andes_plmt_probe(struct udevice *dev) > { > dev->priv = dev_read_addr_ptr(dev); > if (!dev->priv) > return -EINVAL; > > + gd->arch.plic = dev->priv; > return timer_timebase_fallback(dev); > } > > diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c > index 21ae184057..7fa8773da3 100644 > --- a/drivers/timer/riscv_timer.c > +++ b/drivers/timer/riscv_timer.c > @@ -15,8 +15,9 @@ > #include <errno.h> > #include <timer.h> > #include <asm/csr.h> > +#include <div64.h> > > -static u64 riscv_timer_get_count(struct udevice *dev) > +static u64 notrace riscv_timer_get_count(struct udevice *dev) > { > __maybe_unused u32 hi, lo; > > @@ -31,6 +32,17 @@ static u64 riscv_timer_get_count(struct udevice *dev) > return ((u64)hi << 32) | lo; > } > > +#if CONFIG_IS_ENABLED(RISCV_SMODE) > +unsigned long notrace timer_get_us(void) > +{ > + u64 ticks; > + > + ticks = riscv_timer_get_count(NULL); > + do_div(ticks, CONFIG_SYS_HZ); > + return ticks; > +} > +#endif > + > static int riscv_timer_probe(struct udevice *dev) > { > struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev); > diff --git a/drivers/timer/sifive_clint_timer.c b/drivers/timer/sifive_clint_timer.c > index 00ce0f08d6..166655e99d 100644 > --- a/drivers/timer/sifive_clint_timer.c > +++ b/drivers/timer/sifive_clint_timer.c > @@ -10,11 +10,12 @@ > #include <timer.h> > #include <asm/io.h> > #include <linux/err.h> > +#include <div64.h> > > /* mtime register */ > #define MTIME_REG(base) ((ulong)(base) + 0xbff8) > > -static u64 sifive_clint_get_count(struct udevice *dev) > +static u64 notrace sifive_clint_get_count(struct udevice *dev) > { > return readq((void __iomem *)MTIME_REG(dev->priv)); > } > @@ -23,12 +24,25 @@ static const struct timer_ops sifive_clint_ops = { > .get_count = sifive_clint_get_count, > }; > > +#if CONFIG_IS_ENABLED(RISCV_MMODE) > +unsigned long notrace timer_get_us(void) > +{ > + u64 ticks; > + > + /* FIXME: gd->arch.clint should contain valid base address */ > + ticks = sifive_clint_get_count(gd->arch.clint); > + do_div(ticks, CONFIG_SYS_HZ); > + return ticks; > +} > +#endif > + > static int sifive_clint_probe(struct udevice *dev) > { > dev->priv = dev_read_addr_ptr(dev); > if (!dev->priv) > return -EINVAL; > > + gd->arch.clint = dev->priv; > return timer_timebase_fallback(dev); > } > > -- > 2.17.1 >

2 3

Re: [PATCH v2 2/2] riscv: sifive/fu540: kconfig: Enable support for Opencores I2C controller
by Rick Chen 11 Nov '20

11 Nov '20

> From: Pragnesh Patel [mailto:pragnesh.patel@sifive.com] > Sent: Thursday, October 22, 2020 2:55 PM > To: u-boot(a)lists.denx.de > Cc: atish.patra(a)wdc.com; palmerdabbelt(a)google.com; bmeng.cn(a)gmail.com; paul.walmsley(a)sifive.com; anup.patel(a)wdc.com; sagar.kadam(a)sifive.com; Rick Jian-Zhi Chen(陳建志); peter(a)korsgaard.com; Pragnesh Patel; Palmer Dabbelt; Bin Meng; Jagan Teki; Sean Anderson > Subject: [PATCH v2 2/2] riscv: sifive/fu540: kconfig: Enable support for Opencores I2C controller > > Enable support for SiFive FU540 Opencores I2C master controller. > > Signed-off-by: Pragnesh Patel <pragnesh.patel(a)sifive.com> > --- > > (no changes since v1) > > arch/riscv/cpu/fu540/Kconfig | 2 ++ > board/sifive/fu540/Kconfig | 1 + > 2 files changed, 3 insertions(+) > Reviewed-by: Rick Chen <rick(a)andestech.com>

1 0

[PATCH] rockchip: Move Bob specific bits to it's specific u-boot.dtsi
by Peter Robinson 11 Nov '20

11 Nov '20

Move the bits that are device specific to the -u-boot.dtsi as the bits may be different on other devices and hence breaks SPI on those devices such as the Pinebook Pro. Signed-off-by: Peter Robinson <pbrobinson(a)gmail.com> Fixes: c4cea2bbf995 ("rockchip: Enable building a SPI ROM image on bob") Cc: Simon Glass <sjg(a)chromium.org> --- arch/arm/dts/rk3399-gru-u-boot.dtsi | 30 +++++++++++++++++++++++++++++ arch/arm/dts/rk3399-u-boot.dtsi | 25 ------------------------ 2 files changed, 30 insertions(+), 25 deletions(-) diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi b/arch/arm/dts/rk3399-gru-u-boot.dtsi index 390ac2bb5a..5e95cacfea 100644 --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi @@ -5,6 +5,36 @@ #include "rk3399-u-boot.dtsi" +/ { + aliases { + spi1 = &spi1; + }; +}; + +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE +&binman { + rom { + filename = "u-boot.rom"; + size = <0x400000>; + pad-byte = <0xff>; + + mkimage { + args = "-n rk3399 -T rkspi"; + u-boot-spl { + }; + }; + u-boot-img { + offset = <0x40000>; + }; + u-boot { + offset = <0x300000>; + }; + fdtmap { + }; + }; +}; +#endif + &spi_flash { u-boot,dm-pre-reloc; }; diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi index ecd230c720..26b0a34e64 100644 --- a/arch/arm/dts/rk3399-u-boot.dtsi +++ b/arch/arm/dts/rk3399-u-boot.dtsi @@ -11,7 +11,6 @@ mmc0 = &sdhci; mmc1 = &sdmmc; pci0 = &pcie0; - spi1 = &spi1; }; cic: syscon@ff620000 { @@ -60,30 +59,6 @@ }; -#ifdef CONFIG_ROCKCHIP_SPI_IMAGE -&binman { - rom { - filename = "u-boot.rom"; - size = <0x400000>; - pad-byte = <0xff>; - - mkimage { - args = "-n rk3399 -T rkspi"; - u-boot-spl { - }; - }; - u-boot-img { - offset = <0x40000>; - }; - u-boot { - offset = <0x300000>; - }; - fdtmap { - }; - }; -}; -#endif - &cru { u-boot,dm-pre-reloc; }; -- 2.28.0

4 3

[scan-admin@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]
by Tom Rini 10 Nov '20

10 Nov '20

Sadly, when we eliminate defects it doesn't say which ones in an email. -rc2 eliminated one defect and introduced these two new ones. ----- Forwarded message from scan-admin(a)coverity.com ----- Date: Mon, 09 Nov 2020 22:31:55 +0000 (UTC) From: scan-admin(a)coverity.com To: tom.rini(a)gmail.com Subject: New Defects reported by Coverity Scan for Das U-Boot Hi, Please find the latest report on new defect(s) introduced to Das U-Boot found with Coverity Scan. 2 new defect(s) introduced to Das U-Boot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 313047: Control flow issues (DEADCODE) /drivers/core/lists.c: 106 in bind_drivers_pass() ________________________________________________________________________________________________________ *** CID 313047: Control flow issues (DEADCODE) /drivers/core/lists.c: 106 in bind_drivers_pass() 100 dm_warn("No match for driver '%s'\n", entry->name); 101 if (!result || ret != -ENOENT) 102 result = ret; 103 } 104 } 105 >>> CID 313047: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "-11" inside this statement: "return result ? result : (m...". 106 return result ? result : missing_parent ? -EAGAIN : 0; 107 } 108 109 int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only) 110 { 111 int result = 0; ** CID 313046: Uninitialized variables (UNINIT) /test/dm/test-main.c: 202 in dm_test_main() ________________________________________________________________________________________________________ *** CID 313046: Uninitialized variables (UNINIT) /test/dm/test-main.c: 202 in dm_test_main() 196 */ 197 if (!(test->flags & UT_TESTF_LIVE_TREE) && 198 (!runs || dm_test_run_on_flattree(test))) { 199 ut_assertok(dm_do_test(uts, test, false)); 200 runs++; 201 } >>> CID 313046: Uninitialized variables (UNINIT) >>> Using uninitialized value "found". 202 found++; 203 } 204 205 if (test_name && !found) 206 printf("Test '%s' not found\n", test_name); 207 else ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P… To manage Coverity Scan email notifications for "tom.rini(a)gmail.com", click https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P… ----- End forwarded message ----- -- Tom

1 0

[rockchip] broken SPI on RockPro64 and other RK3399 targets
by Marcin Juszkiewicz 10 Nov '20

10 Nov '20

I wanted to update U-Boot on my RockPro64 board from some random build of 2020.07-rc with out of tree patches to official one. Built, flashed and then got this: Loading Environment from SPI Flash... Invalid bus 0 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment According to Peter Robinson it happens also on other RK3399 boards. As I had a bit of time I started bisecting and found reason: 16:43 (7s) hrw@puchatek:u-boot$ git bisect good c4cea2bbf995764f325a907061c22ecd6768cf7b is the first bad commit commit c4cea2bbf995764f325a907061c22ecd6768cf7b Author: Simon Glass <sjg(a)chromium.org> Date: Sun Jul 19 13:55:58 2020 -0600 rockchip: Enable building a SPI ROM image on bob Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot produces a ROM for bob. Signed-off-by: Simon Glass <sjg(a)chromium.org> arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++++ arch/arm/dts/rk3399-gru.dtsi | 2 +- arch/arm/dts/rk3399-u-boot.dtsi | 27 +++++++++++++++++++++++++++ arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++ 4 files changed, 34 insertions(+), 1 deletion(-) Then I checked out HEAD of master branch, reverted that patch and SPI flash got detected properly. Not looked yet on how it should be fixed.

3 4

RPi3: serial console
by Heinrich Schuchardt 10 Nov '20

10 Nov '20

Hello Matthias, I have upgraded the Raspberry 3 firmware from raspi3-firmware (1.20190215-1+deb10u4) to raspi-firmware (1.20200601-3) [https://packages.debian.org/bullseye/raspi-firmware]. After the upgrade the output of U-Boot on the serial console is complete gibberish as if the baudrate were incorrect. The output from the Linux kernel is fine at 115200 baud. I observe this both with rpi_3_defconfig and rpi_arm64_defconfig, v2020.10 and current origin/master. config.txt: arm_control=0x200 enable_uart=1 upstream_kernel=1 kernel=u-boot.bin boot.scr: setenv autoload no dhcp load mmc 0:1 $fdt_addr_r bcm2710-rpi-3-b-plus.dtb load mmc 0:2 $kernel_addr_r EFI/debian/grubaa64.efi bootefi $kernel_addr_r $fdt_addr_r Best regards Heinrich

5 7

Uboot SERDES configuration for PCIEx4 on mvebu 38x
by Tyler S 10 Nov '20

10 Nov '20

Hi, I am trying to create a pcie x4 interface using a standard SERDES map on a Marvell 38x chip (MV88F6828) in Uboot 2019.01. However lane verification prevents me from enabling the pcie x4 configuration. The closest example I can find is this slm1363 board from this file: https://github.com/u-boot/u-boot/blob/3d4825446e4258192e1f2302d691a8c0c82a0… : struct serdes_map db_config_slm1363_d[MAX_SERDES_LANES] = { {PEX0, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X4, 0, 0}, {PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X4, 0, 0}, {PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X4, 0, 0}, {PEX3, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X4, 0, 0}, {USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0}, {USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0} } This is exactly the config I want. However that board was patched out in this commit https://github.com/u-boot/u-boot/commit/544acb07ecebc096c9449e675481ba28031… due to it being an unsupported topology? If I configure uboot for my board using the example above, I get the following output: board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 5 | PCIe0 | | 1 | 5 | PCIe1 | | 2 | 5 | PCIe2 | | 3 | 5 | PCIe3 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 | -------------------------------- hws_serdes_topology_verify: Warning: serdes lane 2 is set to type PCIe2. hws_serdes_topology_verify: Maximum supported lanes are already set to this type (limit = 4) hws_update_serdes_phy_selectors: SerDes lane #2 is disabled hws_serdes_topology_verify: Warning: serdes lane 3 is set to type PCIe3. hws_serdes_topology_verify: Maximum supported lanes are already set to this type (limit = 4) hws_update_serdes_phy_selectors: SerDes lane #3 is disabled board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 5 | PCIe0 | | 1 | 5 | PCIe1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 | -------------------------------- If I comment out the SERDES lane verification in arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c, it seems I can configure the x4 link successfully and recognize the drive that is connected. Can anyone shed some light on the proper way to configure the serdes map for pcie x4? Thanks! Tyler

1 0

[ANN] U-Boot v2021.01-rc2 released
by Tom Rini 10 Nov '20

10 Nov '20

Hey all, It's regular release day and I'm back on schedule, so here's -rc2. There's a few small'ish things outstanding in my queue, and a queue of things building up for -next already. I'm going to try and make sure what I pull in, even when a clean-up, is as close as can be to the obviously correct side of things. Yes, this should always be the case, I'm just going to try and hold myself to expectations a bit harder. In terms of a changelog, git log --merges v2021.01-rc1..v2021.01-rc2 contains what I've pulled but as always, better PR messages and tags will provide better results here. I do have my reminders setup for doing -rc releases every other Monday from here on out and final release on January 11th, 2021. Thanks all! -- Tom

3 7