May 2021 - U-Boot

[PATCH 1/3] Revert "sama5d3: Fix Galois Field Table offsets"
by Tudor Ambarus 07 Jun '21

07 Jun '21

This reverts commit 786f888b743e9b83c9095cb9b5548ebe2e29afc5. Looks like the datasheet at https://ww1.microchip.com/downloads/en/DeviceDoc/SAMA5D3-Series-Data-sheet-… is wrong, and the testing was poorly done, because the PMECC did not raise any error, but also didn't correct any bitflips. Restoring the offsets as they were before, makes the PMECC on sama5d3x capable of correcting bitflips. Fixes: 786f888b74 ("sama5d3: Fix Galois Field Table offsets") Signed-off-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> --- arch/arm/mach-at91/include/mach/sama5d3.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-at91/include/mach/sama5d3.h b/arch/arm/mach-at91/include/mach/sama5d3.h index f4f05676f7..83f18a8148 100644 --- a/arch/arm/mach-at91/include/mach/sama5d3.h +++ b/arch/arm/mach-at91/include/mach/sama5d3.h @@ -190,8 +190,8 @@ /* * PMECC table in ROM */ -#define ATMEL_PMECC_INDEX_OFFSET_512 0x8000 -#define ATMEL_PMECC_INDEX_OFFSET_1024 0x10000 +#define ATMEL_PMECC_INDEX_OFFSET_512 0x10000 +#define ATMEL_PMECC_INDEX_OFFSET_1024 0x18000 /* * SAMA5D3 specific prototypes -- 2.25.1

2 3

[PATCH] arm: bootm: wrong lmb region reservation when PRAM is used
by Aleksandar Gerasimovski 07 Jun '21

07 Jun '21

This is a draft patch to describe the problem and to initiate a discussion for solution. PRAM usage is not taken into account when reserving lmb for ARM architecture, this means that predefined PRAM region is reserved by the u-boot and cannot be used by the u-boot users. In our case this bug leads to non functional ramfs boot, as the PRAM and ram rootfs address ranges are getting reserved by the u-boot. It is obvious that here PRAM region is ignored, but my question is is this clear to everyone and expected? Taking board_f.c as reference, when calculating relocation address PRAM area is taken into account so I would expect that to be case here. Here the intention is to reserve unused space at the end of the effective RAM but PRAM is not part of that. Possible solution would be to introduce something like get_effective_memsize here e.g powerpc/lib/bootm.c but then also NR_DRAM_BANKS has to be considered? Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski(a)hitachi-powergrids.com> --- arch/arm/lib/bootm.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 11af9e2..4b06d25 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -54,7 +54,7 @@ static ulong get_sp(void) void arch_lmb_reserve(struct lmb *lmb) { - ulong sp, bank_end; + ulong sp, bank_end, pram = 0; int bank; /* @@ -69,6 +69,11 @@ void arch_lmb_reserve(struct lmb *lmb) sp = get_sp(); debug("## Current stack ends at 0x%08lx ", sp); +#ifdef CONFIG_PRAM + pram = env_get_ulong("pram", 10, CONFIG_PRAM); + pram = pram << 10; /* size is in kB */ +#endif + /* adjust sp by 4K to be safe */ sp -= 4096; for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) { @@ -76,8 +81,9 @@ void arch_lmb_reserve(struct lmb *lmb) sp < gd->bd->bi_dram[bank].start) continue; /* Watch out for RAM at end of address space! */ + /* @todo: pram obviously wrong if NR_DRAM_BANKS > 1 */ bank_end = gd->bd->bi_dram[bank].start + - gd->bd->bi_dram[bank].size - 1; + gd->bd->bi_dram[bank].size - pram - 1; if (sp > bank_end) continue; if (bank_end > gd->ram_top) -- 1.8.3.1

3 4

[PATCH] mtd: spinand: macronix: Add support for serial NAND flash
by Jaime Liao 07 Jun '21

07 Jun '21

Macronix NAND Flash devices are available in different configurations and densities. MX"35" means SPI NAND MX35"LF"/"UF" , LF means 3V and UF meands 1.8V MX35LF"2G" , 2G means 2Gbits MX35LF2G"E4"/"24"/"14", E4 means internal ECC and Quad I/O(x4) 24 means 8-bit ecc requirement and Quad I/O(x4) 14 means 4-bit ecc requirement and Quad I/O(x4) MX35LF2G14AC is 3V 2Gbit serial NAND flash device (without on-die ECC) https://www.mxic.com.tw/Lists/Datasheet/Attachments/7926/MX35LF2G14AC,%203V… MX35UF4G24AD/MX35UF2G24AD/MX35UF1G24AD is 1.8V 4Gbit serial NAND flash device (without on-die ECC) https://www.mxic.com.tw/Lists/Datasheet/Attachments/7980/MX35UF4G24AD,%201.… MX35UF4GE4AD/MX35UF2GE4AD/MX35UF1GE4AD are 1.8V 4G/2Gbit serial NAND flash device with 8-bit on-die ECC https://www.mxic.com.tw/Lists/Datasheet/Attachments/7983/MX35UF4GE4AD,%201.… MX35UF2GE4AC/MX35UF1GE4AC are 1.8V 2G/1Gbit serial NAND flash device with 8-bit on-die ECC https://www.mxic.com.tw/Lists/Datasheet/Attachments/7974/MX35UF2GE4AC,%201.… MX35UF2G14AC/MX35UF1G14AC are 1.8V 2G/1Gbit serial NAND flash device (without on-die ECC) https://www.mxic.com.tw/Lists/Datasheet/Attachments/7931/MX35UF2G14AC,%201.… Validated via normal(default) and QUAD mode by read, erase, read back, on Xilinx Zynq PicoZed FPGA board which included Macronix SPI Host(drivers/spi/spi-mxic.c). Signed-off-by: Jaime Liao <jaimeliao(a)mxic.com.tw> --- drivers/mtd/nand/spi/macronix.c | 100 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c index 215f09a..8a33dce 100644 --- a/drivers/mtd/nand/spi/macronix.c +++ b/drivers/mtd/nand/spi/macronix.c @@ -114,6 +114,106 @@ static const struct spinand_info macronix_spinand_table[] = { &update_cache_variants), SPINAND_HAS_QE_BIT, SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, NULL)), + SPINAND_INFO("MX35LF2G14AC", 0x20, + NAND_MEMORG(1, 2048, 64, 64, 2048, 2, 1, 1), + NAND_ECCREQ(4, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + SPINAND_INFO("MX35UF4G24AD", 0xb5, + NAND_MEMORG(1, 4096, 256, 64, 2048, 2, 1, 1), + NAND_ECCREQ(8, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + SPINAND_INFO("MX35UF4GE4AD", 0xb7, + NAND_MEMORG(1, 4096, 256, 64, 2048, 1, 1, 1), + NAND_ECCREQ(8, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + SPINAND_INFO("MX35UF2G14AC", 0xa0, + NAND_MEMORG(1, 2048, 64, 64, 2048, 2, 1, 1), + NAND_ECCREQ(4, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + SPINAND_INFO("MX35UF2G24AD", 0xa4, + NAND_MEMORG(1, 2048, 128, 64, 2048, 2, 1, 1), + NAND_ECCREQ(8, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + SPINAND_INFO("MX35UF2GE4AD", 0xa6, + NAND_MEMORG(1, 2048, 128, 64, 2048, 1, 1, 1), + NAND_ECCREQ(8, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + SPINAND_INFO("MX35UF2GE4AC", 0xa2, + NAND_MEMORG(1, 2048, 64, 64, 2048, 1, 1, 1), + NAND_ECCREQ(4, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + SPINAND_INFO("MX35UF1G14AC", 0x90, + NAND_MEMORG(1, 2048, 64, 64, 1024, 1, 1, 1), + NAND_ECCREQ(4, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + SPINAND_INFO("MX35UF1G24AD", 0x94, + NAND_MEMORG(1, 2048, 128, 64, 1024, 1, 1, 1), + NAND_ECCREQ(8, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + SPINAND_INFO("MX35UF1GE4AD", 0x96, + NAND_MEMORG(1, 2048, 128, 64, 1024, 1, 1, 1), + NAND_ECCREQ(8, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + SPINAND_INFO("MX35UF1GE4AC", 0x92, + NAND_MEMORG(1, 2048, 64, 64, 1024, 1, 1, 1), + NAND_ECCREQ(4, 512), + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, + SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, + mx35lf1ge4ab_ecc_get_status)), + }; static int macronix_spinand_detect(struct spinand_device *spinand) -- 1.9.1

4 4

[PATCH v2 1/2] of: addr: Translate 'dma-ranges' for parent nodes missing 'dma-ranges'
by Bin Meng 05 Jun '21

05 Jun '21

'dma-ranges' frequently exists without parent nodes having 'dma-ranges'. While this is an error for 'ranges', this is fine because DMA capable devices always have a translatable DMA address. Also, with no 'dma-ranges' at all, the assumption is that DMA addresses are 1:1 with no restrictions unless perhaps the device itself has implicit restrictions. This keeps in sync with Linux kernel commit: 81db12ee15cb: of/address: Translate 'dma-ranges' for parent nodes missing 'dma-ranges' Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> Reviewed-by: Simon Glass <sjg(a)chromium.org> --- Changes in v2: - rebase on top of Dario's revert patch: http://patchwork.ozlabs.org/project/uboot/patch/20210425141746.19115-6-dari… - drop commit "of: addr: Abort address translation for parent nodes missing 'ranges'", as the revert patch restores the abort behavior drivers/core/of_addr.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c index 9b77308182..a3af48fd88 100644 --- a/drivers/core/of_addr.c +++ b/drivers/core/of_addr.c @@ -192,9 +192,13 @@ static int of_translate_one(const struct device_node *parent, * * As far as we know, this damage only exists on Apple machines, so * This code is only enabled on powerpc. --gcl + * + * This quirk also applies for 'dma-ranges' which frequently exist in + * child nodes without 'dma-ranges' in the parent nodes. --RobH */ ranges = of_get_property(parent, rprop, &rlen); - if (ranges == NULL && !of_empty_ranges_quirk(parent)) { + if (ranges == NULL && !of_empty_ranges_quirk(parent) && + strcmp(rprop, "dma-ranges")) { debug("no ranges; cannot translate\n"); return 1; } -- 2.25.1

2 8

[PATCH] pwm: cros_ec: Rename "priv_auto_alloc_size" to "priv_auto"
by Alper Nebi Yasak 05 Jun '21

05 Jun '21

With commit 41575d8e4c33 ("dm: treewide: Rename auto_alloc_size members to be shorter") "priv_auto_alloc_size" was renamed to "priv_auto". This driver was sent to the mailing list before that change, merged after it, and still has the old form. Apply the rename here as well. Fixes: 1b9ee2882e6b ("pwm: Add a driver for Chrome OS EC PWM") Signed-off-by: Alper Nebi Yasak <alpernebiyasak(a)gmail.com> --- drivers/pwm/cros_ec_pwm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/cros_ec_pwm.c b/drivers/pwm/cros_ec_pwm.c index 44f4105dfd54..4a39c319aa2a 100644 --- a/drivers/pwm/cros_ec_pwm.c +++ b/drivers/pwm/cros_ec_pwm.c @@ -80,5 +80,5 @@ U_BOOT_DRIVER(cros_ec_pwm) = { .id = UCLASS_PWM, .of_match = cros_ec_pwm_ids, .ops = &cros_ec_pwm_ops, - .priv_auto_alloc_size = sizeof(struct cros_ec_pwm_priv), + .priv_auto = sizeof(struct cros_ec_pwm_priv), }; -- 2.31.1

2 3

[PATCH 1/1] sandbox: correct determination of the text base
by Heinrich Schuchardt 05 Jun '21

05 Jun '21

os_find_text_base() assumes that first line of /proc/self/maps holds information about the text. Hence we must call the function before calling os_malloc() which calls mmap(0x10000000,). Failure to do so has led to incorrect values for pc_reloc when an exception was reported => exception undefined Illegal instruction pc = 0x5628d82e9d3c, pc_reloc = 0x5628c82e9d3c as well as incorrect output of the bdinfo command => bdinfo relocaddr = 0x0000000007858000 reloc off = 0x0000000010000000 Fixes: b308d9fd18fa ("sandbox: Avoid using malloc() for system state") Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- This patch must be applied after [PATCH 1/1] sandbox: ensure that state->ram_buf is in low memory --- arch/sandbox/cpu/start.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c index 1388dba895..4000bcc4f1 100644 --- a/arch/sandbox/cpu/start.c +++ b/arch/sandbox/cpu/start.c @@ -435,10 +435,13 @@ void sandbox_reset(void) int main(int argc, char *argv[]) { struct sandbox_state *state; + void * text_base; gd_t data; int size; int ret; + text_base = os_find_text_base(); + /* * This must be the first invocation of os_malloc() to have * state->ram_buf in the low 4 GiB. @@ -459,7 +462,7 @@ int main(int argc, char *argv[]) memset(&data, '\0', sizeof(data)); gd = &data; - gd->arch.text_base = os_find_text_base(); + gd->arch.text_base = text_base; state = state_get_current(); if (os_parse_args(state, argc, argv)) -- 2.30.2

2 2

[PATCH v2 0/2] dm: core: Add address translation in fdt_get_resource - fixes
by Patrick Delaunay 05 Jun '21

05 Jun '21

Hi, This serie push again 2 modifications proposed in previous serie V3 [1] but missing in master branch as only patchset V1 [2] is merged. The first patch solves a issue see by horatiu.vultur(a)microchip.com in V1 [2]. Regards, Patrick [1] [v3] dm: core: Add address translation in fdt_get_resource http://patchwork.ozlabs.org/project/uboot/list/?series=242010&state=* [2] dm: core: Add address translation in fdt_get_resource http://patchwork.ozlabs.org/project/uboot/list/?series=237557&state=* Changes in v2: - Add reviewed-by - Add reviewed-by - use lower-case hex Patrick Delaunay (2): net: luton: remove address translation after ofnode_read_resource test: add dm_test_read_resource drivers/net/mscc_eswitch/luton_switch.c | 5 +--- test/dm/test-fdt.c | 33 +++++++++++++++++++++++++ 2 files changed, 34 insertions(+), 4 deletions(-) -- 2.17.1

2 4

[PATCH u-boot-marvell 1/2] arm: mvebu: turris_omnia: update rescue mode boot command
by Marek Behún 04 Jun '21

04 Jun '21

Update rescue mode boot command on Turris Omnia. We are compressing the image with lzma now. Signed-off-by: Marek Behún <marek.behun(a)nic.cz> --- board/CZ.NIC/turris_omnia/turris_omnia.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c b/board/CZ.NIC/turris_omnia/turris_omnia.c index 1d3cefe703..d3de8004eb 100644 --- a/board/CZ.NIC/turris_omnia/turris_omnia.c +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c @@ -349,10 +349,15 @@ static int set_regdomain(void) "mw.l 0x01000000 0x00ff000c; " \ "i2c write 0x01000000 0x2a.1 0x5 4 -s; " \ "setenv bootargs \"earlyprintk console=ttyS0,115200" \ - " omniarescue=$omnia_reset\"; " \ + " omniarescue=$omnia_reset rescue_mode=$omnia_reset\"; " \ "sf probe; " \ "sf read 0x1000000 0x100000 0x700000; " \ - "bootm 0x1000000; " \ + "lzmadec 0x1000000 0x1700000; " \ + "if gpio input gpio@71_4; then " \ + "bootm 0x1700000#sfp; " \ + "else " \ + "bootm 0x1700000; " \ + "fi; " \ "bootz 0x1000000" static void handle_reset_button(void) -- 2.26.3

3 7

[PATCH 1/6] arm: a37xx: pci: Don't put link into LTSSM Recovery state during probe
by Pali Rohár 04 Jun '21

04 Jun '21

During our debugging of the Aardvark driver in Linux we have discovered that the PCIE_CORE_LINK_CTRL_STAT_REG register in fact controls standard PCIe Link Control Register for PCIe Root Bridge. This led us to discover that the name of the PCIE_CORE_LINK_TRAINING macro and the corresponding comment by this macro's usage is misleading; this bit in fact controls Retrain Link, which, according to PCIe base spec is defined as: A write of 1b to this bit initiates Link retraining by directing the Physical Layer LTSSM to the Recovery state. If the LTSSM is already in Recovery or Configuration, re-entering Recovery is permitted but not required. Entering Recovery state is normally done from LTSSM L0, L0s and L1 states. But since the pci-aardvark.c driver enables Link Training just a few lines above, the controller is not in L0 ready state yet. So setting aardvark bit PCIE_CORE_LINK_TRAINING does not actually enter Recovery state at this place. Moreover, trying to enter LTSSM Recovery state without other configuration is causing issues for some cards (e.g. Atheros AR9xxx and QCA9xxx). Since Recovery state is not entered, these issues are not triggered. Remove code which tries to enter LTSSM Recovery state completely. Signed-off-by: Pali Rohár <pali(a)kernel.org> Reviewed-by: Marek Behún <marek.behun(a)nic.cz> --- drivers/pci/pci-aardvark.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c index c43d4f309b19..06c567e236f9 100644 --- a/drivers/pci/pci-aardvark.c +++ b/drivers/pci/pci-aardvark.c @@ -613,11 +613,6 @@ static int pcie_advk_setup_hw(struct pcie_advk *pcie) reg |= PIO_CTRL_ADDR_WIN_DISABLE; advk_writel(pcie, reg, PIO_CTRL); - /* Start link training */ - reg = advk_readl(pcie, PCIE_CORE_LINK_CTRL_STAT_REG); - reg |= PCIE_CORE_LINK_TRAINING; - advk_writel(pcie, reg, PCIE_CORE_LINK_CTRL_STAT_REG); - /* Wait for PCIe link up */ if (pcie_advk_wait_for_link(pcie)) return -ENXIO; -- 2.20.1

3 25

[BUG] network is broken on Orange Pi PC
by Heinrich Schuchardt 03 Jun '21

03 Jun '21

Dear all, network is broken in U-Boot on orangepi_pc_defconfig: U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56 +0000) Allwinner Technology eth0: ethernet@1c30000 => dhcp sun8i_emac_eth_start: Timeout Best regards Heinrich

4 10