February 2020 - U-Boot

[PATCH] tiny-printf: revert patch to fix spl eth boot
by Moses Christopher 25 Feb '20

25 Feb '20

From: Moses Christopher Bollavarapu <moseschristopherb(a)gmail.com> - Revert commit 831c16111959 ("tiny-printf: Reorder code to support %p") The mentioned commit does not handle the ethaddr properly. Hence, I tried to disable SPL_TINY_PRINTF, but then it was suggested to keep using the tiny-printf library in SPL and revert the patch that caused the issue. - The issue is observed in both Beaglebone Black and Guardian Board, while trying to boot the board using USB-ETH in SPL stage. Signed-off-by: Moses Christopher Bollavarapu <moseschristopherb(a)gmail.com> --- lib/tiny-printf.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c index 1138c7012a..8ee0ffb9ca 100644 --- a/lib/tiny-printf.c +++ b/lib/tiny-printf.c @@ -268,20 +268,10 @@ static int _vprintf(struct printf_info *info, const char *fmt, va_list va) } break; case 'p': -#ifdef DEBUG pointer(info, fmt, va_arg(va, void *)); - /* - * Skip this because it pulls in _ctype which is - * 256 bytes, and we don't generally implement - * pointer anyway - */ while (isalnum(fmt[0])) fmt++; break; -#else - islong = true; - /* no break */ -#endif case 'x': if (islong) { num = va_arg(va, unsigned long); -- 2.20.1

1 0

[PATCH 1/4] nand: raw: Do not free xnand structure
by Michal Simek 25 Feb '20

25 Feb '20

xnand structure is private data structure and it is handled by core and probe shouldn't touch it. Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- drivers/mtd/nand/raw/zynq_nand.c | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/drivers/mtd/nand/raw/zynq_nand.c b/drivers/mtd/nand/raw/zynq_nand.c index 28db4153f5e0..703914969289 100644 --- a/drivers/mtd/nand/raw/zynq_nand.c +++ b/drivers/mtd/nand/raw/zynq_nand.c @@ -1081,18 +1081,18 @@ static int zynq_nand_probe(struct udevice *dev) u8 set_feature[4] = {ONDIE_ECC_FEATURE_ENABLE, 0x00, 0x00, 0x00}; unsigned long ecc_cfg; int ondie_ecc_enabled = 0; - int err = -1; int is_16bit_bw; smc->reg = (struct zynq_nand_smc_regs *)dev_read_addr(dev); of_nand = dev_read_subnode(dev, "flash@e1000000"); if (!ofnode_valid(of_nand)) { printf("Failed to find nand node in dt\n"); - goto fail; + return -ENODEV; } + if (ofnode_read_resource(of_nand, 0, &res)) { printf("Failed to get nand resource\n"); - goto fail; + return -ENODEV; } xnand->nand_base = (void __iomem *)res.start; @@ -1119,7 +1119,7 @@ static int zynq_nand_probe(struct udevice *dev) if (is_16bit_bw == NAND_BW_UNKNOWN) { printf("%s: Unable detect NAND based on MIO settings\n", __func__); - goto fail; + return -EINVAL; } if (is_16bit_bw == NAND_BW_16BIT) @@ -1130,13 +1130,13 @@ static int zynq_nand_probe(struct udevice *dev) /* Initialize the NAND flash interface on NAND controller */ if (zynq_nand_init_nand_flash(mtd, nand_chip->options) < 0) { printf("%s: nand flash init failed\n", __func__); - goto fail; + return -EINVAL; } /* first scan to find the device and get the page size */ if (nand_scan_ident(mtd, 1, NULL)) { printf("%s: nand_scan_ident failed\n", __func__); - goto fail; + return -EINVAL; } /* Send the command for reading device ID */ nand_chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1); @@ -1261,14 +1261,12 @@ static int zynq_nand_probe(struct udevice *dev) /* Second phase scan */ if (nand_scan_tail(mtd)) { printf("%s: nand_scan_tail failed\n", __func__); - goto fail; + return -EINVAL; } if (nand_register(0, mtd)) - goto fail; + return -EINVAL; + return 0; -fail: - free(xnand); - return err; } static const struct udevice_id zynq_nand_dt_ids[] = { -- 2.25.1

1 3

[PATCH v2 0/5] make htmldocs in CI
by Heinrich Schuchardt 25 Feb '20

25 Feb '20

This patch series provides a htmldocs target for Travis, Gitlab and Azure CI. doc/sphinx/kerneldoc.py is updated to avoid a build warning with current Sphinx. The last patch turns build warnings of 'make htmldocs' into errors. While first four patches can be immediately merged the last patch requires an updated Docker image, cf. [PATCH 1/1] Dockerfile: add imagemagick https://lists.denx.de/pipermail/u-boot/2020-February/400983.html v2: update update doc/sphinx/kerneldoc.py change sequence of targets in Travis Ci change a commit message Heinrich Schuchardt (5): doc: update doc/sphinx/kerneldoc.py travis: build HTML docs gitlab: build HTML documentation azure: build HTML documentation doc/Makefile: turn warnings into errors .azure-pipelines.yml | 10 ++++++++ .gitlab-ci.yml | 7 ++++++ .travis.yml | 5 ++++ doc/Makefile | 1 + doc/sphinx/kerneldoc.py | 51 +++++++++++++++++++++++++++++++---------- 5 files changed, 62 insertions(+), 12 deletions(-) -- 2.25.0

3 12

[PATCH] Azure / GitLab: Update Docker image
by Tom Rini 25 Feb '20

25 Feb '20

Bring in a newer Docker image to build on that has everything required for running 'make htmldocs'. Signed-off-by: Tom Rini <trini(a)konsulko.com> --- .azure-pipelines.yml | 2 +- .gitlab-ci.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index c22095830c0c..c2f7f0f1337a 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -1,7 +1,7 @@ variables: windows_vm: vs2017-win2016 ubuntu_vm: ubuntu-18.04 - ci_runner_image: trini/u-boot-gitlab-ci-runner:bionic-20200112-07Feb2020 + ci_runner_image: trini/u-boot-gitlab-ci-runner:bionic-20200112-21Feb2020 # Add '-u 0' options for Azure pipelines, otherwise we get "permission # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer", # since our $(ci_runner_image) user is not root. diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index d486e72042fb..a525ea2ce020 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -2,7 +2,7 @@ # Grab our configured image. The source for this is found at: # https://gitlab.denx.de/u-boot/gitlab-ci-runner -image: trini/u-boot-gitlab-ci-runner:bionic-20200112-07Feb2020 +image: trini/u-boot-gitlab-ci-runner:bionic-20200112-21Feb2020 # We run some tests in different order, to catch some failures quicker. stages: -- 2.17.1

1 1

[PATCH v2] arm: imx6: configure NoC on i.MX6DQP
by Bernhard Messerklinger 25 Feb '20

25 Feb '20

The i.MX6DP and i.MX6QP incorporate NoC interconnect logic which needs to be configured in order to use external DDR memory. This patch enables the SPL to configure the necessary registers in accordance with the NXP engineering bulletin EB828. Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger(a)br-automation.com> --- This patch is a revised version of the patch "arm: imx6: configure NoC on i.MX6DQP" from the original author Filip Brozovic <fbrozovic(a)gmail.com>. It takes care of the review notes for the original patch. patchwork: https://patchwork.ozlabs.org/patch/670208/ mail-archive: https://lists.denx.de/pipermail/u-boot/2016-September/266667.html I'm not sure how to handle a patch which is based on a patch from another author. Guidance from the maintainers regarding this question would be welcome. My assumption would be that this can be solved by adding "Co-Developed-by:" and "Signed-off-by:" lines to this patch for Filip Brozovic (see [1] for a discussion of this topic on LKML). Filip, would this be ok for you? [1] http://lkml.iu.edu/hypermail/linux/kernel/1711.2/00256.html Changes in v2: - Added missing link to lkml discussion arch/arm/include/asm/arch-mx6/mx6-ddr.h | 19 +++++ arch/arm/mach-imx/mx6/ddr.c | 96 +++++++++++++++++++++++++ 2 files changed, 115 insertions(+) diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h b/arch/arm/include/asm/arch-mx6/mx6-ddr.h index 19d2f1d9c5..25168c9865 100644 --- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h +++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h @@ -307,6 +307,25 @@ struct mx6dq_iomux_grp_regs { u32 grp_b6ds; }; +/* + * NoC scheduler registers - only on IMX6DQP + */ +#define MX6DQP_NOC_SCHED_BASE 0x00bb0000 +struct mx6dqp_noc_sched_regs { + u32 coreid; + u32 revid; + u32 ddrconf; + u32 ddrtiming; + u32 ddrmode; + u32 rlat; + u32 res1[4]; + u32 ipu1; + u32 ipu2; + u32 res2[2]; + u32 activate; + u32 res3[16]; +}; + #define MX6SDL_IOM_DDR_BASE 0x020e0400 struct mx6sdl_iomux_ddr_regs { u32 res1[25]; diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c index 6e5e40dd1a..3521d8eac7 100644 --- a/arch/arm/mach-imx/mx6/ddr.c +++ b/arch/arm/mach-imx/mx6/ddr.c @@ -936,6 +936,27 @@ void mx6sdl_dram_iocfg(unsigned width, mmdc1->entry = value; \ } while (0) +/* see BOOT_CFG3 description Table 5-4. EIM Boot Fusemap */ +#define BOOT_CFG3_DDR_MASK 0x30 +#define BOOT_CFG3_EXT_DDR_MASK 0x33 + +#define DDR_MMAP_NOC_SINGLE 0 +#define DDR_MMAP_NOC_DUAL 0x31 + +/* NoC ACTIVATE shifts */ +#define NOC_RD_SHIFT 0 +#define NOC_FAW_PERIOD_SHIFT 4 +#define NOC_FAW_BANKS_SHIFT 10 + +/* NoC DdrTiming shifts */ +#define NOC_ACT_TO_ACT_SHIFT 0 +#define NOC_RD_TO_MISS_SHIFT 6 +#define NOC_WR_TO_MISS_SHIFT 12 +#define NOC_BURST_LEN_SHIFT 18 +#define NOC_RD_TO_WR_SHIFT 21 +#define NOC_WR_TO_RD_SHIFT 26 +#define NOC_BW_RATIO_SHIFT 31 + /* * According JESD209-2B-LPDDR2: Table 103 * WL: write latency @@ -1225,6 +1246,8 @@ void mx6_ddr3_cfg(const struct mx6_ddr_sysinfo *sysinfo, { volatile struct mmdc_p_regs *mmdc0; volatile struct mmdc_p_regs *mmdc1; + struct src *src_regs = (struct src *)SRC_BASE_ADDR; + u8 soc_boot_cfg3 = (readl(&src_regs->sbmr1) >> 16) & 0xff; u32 val; u8 tcke, tcksrx, tcksre, txpdll, taofpd, taonpd, trrd; u8 todtlon, taxpd, tanpd, tcwl, txp, tfaw, tcl; @@ -1517,6 +1540,79 @@ void mx6_ddr3_cfg(const struct mx6_ddr_sysinfo *sysinfo, /* Step 12: Configure and activate periodic refresh */ mmdc0->mdref = (sysinfo->refsel << 14) | (sysinfo->refr << 11); + /* + * Step 13: i.MX6DQP only: If the NoC scheduler is enabled, + * configure it and disable MMDC arbitration/reordering (see EB828) + */ + if (is_mx6dqp() && + ((soc_boot_cfg3 & BOOT_CFG3_DDR_MASK) == DDR_MMAP_NOC_SINGLE || + (soc_boot_cfg3 & BOOT_CFG3_EXT_DDR_MASK) == DDR_MMAP_NOC_DUAL)) { + struct mx6dqp_noc_sched_regs *noc_sched = + (struct mx6dqp_noc_sched_regs *)MX6DQP_NOC_SCHED_BASE; + + /* + * These values are fixed based on integration parameters and + * should not be modified + */ + noc_sched->rlat = 0x00000040; + noc_sched->ipu1 = 0x00000020; + noc_sched->ipu2 = 0x00000020; + + noc_sched->activate = (1 << NOC_FAW_BANKS_SHIFT) | + (tfaw << NOC_FAW_PERIOD_SHIFT) | + (trrd << NOC_RD_SHIFT); + noc_sched->ddrtiming = (((sysinfo->dsize == 1) ? 1 : 0) + << NOC_BW_RATIO_SHIFT) | + ((tcwl + twtr) << NOC_WR_TO_RD_SHIFT) | + ((tcl - tcwl + 2) << NOC_RD_TO_WR_SHIFT) | + (4 << NOC_BURST_LEN_SHIFT) | /* BL8 */ + ((tcwl + twr + trp + trcd) + << NOC_WR_TO_MISS_SHIFT) | + ((trtp + trp + trcd - 4) + << NOC_RD_TO_MISS_SHIFT) | + (trc << NOC_ACT_TO_ACT_SHIFT); + + if (sysinfo->dsize == 2) { + if (ddr3_cfg->coladdr == 10) { + if (ddr3_cfg->rowaddr == 15 && + sysinfo->ncs == 2) + noc_sched->ddrconf = 4; + else + noc_sched->ddrconf = 0; + } else if (ddr3_cfg->coladdr == 11) { + noc_sched->ddrconf = 1; + } + } else { + if (ddr3_cfg->coladdr == 9) { + if (ddr3_cfg->rowaddr == 13) + noc_sched->ddrconf = 2; + else if (ddr3_cfg->rowaddr == 14) + noc_sched->ddrconf = 15; + } else if (ddr3_cfg->coladdr == 10) { + if (ddr3_cfg->rowaddr == 14 && + sysinfo->ncs == 2) + noc_sched->ddrconf = 14; + else if (ddr3_cfg->rowaddr == 15 && + sysinfo->ncs == 2) + noc_sched->ddrconf = 9; + else + noc_sched->ddrconf = 3; + } else if (ddr3_cfg->coladdr == 11) { + if (ddr3_cfg->rowaddr == 15 && + sysinfo->ncs == 2) + noc_sched->ddrconf = 4; + else + noc_sched->ddrconf = 0; + } else if (ddr3_cfg->coladdr == 12) { + if (ddr3_cfg->rowaddr == 14) + noc_sched->ddrconf = 1; + } + } + + /* Disable MMDC arbitration/reordering */ + mmdc0->maarcr = 0x14420000; + } + /* Step 13: Deassert config request - init complete */ mmdc0->mdscr = 0x00000000; -- 2.25.1

2 1

[U-Boot Patch v2 0/4] Fix currently available support for flash on HiFive Unleashed
by Sagar Shrikant Kadam 25 Feb '20

25 Feb '20

Currently device ID for flash mounted on HiFive Unleashed is added to U-Boot. Also there are few patches about to go in mainline (Thanks to Jagan Tekki and Bin Meng). This series addresses few issues discussed there: Patch 1:Add num-cs to device tree which is used by spi-uclass to detect valid chip select numbers Patch 2:Handles valid chip selects only. Flash device is now detected only on chip select 0. Patch 3:Over-ride spi tx/rx width specified in hifive-unleshed-a00.dts file from 4 to 1 in corresponding -u-boot.dtsi This series is based on mainline commit c05b38df477a ("common: fix regression on block cache init") and two below mentioned patches from [1] [U-Boot,v2,4/5] riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi [U-Boot,v2,5/5] sifive: fu540: Enable spi-nor flash support [1] https://patchwork.ozlabs.org/patch/1177979/ The above series is available for testing here[2] [2] https://github.com/sagsifive/u-boot/tree/dev/sagark/test_spi-nor_v2 Change History: V1-V2: 1. Dropped 6th and 7th patch sent in V1 from this series so as to separate out spi-nor related changes in different series and avoid adding TODO fixes to spi-nor-core framework. 2. Removed patch to include -uboot.dts, as it gets automatically included. 3. Over-ride tx/rx width from hifive-unleashed-a00.dts using hifive -unleashed-a00-u-boot.dtsi 4. Print fdt base address in board info for debugging. V1: First version of series ================Log for reference===================== Flash detection only at valid Chip select => sf probe 0:0 SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB => sf probe 0:1 Invalid cs number = 1 Failed to initialize SPI flash at 0:1 (error -22) => sf probe 0:2 Invalid cs number = 2 Failed to initialize SPI flash at 0:2 (error -22) => sf probe 0:0 SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB =>---------------------------------------------------------------- Full flash memory erase/write/read/validate => mw 0x80600000 0x12348765 0x800000 => sf erase 0x0 0x2000000 SF: 33554432 bytes @ 0x0 Erased: OK => sf write 0x80600000 0x0 0x2000000 device 0 whole chip SF: 33554432 bytes @ 0x0 Written: OK => sf read 0x82600000 0x0 0x2000000 device 0 whole chip SF: 33554432 bytes @ 0x0 Read: OK => cmp.b 0x80600000 0x82600000 0x2000000 Total of 33554432 byte(s) were the same =>---------------------------------------------------------------- Sagar Shrikant Kadam (4): fu540: dtsi: spi: add num-cs info to device tree spi: fu540: add claim and release method to spi-sifive.c dts: u-boot.dtsi: override flash tx-rx width bdinfo: fu540: print fdt base address for debugging arch/riscv/dts/fu540-c000.dtsi | 3 +++ arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 8 ++++++ cmd/bdinfo.c | 1 + drivers/spi/spi-sifive.c | 36 +++++++++++++++++++++++++ 4 files changed, 48 insertions(+) -- 2.7.4

3 18

[PATCH] efi_loader: add some description about UEFI secure boot
by AKASHI Takahiro 25 Feb '20

25 Feb '20

A small text in docs/uefi/uefi.rst was added to explain how we can configure and utilise UEFI secure boot feature on U-Boot. Signed-off-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org> --- doc/uefi/uefi.rst | 77 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst index a8fd886d6b5e..98cd770aefe5 100644 --- a/doc/uefi/uefi.rst +++ b/doc/uefi/uefi.rst @@ -97,6 +97,83 @@ Below you find the output of an example session starting GRUB:: See doc/uImage.FIT/howto.txt for an introduction to FIT images. +Configuring UEFI secure boot +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +UEFI specification[1] defines a secure way of executing UEFI images +by verifying a signature (or message digest) of image with certificates. +This feature on U-Boot is enabled with:: + + CONFIG_UEFI_SECURE_BOOT=y + +To make the boot sequence safe, you need to establish a chain of trust; +In UEFI secure boot, you can make it with the UEFI variables, "PK" +(Platform Key), "KEK" (Key Exchange Keys), "db" (white list database) +and "dbx" (black list database). + +There are many online documents that describe what UEFI secure boot is +and how it works. Please consult some of them for details. + +Here is a simple example that you can follow for your initial attempt +(Please note that the actual steps would absolutely depend on your system +and environment.): + +1. Install utility commands on your host + * openssl + * efitools + * sbsigntool + +2. Create signing keys and key database files on your host + for PK:: + + $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_PK/ \ + -keyout PK.key -out PK.crt -nodes -days 365 + $ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \ + PK.crt PK.esl; + $ sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth + + for KEK:: + + $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_KEK/ \ + -keyout KEK.key -out KEK.crt -nodes -days 365 + $ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \ + KEK.crt KEK.esl + $ sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth + + for db:: + + $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_db/ \ + -keyout db.key -out db.crt -nodes -days 365 + $ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \ + db.crt db.esl + $ sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth + + Copy \*.auth to media, say mmc, that is accessible from U-Boot. + +3. Sign an image with one key in "db" on your host:: + + $ sbsign --key db.key --cert db.crt helloworld.efi + +4. Install keys on your board:: + + ==> fatload mmc 0:1 <tmpaddr> PK.auth + ==> setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize PK + ==> fatload mmc 0:1 <tmpaddr> KEK.auth + ==> setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize KEK + ==> fatload mmc 0:1 <tmpaddr> db.auth + ==> setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize db + +5. Set up boot parameters on your board:: + + ==> efidebug boot add 1 HELLO mmc 0:1 /helloworld.efi.signed "" + +Then your board runs that image from Boot manager (See below). +You can also try this sequence by running Pytest, test_efi_secboot, +on sandbox:: + + $ cd <U-Boot source directory> + $ pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox + Executing the boot manager ~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 2.24.0

3 2

[PATCH v2] env: ti: boot: Fix Android boot on AM57x EVM
by Sam Protsenko 25 Feb '20

25 Feb '20

When applying DTBO on top of DTB (with "fdt apply" command) on AM57x EVM board, there is not enough memory reserved in RAM for DTB blob. Hence, DTBO can't be merged in DTB. It leads to inability to boot Android with next error message: failed on fdt_overlay_apply(): FDT_ERR_NOSPACE To overcome that issue let's provide 512 KiB of space to keep DTB and all merged DTBO blobs. To do so, "length" parameter should be specified for "fdt addr" command: => fdt addr $fdtaddr 0x80000 512 KiB is the maximum size we can use for this, because next address after $fdtaddr is 512 KiB ahead of it: fdtaddr=0x88000000 rdaddr=0x88080000 Also add size variables to 'adtimg' command invocations, to avoid cluttering the console with DTBO blob sizes. Signed-off-by: Sam Protsenko <joe.skb7(a)gmail.com> --- Changes in v2: - Reserve 512 KiB for DTB area, not 1 MiB include/environment/ti/boot.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h index 523c8fc4fe..11a57af0a4 100644 --- a/include/environment/ti/boot.h +++ b/include/environment/ti/boot.h @@ -103,18 +103,18 @@ "echo \" Reading DTB for AM57x EVM RevA3...\"; " \ "abootimg get dtb --index=0 dtb_start dtb_size; " \ "cp.b $dtb_start $fdtaddr $dtb_size; " \ - "fdt addr $fdtaddr; " \ + "fdt addr $fdtaddr 0x80000; " \ "echo \" Applying DTBOs for AM57x EVM RevA3...\"; " \ "adtimg addr $dtboaddr; " \ - "adtimg get dt --index=0 dtbo0_addr; " \ + "adtimg get dt --index=0 dtbo0_addr dtbo0_size; " \ "fdt apply $dtbo0_addr; " \ - "adtimg get dt --index=1 dtbo1_addr; " \ + "adtimg get dt --index=1 dtbo1_addr dtbo1_size; " \ "fdt apply $dtbo1_addr; " \ "elif test $board_name = beagle_x15_revc; then " \ "echo \" Reading DTB for Beagle X15 RevC...\"; " \ "abootimg get dtb --index=0 dtb_start dtb_size; " \ "cp.b $dtb_start $fdtaddr $dtb_size; " \ - "fdt addr $fdtaddr; " \ + "fdt addr $fdtaddr 0x80000; " \ "else " \ "echo Error: Android boot is not supported for $board_name; " \ "exit; " \ -- 2.24.1

3 3

[PATCH] net: phy: marvell: Unify 88E151x series phy_driver
by Clemens Gruber 24 Feb '20

24 Feb '20

The PHY models of the Marvell 88E151x series are not reliably distinguishable by their uid / PHY identifiers. The 88E1510, 88E1512, 88E1514 and 88E1518 all have the same OUI and model number and bits 3:0 in the PHY Identifier 2 (Page 0, Reg 3) are described as HW revision number, but both 88E1510 and 88E1518 PHYs were observed with the same HW rev number (1). Before commit 83cfbeb0df9f ("net: phy: Fix mask so that we can identify Marvell 88E1518"), the 88E151x were detected because the HW revision bits were masked from the uid. After that change, 88E1510/12/18 were all detected as 88E1518 and the 88E1510 specific code was no longer run. I modified the mask to again ignore all four HW revision bits, removed the 88E1510 specific code (board-specific LED/INTn setup), which was not called since late 2016 anyway and renamed the config function and phy_driver struct to the better fitting 88e151x. The uid and mask bits 3:0 are now again the same as in the Linux kernel. Signed-off-by: Clemens Gruber <clemens.gruber(a)pqgruber.com> --- drivers/net/phy/marvell.c | 65 ++++++--------------------------------- 1 file changed, 10 insertions(+), 55 deletions(-) diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index efbbd31ff7..93cf44ad4c 100644 --- a/drivers/net/phy/marvell.c +++ b/drivers/net/phy/marvell.c @@ -303,9 +303,9 @@ static int m88e1111s_config(struct phy_device *phydev) } /** - * m88e1518_phy_writebits - write bits to a register + * m88e151x_phy_writebits - write bits to a register */ -void m88e1518_phy_writebits(struct phy_device *phydev, +void m88e151x_phy_writebits(struct phy_device *phydev, u8 reg_num, u16 offset, u16 len, u16 data) { u16 reg, mask; @@ -323,7 +323,7 @@ void m88e1518_phy_writebits(struct phy_device *phydev, phy_write(phydev, MDIO_DEVAD_NONE, reg_num, reg); } -static int m88e1518_config(struct phy_device *phydev) +static int m88e151x_config(struct phy_device *phydev) { u16 reg; @@ -350,11 +350,11 @@ static int m88e1518_config(struct phy_device *phydev) phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 18); /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */ - m88e1518_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL, + m88e151x_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL, 0, 3, MIIM_88E151x_MODE_SGMII); /* PHY reset is necessary after changing MODE[2:0] */ - m88e1518_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL, + m88e151x_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL, MIIM_88E151x_RESET_OFFS, 1, 1); /* Reset page selection */ @@ -401,33 +401,6 @@ static int m88e1518_config(struct phy_device *phydev) return 0; } -/* Marvell 88E1510 */ -static int m88e1510_config(struct phy_device *phydev) -{ - /* Select page 3 */ - phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, - MIIM_88E1118_PHY_LED_PAGE); - - /* Enable INTn output on LED[2] */ - m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_TIMER_CTRL, - MIIM_88E151x_INT_EN_OFFS, 1, 1); - - /* Configure LEDs */ - /* LED[0]:0011 (ACT) */ - m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_FUNC_CTRL, - MIIM_88E151x_LED0_OFFS, MIIM_88E151x_LED_FLD_SZ, - MIIM_88E151x_LED0_ACT); - /* LED[1]:0110 (LINK 100/1000 Mbps) */ - m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_FUNC_CTRL, - MIIM_88E151x_LED1_OFFS, MIIM_88E151x_LED_FLD_SZ, - MIIM_88E151x_LED1_100_1000_LINK); - - /* Reset page selection */ - phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 0); - - return m88e1518_config(phydev); -} - /* Marvell 88E1118 */ static int m88e1118_config(struct phy_device *phydev) { @@ -685,29 +658,12 @@ static struct phy_driver M88E1149S_driver = { .shutdown = &genphy_shutdown, }; -static struct phy_driver M88E1510_driver = { - .name = "Marvell 88E1510", - .uid = 0x1410dd0, - .mask = 0xfffffff, - .features = PHY_GBIT_FEATURES, - .config = &m88e1510_config, - .startup = &m88e1011s_startup, - .shutdown = &genphy_shutdown, - .readext = &m88e1xxx_phy_extread, - .writeext = &m88e1xxx_phy_extwrite, -}; - -/* - * This supports: - * 88E1518, uid 0x1410dd1 - * 88E1512, uid 0x1410dd4 - */ -static struct phy_driver M88E1518_driver = { - .name = "Marvell 88E1518", +static struct phy_driver M88E151x_driver = { + .name = "Marvell 88E151x", .uid = 0x1410dd0, - .mask = 0xffffffa, + .mask = 0xffffff0, .features = PHY_GBIT_FEATURES, - .config = &m88e1518_config, + .config = &m88e151x_config, .startup = &m88e1011s_startup, .shutdown = &genphy_shutdown, .readext = &m88e1xxx_phy_extread, @@ -744,8 +700,7 @@ int phy_marvell_init(void) phy_register(&M88E1118R_driver); phy_register(&M88E1111S_driver); phy_register(&M88E1011S_driver); - phy_register(&M88E1510_driver); - phy_register(&M88E1518_driver); + phy_register(&M88E151x_driver); phy_register(&M88E1680_driver); return 0; -- 2.25.1

1 0

spi_flash_read issue
by dvo 24 Feb '20

24 Feb '20

Hello, I encounter an issue with spi_flash_read function. I'd copy uboot from SPI Flash to DDRAM. If I use the function once. It works OK. If I use the function is more than 1 time, then it doesn't work properly. Here is the procedure of what I did: uboot version: U-Boot 2019.07-00013-g6107815c9c uboot size: 244288 Bytes case 1: - Copy uboot to 0x81000000 -> Jump to uboot at 0x81000000 OK case 2: - Copy uboot to 0x81000000 - Copy uboot to 0x83000000 -> Jump to uboot at 0x83000000 NOK. Only able to load some parts of uboot and then hang. I hexdump and do memory comparison between 0x81000000 and 0x83000000. The memory is different from i=78078. Do I need to do something in between 2 copies to solve the issue? Has anyone experienced this issue? Thanks for any help or suggestion. Dan -- Sent from: http://u-boot.10912.n7.nabble.com/

2 2