Re: [U-Boot] [PATCH v2 7/7] MSCC: Add sysreset driver for Jaguar2 SOC family
Hi Daniel,
The 01/07/2019 21:11, Daniel Schwierzeck wrote:
>
>
> Am 07.01.19 um 14:02 schrieb Horatiu Vultur:
> > Create sysreset driver for Jaguar2 SOC family and update defconfig
> > to use it.
> >
> > Signed-off-by: Horatiu Vultur
> > ---
> > MAINTAINERS | 1 +
> > board/mscc/jr2/jr2.c| 8 +++
> > configs/mscc_jr2_defconfig | 2 ++
> > drivers/sysreset/Kconfig| 6 ++
> > drivers/sysreset/Makefile | 1 +
> > drivers/sysreset/sysreset_jr2.c | 46
> > +
> > 6 files changed, 64 insertions(+)
> > create mode 100644 drivers/sysreset/sysreset_jr2.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index d42736b..8b8cc9d 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -526,6 +526,7 @@ F: arch/mips/dts/serval*
> > F: board/mscc/
> > F: configs/mscc*
> > F: drivers/gpio/mscc_sgpio.c
> > +F: drivers/sysreset/sysreset_jr2.c
> > F: include/configs/vcoreiii.h
> > F: drivers/pinctrl/mscc/
> >
> > diff --git a/board/mscc/jr2/jr2.c b/board/mscc/jr2/jr2.c
> > index 36f9896..2935ad0 100644
> > --- a/board/mscc/jr2/jr2.c
> > +++ b/board/mscc/jr2/jr2.c
> > @@ -6,6 +6,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -17,6 +18,8 @@ enum {
> >
> > int board_early_init_r(void)
> > {
> > + int ret;
> > +
> > /* Prepare SPI controller to be used in master mode */
> > writel(0, BASE_CFG + ICPU_SW_MODE);
> > clrsetbits_le32(BASE_CFG + ICPU_GENERAL_CTRL,
> > @@ -30,6 +33,11 @@ int board_early_init_r(void)
> > if (IS_ENABLED(CONFIG_LED))
> > led_default_state();
> >
> > + ret = device_bind_driver(gd->dm_root, "jr2_soft_reset",
> > +"reset_soft", NULL);
> > + if (ret)
> > + printf("Warning: No reset driver: ret=%d\n", ret);
> > +
>
> that shouldn't be necessary if you put a device node to device tree.
>
> Actually my intention in last review was that you create a driver which
> fits all MSCC SoCs and control the differences via the device tree
> compatible string. This way you could entirely get rid of the legacy
> _machine_restart() hook in the MSCC platform. But you don't have to do
> this in this series.
Ah, now it is more clear. I will create a different patch for this and
fix it for all MSCC SoCs.
>
> > return 0;
> > }
> >
> > diff --git a/configs/mscc_jr2_defconfig b/configs/mscc_jr2_defconfig
> > index b215754..e80dde6 100644
> > --- a/configs/mscc_jr2_defconfig
> > +++ b/configs/mscc_jr2_defconfig
> > @@ -57,3 +57,5 @@ CONFIG_SPI=y
> > CONFIG_DM_SPI=y
> > CONFIG_LZMA=y
> > CONFIG_XZ=y
> > +CONFIG_SYSRESET=y
> > +CONFIG_SYSRESET_JR2=y
> > diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> > index 8ce3e2e..7c6db0f 100644
> > --- a/drivers/sysreset/Kconfig
> > +++ b/drivers/sysreset/Kconfig
> > @@ -43,6 +43,12 @@ config SYSRESET_TI_SCI
> > This enables the system reset driver support over TI System Control
> > Interface available on some new TI's SoCs.
> >
> > +config SYSRESET_JR2
> > + bool "Enable support for Jaguar2 soft reset"
> > + depends on SOC_JR2
> > + help
> > + This is soft reset on Jaguar2.
> > +
> > endif
> >
> > config SYSRESET_SYSCON
> > diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
> > index b3728ac..24c488b 100644
> > --- a/drivers/sysreset/Makefile
> > +++ b/drivers/sysreset/Makefile
> > @@ -16,3 +16,4 @@ obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
> > obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
> > obj-$(CONFIG_SYSRESET_X86) += sysreset_x86.o
> > obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
> > +obj-$(CONFIG_SYSRESET_JR2) += sysreset_jr2.o
> > diff --git a/drivers/sysreset/sysreset_jr2.c
> > b/drivers/sysreset/sysreset_jr2.c
> > new file mode 100644
> > index 000..76a5bac
> > --- /dev/null
> > +++ b/drivers/sysreset/sysreset_jr2.c
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Microsemi SoCs pinctrl driver
> > + *
> > + * Author:
> > + * License: Dual MIT/GPL
>
> redundant due to SPDX identifier
>
> > + * Copyright (c) 2018 Microsemi Corporation
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static int jr2_sysreset_request(struct udevice *dev,
> > + enum sysreset_t type)
> > +{
> > + register u32 reg = readl(BASE_CFG + ICPU_GENERAL_CTRL);
>
> register is not required in this context
>
> > + /* Set owner */
> > + reg &= ~ICPU_GENERAL_CTRL_IF_SI_OWNER_M;
> > + reg |= ICPU_GENERAL_CTRL_IF_SI_OWNER(1);
> > + /* Set boot mode */
> > + reg |= ICPU_GENERAL_CTRL_BOOT_MODE_ENA;
> > + writel(reg, BASE_CFG + ICPU_GENERAL_CTRL);
> > + /* Read back in order to make BOOT mode setting active */
> > + reg = readl(BASE_CFG + ICPU_GENERAL_CTRL);
> > + /* Reset CPU only - still executing
Re: [U-Boot] [PATCH v1 3/4] serial: add an of-platdata driver for "snps, dw-apb-uart"
On Tue, Jan 8, 2019 at 8:30 AM Lukasz Majewski wrote:
>
> Hi Simon,
>
> > On Mon, Jan 7, 2019 at 11:12 PM Lukasz Majewski wrote:
> > >
> > > Hi Simon,
> > >
> > > > Add a driver for the "snps,dw-apb-uart" used in socfpga and
> > > > others.
> > > >
> > > > This driver is required to get OF_PLATDATA to work for socfpga.
> > > > It uses the ns16550 driver, converting the platdata from
> > > > of-platdata go the ns16550 format.
> > > >
> > > > Signed-off-by: Simon Goldschmidt
> > > > ---
> > > >
> > > > drivers/serial/Kconfig | 10
> > > > drivers/serial/Makefile| 1 +
> > > > drivers/serial/serial_dw_apb.c | 42
> > > > ++ 3 files changed, 53
> > > > insertions(+) create mode 100644 drivers/serial/serial_dw_apb.c
> > > >
> > > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> > > > index b7ff2960ab..10addd3309 100644
> > > > --- a/drivers/serial/Kconfig
> > > > +++ b/drivers/serial/Kconfig
> > > > @@ -511,6 +511,16 @@ config BCM283X_PL011_SERIAL
> > > > that supports automatic disable, so that it only gets used
> > > > when the UART is actually muxed.
> > > >
> > > > +config DESIGNWARE_SERIAL
> > > > + bool "DesignWare UART support"
> > > > + depends on DM_SERIAL && SPL_OF_PLATDATA
> > > > + help
> > > > + Select this to enable a UART driver for "snps,dw-apb-uart"
> > > > devices
> > > > + when using CONFIG_SPL_OF_PLATDATA (i.e. a compiled-in
> > > > device tree
> > > > + replacement).
> > > > + This uses the ns16550 driver, converting the platdata from
> > > > of-platdata
> > > > + to the ns16550 format.
> > > > +
> > > > config BCM6345_SERIAL
> > > > bool "Support for BCM6345 UART"
> > > > depends on DM_SERIAL
> > > > diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
> > > > index 06ee30697d..f1ebb90d92 100644
> > > > --- a/drivers/serial/Makefile
> > > > +++ b/drivers/serial/Makefile
> > > > @@ -46,6 +46,7 @@ obj-$(CONFIG_MESON_SERIAL) += serial_meson.o
> > > > obj-$(CONFIG_INTEL_MID_SERIAL) += serial_intel_mid.o
> > > > ifdef CONFIG_SPL_BUILD
> > > > obj-$(CONFIG_ROCKCHIP_SERIAL) += serial_rockchip.o
> > > > +obj-$(CONFIG_DESIGNWARE_SERIAL) += serial_dw_apb.o
> > > > endif
> > > > obj-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
> > > > obj-$(CONFIG_SANDBOX_SERIAL) += sandbox.o
> > > > diff --git a/drivers/serial/serial_dw_apb.c
> > > > b/drivers/serial/serial_dw_apb.c new file mode 100644
> > > > index 00..26580e5ba5
> > > > --- /dev/null
> > > > +++ b/drivers/serial/serial_dw_apb.c
> > > > @@ -0,0 +1,42 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * Copyright (c) 2018 Simon Goldschmidt
> > > > + */
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > > > +struct dw_apb_uart_platdata {
> > > > + struct dtd_snps_dw_apb_uart dtplat;
> > > > + struct ns16550_platdata plat;
> > > > +};
> > > > +
> > > > +static int dw_apb_serial_probe(struct udevice *dev)
> > > > +{
> > > > + struct dw_apb_uart_platdata *plat = dev_get_platdata(dev);
> > > > +
> > > > + /* Set up correct platform data for the standard driver */
> > > > + plat->plat.base = plat->dtplat.reg[0];
> > > > + plat->plat.reg_shift = plat->dtplat.reg_shift;
> > > > + plat->plat.reg_width = plat->dtplat.reg_io_width;
> > > > + plat->plat.clock = plat->dtplat.clock_frequency;
> > > > + plat->plat.fcr = UART_FCR_DEFVAL;
> > > > + dev->platdata = >plat;
> > > > +
> > > > + return ns16550_serial_probe(dev);
> > > > +}
> > > > +
> > > > +U_BOOT_DRIVER(snps_dw_apb_uart) = {
> > > > + .name = "snps_dw_apb_uart",
> > > > + .id = UCLASS_SERIAL,
> > > > + .priv_auto_alloc_size = sizeof(struct NS16550),
> > > > + .platdata_auto_alloc_size = sizeof(struct
> > > > dw_apb_uart_platdata),
> > > > + .probe = dw_apb_serial_probe,
> > > > + .ops= _serial_ops,
> > > > + .flags = DM_FLAG_PRE_RELOC,
> > >
> > > Is it possible/or is your application requiring the pinmux/clock
> > > setting for this serial?
> >
> > No, the socfpga gen5 platform is somewhat of a real bad example
> > regarding pinmux and clocks. These are implemented completely
> > separate, based on files generated by the FPGA toolchain...
> >
> > And as you can see above, the clock must be encoded into the DTS (and
> > platdata) instead of calculating it via clock references.
>
> Just to be clear here - the FPGA SDK (Quartus ?) generates clock info
> in different way than "normal" SoCs and it cannot use "clocks" and
> "clocks-names" properties to define needed clocks?
I'm afraid I don't know what the "normal" SoC way is in Linux. Coming from
smaller embedded systems like STM32, what Quartus generates here is
not uncommon :-)
The DTS for socfpga has clock references but at least for the gen5 devices,
these are not used.
Re: [U-Boot] [PATCH v1 3/4] serial: add an of-platdata driver for "snps, dw-apb-uart"
Hi Simon,
> On Mon, Jan 7, 2019 at 11:12 PM Lukasz Majewski wrote:
> >
> > Hi Simon,
> >
> > > Add a driver for the "snps,dw-apb-uart" used in socfpga and
> > > others.
> > >
> > > This driver is required to get OF_PLATDATA to work for socfpga.
> > > It uses the ns16550 driver, converting the platdata from
> > > of-platdata go the ns16550 format.
> > >
> > > Signed-off-by: Simon Goldschmidt
> > > ---
> > >
> > > drivers/serial/Kconfig | 10
> > > drivers/serial/Makefile| 1 +
> > > drivers/serial/serial_dw_apb.c | 42
> > > ++ 3 files changed, 53
> > > insertions(+) create mode 100644 drivers/serial/serial_dw_apb.c
> > >
> > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> > > index b7ff2960ab..10addd3309 100644
> > > --- a/drivers/serial/Kconfig
> > > +++ b/drivers/serial/Kconfig
> > > @@ -511,6 +511,16 @@ config BCM283X_PL011_SERIAL
> > > that supports automatic disable, so that it only gets used
> > > when the UART is actually muxed.
> > >
> > > +config DESIGNWARE_SERIAL
> > > + bool "DesignWare UART support"
> > > + depends on DM_SERIAL && SPL_OF_PLATDATA
> > > + help
> > > + Select this to enable a UART driver for "snps,dw-apb-uart"
> > > devices
> > > + when using CONFIG_SPL_OF_PLATDATA (i.e. a compiled-in
> > > device tree
> > > + replacement).
> > > + This uses the ns16550 driver, converting the platdata from
> > > of-platdata
> > > + to the ns16550 format.
> > > +
> > > config BCM6345_SERIAL
> > > bool "Support for BCM6345 UART"
> > > depends on DM_SERIAL
> > > diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
> > > index 06ee30697d..f1ebb90d92 100644
> > > --- a/drivers/serial/Makefile
> > > +++ b/drivers/serial/Makefile
> > > @@ -46,6 +46,7 @@ obj-$(CONFIG_MESON_SERIAL) += serial_meson.o
> > > obj-$(CONFIG_INTEL_MID_SERIAL) += serial_intel_mid.o
> > > ifdef CONFIG_SPL_BUILD
> > > obj-$(CONFIG_ROCKCHIP_SERIAL) += serial_rockchip.o
> > > +obj-$(CONFIG_DESIGNWARE_SERIAL) += serial_dw_apb.o
> > > endif
> > > obj-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
> > > obj-$(CONFIG_SANDBOX_SERIAL) += sandbox.o
> > > diff --git a/drivers/serial/serial_dw_apb.c
> > > b/drivers/serial/serial_dw_apb.c new file mode 100644
> > > index 00..26580e5ba5
> > > --- /dev/null
> > > +++ b/drivers/serial/serial_dw_apb.c
> > > @@ -0,0 +1,42 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (c) 2018 Simon Goldschmidt
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > > +struct dw_apb_uart_platdata {
> > > + struct dtd_snps_dw_apb_uart dtplat;
> > > + struct ns16550_platdata plat;
> > > +};
> > > +
> > > +static int dw_apb_serial_probe(struct udevice *dev)
> > > +{
> > > + struct dw_apb_uart_platdata *plat = dev_get_platdata(dev);
> > > +
> > > + /* Set up correct platform data for the standard driver */
> > > + plat->plat.base = plat->dtplat.reg[0];
> > > + plat->plat.reg_shift = plat->dtplat.reg_shift;
> > > + plat->plat.reg_width = plat->dtplat.reg_io_width;
> > > + plat->plat.clock = plat->dtplat.clock_frequency;
> > > + plat->plat.fcr = UART_FCR_DEFVAL;
> > > + dev->platdata = >plat;
> > > +
> > > + return ns16550_serial_probe(dev);
> > > +}
> > > +
> > > +U_BOOT_DRIVER(snps_dw_apb_uart) = {
> > > + .name = "snps_dw_apb_uart",
> > > + .id = UCLASS_SERIAL,
> > > + .priv_auto_alloc_size = sizeof(struct NS16550),
> > > + .platdata_auto_alloc_size = sizeof(struct
> > > dw_apb_uart_platdata),
> > > + .probe = dw_apb_serial_probe,
> > > + .ops= _serial_ops,
> > > + .flags = DM_FLAG_PRE_RELOC,
> >
> > Is it possible/or is your application requiring the pinmux/clock
> > setting for this serial?
>
> No, the socfpga gen5 platform is somewhat of a real bad example
> regarding pinmux and clocks. These are implemented completely
> separate, based on files generated by the FPGA toolchain...
>
> And as you can see above, the clock must be encoded into the DTS (and
> platdata) instead of calculating it via clock references.
Just to be clear here - the FPGA SDK (Quartus ?) generates clock info
in different way than "normal" SoCs and it cannot use "clocks" and
"clocks-names" properties to define needed clocks?
>
> This might be valid for socfpga only, and this driver migth be used
> on other boards as well.
I think yes. IMHO the goal here is to reuse DM versions of drivers in
the SPL (as non DM ones will be removed finally).
> But I think it wouldn't hurt to start it
> like this and continue improving it once it is used on other
> platforms - it has to be actively enabled and is only used for SPL
> with OF_PLATDATA.
>
> > With OF_PLATDATA we don't need to parse (and provide) the DTS (and
> > we use the DM/DTS driver's code in a way similar
Re: [U-Boot] [PATCH v3 8/8] cmd: env: add "-e" option for handling UEFI variables
On Mon, Jan 07, 2019 at 04:47:13PM +0900, AKASHI Takahiro wrote: > Heinrich, > > On Wed, Dec 26, 2018 at 10:20:32PM +0100, Alexander Graf wrote: > > > > > > On 25.12.18 09:44, AKASHI Takahiro wrote: > > > On Sun, Dec 23, 2018 at 02:56:40AM +0100, Alexander Graf wrote: > > >> > > >> > > >> On 19.12.18 13:23, Heinrich Schuchardt wrote: > > >>> On 12/19/18 2:49 AM, AKASHI Takahiro wrote: > > Heinrich, > > > > On Tue, Dec 18, 2018 at 07:07:02AM +0100, Heinrich Schuchardt wrote: > > > On 12/18/18 6:05 AM, AKASHI Takahiro wrote: > > >> "env [print|set] -e" allows for handling uefi variables without > > >> knowing details about mapping to corresponding u-boot variables. > > >> > > >> Signed-off-by: AKASHI Takahiro > > > > > > Hello Takahiro, > > > > > > in several patch series you are implementing multiple interactive > > > commands that concern > > > > > > - handling of EFI variables > > > - executing EFI binaries > > > - managing boot sequence > > > > > > I very much appreciate your effort to provide an independent UEFI > > > shell > > > implementation. What I am worried about is that your current patches > > > make it part of the monolithic U-Boot binary. > > > > First of all, in v3, CONFIG_CMD_EFISHELL was introduced after Alex's > > comment on v2. So you can disable efishell command if you don't want > > it. > > > > Are you still worried? > > > > > This design has multiple drawbacks: > > > > > > The memory size available for U-Boot is very limited for many devices. > > > We already had to disable EFI_LOADER for some boards due to this > > > limitations. Hence we want to keep everything out of the U-Boot binary > > > that does not serve the primary goal of loading and executing the next > > > binary. > > > > I don't know your point here. If EFI_LOADER is disabled, efishell > > will never be compiled in. > > > > > The UEFI forum has published a UEFI Shell specification which is very > > > extensive. We still have a lot of deficiencies in U-Boot's UEFI API > > > implementation. By merging in parts of an UEFI shell implementation > > > our > > > project looses focus. > > > > What is "our project?" What is "focus?" > > I'm just asking as I want to share that information with you. > > > > > There is an EDK2 implementation of said > > > specification. If we fix the remaining bugs of the EFI API > > > implementation in U-Boot we could simply run the EDK2 shell which > > > provides all that is needed for interactive work. > > > > > > With you monolithic approach your UEFI shell implementation can > > > neither > > > be used with other UEFI API implementations than U-Boot nor can it be > > > tested against other API implementations. > > > > Let me explain my stance. > > My efishell is basically something like a pursuit as well as > > a debug/test tool which was and is still quite useful for me. > > Without it, I would have completed (most of) my efi-related work so > > far. > > So I believe that it will also be useful for other people who may want > > to get involved and play with u-boot's efi environment. > > >>> > > >>> On SD-Cards U-Boot is installed between the MBR and the first partition. > > >>> On other devices it is put into a very small ROM. Both ways the maximum > > >>> size is rather limited. > > >>> > > >>> U-Boot provides all that is needed to load and execute an EFI binary. So > > >>> you can put your efishell as file into the EFI partition like you would > > >>> install the EDK2 shell. > > >>> > > >>> The only hardshift this approach brings is that you have to implement > > >>> your own printf because UEFI does not offer formatted output. But this > > >>> can be copied from lib/efi_selftest/efi_selftest_console.c. > > >>> > > >>> The same decision I took for booting from iSCSI. I did not try to put an > > >>> iSCSI driver into U-Boot instead I use iPXE as an executable that is > > >>> loaded from the EFI partition. > > >>> > > > > I have never intended to fully implement a shell which is to be > > compliant > > with UEFI specification while I'm trying to mimick some command > > interfaces for convenience. UEFI shell, as you know, provides plenty > > of "protocols" on which some UEFI applications, including UEFI SCT, > > reply. I will never implement it with my efishell. > > > > I hope that my efishell is a quick and easy way of learning more about > > u-boot's uefi environment. I will be even happier if more people > > get involved there. > > > > > Due to these considerations I suggest that you build your UEFI shell > > > implementation as a separate UEFI binary (like helloworld.efi). You > > > may > > > offer an embedding of the
Re: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata
On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut wrote: > > On 1/7/19 10:14 PM, Simon Goldschmidt wrote: > > This is an initial attempt to support OF_PLATDATA for socfpga gen5. > > > > There are two motivations for this: > > a) reduce code size to eventually support secure boot (where SPL has to > >authenticate the next stage by loading/checking U-Boot from a FIT > >image) > > b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM > >(on warm-restart), all bytes to check need to be in one piece. With > >OF_SEPARATE, this is not the case (.bss is between .rodata and the > >DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to > >be a good solution. > > I'd much prefer parsing the DT (and thus, decoupling the SW from HW) > than having some ad-hoc plat data again if we can avoid that. So you're against the whole OF_PLATDATA thing or how should I understand that? It's not really ad-hoc, it's the DT converted to C structs. It's just in another format, but it's still (sort of) decoupled SW from HW. As written above, I have two goals I want to achieve with this. Right now, I cannot enable verified boot in SPL because the available OCRAM cannot hold all the code. And it seemed to me OF_PLATDATA could help me there. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata
On Mon, Jan 7, 2019 at 10:59 PM Lukasz Majewski wrote:
>
> Hi Simon,
>
> > This is an initial attempt to support OF_PLATDATA for socfpga gen5.
> >
> > There are two motivations for this:
> > a) reduce code size to eventually support secure boot (where SPL has
> > to authenticate the next stage by loading/checking U-Boot from a FIT
> >image)
> > b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM
> >(on warm-restart), all bytes to check need to be in one piece. With
> >OF_SEPARATE, this is not the case (.bss is between .rodata and the
> >DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to
> >be a good solution.
>
> I'm not an expert with SOCFPGA nor your application, but maybe
> selecting: "SPL_SEPARATE_BSS" would fix your issue?
>
> This option allows putting on IMX6 SPL the DTB blob into OCRAM (internal
> RAM), before the DDR is setup (so it would be possible to calculate
> CRC).
In socfpga, the whole SPL is copied into OCRAM by the boot ROM and executed
from there. How can OF_SEPARATE help here? I tried enabling it but the SPL map
file does not change. The only difference is there is no padding
between the binary
and the DTB ('u-boot-spl-nodtb.bin' vs 'u-boot-spl-dtb.bin')
Regards,
Simon
>
> I've stumbled upon such issue when I wanted to switch from OF_EMBEDDED
> to OF_SEPARATE.
>
> >
> > This series enables booting from MMC with OF_PLATDATA. Booting from
> > SPI does not yet work (I'm working on that, but it's tougher than
> > expected).
> >
> > Tested on the socrates board. To use it:
> > - use socfpga_socrates_defconfig
> > - disable CONFIG_SPL_SPI_FLASH_SUPPORT, CONFIG_SPL_SPI_SUPPORT and
> > CONFIG_SPL_DM_RESET (those don't work yet)
> > - enable CONFIG_DESIGNWARE_SERIAL (required for console)
> >
> >
> > Simon Goldschmidt (4):
> > arm: socfpga: imply SPL config instead of select
> > arm: socfpga: fix compiling with OF_PLATDATA
> > serial: add an of-platdata driver for "snps,dw-apb-uart"
> > mmc: socfpga: support of-platdata
> >
> > arch/arm/Kconfig | 4 ++--
> > arch/arm/mach-socfpga/misc.c | 2 +-
> > drivers/mmc/socfpga_dw_mmc.c | 28 ---
> > drivers/serial/Kconfig | 10
> > drivers/serial/Makefile| 1 +
> > drivers/serial/serial_dw_apb.c | 42
> > ++ 6 files changed, 81 insertions(+),
> > 6 deletions(-) create mode 100644 drivers/serial/serial_dw_apb.c
> >
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5
On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut wrote:
>
> On 1/7/19 10:01 PM, Simon Goldschmidt wrote:
> > Am 07.01.2019 um 21:47 schrieb Marek Vasut:
> >> On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
> >>> Am 07.01.2019 um 21:25 schrieb Marek Vasut:
> On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
> > Am 07.01.2019 um 21:19 schrieb Marek Vasut:
> >> On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
> >>> When debug UART is enabled on socfpga_gen5, the debug uart driver
> >>> hangs
> >>> in an endless loop because 'socfpga_bridges_reset' calls printf
> >>> before
> >>> the debug UART is initialized.
> >>>
> >>> After the generic fix for this in the UART driver did not work
> >>> due to
> >>> portability issues, let's just drop this printf statement when
> >>> called
> >>> from SPL with debug UART enabled.
> >>>
> >>> Signed-off-by: Simon Goldschmidt
> >>
> >> Can we have an un-portable fix which at least works on SoCFPGA ? :)
> >
> > This one worked on socfpga but broke rockchip:
> >
> > https://patchwork.ozlabs.org/patch/992553/
> >
> > However, the message below wasn't shown either with that patch
> > applied.
> > The code just runs too early to enable the UART.
> >
> > Do you want to keep the message (although I failed to see in which
> > situation it can be printed) or do you just dislike the #ifdef thing?
>
> I'd like to keep the error message if possible. Is it possible ?
> >>>
> >>> I have *never* seen this message yet. I have failed to produce a
> >>> situation where it is shown.
> >>
> >> I believe that.
> >>
> >>> This function ('socfpga_bridges_reset') is called 5 times throughout the
> >>> code, but only *one* single time with 'reset=0' as argument (only with
> >>> 0, the code in question is executed). And this is in SPL before
> >>> initializing the console and even before the debug UART can be
> >>> initialized.
> >>>
> >>> As I could see, the printf *is* executed on every boot (I saw the code
> >>> hanging when enabling debug UART). However, when not booting from FPGA,
> >>> it is just normal that the FPGA is not ready when running SPL. Why do
> >>> you want an error message here anyway?
> >>
> >> I was under the impression this is an error message, but it might not be
> >> so ? Maybe the wording is incorrect ?
> >
> > Now that I re-read it, "aborting" is incorrect, yes.
> >
> > So how should we proceed? This is an error message that can never be
> > shown (like the code is now) but breaks debug UART.
> >
> > I'd say we can drop it altogether. It might only be interesint if (in
> > the future) that code would get called from somewhere else (i.e. later,
> > after console initialization).
> >
> > Re-reading spl_gen5.c, there are some 'debug' calls before the debug
> > uart is initialized which probably would need to be removed as well, but
> > that's a different story...
>
> How come those don't hang the system then ?
I just haven't enabled debug output in spl_gen5.c, yet. I guess they would hang
the system when enabling them.
While it would be easy to remove these debug statements, to be future-proof
it would of course make sense to make the debug UART robust against this.
But given the problems with Rockchip ns16550, we would need a dedicated
debug UART for socfpga to solve this. And that would probably mean code
duplication.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting on RK3399[Please note, mail behalf by s...@google.com]
Hi Simon, On 01/08/2019 08:38 AM, Simon Glass wrote: > Hi Mark, > > On Sat, 5 Jan 2019 at 09:05, Mark Kettenis wrote: >>> From: Simon Glass >>> Date: Sat, 5 Jan 2019 08:56:07 -0700 >>> >>> Hi Mark, >>> >>> On Fri, 4 Jan 2019 at 20:35, Simon Glass wrote: Hi Mark, On Fri, 4 Jan 2019 at 13:43, Simon Glass wrote: > Hi Mark, > > On Fri, 4 Jan 2019 at 13:29, Mark Kettenis > wrote: >>> From: Simon Glass >>> Date: Fri, 4 Jan 2019 13:12:58 -0700 >>> >>> Hi Mark, >>> >>> On Fri, 4 Jan 2019 at 12:43, Mark Kettenis >>> wrote: So obviously that diff is needed to boot properly from uSD. I'll send out a git patch with a proper commit messages in a bit. >>> Yes I have the diff. What toolchain version are you using? >> I'm using the following OpenBSD packages: >> >> aarch64-none-elf-binutils-2.27p0 >> aarch64-none-elf-gcc-linaro-6.3.2017.02p3 >> >> which is binutils 2.27 and the Linaro GCC 6.3.2017.02 with minimal >> patches to get them to build on OpenBSD. > OK thank you. I'll try again when I get back. Something funny is going on. I pushed my tree to u-boot-dm/rk-working export ARCH=arm CROSS_COMPILE=/opt/linaro/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- O=/tmp/b/firefly-rk3399 /tmp/b/firefly-rk3399> ln -s ~/cosarm/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf make -s firefly-rk3399_defconfig && make -s -j16 && make -s u-boot.itb && /tmp/b/firefly-rk3399/tools/mkimage -n rk3399 -T rksd -d /tmp/b/firefly-rk3399/spl/u-boot-spl.bin idbspl.img && sudo dd if=idbspl.img of=/dev/sdb seek=64 && sudo dd if=/tmp/b/firefly-rk3399/u-boot.itb of=/dev/sdb seek=16384 && sync Output is U-Boot SPL board init abc.d123456 7fe90 at which point it hangs. Hopefully I've done something silly in the setup. Any chance you could share your image? Thanks for your help. I am sure I had the board running at one point. >>> Thanks for the image - I tried it with the same result. I think my >>> board is 4GB - perhaps there is a memory init problem still? >> Not inconceivable. My board indeed only has 2GB. > OK thanks. Oddly I got this running on Bob which also has 4GB and did > not have this problem. For 4GB ddr3, maybe you need to use arch/arm/dts/rk3399-sdram-ddr3-4G-1600.dtsi, and you can turn on DEBUG so that we can confirm if hang in dram init driver. Thanks, - Kever > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] usb: xhci-mem: Fix scratchpad array issue
On Tue, Jan 8, 2019 at 12:00 PM Ye Li wrote: > > On 1/7/2019 5:54 PM, Bin Meng wrote: > > On Mon, Jan 7, 2019 at 10:45 AM Ye Li wrote: > >> > >> After updating the value of dev_context_ptrs[0], we should flush this > >> from cache to memory. Otherwise the xhci controller won't use it. > >> > >> Signed-off-by: Ye Li > >> Reviewed-by: Marek Vasut > >> --- > >> Changes for v2: > >>- Change to use sizeof(ctrl->dcbaa->dev_context_ptrs[0]) > >> > >> drivers/usb/host/xhci-mem.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > > > > Reviewed-by: Bin Meng > > > > But you need do the same in xhci_scratchpad_free() too. Please fix it in v3. > > > The xhci controller has been stopped before calling xhci_scratchpad_free, is > it necessary to > add flush in this function? And I don't see other buffers are flushed when > freeing. > Ah, yes. It's called after HCD reset, so that's not needed. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] arm: socfpga: fix compiling with OF_PLATDATA
On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut wrote:
>
> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> > 'socfpga_eth_reset_common' must not be compiled when OF_PLATDATA is enabled
> > since it uses functions accessing the devicetree.
> >
> > Since this function is not used in SPL anyway, change the compile guard
> > to reflect this and fix compiling SPL with OF_PLATDATA.
>
> Doesn't this break ethernet in SPL ? I think it does. The real fix is to
> move this PHY mode configuration into the driver.
Hmm, ethernet in SPL. Haven't thought of that :-)
While it could be easy to move the DTS part of PHY mode configuration into
the driver, moving the reset portion of that code into the driver would be ugly
unless using proper reset management?
>
> > Signed-off-by: Simon Goldschmidt
> > ---
> >
> > arch/arm/mach-socfpga/misc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> > index 78fbe28724..30f74d9940 100644
> > --- a/arch/arm/mach-socfpga/misc.c
> > +++ b/arch/arm/mach-socfpga/misc.c
> > @@ -120,7 +120,7 @@ int arch_cpu_init(void)
> > return 0;
> > }
> >
> > -#ifdef CONFIG_ETH_DESIGNWARE
> > +#if defined CONFIG_ETH_DESIGNWARE && !defined CONFIG_SPL_BUILD
Would it work for you to change this into:
#if defined CONFIG_ETH_DESIGNWARE && !CONFIG_IS_ENABLED(OF_PLATDATA)
We could still fix the reset code when actually using OF_PLATDATA with
ethernet...
Regards,
Simon
> > static int dwmac_phymode_to_modereg(const char *phymode, u32 *modereg)
> > {
> > if (!phymode)
> >
>
>
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select
On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut wrote: > > On 1/7/19 10:14 PM, Simon Goldschmidt wrote: > > In order to build a smaller SPL, let's imply SPL_DM_RESET and > > SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled > > via defconfig. > > > > This also seems to be required to use OF_PLATDATA, as the reset drivers > > don't seem to work with it. > > How do you un-reset IP blocks if you disable the reset controller ? Here again, socfpga seems to be another bad example. Taking peripherals out of reset is cluttered throughout the mach-socfpga code at least in SPL. By now I know socfpga is lacking support for clock and reset management via devicetree. And this is bad, I know, but can we keep this a seperate issue from OF_PLATDATA? That being said, drivers/reset/reset-uclass.c fails to compile with OF_PLATDATA, so I guess this has not been used with OF_PLATDATA before. And given that I don't seem to need it for socfpga either, I don't think this would be the right series to fix that. Regards, Simon > > > Signed-off-by: Simon Goldschmidt > > --- > > > > arch/arm/Kconfig | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 520ea8bed9..1ca71bd323 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -815,7 +815,6 @@ config ARCH_SOCFPGA > > select DM_SERIAL > > select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || > > TARGET_SOCFPGA_ARRIA10 > > select OF_CONTROL > > - select SPL_DM_RESET if DM_RESET > > select SPL_DM_SERIAL > > select SPL_LIBCOMMON_SUPPORT > > select SPL_LIBGENERIC_SUPPORT > > @@ -823,7 +822,6 @@ config ARCH_SOCFPGA > > select SPL_OF_CONTROL > > select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10 > > select SPL_SERIAL_SUPPORT > > - select SPL_WATCHDOG_SUPPORT > > select SUPPORT_SPL > > select SYS_NS16550 > > select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || > > TARGET_SOCFPGA_ARRIA10 > > @@ -833,12 +831,14 @@ config ARCH_SOCFPGA > > imply DM_SPI > > imply DM_SPI_FLASH > > imply FAT_WRITE > > + imply SPL_DM_RESET > > imply SPL_LIBDISK_SUPPORT > > imply SPL_MMC_SUPPORT > > imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION > > imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE > > imply SPL_SPI_FLASH_SUPPORT > > imply SPL_SPI_SUPPORT > > + imply SPL_WATCHDOG_SUPPORT > > > > config ARCH_SUNXI > > bool "Support sunxi (Allwinner) SoCs" > > > > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] serial: add an of-platdata driver for "snps, dw-apb-uart"
On Mon, Jan 7, 2019 at 11:12 PM Lukasz Majewski wrote:
>
> Hi Simon,
>
> > Add a driver for the "snps,dw-apb-uart" used in socfpga and others.
> >
> > This driver is required to get OF_PLATDATA to work for socfpga.
> > It uses the ns16550 driver, converting the platdata from of-platdata
> > go the ns16550 format.
> >
> > Signed-off-by: Simon Goldschmidt
> > ---
> >
> > drivers/serial/Kconfig | 10
> > drivers/serial/Makefile| 1 +
> > drivers/serial/serial_dw_apb.c | 42
> > ++ 3 files changed, 53 insertions(+)
> > create mode 100644 drivers/serial/serial_dw_apb.c
> >
> > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> > index b7ff2960ab..10addd3309 100644
> > --- a/drivers/serial/Kconfig
> > +++ b/drivers/serial/Kconfig
> > @@ -511,6 +511,16 @@ config BCM283X_PL011_SERIAL
> > that supports automatic disable, so that it only gets used
> > when the UART is actually muxed.
> >
> > +config DESIGNWARE_SERIAL
> > + bool "DesignWare UART support"
> > + depends on DM_SERIAL && SPL_OF_PLATDATA
> > + help
> > + Select this to enable a UART driver for "snps,dw-apb-uart"
> > devices
> > + when using CONFIG_SPL_OF_PLATDATA (i.e. a compiled-in
> > device tree
> > + replacement).
> > + This uses the ns16550 driver, converting the platdata from
> > of-platdata
> > + to the ns16550 format.
> > +
> > config BCM6345_SERIAL
> > bool "Support for BCM6345 UART"
> > depends on DM_SERIAL
> > diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
> > index 06ee30697d..f1ebb90d92 100644
> > --- a/drivers/serial/Makefile
> > +++ b/drivers/serial/Makefile
> > @@ -46,6 +46,7 @@ obj-$(CONFIG_MESON_SERIAL) += serial_meson.o
> > obj-$(CONFIG_INTEL_MID_SERIAL) += serial_intel_mid.o
> > ifdef CONFIG_SPL_BUILD
> > obj-$(CONFIG_ROCKCHIP_SERIAL) += serial_rockchip.o
> > +obj-$(CONFIG_DESIGNWARE_SERIAL) += serial_dw_apb.o
> > endif
> > obj-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
> > obj-$(CONFIG_SANDBOX_SERIAL) += sandbox.o
> > diff --git a/drivers/serial/serial_dw_apb.c
> > b/drivers/serial/serial_dw_apb.c new file mode 100644
> > index 00..26580e5ba5
> > --- /dev/null
> > +++ b/drivers/serial/serial_dw_apb.c
> > @@ -0,0 +1,42 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2018 Simon Goldschmidt
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > +struct dw_apb_uart_platdata {
> > + struct dtd_snps_dw_apb_uart dtplat;
> > + struct ns16550_platdata plat;
> > +};
> > +
> > +static int dw_apb_serial_probe(struct udevice *dev)
> > +{
> > + struct dw_apb_uart_platdata *plat = dev_get_platdata(dev);
> > +
> > + /* Set up correct platform data for the standard driver */
> > + plat->plat.base = plat->dtplat.reg[0];
> > + plat->plat.reg_shift = plat->dtplat.reg_shift;
> > + plat->plat.reg_width = plat->dtplat.reg_io_width;
> > + plat->plat.clock = plat->dtplat.clock_frequency;
> > + plat->plat.fcr = UART_FCR_DEFVAL;
> > + dev->platdata = >plat;
> > +
> > + return ns16550_serial_probe(dev);
> > +}
> > +
> > +U_BOOT_DRIVER(snps_dw_apb_uart) = {
> > + .name = "snps_dw_apb_uart",
> > + .id = UCLASS_SERIAL,
> > + .priv_auto_alloc_size = sizeof(struct NS16550),
> > + .platdata_auto_alloc_size = sizeof(struct
> > dw_apb_uart_platdata),
> > + .probe = dw_apb_serial_probe,
> > + .ops= _serial_ops,
> > + .flags = DM_FLAG_PRE_RELOC,
>
> Is it possible/or is your application requiring the pinmux/clock setting
> for this serial?
No, the socfpga gen5 platform is somewhat of a real bad example regarding
pinmux and clocks. These are implemented completely separate, based on
files generated by the FPGA toolchain...
And as you can see above, the clock must be encoded into the DTS (and
platdata) instead of calculating it via clock references.
This might be valid for socfpga only, and this driver migth be used on other
boards as well. But I think it wouldn't hurt to start it like this and continue
improving it once it is used on other platforms - it has to be actively enabled
and is only used for SPL with OF_PLATDATA.
> With OF_PLATDATA we don't need to parse (and provide) the DTS (and we
> use the DM/DTS driver's code in a way similar to "native" one).
>
> I'm wondering, if it would be possible to "mimic" the dependencies
> between DM drivers without DTS parsing / providing overhead.
I'm actually working on something like that as I want to use QSPI with of-
platdata and there I need the parent/child connection between the SPI
master and the spi-flash...
> At least in my case I would need in SPL:
>
> -> driver XXX (working with u-boot proper's DM/DTS)
> ---> CLK (uclass-clk) to enable clocks
Clock binding might already work with dtoc, but I haven't tried.
> ---> pinctrl (to config
Re: [U-Boot] Regression in 2019.01-rc2 for eMMC boot on mxs board?
Simon Glass [2019-01-07 17:38:31]: > Yes, I believe these is a patch to fix this. https://patchwork.ozlabs.org/patch/1014381/ -- ynezz ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2019.01-rc3 released
Hey all, It's release day and, we're not doing the final release. I sent out an email on Friday saying I was doing a week delay, and here we are. Too much stuff came in post -rc2, for various reasons, and I couldn't just release it. We also still have: - A USB gadget / fastboot / etc issue to resolve fully. - A FAT regression on some platforms due to a fix on others. - A regression due to d0851c893706 (patch exists, needs to be pulled in). - Two SATA ENV issues to grab patches for. Of which only the FAT issue isn't something we have a patch for and the change in question may get reverted for now. That said, here's the changelog for -rc3 and I intend to release v2019.01 next Monday, the 14th. - Samsung, Rockchip, i.MX, video, SPI, x86, EFI, UniPhier, TI, MediaTek, Marvell, SoCFPGA, amlogic, MIPS and RISC-V updates. - This includes among other things, pulling in the Ci20 platform support, fixing at least one regression in EFI support, synchronizing some i.MX8 related locations and files and other important bugfixes. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] usb: xhci-mem: Fix scratchpad array issue
On 1/7/2019 5:54 PM, Bin Meng wrote: > On Mon, Jan 7, 2019 at 10:45 AM Ye Li wrote: >> >> After updating the value of dev_context_ptrs[0], we should flush this >> from cache to memory. Otherwise the xhci controller won't use it. >> >> Signed-off-by: Ye Li >> Reviewed-by: Marek Vasut >> --- >> Changes for v2: >>- Change to use sizeof(ctrl->dcbaa->dev_context_ptrs[0]) >> >> drivers/usb/host/xhci-mem.c | 3 +++ >> 1 file changed, 3 insertions(+) >> > > Reviewed-by: Bin Meng > > But you need do the same in xhci_scratchpad_free() too. Please fix it in v3. > > Regards, > Bin > The xhci controller has been stopped before calling xhci_scratchpad_free, is it necessary to add flush in this function? And I don't see other buffers are flushed when freeing. Best regards, Ye Li ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Makefile: Correct logic for DM_SCSI + unconverted drivers check
When checking for boards that are enabling a SATA driver that isn't
converted to DM yet we need to be sure to not also trip over boards that
do set CONFIG_DM_SCSI by itself, as that is not a bug.
Reported-by: Andy Shevchenko
Fixes: ea9d7c17fc4c ("dm: MIGRATION: Add migration plan for CONFIG_SATA")
Signed-off-by: Tom Rini
---
Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 27c09199a446..e3e54a393f68 100644
--- a/Makefile
+++ b/Makefile
@@ -938,7 +938,8 @@ ifneq
($(CONFIG_DM_USB)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy)
@echo >&2 ""
endif
endif
-ifeq ($(CONFIG_LIBATA)$(CONFIG_DM_SCSI)$(CONFIG_MVSATA_IDE),y)
+ifeq ($(CONFIG_LIBATA)$(CONFIG_MVSATA_IDE),y)
+ifneq ($(CONFIG_DM_SCSI),y)
@echo >&2 "= WARNING =="
@echo >&2 "This board does not use CONFIG_DM_SCSI. Please update"
@echo >&2 "the storage controller to use CONFIG_DM_SCSI before the
v2019.07 release."
@@ -946,6 +947,7 @@ ifeq
($(CONFIG_LIBATA)$(CONFIG_DM_SCSI)$(CONFIG_MVSATA_IDE),y)
@echo >&2 "See doc/driver-model/MIGRATION.txt for more info."
@echo >&2 ""
endif
+endif
ifeq ($(CONFIG_OF_EMBED),y)
@echo >&2 "= WARNING =="
@echo >&2 "CONFIG_OF_EMBED is enabled. This option should only"
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bogus message about SCSI during build
Hi Andy, On Tue, Jan 8, 2019 at 2:38 AM Andy Shevchenko wrote: > > On Mon, Jan 7, 2019 at 8:34 PM Andy Shevchenko > wrote: > > On Wed, Dec 26, 2018 at 6:38 PM Tom Rini wrote: > > > On Thu, Dec 13, 2018 at 12:52:21PM +0800, Bin Meng wrote: > > > > On Wed, Dec 12, 2018 at 12:21 AM Andy Shevchenko > > > > wrote: > > > > > > Since X86 implies SCSI and Intel Edison board does not use it, I have > > > > > got a > > > > > = WARNING == > > > > > This board does not use CONFIG_DM_SCSI. Please update > > > > > the storage controller to use CONFIG_DM_SCSI before the v2019.07 > > > > > release. > > > > > Failure to update by the deadline may result in board removal. > > > > > See doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > > > > Is anybody aware of? > > > > > > > > AFAIK , this warning message is intentional to push board maintainers > > > > to convert their boards over to driver model. > > > > > > > > For the edison board, if SCSI is not used. you can turn it off in the > > > > board defconfig file. > > > > > > Right. Our warnings now are perhaps a bit too easy to trip over because > > > there are cases like this where you don't need SCSI (or other things) > > > but have them on without having DM_xxx and BLK enabled. In this case > > > the right thing to do is disable stuff you don't need. > > > > What stuff? > > The platform does have DM_MMC and BLK as far as I can see, other than > > that I have no idea how CONFIG_DM_SCSI becomes set. > > Something broken upper, not on this certain board. > > config X86 > ... > imply DM_SCSI > ... > > This has to be fixed, not my board. Message now is bogus. > No. SCSI is common for almost all x86 boards, hence we use 'imply'. And we acknowledge that some boards may not have it so we don't use 'select'. You can turn it off in your board defconfig. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting on RK3399
Hi Mark, On Sat, 5 Jan 2019 at 09:05, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Sat, 5 Jan 2019 08:56:07 -0700 > > > > Hi Mark, > > > > On Fri, 4 Jan 2019 at 20:35, Simon Glass wrote: > > > > > > Hi Mark, > > > > > > On Fri, 4 Jan 2019 at 13:43, Simon Glass wrote: > > > > > > > > Hi Mark, > > > > > > > > On Fri, 4 Jan 2019 at 13:29, Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Simon Glass > > > > > > Date: Fri, 4 Jan 2019 13:12:58 -0700 > > > > > > > > > > > > Hi Mark, > > > > > > > > > > > > On Fri, 4 Jan 2019 at 12:43, Mark Kettenis > > > > > > wrote: > > > > > > > So obviously that diff is needed to boot properly from uSD. I'll > > > > > > > send > > > > > > > out a git patch with a proper commit messages in a bit. > > > > > > > > > > > > Yes I have the diff. What toolchain version are you using? > > > > > > > > > > I'm using the following OpenBSD packages: > > > > > > > > > > aarch64-none-elf-binutils-2.27p0 > > > > > aarch64-none-elf-gcc-linaro-6.3.2017.02p3 > > > > > > > > > > which is binutils 2.27 and the Linaro GCC 6.3.2017.02 with minimal > > > > > patches to get them to build on OpenBSD. > > > > > > > > OK thank you. I'll try again when I get back. Something funny is going > > > > on. > > > > > > I pushed my tree to u-boot-dm/rk-working > > > > > > export ARCH=arm > > > CROSS_COMPILE=/opt/linaro/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- > > > O=/tmp/b/firefly-rk3399 > > > > > > /tmp/b/firefly-rk3399> ln -s > > > ~/cosarm/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf > > > > > > make -s firefly-rk3399_defconfig && make -s -j16 && make -s u-boot.itb > > > && /tmp/b/firefly-rk3399/tools/mkimage -n rk3399 -T rksd -d > > > /tmp/b/firefly-rk3399/spl/u-boot-spl.bin idbspl.img && sudo dd > > > if=idbspl.img of=/dev/sdb seek=64 && sudo dd > > > if=/tmp/b/firefly-rk3399/u-boot.itb of=/dev/sdb seek=16384 && sync > > > > > > Output is > > > > > > U-Boot SPL board init > > > abc.d123456 7fe90 > > > > > > at which point it hangs. > > > > > > Hopefully I've done something silly in the setup. Any chance you could > > > share your image? > > > > > > Thanks for your help. I am sure I had the board running at one point. > > > > Thanks for the image - I tried it with the same result. I think my > > board is 4GB - perhaps there is a memory init problem still? > > Not inconceivable. My board indeed only has 2GB. OK thanks. Oddly I got this running on Bob which also has 4GB and did not have this problem. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Issue faced due to "serial: Remove DM_FLAG_PRE_RELOC flag in various drivers" patch
Hi, On Mon, 7 Jan 2019 at 00:19, Priyanka Jain wrote: > > Hello Simon, > > > > Creating a duplicate driver for enabling the flag will add a lot of redundant > code. Please can you avoid top posting? > > Is there a way, I can add some conditional code to enable this flag for case > when pl01x_serial_platdata in the same driver. Firstly, can you use device tree? No you cannot add an arch-specific #ifdef here. Is the overhead a lot? Regards, Simon > > > > Regards > > Priyanka > > From: Simon Glass > Sent: Friday, January 4, 2019 3:00 AM > To: Priyanka Jain > Cc: bmeng...@gmail.com; York Sun ; Vabhav Sharma > ; u-boot@lists.denx.de > Subject: Re: Issue faced due to "serial: Remove DM_FLAG_PRE_RELOC flag in > various drivers" patch > > > > Hi Priyanka, > > > > On Thu, 3 Jan 2019 at 03:31, Priyanka Jain wrote: > > Hello, > > I am working to add support for NXP LX2160ARDB board support" > "https://patchwork.ozlabs.org/patch/1004541/; > > For serial driver, we are using PL01X_SERIAL driver with DM_SERIAL enabled > Since we need to support various clock frequencies, we have defined > pl01x_serial_platdata in board file > So it's a combination of CONFIG_DM_SERIAL + pl01x_serial_platdata > > Also we have requirement to use serial driver before relocation as well. > > Now with the patch " serial: Remove DM_FLAG_PRE_RELOC flag in various > drivers" > the flag "DM_FLAG_PRE_RELOC" is no longer getting set resulting in UART > driver not being available before relocation. > > I tried adding "u-boot,dm-pre-reloc" in uart node, but it doesn't helped. > [May be because uart nodes are set to disable to use 'pl01x_serial_platdata' > method] > > Can you please provide some suggestions on this issue. > How to use "DM_SERIAL + pl01x_serial_platdata" feature in pre_reloc phase? > > > > This really should be using device tree - how come your board cannot use that? > > > > But it seems that removing the flag has in fact made it impossible to use > platdata before relocation? That seems bad. One option is to create your own > driver when that flag set. > > > > Regards, > > Simon > > > > > Regards > Priyanka > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cmd: sf: use correct printf code
On Sun, 6 Jan 2019 at 04:03, Heinrich Schuchardt wrote: > > test->time_ms[] is defined as unsigned. So use %u for printf(). > > Signed-off-by: Heinrich Schuchardt > --- > cmd/sf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Regression in 2019.01-rc2 for eMMC boot on mxs board?
On Sat, 5 Jan 2019 at 01:39, Michael Heimpold wrote: > > Hi, > > this morning I bisected the issue and found the following commit is causing > it: > > d0851c8937067ad396f2bdafc46d0326bf3317db is the first bad commit > commit d0851c8937067ad396f2bdafc46d0326bf3317db > Author: Bin Meng > Date: Mon Oct 15 02:21:07 2018 -0700 > > blk: Call part_init() in the post_probe() method Yes, I believe these is a patch to fix this. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rk3399 sdram data training read gate is looping forever
Hi Jagan, On Sat, 5 Jan 2019 at 12:58, Jagan Teki wrote: > > Hi, > > I'm trying to bring-up rk3399 SBC with 1GB DDR3 933MHZ capable, and > observed an sdram_init issue where data_training_rg transfer is > looping forever. The denali_pi[80], and denali_pi[74] seems to be > proper values while setting up the particular ranks. > > Can anyone encounter similar issue? let me know for any inputs. > > Log: I have not seen this so far. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] sandbox: i2c_emul_find() No emulators for device 'rtc@43'
On Sat, 5 Jan 2019 at 14:30, Heinrich Schuchardt wrote:
>
> when running the date command on sandbox_defconfig an error occurs:
>
> ./u-boot -D u-boot.dtb
>
> => date
> i2c_emul_find() No emulators for device 'rtc@43'
> ## Get date failed
>
> Correct the references to the emulator devices in the sandbox device trees
> using test.dts as a reference.
>
> Fixes: 031a650e1309 ("dm: sandbox: i2c: Use new emulator parent uclass")
> Signed-off-by: Heinrich Schuchardt
> ---
> arch/sandbox/dts/sandbox.dts | 8
> arch/sandbox/dts/sandbox64.dts | 6 --
> 2 files changed, 8 insertions(+), 6 deletions(-)
Thanks
Reviewed-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cmd: gpio: use correct printf code
On Sun, 6 Jan 2019 at 03:32, Heinrich Schuchardt wrote: > > gpio is defined as unsigned int. So we should use %u when calling printf(). > > Signed-off-by: Heinrich Schuchardt > --- > cmd/gpio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
Hi,
On Thu, 6 Dec 2018 at 03:37, Thomas Petazzoni
wrote:
>
> Hello Stefan,
>
> On Wed, 5 Dec 2018 12:30:57 +0100, Stefan Roese wrote:
>
> > > It's weird to me that it's happening with this SoC because it's based on
> > > ARM926ejs which is widely used I assume. Shouldn't have anyone already
> > > encountered the bug? Or is nobody actually booting a fitImage and had the
> > > luck to never call memcpy with src == dest anywhere else in the code?
> >
> > I did some work on the SPEAr600 some years ago and I'm pretty sure that
> > I never used FIT image at that time. Sorry, but I can't remember any
> > similar issues like these.
>
> Well, the issue is in generic ARM code, so whether it's SPEAr600 or any
> other ARM SoC should not really matter here.
>
> > FWIW, I would not oppose to having at least this "src == dest" check
> > in the code again, since it doesn't really make sense to overwrite
> > an area with the same value - other than for testing purposes.
>
> The thing is that the memcpy() that gets called does have this src ==
> dest check, as its code starts with:
>
> ENTRY(memcpy)
> cmp r0, r1
> bxeqlr
>
> which, if my assembly-fu is not bad, means: if first argument == second
> argument, then return. But even with this src == dest check within
> memcpy() itself, Quentin is seeing memmove() hang when src == dest.
>
> Another thing is that the memmove() code looks like this:
>
> {
> char *tmp, *s;
>
> if (dest <= src) {
> memcpy(dest, src, count);
>
> However, having dest <= src does not guarantee that the destination and
> source areas are non-overlapping. And the normal semantic for memcpy()
> is that it doesn't work for overlapping areas. From memcpy(3):
>
> The memcpy() function copies n bytes from memory area src to memory
> area dest. The memory areas must not overlap. Use memmove(3) if the
> memory areas do overlap.
>
> Of course, this man page documents the memcpy() implementation from the
> C library, and perhaps the semantic of U-Boot memcpy is different.
Yes I suppose it is different.
>
> So is it correct to use memcpy() to implement memmove() when the areas
> are overlapping ?
Strictly speaking, no. I think perhaps my patch should have been more careful.
>
> Perhaps Simon Glass, who did the change to use memcpy() in
> cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2 could comment on that ?
>
That said, I cannot see why the memcpy() fails. How do you explain
that? If you revert my change, does it work?
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm
Hi Tom,
On Fri, 4 Jan 2019 at 22:00, Tom Rini wrote:
>
> On Fri, Jan 04, 2019 at 01:47:08PM -0700, Simon Glass wrote:
>
> > Hi Tom,
> >
> > https://travis-ci.org/sglass68/u-boot/builds/474968097
> >
> >
> > The following changes since commit f97c49d6a2f504d0f0a8aab37c67aa314e006250:
> >
> > Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-01-01
> > 19:55:05 -0500)
> >
> > are available in the Git repository at:
> >
> > git://git.denx.de/u-boot-dm.git tags/dm-pull-4jan19
> >
> > for you to fetch changes up to 1b4770dfe03b5dd1dfd2a6076c4c85ee566e360a:
> >
> > sandbox: Correct SDL build flags (2019-01-03 11:06:07 -0700)
>
> So, the clang switch doesn't catch warnings anymore. While travis is
> clean, my local hand-build shows:
> /home/trini/u-boot/u-boot/lib/efi_loader/efi_file.c:224:61: warning: format
> specifies type 'wchar_t *' (aka 'unsigned short *') but the argument has type
> 's16 *' (aka 'short *') [-Wformat]
> EFI_ENTRY("%p, %p, \"%ls\", %llx, %llu", file, new_handle, file_name,
> ~~~ ^
> /home/trini/u-boot/u-boot/include/efi_loader.h:40:15: note: expanded from
> macro 'EFI_ENTRY'
> __func__, ##__VA_ARGS__); \
> ^~~
> /home/trini/u-boot/u-boot/include/log.h:164:28: note: expanded from macro
> 'debug'
> debug_cond(_DEBUG, fmt, ##args)
> ^~~~
> /home/trini/u-boot/u-boot/include/log.h:144:41: note: expanded from macro
> 'debug_cond'
> log(LOG_CATEGORY, LOGL_DEBUG, fmt, ##args); \
> ^~~~
> /home/trini/u-boot/u-boot/include/log.h:121:25: note: expanded from macro
> 'log'
> pr_fmt(_fmt), ##_args); \
> ^
> 1 warning generated.
>
> So the log changes have a problem, and the buildman integration doesn't
> promote warnings right :(
Actually this uncovered a problem that I had not noticed before. I
sent a new series to take care of it. But given that today is release
day, I am unfortunately a little late!
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: fix memory allocation on sandbox
On Sat, 5 Jan 2019 at 15:41, Heinrich Schuchardt wrote:
>
> Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced
> a comparison between RAM top and RAM start that was not known at the time
> when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox
> addresses") was written.
>
> The sandbox uses an address space that is only relevant in the sandbox
> context. We have to map ram_top from the sandbox address space to the
> physical address space before using it in the EFI subsystem.
>
> Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses")
> Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory")
> Signed-off-by: Heinrich Schuchardt
> ---
> Travis CI showed no error:
> https://travis-ci.org/xypron2/u-boot/builds/475766261
> ---
> lib/efi_loader/efi_memory.c | 6 ++
> 1 file changed, 6 insertions(+)
Reviewed-by: Simon Glass
I'm not a big fan of using a u64 to store a pointer. By using ulong
for addresses and void * for pointers, we can make bugs like this
easier to spot.
>
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index 4bb517473e..0ae49f5d5f 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -554,6 +554,12 @@ __weak void efi_add_known_memory(void)
> u64 ram_top = board_get_usable_ram_top(0) & ~EFI_PAGE_MASK;
> int i;
>
> + /*
> +* ram_top is just outside mapped memory. So use an offset of one for
> +* mapping the sandbox address.
> +*/
> + ram_top = (uintptr_t)map_sysmem(ram_top - 1, 0) + 1;
> +
> /* Fix for 32bit targets with ram_top at 4G */
> if (!ram_top)
> ram_top = 0x1ULL;
> --
> 2.20.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols
On 01/07/19 20:22, Leif Lindholm wrote:
> On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote:
>> The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit aligned,
>> unless specified otherwise. See in "Table 5. Common UEFI Data Types":
>>
>> EFI_GUID -- 128-bit buffer containing a unique identifier value.
>> Unless otherwise specified, aligned on a 64-bit
>> boundary.
>
> Indeed.
>
>> Whether edk2 satisfies that, and if so, how (by chance / by general
>> build flags), I don't know. The code says,
>>
>> ///
>> /// 128 bit buffer containing a unique identifier value.
>> /// Unless otherwise specified, aligned on a 64 bit boundary.
>> ///
>> typedef struct {
>> UINT32 Data1;
>> UINT16 Data2;
>> UINT16 Data3;
>> UINT8 Data4[8];
>> } GUID;
>>
>> I think there may have been an expectation in "MdePkg/Include/Base.h"
>> that the supported compilers would automatically ensure the specified
>> alignment, given the structure definition.
>
> But that would be expecting things not only not guaranteed by C, but
> something there is no semantic information suggesting would be useful
> for the compiler to do above. [...]
Agreed. I'm not saying the edk2 code is right, just guessing why the
code might look like it does. This would not be the first silent
assumption, I think.
Anyhow, I think it would be better to change the code than the spec.
Thanks,
Laszlo
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] net: Fix error handling in sb_eth_raw_ofdata_to_platdata()
On Mon, Jan 7, 2019 at 5:47 PM Simon Glass wrote: > > At present this stores the error number in an unsigned int so an error is > never detected. Use the existing signed variable instead. > > Signed-off-by: Simon Glass Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/7] buildman: Add support for building with clang
Add a -O option which allows building with clang.
Signed-off-by: Simon Glass
---
Changes in v2:
- Use the command line instead of environment for make variables
tools/buildman/README | 10 +
tools/buildman/builderthread.py | 1 +
tools/buildman/cmdline.py | 2 ++
tools/buildman/control.py | 2 +-
tools/buildman/toolchain.py | 38 +
5 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/tools/buildman/README b/tools/buildman/README
index d688b7cf00..56a99c70a2 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -1046,6 +1046,16 @@ value for 'altbootcmd', but lost one for ' altbootcmd'.
The -U option uses the u-boot.env files which are produced by a build.
+
+Building with clang
+===
+
+To build with clang (sandbox only), use the -O option to override the
+toolchain. For example:
+
+ buildman -O clang-7 --board sandbox
+
+
Other options
=
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index b91634f3ab..6b156f152d 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -229,6 +229,7 @@ class BuilderThread(threading.Thread):
config_args = ['%s_defconfig' % brd.target]
config_out = ''
args.extend(self.builder.toolchains.GetMakeArguments(brd))
+args.extend(self.toolchain.MakeArgs())
# If we need to reconfigure, do that now
if do_config:
diff --git a/tools/buildman/cmdline.py b/tools/buildman/cmdline.py
index 93d09ca08d..832a5145d2 100644
--- a/tools/buildman/cmdline.py
+++ b/tools/buildman/cmdline.py
@@ -74,6 +74,8 @@ def ParseArgs():
parser.add_option('-o', '--output-dir', type='string',
dest='output_dir', default='..',
help='Directory where all builds happen and buildman has its
workspace (default is ../)')
+parser.add_option('-O', '--override-toolchain', type='string',
+ help="Override host toochain to use for sandbox (e.g. 'clang-7')")
parser.add_option('-Q', '--quick', action='store_true',
default=False, help='Do a rough build, with limited warning
resolution')
parser.add_option('-p', '--full-path', action='store_true',
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index c900211510..27916d3c35 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -141,7 +141,7 @@ def DoBuildman(options, args, toolchains=None,
make_func=None, boards=None,
no_toolchains = toolchains is None
if no_toolchains:
-toolchains = toolchain.Toolchains()
+toolchains = toolchain.Toolchains(options.override_toolchain)
if options.fetch_arch:
if options.fetch_arch == 'list':
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index c62ce136fa..b3c61827f3 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -54,9 +54,11 @@ class Toolchain:
arch: Architecture of toolchain as determined from the first
component of the filename. E.g. arm-linux-gcc becomes arm
priority: Toolchain priority (0=highest, 20=lowest)
+override_toolchain: Toolchain to use for sandbox, overriding the normal
+one
"""
def __init__(self, fname, test, verbose=False, priority=PRIORITY_CALC,
- arch=None):
+ arch=None, override_toolchain=None):
"""Create a new toolchain object.
Args:
@@ -68,6 +70,7 @@ class Toolchain:
"""
self.gcc = fname
self.path = os.path.dirname(fname)
+self.override_toolchain = override_toolchain
# Find the CROSS_COMPILE prefix to use for U-Boot. For example,
# 'arm-linux-gnueabihf-gcc' turns into 'arm-linux-gnueabihf-'.
@@ -81,6 +84,8 @@ class Toolchain:
self.arch = arch
else:
self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
+if self.arch == 'sandbox' and override_toolchain:
+self.gcc = override_toolchain
env = self.MakeEnvironment(False)
@@ -150,11 +155,18 @@ class Toolchain:
Args:
full_path: Return the full path in CROSS_COMPILE and don't set
PATH
+Returns:
+Dict containing the environemnt to use. This is based on the
current
+environment, with changes as needed to CROSS_COMPILE, PATH and
+LC_ALL.
"""
env = dict(os.environ)
wrapper = self.GetWrapper()
-if full_path:
+if self.override_toolchain:
+# We'll use MakeArgs() to provide this
+pass
+elif full_path:
env['CROSS_COMPILE'] = wrapper + os.path.join(self.path,
self.cross)
else:
env['CROSS_COMPILE'] = wrapper + self.cross
@@ -164,6 +176,22 @@ class Toolchain:
[U-Boot] [PATCH v2 4/7] travis: Use buildman for building with clang
Now that buildman supports clang, use it.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
---
Changes in v2: None
.travis.yml | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 321fd793a7..fc4d5a1d5c 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -109,16 +109,9 @@ script:
#
# From buildman, exit code 129 means warnings only. If we've been asked to
# use clang only do one configuration.
- - if [[ "${TOOLCHAIN}" == "clang" ]]; then
+ - if [[ "${BUILDMAN}" != "" ]]; then
ret=0;
- make O=../.bm-work/${TEST_PY_BD} HOSTCC=clang-7 CC=clang-7 -j$(nproc)
- KCFLAGS=-Werror sandbox_config all || ret=$?;
- if [[ $ret -ne 0 ]]; then
- exit $ret;
- fi;
- elif [[ "${BUILDMAN}" != "" ]]; then
- ret=0;
- tools/buildman/buildman -P -E ${BUILDMAN} || ret=$?;
+ tools/buildman/buildman -P -E ${BUILDMAN} ${OVERRIDE}|| ret=$?;
if [[ $ret -ne 0 && $ret -ne 129 ]]; then
tools/buildman/buildman -sdeP ${BUILDMAN};
exit $ret;
@@ -351,7 +344,7 @@ matrix:
env:
- TEST_PY_BD="sandbox"
BUILDMAN="^sandbox$"
- TOOLCHAIN="clang"
+ OVERRIDE="clang-7"
- name: "test/py sandbox_spl"
env:
- TEST_PY_BD="sandbox_spl"
--
2.20.1.97.g81188d93c3-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/7] net: Fix error handling in sb_eth_raw_ofdata_to_platdata()
At present this stores the error number in an unsigned int so an error is never detected. Use the existing signed variable instead. Signed-off-by: Simon Glass --- Changes in v2: None drivers/net/sandbox-raw.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/net/sandbox-raw.c b/drivers/net/sandbox-raw.c index 09cc678ebd..7e6625d020 100644 --- a/drivers/net/sandbox-raw.c +++ b/drivers/net/sandbox-raw.c @@ -152,7 +152,6 @@ static int sb_eth_raw_ofdata_to_platdata(struct udevice *dev) struct eth_pdata *pdata = dev_get_platdata(dev); struct eth_sandbox_raw_priv *priv = dev_get_priv(dev); const char *ifname; - u32 local; int ret; pdata->iobase = dev_read_addr(dev); @@ -173,10 +172,10 @@ static int sb_eth_raw_ofdata_to_platdata(struct udevice *dev) priv->host_ifindex, priv->host_ifname); } - local = sandbox_eth_raw_os_is_local(priv->host_ifname); - if (local < 0) - return local; - priv->local = local; + ret = sandbox_eth_raw_os_is_local(priv->host_ifname); + if (ret < 0) + return ret; + priv->local = ret; return 0; } -- 2.20.1.97.g81188d93c3-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/7] buildman: Write the environment out to an 'env' file
Sometimes it is useful to see the environment that was used to build U-Boot. Write this out to a file in the build directory. Signed-off-by: Simon Glass --- Changes in v2: None tools/buildman/builderthread.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py index 6b156f152d..8a9d47cd5e 100644 --- a/tools/buildman/builderthread.py +++ b/tools/buildman/builderthread.py @@ -322,6 +322,9 @@ class BuilderThread(threading.Thread): # Write out the image and function size information and an objdump env = result.toolchain.MakeEnvironment(self.builder.full_path) +with open(os.path.join(build_dir, 'env'), 'w') as fd: +for var in sorted(env.keys()): +print >>fd, '%s="%s"' % (var, env[var]) lines = [] for fname in ['u-boot', 'spl/u-boot-spl']: cmd = ['%snm' % self.toolchain.cross, '--size-sort', fname] -- 2.20.1.97.g81188d93c3-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 7/7] buildman: Fix tabs in GetWrapper()
This function has tabs instead of spaces. Fix it.
Signed-off-by: Simon Glass
---
Changes in v2:
- Drop patches previously applied
- Add fixes needed to get clang building running
tools/buildman/toolchain.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index b3c61827f3..a65737fdf8 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -135,8 +135,8 @@ class Toolchain:
def GetWrapper(self, show_warning=True):
"""Get toolchain wrapper from the setting file.
"""
- value = ''
- for name, value in bsettings.GetItems('toolchain-wrapper'):
+value = ''
+for name, value in bsettings.GetItems('toolchain-wrapper'):
if not value:
print "Warning: Wrapper not found"
if value:
--
2.20.1.97.g81188d93c3-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] efi_loader: Add a wchar_t cast in efi_file_open()
The printf() string here is not actually correct. Add a cast to avoid
a warning when checking is enabled.
Signed-off-by: Simon Glass
---
Changes in v2: None
lib/efi_loader/efi_file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 128cb0a627..8a4f3a9f40 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -221,8 +221,8 @@ static efi_status_t EFIAPI efi_file_open(struct
efi_file_handle *file,
struct file_handle *fh = to_fh(file);
efi_status_t ret;
- EFI_ENTRY("%p, %p, \"%ls\", %llx, %llu", file, new_handle, file_name,
- open_mode, attributes);
+ EFI_ENTRY("%p, %p, \"%ls\", %llx, %llu", file, new_handle,
+ (wchar_t *)file_name, open_mode, attributes);
/* Check parameters */
if (!file || !new_handle || !file_name) {
--
2.20.1.97.g81188d93c3-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] log: Check printf() arguments
At present logging does not check printf() arguments. Now that all users have been corrected, enable this to prevent further problems. Signed-off-by: Simon Glass --- Changes in v2: None include/log.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/log.h b/include/log.h index 0f2bc19477..d7f6471006 100644 --- a/include/log.h +++ b/include/log.h @@ -73,7 +73,8 @@ static inline int log_uc_cat(enum uclass_id id) * @return 0 if log record was emitted, -ve on error */ int _log(enum log_category_t cat, enum log_level_t level, const char *file, -int line, const char *func, const char *fmt, ...); +int line, const char *func, const char *fmt, ...) + __attribute__ ((format (__printf__, 6, 7))); /* Define this at the top of a file to add a prefix to debug messages */ #ifndef pr_fmt -- 2.20.1.97.g81188d93c3-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] Fixes for previous -dm pull request
It turns out that the 'clang' support in buildman did not actually work, i.e. it failed to build with clang. This is because the U-Boot Makefile overrides the environment variables supplied by buildman. This series fixes that as well as an EFI loader warning that would be introduced by checking log() arguments. This is sent as a new series on top of dm/master. Changes in v2: - Use the command line instead of environment for make variables - Drop patches previously applied - Add fixes needed to get clang building running Simon Glass (7): efi_loader: Add a wchar_t cast in efi_file_open() log: Check printf() arguments buildman: Add support for building with clang travis: Use buildman for building with clang net: Fix error handling in sb_eth_raw_ofdata_to_platdata() buildman: Write the environment out to an 'env' file buildman: Fix tabs in GetWrapper() .travis.yml | 13 +++--- drivers/net/sandbox-raw.c | 9 --- include/log.h | 3 ++- lib/efi_loader/efi_file.c | 4 ++-- tools/buildman/README | 10 tools/buildman/builderthread.py | 4 tools/buildman/cmdline.py | 2 ++ tools/buildman/control.py | 2 +- tools/buildman/toolchain.py | 42 - 9 files changed, 64 insertions(+), 25 deletions(-) -- 2.20.1.97.g81188d93c3-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform
On 1/7/19 3:59 PM, Tom Rini wrote: On Mon, Jan 07, 2019 at 09:15:17PM +0100, Alexander Graf wrote: On 07.01.19 18:13, Tom Rini wrote: On Mon, Jan 07, 2019 at 05:57:10PM +0100, Alexander Graf wrote: ... So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO: 1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior ... which is one more change to the uboot-test-scripts repo, can someone please? Thanks. Done: https://github.com/swarren/uboot-test-hooks/pull/23 nd this breaks older QEMU. I think for the moment, can you please revert this Stephen? We'll take the QEMU version bump early on in the next release and I'll let you know off-list when I'm grabbing it. Thanks! It's done. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform
On Mon, Jan 07, 2019 at 09:15:17PM +0100, Alexander Graf wrote:
>
>
> On 07.01.19 18:13, Tom Rini wrote:
> > On Mon, Jan 07, 2019 at 05:57:10PM +0100, Alexander Graf wrote:
> >> On 01/07/2019 01:46 PM, Michal Simek wrote:
> >>> On 07. 01. 19 13:28, Tom Rini wrote:
> On Mon, Jan 07, 2019 at 01:18:46PM +0100, Michal Simek wrote:
> > On 04. 01. 19 4:01, Tom Rini wrote:
> >> On Fri, Jan 04, 2019 at 09:29:47AM +0800, Bin Meng wrote:
> >>> On Thu, Jan 3, 2019 at 9:39 PM Tom Rini wrote:
> On Thu, Jan 03, 2019 at 09:00:41AM +0100, Michal Simek wrote:
> > On 26. 12. 18 15:29, Tom Rini wrote:
> >> On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
> >>> Hi Michal,
> >>>
> >>> On Thu, Dec 20, 2018 at 4:17 PM Michal Simek
> >>> wrote:
> On 20. 12. 18 9:09, Bin Meng wrote:
> > On Thu, Dec 20, 2018 at 3:55 PM Michal Simek
> > wrote:
> >> Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
> >>
> >> Signed-off-by: Michal Simek
> >> ---
> >>
> >> Patch needs to be applied when this PR is merged.
> >> https://github.com/swarren/uboot-test-hooks/pull/21
> >>
> >> ---
> >> .travis.yml | 8
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/.travis.yml b/.travis.yml
> >> index 6e4b4ba0a34a..e14e6987e4cf 100644
> >> --- a/.travis.yml
> >> +++ b/.travis.yml
> >> @@ -454,6 +454,14 @@ matrix:
> >>QEMU_TARGET="arm-softmmu"
> >>TEST_PY_ID="--id qemu"
> >>BUILDMAN="^zynq_zc702$"
> >> +- name: "test/py xilinx_versal_virt"
> >> + env:
> >> +- TEST_PY_BD="xilinx_versal_virt"
> >> + TEST_PY_TEST_SPEC="not sleep"
> >> + QEMU_TARGET="aarch64-softmmu"
> >> + QEMU_VERSION="v3.1.0"
> >> + TEST_PY_ID="--id qemu"
> >> + BUILDMAN="^xilinx_versal_virt$"
> > Can we turn on 3.1.0 for all QEMU targets?
> I expected this question.
> First of all I wanted to enable an option to be able to wire
> whatever
> version. Even sha1 for not released version.
>
> I think we can try to test v3.1.0 qemu version for all boards
> but I will
> let Tom to decide is we can move or not.
>
> >>> Yes, please try to test that. If everything is good, I see no
> >>> reason
> >>> not using it.
> >> Yes, I would also like to move everyone up to v3.1.0 and also
> >> having the
> >> version we use be spelled out will help with future
> >> reproducibility.
> >>
> > v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
> > take a look at
> > https://travis-ci.org/michalsimek/u-boot/builds/470873127
> > I am happy to keep them on v3.0 and move the rest to v3.1 and let
> > vexpress guys to figured out what's wrong with v3.1 and configs
> > around.
> >
> > What do you think?
> The error is:
> Captured stdout setup
> -
> +u-boot-test-reset vexpress_ca15_tc2 qemu
> qemu-system-arm: -tftp: invalid option
>
> And I guess the problem is that by v3.1.0 -tftp has been removed and
> we
> need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like
> on
> the other QEMU-based targets. Can you update uboot-test-hooks
> (change
> .travis.yml to clone your fork of uboot-test-hooks rather than
> swarren's) to have the modern syntax? Thanks!
> >>> I think the correct approach is to update uboot-test-hooks and send PR
> >>> to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should
> >>> still have U-Boot's .travis.yml point to swarren's git repo, no?
> >> Yes, sorry, to be clear, I was just saying how to debug / confirm the
> >> changes to uboot-test-hooks.
> > I have created new pull request for fixing that network issue here.
> > https://github.com/swarren/uboot-test-hooks/pull/22
> >
> > But for vexpress_ca15_tc2 there is still an issue with helloworld efi.
> > It works on v3.0 but not on v3.1.
> >
> > => => tftpboot 8000 lib/efi_loader/helloworld.efi
> > smc911x: MAC 52:54:00:12:34:56
> > smc911x: detected LAN9118 controller
> > smc911x: phy initialized
> > smc911x: MAC 52:54:00:12:34:56
> > Using smc911x-0 device
> > TFTP from server 10.0.2.2; our IP address is
Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5
On 1/7/19 10:01 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 21:47 schrieb Marek Vasut:
>> On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 21:25 schrieb Marek Vasut:
On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 21:19 schrieb Marek Vasut:
>> On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
>>> When debug UART is enabled on socfpga_gen5, the debug uart driver
>>> hangs
>>> in an endless loop because 'socfpga_bridges_reset' calls printf
>>> before
>>> the debug UART is initialized.
>>>
>>> After the generic fix for this in the UART driver did not work
>>> due to
>>> portability issues, let's just drop this printf statement when
>>> called
>>> from SPL with debug UART enabled.
>>>
>>> Signed-off-by: Simon Goldschmidt
>>
>> Can we have an un-portable fix which at least works on SoCFPGA ? :)
>
> This one worked on socfpga but broke rockchip:
>
> https://patchwork.ozlabs.org/patch/992553/
>
> However, the message below wasn't shown either with that patch
> applied.
> The code just runs too early to enable the UART.
>
> Do you want to keep the message (although I failed to see in which
> situation it can be printed) or do you just dislike the #ifdef thing?
I'd like to keep the error message if possible. Is it possible ?
>>>
>>> I have *never* seen this message yet. I have failed to produce a
>>> situation where it is shown.
>>
>> I believe that.
>>
>>> This function ('socfpga_bridges_reset') is called 5 times throughout the
>>> code, but only *one* single time with 'reset=0' as argument (only with
>>> 0, the code in question is executed). And this is in SPL before
>>> initializing the console and even before the debug UART can be
>>> initialized.
>>>
>>> As I could see, the printf *is* executed on every boot (I saw the code
>>> hanging when enabling debug UART). However, when not booting from FPGA,
>>> it is just normal that the FPGA is not ready when running SPL. Why do
>>> you want an error message here anyway?
>>
>> I was under the impression this is an error message, but it might not be
>> so ? Maybe the wording is incorrect ?
>
> Now that I re-read it, "aborting" is incorrect, yes.
>
> So how should we proceed? This is an error message that can never be
> shown (like the code is now) but breaks debug UART.
>
> I'd say we can drop it altogether. It might only be interesint if (in
> the future) that code would get called from somewhere else (i.e. later,
> after console initialization).
>
> Re-reading spl_gen5.c, there are some 'debug' calls before the debug
> uart is initialized which probably would need to be removed as well, but
> that's a different story...
How come those don't hang the system then ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata
On 1/7/19 10:14 PM, Simon Goldschmidt wrote: > This is an initial attempt to support OF_PLATDATA for socfpga gen5. > > There are two motivations for this: > a) reduce code size to eventually support secure boot (where SPL has to >authenticate the next stage by loading/checking U-Boot from a FIT >image) > b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM >(on warm-restart), all bytes to check need to be in one piece. With >OF_SEPARATE, this is not the case (.bss is between .rodata and the >DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to >be a good solution. I'd much prefer parsing the DT (and thus, decoupling the SW from HW) than having some ad-hoc plat data again if we can avoid that. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] arm: socfpga: fix compiling with OF_PLATDATA
On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> 'socfpga_eth_reset_common' must not be compiled when OF_PLATDATA is enabled
> since it uses functions accessing the devicetree.
>
> Since this function is not used in SPL anyway, change the compile guard
> to reflect this and fix compiling SPL with OF_PLATDATA.
Doesn't this break ethernet in SPL ? I think it does. The real fix is to
move this PHY mode configuration into the driver.
> Signed-off-by: Simon Goldschmidt
> ---
>
> arch/arm/mach-socfpga/misc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> index 78fbe28724..30f74d9940 100644
> --- a/arch/arm/mach-socfpga/misc.c
> +++ b/arch/arm/mach-socfpga/misc.c
> @@ -120,7 +120,7 @@ int arch_cpu_init(void)
> return 0;
> }
>
> -#ifdef CONFIG_ETH_DESIGNWARE
> +#if defined CONFIG_ETH_DESIGNWARE && !defined CONFIG_SPL_BUILD
> static int dwmac_phymode_to_modereg(const char *phymode, u32 *modereg)
> {
> if (!phymode)
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select
On 1/7/19 10:14 PM, Simon Goldschmidt wrote: > In order to build a smaller SPL, let's imply SPL_DM_RESET and > SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled > via defconfig. > > This also seems to be required to use OF_PLATDATA, as the reset drivers > don't seem to work with it. How do you un-reset IP blocks if you disable the reset controller ? > Signed-off-by: Simon Goldschmidt > --- > > arch/arm/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 520ea8bed9..1ca71bd323 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -815,7 +815,6 @@ config ARCH_SOCFPGA > select DM_SERIAL > select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || > TARGET_SOCFPGA_ARRIA10 > select OF_CONTROL > - select SPL_DM_RESET if DM_RESET > select SPL_DM_SERIAL > select SPL_LIBCOMMON_SUPPORT > select SPL_LIBGENERIC_SUPPORT > @@ -823,7 +822,6 @@ config ARCH_SOCFPGA > select SPL_OF_CONTROL > select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10 > select SPL_SERIAL_SUPPORT > - select SPL_WATCHDOG_SUPPORT > select SUPPORT_SPL > select SYS_NS16550 > select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 > @@ -833,12 +831,14 @@ config ARCH_SOCFPGA > imply DM_SPI > imply DM_SPI_FLASH > imply FAT_WRITE > + imply SPL_DM_RESET > imply SPL_LIBDISK_SUPPORT > imply SPL_MMC_SUPPORT > imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION > imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE > imply SPL_SPI_FLASH_SUPPORT > imply SPL_SPI_SUPPORT > + imply SPL_WATCHDOG_SUPPORT > > config ARCH_SUNXI > bool "Support sunxi (Allwinner) SoCs" > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] serial: add an of-platdata driver for "snps, dw-apb-uart"
Hi Simon,
> Add a driver for the "snps,dw-apb-uart" used in socfpga and others.
>
> This driver is required to get OF_PLATDATA to work for socfpga.
> It uses the ns16550 driver, converting the platdata from of-platdata
> go the ns16550 format.
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> drivers/serial/Kconfig | 10
> drivers/serial/Makefile| 1 +
> drivers/serial/serial_dw_apb.c | 42
> ++ 3 files changed, 53 insertions(+)
> create mode 100644 drivers/serial/serial_dw_apb.c
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index b7ff2960ab..10addd3309 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -511,6 +511,16 @@ config BCM283X_PL011_SERIAL
> that supports automatic disable, so that it only gets used
> when the UART is actually muxed.
>
> +config DESIGNWARE_SERIAL
> + bool "DesignWare UART support"
> + depends on DM_SERIAL && SPL_OF_PLATDATA
> + help
> + Select this to enable a UART driver for "snps,dw-apb-uart"
> devices
> + when using CONFIG_SPL_OF_PLATDATA (i.e. a compiled-in
> device tree
> + replacement).
> + This uses the ns16550 driver, converting the platdata from
> of-platdata
> + to the ns16550 format.
> +
> config BCM6345_SERIAL
> bool "Support for BCM6345 UART"
> depends on DM_SERIAL
> diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
> index 06ee30697d..f1ebb90d92 100644
> --- a/drivers/serial/Makefile
> +++ b/drivers/serial/Makefile
> @@ -46,6 +46,7 @@ obj-$(CONFIG_MESON_SERIAL) += serial_meson.o
> obj-$(CONFIG_INTEL_MID_SERIAL) += serial_intel_mid.o
> ifdef CONFIG_SPL_BUILD
> obj-$(CONFIG_ROCKCHIP_SERIAL) += serial_rockchip.o
> +obj-$(CONFIG_DESIGNWARE_SERIAL) += serial_dw_apb.o
> endif
> obj-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
> obj-$(CONFIG_SANDBOX_SERIAL) += sandbox.o
> diff --git a/drivers/serial/serial_dw_apb.c
> b/drivers/serial/serial_dw_apb.c new file mode 100644
> index 00..26580e5ba5
> --- /dev/null
> +++ b/drivers/serial/serial_dw_apb.c
> @@ -0,0 +1,42 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2018 Simon Goldschmidt
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
> +struct dw_apb_uart_platdata {
> + struct dtd_snps_dw_apb_uart dtplat;
> + struct ns16550_platdata plat;
> +};
> +
> +static int dw_apb_serial_probe(struct udevice *dev)
> +{
> + struct dw_apb_uart_platdata *plat = dev_get_platdata(dev);
> +
> + /* Set up correct platform data for the standard driver */
> + plat->plat.base = plat->dtplat.reg[0];
> + plat->plat.reg_shift = plat->dtplat.reg_shift;
> + plat->plat.reg_width = plat->dtplat.reg_io_width;
> + plat->plat.clock = plat->dtplat.clock_frequency;
> + plat->plat.fcr = UART_FCR_DEFVAL;
> + dev->platdata = >plat;
> +
> + return ns16550_serial_probe(dev);
> +}
> +
> +U_BOOT_DRIVER(snps_dw_apb_uart) = {
> + .name = "snps_dw_apb_uart",
> + .id = UCLASS_SERIAL,
> + .priv_auto_alloc_size = sizeof(struct NS16550),
> + .platdata_auto_alloc_size = sizeof(struct
> dw_apb_uart_platdata),
> + .probe = dw_apb_serial_probe,
> + .ops= _serial_ops,
> + .flags = DM_FLAG_PRE_RELOC,
Is it possible/or is your application requiring the pinmux/clock setting
for this serial?
With OF_PLATDATA we don't need to parse (and provide) the DTS (and we
use the DM/DTS driver's code in a way similar to "native" one).
I'm wondering, if it would be possible to "mimic" the dependencies
between DM drivers without DTS parsing / providing overhead.
At least in my case I would need in SPL:
-> driver XXX (working with u-boot proper's DM/DTS)
---> CLK (uclass-clk) to enable clocks
---> pinctrl (to config pins)
As an example: uart or eMMC.
I'm aware that it would be possible to use the old "approach" to
configure pinmux and clk separately (as it is done now) and only
re-use the DM portion of driver with OF_PLATDATA having all the
necessary info.
However, I'm wondering if there is a better way to achieve it (or if I
misunderstood something).
> +};
> +#endif
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgppVERp0tTP7.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata
Hi Simon, > This is an initial attempt to support OF_PLATDATA for socfpga gen5. > > There are two motivations for this: > a) reduce code size to eventually support secure boot (where SPL has > to authenticate the next stage by loading/checking U-Boot from a FIT >image) > b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM >(on warm-restart), all bytes to check need to be in one piece. With >OF_SEPARATE, this is not the case (.bss is between .rodata and the >DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to >be a good solution. I'm not an expert with SOCFPGA nor your application, but maybe selecting: "SPL_SEPARATE_BSS" would fix your issue? This option allows putting on IMX6 SPL the DTB blob into OCRAM (internal RAM), before the DDR is setup (so it would be possible to calculate CRC). I've stumbled upon such issue when I wanted to switch from OF_EMBEDDED to OF_SEPARATE. > > This series enables booting from MMC with OF_PLATDATA. Booting from > SPI does not yet work (I'm working on that, but it's tougher than > expected). > > Tested on the socrates board. To use it: > - use socfpga_socrates_defconfig > - disable CONFIG_SPL_SPI_FLASH_SUPPORT, CONFIG_SPL_SPI_SUPPORT and > CONFIG_SPL_DM_RESET (those don't work yet) > - enable CONFIG_DESIGNWARE_SERIAL (required for console) > > > Simon Goldschmidt (4): > arm: socfpga: imply SPL config instead of select > arm: socfpga: fix compiling with OF_PLATDATA > serial: add an of-platdata driver for "snps,dw-apb-uart" > mmc: socfpga: support of-platdata > > arch/arm/Kconfig | 4 ++-- > arch/arm/mach-socfpga/misc.c | 2 +- > drivers/mmc/socfpga_dw_mmc.c | 28 --- > drivers/serial/Kconfig | 10 > drivers/serial/Makefile| 1 + > drivers/serial/serial_dw_apb.c | 42 > ++ 6 files changed, 81 insertions(+), > 6 deletions(-) create mode 100644 drivers/serial/serial_dw_apb.c > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgprnGpzcP4oN.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/4] arm: socfpga: fix compiling with OF_PLATDATA
'socfpga_eth_reset_common' must not be compiled when OF_PLATDATA is enabled
since it uses functions accessing the devicetree.
Since this function is not used in SPL anyway, change the compile guard
to reflect this and fix compiling SPL with OF_PLATDATA.
Signed-off-by: Simon Goldschmidt
---
arch/arm/mach-socfpga/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
index 78fbe28724..30f74d9940 100644
--- a/arch/arm/mach-socfpga/misc.c
+++ b/arch/arm/mach-socfpga/misc.c
@@ -120,7 +120,7 @@ int arch_cpu_init(void)
return 0;
}
-#ifdef CONFIG_ETH_DESIGNWARE
+#if defined CONFIG_ETH_DESIGNWARE && !defined CONFIG_SPL_BUILD
static int dwmac_phymode_to_modereg(const char *phymode, u32 *modereg)
{
if (!phymode)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 4/4] mmc: socfpga: support of-platdata
This adds support for OF_PLATDATA to the socfpga_dw_mmc driver.
To do that, also the name of the driver has to be changed to match the
compatible string in the platdata generated from dts.
Signed-off-by: Simon Goldschmidt
---
drivers/mmc/socfpga_dw_mmc.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index 739c1629a2..8503dff932 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,6 +25,9 @@ static const struct socfpga_system_manager
*system_manager_base =
(void *)SOCFPGA_SYSMGR_ADDRESS;
struct socfpga_dwmci_plat {
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+ struct dtd_altr_socfpga_dw_mshc dtplat;
+#endif
struct mmc_config cfg;
struct mmc mmc;
};
@@ -100,6 +104,7 @@ static int socfpga_dwmmc_get_clk_rate(struct udevice *dev)
static int socfpga_dwmmc_ofdata_to_platdata(struct udevice *dev)
{
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
struct dwmci_socfpga_priv_data *priv = dev_get_priv(dev);
struct dwmci_host *host = >host;
int fifo_depth;
@@ -129,13 +134,13 @@ static int socfpga_dwmmc_ofdata_to_platdata(struct
udevice *dev)
priv->smplsel = fdtdec_get_uint(gd->fdt_blob, dev_of_offset(dev),
"smplsel", 0);
host->priv = priv;
-
+#endif
return 0;
}
static int socfpga_dwmmc_probe(struct udevice *dev)
{
-#ifdef CONFIG_BLK
+#if defined(CONFIG_BLK) || CONFIG_IS_ENABLED(OF_PLATDATA)
struct socfpga_dwmci_plat *plat = dev_get_platdata(dev);
#endif
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
@@ -143,6 +148,23 @@ static int socfpga_dwmmc_probe(struct udevice *dev)
struct dwmci_host *host = >host;
int ret;
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+ struct dtd_altr_socfpga_dw_mshc *dtplat = >dtplat;
+
+ host->name = dev->name;
+ host->ioaddr = (void *)dtplat->reg[0];
+ host->buswidth = dtplat->bus_width;
+ host->clksel = socfpga_dwmci_clksel;
+ host->dev_index = 0;
+ host->fifoth_val = MSIZE(0x2) |
+ RX_WMARK(dtplat->fifo_depth / 2 - 1) |
+ TX_WMARK(dtplat->fifo_depth / 2);
+ host->priv = priv;
+ /* TODO: these are optional, of-platdata does not support this. */
+ priv->drvsel = 3;
+ priv->smplsel = 0;
+#endif
+
ret = socfpga_dwmmc_get_clk_rate(dev);
if (ret)
return ret;
@@ -185,7 +207,7 @@ static const struct udevice_id socfpga_dwmmc_ids[] = {
};
U_BOOT_DRIVER(socfpga_dwmmc_drv) = {
- .name = "socfpga_dwmmc",
+ .name = "altr_socfpga_dw_mshc",
.id = UCLASS_MMC,
.of_match = socfpga_dwmmc_ids,
.ofdata_to_platdata = socfpga_dwmmc_ofdata_to_platdata,
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/4] serial: add an of-platdata driver for "snps, dw-apb-uart"
Add a driver for the "snps,dw-apb-uart" used in socfpga and others.
This driver is required to get OF_PLATDATA to work for socfpga.
It uses the ns16550 driver, converting the platdata from of-platdata
go the ns16550 format.
Signed-off-by: Simon Goldschmidt
---
drivers/serial/Kconfig | 10
drivers/serial/Makefile| 1 +
drivers/serial/serial_dw_apb.c | 42 ++
3 files changed, 53 insertions(+)
create mode 100644 drivers/serial/serial_dw_apb.c
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index b7ff2960ab..10addd3309 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -511,6 +511,16 @@ config BCM283X_PL011_SERIAL
that supports automatic disable, so that it only gets used when
the UART is actually muxed.
+config DESIGNWARE_SERIAL
+ bool "DesignWare UART support"
+ depends on DM_SERIAL && SPL_OF_PLATDATA
+ help
+ Select this to enable a UART driver for "snps,dw-apb-uart" devices
+ when using CONFIG_SPL_OF_PLATDATA (i.e. a compiled-in device tree
+ replacement).
+ This uses the ns16550 driver, converting the platdata from of-platdata
+ to the ns16550 format.
+
config BCM6345_SERIAL
bool "Support for BCM6345 UART"
depends on DM_SERIAL
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 06ee30697d..f1ebb90d92 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_MESON_SERIAL) += serial_meson.o
obj-$(CONFIG_INTEL_MID_SERIAL) += serial_intel_mid.o
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_ROCKCHIP_SERIAL) += serial_rockchip.o
+obj-$(CONFIG_DESIGNWARE_SERIAL) += serial_dw_apb.o
endif
obj-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
obj-$(CONFIG_SANDBOX_SERIAL) += sandbox.o
diff --git a/drivers/serial/serial_dw_apb.c b/drivers/serial/serial_dw_apb.c
new file mode 100644
index 00..26580e5ba5
--- /dev/null
+++ b/drivers/serial/serial_dw_apb.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Simon Goldschmidt
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+struct dw_apb_uart_platdata {
+ struct dtd_snps_dw_apb_uart dtplat;
+ struct ns16550_platdata plat;
+};
+
+static int dw_apb_serial_probe(struct udevice *dev)
+{
+ struct dw_apb_uart_platdata *plat = dev_get_platdata(dev);
+
+ /* Set up correct platform data for the standard driver */
+ plat->plat.base = plat->dtplat.reg[0];
+ plat->plat.reg_shift = plat->dtplat.reg_shift;
+ plat->plat.reg_width = plat->dtplat.reg_io_width;
+ plat->plat.clock = plat->dtplat.clock_frequency;
+ plat->plat.fcr = UART_FCR_DEFVAL;
+ dev->platdata = >plat;
+
+ return ns16550_serial_probe(dev);
+}
+
+U_BOOT_DRIVER(snps_dw_apb_uart) = {
+ .name = "snps_dw_apb_uart",
+ .id = UCLASS_SERIAL,
+ .priv_auto_alloc_size = sizeof(struct NS16550),
+ .platdata_auto_alloc_size = sizeof(struct dw_apb_uart_platdata),
+ .probe = dw_apb_serial_probe,
+ .ops= _serial_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
+#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata
This is an initial attempt to support OF_PLATDATA for socfpga gen5. There are two motivations for this: a) reduce code size to eventually support secure boot (where SPL has to authenticate the next stage by loading/checking U-Boot from a FIT image) b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM (on warm-restart), all bytes to check need to be in one piece. With OF_SEPARATE, this is not the case (.bss is between .rodata and the DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to be a good solution. This series enables booting from MMC with OF_PLATDATA. Booting from SPI does not yet work (I'm working on that, but it's tougher than expected). Tested on the socrates board. To use it: - use socfpga_socrates_defconfig - disable CONFIG_SPL_SPI_FLASH_SUPPORT, CONFIG_SPL_SPI_SUPPORT and CONFIG_SPL_DM_RESET (those don't work yet) - enable CONFIG_DESIGNWARE_SERIAL (required for console) Simon Goldschmidt (4): arm: socfpga: imply SPL config instead of select arm: socfpga: fix compiling with OF_PLATDATA serial: add an of-platdata driver for "snps,dw-apb-uart" mmc: socfpga: support of-platdata arch/arm/Kconfig | 4 ++-- arch/arm/mach-socfpga/misc.c | 2 +- drivers/mmc/socfpga_dw_mmc.c | 28 --- drivers/serial/Kconfig | 10 drivers/serial/Makefile| 1 + drivers/serial/serial_dw_apb.c | 42 ++ 6 files changed, 81 insertions(+), 6 deletions(-) create mode 100644 drivers/serial/serial_dw_apb.c -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select
In order to build a smaller SPL, let's imply SPL_DM_RESET and SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled via defconfig. This also seems to be required to use OF_PLATDATA, as the reset drivers don't seem to work with it. Signed-off-by: Simon Goldschmidt --- arch/arm/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 520ea8bed9..1ca71bd323 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -815,7 +815,6 @@ config ARCH_SOCFPGA select DM_SERIAL select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 select OF_CONTROL - select SPL_DM_RESET if DM_RESET select SPL_DM_SERIAL select SPL_LIBCOMMON_SUPPORT select SPL_LIBGENERIC_SUPPORT @@ -823,7 +822,6 @@ config ARCH_SOCFPGA select SPL_OF_CONTROL select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10 select SPL_SERIAL_SUPPORT - select SPL_WATCHDOG_SUPPORT select SUPPORT_SPL select SYS_NS16550 select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 @@ -833,12 +831,14 @@ config ARCH_SOCFPGA imply DM_SPI imply DM_SPI_FLASH imply FAT_WRITE + imply SPL_DM_RESET imply SPL_LIBDISK_SUPPORT imply SPL_MMC_SUPPORT imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE imply SPL_SPI_FLASH_SUPPORT imply SPL_SPI_SUPPORT + imply SPL_WATCHDOG_SUPPORT config ARCH_SUNXI bool "Support sunxi (Allwinner) SoCs" -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] MIPS: cleanup/optimise linker scripts
On Sun, 2019-01-06 at 20:42 +0100, Daniel Schwierzeck wrote: > Cleanup and optimise MIPS linker scripts and align them more with > Linux. > > Switch the CI20 board from the custom SPL linker script to the > generic MIPS SPL linker script. > > For both patches: Tested-by: Ezequiel Garcia Thanks a lot! > Daniel Schwierzeck (2): > MIPS: optimize and fix ELF sections > MIPS: jz47xx: remove custom u-boot-spl.lds > > arch/mips/cpu/u-boot-spl.lds| 100 --- > arch/mips/cpu/u-boot.lds| 104 +--- > arch/mips/mach-jz47xx/jz4780/u-boot-spl.lds | 50 -- > configs/ci20_mmc_defconfig | 1 - > 4 files changed, 136 insertions(+), 119 deletions(-) > delete mode 100644 arch/mips/mach-jz47xx/jz4780/u-boot-spl.lds > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] mmc: jz_mmc: Compile-out write support if disabled
Do not build write support, unless it's enabled.
In the SPL case, this change will typically remove
precious bytes (as write support is most often
not needed in SPL).
This is important on this platform, where the maximum
SPL size is 14 KiB.
With gcc v7.3, this change saves 144 bytes producing:
size spl/u-boot-spl
textdata bss dec hex filename
9240 752 712 1070429d0 spl/u-boot-spl
To make the code easier to compile-out and more
readable, a pair of read_data/write_data helpers are created.
Signed-off-by: Ezequiel Garcia
---
drivers/mmc/jz_mmc.c | 105 +--
1 file changed, 61 insertions(+), 44 deletions(-)
diff --git a/drivers/mmc/jz_mmc.c b/drivers/mmc/jz_mmc.c
index 3132c3e191ac..cb2a7c3eb5e1 100644
--- a/drivers/mmc/jz_mmc.c
+++ b/drivers/mmc/jz_mmc.c
@@ -134,6 +134,60 @@ static int jz_mmc_clock_rate(void)
return 2400;
}
+#if CONFIG_IS_ENABLED(MMC_WRITE)
+static inline void jz_mmc_write_data(struct jz_mmc_priv *priv, struct mmc_data
*data)
+{
+ int sz = DIV_ROUND_UP(data->blocks * data->blocksize, 4);
+ const void *buf = data->src;
+
+ while (sz--) {
+ u32 val = get_unaligned_le32(buf);
+
+ wait_for_bit_le32(priv->regs + MSC_IREG,
+ MSC_IREG_TXFIFO_WR_REQ,
+ true, 1, false);
+ writel(val, priv->regs + MSC_TXFIFO);
+ buf += 4;
+ }
+}
+#else
+static void jz_mmc_write_data(struct jz_mmc_priv *priv, struct mmc_data *data)
+{}
+#endif
+
+static inline int jz_mmc_read_data(struct jz_mmc_priv *priv, struct mmc_data
*data)
+{
+ int sz = data->blocks * data->blocksize;
+ void *buf = data->dest;
+ u32 stat, val;
+
+ do {
+ stat = readl(priv->regs + MSC_STAT);
+
+ if (stat & MSC_STAT_TIME_OUT_READ)
+ return -ETIMEDOUT;
+ if (stat & MSC_STAT_CRC_READ_ERROR)
+ return -EINVAL;
+ if (stat & MSC_STAT_DATA_FIFO_EMPTY) {
+ udelay(10);
+ continue;
+ }
+ do {
+ val = readl(priv->regs + MSC_RXFIFO);
+ if (sz == 1)
+ *(u8 *)buf = (u8)val;
+ else if (sz == 2)
+ put_unaligned_le16(val, buf);
+ else if (sz >= 4)
+ put_unaligned_le32(val, buf);
+ buf += 4;
+ sz -= 4;
+ stat = readl(priv->regs + MSC_STAT);
+ } while (!(stat & MSC_STAT_DATA_FIFO_EMPTY));
+ } while (!(stat & MSC_STAT_DATA_TRAN_DONE));
+ return 0;
+}
+
static int jz_mmc_send_cmd(struct mmc *mmc, struct jz_mmc_priv *priv,
struct mmc_cmd *cmd, struct mmc_data *data)
{
@@ -249,51 +303,14 @@ static int jz_mmc_send_cmd(struct mmc *mmc, struct
jz_mmc_priv *priv,
cmd->response[0] |= readw(priv->regs + MSC_RES) & 0xff;
}
}
-
- if (data && (data->flags & MMC_DATA_WRITE)) {
- /* write the data */
- int sz = DIV_ROUND_UP(data->blocks * data->blocksize, 4);
- const void *buf = data->src;
-
- while (sz--) {
- u32 val = get_unaligned_le32(buf);
-
- wait_for_bit_le32(priv->regs + MSC_IREG,
- MSC_IREG_TXFIFO_WR_REQ,
- true, 1, false);
- writel(val, priv->regs + MSC_TXFIFO);
- buf += 4;
+ if (data) {
+ if (data->flags & MMC_DATA_WRITE)
+ jz_mmc_write_data(priv, data);
+ else if (data->flags & MMC_DATA_READ) {
+ ret = jz_mmc_read_data(priv, data);
+ if (ret)
+ return ret;
}
- } else if (data && (data->flags & MMC_DATA_READ)) {
- /* read the data */
- int sz = data->blocks * data->blocksize;
- void *buf = data->dest;
-
- do {
- stat = readl(priv->regs + MSC_STAT);
-
- if (stat & MSC_STAT_TIME_OUT_READ)
- return -ETIMEDOUT;
- if (stat & MSC_STAT_CRC_READ_ERROR)
- return -EINVAL;
- if (stat & MSC_STAT_DATA_FIFO_EMPTY) {
- udelay(10);
- continue;
- }
- do {
- u32 val = readl(priv->regs + MSC_RXFIFO);
-
- if (sz == 1)
- *(u8 *)buf =
[U-Boot] [PATCH 1/2] mmc: Use proper IS_ENABLED macro to check block support
Use CONFIG_IS_ENABLED(BLK) instead of CONFIG_BLK,
in order to fix the following build issues when
CONFIG_SPL_MMC_WRITE is selected:
drivers/mmc/mmc_write.c:69:7: error: conflicting types for 'mmc_berase'
ulong mmc_berase(struct udevice *dev, lbaint_t start, lbaint_t blkcnt)
^~
In file included from drivers/mmc/mmc_write.c:15:0:
drivers/mmc/mmc_private.h:39:7: note: previous declaration of 'mmc_berase' was
here
ulong mmc_berase(struct blk_desc *block_dev, lbaint_t start, lbaint_t blkcnt);
^~
drivers/mmc/mmc_write.c:187:7: error: conflicting types for 'mmc_bwrite'
ulong mmc_bwrite(struct udevice *dev, lbaint_t start, lbaint_t blkcnt,
^~
In file included from drivers/mmc/mmc_write.c:15:0:
drivers/mmc/mmc_private.h:37:7: note: previous declaration of 'mmc_bwrite' was
here
ulong mmc_bwrite(struct blk_desc *block_dev, lbaint_t start, lbaint_t blkcnt,
^~
Signed-off-by: Ezequiel Garcia
---
drivers/mmc/mmc_write.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
index b8acc33c76d0..c8c83c9188ec 100644
--- a/drivers/mmc/mmc_write.c
+++ b/drivers/mmc/mmc_write.c
@@ -65,13 +65,13 @@ err_out:
return err;
}
-#ifdef CONFIG_BLK
+#if CONFIG_IS_ENABLED(BLK)
ulong mmc_berase(struct udevice *dev, lbaint_t start, lbaint_t blkcnt)
#else
ulong mmc_berase(struct blk_desc *block_dev, lbaint_t start, lbaint_t blkcnt)
#endif
{
-#ifdef CONFIG_BLK
+#if CONFIG_IS_ENABLED(BLK)
struct blk_desc *block_dev = dev_get_uclass_platdata(dev);
#endif
int dev_num = block_dev->devnum;
@@ -183,7 +183,7 @@ static ulong mmc_write_blocks(struct mmc *mmc, lbaint_t
start,
return blkcnt;
}
-#ifdef CONFIG_BLK
+#if CONFIG_IS_ENABLED(BLK)
ulong mmc_bwrite(struct udevice *dev, lbaint_t start, lbaint_t blkcnt,
const void *src)
#else
@@ -191,7 +191,7 @@ ulong mmc_bwrite(struct blk_desc *block_dev, lbaint_t
start, lbaint_t blkcnt,
const void *src)
#endif
{
-#ifdef CONFIG_BLK
+#if CONFIG_IS_ENABLED(BLK)
struct blk_desc *block_dev = dev_get_uclass_platdata(dev);
#endif
int dev_num = block_dev->devnum;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5
Am 07.01.2019 um 21:47 schrieb Marek Vasut:
On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
Am 07.01.2019 um 21:25 schrieb Marek Vasut:
On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
Am 07.01.2019 um 21:19 schrieb Marek Vasut:
On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
When debug UART is enabled on socfpga_gen5, the debug uart driver
hangs
in an endless loop because 'socfpga_bridges_reset' calls printf before
the debug UART is initialized.
After the generic fix for this in the UART driver did not work due to
portability issues, let's just drop this printf statement when called
from SPL with debug UART enabled.
Signed-off-by: Simon Goldschmidt
Can we have an un-portable fix which at least works on SoCFPGA ? :)
This one worked on socfpga but broke rockchip:
https://patchwork.ozlabs.org/patch/992553/
However, the message below wasn't shown either with that patch applied.
The code just runs too early to enable the UART.
Do you want to keep the message (although I failed to see in which
situation it can be printed) or do you just dislike the #ifdef thing?
I'd like to keep the error message if possible. Is it possible ?
I have *never* seen this message yet. I have failed to produce a
situation where it is shown.
I believe that.
This function ('socfpga_bridges_reset') is called 5 times throughout the
code, but only *one* single time with 'reset=0' as argument (only with
0, the code in question is executed). And this is in SPL before
initializing the console and even before the debug UART can be initialized.
As I could see, the printf *is* executed on every boot (I saw the code
hanging when enabling debug UART). However, when not booting from FPGA,
it is just normal that the FPGA is not ready when running SPL. Why do
you want an error message here anyway?
I was under the impression this is an error message, but it might not be
so ? Maybe the wording is incorrect ?
Now that I re-read it, "aborting" is incorrect, yes.
So how should we proceed? This is an error message that can never be
shown (like the code is now) but breaks debug UART.
I'd say we can drop it altogether. It might only be interesint if (in
the future) that code would get called from somewhere else (i.e. later,
after console initialization).
Re-reading spl_gen5.c, there are some 'debug' calls before the debug
uart is initialized which probably would need to be removed as well, but
that's a different story...
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5
On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 21:25 schrieb Marek Vasut:
>> On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 21:19 schrieb Marek Vasut:
On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
> When debug UART is enabled on socfpga_gen5, the debug uart driver
> hangs
> in an endless loop because 'socfpga_bridges_reset' calls printf before
> the debug UART is initialized.
>
> After the generic fix for this in the UART driver did not work due to
> portability issues, let's just drop this printf statement when called
> from SPL with debug UART enabled.
>
> Signed-off-by: Simon Goldschmidt
Can we have an un-portable fix which at least works on SoCFPGA ? :)
>>>
>>> This one worked on socfpga but broke rockchip:
>>>
>>> https://patchwork.ozlabs.org/patch/992553/
>>>
>>> However, the message below wasn't shown either with that patch applied.
>>> The code just runs too early to enable the UART.
>>>
>>> Do you want to keep the message (although I failed to see in which
>>> situation it can be printed) or do you just dislike the #ifdef thing?
>>
>> I'd like to keep the error message if possible. Is it possible ?
>
> I have *never* seen this message yet. I have failed to produce a
> situation where it is shown.
I believe that.
> This function ('socfpga_bridges_reset') is called 5 times throughout the
> code, but only *one* single time with 'reset=0' as argument (only with
> 0, the code in question is executed). And this is in SPL before
> initializing the console and even before the debug UART can be initialized.
>
> As I could see, the printf *is* executed on every boot (I saw the code
> hanging when enabling debug UART). However, when not booting from FPGA,
> it is just normal that the FPGA is not ready when running SPL. Why do
> you want an error message here anyway?
I was under the impression this is an error message, but it might not be
so ? Maybe the wording is incorrect ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] musb-new: Hide spurious warning in interrupt
On 1/7/19 9:37 PM, Viktoriia Taraniuk wrote:
> During dfu command the next unnecessary warning appears:
>
> musb-hdrc: peripheral reset irq lost!
>
> which confuses user (it is not an actual error).
>
> This patch makes the warning to be printed with debug(), so
> that it only appears in debug build.
Why is it not an actual error ? This sounds like hiding real issues here.
> Signed-off-by: Viktoriia Taraniuk
> ---
> drivers/usb/musb-new/musb_gadget_ep0.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/musb-new/musb_gadget_ep0.c
> b/drivers/usb/musb-new/musb_gadget_ep0.c
> index 9835a2e..0e254ac 100644
> --- a/drivers/usb/musb-new/musb_gadget_ep0.c
> +++ b/drivers/usb/musb-new/musb_gadget_ep0.c
> @@ -792,9 +792,8 @@ setup:
> if (unlikely(musb->g.speed == USB_SPEED_UNKNOWN)) {
> u8 power;
>
> - printk(KERN_NOTICE "%s: peripheral reset "
> - "irq lost!\n",
> - musb_driver_name);
> + debug("%s: peripheral reset irq lost!\n",
> + musb_driver_name);
> power = musb_readb(mbase, MUSB_POWER);
> musb->g.speed = (power & MUSB_POWER_HSMODE)
> ? USB_SPEED_HIGH : USB_SPEED_FULL;
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] dm: MIGRATION: Update migration plan for DM_SPI_FLASH
On Sat, 5 Jan 2019 at 10:01, Jagan Teki wrote: > > On Sat, Jan 5, 2019 at 7:27 AM Simon Glass wrote: > > > > Hi Jagan, > > > > On Tue, 1 Jan 2019 at 12:17, Jagan Teki wrote: > > > > > > Migration plan for DM_SPI_FLASH is v2019.07 since it > > > depends on DM_SPI migration. > > > > > > Signed-off-by: Jagan Teki > > > --- > > > Changes for v2: > > > - none > > > > > > Makefile | 10 ++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/Makefile b/Makefile > > > index c4d827f259..3e926d839f 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -964,6 +964,16 @@ ifneq ($(CONFIG_DM_SPI)$(CONFIG_OF_CONTROL),yy) > > > @echo >&2 "See doc/driver-model/MIGRATION.txt for more info." > > > @echo >&2 "" > > > endif > > > +endif > > > +ifeq ($(CONFIG_SPI_FLASH),y) > > > > Again i worry what happens if the board does not actually use SPI flash? > > If SPI_FLASH not used then it will not enter this loop since its ifeq > (not even to check next ifneq). Did you find any config to enter even > if not used, same case for SPI. OK I see. Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] musb-new: Hide spurious warning in interrupt
During dfu command the next unnecessary warning appears:
musb-hdrc: peripheral reset irq lost!
which confuses user (it is not an actual error).
This patch makes the warning to be printed with debug(), so
that it only appears in debug build.
Signed-off-by: Viktoriia Taraniuk
---
drivers/usb/musb-new/musb_gadget_ep0.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb-new/musb_gadget_ep0.c
b/drivers/usb/musb-new/musb_gadget_ep0.c
index 9835a2e..0e254ac 100644
--- a/drivers/usb/musb-new/musb_gadget_ep0.c
+++ b/drivers/usb/musb-new/musb_gadget_ep0.c
@@ -792,9 +792,8 @@ setup:
if (unlikely(musb->g.speed == USB_SPEED_UNKNOWN)) {
u8 power;
- printk(KERN_NOTICE "%s: peripheral reset "
- "irq lost!\n",
- musb_driver_name);
+ debug("%s: peripheral reset irq lost!\n",
+ musb_driver_name);
power = musb_readb(mbase, MUSB_POWER);
musb->g.speed = (power & MUSB_POWER_HSMODE)
? USB_SPEED_HIGH : USB_SPEED_FULL;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5
Am 07.01.2019 um 21:25 schrieb Marek Vasut:
On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
Am 07.01.2019 um 21:19 schrieb Marek Vasut:
On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
When debug UART is enabled on socfpga_gen5, the debug uart driver hangs
in an endless loop because 'socfpga_bridges_reset' calls printf before
the debug UART is initialized.
After the generic fix for this in the UART driver did not work due to
portability issues, let's just drop this printf statement when called
from SPL with debug UART enabled.
Signed-off-by: Simon Goldschmidt
Can we have an un-portable fix which at least works on SoCFPGA ? :)
This one worked on socfpga but broke rockchip:
https://patchwork.ozlabs.org/patch/992553/
However, the message below wasn't shown either with that patch applied.
The code just runs too early to enable the UART.
Do you want to keep the message (although I failed to see in which
situation it can be printed) or do you just dislike the #ifdef thing?
I'd like to keep the error message if possible. Is it possible ?
I have *never* seen this message yet. I have failed to produce a
situation where it is shown.
This function ('socfpga_bridges_reset') is called 5 times throughout the
code, but only *one* single time with 'reset=0' as argument (only with
0, the code in question is executed). And this is in SPL before
initializing the console and even before the debug UART can be initialized.
As I could see, the printf *is* executed on every boot (I saw the code
hanging when enabling debug UART). However, when not booting from FPGA,
it is just normal that the FPGA is not ready when running SPL. Why do
you want an error message here anyway?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: micrel: fix KSZ9031 clock skew for values greater 0ps
Request for inclusion of below patch.
CC Joe Hershberger as listed maintainer for 'drivers/net/'.
Thanks,
Andreas
On Thu, 2018-11-29 at 20:04 +0100, Andreas Pretzsch wrote:
> For KSZ9021, all skew register fields are 4-bit wide.
> For KSZ9031, the clock skew register fields are 5-bit wide.
>
> The common code in ksz90x1_of_config_group calculating the combined
> register value checks if the requested value is above the maximum
> and uses this maximum if so. The calculation of this maximum uses
> the register width, but the check itself does not. It uses a
> hardcoded
> value of 0xf, which is too low in case of the 5-bit clock (0x1f).
> This detail was probably lost during driver unification.
>
> Effect (only for KSZ9031 clock skews): For values greater 900 (==
> 0ps),
> this silently results in 1860 (== +960ps) instead of the requested
> one.
>
> Fix the check by using the bit width instead of hardcoded value(s).
>
> Signed-off-by: Andreas Pretzsch
> ---
> drivers/net/phy/micrel_ksz90x1.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/micrel_ksz90x1.c
> b/drivers/net/phy/micrel_ksz90x1.c
> index 3951535bf1..63e7b0242b 100644
> --- a/drivers/net/phy/micrel_ksz90x1.c
> +++ b/drivers/net/phy/micrel_ksz90x1.c
> @@ -123,8 +123,8 @@ static int ksz90x1_of_config_group(struct
> phy_device *phydev,
> } else {
> changed = 1;/* Value was changed in OF */
> /* Calculate the register value and fix corner
> cases */
> - if (val[i] > ps_to_regval * 0xf) {
> - max = (1 << ofcfg->grp[i].size) - 1;
> + max = (1 << ofcfg->grp[i].size) - 1;
> + if (val[i] > ps_to_regval * max) {
> regval |= max << offset;
> } else {
> regval |= (val[i] / ps_to_regval) <<
> offset;
--
carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas PretzschTel. +49-(0)7307-936088-1
Lange Strasse 28a Fax: +49-(0)7307-936088-9
89250 Senden, Germany email: a...@cn-eng.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5
On 1/7/19 9:24 PM, Simon Goldschmidt wrote: > Am 07.01.2019 um 21:19 schrieb Marek Vasut: >> On 1/7/19 8:36 PM, Simon Goldschmidt wrote: >>> When debug UART is enabled on socfpga_gen5, the debug uart driver hangs >>> in an endless loop because 'socfpga_bridges_reset' calls printf before >>> the debug UART is initialized. >>> >>> After the generic fix for this in the UART driver did not work due to >>> portability issues, let's just drop this printf statement when called >>> from SPL with debug UART enabled. >>> >>> Signed-off-by: Simon Goldschmidt >> >> Can we have an un-portable fix which at least works on SoCFPGA ? :) > > This one worked on socfpga but broke rockchip: > > https://patchwork.ozlabs.org/patch/992553/ > > However, the message below wasn't shown either with that patch applied. > The code just runs too early to enable the UART. > > Do you want to keep the message (although I failed to see in which > situation it can be printed) or do you just dislike the #ifdef thing? I'd like to keep the error message if possible. Is it possible ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5
Am 07.01.2019 um 21:19 schrieb Marek Vasut:
On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
When debug UART is enabled on socfpga_gen5, the debug uart driver hangs
in an endless loop because 'socfpga_bridges_reset' calls printf before
the debug UART is initialized.
After the generic fix for this in the UART driver did not work due to
portability issues, let's just drop this printf statement when called
from SPL with debug UART enabled.
Signed-off-by: Simon Goldschmidt
Can we have an un-portable fix which at least works on SoCFPGA ? :)
This one worked on socfpga but broke rockchip:
https://patchwork.ozlabs.org/patch/992553/
However, the message below wasn't shown either with that patch applied.
The code just runs too early to enable the UART.
Do you want to keep the message (although I failed to see in which
situation it can be printed) or do you just dislike the #ifdef thing?
Regards,
Simon
---
This is about my fourth try to get the debug uart usable on socfpga gen5.
Hope this time I'll make it :-)
It's really annoying to have local diffs only for enabling the debug uart!
arch/arm/mach-socfpga/reset_manager_gen5.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-socfpga/reset_manager_gen5.c
b/arch/arm/mach-socfpga/reset_manager_gen5.c
index 25baef79bc..39d8fbed94 100644
--- a/arch/arm/mach-socfpga/reset_manager_gen5.c
+++ b/arch/arm/mach-socfpga/reset_manager_gen5.c
@@ -90,7 +90,10 @@ void socfpga_bridges_reset(int enable)
if (!fpgamgr_test_fpga_ready()) {
/* FPGA not ready, do nothing. We allow system to boot
* without FPGA ready. So, return 0 instead of error. */
+#if !defined CONFIG_SPL_BUILD || !defined CONFIG_DEBUG_UART
+ /* In SPL, this is called before debug-uart init... */
printf("%s: FPGA not ready, aborting.\n", __func__);
+#endif
return;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] lib: uuid: Do not enable UUID command SPL
The uuid command is only really useful in U-Boot, but it's useless in
SPL. Worse yet, it pulls in various environment manipulation functions
as it call env_set(). Do not compile the command in in SPL.
Signed-off-by: Marek Vasut
Cc: Tom Rini
---
lib/uuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/uuid.c b/lib/uuid.c
index 5d5adf6b2d..fa20ee39fc 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -271,7 +271,7 @@ void gen_rand_uuid_str(char *uuid_str, int str_format)
uuid_bin_to_str(uuid_bin, uuid_str, str_format);
}
-#ifdef CONFIG_CMD_UUID
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_CMD_UUID)
int do_uuid(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
char uuid[UUID_STR_LEN + 1];
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spl: ymodem: Add support for loading gzip compressed uImage
Add support for gunzip-ing gzip-compressed uImages in the SPL Ymodem code.
Loading data over Ymodem can be gruelingly slow, gzip-ing the data can
reduce that aggravating slowness at least slightly (depends on the data,
u-boot.bin compresses to ~1/3 of it's original size on ARM64), hence add
optional support for decompressing gzip-compressed uImages.
Signed-off-by: Marek Vasut
Cc: Tom Rini
---
common/spl/spl_ymodem.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/common/spl/spl_ymodem.c b/common/spl/spl_ymodem.c
index 3b1bd71bda..577fdc69af 100644
--- a/common/spl/spl_ymodem.c
+++ b/common/spl/spl_ymodem.c
@@ -69,12 +69,13 @@ static ulong ymodem_read_fit(struct spl_load_info *load,
ulong offset,
static int spl_ymodem_load_image(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev)
{
- int size = 0;
+ ulong size = 0;
int err;
int res;
int ret;
connection_info_t info;
char buf[BUF_SIZE];
+ struct image_header *ih;
ulong addr = 0;
info.mode = xyzModem_ymodem;
@@ -107,12 +108,18 @@ static int spl_ymodem_load_image(struct spl_image_info
*spl_image,
while ((res = xyzModem_stream_read(buf, BUF_SIZE, )) > 0)
size += res;
} else {
- ret = spl_parse_image_header(spl_image,
-(struct image_header *)buf);
+ ih = (struct image_header *)buf;
+ ret = spl_parse_image_header(spl_image, ih);
if (ret)
return ret;
- addr = spl_image->load_addr;
+#ifdef CONFIG_SPL_GZIP
+ if (ih->ih_comp == IH_COMP_GZIP)
+ addr = CONFIG_SYS_LOAD_ADDR;
+ else
+#endif
+ addr = spl_image->load_addr;
memcpy((void *)addr, buf, res);
+ ih = (struct image_header *)addr;
size += res;
addr += res;
@@ -121,13 +128,25 @@ static int spl_ymodem_load_image(struct spl_image_info
*spl_image,
size += res;
addr += res;
}
+
+#ifdef CONFIG_SPL_GZIP
+ if (ih->ih_comp == IH_COMP_GZIP) {
+ if (gunzip((void *)(spl_image->load_addr + sizeof(*ih)),
+ CONFIG_SYS_BOOTM_LEN,
+ (void *)(CONFIG_SYS_LOAD_ADDR + sizeof(*ih)),
+ )) {
+ puts("Uncompressing error\n");
+ return -EIO;
+ }
+ }
+#endif
}
end_stream:
xyzModem_stream_close();
xyzModem_stream_terminate(false, );
- printf("Loaded %d bytes\n", size);
+ printf("Loaded %lu bytes\n", size);
return 0;
}
SPL_LOAD_IMAGE_METHOD("UART", 0, BOOT_DEVICE_UART, spl_ymodem_load_image);
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/9] arm: dts: imx7: colibri: split dt for raw NAND and eMMC devices
On Mon, 2019-01-07 at 17:33 +0100, Stefan Agner wrote:
> On 07.01.2019 00:18, Marcel Ziswiler wrote:
> > On Sun, 2019-01-06 at 22:00 +0100, Stefan Agner wrote:
> > > From: Stefan Agner
> > >
> > > In preparation of adding CONFIG_DM_MMC support use separate
> > > device
> > > trees for raw NAND and eMMC devices.
> > >
> > > Signed-off-by: Stefan Agner
> > > ---
> > >
> > > arch/arm/dts/imx7-colibri-emmc.dts| 16 +++
> > > arch/arm/dts/imx7-colibri-rawnand.dts | 46
> > > +++
> > > .../{imx7-colibri.dts => imx7-colibri.dtsi} | 39 +--
> > > -
> >
> > I believe renaming that one also needs changes in resp. Makefile
> > otherwise leading to the following:
> >
> > make[3]: *** No rule to make target 'arch/arm/dts/imx7-
> > colibri.dtb',
> > needed by 'dtbs'. Stop.
>
> Good catch, I definitely need to remove imx7-colibri.dtb there.
>
> > Plus you may want to add the eMMC one as well e.g. as follows:
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index dda4e59491..9596b2a64f 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -458,7 +458,8 @@ dtb-$(CONFIG_MX6UL) += \
> >
> > dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb
> >
> > -dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
> > +dtb-$(CONFIG_MX7) += imx7-colibri-emmc.dtb \
> > + imx7-colibri-rawnand.dtb \
> > imx7d-sdb.dtb \
> > imx7d-sdb-qspi.dtb
>
> It seems that removing is actually sufficient. dtc/Makefile along
> with
> CONFIG_OF_EMBED actually builds the device tree specified in the
> config
> file automatically. Should we still add board device trees to
> arch/arm/dts/Makefile?
Ah, that's why. I don't see much of an advantage having them all in
there then.
> @Stefano/ML any preference?
>
>
> > BTW: Remember, I am not too big of a fan of renaming stuff and
> > everywhere else we so far did not call anything -rawnand as of yet.
> > However, in general I agree that this would be more clear and if
> > you do
> > clean-up the rest of the world(TM) in a similar fashion I am OK
> > with
> > it.
> >
>
> I don't _re_name, I just name :-)
Yeah, but I do know how a git rename looks like (;-p). So you are
cheating just a tiny little bit!
> When we had to name the dt's in the
> kernel, we did not knew that there will be an eMMC variant. It's a
> different start condition here.
Sure.
> Also mind that device trees are named differently: Since we use the
> same
> boot loader for i.MX 7S and 7D, I dropped a letter there too...
Yep, fully aware of this and fully agree.
> IMHO,
> renaming the dt in Linux now is too much churn. So I suggest either
> leave as is in Kernel and deviate a bit in U-Boot or drop -rawnand in
> U-Boot, what do you think?
No, I'm fine with it. With the Makefile fixed:
Acked-by: Marcel Ziswiler
> --
> Stefan
>
> > > board/toradex/colibri_imx7/MAINTAINERS| 3 ++
> > > configs/colibri_imx7_defconfig| 2 +-
> > > 5 files changed, 67 insertions(+), 39 deletions(-)
> > > create mode 100644 arch/arm/dts/imx7-colibri-emmc.dts
> > > create mode 100644 arch/arm/dts/imx7-colibri-rawnand.dts
> > > rename arch/arm/dts/{imx7-colibri.dts => imx7-colibri.dtsi}
> > > (65%)
> > >
> > > diff --git a/arch/arm/dts/imx7-colibri-emmc.dts
> > > b/arch/arm/dts/imx7-
> > > colibri-emmc.dts
> > > new file mode 100644
> > > index 00..295ca05916
> > > --- /dev/null
> > > +++ b/arch/arm/dts/imx7-colibri-emmc.dts
> > > @@ -0,0 +1,16 @@
> > > +// SPDX-License-Identifier: GPL-2.0+ OR X11
> >
> > Don't we rather want GPL-2.0 OR MIT?
> >
> > > +/*
> > > + * Copyright 2019 Toradex AG
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "imx7-colibri.dtsi"
> > > +
> > > +/ {
> > > + model = "Toradex Colibri iMX7D 1GB (eMMC)";
> > > + compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
> > > +
> > > + chosen {
> > > + stdout-path =
> > > + };
> > > +};
> >
> > I guess the meat-on-the-bone will follow (;-p).
> >
> > > diff --git a/arch/arm/dts/imx7-colibri-rawnand.dts
> > > b/arch/arm/dts/imx7-colibri-rawnand.dts
> > > new file mode 100644
> > > index 00..4eb86fb011
> > > --- /dev/null
> > > +++ b/arch/arm/dts/imx7-colibri-rawnand.dts
> > > @@ -0,0 +1,46 @@
> > > +// SPDX-License-Identifier: GPL-2.0+ OR X11
> >
> > Dito.
> >
> > > +/*
> > > + * Copyright 2019 Toradex AG
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "imx7-colibri.dtsi"
> > > +
> > > +/ {
> > > + model = "Toradex Colibri iMX7S/D";
> > > + compatible = "toradex,imx7-colibri", "fsl,imx7";
> > > +
> > > + chosen {
> > > + stdout-path =
> > > + };
> > > +};
> > > +
> > > + {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_gpmi_nand>;
> > > + ,use-minimum-ecc;
> > > + nand-on-flash-bbt;
> > > + -ecc-mode = "hw";
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + pinctrl_gpmi_nand: gpmi-nand-grp {
> > > + fsl,pins = <
> > > + MX7D_PAD_SD3_CLK__NAND_CLE
Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5
On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
> When debug UART is enabled on socfpga_gen5, the debug uart driver hangs
> in an endless loop because 'socfpga_bridges_reset' calls printf before
> the debug UART is initialized.
>
> After the generic fix for this in the UART driver did not work due to
> portability issues, let's just drop this printf statement when called
> from SPL with debug UART enabled.
>
> Signed-off-by: Simon Goldschmidt
Can we have an un-portable fix which at least works on SoCFPGA ? :)
> ---
>
> This is about my fourth try to get the debug uart usable on socfpga gen5.
> Hope this time I'll make it :-)
> It's really annoying to have local diffs only for enabling the debug uart!
>
> arch/arm/mach-socfpga/reset_manager_gen5.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-socfpga/reset_manager_gen5.c
> b/arch/arm/mach-socfpga/reset_manager_gen5.c
> index 25baef79bc..39d8fbed94 100644
> --- a/arch/arm/mach-socfpga/reset_manager_gen5.c
> +++ b/arch/arm/mach-socfpga/reset_manager_gen5.c
> @@ -90,7 +90,10 @@ void socfpga_bridges_reset(int enable)
> if (!fpgamgr_test_fpga_ready()) {
> /* FPGA not ready, do nothing. We allow system to boot
>* without FPGA ready. So, return 0 instead of error. */
> +#if !defined CONFIG_SPL_BUILD || !defined CONFIG_DEBUG_UART
> + /* In SPL, this is called before debug-uart init... */
> printf("%s: FPGA not ready, aborting.\n", __func__);
> +#endif
> return;
> }
>
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform
On 07.01.19 18:13, Tom Rini wrote:
> On Mon, Jan 07, 2019 at 05:57:10PM +0100, Alexander Graf wrote:
>> On 01/07/2019 01:46 PM, Michal Simek wrote:
>>> On 07. 01. 19 13:28, Tom Rini wrote:
On Mon, Jan 07, 2019 at 01:18:46PM +0100, Michal Simek wrote:
> On 04. 01. 19 4:01, Tom Rini wrote:
>> On Fri, Jan 04, 2019 at 09:29:47AM +0800, Bin Meng wrote:
>>> On Thu, Jan 3, 2019 at 9:39 PM Tom Rini wrote:
On Thu, Jan 03, 2019 at 09:00:41AM +0100, Michal Simek wrote:
> On 26. 12. 18 15:29, Tom Rini wrote:
>> On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
>>> Hi Michal,
>>>
>>> On Thu, Dec 20, 2018 at 4:17 PM Michal Simek
>>> wrote:
On 20. 12. 18 9:09, Bin Meng wrote:
> On Thu, Dec 20, 2018 at 3:55 PM Michal Simek
> wrote:
>> Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
>>
>> Signed-off-by: Michal Simek
>> ---
>>
>> Patch needs to be applied when this PR is merged.
>> https://github.com/swarren/uboot-test-hooks/pull/21
>>
>> ---
>> .travis.yml | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index 6e4b4ba0a34a..e14e6987e4cf 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -454,6 +454,14 @@ matrix:
>>QEMU_TARGET="arm-softmmu"
>>TEST_PY_ID="--id qemu"
>>BUILDMAN="^zynq_zc702$"
>> +- name: "test/py xilinx_versal_virt"
>> + env:
>> +- TEST_PY_BD="xilinx_versal_virt"
>> + TEST_PY_TEST_SPEC="not sleep"
>> + QEMU_TARGET="aarch64-softmmu"
>> + QEMU_VERSION="v3.1.0"
>> + TEST_PY_ID="--id qemu"
>> + BUILDMAN="^xilinx_versal_virt$"
> Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire
whatever
version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but
I will
let Tom to decide is we can move or not.
>>> Yes, please try to test that. If everything is good, I see no reason
>>> not using it.
>> Yes, I would also like to move everyone up to v3.1.0 and also having
>> the
>> version we use be spelled out will help with future reproducibility.
>>
> v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
> take a look at
> https://travis-ci.org/michalsimek/u-boot/builds/470873127
> I am happy to keep them on v3.0 and move the rest to v3.1 and let
> vexpress guys to figured out what's wrong with v3.1 and configs
> around.
>
> What do you think?
The error is:
Captured stdout setup
-
+u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we
need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on
the other QEMU-based targets. Can you update uboot-test-hooks (change
.travis.yml to clone your fork of uboot-test-hooks rather than
swarren's) to have the modern syntax? Thanks!
>>> I think the correct approach is to update uboot-test-hooks and send PR
>>> to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should
>>> still have U-Boot's .travis.yml point to swarren's git repo, no?
>> Yes, sorry, to be clear, I was just saying how to debug / confirm the
>> changes to uboot-test-hooks.
> I have created new pull request for fixing that network issue here.
> https://github.com/swarren/uboot-test-hooks/pull/22
>
> But for vexpress_ca15_tc2 there is still an issue with helloworld efi.
> It works on v3.0 but not on v3.1.
>
> => => tftpboot 8000 lib/efi_loader/helloworld.efi
> smc911x: MAC 52:54:00:12:34:56
> smc911x: detected LAN9118 controller
> smc911x: phy initialized
> smc911x: MAC 52:54:00:12:34:56
> Using smc911x-0 device
> TFTP from server 10.0.2.2; our IP address is 10.0.2.15
> Filename 'lib/efi_loader/helloworld.efi'.
> Load address: 0x8000
> Loading: #
>2 MiB/s
> done
> Bytes transferred = 2144 (860 hex)
> smc911x: MAC 52:54:00:12:34:56
> => => crc32 8000 $filesize
> CRC32 for 8000 ... 885f ==> b76d87c0
> => => bootefi 8000
>
Re: [U-Boot] [PATCH v2 6/7] MSCC: Add board support for Jaguar2 SOC family
Am 07.01.19 um 14:02 schrieb Horatiu Vultur: > Add board support and configuration for Jaguar2 SOC family. > The detection of the board type in this family is based on the phy ids. > > Signed-off-by: Horatiu Vultur > --- > arch/mips/dts/Makefile | 1 + > arch/mips/mach-mscc/Makefile | 5 +- > board/mscc/common/Makefile | 4 ++ > board/mscc/common/spi.c | 31 > board/mscc/jr2/Kconfig | 15 ++ > board/mscc/jr2/Makefile | 4 ++ > board/mscc/jr2/jr2.c | 117 > +++ > board/mscc/ocelot/ocelot.c | 22 > configs/mscc_jr2_defconfig | 59 ++ > 9 files changed, 234 insertions(+), 24 deletions(-) > create mode 100644 board/mscc/common/Makefile > create mode 100644 board/mscc/common/spi.c > create mode 100644 board/mscc/jr2/Kconfig > create mode 100644 board/mscc/jr2/Makefile > create mode 100644 board/mscc/jr2/jr2.c > create mode 100644 configs/mscc_jr2_defconfig > Reviewed-by: Daniel Schwierzeck -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] MSCC: Add support for Jaguar2 SOC family
Am 07.01.19 um 14:02 schrieb Horatiu Vultur: > As the Ocelot and Luton SoCs, this family of SoCs are found > in Microsemi Switches solution. > > Signed-off-by: Horatiu Vultur > --- > arch/mips/mach-mscc/Kconfig| 9 + > arch/mips/mach-mscc/cpu.c | 7 + > arch/mips/mach-mscc/dram.c | 2 +- > arch/mips/mach-mscc/include/mach/common.h | 5 + > arch/mips/mach-mscc/include/mach/ddr.h | 38 ++- > arch/mips/mach-mscc/include/mach/jr2/jr2.h | 24 ++ > .../mach-mscc/include/mach/jr2/jr2_devcpu_gcb.h| 20 ++ > .../include/mach/jr2/jr2_devcpu_gcb_miim_regs.h| 25 ++ > .../mips/mach-mscc/include/mach/jr2/jr2_icpu_cfg.h | 321 > + > 9 files changed, 443 insertions(+), 8 deletions(-) > create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2.h > create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2_devcpu_gcb.h > create mode 100644 > arch/mips/mach-mscc/include/mach/jr2/jr2_devcpu_gcb_miim_regs.h > create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2_icpu_cfg.h > Reviewed-by: Daniel Schwierzeck -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] MSCC: Add sysreset driver for Jaguar2 SOC family
Am 07.01.19 um 14:02 schrieb Horatiu Vultur:
> Create sysreset driver for Jaguar2 SOC family and update defconfig
> to use it.
>
> Signed-off-by: Horatiu Vultur
> ---
> MAINTAINERS | 1 +
> board/mscc/jr2/jr2.c| 8 +++
> configs/mscc_jr2_defconfig | 2 ++
> drivers/sysreset/Kconfig| 6 ++
> drivers/sysreset/Makefile | 1 +
> drivers/sysreset/sysreset_jr2.c | 46
> +
> 6 files changed, 64 insertions(+)
> create mode 100644 drivers/sysreset/sysreset_jr2.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d42736b..8b8cc9d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -526,6 +526,7 @@ F:arch/mips/dts/serval*
> F: board/mscc/
> F: configs/mscc*
> F: drivers/gpio/mscc_sgpio.c
> +F: drivers/sysreset/sysreset_jr2.c
> F: include/configs/vcoreiii.h
> F: drivers/pinctrl/mscc/
>
> diff --git a/board/mscc/jr2/jr2.c b/board/mscc/jr2/jr2.c
> index 36f9896..2935ad0 100644
> --- a/board/mscc/jr2/jr2.c
> +++ b/board/mscc/jr2/jr2.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -17,6 +18,8 @@ enum {
>
> int board_early_init_r(void)
> {
> + int ret;
> +
> /* Prepare SPI controller to be used in master mode */
> writel(0, BASE_CFG + ICPU_SW_MODE);
> clrsetbits_le32(BASE_CFG + ICPU_GENERAL_CTRL,
> @@ -30,6 +33,11 @@ int board_early_init_r(void)
> if (IS_ENABLED(CONFIG_LED))
> led_default_state();
>
> + ret = device_bind_driver(gd->dm_root, "jr2_soft_reset",
> + "reset_soft", NULL);
> + if (ret)
> + printf("Warning: No reset driver: ret=%d\n", ret);
> +
that shouldn't be necessary if you put a device node to device tree.
Actually my intention in last review was that you create a driver which
fits all MSCC SoCs and control the differences via the device tree
compatible string. This way you could entirely get rid of the legacy
_machine_restart() hook in the MSCC platform. But you don't have to do
this in this series.
> return 0;
> }
>
> diff --git a/configs/mscc_jr2_defconfig b/configs/mscc_jr2_defconfig
> index b215754..e80dde6 100644
> --- a/configs/mscc_jr2_defconfig
> +++ b/configs/mscc_jr2_defconfig
> @@ -57,3 +57,5 @@ CONFIG_SPI=y
> CONFIG_DM_SPI=y
> CONFIG_LZMA=y
> CONFIG_XZ=y
> +CONFIG_SYSRESET=y
> +CONFIG_SYSRESET_JR2=y
> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> index 8ce3e2e..7c6db0f 100644
> --- a/drivers/sysreset/Kconfig
> +++ b/drivers/sysreset/Kconfig
> @@ -43,6 +43,12 @@ config SYSRESET_TI_SCI
> This enables the system reset driver support over TI System Control
> Interface available on some new TI's SoCs.
>
> +config SYSRESET_JR2
> + bool "Enable support for Jaguar2 soft reset"
> + depends on SOC_JR2
> + help
> + This is soft reset on Jaguar2.
> +
> endif
>
> config SYSRESET_SYSCON
> diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
> index b3728ac..24c488b 100644
> --- a/drivers/sysreset/Makefile
> +++ b/drivers/sysreset/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
> obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
> obj-$(CONFIG_SYSRESET_X86) += sysreset_x86.o
> obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
> +obj-$(CONFIG_SYSRESET_JR2) += sysreset_jr2.o
> diff --git a/drivers/sysreset/sysreset_jr2.c b/drivers/sysreset/sysreset_jr2.c
> new file mode 100644
> index 000..76a5bac
> --- /dev/null
> +++ b/drivers/sysreset/sysreset_jr2.c
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Microsemi SoCs pinctrl driver
> + *
> + * Author:
> + * License: Dual MIT/GPL
redundant due to SPDX identifier
> + * Copyright (c) 2018 Microsemi Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int jr2_sysreset_request(struct udevice *dev,
> + enum sysreset_t type)
> +{
> + register u32 reg = readl(BASE_CFG + ICPU_GENERAL_CTRL);
register is not required in this context
> + /* Set owner */
> + reg &= ~ICPU_GENERAL_CTRL_IF_SI_OWNER_M;
> + reg |= ICPU_GENERAL_CTRL_IF_SI_OWNER(1);
> + /* Set boot mode */
> + reg |= ICPU_GENERAL_CTRL_BOOT_MODE_ENA;
> + writel(reg, BASE_CFG + ICPU_GENERAL_CTRL);
> + /* Read back in order to make BOOT mode setting active */
> + reg = readl(BASE_CFG + ICPU_GENERAL_CTRL);
> + /* Reset CPU only - still executing _here_. but from cache */
> + writel(readl(BASE_CFG + ICPU_RESET) |
> +ICPU_RESET_CORE_RST_CPU_ONLY |
> +ICPU_RESET_CORE_RST_FORCE,
> +BASE_CFG + ICPU_RESET);
> +
> + return -EINPROGRESS;
> +}
> +
> +static struct sysreset_ops jr2_sysreset = {
> + .request = jr2_sysreset_request,
> +};
> +
> +U_BOOT_DRIVER(sysreset_jr2) = {
> + .id =
Re: [U-Boot] [PATCH v2 1/7] pinctrl: mscc: Add gpio and pinctrl for Jaguar2 SOC family
Am 07.01.19 um 14:02 schrieb Horatiu Vultur:
> The Jaguar2 SOC family has 63 gpio pins therefore I extended mscc-common
> to support new numbe of pins.
>
> Signed-off-by: Horatiu Vultur
> ---
> MAINTAINERS| 1 +
> drivers/pinctrl/mscc/Kconfig | 9 +
> drivers/pinctrl/mscc/Makefile | 1 +
> drivers/pinctrl/mscc/mscc-common.c | 97 ---
> drivers/pinctrl/mscc/mscc-common.h | 5 +
> drivers/pinctrl/mscc/pinctrl-jr2.c | 342
> +
> 6 files changed, 433 insertions(+), 22 deletions(-)
> create mode 100644 drivers/pinctrl/mscc/pinctrl-jr2.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 494962e..495d3e5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -525,6 +525,7 @@ F:board/mscc/
> F: configs/mscc*
> F: drivers/gpio/mscc_sgpio.c
> F: include/configs/vcoreiii.h
> +F: drivers/pinctrl/mscc/
>
> MIPS JZ4780
> M: Ezequiel Garcia
> diff --git a/drivers/pinctrl/mscc/Kconfig b/drivers/pinctrl/mscc/Kconfig
> index cfc6c06..d07ea1b 100644
> --- a/drivers/pinctrl/mscc/Kconfig
> +++ b/drivers/pinctrl/mscc/Kconfig
> @@ -20,3 +20,12 @@ config PINCTRL_MSCC_LUTON
> help
> Support pin multiplexing and pin configuration control on
> Microsemi luton SoCs.
> +
> +config PINCTRL_MSCC_JR2
> + depends on SOC_JR2 && PINCTRL_FULL && OF_CONTROL
> + select PINCTRL_MSCC
> + default y
> + bool "Microsemi jr2 family pin control driver"
> + help
> + Support pin multiplexing and pin configuration control on
> + Microsemi jr2 SoCs.
> diff --git a/drivers/pinctrl/mscc/Makefile b/drivers/pinctrl/mscc/Makefile
> index 6910671..8038d54 100644
> --- a/drivers/pinctrl/mscc/Makefile
> +++ b/drivers/pinctrl/mscc/Makefile
> @@ -3,3 +3,4 @@
> obj-y += mscc-common.o
> obj-$(CONFIG_PINCTRL_MSCC_OCELOT) += pinctrl-ocelot.o
> obj-$(CONFIG_PINCTRL_MSCC_LUTON) += pinctrl-luton.o
> +obj-$(CONFIG_PINCTRL_MSCC_JR2) += pinctrl-jr2.o
> diff --git a/drivers/pinctrl/mscc/mscc-common.c
> b/drivers/pinctrl/mscc/mscc-common.c
> index d74b8a6..7743565 100644
> --- a/drivers/pinctrl/mscc/mscc-common.c
> +++ b/drivers/pinctrl/mscc/mscc-common.c
> @@ -22,6 +22,18 @@
> #include
> #include "mscc-common.h"
>
> +#if defined(CONFIG_SOC_JR2)
> +#define MSCC_GPIO_OUT_SET0x00
> +#define MSCC_GPIO_OUT_CLR0x08
> +#define MSCC_GPIO_OUT0x10
> +#define MSCC_GPIO_IN 0x18
> +#define MSCC_GPIO_OE 0x20
> +#define MSCC_GPIO_INTR 0x28
> +#define MSCC_GPIO_INTR_ENA 0x30
> +#define MSCC_GPIO_INTR_IDENT 0x38
> +#define MSCC_GPIO_ALT0 0x40
> +#define MSCC_GPIO_ALT1 0x48
> +#else
you should also move this to pinctrl-jr2.c
> #define MSCC_GPIO_OUT_SET0x0
> #define MSCC_GPIO_OUT_CLR0x4
> #define MSCC_GPIO_OUT0x8
> @@ -32,6 +44,39 @@
> #define MSCC_GPIO_INTR_IDENT 0x1c
> #define MSCC_GPIO_ALT0 0x20
> #define MSCC_GPIO_ALT1 0x24
> +#endif
> +
> +static void mscc_writel(unsigned int offset, void *addr)
> +{
> + if (offset < 32)
> + writel(BIT(offset), addr);
> + else
> + writel(BIT(offset % 32), addr + 4);
> +}
> +
> +static unsigned int mscc_readl(unsigned int offset, void *addr)
> +{
> + if (offset < 32)
> + return readl(addr);
> + else
> + return readl(addr + 4);
> +}
> +
> +void mscc_setbits(unsigned int offset, void *addr)
> +{
> + if (offset < 32)
> + writel(readl(addr) | BIT(offset), addr);
> + else
> + writel(readl(addr + 4) | BIT(offset % 32), addr + 4);
> +}
> +
> +void mscc_clrbits(unsigned int offset, void *addr)
> +{
> + if (offset < 32)
> + writel(readl(addr) & ~BIT(offset), addr);
> + else
> + writel(readl(addr + 4) & ~BIT(offset % 32), addr + 4);
> +}
>
> static int mscc_get_functions_count(struct udevice *dev)
> {
> @@ -48,8 +93,8 @@ static const char *mscc_get_function_name(struct udevice
> *dev,
> return info->function_names[function];
> }
>
> -static int mscc_pin_function_idx(unsigned int pin, unsigned int function,
> - const struct mscc_pin_data *mscc_pins)
> +int mscc_pin_function_idx(unsigned int pin, unsigned int function,
> + const struct mscc_pin_data *mscc_pins)
> {
> struct mscc_pin_caps *p = mscc_pins[pin].drv_data;
> int i;
> @@ -62,7 +107,7 @@ static int mscc_pin_function_idx(unsigned int pin,
> unsigned int function,
> return -1;
> }
>
> -static int mscc_pinmux_set_mux(struct udevice *dev,
> +__weak int mscc_pinmux_set_mux(struct udevice *dev,
> unsigned int pin_selector, unsigned int selector)
> {
> struct mscc_pinctrl *info = dev_get_priv(dev);
> @@ -79,15 +124,16 @@ static int mscc_pinmux_set_mux(struct udevice *dev,
>* This is racy because both registers can't be updated at the
[U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5
When debug UART is enabled on socfpga_gen5, the debug uart driver hangs
in an endless loop because 'socfpga_bridges_reset' calls printf before
the debug UART is initialized.
After the generic fix for this in the UART driver did not work due to
portability issues, let's just drop this printf statement when called
from SPL with debug UART enabled.
Signed-off-by: Simon Goldschmidt
---
This is about my fourth try to get the debug uart usable on socfpga gen5.
Hope this time I'll make it :-)
It's really annoying to have local diffs only for enabling the debug uart!
arch/arm/mach-socfpga/reset_manager_gen5.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-socfpga/reset_manager_gen5.c
b/arch/arm/mach-socfpga/reset_manager_gen5.c
index 25baef79bc..39d8fbed94 100644
--- a/arch/arm/mach-socfpga/reset_manager_gen5.c
+++ b/arch/arm/mach-socfpga/reset_manager_gen5.c
@@ -90,7 +90,10 @@ void socfpga_bridges_reset(int enable)
if (!fpgamgr_test_fpga_ready()) {
/* FPGA not ready, do nothing. We allow system to boot
* without FPGA ready. So, return 0 instead of error. */
+#if !defined CONFIG_SPL_BUILD || !defined CONFIG_DEBUG_UART
+ /* In SPL, this is called before debug-uart init... */
printf("%s: FPGA not ready, aborting.\n", __func__);
+#endif
return;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] dtoc: make generated platdata structs const
The platdata initialization structs are currently generated into .rwdata.
Make sure the are put into .rodata by generating them as const.
Signed-off-by: Simon Goldschmidt
---
tools/dtoc/dtb_platdata.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index 6cb1259446..ca580b45d4 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -461,7 +461,7 @@ class DtbPlatdata(object):
"""
struct_name, _ = get_compat_name(node)
var_name = conv_name_to_c(node.name)
-self.buf('static struct %s%s %s%s = {\n' %
+self.buf('static const struct %s%s %s%s = {\n' %
(STRUCT_PREFIX, struct_name, VAL_PREFIX, var_name))
for pname, prop in node.props.items():
if pname in PROP_IGNORE_LIST or pname[0] == '#':
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: soft_spi: Fix null ptr when probing soft_spi.
The 01/07/2019 18:09, Daniel Schwierzeck wrote:
>
>
> Am 07.01.19 um 09:20 schrieb Horatiu Vultur:
> > When probing soft_spi the result of dev_get_parent_priv(dev) in probe
> > function is null ptr because the spi is on the ahb bus which has
> > per_child_auto_alloc_size set to 0. Therefore it would generate an Ooops
> > messages when accessing spi_slave structure.
> >
> > The fix consist of updating the soft_spi_platdata flags inside the
> > .set_mode.
> >
> > Signed-off-by: Horatiu Vultur
> > ---
> > drivers/spi/soft_spi.c | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
>
> is this patch still required with https://patchwork.ozlabs.org/cover/1021335/
> ?
This patch is not required if you will take in
https://patchwork.ozlabs.org/cover/1021335.
>
> >
> > diff --git a/drivers/spi/soft_spi.c b/drivers/spi/soft_spi.c
> > index b06883f..2c47577 100644
> > --- a/drivers/spi/soft_spi.c
> > +++ b/drivers/spi/soft_spi.c
> > @@ -183,9 +183,15 @@ static int soft_spi_set_speed(struct udevice *dev,
> > unsigned int speed)
> > static int soft_spi_set_mode(struct udevice *dev, unsigned int mode)
> > {
> > struct soft_spi_priv *priv = dev_get_priv(dev);
> > + struct soft_spi_platdata *plat = dev->platdata;
> >
> > priv->mode = mode;
> >
> > + if (!(mode & SPI_CS_HIGH))
> > + plat->cs.flags |= GPIOD_ACTIVE_LOW;
> > + if (mode & SPI_CPOL)
> > + plat->sclk.flags |= GPIOD_ACTIVE_LOW;
> > +
>
> don't you need to manually set the initial state of CS and CLK now? This was
> previously done by
> gpio_request_by_name(). That's why the driver needed to know the low-active
> bits early.
No, because it is still using gpio_request_by_name() and that one will
set the initial values for CS and CLK. And now in the .set_mode() we
just update the CS and CLK, which is called before probing the spi.
>
> > return 0;
> > }
> >
> > @@ -210,18 +216,13 @@ static int soft_spi_ofdata_to_platdata(struct udevice
> > *dev)
> >
> > static int soft_spi_probe(struct udevice *dev)
> > {
> > - struct spi_slave *slave = dev_get_parent_priv(dev);
> > struct soft_spi_platdata *plat = dev->platdata;
> > - int cs_flags, clk_flags;
> > int ret;
> >
> > - cs_flags = (slave->mode & SPI_CS_HIGH) ? 0 : GPIOD_ACTIVE_LOW;
> > - clk_flags = (slave->mode & SPI_CPOL) ? GPIOD_ACTIVE_LOW : 0;
> > -
> > if (gpio_request_by_name(dev, "cs-gpios", 0, >cs,
> > -GPIOD_IS_OUT | cs_flags) ||
> > +GPIOD_IS_OUT) ||
> > gpio_request_by_name(dev, "gpio-sck", 0, >sclk,
> > -GPIOD_IS_OUT | clk_flags))
> > +GPIOD_IS_OUT))
> > return -EINVAL;
> >
> > ret = gpio_request_by_name(dev, "gpio-mosi", 0, >mosi,
> >
>
> --
> - Daniel
--
/Horatiu
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] of-platdata: improve documentation
Improve some things in the documentation of OF_PLATDATA that I found while porting socfgpa_gen5 to it. Signed-off-by: Simon Goldschmidt --- doc/driver-model/of-plat.txt | 18 -- dts/Kconfig | 6 ++ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/doc/driver-model/of-plat.txt b/doc/driver-model/of-plat.txt index 732bc34f06..ecb5f1724b 100644 --- a/doc/driver-model/of-plat.txt +++ b/doc/driver-model/of-plat.txt @@ -69,12 +69,12 @@ How it works The feature is enabled by CONFIG SPL_OF_PLATDATA. This is only available -in SPL and should be tested with: +in SPL/TPL and should be tested with: #if CONFIG_IS_ENABLED(SPL_OF_PLATDATA) A new tool called 'dtoc' converts a device tree file either into a set of -struct declarations, one for each compatible node, or a set of +struct declarations, one for each compatible node, and a set of U_BOOT_DEVICE() declarations along with the actual platform data for each device. As an example, consider this MMC node: @@ -156,6 +156,12 @@ This avoids the code overhead of converting the device tree data to platform data in the driver. The ofdata_to_platdata() method should therefore do nothing in such a driver. +Note that for the platform data to be matched with a driver, the 'name' +property of the U_BOOT_DEVICE() declaration has to match a driver declared +via U_BOOT_DRIVER(). This effectively means that a U_BOOT_DRIVER() with a +'name' identical to the devicetree 'compatible' string is needed, so a +dedicated driver is required for each 'compatible' string. + Where a node has multiple compatible strings, a #define is used to make them equivalent, e.g.: @@ -165,8 +171,8 @@ equivalent, e.g.: Converting of-platdata to a useful form --- -Of course it would be possible use the of-platdata directly in your driver -whenever configuration information is required. However this meands that the +Of course it would be possible to use the of-platdata directly in your driver +whenever configuration information is required. However this means that the driver will not be able to support device tree, since the of-platdata structure is not available when device tree is used. It would make no sense to use this structure if device tree were available, since the structure has @@ -282,8 +288,8 @@ prevents them being used inadvertently. All usage must be bracketed with The dt-platdata.c file contains the device declarations and is is built in spl/dt-platdata.c. -Some phandles (thsoe that are recognised as such) are converted into -points to platform data. This pointer can potentially be used to access the +Some phandles (those that are recognised as such) are converted into +pointer to platform data. This pointer can potentially be used to access the referenced device (by searching for the pointer value). This feature is not yet implemented, however. diff --git a/dts/Kconfig b/dts/Kconfig index 8917f42444..3e85914d11 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -265,8 +265,7 @@ config SPL_OF_PLATDATA This option works by generating C structure declarations for each compatible string, then adding platform data and U_BOOT_DEVICE - declarations for each node. See README.platdata for more - information. + declarations for each node. See of-plat.txt for more information. config TPL_OF_PLATDATA bool "Generate platform data for use in TPL" @@ -287,8 +286,7 @@ config TPL_OF_PLATDATA This option works by generating C structure declarations for each compatible string, then adding platform data and U_BOOT_DEVICE - declarations for each node. See README.platdata for more - information. + declarations for each node. See of-plat.txt for more information. endmenu -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols
On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote:
> On 01/07/19 15:09, Leif Lindholm wrote:
> > Apologies for late reply, back from holidays today.
>
> I'm going to snip a whole lot of context below, since I have no idea
> what project this is about, and/or what files in that project (no diff
> hunk headers in the context). Judged from the address list, is this
> about u-boot perhaps? And adding type definitions to u-boot so they
> conform to the UEFI spec, and (assuming this "and" is possible) match
> edk2 practice?
Well, the u-boot UEFI interface is what triggered the questions.
And the answer is relevant to the people asking, so I kept the list on
cc.
But I'm more concerned with regards to whether EDK2 is compliant, and
what impacts this has on the spec if not.
> > My understanding is this:
> > - The EDK2 implementation does not conform to the specification; it
> > completely packs the EFI_HII_KEYBOARD_LAYOUT, which the
> > specification does not mention anything about. Since this code is
> > well in the wild, and drivers tested against the current layout need
> > to continuw eorking, I expect the only possible solution is to
> > update the specification to say EFI_HII_KEYBOARD_LAYOUT must be
> > packed.
>
> I'm going to take a pass on this. :)
Be my guest :)
> > - The default EDK2 definition of GUID (and hence EFI_GUID) gives it a
> > 32-bit alignment requirement also on 64-bit architectures. In
> > practice, I expect this would only affect (some of the) GUIDs that
> > are members of structs used in UEFI interfaces. But that may already
> > be too common an occurrence to audit and address in EDK2. Does the
> > spec need to change on this also?
>
> The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit aligned,
> unless specified otherwise. See in "Table 5. Common UEFI Data Types":
>
> EFI_GUID -- 128-bit buffer containing a unique identifier value.
> Unless otherwise specified, aligned on a 64-bit
> boundary.
Indeed.
> Whether edk2 satisfies that, and if so, how (by chance / by general
> build flags), I don't know. The code says,
>
> ///
> /// 128 bit buffer containing a unique identifier value.
> /// Unless otherwise specified, aligned on a 64 bit boundary.
> ///
> typedef struct {
> UINT32 Data1;
> UINT16 Data2;
> UINT16 Data3;
> UINT8 Data4[8];
> } GUID;
>
> I think there may have been an expectation in "MdePkg/Include/Base.h"
> that the supported compilers would automatically ensure the specified
> alignment, given the structure definition.
But that would be expecting things not only not guaranteed by C, but
something there is no semantic information suggesting would be useful
for the compiler to do above. C is quite explicit that the above would
be given a 32-bit alignment requirement. The most aligned member is
Data1, and its alignment is 32 bits.
Now, technically, it would be absolutely fine for this struct to be
32-but aligned, if the EFI_GUID typedef in
MdePkg/Include/Uefi/UefiBaseType.h added this constraint. It does not.
/
Leif
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bogus message about SCSI during build
On Mon, Jan 07, 2019 at 08:38:35PM +0200, Andy Shevchenko wrote: > On Mon, Jan 7, 2019 at 8:34 PM Andy Shevchenko > wrote: > > On Wed, Dec 26, 2018 at 6:38 PM Tom Rini wrote: > > > On Thu, Dec 13, 2018 at 12:52:21PM +0800, Bin Meng wrote: > > > > On Wed, Dec 12, 2018 at 12:21 AM Andy Shevchenko > > > > wrote: > > > > > > Since X86 implies SCSI and Intel Edison board does not use it, I have > > > > > got a > > > > > = WARNING == > > > > > This board does not use CONFIG_DM_SCSI. Please update > > > > > the storage controller to use CONFIG_DM_SCSI before the v2019.07 > > > > > release. > > > > > Failure to update by the deadline may result in board removal. > > > > > See doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > > > > Is anybody aware of? > > > > > > > > AFAIK , this warning message is intentional to push board maintainers > > > > to convert their boards over to driver model. > > > > > > > > For the edison board, if SCSI is not used. you can turn it off in the > > > > board defconfig file. > > > > > > Right. Our warnings now are perhaps a bit too easy to trip over because > > > there are cases like this where you don't need SCSI (or other things) > > > but have them on without having DM_xxx and BLK enabled. In this case > > > the right thing to do is disable stuff you don't need. > > > > What stuff? > > The platform does have DM_MMC and BLK as far as I can see, other than > > that I have no idea how CONFIG_DM_SCSI becomes set. > > Something broken upper, not on this certain board. > > config X86 > ... > imply DM_SCSI > ... > > This has to be fixed, not my board. Message now is bogus. Ah, I see now, thanks for being patient with me. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [V3] please pull u-boot-samsung master
On Mon, Jan 07, 2019 at 09:42:27AM +0900, Minkyu Kang wrote: > Hi, > > The following changes since commit 1f2e948d6d53f77a2ddb2dde3531b0d5bc2815ad: > > Prepare v2019.01-rc2 (2018-12-17 20:25:24 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-samsung master > > for you to fetch changes up to df1ff4d6ba591a5fcb9549e895b23c781d8fda6d: > > exynos: Leave the compiler to choose the register to avoid possible r0 > corruption (2019-01-04 17:28:50 +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] Please pull u-boot-rockchip
On Sun, Jan 06, 2019 at 03:29:51PM +0100, Philipp Tomsich wrote: > The following changes since commit 53240275666acf32cb9811e44eaf2fd571a6cb75: > > Merge tag 'for-v2019.01' of git://git.denx.de/u-boot-video (2019-01-03 > 15:34:44 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-rockchip.git tags/for-master-20190106 > > for you to fetch changes up to 33502f371d49161a66f7c1f3752dbfc1358129c0: > > rockchip: rk3399: fix missing braces in full pinctrl (2019-01-06 15:26:31 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bogus message about SCSI during build
On Mon, Jan 7, 2019 at 8:34 PM Andy Shevchenko wrote: > On Wed, Dec 26, 2018 at 6:38 PM Tom Rini wrote: > > On Thu, Dec 13, 2018 at 12:52:21PM +0800, Bin Meng wrote: > > > On Wed, Dec 12, 2018 at 12:21 AM Andy Shevchenko > > > wrote: > > > > Since X86 implies SCSI and Intel Edison board does not use it, I have > > > > got a > > > > = WARNING == > > > > This board does not use CONFIG_DM_SCSI. Please update > > > > the storage controller to use CONFIG_DM_SCSI before the v2019.07 > > > > release. > > > > Failure to update by the deadline may result in board removal. > > > > See doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > Is anybody aware of? > > > > > > AFAIK , this warning message is intentional to push board maintainers > > > to convert their boards over to driver model. > > > > > > For the edison board, if SCSI is not used. you can turn it off in the > > > board defconfig file. > > > > Right. Our warnings now are perhaps a bit too easy to trip over because > > there are cases like this where you don't need SCSI (or other things) > > but have them on without having DM_xxx and BLK enabled. In this case > > the right thing to do is disable stuff you don't need. > > What stuff? > The platform does have DM_MMC and BLK as far as I can see, other than > that I have no idea how CONFIG_DM_SCSI becomes set. > Something broken upper, not on this certain board. config X86 ... imply DM_SCSI ... This has to be fixed, not my board. Message now is bogus. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bogus message about SCSI during build
On Wed, Dec 26, 2018 at 6:38 PM Tom Rini wrote: > > On Thu, Dec 13, 2018 at 12:52:21PM +0800, Bin Meng wrote: > > Hi Andy, > > > > On Wed, Dec 12, 2018 at 12:21 AM Andy Shevchenko > > wrote: > > > > > > Hi! > > > > > > Since X86 implies SCSI and Intel Edison board does not use it, I have got > > > a > > > = WARNING == > > > This board does not use CONFIG_DM_SCSI. Please update > > > the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. > > > Failure to update by the deadline may result in board removal. > > > See doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > Is anybody aware of? > > > > AFAIK , this warning message is intentional to push board maintainers > > to convert their boards over to driver model. > > > > For the edison board, if SCSI is not used. you can turn it off in the > > board defconfig file. > > Right. Our warnings now are perhaps a bit too easy to trip over because > there are cases like this where you don't need SCSI (or other things) > but have them on without having DM_xxx and BLK enabled. In this case > the right thing to do is disable stuff you don't need. What stuff? The platform does have DM_MMC and BLK as far as I can see, other than that I have no idea how CONFIG_DM_SCSI becomes set. Something broken upper, not on this certain board. > > -- > Tom -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols
On 01/07/19 15:09, Leif Lindholm wrote:
> Apologies for late reply, back from holidays today.
>
I'm going to snip a whole lot of context below, since I have no idea
what project this is about, and/or what files in that project (no diff
hunk headers in the context). Judged from the address list, is this
about u-boot perhaps? And adding type definitions to u-boot so they
conform to the UEFI spec, and (assuming this "and" is possible) match
edk2 practice?
> My understanding is this:
> - The EDK2 implementation does not conform to the specification; it
> completely packs the EFI_HII_KEYBOARD_LAYOUT, which the
> specification does not mention anything about. Since this code is
> well in the wild, and drivers tested against the current layout need
> to continuw eorking, I expect the only possible solution is to
> update the specification to say EFI_HII_KEYBOARD_LAYOUT must be
> packed.
I'm going to take a pass on this. :)
> - The default EDK2 definition of GUID (and hence EFI_GUID) gives it a
> 32-bit alignment requirement also on 64-bit architectures. In
> practice, I expect this would only affect (some of the) GUIDs that
> are members of structs used in UEFI interfaces. But that may already
> be too common an occurrence to audit and address in EDK2. Does the
> spec need to change on this also?
The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit aligned,
unless specified otherwise. See in "Table 5. Common UEFI Data Types":
EFI_GUID -- 128-bit buffer containing a unique identifier value.
Unless otherwise specified, aligned on a 64-bit boundary.
Whether edk2 satisfies that, and if so, how (by chance / by general
build flags), I don't know. The code says,
///
/// 128 bit buffer containing a unique identifier value.
/// Unless otherwise specified, aligned on a 64 bit boundary.
///
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} GUID;
I think there may have been an expectation in "MdePkg/Include/Base.h"
that the supported compilers would automatically ensure the specified
alignment, given the structure definition.
Thanks
Laszlo
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 15/26] clk: sunxi: Add ccu clock tree support
On Mon, Jan 07, 2019 at 02:09:12PM +, Andre Przywara wrote: > > > What is MISC, exactly? Seems like an artefact clock to me, some > > > placeholder you need because gate clocks are handled separately in > > > the gates struct. Should this be called something with SIMPLE > > > instead, or GATE? > > > > + * @CCU_CLK_TYPE_FIXED:fixed clock type > > > > + * @CCU_CLK_TYPE_MP: mp clock type > > > > + * @CCU_CLK_TYPE_NK: nk clock type > > > > > > What is the point of those comments, as you are basically repeating > > > the enum name? What about: > > > * @CCU_CLK_TYPE_PLL: PLL clock with two multiplier > > > fields > > > > We have PLL with 2 multipliers, but also others with other factors > > sets, so that will end up being confusing. If the MP, NK and so on > > stuff is confusing, maybe we should just add a comment on top of that > > structure to explain what those factors are and what it actually > > means? > > Fair enough, or we name it CCU_CLK_TYPE_PLL_NK, because this is what > this type deals with. Point is that by chance I happened to know about > those naming of factors in the manual, but other might be lost by just > seeing "mp" or "nk", without any explanation - and the comment doesn't > help here at all. Either way, we should really document this properly. > The other part is that the "TYPE_MP" is twice as confusing, as it can > perfectly describe the MMC clocks, which use "N" and "M" in the A64 > manual, for instance. That's why my suggestion for calling a spade a > spade and saying it's a divider clock with a multiplexer. Happy to have > the Linux naming in the comments. NM and MP aren't really the same though. NM is one multiplier and one divider, while MP is one divider and one right shift. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: add spi flash bootcmd
On 7.1.2019 15.54, Andre Przywara wrote:
> On Mon, 7 Jan 2019 14:16:23 +0100
> Maxime Ripard wrote:
>
>> On Sat, Jan 05, 2019 at 08:03:46PM +0200, Oskari Lemmela wrote:
>>> Enable SPI bootcmd if CONFIG_DM_SPI_FLASH is defined.
>>>
>>> Signed-off-by: Oskari Lemmela
>>> ---
>>> include/configs/sunxi-common.h | 16
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/include/configs/sunxi-common.h
>>> b/include/configs/sunxi-common.h index 9819d9980c..b2443ef678 100644
>>> --- a/include/configs/sunxi-common.h
>>> +++ b/include/configs/sunxi-common.h
>>> @@ -401,6 +401,21 @@ extern int soft_i2c_gpio_scl;
>>> #define BOOT_TARGET_DEVICES_USB(func)
>>> #endif
>>>
>>> +#ifdef CONFIG_DM_SPI_FLASH
>>> +#define BOOT_TARGET_DEVICES_SPI(func) func(SPI, spi, 0)
>>> +#define BOOTENV_DEV_SPI(devtypeu, devtypel, instance) \
>> This belongs more in include/config_distro_bootcmd.h, there's nothing
>> really sunxi specific here.
True. I'll try to rework it that way.
>>> + "image_addr=0x10\0" \
>>> + "image_size=0x70\0" \
>> image_addr and image_size usually come from Kconfig, instead of being
>> hardcoded
> Actually this whole approach looks very specific to me, if I understand
> this correctly, it loads 7 MB from 1MB of the SPI flash and treats this
> as a kernel?
> This looks very arbitrary to me, requires at least 8MB of SPI flash
> (many boards come with just 2MB) and will never hold any normal arm64
> kernel (which are in the range of 16MB, typically).
> So this might fit some specific embedded project, but doesn't look like
> something we want in the default environment. If there is a use case
> for it, people can always either set up their specific environment (and
> store it in FAT), or change the default environment just for their
> build.
>
> Cheers,
> Andre.
Making image_addr and image_size configurable via Kconfig would allow
this be
generic approach.
Goal is not load kernel image directly as it would be too big for most
of SPI
flash devices. Approach is load FIT image some where else and then let
u-boot
uncompress and boot it.
Most likely 2MB flash device is not enough even when lzma compressing
kernel.
>>> + "bootcmd_" #devtypel #instance "=" \
>>> + "if sf probe " #instance "; then " \
>>> + "sf read ${ramdisk_addr_r} ${image_addr}
>>> ${image_size}; " \
>> s/ramdisk_addr_r/kernel_addr_r/
Reason explained earlier boot process would be loading FIT image to
ramdisk_addr_r. Then u-boot will decompress kernel, dtb and ramdisk to
memory
and boot kernel.
Or could it be better not to use ramdisk_addr_r and replace it with some
other configurable memory address?
Example boot log:
=> sf probe 0
SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total
16 MiB
=> sf read ${ramdisk_addr_r} ${image_addr} ${image_size}
device 0 offset 0x10, size 0x70
SF: 7340032 bytes @ 0x10 Read: OK
=> bootm ${ramdisk_addr_r}
## Loading kernel from FIT Image at 4fe0 ...
Using 'config@1' configuration
Trying 'kernel@1' kernel subimage
Description: ARM64 Linux-4.19.13
Type: Kernel Image
Compression: lzma compressed
Data Start: 0x4fe000e8
Data Size: 2812412 Bytes = 2.7 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x4008
Entry Point: 0x4008
Hash algo: crc32
Hash value: 27f9179d
Hash algo: sha1
Hash value: f5e9b16f6958cca20013f06074ad85141ccd3cc6
Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 4fe0 ...
Using 'config@1' configuration
Trying 'fdt@1' fdt subimage
Description: ARM64 sun50i-a64-pine64-lts device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x500aec2c
Data Size: 13158 Bytes = 12.8 KiB
Architecture: AArch64
Hash algo: crc32
Hash value: 3d2574b7
Hash algo: sha1
Hash value: c55ea000ca7925a505a5de69425b49d8092ceb5e
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x500aec2c
EHCI failed to shut down host controller.
EHCI failed to shut down host controller.
Uncompressing Kernel Image ... OK
Loading Device Tree to 49ff9000, end 49fff365 ... OK
Starting kernel ...
[ 0.00] Booting Linux on physical CPU 0x0
>>
>> Thanks!
>> Maxime
>>
Thanks!
Oskari
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] mips: spi: mscc: Add fast bitbang SPI driver
Am 07.01.19 um 14:28 schrieb Lars Povlsen:
> This patch add a new SPI driver for MSCC SOCs that does not sport the
> designware SPI hardware controller.
>
> Performance gain: 7.664 seconds vs. 17.633 for 1 Mbyte write.
>
> Signed-off-by: Lars Povlsen
> ---
> MAINTAINERS | 1 +
> arch/mips/mach-mscc/include/mach/common.h | 38
> drivers/spi/Kconfig | 7 +
> drivers/spi/Makefile | 1 +
> drivers/spi/mscc_bb_spi.c | 253 ++
> 5 files changed, 300 insertions(+)
> create mode 100644 drivers/spi/mscc_bb_spi.c
>
Reviewed-by: Daniel Schwierzeck
nits below
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 494962e9b3..0cee99ef56 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -524,6 +524,7 @@ F:arch/mips/dts/ocelot*
> F: board/mscc/
> F: configs/mscc*
> F: drivers/gpio/mscc_sgpio.c
> +F: drivers/spi/mscc_bb_spi.c
> F: include/configs/vcoreiii.h
>
> MIPS JZ4780
> diff --git a/arch/mips/mach-mscc/include/mach/common.h
> b/arch/mips/mach-mscc/include/mach/common.h
> index d18ae78bfd..7765c060ed 100644
> --- a/arch/mips/mach-mscc/include/mach/common.h
> +++ b/arch/mips/mach-mscc/include/mach/common.h
> @@ -29,6 +29,44 @@
>
> /* Common utility functions */
>
> +/*
> + * Perform a number of NOP instructions, blocks of 8 instructions.
> + * The (inlined) function will not affect cache or processor state.
> + */
> +static inline void mscc_vcoreiii_nop_delay(int delay)
> +{
> + while (delay > 0) {
> +#define DELAY_8_NOPS() asm volatile("nop; nop; nop; nop; nop; nop; nop;
> nop;")
> + switch (delay) {
> + case 8:
> + DELAY_8_NOPS();
> + /* fallthrough */
> + case 7:
> + DELAY_8_NOPS();
> + /* fallthrough */
> + case 6:
> + DELAY_8_NOPS();
> + /* fallthrough */
> + case 5:
> + DELAY_8_NOPS();
> + /* fallthrough */
> + case 4:
> + DELAY_8_NOPS();
> + /* fallthrough */
> + case 3:
> + DELAY_8_NOPS();
> + /* fallthrough */
> + case 2:
> + DELAY_8_NOPS();
> + /* fallthrough */
> + case 1:
> + DELAY_8_NOPS();
> + }
> + delay -= 8;
> +#undef DELAY_8_NOPS
> + }
> +}
> +
> int mscc_phy_rd_wr(u8 read,
> u32 miim_controller,
> u8 miim_addr,
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index a7bb5b35c2..de4d62dd8f 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -294,6 +294,13 @@ config SOFT_SPI
>Enable Soft SPI driver. This driver is to use GPIO simulate
>the SPI protocol.
>
> +config MSCC_BB_SPI
> + bool "MSCC bitbang SPI driver"
> + depends on SOC_VCOREIII
> + help
> + Enable MSCC bitbang SPI driver. This driver can be used on
> + MSCC SOCs.
> +
> config CF_SPI
> bool "ColdFire SPI driver"
> help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 392a925795..4acec3ea17 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
> obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
> obj-$(CONFIG_MTK_QSPI) += mtk_qspi.o
> obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
> +obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o
> obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
> obj-$(CONFIG_MXC_SPI) += mxc_spi.o
> obj-$(CONFIG_MXS_SPI) += mxs_spi.o
> diff --git a/drivers/spi/mscc_bb_spi.c b/drivers/spi/mscc_bb_spi.c
> new file mode 100644
> index 00..5685878597
> --- /dev/null
> +++ b/drivers/spi/mscc_bb_spi.c
> @@ -0,0 +1,253 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Microsemi SoCs spi driver
> + *
> + * Copyright (c) 2018 Microsemi Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct mscc_bb_platdata {
> + void __iomem *regs;
> + u32 deactivate_delay_us;
> +};
you could drop this along with mscc_bb_spi_ofdata_to_platdata() if you
don't need to support a non-device-tree config or a SPL with DM and
platdata only (I guess neither is true for MSCC platform). Otherwise you
can init mscc_bb_priv from device-tree in your probe function.
> +
> +struct mscc_bb_priv {
> + void __iomem *regs;
> + bool cs_active; /* State flag as to whether CS is asserted */
> + int cs_num;
> + u32 svalue; /* Value to start transfer with */
> + u32 clk1; /* Clock value start */
> + u32 clk2; /* Clock value 2nd phase */
> +};
> +
> +/* Delay 24 instructions
Re: [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform
On Mon, Jan 07, 2019 at 05:57:10PM +0100, Alexander Graf wrote:
> On 01/07/2019 01:46 PM, Michal Simek wrote:
> >On 07. 01. 19 13:28, Tom Rini wrote:
> >>On Mon, Jan 07, 2019 at 01:18:46PM +0100, Michal Simek wrote:
> >>>On 04. 01. 19 4:01, Tom Rini wrote:
> On Fri, Jan 04, 2019 at 09:29:47AM +0800, Bin Meng wrote:
> >On Thu, Jan 3, 2019 at 9:39 PM Tom Rini wrote:
> >>On Thu, Jan 03, 2019 at 09:00:41AM +0100, Michal Simek wrote:
> >>>On 26. 12. 18 15:29, Tom Rini wrote:
> On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
> >Hi Michal,
> >
> >On Thu, Dec 20, 2018 at 4:17 PM Michal Simek
> > wrote:
> >>On 20. 12. 18 9:09, Bin Meng wrote:
> >>>On Thu, Dec 20, 2018 at 3:55 PM Michal Simek
> >>> wrote:
> Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
>
> Signed-off-by: Michal Simek
> ---
>
> Patch needs to be applied when this PR is merged.
> https://github.com/swarren/uboot-test-hooks/pull/21
>
> ---
> .travis.yml | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/.travis.yml b/.travis.yml
> index 6e4b4ba0a34a..e14e6987e4cf 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -454,6 +454,14 @@ matrix:
> QEMU_TARGET="arm-softmmu"
> TEST_PY_ID="--id qemu"
> BUILDMAN="^zynq_zc702$"
> +- name: "test/py xilinx_versal_virt"
> + env:
> +- TEST_PY_BD="xilinx_versal_virt"
> + TEST_PY_TEST_SPEC="not sleep"
> + QEMU_TARGET="aarch64-softmmu"
> + QEMU_VERSION="v3.1.0"
> + TEST_PY_ID="--id qemu"
> + BUILDMAN="^xilinx_versal_virt$"
> >>>Can we turn on 3.1.0 for all QEMU targets?
> >>I expected this question.
> >>First of all I wanted to enable an option to be able to wire
> >>whatever
> >>version. Even sha1 for not released version.
> >>
> >>I think we can try to test v3.1.0 qemu version for all boards but I
> >>will
> >>let Tom to decide is we can move or not.
> >>
> >Yes, please try to test that. If everything is good, I see no reason
> >not using it.
> Yes, I would also like to move everyone up to v3.1.0 and also having
> the
> version we use be spelled out will help with future reproducibility.
>
> >>>v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
> >>>take a look at
> >>>https://travis-ci.org/michalsimek/u-boot/builds/470873127
> >>>I am happy to keep them on v3.0 and move the rest to v3.1 and let
> >>>vexpress guys to figured out what's wrong with v3.1 and configs around.
> >>>
> >>>What do you think?
> >>The error is:
> >> Captured stdout setup
> >>-
> >>+u-boot-test-reset vexpress_ca15_tc2 qemu
> >>qemu-system-arm: -tftp: invalid option
> >>
> >>And I guess the problem is that by v3.1.0 -tftp has been removed and we
> >>need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on
> >>the other QEMU-based targets. Can you update uboot-test-hooks (change
> >>.travis.yml to clone your fork of uboot-test-hooks rather than
> >>swarren's) to have the modern syntax? Thanks!
> >I think the correct approach is to update uboot-test-hooks and send PR
> >to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should
> >still have U-Boot's .travis.yml point to swarren's git repo, no?
> Yes, sorry, to be clear, I was just saying how to debug / confirm the
> changes to uboot-test-hooks.
> >>>I have created new pull request for fixing that network issue here.
> >>>https://github.com/swarren/uboot-test-hooks/pull/22
> >>>
> >>>But for vexpress_ca15_tc2 there is still an issue with helloworld efi.
> >>>It works on v3.0 but not on v3.1.
> >>>
> >>>=> => tftpboot 8000 lib/efi_loader/helloworld.efi
> >>>smc911x: MAC 52:54:00:12:34:56
> >>>smc911x: detected LAN9118 controller
> >>>smc911x: phy initialized
> >>>smc911x: MAC 52:54:00:12:34:56
> >>>Using smc911x-0 device
> >>>TFTP from server 10.0.2.2; our IP address is 10.0.2.15
> >>>Filename 'lib/efi_loader/helloworld.efi'.
> >>>Load address: 0x8000
> >>>Loading: #
> >>>2 MiB/s
> >>>done
> >>>Bytes transferred = 2144 (860 hex)
> >>>smc911x: MAC 52:54:00:12:34:56
> >>>=> => crc32 8000 $filesize
> >>>CRC32 for 8000 ... 885f ==> b76d87c0
> >>>=> => bootefi 8000
> >>>Scanning disks on mmc...
> >>>^[[61;213RCard did not respond to voltage select!
> >>>MMC Device 1 not found
> >>>MMC Device 2 not found
>
Re: [U-Boot] [PATCH v2] spi: soft_spi: Fix null ptr when probing soft_spi.
Am 07.01.19 um 09:20 schrieb Horatiu Vultur:
> When probing soft_spi the result of dev_get_parent_priv(dev) in probe
> function is null ptr because the spi is on the ahb bus which has
> per_child_auto_alloc_size set to 0. Therefore it would generate an Ooops
> messages when accessing spi_slave structure.
>
> The fix consist of updating the soft_spi_platdata flags inside the
> .set_mode.
>
> Signed-off-by: Horatiu Vultur
> ---
> drivers/spi/soft_spi.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
is this patch still required with https://patchwork.ozlabs.org/cover/1021335/ ?
>
> diff --git a/drivers/spi/soft_spi.c b/drivers/spi/soft_spi.c
> index b06883f..2c47577 100644
> --- a/drivers/spi/soft_spi.c
> +++ b/drivers/spi/soft_spi.c
> @@ -183,9 +183,15 @@ static int soft_spi_set_speed(struct udevice *dev,
> unsigned int speed)
> static int soft_spi_set_mode(struct udevice *dev, unsigned int mode)
> {
> struct soft_spi_priv *priv = dev_get_priv(dev);
> + struct soft_spi_platdata *plat = dev->platdata;
>
> priv->mode = mode;
>
> + if (!(mode & SPI_CS_HIGH))
> + plat->cs.flags |= GPIOD_ACTIVE_LOW;
> + if (mode & SPI_CPOL)
> + plat->sclk.flags |= GPIOD_ACTIVE_LOW;
> +
don't you need to manually set the initial state of CS and CLK now? This was
previously done by
gpio_request_by_name(). That's why the driver needed to know the low-active
bits early.
> return 0;
> }
>
> @@ -210,18 +216,13 @@ static int soft_spi_ofdata_to_platdata(struct udevice
> *dev)
>
> static int soft_spi_probe(struct udevice *dev)
> {
> - struct spi_slave *slave = dev_get_parent_priv(dev);
> struct soft_spi_platdata *plat = dev->platdata;
> - int cs_flags, clk_flags;
> int ret;
>
> - cs_flags = (slave->mode & SPI_CS_HIGH) ? 0 : GPIOD_ACTIVE_LOW;
> - clk_flags = (slave->mode & SPI_CPOL) ? GPIOD_ACTIVE_LOW : 0;
> -
> if (gpio_request_by_name(dev, "cs-gpios", 0, >cs,
> - GPIOD_IS_OUT | cs_flags) ||
> + GPIOD_IS_OUT) ||
> gpio_request_by_name(dev, "gpio-sck", 0, >sclk,
> - GPIOD_IS_OUT | clk_flags))
> + GPIOD_IS_OUT))
> return -EINVAL;
>
> ret = gpio_request_by_name(dev, "gpio-mosi", 0, >mosi,
>
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform
On 01/07/2019 01:46 PM, Michal Simek wrote:
On 07. 01. 19 13:28, Tom Rini wrote:
On Mon, Jan 07, 2019 at 01:18:46PM +0100, Michal Simek wrote:
On 04. 01. 19 4:01, Tom Rini wrote:
On Fri, Jan 04, 2019 at 09:29:47AM +0800, Bin Meng wrote:
On Thu, Jan 3, 2019 at 9:39 PM Tom Rini wrote:
On Thu, Jan 03, 2019 at 09:00:41AM +0100, Michal Simek wrote:
On 26. 12. 18 15:29, Tom Rini wrote:
On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
Hi Michal,
On Thu, Dec 20, 2018 at 4:17 PM Michal Simek wrote:
On 20. 12. 18 9:09, Bin Meng wrote:
On Thu, Dec 20, 2018 at 3:55 PM Michal Simek wrote:
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by: Michal Simek
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
.travis.yml | 8
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6e4b4ba0a34a..e14e6987e4cf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -454,6 +454,14 @@ matrix:
QEMU_TARGET="arm-softmmu"
TEST_PY_ID="--id qemu"
BUILDMAN="^zynq_zc702$"
+- name: "test/py xilinx_versal_virt"
+ env:
+- TEST_PY_BD="xilinx_versal_virt"
+ TEST_PY_TEST_SPEC="not sleep"
+ QEMU_TARGET="aarch64-softmmu"
+ QEMU_VERSION="v3.1.0"
+ TEST_PY_ID="--id qemu"
+ BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever
version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will
let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason
not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the
version we use be spelled out will help with future reproducibility.
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let
vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
Captured stdout setup -
+u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we
need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on
the other QEMU-based targets. Can you update uboot-test-hooks (change
.travis.yml to clone your fork of uboot-test-hooks rather than
swarren's) to have the modern syntax? Thanks!
I think the correct approach is to update uboot-test-hooks and send PR
to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should
still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the
changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi.
It works on v3.0 but not on v3.1.
=> => tftpboot 8000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'lib/efi_loader/helloworld.efi'.
Load address: 0x8000
Loading: #
2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 8000 $filesize
CRC32 for 8000 ... 885f ==> b76d87c0
=> => bootefi 8000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 8000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.
My goal is to get Versal to travis to make sure that none is breaking it
not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468
So the offending change is a new capability in QEMU that exposes EL2
(HYP) mode on the Cortex-A15 core which this vexpress model uses. There
are 2 steps here IMHO:
1) Disable EL2 again by hand. This is easily doable by passing "-cpu
cortex-a15,has_el2=off" to the QEMU command line. That restores the
previous behavior
2) Find out *why* it's broken. That's probably a U-Boot bug.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH 1/2] mips: spi: mscc: Add fast bitbang SPI driver
Am 07.01.19 um 11:19 schrieb lars.povl...@microchip.com: > Hi Daniel! > > Thank you for your comments. I hope we are not carpet-bombing you > with patches :-). Your efforts are much appreciated! > > I added comments below. > >> -Original Message- >> From: Daniel Schwierzeck >> Sent: Friday, January 4, 2019 19:53 >> To: Lars Povlsen - M31675 ; u- >> b...@lists.denx.de >> Cc: gregory.clem...@bootlin.com; Horatiu Vultur - M31836 >> ; Jagan Teki >> Subject: Re: [PATCH 1/2] mips: spi: mscc: Add fast bitbang SPI driver >> >> >> >> Am 04.01.19 um 10:47 schrieb Lars Povlsen: >>> From: Lars Povlsen >>> >>> This patch add a new SPI driver for MSCC SOCs that does not sport the >>> designware SPI hardware controller. >>> >>> Performance gain: 7.664 seconds vs. 17.633 for 1 Mbyte write - >>> measured on a Luton10 with a m25p128 NOR flash. >> >> is the generic bitbang driver such inefficient (e.g. by having to much >> delays) or does the improvement cone from cutting out GPIO API and >> drivers? IMHO it's not the best idea to workaround generic drivers by >> creating custom ones and repeating parts of the code. > > Surely some overhead is introduced by the GPIO API. In this case the overhead > is made worse by an "emulation" on top of the normal GPIO drivers on the SoC > due to the fact that CS0 is not GPIO controlled but a dedicated pin controlled > by SPI directly. This driver is more "direct" and offer a significant speed > increase. > > As for duplication, the inner loop of the driver is admittedly functionally > equivalent to the innards of soft_spi_xfer(), but not a duplicate. And it will > obsolete gpio-mscc-bitbang-spi.c (which I will remove in the next patch > version). ok, fine with me > >> >>> >>> Signed-off-by: Lars Povlsen >>> --- >>> MAINTAINERS | 1 + >>> configs/mscc_luton_defconfig | 3 +- >>> drivers/spi/Kconfig | 7 + >>> drivers/spi/Makefile | 1 + >>> drivers/spi/mscc_bb_spi.c| 258 >> +++ >>> 5 files changed, 269 insertions(+), 1 deletion(-) >>> create mode 100644 drivers/spi/mscc_bb_spi.c >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 494962e9b3..0cee99ef56 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -524,6 +524,7 @@ F: arch/mips/dts/ocelot* >>> F: board/mscc/ >>> F: configs/mscc* >>> F: drivers/gpio/mscc_sgpio.c >>> +F: drivers/spi/mscc_bb_spi.c >>> F: include/configs/vcoreiii.h >>> >>> MIPS JZ4780 >>> diff --git a/configs/mscc_luton_defconfig >> b/configs/mscc_luton_defconfig >>> index 65f0672c1e..d48a93a2a5 100644 >>> --- a/configs/mscc_luton_defconfig >>> +++ b/configs/mscc_luton_defconfig >>> @@ -34,6 +34,7 @@ CONFIG_CMD_DHCP=y >>> # CONFIG_NET_TFTP_VARS is not set >>> # CONFIG_CMD_NFS is not set >>> CONFIG_CMD_PING=y >>> +CONFIG_CMD_TIME=y >>> CONFIG_CMD_MTDPARTS=y >>> CONFIG_MTDIDS_DEFAULT="nor0=spi_flash" >>> >> CONFIG_MTDPARTS_DEFAULT="mtdparts=spi_flash:1m(UBoot),256k(Env),256k(Env >> .bk),512k(Unused),6m(linux)" >>> @@ -66,5 +67,5 @@ CONFIG_DEBUG_UART_SHIFT=2 >>> CONFIG_SYS_NS16550=y >>> CONFIG_SPI=y >>> CONFIG_DM_SPI=y >>> -CONFIG_SOFT_SPI=y >>> +CONFIG_MSCC_BB_SPI=y >>> CONFIG_LZMA=y >> >> the defconfig change should go into patch 1/2 along with the device-tree >> update > > I will do so. (I was earlier advised to keep DT changes in separate patches). I guess you're refering to Linux, where it makes sense. But with U-Boot you would get a broken or unbootable binary between separate defconfig and DT patches which hurts bisectability. > >> >>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig >>> index a7bb5b35c2..de4d62dd8f 100644 >>> --- a/drivers/spi/Kconfig >>> +++ b/drivers/spi/Kconfig >>> @@ -294,6 +294,13 @@ config SOFT_SPI >>> Enable Soft SPI driver. This driver is to use GPIO simulate >>> the SPI protocol. >>> >>> +config MSCC_BB_SPI >>> + bool "MSCC bitbang SPI driver" >>> + depends on SOC_VCOREIII >>> + help >>> + Enable MSCC bitbang SPI driver. This driver can be used on >>> + MSCC SOCs. >>> + >>> config CF_SPI >>> bool "ColdFire SPI driver" >>> help >>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile >>> index 392a925795..4acec3ea17 100644 >>> --- a/drivers/spi/Makefile >>> +++ b/drivers/spi/Makefile >>> @@ -36,6 +36,7 @@ obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o >>> obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o >>> obj-$(CONFIG_MTK_QSPI) += mtk_qspi.o >>> obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o >>> +obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o >>> obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o >>> obj-$(CONFIG_MXC_SPI) += mxc_spi.o >>> obj-$(CONFIG_MXS_SPI) += mxs_spi.o >>> diff --git a/drivers/spi/mscc_bb_spi.c b/drivers/spi/mscc_bb_spi.c >>> new file mode 100644 >>> index 00..e0ed2c9725 >>> --- /dev/null >>> +++ b/drivers/spi/mscc_bb_spi.c >>> @@ -0,0 +1,258 @@ >>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >>> +/* >>> + * Microsemi SoCs spi driver >>> + * >>>
Re: [U-Boot] [PATCH v1 9/9] configs: add default configuraiton for Colibri iMX7 with eMMC
On 07.01.2019 00:49, Marcel Ziswiler wrote: > On Sun, 2019-01-06 at 22:00 +0100, Stefan Agner wrote: >> From: Stefan Agner >> >> Add a default configuration for Colibri iMX7D 1GB (with eMMC >> NAND flash). > > Finally (;-p). > >> Signed-off-by: Stefan Agner >> --- >> >> configs/colibri_imx7_emmc_defconfig | 65 >> + >> 1 file changed, 65 insertions(+) >> create mode 100644 configs/colibri_imx7_emmc_defconfig >> >> diff --git a/configs/colibri_imx7_emmc_defconfig >> b/configs/colibri_imx7_emmc_defconfig >> new file mode 100644 >> index 00..5bd8ac943c >> --- /dev/null >> +++ b/configs/colibri_imx7_emmc_defconfig >> @@ -0,0 +1,65 @@ >> +CONFIG_ARM=y >> +CONFIG_SYS_THUMB_BUILD=y >> +CONFIG_ARCH_MX7=y >> +CONFIG_SYS_TEXT_BASE=0x8780 >> +CONFIG_SECURE_BOOT=y >> +CONFIG_TARGET_COLIBRI_IMX7=y >> +CONFIG_TARGET_COLIBRI_IMX7_EMMC=y >> +CONFIG_IMX_RDC=y >> +CONFIG_IMX_BOOTAUX=y >> +# CONFIG_CMD_DEKBLOB is not set >> +CONFIG_ENV_VARS_UBOOT_CONFIG=y >> +CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imxi >> mage.cfg,MX7D" >> +CONFIG_BOOTDELAY=1 >> +# CONFIG_CONSOLE_MUX is not set >> +CONFIG_SYS_CONSOLE_IS_IN_ENV=y >> +# CONFIG_DISPLAY_BOARDINFO is not set >> +CONFIG_DISPLAY_BOARDINFO_LATE=y >> +CONFIG_HUSH_PARSER=y >> +CONFIG_SYS_PROMPT="Colibri iMX7 # " >> +# CONFIG_CMD_BOOTD is not set >> +CONFIG_CMD_BOOTZ=y >> +# CONFIG_CMD_IMI is not set >> +# CONFIG_CMD_XIMG is not set >> +CONFIG_CMD_ASKENV=y >> +CONFIG_CMD_MEMTEST=y >> +CONFIG_CMD_GPIO=y >> +CONFIG_CMD_I2C=y >> +CONFIG_CMD_MMC=y >> +CONFIG_CMD_USB=y >> +CONFIG_CMD_USB_MASS_STORAGE=y >> +CONFIG_CMD_DHCP=y >> +CONFIG_CMD_MII=y >> +CONFIG_CMD_PING=y >> +CONFIG_CMD_BMP=y >> +CONFIG_CMD_CACHE=y >> +# CONFIG_CMD_HASH is not set >> +CONFIG_CMD_EXT4=y >> +CONFIG_CMD_FAT=y >> +CONFIG_CMD_FS_GENERIC=y >> +CONFIG_OF_CONTROL=y >> +CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-emmc" >> +CONFIG_ENV_IS_IN_MMC=y >> +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y >> +CONFIG_FSL_CAAM=y >> +CONFIG_DM_GPIO=y >> +CONFIG_DM_I2C=y >> +CONFIG_DM_MMC=y >> +CONFIG_FSL_ESDHC=y >> +CONFIG_PHYLIB=y >> +CONFIG_PHY_MICREL=y >> +CONFIG_MII=y >> +CONFIG_PINCTRL=y >> +CONFIG_PINCTRL_IMX7=y >> +CONFIG_DM_PMIC=y >> +CONFIG_PMIC_RN5T567=y >> +CONFIG_USB=y >> +CONFIG_USB_EHCI_HCD=y >> +CONFIG_USB_GADGET=y >> +CONFIG_USB_GADGET_MANUFACTURER="Toradex" >> +CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 >> +CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 >> +CONFIG_CI_UDC=y >> +CONFIG_USB_GADGET_DOWNLOAD=y >> +CONFIG_VIDEO=y >> +CONFIG_OF_LIBFDT_OVERLAY=y > > Again, I would use CONFIG_DISTRO_DEFAULTS as well. Plus maybe some > other goodies like CONFIG_FIT, CONFIG_CRC32_VERIFY, CONFIG_CMD_DFU, > CONFIG_CMD_GPT, CONFIG_DFU_MMC and the oldé CONFIG_FAT_WRITE. Okay, will add those. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/9] configs: colibri_imx7: enable DM for raw NAND devices
On 07.01.2019 00:25, Marcel Ziswiler wrote: > On Sun, 2019-01-06 at 22:00 +0100, Stefan Agner wrote: >> From: Stefan Agner >> >> Use DM and device trees for raw NAND devices by default. This >> fixes -74 NAND read errors since it makes sure the ECC settings >> are the same as used in Linux and our downstream U-Boot. >> >> Signed-off-by: Stefan Agner >> --- >> >> configs/colibri_imx7_defconfig | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/configs/colibri_imx7_defconfig >> b/configs/colibri_imx7_defconfig >> index 7441102ed4..3aaf1a417d 100644 >> --- a/configs/colibri_imx7_defconfig >> +++ b/configs/colibri_imx7_defconfig >> @@ -25,6 +25,7 @@ CONFIG_CMD_DFU=y >> CONFIG_CMD_GPIO=y >> CONFIG_CMD_I2C=y >> CONFIG_CMD_MMC=y >> +CONFIG_CMD_MTD=y >> CONFIG_CMD_NAND_TRIMFFS=y >> CONFIG_CMD_NAND_TORTURE=y >> CONFIG_CMD_USB=y >> @@ -50,7 +51,9 @@ CONFIG_DFU_MMC=y >> CONFIG_DM_GPIO=y >> CONFIG_DM_I2C=y >> CONFIG_FSL_ESDHC=y >> +CONFIG_MTD=y >> CONFIG_NAND=y >> +CONFIG_NAND_MXS_DT=y >> CONFIG_MTD_UBI_FASTMAP=y >> CONFIG_PHYLIB=y >> CONFIG_PHY_MICREL=y > > We might want to add the following as well: > > CONFIG_DFU_NAND=y > > Plus I do not understand why we do not use CONFIG_DISTRO_DEFAULTS which would > include a lot of our now manually picked configuration items. Hm, good catch. There is CONFIG_DFU_MMC enabled for some reason, seemed to have slipped in in a Kconfig move. Will fix this. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/9] arm: dts: imx7: colibri: split dt for raw NAND and eMMC devices
On 07.01.2019 00:18, Marcel Ziswiler wrote:
> On Sun, 2019-01-06 at 22:00 +0100, Stefan Agner wrote:
>> From: Stefan Agner
>>
>> In preparation of adding CONFIG_DM_MMC support use separate device
>> trees for raw NAND and eMMC devices.
>>
>> Signed-off-by: Stefan Agner
>> ---
>>
>> arch/arm/dts/imx7-colibri-emmc.dts| 16 +++
>> arch/arm/dts/imx7-colibri-rawnand.dts | 46
>> +++
>> .../{imx7-colibri.dts => imx7-colibri.dtsi} | 39 +---
>
> I believe renaming that one also needs changes in resp. Makefile
> otherwise leading to the following:
>
> make[3]: *** No rule to make target 'arch/arm/dts/imx7-colibri.dtb',
> needed by 'dtbs'. Stop.
Good catch, I definitely need to remove imx7-colibri.dtb there.
>
> Plus you may want to add the eMMC one as well e.g. as follows:
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index dda4e59491..9596b2a64f 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -458,7 +458,8 @@ dtb-$(CONFIG_MX6UL) += \
>
> dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb
>
> -dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
> +dtb-$(CONFIG_MX7) += imx7-colibri-emmc.dtb \
> + imx7-colibri-rawnand.dtb \
> imx7d-sdb.dtb \
> imx7d-sdb-qspi.dtb
It seems that removing is actually sufficient. dtc/Makefile along with
CONFIG_OF_EMBED actually builds the device tree specified in the config
file automatically. Should we still add board device trees to
arch/arm/dts/Makefile?
@Stefano/ML any preference?
>
> BTW: Remember, I am not too big of a fan of renaming stuff and
> everywhere else we so far did not call anything -rawnand as of yet.
> However, in general I agree that this would be more clear and if you do
> clean-up the rest of the world(TM) in a similar fashion I am OK with
> it.
>
I don't _re_name, I just name :-) When we had to name the dt's in the
kernel, we did not knew that there will be an eMMC variant. It's a
different start condition here.
Also mind that device trees are named differently: Since we use the same
boot loader for i.MX 7S and 7D, I dropped a letter there too... IMHO,
renaming the dt in Linux now is too much churn. So I suggest either
leave as is in Kernel and deviate a bit in U-Boot or drop -rawnand in
U-Boot, what do you think?
--
Stefan
>> board/toradex/colibri_imx7/MAINTAINERS| 3 ++
>> configs/colibri_imx7_defconfig| 2 +-
>> 5 files changed, 67 insertions(+), 39 deletions(-)
>> create mode 100644 arch/arm/dts/imx7-colibri-emmc.dts
>> create mode 100644 arch/arm/dts/imx7-colibri-rawnand.dts
>> rename arch/arm/dts/{imx7-colibri.dts => imx7-colibri.dtsi} (65%)
>>
>> diff --git a/arch/arm/dts/imx7-colibri-emmc.dts b/arch/arm/dts/imx7-
>> colibri-emmc.dts
>> new file mode 100644
>> index 00..295ca05916
>> --- /dev/null
>> +++ b/arch/arm/dts/imx7-colibri-emmc.dts
>> @@ -0,0 +1,16 @@
>> +// SPDX-License-Identifier: GPL-2.0+ OR X11
>
> Don't we rather want GPL-2.0 OR MIT?
>
>> +/*
>> + * Copyright 2019 Toradex AG
>> + */
>> +
>> +/dts-v1/;
>> +#include "imx7-colibri.dtsi"
>> +
>> +/ {
>> +model = "Toradex Colibri iMX7D 1GB (eMMC)";
>> +compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
>> +
>> +chosen {
>> +stdout-path =
>> +};
>> +};
>
> I guess the meat-on-the-bone will follow (;-p).
>
>> diff --git a/arch/arm/dts/imx7-colibri-rawnand.dts
>> b/arch/arm/dts/imx7-colibri-rawnand.dts
>> new file mode 100644
>> index 00..4eb86fb011
>> --- /dev/null
>> +++ b/arch/arm/dts/imx7-colibri-rawnand.dts
>> @@ -0,0 +1,46 @@
>> +// SPDX-License-Identifier: GPL-2.0+ OR X11
>
> Dito.
>
>> +/*
>> + * Copyright 2019 Toradex AG
>> + */
>> +
>> +/dts-v1/;
>> +#include "imx7-colibri.dtsi"
>> +
>> +/ {
>> +model = "Toradex Colibri iMX7S/D";
>> +compatible = "toradex,imx7-colibri", "fsl,imx7";
>> +
>> +chosen {
>> +stdout-path =
>> +};
>> +};
>> +
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_gpmi_nand>;
>> +,use-minimum-ecc;
>> +nand-on-flash-bbt;
>> +-ecc-mode = "hw";
>> +status = "okay";
>> +};
>> +
>> + {
>> +pinctrl_gpmi_nand: gpmi-nand-grp {
>> +fsl,pins = <
>> +MX7D_PAD_SD3_CLK__NAND_CLE 0x71
>> +MX7D_PAD_SD3_CMD__NAND_ALE 0x71
>> +MX7D_PAD_SAI1_TX_BCLK__NAND_CE0_B 0x71
>> +MX7D_PAD_SAI1_TX_DATA__NAND_READY_B 0x74
>> +MX7D_PAD_SD3_STROBE__NAND_RE_B 0x71
>> +MX7D_PAD_SD3_RESET_B__NAND_WE_B 0x71
>> +MX7D_PAD_SD3_DATA0__NAND_DATA00 0x71
>> +MX7D_PAD_SD3_DATA1__NAND_DATA01 0x71
>> +MX7D_PAD_SD3_DATA2__NAND_DATA02 0x71
>> +MX7D_PAD_SD3_DATA3__NAND_DATA03 0x71
>> +MX7D_PAD_SD3_DATA4__NAND_DATA04 0x71
>> +
Re: [U-Boot] [GIT] Pull request: u-boot-dfu (04.01.2019)
On 1/7/19 3:51 PM, Jean-Jacques Hiblot wrote: > > On 04/01/2019 19:51, Marek Vasut wrote: >> On 1/4/19 4:17 PM, Jean-Jacques Hiblot wrote: >>> On 04/01/2019 16:07, Marek Vasut wrote: On 1/4/19 8:01 AM, Lukasz Majewski wrote: > Dear Marek, > > The following changes since commit > 7436f5e54d35bcad53befec90e2e67288071f74e: > > Merge tag 'for-master-20190103' of > git://git.denx.de/u-boot-rockchip > (2019-01-03 08:39:44 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-dfu.git > > for you to fetch changes up to > deb73d0aea6ca09ecb56ea3431d3151427fff4a4: > > dm: usb: gadget: Fix boot breakage on sunxi platforms (2019-01-03 > 22:43:02 +0100) > > > Jean-Jacques Hiblot (3): > dm: usb: udc: Use SEQ_ALIAS to index the USB gadget ports > ARM: dts: define USB aliases for all omap5 platforms > dm: usb: gadget: Fix boot breakage on sunxi platforms Why is udc-uclass.c compiled in when CONFIG_(SPL_)DM is enabled ? This doesn't make sense, I don't want any UDC code in builds which enable just DM . >>> It only adds the UCLASS_DRIVER definition for the USB gadget. The rest >>> is compiled out inside udc-uclass.c >> Why do we want it in unconditionally at all ? > > We don't really. I'll post something to make it conditional on USB_GADGET. > > I'll take the opportunity to rename SPL_USB_GADGET_SUPPORT to > SPL_USB_GADGET for consistency. > > But this may take some time to verify (buildman and also boot check), > and the current version seems to work for everyone so far. That's fine, there's still ~1 week till the release. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu (04.01.2019)
On 04/01/2019 19:51, Marek Vasut wrote: On 1/4/19 4:17 PM, Jean-Jacques Hiblot wrote: On 04/01/2019 16:07, Marek Vasut wrote: On 1/4/19 8:01 AM, Lukasz Majewski wrote: Dear Marek, The following changes since commit 7436f5e54d35bcad53befec90e2e67288071f74e: Merge tag 'for-master-20190103' of git://git.denx.de/u-boot-rockchip (2019-01-03 08:39:44 -0500) are available in the git repository at: git://git.denx.de/u-boot-dfu.git for you to fetch changes up to deb73d0aea6ca09ecb56ea3431d3151427fff4a4: dm: usb: gadget: Fix boot breakage on sunxi platforms (2019-01-03 22:43:02 +0100) Jean-Jacques Hiblot (3): dm: usb: udc: Use SEQ_ALIAS to index the USB gadget ports ARM: dts: define USB aliases for all omap5 platforms dm: usb: gadget: Fix boot breakage on sunxi platforms Why is udc-uclass.c compiled in when CONFIG_(SPL_)DM is enabled ? This doesn't make sense, I don't want any UDC code in builds which enable just DM . It only adds the UCLASS_DRIVER definition for the USB gadget. The rest is compiled out inside udc-uclass.c Why do we want it in unconditionally at all ? We don't really. I'll post something to make it conditional on USB_GADGET. I'll take the opportunity to rename SPL_USB_GADGET_SUPPORT to SPL_USB_GADGET for consistency. But this may take some time to verify (buildman and also boot check), and the current version seems to work for everyone so far. JJ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] x86: tsc: Add support for native calibration of TSC freq
On Mon, Jan 7, 2019 at 1:14 PM Bernhard Messerklinger
wrote:
>
> Add native tsc calibration function. Calibrate the tsc timer the same
> way as linux does in arch/x86/kernel/tsc.c.
> Fixes booting for Apollo Lake processors.
>
LGTM
Reviewed-by: Andy Shevchenko
P.S. Though I didn't test it.
> Signed-off-by: Bernhard Messerklinger
>
> ---
> I hope this patch won't break other x86 board.
> I only can test it with APL board.
>
> Changes in v4:
> - Fix commit message
> - Update macro names
> - Order macro numbers
> - Check cpuid eax and ebx return value
>
> drivers/timer/tsc_timer.c | 55 +++
> 1 file changed, 55 insertions(+)
>
> diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c
> index ba940ebf1c..919caba8a1 100644
> --- a/drivers/timer/tsc_timer.c
> +++ b/drivers/timer/tsc_timer.c
> @@ -19,8 +19,59 @@
>
> #define MAX_NUM_FREQS 9
>
> +#define INTEL_FAM6_SKYLAKE_MOBILE 0x4E
> +#define INTEL_FAM6_ATOM_GOLDMONT 0x5C /* Apollo Lake */
> +#define INTEL_FAM6_SKYLAKE_DESKTOP 0x5E
> +#define INTEL_FAM6_ATOM_GOLDMONT_X 0x5F /* Denverton */
> +#define INTEL_FAM6_KABYLAKE_MOBILE 0x8E
> +#define INTEL_FAM6_KABYLAKE_DESKTOP0x9E
> +
> DECLARE_GLOBAL_DATA_PTR;
>
> +/*
> + * native_calibrate_tsc
> + * Determine TSC frequency via CPUID, else return 0.
> + */
> +static unsigned long native_calibrate_tsc(void)
> +{
> + struct cpuid_result tsc_info;
> + unsigned int crystal_freq;
> +
> + if (gd->arch.x86_vendor != X86_VENDOR_INTEL)
> + return 0;
> +
> + if (cpuid_eax(0) < 0x15)
> + return 0;
> +
> + tsc_info = cpuid(0x15);
> +
> + if (tsc_info.ebx == 0 || tsc_info.eax == 0)
> + return 0;
> +
> + crystal_freq = tsc_info.ecx / 1000;
> +
> + if (!crystal_freq) {
> + switch (gd->arch.x86_model) {
> + case INTEL_FAM6_SKYLAKE_MOBILE:
> + case INTEL_FAM6_SKYLAKE_DESKTOP:
> + case INTEL_FAM6_KABYLAKE_MOBILE:
> + case INTEL_FAM6_KABYLAKE_DESKTOP:
> + crystal_freq = 24000; /* 24.0 MHz */
> + break;
> + case INTEL_FAM6_ATOM_GOLDMONT_X:
> + crystal_freq = 25000; /* 25.0 MHz */
> + break;
> + case INTEL_FAM6_ATOM_GOLDMONT:
> + crystal_freq = 19200; /* 19.2 MHz */
> + break;
> + default:
> + return 0;
> + }
> + }
> +
> + return (crystal_freq * tsc_info.ebx / tsc_info.eax) / 1000;
> +}
> +
> static unsigned long cpu_mhz_from_cpuid(void)
> {
> if (gd->arch.x86_vendor != X86_VENDOR_INTEL)
> @@ -350,6 +401,10 @@ static void tsc_timer_ensure_setup(bool early)
> if (!gd->arch.clock_rate) {
> unsigned long fast_calibrate;
>
> + fast_calibrate = native_calibrate_tsc();
> + if (fast_calibrate)
> + goto done;
> +
> fast_calibrate = cpu_mhz_from_cpuid();
> if (fast_calibrate)
> goto done;
> --
> 2.20.1
>
>
--
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 15/26] clk: sunxi: Add ccu clock tree support
On Mon, 7 Jan 2019 14:01:01 +0100 Maxime Ripard wrote: Hi, > On Mon, Jan 07, 2019 at 01:03:33AM +, André Przywara wrote: > > On 31/12/2018 16:59, Jagan Teki wrote: > > > Clock control unit comprises of parent clocks, gates, > > > multiplexers, dividers, multipliers, pre/post dividers and flags > > > etc. > > > > > > So, the U-Boot implementation of ccu has divided into gates and > > > tree. gates are generic clock configuration of enable/disable bit > > > management which can be handle via ccu_clock_gate. > > > > So if I understand this correctly, you implement the gate > > functionality separately from the complex clock code, even if they > > are the same clock from the DT point of view? So if one wants to > > enable the MMC0 clock, which is a mux/divider clock, one needs to > > specify an extra entry in the gate array to describe the enable bit > > in this special clock register? Sounds a bit surprising, but is > > probably a neat trick to keep things simple. There should be a > > comment in the code to this regard then. > > > Tree clocks are parent clock type, fixed clocks, mp, nk, nkm, > > > nkmp, pre/post div, flags etc. which were managed via > > > ccu_clock_tree. > > > > For a start, can we use more descriptive names than those very > > specific MP/NK names? DIV_MUX and PLL sound more descriptive to me. > > I understand that Linux uses those terms, but it would be great if > > uninitiated people have a chance to understand this as well. > > > > > This patch add support for MP, NK, MISC, FIXED clock types as > > > part of ccu clock tree with get_rate functionality this > > > eventually used by uart driver. and rest of the infrastructure > > > will try to add while CLK is being used on respective peripherals. > > > > > > Note that few of the tree type clock would require to enable > > > gates on their specific clock, in that case we need to add the > > > gate details via ccu_clock_gate, example: MP with gate so the > > > gate offset, bit value should add as part of ccu_clock_gate. > > > > > > Signed-off-by: Jagan Teki > > > --- > > > arch/arm/include/asm/arch-sunxi/ccu.h | 192 > > > +- drivers/clk/sunxi/clk_a64.c > > > | 40 ++ drivers/clk/sunxi/clk_sunxi.c | 182 > > > 3 files changed, 413 insertions(+), 1 > > > deletion(-) > > > > > > diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h > > > b/arch/arm/include/asm/arch-sunxi/ccu.h index > > > 3fdc26978d..61b8c36b3b 100644 --- > > > a/arch/arm/include/asm/arch-sunxi/ccu.h +++ > > > b/arch/arm/include/asm/arch-sunxi/ccu.h @@ -7,15 +7,204 @@ > > > #ifndef _ASM_ARCH_CCU_H > > > #define _ASM_ARCH_CCU_H > > > > > > +#define OSC_32K_ULL 32000ULL > > > > 32768 > > > > And why ULL? The whole Allwinner clock system works with 32-bit > > values, so just U would be totally sufficient. This avoid blowing > > this up to 64 bit unnecessarily, which sounds painful for those > > poor ARMv7 parts. > > > +#define OSC_24M_ULL 2400ULL > > > + > > > +/** > > > + * enum ccu_clk_type - ccu clock types > > > + * > > > + * @CCU_CLK_TYPE_MISC: misc clock type > > > > What is MISC, exactly? Seems like an artefact clock to me, some > > placeholder you need because gate clocks are handled separately in > > the gates struct. Should this be called something with SIMPLE > > instead, or GATE? > > > + * @CCU_CLK_TYPE_FIXED: fixed clock type > > > + * @CCU_CLK_TYPE_MP: mp clock type > > > + * @CCU_CLK_TYPE_NK: nk clock type > > > > What is the point of those comments, as you are basically repeating > > the enum name? What about: > > * @CCU_CLK_TYPE_PLL: PLL clock with two multiplier > > fields > > We have PLL with 2 multipliers, but also others with other factors > sets, so that will end up being confusing. If the MP, NK and so on > stuff is confusing, maybe we should just add a comment on top of that > structure to explain what those factors are and what it actually > means? Fair enough, or we name it CCU_CLK_TYPE_PLL_NK, because this is what this type deals with. Point is that by chance I happened to know about those naming of factors in the manual, but other might be lost by just seeing "mp" or "nk", without any explanation - and the comment doesn't help here at all. The other part is that the "TYPE_MP" is twice as confusing, as it can perfectly describe the MMC clocks, which use "N" and "M" in the A64 manual, for instance. That's why my suggestion for calling a spade a spade and saying it's a divider clock with a multiplexer. Happy to have the Linux naming in the comments. Thanks, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols
Apologies for late reply, back from holidays today.
On Tue, Dec 25, 2018 at 05:30:25PM +0900, AKASHI Takahiro wrote:
> > >>> +struct efi_key_descriptor {
> > >>> + efi_key key;
> > >>
> > >> Hello Takahiro,
> > >>
> > >> with the patch I can start the EFI shell. But I am still trying to check
> > >> the different definitions in this file.
> > >>
> > >> As mentioned in prior mail the size of enum is not defined in the C
> > >> spec. So better use u32.
> > >
> > > Sure, but I still wonder whether this should be u32 or u16 (or even u8)
> > > as UEFI spec doesn't clearly define this.
> >
> > Enums may hold up to INT_MAX, so just make it u32.
>
> OK.
>
> > >
> > >>> + u16 unicode;
> > >>> + u16 shifted_unicode;
> > >>> + u16 alt_gr_unicode;
> > >>> + u16 shifted_alt_gr_unicode;
> > >>> + u16 modifier;
> > >>> + u16 affected_attribute;
> > >>> +};
> > >>> +
> > >>> +struct efi_hii_keyboard_layout {
> > >>> + u16 layout_length;
> > >>> + efi_guid_t guid;
> > >>
> > >> A patch to change the alignment of efi_guid_t to __alinged(8) has been
> > >> merged into efi-next.
> > >
> > > I have one concern here;
> > > This structure will also be used as a data format/layout in a file,
> > > a package list, given the fact that UEFI defines ExportPackageLists().
> > > So extra six bytes after layout_length, for example, may not be very
> > > useful in general.
> > > I'm not very much sure if UEFI spec intends so.
> >
> > I'm not sure I fully follow. We ideally should be compatible with edk2,
> > no? So if the spec isn't clear, let's make sure we clarify the spec to
> > the behavior edk2 exposes today.
The spec cannot simply be changed to be incompatible with a previous
version of the spec, regardless of what EDK2 happens to do. (But...)
> I'm not sure that EDK2 is very careful about data alignment.
> Regarding guid, in MdePkg/Include/Base.h,
> ///
> /// 128 bit buffer containing a unique identifier value.
> /// Unless otherwise specified, aligned on a 64 bit boundary.
> ///
> typedef struct {
> UINT32 Data1;
> UINT16 Data2;
> UINT16 Data3;
> UINT8 Data4[8];
> } GUID;
> in MdePkg/Include/Uefi/UefiBaseType.h,
> typedef GUID EFI_GUID;
>
> There is no explicit "aligned()" attribute contrary to Heinrich's patch.
No, so the alignment when building for (any) ARM architecture will end
up being 32-bit. Which I agree does not seem to live up to the
specification's requirement on 64-bit alignment where nothing else is
said.
Since, obviously, u-boot and edk2 disagreeing about the layout of
structs that are exposed to external applications/drivers would defeat
this whole exercise, I think we should start by taking this question
to edk2-devel (which I have).
> Regarding hii_keyboard_layout,
> in Include/Uefi/UefiInternalFormRepresentation.h,
> typedef struct {
> UINT16 LayoutLength;
> EFI_GUIDGuid;
> UINT32 LayoutDescriptorStringOffset;
> UINT8 DescriptorCount;
> // EFI_KEY_DESCRIPTORDescriptors[];
> } EFI_HII_KEYBOARD_LAYOUT;
>
> No "packed" attribute, so neither in my code.
There is a #pragma pack(1) near the start of this file and a #pragma
pack() near the end.
Interestingly, UEFI 2.7a describes the EFI_HII_KEYBOARD_LAYOUT struct
as containing the EFI_KEY_DESCRIPTOR array at the end, whereas the
EDK2 code above has it commented it out.
EDK2 itself treats the EFI_HII_KEYBOARD_LAYOUT as a header, which is
discarded.
So, continuning the (But...)
My understanding is this:
- The EDK2 implementation does not conform to the specification; it
completely packs the EFI_HII_KEYBOARD_LAYOUT, which the
specification does not mention anything about. Since this code is
well in the wild, and drivers tested against the current layout need
to continuw eorking, I expect the only possible solution is to
update the specification to say EFI_HII_KEYBOARD_LAYOUT must be
packed.
- The default EDK2 definition of GUID (and hence EFI_GUID) gives it a
32-bit alignment requirement also on 64-bit architectures. In
practice, I expect this would only affect (some of the) GUIDs that
are members of structs used in UEFI interfaces. But that may already
be too common an occurrence to audit and address in EDK2. Does the
spec need to change on this also?
Can the TianoCore MdeModulePkg Maintainers on cc please comment?
(I also cc:d the other stewards as well as Ard, in case they have
further input.)
> > >>> + u32 layout_descriptor_string_offset;
> > >>> + u8 descriptor_count;
> > >>> + struct efi_key_descriptor descriptors[];
> > >>> +};
> > >>> +
> > >>> +struct efi_hii_package_list_header {
> > >>> + efi_guid_t package_list_guid;
> > >>> + u32 package_length;
> > >>> +} __packed;
> > >>
> > >> You are defining several
[U-Boot] [PATCH v2 3/3] mips: gpio: mscc: Obsoleted gpio-mscc-bitbang-spi.c
With the new mscc_bb_spi.c driver, there is no longer use for the
gpio-mscc-bitbang-spi.c driver.
Signed-off-by: Lars Povlsen
---
drivers/gpio/Kconfig | 7 --
drivers/gpio/Makefile| 1 -
drivers/gpio/gpio-mscc-bitbang-spi.c | 122 ---
3 files changed, 130 deletions(-)
delete mode 100644 drivers/gpio/gpio-mscc-bitbang-spi.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index aa55ff43c4..14a14be917 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -99,13 +99,6 @@ config LPC32XX_GPIO
help
Support for the LPC32XX GPIO driver.
-config MSCC_BITBANG_SPI_GPIO
- bool "Microsemi bitbang spi GPIO driver"
- depends on DM_GPIO && SOC_VCOREIII
- help
- Support controlling the GPIO used for SPI bitbang by software. Can
- be used by the VCoreIII SoCs, but it was mainly useful for Luton.
-
config MSCC_SGPIO
bool "Microsemi Serial GPIO driver"
depends on DM_GPIO && SOC_VCOREIII
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index be2b3c792f..7c479efe2d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -59,5 +59,4 @@ obj-$(CONFIG_MSM_GPIO)+= msm_gpio.o
obj-$(CONFIG_$(SPL_)PCF8575_GPIO) += pcf8575_gpio.o
obj-$(CONFIG_PM8916_GPIO) += pm8916_gpio.o
obj-$(CONFIG_MT7621_GPIO) += mt7621_gpio.o
-obj-$(CONFIG_MSCC_BITBANG_SPI_GPIO)+= gpio-mscc-bitbang-spi.o
obj-$(CONFIG_MSCC_SGPIO) += mscc_sgpio.o
diff --git a/drivers/gpio/gpio-mscc-bitbang-spi.c
b/drivers/gpio/gpio-mscc-bitbang-spi.c
deleted file mode 100644
index b675f9052c..00
--- a/drivers/gpio/gpio-mscc-bitbang-spi.c
+++ /dev/null
@@ -1,122 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MIT)
-/*
- * Microsemi SoCs pinctrl driver
- *
- * Author:
- * License: Dual MIT/GPL
- * Copyright (c) 2018 Microsemi Corporation
- */
-
-#include
-#include
-#include
-#include
-#include
-
-enum {
- SDI,
- CS0,
- CS1,
- CS2,
- CS3,
- SDO,
- SCK
-};
-
-static const int pinmap[] = { 0, 5, 6, 7, 8, 10, 12 };
-
-#define SW_SPI_CSn_OE 0x1E /* bits 1 to 4 */
-#define SW_SPI_CS0_OE BIT(1)
-#define SW_SPI_SDO_OE BIT(9)
-#define SW_SPI_SCK_OE BIT(11)
-#define SW_PIN_CTRL_MODE BIT(13)
-
-struct mscc_bb_spi_gpio {
- void __iomem *regs;
- u32 cache_val;
-};
-
-static int mscc_bb_spi_gpio_set(struct udevice *dev, unsigned oft, int val)
-{
- struct mscc_bb_spi_gpio *gpio = dev_get_priv(dev);
-
- if (val)
- gpio->cache_val |= BIT(pinmap[oft]);
- else
- gpio->cache_val &= ~BIT(pinmap[oft]);
-
- writel(gpio->cache_val, gpio->regs);
-
- return 0;
-}
-
-static int mscc_bb_spi_gpio_direction_output(struct udevice *dev, unsigned oft,
-int val)
-{
- if (oft == 0) {
- pr_err("SW_SPI_DSI can't be used as output\n");
- return -ENOTSUPP;
- }
-
- mscc_bb_spi_gpio_set(dev, oft, val);
-
- return 0;
-}
-
-static int mscc_bb_spi_gpio_direction_input(struct udevice *dev, unsigned oft)
-{
- return 0;
-}
-
-static int mscc_bb_spi_gpio_get(struct udevice *dev, unsigned int oft)
-{
- struct mscc_bb_spi_gpio *gpio = dev_get_priv(dev);
- u32 val = readl(gpio->regs);
-
- return !!(val & BIT(pinmap[oft]));
-}
-
-static const struct dm_gpio_ops mscc_bb_spi_gpio_ops = {
- .direction_output = mscc_bb_spi_gpio_direction_output,
- .direction_input= mscc_bb_spi_gpio_direction_input,
- .set_value = mscc_bb_spi_gpio_set,
- .get_value = mscc_bb_spi_gpio_get,
-};
-
-static int mscc_bb_spi_gpio_probe(struct udevice *dev)
-{
- struct mscc_bb_spi_gpio *gpio = dev_get_priv(dev);
- struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-
- gpio->regs = dev_remap_addr(dev);
- if (!gpio->regs)
- return -EINVAL;
-
- uc_priv->bank_name = dev->name;
- uc_priv->gpio_count = ARRAY_SIZE(pinmap);
- /*
-* Enable software mode to control the SPI pin, enables the
-* output mode for most of the pin and initialize the cache
-* value in the same time
-*/
-
- gpio->cache_val = SW_PIN_CTRL_MODE | SW_SPI_SCK_OE | SW_SPI_SDO_OE |
- SW_SPI_CS0_OE;
- writel(gpio->cache_val, gpio->regs);
-
- return 0;
-}
-
-static const struct udevice_id mscc_bb_spi_gpio_ids[] = {
- {.compatible = "mscc,spi-bitbang-gpio"},
- {}
-};
-
-U_BOOT_DRIVER(gpio_mscc_bb_spi) = {
- .name = "gpio-mscc-spi-bitbang",
- .id = UCLASS_GPIO,
- .ops= _bb_spi_gpio_ops,
- .probe = mscc_bb_spi_gpio_probe,
- .of_match = of_match_ptr(mscc_bb_spi_gpio_ids),
- .priv_auto_alloc_size = sizeof(struct mscc_bb_spi_gpio),
-};
--
2.19.2
___
U-Boot
[U-Boot] [PATCH v2 2/3] mips: mscc: DT: Update luton device tree to use fast SPI driver
Thes patch change the luton base device tree to use the newly added
SPI bitbang driver.
It also updates the "mscc_luton_defconfig" to use the new driver.
Signed-off-by: Lars Povlsen
---
arch/mips/dts/mscc,luton.dtsi | 15 ++-
configs/mscc_luton_defconfig | 3 ++-
2 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/arch/mips/dts/mscc,luton.dtsi b/arch/mips/dts/mscc,luton.dtsi
index 87e27c6de5..d11ec4884d 100644
--- a/arch/mips/dts/mscc,luton.dtsi
+++ b/arch/mips/dts/mscc,luton.dtsi
@@ -84,21 +84,10 @@
gpio-ranges = < 0 0 64>;
};
- gpio_spi_bitbang: gpio@1064 {
- compatible = "mscc,spi-bitbang-gpio";
- reg = <0x1064 0x4>;
- gpio-controller;
- #gpio-cells = <2>;
-
- };
-
spi0: spi-bitbang {
- compatible = "spi-gpio";
+ compatible = "mscc,luton-bb-spi";
status = "okay";
- gpio-sck = <_spi_bitbang 6 0>;
- gpio-miso = <_spi_bitbang 0 0>;
- gpio-mosi = <_spi_bitbang 5 0>;
- cs-gpios = <_spi_bitbang 1 0>;
+ reg = <0x1064 0x4>;
num-chipselects = <1>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/configs/mscc_luton_defconfig b/configs/mscc_luton_defconfig
index 65f0672c1e..d48a93a2a5 100644
--- a/configs/mscc_luton_defconfig
+++ b/configs/mscc_luton_defconfig
@@ -34,6 +34,7 @@ CONFIG_CMD_DHCP=y
# CONFIG_NET_TFTP_VARS is not set
# CONFIG_CMD_NFS is not set
CONFIG_CMD_PING=y
+CONFIG_CMD_TIME=y
CONFIG_CMD_MTDPARTS=y
CONFIG_MTDIDS_DEFAULT="nor0=spi_flash"
CONFIG_MTDPARTS_DEFAULT="mtdparts=spi_flash:1m(UBoot),256k(Env),256k(Env.bk),512k(Unused),6m(linux)"
@@ -66,5 +67,5 @@ CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYS_NS16550=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
-CONFIG_SOFT_SPI=y
+CONFIG_MSCC_BB_SPI=y
CONFIG_LZMA=y
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] mips: spi: mscc: Add fast bitbang SPI driver
This patch add a new SPI driver for MSCC SOCs that does not sport the
designware SPI hardware controller.
Performance gain: 7.664 seconds vs. 17.633 for 1 Mbyte write.
Signed-off-by: Lars Povlsen
---
MAINTAINERS | 1 +
arch/mips/mach-mscc/include/mach/common.h | 38
drivers/spi/Kconfig | 7 +
drivers/spi/Makefile | 1 +
drivers/spi/mscc_bb_spi.c | 253 ++
5 files changed, 300 insertions(+)
create mode 100644 drivers/spi/mscc_bb_spi.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 494962e9b3..0cee99ef56 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -524,6 +524,7 @@ F: arch/mips/dts/ocelot*
F: board/mscc/
F: configs/mscc*
F: drivers/gpio/mscc_sgpio.c
+F: drivers/spi/mscc_bb_spi.c
F: include/configs/vcoreiii.h
MIPS JZ4780
diff --git a/arch/mips/mach-mscc/include/mach/common.h
b/arch/mips/mach-mscc/include/mach/common.h
index d18ae78bfd..7765c060ed 100644
--- a/arch/mips/mach-mscc/include/mach/common.h
+++ b/arch/mips/mach-mscc/include/mach/common.h
@@ -29,6 +29,44 @@
/* Common utility functions */
+/*
+ * Perform a number of NOP instructions, blocks of 8 instructions.
+ * The (inlined) function will not affect cache or processor state.
+ */
+static inline void mscc_vcoreiii_nop_delay(int delay)
+{
+ while (delay > 0) {
+#define DELAY_8_NOPS() asm volatile("nop; nop; nop; nop; nop; nop; nop; nop;")
+ switch (delay) {
+ case 8:
+ DELAY_8_NOPS();
+ /* fallthrough */
+ case 7:
+ DELAY_8_NOPS();
+ /* fallthrough */
+ case 6:
+ DELAY_8_NOPS();
+ /* fallthrough */
+ case 5:
+ DELAY_8_NOPS();
+ /* fallthrough */
+ case 4:
+ DELAY_8_NOPS();
+ /* fallthrough */
+ case 3:
+ DELAY_8_NOPS();
+ /* fallthrough */
+ case 2:
+ DELAY_8_NOPS();
+ /* fallthrough */
+ case 1:
+ DELAY_8_NOPS();
+ }
+ delay -= 8;
+#undef DELAY_8_NOPS
+ }
+}
+
int mscc_phy_rd_wr(u8 read,
u32 miim_controller,
u8 miim_addr,
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index a7bb5b35c2..de4d62dd8f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -294,6 +294,13 @@ config SOFT_SPI
Enable Soft SPI driver. This driver is to use GPIO simulate
the SPI protocol.
+config MSCC_BB_SPI
+ bool "MSCC bitbang SPI driver"
+ depends on SOC_VCOREIII
+ help
+ Enable MSCC bitbang SPI driver. This driver can be used on
+ MSCC SOCs.
+
config CF_SPI
bool "ColdFire SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 392a925795..4acec3ea17 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
obj-$(CONFIG_MTK_QSPI) += mtk_qspi.o
obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
+obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o
obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
obj-$(CONFIG_MXC_SPI) += mxc_spi.o
obj-$(CONFIG_MXS_SPI) += mxs_spi.o
diff --git a/drivers/spi/mscc_bb_spi.c b/drivers/spi/mscc_bb_spi.c
new file mode 100644
index 00..5685878597
--- /dev/null
+++ b/drivers/spi/mscc_bb_spi.c
@@ -0,0 +1,253 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Microsemi SoCs spi driver
+ *
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct mscc_bb_platdata {
+ void __iomem *regs;
+ u32 deactivate_delay_us;
+};
+
+struct mscc_bb_priv {
+ void __iomem *regs;
+ bool cs_active; /* State flag as to whether CS is asserted */
+ int cs_num;
+ u32 svalue; /* Value to start transfer with */
+ u32 clk1; /* Clock value start */
+ u32 clk2; /* Clock value 2nd phase */
+};
+
+/* Delay 24 instructions for this particular application */
+#define hold_time_delay() mscc_vcoreiii_nop_delay(3)
+
+static int mscc_bb_spi_cs_activate(struct mscc_bb_priv *priv, int mode, int cs)
+{
+ if (!priv->cs_active) {
+ int cpha = mode & SPI_CPHA;
+ u32 cs_value;
+
+ priv->cs_num = cs;
+
+ if (cpha) {
+ /* Initial clock starts SCK=1 */
+ priv->clk1 = ICPU_SW_MODE_SW_SPI_SCK;
+ priv->clk2 = 0;
+ } else {
+ /*
