April 2020 - U-Boot

[PATCH v2 1/2] mtd: spi-nand: Import Toshiba SPI-NAND support
by Robert Marko 03 Apr '20

03 Apr '20

Linux has good support for Toshiba SPI-NAND, so lets import it. Signed-off-by: Robert Marko <robert.marko(a)sartura.hr> Tested-by: Luka Kovacic <luka.kovacic(a)sartura.hr> Cc: Luka Perkov <luka.perkov(a)sartura.hr> --- Changes from v1: Refresh to apply due to free() to rfree() rename drivers/mtd/nand/spi/Makefile | 2 +- drivers/mtd/nand/spi/core.c | 1 + drivers/mtd/nand/spi/toshiba.c | 191 +++++++++++++++++++++++++++++++++ include/linux/mtd/spinand.h | 1 + 4 files changed, 194 insertions(+), 1 deletion(-) create mode 100644 drivers/mtd/nand/spi/toshiba.c diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile index dd6bacae34..6c65b187e8 100644 --- a/drivers/mtd/nand/spi/Makefile +++ b/drivers/mtd/nand/spi/Makefile @@ -1,4 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 -spinand-objs := core.o gigadevice.o macronix.o micron.o winbond.o +spinand-objs := core.o gigadevice.o macronix.o micron.o toshiba.o winbond.o obj-$(CONFIG_MTD_SPI_NAND) += spinand.o diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c index cd624ec6ae..397dfa4178 100644 --- a/drivers/mtd/nand/spi/core.c +++ b/drivers/mtd/nand/spi/core.c @@ -835,6 +835,7 @@ static const struct spinand_manufacturer *spinand_manufacturers[] = { &gigadevice_spinand_manufacturer, &macronix_spinand_manufacturer, &micron_spinand_manufacturer, + &toshiba_spinand_manufacturer, &winbond_spinand_manufacturer, }; diff --git a/drivers/mtd/nand/spi/toshiba.c b/drivers/mtd/nand/spi/toshiba.c new file mode 100644 index 0000000000..571104a5d9 --- /dev/null +++ b/drivers/mtd/nand/spi/toshiba.c @@ -0,0 +1,191 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2018 exceet electronics GmbH + * Copyright (c) 2018 Kontron Electronics GmbH + * + * Author: Frieder Schrempf <frieder.schrempf(a)kontron.de> + */ + +#ifndef __UBOOT__ +#include <malloc.h> +#include <linux/device.h> +#include <linux/kernel.h> +#endif +#include <linux/mtd/spinand.h> + +#define SPINAND_MFR_TOSHIBA 0x98 +#define TOSH_STATUS_ECC_HAS_BITFLIPS_T (3 << 4) + +static SPINAND_OP_VARIANTS(read_cache_variants, + SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0), + SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0), + SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0), + SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0)); + +static SPINAND_OP_VARIANTS(write_cache_variants, + SPINAND_PROG_LOAD(true, 0, NULL, 0)); + +static SPINAND_OP_VARIANTS(update_cache_variants, + SPINAND_PROG_LOAD(false, 0, NULL, 0)); + +static int tc58cxgxsx_ooblayout_ecc(struct mtd_info *mtd, int section, + struct mtd_oob_region *region) +{ + if (section > 0) + return -ERANGE; + + region->offset = mtd->oobsize / 2; + region->length = mtd->oobsize / 2; + + return 0; +} + +static int tc58cxgxsx_ooblayout_free(struct mtd_info *mtd, int section, + struct mtd_oob_region *region) +{ + if (section > 0) + return -ERANGE; + + /* 2 bytes reserved for BBM */ + region->offset = 2; + region->length = (mtd->oobsize / 2) - 2; + + return 0; +} + +static const struct mtd_ooblayout_ops tc58cxgxsx_ooblayout = { + .ecc = tc58cxgxsx_ooblayout_ecc, + .rfree = tc58cxgxsx_ooblayout_free, +}; + +static int tc58cxgxsx_ecc_get_status(struct spinand_device *spinand, + u8 status) +{ + struct nand_device *nand = spinand_to_nand(spinand); + u8 mbf = 0; + struct spi_mem_op op = SPINAND_GET_FEATURE_OP(0x30, &mbf); + + switch (status & STATUS_ECC_MASK) { + case STATUS_ECC_NO_BITFLIPS: + return 0; + + case STATUS_ECC_UNCOR_ERROR: + return -EBADMSG; + + case STATUS_ECC_HAS_BITFLIPS: + case TOSH_STATUS_ECC_HAS_BITFLIPS_T: + /* + * Let's try to retrieve the real maximum number of bitflips + * in order to avoid forcing the wear-leveling layer to move + * data around if it's not necessary. + */ + if (spi_mem_exec_op(spinand->slave, &op)) + return nand->eccreq.strength; + + mbf >>= 4; + + if (WARN_ON(mbf > nand->eccreq.strength || !mbf)) + return nand->eccreq.strength; + + return mbf; + + default: + break; + } + + return -EINVAL; +} + +static const struct spinand_info toshiba_spinand_table[] = { + /* 3.3V 1Gb */ + SPINAND_INFO("TC58CVG0S3", 0xC2, + 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), + 0, + SPINAND_ECCINFO(&tc58cxgxsx_ooblayout, + tc58cxgxsx_ecc_get_status)), + /* 3.3V 2Gb */ + SPINAND_INFO("TC58CVG1S3", 0xCB, + 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), + 0, + SPINAND_ECCINFO(&tc58cxgxsx_ooblayout, + tc58cxgxsx_ecc_get_status)), + /* 3.3V 4Gb */ + SPINAND_INFO("TC58CVG2S0", 0xCD, + 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), + 0, + SPINAND_ECCINFO(&tc58cxgxsx_ooblayout, + tc58cxgxsx_ecc_get_status)), + /* 1.8V 1Gb */ + SPINAND_INFO("TC58CYG0S3", 0xB2, + 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), + 0, + SPINAND_ECCINFO(&tc58cxgxsx_ooblayout, + tc58cxgxsx_ecc_get_status)), + /* 1.8V 2Gb */ + SPINAND_INFO("TC58CYG1S3", 0xBB, + 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), + 0, + SPINAND_ECCINFO(&tc58cxgxsx_ooblayout, + tc58cxgxsx_ecc_get_status)), + /* 1.8V 4Gb */ + SPINAND_INFO("TC58CYG2S0", 0xBD, + 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), + 0, + SPINAND_ECCINFO(&tc58cxgxsx_ooblayout, + tc58cxgxsx_ecc_get_status)), +}; + +static int toshiba_spinand_detect(struct spinand_device *spinand) +{ + u8 *id = spinand->id.data; + int ret; + + /* + * Toshiba SPI NAND read ID needs a dummy byte, + * so the first byte in id is garbage. + */ + if (id[1] != SPINAND_MFR_TOSHIBA) + return 0; + + ret = spinand_match_and_init(spinand, toshiba_spinand_table, + ARRAY_SIZE(toshiba_spinand_table), + id[2]); + if (ret) + return ret; + + return 1; +} + +static const struct spinand_manufacturer_ops toshiba_spinand_manuf_ops = { + .detect = toshiba_spinand_detect, +}; + +const struct spinand_manufacturer toshiba_spinand_manufacturer = { + .id = SPINAND_MFR_TOSHIBA, + .name = "Toshiba", + .ops = &toshiba_spinand_manuf_ops, +}; diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h index be01e1e82e..83eafb184e 100644 --- a/include/linux/mtd/spinand.h +++ b/include/linux/mtd/spinand.h @@ -204,6 +204,7 @@ struct spinand_manufacturer { extern const struct spinand_manufacturer gigadevice_spinand_manufacturer; extern const struct spinand_manufacturer macronix_spinand_manufacturer; extern const struct spinand_manufacturer micron_spinand_manufacturer; +extern const struct spinand_manufacturer toshiba_spinand_manufacturer; extern const struct spinand_manufacturer winbond_spinand_manufacturer; /** -- 2.24.1

2 3

[U-Boot] [PATCH 0/2] Add Broadcom SPI driver
by Vladimir Olovyannikov 03 Apr '20

03 Apr '20

This patchset: - adds Broadcom SPI driver for iproc-based platforms and - extends Micron SPI commands for dual and quad SPI transfers on Micon SPI. Shreesha Rajashekar (1): drivers: spi: Add brcm iproc spi driver Corneliu Doban (1): drivers: spi: Add commands for Micron SPI drivers/spi/Kconfig | 26 + drivers/spi/Makefile | 4 + drivers/spi/iproc_qspi.c | 1161 ++++++++++++++++++++++++++++++++++++++ drivers/spi/iproc_qspi.h | 47 ++ drivers/spi/iproc_spi.c | 71 +++ include/spi.h | 6 + 6 files changed, 1315 insertions(+) create mode 100644 drivers/spi/iproc_qspi.c create mode 100644 drivers/spi/iproc_qspi.h create mode 100644 drivers/spi/iproc_spi.c -- 2.17.1

2 3

Re: AW: AW: latest u-boot branch for Marvell Armada 88F3720
by Stefan Roese 03 Apr '20

03 Apr '20

Hi Moritz, On 03.04.20 16:25, Moritz Berghof wrote: > Hi Stefan, Hi Marek > > I got your U-Boot mainline booting on the ESPRESSObin. First Step is done. > > Your are right Stefan, the SATA makes kind of Issues. With disabling it > is booting! Okay, thanks for testing and reporting. But we should strive to fix this SATA issue in mainline as well. If you find the time, it would be great if you (or someone else) could dig into this and send a patch to fix the real issue. Thanks, Stefan > You guys done a great job, the mainline works with that little changes. > > It tested for my need: > > USB 2.0 and USB 3.0 --- works > > If I will do further tests, I will commit. > > Changes are: > > diff --git a/arch/arm/dts/armada-3720-espressobin.dts > b/arch/arm/dts/armada-3720-espressobin.dts > > index 84e2c2adba..f8701c0e87 100644 > > --- a/arch/arm/dts/armada-3720-espressobin.dts > > +++ b/arch/arm/dts/armada-3720-espressobin.dts > > @@ -106,9 +106,9 @@ > > }; > > /* CON3 */ > > -&sata { > > - status = "okay"; > > -}; > > +//&sata { > > +// status = "okay"; > > +//}; > > &spi0 { > > status = "okay"; > > I would make it clean and suggest a pull request, therefore we have a > base, everybody can work on. > > The working boot-log is: > > DLL 0xc0001074NOTICE: Booting Trusted Firmware > > NOTICE: BL1: v1.3(release):armada-17.10.8:34247e02 > > NOTICE: BL1: Built : 10:52:47, Mar 31 2NOTICE: BL2: > v1.3(release):armada-17.10 > > .8:34247e02 > > NOTICE: BL2: Built : 10:52:48, Mar 31 2020 > > NNOTICE: BL31: v1.3(release):armada-17.10.8:34247e02 > > NOTICE: BL31: > > U-Boot 2020.04-rc3-00188-g350c44dfb9-dirty (Apr 03 2020 - 12:28:10 +0200) > > DRAM: 512 MiB > > Comphy-0: USB3_HOST0 5 Gbps > > Comphy-1: PEX0 2.5 Gbps > > Comphy-2: SATA0 5 Gbps > > PCIE-0: Link down > > MMC: > > Loading Environment from SPI Flash... SF: Detected w25q32dw with page > size 256 Bytes, erase size 4 KiB, total 4 MiB > > OK > > Model: Marvell Armada 3720 Community Board ESPRESSOBin > > Net: No ethernet found. > > Hit any key to stop autoboot: 0 > > Unknown command 'tftp' - try 'help' > > Unknown command 'tftp' - try 'help' > > Bad Linux ARM64 Image magic! > > Thank you very much, have a great weekend, > > -- > > Moritz Berghof > > Software Engineer > > Tel. +49 30 921028-209 <tel:+49%C2%A030%C2%A0921028-204> > > Fax +49 30 921028-020 <tel:+49%C2%A030%C2%A0921028-020> > > mberghof(a)phoenixcontact.com <mailto:mberghof@phoenixcontact.com> > > www.phoenixcontact.com <http://www.phoenixcontact.com/> > > PHOENIX CONTACT Cyber Security GmbH > > Richard-Willstätter-Straße 6 <x-apple-data-detectors://1/1> > D-12489 Berlin <x-apple-data-detectors://1/1> > > Register Court: AG Charlottenburg, HR B 202908 > Geschäftsführer/General Manager: Kilian Golm > > -- > > On Thu, 2 Apr 2020 14:18:24 +0200 > > Stefan Roese <sr at denx.de <https://lists.denx.de/listinfo/u-boot>> wrote: > >>/Hi Moritz,/ > >>// > >>/On 02.04.20 13:30, Moritz Berghof wrote:/ > >>/> it's really great that you answered so fast and helpfully, thank you!/ > >>/> / > >>/> It's great you want get the board ported to mainline. Me too./ > >>/> / > >>/> / > >>/> I build the U-boot mainline and uploaded on my espressobin. Used the ATF/ > >>/> and WTMI from Marvell./ > >>/> / > >>/> When I start the flashed .bin file, the U-boot crashed at this following/ > >>/> point. "Synchronous Abort" handler, esr 0x96000210 / > >>// > >>/Looks like an issue with SATA - not sure why. You might want to try to/ > >>/disable SATA / AHCI for testing./ > >>// > >>/> Prompt is attached at this mail./ > >>/> / > >>/> I think there is a problem with the RAM. For example, I build the U-Boot/ > >>/> for 1 GB RAM with the Marvell U-boot and the mainline/master. Important/ > >>/> constant is DDR_TOPOLOGY=2/ > >>/> / > >>/> make DEBUG=0 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 > CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 WTP=... BOOTDEV=SPINOR > PARTNUM=0 PLAT=a3700 all fip/ > >>/> / > >>/> But when the u-boot mainline starts it promts:/ > >>/> U-Boot 2020.04-rc3-00188-g350c44dfb9 (Mar 31 2020 - 10:52:01 +0200)/ > >>/> / > >>/> DRAM: 512 MiB/ > >>/> / > >>/> / > >>/> The Marvell U-boot promts DRAM: 1 GiB/ > >>/> / > >>/> / > >>/> / > >>/> So my question is, where do you define the RAM Size? / > >>// > >>/Take a look at arch/arm/mach-mvebu/arm64-common.c. Perhaps this code/ > >>/needs some changes for CONFIG_ARMADA_A3700 similar to what is done/ > >>/for CONFIG_ARMADA_8K ?/ > >>// > >>/I suggest you debug in this area a bit to see, where it goes wrong./ > > There is a register on A3720 which should contain information about how > > much RAM the system has (0xD0000200 if the device contains only one > > DDR chip). It is written by the TIM image. I am going to send a patch > > which uses this register to determine RAM size for Turris Mox. > > The thing is that without upgrade of TIM header some Moxes may report > > 1 GB RAM in this register, although they only have 512 MB. So a call to > > get_ram_size will still be needed. > > Marek > > ....................................................................................... > > PHOENIX CONTACT Cyber Security GmbH　 > > Richard-Willstätter-Straße 6 　 > > D-12489 Berlin 　 > > 　 > > Register Court: AG Charlottenburg, HR B 202908　 > > Geschäftsführer/General Manager: Kilian Golm > > // Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr(a)denx.de

1 0

[PATCH v2] serial: ns16550: Fix ordering of getting base address
by Bin Meng 03 Apr '20

03 Apr '20

Currently the driver gets ns16550 base address in the driver probe() routine, which may potentially break any ns16550 wrapper driver that does additional initialization before calling ns16550_serial_probe(). Things are complicated that we need consider ns16550 devices on both simple-bus and PCI bus. To fix the issue we move the base address assignment for simple-bus ns16550 device back to the ofdata_to_platdata(), and assign base address for PCI ns16550 device in ns16550_serial_probe(). This is still not perfect. Ideally if any PCI bus based ns16550 wrapper driver tries to access plat->base before calling probe(), it is subject to break. Fixes: 720f9e1fdb0c9 ("serial: ns16550: Move PCI access from ofdata_to_platdata() to probe()") Reported-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> Tested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner(a)br-automation.com> Tested-by: Wolfgang Wallner <wolfgang.wallner(a)br-automation.com> --- Changes in v2: - not to break Fixes, etc to two or more lines in the commit message - add the same CONFIG_SYS_NS16550_PORT_MAPPED ifdefs in the PCI case drivers/serial/ns16550.c | 53 ++++++++++++++++++++++++------------------------ 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index c1b303f..cb464a5 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -479,39 +479,28 @@ static int ns16550_serial_getinfo(struct udevice *dev, return 0; } -#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA) -static int ns1655_serial_set_base_addr(struct udevice *dev) -{ - fdt_addr_t addr; - struct ns16550_platdata *plat; - - plat = dev_get_platdata(dev); - - addr = dev_read_addr_pci(dev); - if (addr == FDT_ADDR_T_NONE) - return -EINVAL; - -#ifdef CONFIG_SYS_NS16550_PORT_MAPPED - plat->base = addr; -#else - plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE); -#endif - - return 0; -} -#endif - int ns16550_serial_probe(struct udevice *dev) { + struct ns16550_platdata *plat = dev->platdata; struct NS16550 *const com_port = dev_get_priv(dev); struct reset_ctl_bulk reset_bulk; + fdt_addr_t addr; int ret; -#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA) - ret = ns1655_serial_set_base_addr(dev); - if (ret) - return ret; + /* + * If we are on PCI bus, either directly attached to a PCI root port, + * or via a PCI bridge, assign platdata->base before probing hardware. + */ + if (device_is_on_pci_bus(dev)) { + addr = devfdt_get_addr_pci(dev); + if (addr == FDT_ADDR_T_NONE) + return -EINVAL; +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED + plat->base = addr; +#else + plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE); #endif + } ret = reset_get_bulk(dev, &reset_bulk); if (!ret) @@ -535,9 +524,21 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev) { struct ns16550_platdata *plat = dev->platdata; const u32 port_type = dev_get_driver_data(dev); + fdt_addr_t addr; struct clk clk; int err; + addr = dev_read_addr(dev); + if (addr != FDT_ADDR_T_NONE) { +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED + plat->base = addr; +#else + plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE); +#endif + } else if (!device_is_on_pci_bus(dev)) { + return -EINVAL; + } + plat->reg_offset = dev_read_u32_default(dev, "reg-offset", 0); plat->reg_shift = dev_read_u32_default(dev, "reg-shift", 0); plat->reg_width = dev_read_u32_default(dev, "reg-io-width", 1); -- 2.7.4

3 2

[PATCH] serial: ns16550: Fix ordering of getting base address
by Bin Meng 03 Apr '20

03 Apr '20

Currently the driver gets ns16550 base address in the driver probe() routine, which may potentially break any ns16550 wrapper driver that does additional initialization before calling ns16550_serial_probe(). Things are complicated that we need consider ns16550 devices on both simple-bus and PCI bus. To fix the issue we move the base address assignment for simple-bus ns16550 device back to the ofdata_to_platdata(), and assign base address for PCI ns16550 device in ns16550_serial_probe(). This is still not perfect. Ideally if any PCI bus based ns16550 wrapper driver tries to access plat->base before calling probe(), it is subject to break. Fixes: 720f9e1fdb0c9 ("serial: ns16550: Move PCI access from ofdata_to_platdata() to probe()") Reported-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- drivers/serial/ns16550.c | 51 +++++++++++++++++++++++------------------------- 1 file changed, 24 insertions(+), 27 deletions(-) diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index c1b303f..5e3cd1c 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -479,39 +479,24 @@ static int ns16550_serial_getinfo(struct udevice *dev, return 0; } -#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA) -static int ns1655_serial_set_base_addr(struct udevice *dev) -{ - fdt_addr_t addr; - struct ns16550_platdata *plat; - - plat = dev_get_platdata(dev); - - addr = dev_read_addr_pci(dev); - if (addr == FDT_ADDR_T_NONE) - return -EINVAL; - -#ifdef CONFIG_SYS_NS16550_PORT_MAPPED - plat->base = addr; -#else - plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE); -#endif - - return 0; -} -#endif - int ns16550_serial_probe(struct udevice *dev) { + struct ns16550_platdata *plat = dev->platdata; struct NS16550 *const com_port = dev_get_priv(dev); struct reset_ctl_bulk reset_bulk; + fdt_addr_t addr; int ret; -#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA) - ret = ns1655_serial_set_base_addr(dev); - if (ret) - return ret; -#endif + /* + * If we are on PCI bus, either directly attached to a PCI root port, + * or via a PCI bridge, assign platdata->base before probing hardware. + */ + if (device_is_on_pci_bus(dev)) { + addr = devfdt_get_addr_pci(dev); + if (addr == FDT_ADDR_T_NONE) + return -EINVAL; + plat->base = addr; + } ret = reset_get_bulk(dev, &reset_bulk); if (!ret) @@ -535,9 +520,21 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev) { struct ns16550_platdata *plat = dev->platdata; const u32 port_type = dev_get_driver_data(dev); + fdt_addr_t addr; struct clk clk; int err; + addr = dev_read_addr(dev); + if (addr != FDT_ADDR_T_NONE) { +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED + plat->base = addr; +#else + plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE); +#endif + } else if (!device_is_on_pci_bus(dev)) { + return -EINVAL; + } + plat->reg_offset = dev_read_u32_default(dev, "reg-offset", 0); plat->reg_shift = dev_read_u32_default(dev, "reg-shift", 0); plat->reg_width = dev_read_u32_default(dev, "reg-io-width", 1); -- 2.7.4

3 5

[PATCH v3] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
by Andy Shevchenko 03 Apr '20

03 Apr '20

The commit 720f9e1fdb0c ("Move PCI access from ofdata_to_platdata() to probe()") while doing formally a right thing, actually brings a regression to the drivers that would like to pre-initialize hardware before calling ns16550_serial_probe(). In particular, the code, which gets moved out, is responsible for getting the address of the hardware. The commit breaks serial console on the Intel Edison, for example. Since we are very close to the release, the quick fix is to revert the culprit commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. Note, it doesn't affect SoCFPGA case. Cc: Wolfgang Wallner <wolfgang.wallner(a)br-automation.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- v3: drop wrong patch, better explanation in the commit message drivers/serial/ns16550.c | 40 ++++++++++++---------------------------- 1 file changed, 12 insertions(+), 28 deletions(-) diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index c1b303ffcb..1fcbc35015 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -479,40 +479,12 @@ static int ns16550_serial_getinfo(struct udevice *dev, return 0; } -#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA) -static int ns1655_serial_set_base_addr(struct udevice *dev) -{ - fdt_addr_t addr; - struct ns16550_platdata *plat; - - plat = dev_get_platdata(dev); - - addr = dev_read_addr_pci(dev); - if (addr == FDT_ADDR_T_NONE) - return -EINVAL; - -#ifdef CONFIG_SYS_NS16550_PORT_MAPPED - plat->base = addr; -#else - plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE); -#endif - - return 0; -} -#endif - int ns16550_serial_probe(struct udevice *dev) { struct NS16550 *const com_port = dev_get_priv(dev); struct reset_ctl_bulk reset_bulk; int ret; -#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA) - ret = ns1655_serial_set_base_addr(dev); - if (ret) - return ret; -#endif - ret = reset_get_bulk(dev, &reset_bulk); if (!ret) reset_deassert_bulk(&reset_bulk); @@ -535,9 +507,21 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev) { struct ns16550_platdata *plat = dev->platdata; const u32 port_type = dev_get_driver_data(dev); + fdt_addr_t addr; struct clk clk; int err; + /* try Processor Local Bus device first */ + addr = dev_read_addr_pci(dev); + if (addr == FDT_ADDR_T_NONE) + return -EINVAL; + +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED + plat->base = addr; +#else + plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE); +#endif + plat->reg_offset = dev_read_u32_default(dev, "reg-offset", 0); plat->reg_shift = dev_read_u32_default(dev, "reg-shift", 0); plat->reg_width = dev_read_u32_default(dev, "reg-io-width", 1); -- 2.25.1

4 4

[PATCH] mtd: spi-nor-ids: Add Spansion s25fs512s flash entry
by Kuldeep Singh 03 Apr '20

03 Apr '20

Spansion "s25fs512s" flash is incorrectly decoded as "s25fl512s" on various platforms as former is not present. Add the entry. Linux already has both the flashes present. A snippet below: { "s25fl512s", INFO6(0x010220, 0x4d0080, 256 * 1024, 256...}, { "s25fs512s", INFO6(0x010220, 0x4d0081, 256 * 1024, 256...}, Signed-off-by: Kuldeep Singh <kuldeep.singh(a)nxp.com> --- drivers/mtd/spi/spi-nor-ids.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c index 973b6f8..42baa84 100644 --- a/drivers/mtd/spi/spi-nor-ids.c +++ b/drivers/mtd/spi/spi-nor-ids.c @@ -193,7 +193,8 @@ const struct flash_info spi_nor_ids[] = { { INFO("s25sl064p", 0x010216, 0x4d00, 64 * 1024, 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, { INFO("s25fl256s0", 0x010219, 0x4d00, 256 * 1024, 128, USE_CLSR) }, { INFO("s25fl256s1", 0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) }, - { INFO6("s25fl512s", 0x010220, 0x4d0081, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) }, + { INFO6("s25fl512s", 0x010220, 0x4d0080, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) }, + { INFO6("s25fs512s", 0x010220, 0x4d0081, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) }, { INFO("s25fl512s_256k", 0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) }, { INFO("s25fl512s_64k", 0x010220, 0x4d01, 64 * 1024, 1024, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) }, { INFO("s25fl512s_512k", 0x010220, 0x4f00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) }, -- 2.7.4

1 0

[PATCH 1/2] arm: tegra: define fdtfile option for distro boot
by Peter Robinson 02 Apr '20

02 Apr '20

For booting via UEFI we need to define the fdtfile option so bootefi has the option to load a fdtfile from disk. For arm64 the kernel dtb is located in a vendor directory so we define that as nvidia for that architecture. Signed-off-by: Peter Robinson <pbrobinson(a)gmail.com> --- Without this the aarch64 tegra devices don't find the kernel device tree when booting using UEFI so fall back to the firmware DT in U-Boot which alone isn't enough to boot the Linux kernel and you end up with a boot failure in very early boot due to being unable to find the architecture timer. This fixes the issue when booting Fedora using UEFI for me. include/configs/tegra-common.h | 6 ++++++ include/configs/tegra114-common.h | 1 + include/configs/tegra124-common.h | 1 + include/configs/tegra186-common.h | 1 + include/configs/tegra20-common.h | 1 + include/configs/tegra210-common.h | 1 + include/configs/tegra30-common.h | 1 + 7 files changed, 12 insertions(+) diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index f2cdd9c019..997b50394b 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -55,6 +55,12 @@ #define CONFIG_SYS_MEMTEST_START (NV_PA_SDRC_CS0 + 0x600000) #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 0x100000) +#ifdef CONFIG_ARM64 +#define FDTFILE "nvidia/" CONFIG_DEFAULT_DEVICE_TREE ".dtb" +#else +#define FDTFILE CONFIG_DEFAULT_DEVICE_TREE ".dtb" +#endif + /*----------------------------------------------------------------------- * Physical Memory Map */ diff --git a/include/configs/tegra114-common.h b/include/configs/tegra114-common.h index d3a7045697..9d751b6740 100644 --- a/include/configs/tegra114-common.h +++ b/include/configs/tegra114-common.h @@ -50,6 +50,7 @@ "scriptaddr=0x90000000\0" \ "pxefile_addr_r=0x90100000\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x83000000\0" \ "ramdisk_addr_r=0x83100000\0" diff --git a/include/configs/tegra124-common.h b/include/configs/tegra124-common.h index 522993b958..0eb8f92809 100644 --- a/include/configs/tegra124-common.h +++ b/include/configs/tegra124-common.h @@ -52,6 +52,7 @@ "scriptaddr=0x90000000\0" \ "pxefile_addr_r=0x90100000\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x83000000\0" \ "ramdisk_addr_r=0x83100000\0" diff --git a/include/configs/tegra186-common.h b/include/configs/tegra186-common.h index b4936cc731..5c3ad35c76 100644 --- a/include/configs/tegra186-common.h +++ b/include/configs/tegra186-common.h @@ -49,6 +49,7 @@ "scriptaddr=0x90000000\0" \ "pxefile_addr_r=0x90100000\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x82000000\0" \ "ramdisk_addr_r=0x82100000\0" diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h index 1e31d82574..fdd8996955 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -51,6 +51,7 @@ "scriptaddr=0x10000000\0" \ "pxefile_addr_r=0x10100000\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x03000000\0" \ "ramdisk_addr_r=0x03100000\0" diff --git a/include/configs/tegra210-common.h b/include/configs/tegra210-common.h index 1b8e94b60c..2226effe16 100644 --- a/include/configs/tegra210-common.h +++ b/include/configs/tegra210-common.h @@ -46,6 +46,7 @@ "scriptaddr=0x90000000\0" \ "pxefile_addr_r=0x90100000\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x83000000\0" \ "ramdisk_addr_r=0x83200000\0" diff --git a/include/configs/tegra30-common.h b/include/configs/tegra30-common.h index 54bc6756ab..6c5dc24b26 100644 --- a/include/configs/tegra30-common.h +++ b/include/configs/tegra30-common.h @@ -47,6 +47,7 @@ "scriptaddr=0x90000000\0" \ "pxefile_addr_r=0x90100000\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x83000000\0" \ "ramdisk_addr_r=0x83100000\0" -- 2.26.0

2 2

latest u-boot branch for Marvell Armada 88F3720
by Moritz Berghof 02 Apr '20

02 Apr '20

Dear U-Boot developers, My Name is Moritz and we evaluate the Marvell Armada 88F3720 on the Marvell ESPRESSObin and the TURRIS MOX. Does someone know, where is the actual or latest u-boot branch for Marvell Armada 88F3720 placed? At the u-boot master or a marvell custodian tree or somewhere else? Does Marvell develop u-boot still for their Armada 88F3720 and when yes, where? Because that https://github.com/MarvellEmbeddedProcessors/u-boot-marvell, which is well used on the ESPRESSObin is NOT up-to-date. 4 Years ago, last commit. I'm searching an actual u-boot platform for my Chip. I look forward to your reply, thank you very much, -- Moritz Berghof Software Engineer Tel. +49 30 921028-209<tel:+49%C2%A030%C2%A0921028-204> Fax +49 30 921028-020<tel:+49%C2%A030%C2%A0921028-020> mberghof(a)phoenixcontact.com<mailto:mberghof@phoenixcontact.com> www.phoenixcontact.com<http://www.phoenixcontact.com/> PHOENIX CONTACT Cyber Security GmbH Richard-Willstätter-Straße 6<x-apple-data-detectors://1/1> D-12489 Berlin<x-apple-data-detectors://1/1> Register Court: AG Charlottenburg, HR B 202908 Geschäftsführer/General Manager: Kilian Golm ....................................................................................... PHOENIX CONTACT Cyber Security GmbH Richard-Willstätter-Straße 6 D-12489 Berlin Register Court: AG Charlottenburg, HR B 202908 Geschäftsführer/General Manager: Kilian Golm

3 6

[PATCH v2 1/5] rockchip: Separate the reset cause from display cpuinfo
by Jagan Teki 02 Apr '20

02 Apr '20

reset cause is a generic functionality based on the soc cru registers in rockchip. This can be used for printing the cause of reset in cpuinfo or some other place where reset cause is needed. Other than cpuinfo, reset cause can also be using during bootcount for checking the specific reset cause and glow the led based on the reset cause. So, let's separate the reset cause code from cpuinfo, and add a check to build it for rk3399, rk3288 since these two soc are supporting reset cause as of now. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- Changes for v2: - none arch/arm/include/asm/arch-rockchip/cru.h | 2 ++ arch/arm/mach-rockchip/Makefile | 5 ++++- arch/arm/mach-rockchip/cpu-info.c | 20 ++++++++++++-------- 3 files changed, 18 insertions(+), 9 deletions(-) diff --git a/arch/arm/include/asm/arch-rockchip/cru.h b/arch/arm/include/asm/arch-rockchip/cru.h index 5cf2aec11a..b2ffc57c7d 100644 --- a/arch/arm/include/asm/arch-rockchip/cru.h +++ b/arch/arm/include/asm/arch-rockchip/cru.h @@ -27,4 +27,6 @@ enum { #define MHz 1000000 +char *get_reset_cause(void); + #endif /* _ROCKCHIP_CLOCK_H */ diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile index 5b38526fe0..ef4898e00c 100644 --- a/arch/arm/mach-rockchip/Makefile +++ b/arch/arm/mach-rockchip/Makefile @@ -15,6 +15,10 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o +ifeq ($(CONFIG_ROCKCHIP_RK3288)$(CONFIG_ROCKCHIP_RK3399), y) +obj-y += cpu-info.o +endif + ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),) # Always include boot_mode.o, as we bypass it (i.e. turn it off) @@ -22,7 +26,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),) # we can have the preprocessor correctly recognise both 0x0 and 0 # meaning "turn it off". obj-y += boot_mode.o -obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o obj-$(CONFIG_MISC_INIT_R) += misc.o endif diff --git a/arch/arm/mach-rockchip/cpu-info.c b/arch/arm/mach-rockchip/cpu-info.c index 4b0e99299a..ee0ec3d082 100644 --- a/arch/arm/mach-rockchip/cpu-info.c +++ b/arch/arm/mach-rockchip/cpu-info.c @@ -11,7 +11,7 @@ #include <asm/arch-rockchip/hardware.h> #include <linux/err.h> -static char *get_reset_cause(void) +char *get_reset_cause(void) { struct rockchip_cru *cru = rockchip_get_cru(); char *cause = NULL; @@ -39,12 +39,6 @@ static char *get_reset_cause(void) cause = "unknown reset"; } - /** - * reset_reason env is used by rk3288, due to special use case - * to figure it the boot behavior. so keep this as it is. - */ - env_set("reset_reason", cause); - /* * Clear glb_rst_st, so we can determine the last reset cause * for following resets. @@ -54,12 +48,22 @@ static char *get_reset_cause(void) return cause; } +#ifdef CONFIG_DISPLAY_CPUINFO int print_cpuinfo(void) { + char *cause = get_reset_cause(); + printf("SoC: Rockchip %s\n", CONFIG_SYS_SOC); - printf("Reset cause: %s\n", get_reset_cause()); + printf("Reset cause: %s\n", cause); + + /** + * reset_reason env is used by rk3288, due to special use case + * to figure it the boot behavior. so keep this as it is. + */ + env_set("reset_reason", cause); /* TODO print operating temparature and clock */ return 0; } +#endif -- 2.17.1

3 10