Re: [U-Boot] [PATCH 3/4] gpio: xilinx: Not read output values via regs
On 26.7.2018 21:46, Stefan Herbrechtsmeier wrote:
> Am 26.07.2018 um 10:41 schrieb Michal Simek:
>> On 25.7.2018 20:21, Stefan Herbrechtsmeier wrote:
>>> Am 25.07.2018 um 08:39 schrieb Michal Simek:
On 24.7.2018 21:56, Stefan Herbrechtsmeier wrote:
> Am 24.07.2018 um 12:31 schrieb Michal Simek:
>> On 23.7.2018 20:42, Stefan Herbrechtsmeier wrote:
>>> Am 23.07.2018 um 13:43 schrieb Michal Simek:
Reading registers for finding out output value is not working
because
input value is read instead in case of tristate.
Reported-by: Stefan Herbrechtsmeier
Signed-off-by: Michal Simek
---
drivers/gpio/xilinx_gpio.c | 38
+-
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/xilinx_gpio.c
b/drivers/gpio/xilinx_gpio.c
index 4da9ae114d87..9d3e9379d0e5 100644
--- a/drivers/gpio/xilinx_gpio.c
+++ b/drivers/gpio/xilinx_gpio.c
> [snip]
>
+ priv->output_val[bank] = val;
+
return val;
};
@@ -441,6 +449,7 @@ static int xilinx_gpio_get_function(struct
udevice *dev, unsigned offset)
static int xilinx_gpio_get_value(struct udevice *dev, unsigned
offset)
{
struct xilinx_gpio_platdata *platdata =
dev_get_platdata(dev);
+ struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
int val, ret;
u32 bank, pin;
@@ -451,7 +460,14 @@ static int xilinx_gpio_get_value(struct
udevice
*dev, unsigned offset)
debug("%s: regs: %lx, gpio: %x, bank %x, pin %x\n",
__func__,
(ulong)platdata->regs, offset, bank, pin);
- val = readl(&platdata->regs->gpiodata + bank * 2);
+ if (xilinx_gpio_get_function(dev, offset) == GPIOF_INPUT) {
+ debug("%s: Read input value from reg\n", __func__);
+ val = readl(&platdata->regs->gpiodata + bank * 2);
+ } else {
+ debug("%s: Read saved output value\n", __func__);
+ val = priv->output_val[bank];
+ }
>>> Why you don't always read the data register? This doesn't work for
>>> three
>>> state outputs.
>> In three state register every bit/pin is 0 - output, 1 input.
>> It means else part is output and I read saved value in
>> priv->output_val.
>> If pin is setup as INPUT then I need read data reg to find out input
>> value.
>> Maybe you are commenting something else but please let me know if
>> there
>> is any other bug.
> What happen if I have an open drain output. Even if the gpio output
> is 1
> the input could read a 0. You driver will always return the output
> value
> and not the real input value. According to the picture in
> documentation
> and my tests a data register write writes the output registers and a
> data register read reads the input registers.
>
> Why should the driver return the desired state (output register)
> and not
> the real state (input register)?
First of all thanks for description.
I have another example where you have output only and you can't read
input because there is no wire.
>>> Does you mean the all outputs configuration? Does this removes the
>>> "gpio_io_i" signal from the IP?
>> I am not sure what synthesis is doing with that unused IP pins but I
>> would consider as a bug if this is automatically connected together.
>
> I mean does the IP generator removes the gpio_io_i signal because it
> isn't needed? If the IP generator creates the gpio_io_i signal I would
> expect that you can't leave it unconnected as this would lead to
> undefined values.
Normally when you know that you have output only there is no no
gpio_io_i or tristate signal. The same for input only.
>> And
>> also wasting a logic if there is unused part.
>> But in Vivado you should be able to setup output pins to and input pins
>> separately. There are In/Out/Tristate.
>> If you don't want to deal with external pin you can connect them
>> inside PL.
>
> This isn't my point. I mean that if you have an gpio_io_i signal you
> have to connected it to a signal. You could connect it to the output of
> an IO, to the gpio_io_o signal or to fixed value (0 or 1). If you
> connect it to a fixed value (0 or 1) you get this value if you read the
> status of this GPIO.
Not a HW to tell you what's vivado is going to do with that. But you can
select that ouput/input only where these signals are out.
Regarding open drain output.
Also this is what it is written in manual:
"AXI GPIO Data Register Description"
"For each I/O bit programmed as output:
• R: Reads to
Re: [U-Boot] [PATCH 2/9] rockchip: support 4GB DRAM on 32bit systems
On Fri, 2018-07-27 at 00:54 +0200, Dr. Philipp Tomsich wrote: > > On 26 Jul 2018, at 22:05, Carlo Caione wrote: > > > > On Thu, 2018-07-26 at 15:59 +0200, Philipp Tomsich wrote: > > > The calculation in `rockchip_sdram_size` would overflow for 4GB > > > on > > > 32bit systems (i.e. when PHYS_64BIT is not defined). > > > > > > This makes the internal variables and the signature prototype use > > > a > > > u64 to ensure that we can represent the 33rd bit (as in '4GB'). > > > > > > > Hi Philipp, > > just to let you know that this is still not working on the veyron > > jerry > > chromebook with 4GB I have here (RK3288). The boot stops at: > > > > U-Boot SPL 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100) > > Trying to boot from SPI > > > > U-Boot 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100) > > > > Model: Google Jerry > > DRAM: 0 Bytes > > > > I'm still investigating why but for sure there are several points > > to > > fix to have a proper debug, see [0]. > > I reread ‘rockchip_sdram_size’ and it looks as if I forgot to mark > the value > shifted to create chipsize_mb as ULL. When looking at this code I > had an > uneasy feeling that this might run into the C type rules (i.e. 1 will > be a 32bit > integer and shifting it by 32 would result in 0), but I didn’t think > that this > would ever be the case and that any 4GB DRAM setup would be made > up of multiple channels or of multiple ranks. It doesn't hurt but rockchip_sdram_size() is returning the correct value of 0x1 in my tests. -- Carlo Caione ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/32] i.MX: Add i.MX8QXP support
Hi All, I plan to send out V3 early next week. QXP BETA2 has been external released, so there will be update in README including link to scfw images. Paste the link here first: https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-sc-firmware-0.7.bin, use mx8qx-mek-scfw-tcm.bin for b0 chip. Troy, Fabio, Stefano, I would like to still keep CONFIG_IMX8, not CONFIG_MX8. Do you have concerns? Thanks, Peng. > -Original Message- > From: Peng Fan > Sent: 2018年7月18日 9:36 > To: sba...@denx.de; Fabio Estevam > Cc: u-boot@lists.denx.de; dl-linux-imx ; Peng Fan > > Subject: [PATCH V2 00/32] i.MX: Add i.MX8QXP support > > This patchset is to upstream i.MX8QXP and mek board support, with some > drivers update to support i.MX8QXP. The information about the processor could > be found > https://www.nxp.com/products/processors-and-microcontrollers/applications-p > rocessors/i.mx-applications-processors/i.mx-8-processors/i.mx-8x-family-arm-co > rtex-a35-3d-graphics-4k-video-dsp-error-correcting-code-on-ddr:i.MX8X > > The architecture of i.MX8QXP is different from i.MX6/7/8M, inside i.MX8QXP, > there is a dedicated processor(SCU) used for power/clock/pin/ pad/resource > management/thermal and etc. > > V2: > In this V2 patchset, the SCFW API is replaced by uclass driver implementation, > but the api name is not changed from scfw api. > The related macro definitions are kept in different api.h file following SCFW > API > file structure. > > Impelemnted scu misc driver to handle the low level communication between > Acore and SCU. > Implemented rm/pm/pad/misc protocol code to invoke misc_call for different > functionality. > The dm clk/pinctrl/power and others will invokde the protocol api to > communicate with SCU. > > The arch/arm/mach-imx/imx8/clock.c currently is only a dummy file to avoid > build break for mxc_get_clock. > > The i2c patch and common power domain patches are removed from this > patchset. > > The imx8 name still kept, this is because NXP marketing requires to use this > name for i.MX branding. > > Peng Fan (30): > dt-bindings: pinctrl: add i.MX8QXP pads definition > dt-bindings: clock: dt-bindings: pinctrl: add i.MX8QXP clocks > definition > dt-bindings: soc: add i.MX8QXP pm and rsrc definition > imx8: add scfw macro definition > imx: add Kconfig entry for i.MX8QXP > arm: build mach-imx for i.MX8 > misc: add i.MX8 misc driver > misc: imx8: add scfw api impementation > arm: global_data: add scu_dev for i.MX8 > imx: boot_mode: Add FLEXSPI boot entry > imx8: add imx-regs header file > imx8: pins: include i.MX8QXP pin header when CONFIG_IMX8QXP defined > imx: add i.MX8 cpu type > armv8: add cpu core helper functions > imx8: add basic cpu support > imx8: add boot device detection > imx8: implement mmc_get_env_dev > imx8: add mmu and dram related functiions > imx8: add arch_cpu_init arch_cpu_init_dm > imx8: add iomux configuration api > imx8: add dummy clock > gpio: mxc_gpio: add support for i.MX8 > pinctrl: Add pinctrl driver for i.MX8 > power: Add power domain driver for i.MX8 > clk: imx: add clk driver for i.MX8QXP > serial_lpuart: Update lpuart driver to support i.MX8 > serial: lpuart: support uclass clk api > mmc: fsl_esdhc: add uclass clk support > arm: dts: introduce dtsi for i.MX8QXP > imx: add i.MX8QXP MEK board support > > Ye Li (2): > serial: lpuart: Enable RX and TX FIFO > fsl_esdhc: Update usdhc driver to support i.MX8 > > arch/arm/Kconfig | 8 + > arch/arm/Makefile | 2 +- > arch/arm/dts/Makefile | 2 + > arch/arm/dts/fsl-imx8-ca35.dtsi | 66 ++ > arch/arm/dts/fsl-imx8dx.dtsi | 444 + > arch/arm/dts/fsl-imx8dxp.dtsi | 11 + > arch/arm/dts/fsl-imx8qxp-mek.dts | 136 > arch/arm/dts/fsl-imx8qxp.dtsi | 51 ++ > arch/arm/include/asm/arch-imx/cpu.h | 5 + > arch/arm/include/asm/arch-imx8/clock.h| 27 + > arch/arm/include/asm/arch-imx8/gpio.h | 21 + > arch/arm/include/asm/arch-imx8/imx-regs.h | 46 ++ > arch/arm/include/asm/arch-imx8/imx8-pins.h| 15 + > arch/arm/include/asm/arch-imx8/iomux.h| 40 ++ > arch/arm/include/asm/arch-imx8/power-domain.h | 15 + > arch/arm/include/asm/arch-imx8/sci/rpc.h | 159 + > arch/arm/include/asm/arch-imx8/sci/sci.h | 86 +++ > arch/arm/include/asm/arch-imx8/sci/svc/misc/api.h | 30 + > arch/arm/include/asm/arch-imx8/sci/svc/pad/api.h | 57 ++ > arch/arm/include/asm/arch-imx8/sci/svc/pm/api.h | 44 ++ > arch/arm/include/asm/arch-imx8/sci/svc/rm/api.h | 69 ++ > arch/arm/include/asm/arch-imx8/sci/types.h| 220 +++ > arch/arm/include/asm/arch-imx8/sys_proto.h| 19 + > arch/arm/include/asm/armv8/cpu.h | 26 + > arch/arm/include/asm/g
Re: [U-Boot] [PATCH v5] u-boot: remove driver lookup loop from env_save()
Hi Tom, On gio, 2018-07-26 at 20:29 -0400, Tom Rini wrote: > On Thu, Jul 26, 2018 at 10:16:01PM +0200, Goldschmidt Simon wrote: > > > > > + Tom: > > > > I don't know via which tree this would go in. I think you took the > > last env > > changes directly? > > > > v1..v4 are detached threads, I can send you links if you need them. > It's on my TODO list to pick up, thanks! > Thanks. I apologize for the detached threads, I was not very familiar with patman. Here links of the other threads if needed: v1: https://lists.denx.de/pipermail/u-boot/2018-July/334199.html v2: https://lists.denx.de/pipermail/u-boot/2018-July/334445.html v3: https://lists.denx.de/pipermail/u-boot/2018-July/334538.html v4: https://lists.denx.de/pipermail/u-boot/2018-July/334589.html ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] env: Include bootdelay in environment if negative
On Fri, Jul 27, 2018 at 1:26 AM Tom Rini wrote: > > On Thu, Jul 26, 2018 at 09:31:08AM +0100, Alex Kiernan wrote: > > On Fri, Jul 20, 2018 at 11:34 PM Tom Rini wrote: > > > > > > On Thu, Jul 05, 2018 at 12:38:15PM +, Alex Kiernan wrote: > > > > > > > The test for (CONFIG_BOOTDELAY >= 0) has been in U-Boot since the > > > > beginning, but the meaning of it has changed over time. Allow the > > > > default to be set for any value, including -ve ones. This allows > > > > (for example) CONFIG_ENV_IS_NOWHERE to have values for bootdelay in > > > > its compiled in environment. > > > > > > > > The only thing this changes is where the default for bootdelay can be > > > > fetched from; before this change you get a compiled in default, after > > > > you'll pull it from the default value in the environment, but both > > > > values > > > > will be the same. Also if there's a value set in the environment then > > > > that will take precedence (as before). > > > > > > > > Signed-off-by: Alex Kiernan > > > > > > Applied to u-boot/master, thanks! > > > > > > > I've just realised that if you had an existing hardcoded bootdelay= to > > cover the case where it wasn't being inserted through env_defaults you > > would now end up with two. > > > > However checking there's 6 boards (9 configs) which possibly have this > > problem, but none of them have a -ve value for CONFIG_BOOTDELAY. If I > > revert this change and then grep out bootdelay from the generated > > environments for those configs, 7 have duplicates before this change > > (the last two are odroid-c2 and odroid-xu3 which are fine): > > > > cl-som-am57x/uboot.env: bootdelay=2 > > cl-som-am57x/uboot.env: bootdelay=3 > > cm_t54/uboot.env: bootdelay=3 > > cm_t54/uboot.env: bootdelay=3 > > display5_factory/uboot.env: bootdelay=3 > > display5_factory/uboot.env: bootdelay=1 > > display5/uboot.env: bootdelay=2 > > display5/uboot.env: bootdelay=1 > > nas220/uboot.env: bootdelay=3 > > nas220/uboot.env: bootdelay=-1 > > odroid/uboot.env: bootdelay=2 > > odroid/uboot.env: bootdelay=0 > > vinco/uboot.env: bootdelay=3 > > vinco/uboot.env: bootdelay=0 > > Ah, good catch. In the end, it's probably OK. > I guess last match will win, so you end up with what you've put in your board file, which is likely what's intended. > > I don't think there's anything here for me to fix up, but the > > maintainers of those boards probably want to figure out which of the > > bootdelay values they wanted. > > > > I wonder if we want some QA process off the end of the build (or in > > buildman?) which verifies the extracted environment for duplicate > > entries. > > That would be a great addition to buildman, yes. > Have we got any warning machinery in buildman? I can only find stuff which is reporting warnings from the tools, not from itself. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
On Thu, 2018-07-26 at 12:29 +0200, Michal Simek wrote:
> On 26.7.2018 11:23, Chee, Tien Fong wrote:
> >
> > On Wed, 2018-07-25 at 11:48 +0200, Michal Simek wrote:
> > >
> > > On 25.7.2018 08:31, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek wrote:
> > > > >
> > > > >
> > > > > On 6.7.2018 10:28, tien.fong.c...@intel.com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: Tien Fong Chee
> > > > > >
> > > > > > This is file system generic loader which can be used to
> > > > > > load
> > > > > > the file image from the storage into target such as memory.
> > > > > > The consumer driver would then use this loader to program
> > > > > > whatever,
> > > > > > ie. the FPGA device.
> > > > > >
> > > > > > Signed-off-by: Tien Fong Chee
> > > > > > ---
> > > > > > drivers/misc/Kconfig | 10 ++
> > > > > > drivers/misc/Makefile| 1 +
> > > > > > drivers/misc/fs_loader.c | 295
> > > > > > +++
> > > > > > include/dm/uclass-id.h | 1 +
> > > > > > include/fs_loader.h | 79 +
> > > > > > 5 files changed, 386 insertions(+)
> > > > > > create mode 100644 drivers/misc/fs_loader.c
> > > > > > create mode 100644 include/fs_loader.h
> > > > > >
> > > > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > > > > index 17b3a80..4163b4f 100644
> > > > > > --- a/drivers/misc/Kconfig
> > > > > > +++ b/drivers/misc/Kconfig
> > > > > > @@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
> > > > > > depends on MISC
> > > > > > help
> > > > > > Support gdsys FPGA's RXAUI control.
> > > > > > +
> > > > > > +config FS_LOADER
> > > > > > + bool "Enable loader driver for file system"
> > > > > > + help
> > > > > > + This is file system generic loader which can be
> > > > > > used
> > > > > > to
> > > > > > load
> > > > > > + the file image from the storage into target such
> > > > > > as
> > > > > > memory.
> > > > > > +
> > > > > > + The consumer driver would then use this loader
> > > > > > to
> > > > > > program whatever,
> > > > > > + ie. the FPGA device.
> > > > > > +
> > > > > > endmenu
> > > > > > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > > > > > index 4ce9d21..67a36f8 100644
> > > > > > --- a/drivers/misc/Makefile
> > > > > > +++ b/drivers/misc/Makefile
> > > > > > @@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
> > > > > > obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
> > > > > > obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
> > > > > > obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
> > > > > > +obj-$(CONFIG_FS_LOADER) += fs_loader.o
> > > > > > diff --git a/drivers/misc/fs_loader.c
> > > > > > b/drivers/misc/fs_loader.c
> > > > > > new file mode 100644
> > > > > > index 000..5fe642b
> > > > > > --- /dev/null
> > > > > > +++ b/drivers/misc/fs_loader.c
> > > > > > @@ -0,0 +1,295 @@
> > > > > > +/*
> > > > > > + * Copyright (C) 2018 Intel Corporation
> > > > > > + *
> > > > > > + * SPDX-License-Identifier:GPL-2.0
> > > > > > + */
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +
> > > > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > > > +
> > > > > > +struct firmware_priv {
> > > > > > + const char *name; /* Filename */
> > > > > > + u32 offset; /* Offset of reading a
> > > > > > file
> > > > > > */
> > > > > > +};
> > > > > > +
> > > > > > +#ifdef CONFIG_CMD_UBIFS
> > > > > > +static int mount_ubifs(char *mtdpart, char *ubivol)
> > > > > > +{
> > > > > > + int ret = ubi_part(mtdpart, NULL);
> > > > > > +
> > > > > > + if (ret) {
> > > > > > + debug("Cannot find mtd partition %s\n",
> > > > > > mtdpart);
> > > > > > + return ret;
> > > > > > + }
> > > > > > +
> > > > > > + return cmd_ubifs_mount(ubivol);
> > > > > > +}
> > > > > > +
> > > > > > +static int umount_ubifs(void)
> > > > > > +{
> > > > > > + return cmd_ubifs_umount();
> > > > > > +}
> > > > > > +#else
> > > > > > +static int mount_ubifs(char *mtdpart, char *ubivol)
> > > > > > +{
> > > > > > + debug("Error: Cannot load image: no UBIFS
> > > > > > support\n");
> > > > > > + return -ENOSYS;
> > > > > > +}
> > > > > > +#endif
> > > > > > +
> > > > > > +static int select_fs_dev(struct device_platdata *plat)
> > > > > > +{
> > > > > > + int ret;
> > > > > > +
> > > > > > + if (plat->phandlepart.phandle) {
> > > > > > + ofnode node;
> > > > > > +
> > > > > > + node = ofnode_get_by_phandle(plat-
> > > > > > >
> > > > > > >
> > > > > > > phandlepart.phandle);
> > > > > > +
> > > > > > + int of_offset = ofnode_to_offset(node);
> > > > > > +
> > > > > > + struct udevice *dev;
> > > > > > +
> > > > > > + ret =
> > > > > > device_get_global_by_of_offset(o
Re: [U-Boot] [PATCH v1 9/9] ARM: Odroid XU3: Modify Odroid XU3 config to boot by default from SD card
On Fri, 27 Jul 2018 08:34:15 +0530 Anand Moon wrote: > Hi Lukasz, > > On 26 July 2018 at 21:23, Lukasz Majewski wrote: > > Hi Anand, > > > >> Hi Lukasz, > >> > >> On 26 July 2018 at 03:55, Lukasz Majewski wrote: > >> > This commit allows by default booting Odroid XU3 from the SD card > >> > (when e.g. eMMC module is not present). > >> > > >> > Signed-off-by: Lukasz Majewski > >> > > >> > --- > >> > > >> > include/configs/odroid_xu3.h | 7 +-- > >> > 1 file changed, 5 insertions(+), 2 deletions(-) > >> > > >> > diff --git a/include/configs/odroid_xu3.h > >> > b/include/configs/odroid_xu3.h index f495f6219ba9..818a06515cb2 > >> > 100644 --- a/include/configs/odroid_xu3.h > >> > +++ b/include/configs/odroid_xu3.h > >> > @@ -94,6 +94,9 @@ > >> > #undef CONFIG_SYS_BOARD > >> > #define CONFIG_SYS_BOARD "odroid" > >> > > >> > +#undef CONFIG_SYS_MMC_ENV_DEV > >> > +#define CONFIG_SYS_MMC_ENV_DEV 2 > >> > + > >> > /* Define new extra env settings, including DFU settings */ > >> > #undef CONFIG_EXTRA_ENV_SETTINGS > >> > #define CONFIG_EXTRA_ENV_SETTINGS \ > >> > @@ -105,8 +108,8 @@ > >> > "console=" CONFIG_DEFAULT_CONSOLE "\0"\ > >> > "fdtfile=exynos5422-odroidxu3.dtb\0" \ > >> > "boardname=odroidxu3\0" \ > >> > - "mmcbootdev=0\0" \ > >> > - "mmcrootdev=0\0" \ > >> > + "mmcbootdev=2\0" \ > >> > + "mmcrootdev=1\0" \ > >> > "mmcbootpart=1\0" \ > >> > "mmcrootpart=2\0" \ > >> > "dfu_alt_system="CONFIG_DFU_ALT_SYSTEM \ > >> > -- > >> > 2.11.0 > >> > > >> > >> This changes probably breaks the booting from eMMC on Odroid-XU4 > > > > I suppose, that XU4 is also equipped with SD card slot as XU3. > > > > Nonetheless, as I don't have eMMC card for mine XU3, the only way to > > boot my device is SD card. > > > > If you believe that this may be a problem, then I can drop this > > patch. > > > > Have you checked patches from 1-8? > > Does it work for you? If yes, please send tested-by tag. > > > > Yes you probably need to drop this patch, > I had some tough time recovering my eMMC back to flash new u-boot. > > I have tested my eMMC with default boot.scr its boot good. > Need to modify the boot.scr to boot into SD card. SD card has different layout than eMMC. Despite above - you just shall need to apply patch 9/9 to get the board running from SD card. > > Best Regards > -Anand 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-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgpG_2wGHla6T.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 v4 6/6] common: Generic loader for file system
On Thu, 2018-07-26 at 11:03 +0200, Michal Simek wrote:
> On 25.7.2018 18:03, Tom Rini wrote:
> >
> > On Wed, Jul 25, 2018 at 09:47:17AM -0600, Simon Glass wrote:
> > >
> > > Hi,
> > >
> > > On 25 July 2018 at 03:48, Michal Simek
> > > wrote:
> > > >
> > > >
> > > > On 25.7.2018 08:31, Chee, Tien Fong wrote:
> > > > >
> > > > > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek wrote:
> > > > > >
> > > > > > On 6.7.2018 10:28, tien.fong.c...@intel.com wrote:
> > > > > > >
> > > > > > >
> > > > > > > From: Tien Fong Chee
> > > > > > >
> > > [...]
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > Also that DT binding is quite weird and I don't think you
> > > > > > will get
> > > > > > ACK
> > > > > > for this from device tree community at all. I think that
> > > > > > calling via
> > > > > > platdata and avoid DT nodes would be better way to go.
> > > > > Why do you think DT binding is weird? The DT is designed
> > > > > based on Simon
> > > > > proposal, and i believe following the rules in DTS spec.
> > > > > There are some DT benefits with current design, i think
> > > > > someone may be
> > > > > maintainer need to made the final decision on the design.
> > > > It is software configuration in file which should mostly
> > > > describe
> > > > hardware and state for hardware configuration.
> > > >
> > > > Your fs_loader node is purely describe sw configuration which
> > > > shouldn't
> > > > be here.
> > > > You have there run time configuration via variables. I think
> > > > using only
> > > > this way is enough. Default variables will match what you would
> > > > want to
> > > > add to DT.
> > > I think DT makes sense in the U-Boot context.
> > >
> > > We don't have a user space to handle policy decisions, and the
> > > 'chosen' node is a good place to configure these common features.
> > >
> > > While you can argue that the partition or filesystem where an
> > > image
> > > comes from is a software config, it is something that has to be
> > > configured. It has impact on hardware too, since the FPGA has to
> > > get
> > > its firmware from somewhere. We use the chosen node to specify
> > > the
> > > UART to use, and this is no different. Again, we don't have user-
> > > space
> > > config files in U-Boot.
> > >
> > > This argument comes up from time to time and I'd really like to
> > > put it
> > > to bed for U-Boot. I understand that Linux has its own approach
> > > and
> > > rules, but in some cases they serve U-Boot poorly.
> > I want to second this as well. So long as we're using our prefix
> > and
> > we've thought through and discussed what we're trying to do here,
> > it's
> > OK to do things that might not be accepted for Linux.
> >
> I have not a problem with using chosen node with u-boot prefix
> properties and my colleague hopefully with finish work about moving
> u-boot,dm-pre-reloc; to chosen node where it should be (because
> current
> solution has also problem with ordering).
>
> In this loader case doc is saying that you can rewrite it with
> variables
> on the prompt (or via script).
> For cases that you want to autodetect platform and pass/load correct
> dtb
> which setup u-boot this can be problematic and using DT is could be
> considered as easier for use.
>
> In this case this is what was proposed:
>
> + fs_loader0: fs-loader@0 {
> + u-boot,dm-pre-reloc;
> + compatible = "u-boot,fs-loader";
> + phandlepart = <&mmc 1>;
> + };
>
> + fs_loader1: fs-loader@1 {
> + u-boot,dm-pre-reloc;
> + compatible = "u-boot,fs-loader";
> + mtdpart = "UBI",
> + ubivol = "ubi0";
> + };
>
> u-boot,dm-pre-reloc; requires DM_FLAG_PRE_RELOC which is not setup
> for
> this driver - it means this should be here.
You are right, i missed this one. The intention of design enables user
to call any loader with default storage through the sequence number if
fs loader is not defined in chosen. For example, there is a case where
system loading the file from SDMMC, NAND and QSPI.
>
> compatible = "u-boot,fs-loader"; - bind and probe are empty that's
> why
> this is only used for filling platdata but driver has no user that's
> why
> this is unused till someone calls that functions.
>
> phandlepart/mtdpart/ubivol is just for setup.
There are some benefits with driver model:
1. Saving space, calling when need.
2. Handle memory allocation and deallocation automatically.
>
> For the first case you can just use in chosen node:
> u-boot,fs-loader = <&mmc 1>;
>
> And for UBIfs. I have never played with that but I expect it
> shouldn't
> be big problem to describe it differently too (something like)
> u-boot,fs-loader = <0 ubi0>;
Need consider description for UBIFS, using fs-loader seems not working
for UBIFS, since more arguments such as mtdpartition and mtd volume
need passing into driver. In order to avoid messing, fs_loader can act
the pointer to the chosen.
Anyway, i have no strong
Re: [U-Boot] [PATCH 3/4] gpio: xilinx: Not read output values via regs
Am 27.07.2018 um 09:05 schrieb Michal Simek:
On 26.7.2018 21:46, Stefan Herbrechtsmeier wrote:
Am 26.07.2018 um 10:41 schrieb Michal Simek:
On 25.7.2018 20:21, Stefan Herbrechtsmeier wrote:
Am 25.07.2018 um 08:39 schrieb Michal Simek:
On 24.7.2018 21:56, Stefan Herbrechtsmeier wrote:
Am 24.07.2018 um 12:31 schrieb Michal Simek:
On 23.7.2018 20:42, Stefan Herbrechtsmeier wrote:
Am 23.07.2018 um 13:43 schrieb Michal Simek:
Reading registers for finding out output value is not working
because
input value is read instead in case of tristate.
Reported-by: Stefan Herbrechtsmeier
Signed-off-by: Michal Simek
---
drivers/gpio/xilinx_gpio.c | 38
+-
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/xilinx_gpio.c
b/drivers/gpio/xilinx_gpio.c
index 4da9ae114d87..9d3e9379d0e5 100644
--- a/drivers/gpio/xilinx_gpio.c
+++ b/drivers/gpio/xilinx_gpio.c
[snip]
+ priv->output_val[bank] = val;
+
return val;
};
@@ -441,6 +449,7 @@ static int xilinx_gpio_get_function(struct
udevice *dev, unsigned offset)
static int xilinx_gpio_get_value(struct udevice *dev, unsigned
offset)
{
struct xilinx_gpio_platdata *platdata =
dev_get_platdata(dev);
+ struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
int val, ret;
u32 bank, pin;
@@ -451,7 +460,14 @@ static int xilinx_gpio_get_value(struct
udevice
*dev, unsigned offset)
debug("%s: regs: %lx, gpio: %x, bank %x, pin %x\n",
__func__,
(ulong)platdata->regs, offset, bank, pin);
- val = readl(&platdata->regs->gpiodata + bank * 2);
+ if (xilinx_gpio_get_function(dev, offset) == GPIOF_INPUT) {
+ debug("%s: Read input value from reg\n", __func__);
+ val = readl(&platdata->regs->gpiodata + bank * 2);
+ } else {
+ debug("%s: Read saved output value\n", __func__);
+ val = priv->output_val[bank];
+ }
Why you don't always read the data register? This doesn't work for
three
state outputs.
In three state register every bit/pin is 0 - output, 1 input.
It means else part is output and I read saved value in
priv->output_val.
If pin is setup as INPUT then I need read data reg to find out input
value.
Maybe you are commenting something else but please let me know if
there
is any other bug.
What happen if I have an open drain output. Even if the gpio output
is 1
the input could read a 0. You driver will always return the output
value
and not the real input value. According to the picture in
documentation
and my tests a data register write writes the output registers and a
data register read reads the input registers.
Why should the driver return the desired state (output register)
and not
the real state (input register)?
First of all thanks for description.
I have another example where you have output only and you can't read
input because there is no wire.
Does you mean the all outputs configuration? Does this removes the
"gpio_io_i" signal from the IP?
I am not sure what synthesis is doing with that unused IP pins but I
would consider as a bug if this is automatically connected together.
I mean does the IP generator removes the gpio_io_i signal because it
isn't needed? If the IP generator creates the gpio_io_i signal I would
expect that you can't leave it unconnected as this would lead to
undefined values.
Normally when you know that you have output only there is no no
gpio_io_i or tristate signal. The same for input only.
And in this case the device tree flags "xlnx,all-inputs" or
"xlnx,all-outputs" should be set.
And
also wasting a logic if there is unused part.
But in Vivado you should be able to setup output pins to and input pins
separately. There are In/Out/Tristate.
If you don't want to deal with external pin you can connect them
inside PL.
This isn't my point. I mean that if you have an gpio_io_i signal you
have to connected it to a signal. You could connect it to the output of
an IO, to the gpio_io_o signal or to fixed value (0 or 1). If you
connect it to a fixed value (0 or 1) you get this value if you read the
status of this GPIO.
Not a HW to tell you what's vivado is going to do with that. But you can
select that ouput/input only where these signals are out.
You mean the all-inputs or all-outputs case.
Regarding open drain output.
Also this is what it is written in manual:
"AXI GPIO Data Register Description"
"For each I/O bit programmed as output:
• R: Reads to these bits always return zeros"
This must be a mistake in the documentation. I could read the input
value.
The old driver and the Linux driver always read the register.
In old u-boot driver I see
179 if (gpio_get_direction(gpio) == GPIO_DIRECTION_OUT)
180 val = gpio_get_output_value(gpio);
181 else
182 val = gpio_get_input_value(gpio);
gpio_get_output_value() reads it from gpiodata_store for output
gpio_get_in
[U-Boot] [PATCH] arm: zynq: dts: add spi flash node to zedboard
Add a flash node to fix the detection of the memory IC.
With the changes introduced with commit 8fee8845e754
("enf_sf: reuse setup_flash_device instead of open coding it")
the SPI speed is now read from device-tree or a default value
is applied. This replaced the old behavior of setting the
SPI speed to CONFIG_ENV_SPI_MAX_HZ.
As this board didn't have a flash node, the default value
was applied to the SPI speed, producing an error when probing
the flash memory (speed too slow).
Signed-off-by: Luis Araneda
---
arch/arm/dts/zynq-zed.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/zynq-zed.dts b/arch/arm/dts/zynq-zed.dts
index 24eccf1633..9c505fb7b8 100644
--- a/arch/arm/dts/zynq-zed.dts
+++ b/arch/arm/dts/zynq-zed.dts
@@ -51,6 +51,13 @@
&qspi {
u-boot,dm-pre-reloc;
status = "okay";
+ num-cs = <1>;
+ flash@0 {
+ compatible = "spansion,s25fl256s", "spi-flash";
+ reg = <0>;
+ spi-max-frequency = <3000>;
+ m25p,fast-read;
+ };
};
&sdhci0 {
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] enable fpga loadfs
On Thu, 2018-07-26 at 10:10 +0200, Marek Vasut wrote:
> On 07/26/2018 09:54 AM, tien.fong.c...@intel.com wrote:
> >
> > From: Tien Fong Chee
> >
> > Signed-off-by: Tien Fong Chee
> > ---
> > arch/arm/dts/socfpga_arria10.dtsi| 12
> > arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts |6 ++
> > configs/socfpga_arria10_defconfig| 12
> > 3 files changed, 30 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/dts/socfpga_arria10.dtsi
> > b/arch/arm/dts/socfpga_arria10.dtsi
> > index b51febd..45aef6a 100644
> > --- a/arch/arm/dts/socfpga_arria10.dtsi
> > +++ b/arch/arm/dts/socfpga_arria10.dtsi
> > @@ -48,6 +48,12 @@
> > <0xc100 0x100>;
> > };
> >
> > + fs_loader0: fs-loader@0 {
> > + u-boot,dm-pre-reloc;
> > + compatible = "u-boot,fs-loader";
> > + phandlepart = <&mmc 1>;
> Which hardware does this describe ?
> DT is hardware description ...
I agree with Simon, it still describes some hardware information
required for this whole mechanism to work although this pointer is not
represent a real hardware.
>
> >
> > + };
> [...]
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] rockchip: support 4GB DRAM on 32bit systems
> On 27 Jul 2018, at 09:50, Carlo Caione wrote: > > On Fri, 2018-07-27 at 00:54 +0200, Dr. Philipp Tomsich wrote: >>> On 26 Jul 2018, at 22:05, Carlo Caione wrote: >>> >>> On Thu, 2018-07-26 at 15:59 +0200, Philipp Tomsich wrote: The calculation in `rockchip_sdram_size` would overflow for 4GB on 32bit systems (i.e. when PHYS_64BIT is not defined). This makes the internal variables and the signature prototype use a u64 to ensure that we can represent the 33rd bit (as in '4GB'). >>> >>> Hi Philipp, >>> just to let you know that this is still not working on the veyron >>> jerry >>> chromebook with 4GB I have here (RK3288). The boot stops at: >>> >>> U-Boot SPL 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100) >>> Trying to boot from SPI >>> >>> U-Boot 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100) >>> >>> Model: Google Jerry >>> DRAM: 0 Bytes >>> >>> I'm still investigating why but for sure there are several points >>> to >>> fix to have a proper debug, see [0]. >> >> I reread ‘rockchip_sdram_size’ and it looks as if I forgot to mark >> the value >> shifted to create chipsize_mb as ULL. When looking at this code I >> had an >> uneasy feeling that this might run into the C type rules (i.e. 1 will >> be a 32bit >> integer and shifting it by 32 would result in 0), but I didn’t think >> that this >> would ever be the case and that any 4GB DRAM setup would be made >> up of multiple channels or of multiple ranks. > > It doesn't hurt but rockchip_sdram_size() is returning the correct > value of 0x1 in my tests. The 'gd->bd->bi_dram[i].size’ path will also be involved and truncate this later on, but I am not convinced that it’s worth fixing the dram banks info for the general case. Generally, typing for these bi_dram structures seems a mess: they are often cast to 32bit and sometimes to 64bit in common code (i.e. fdtdec.c uses unsigned long long). I hope I can avoid touching this code. Btw, here’s a gem from board_f.c (these two lines are after each other): > gd->ram_top = gd->ram_base + get_effective_memsize(); > gd->ram_top = board_get_usable_ram_top(gd->mon_len); As the first line is clearly deal (except the fact that the compiler can’t tell that get_effective_memsize() should be side-effect free), we can drop it. I’ll send a separate patch for this to be picked up by Tom… —Phil. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 9/9] ARM: Odroid XU3: Modify Odroid XU3 config to boot by default from SD card
Hi Lukasz, On 27 July 2018 at 13:54, Lukasz Majewski wrote: > On Fri, 27 Jul 2018 08:34:15 +0530 > Anand Moon wrote: > >> Hi Lukasz, >> >> On 26 July 2018 at 21:23, Lukasz Majewski wrote: >> > Hi Anand, >> > >> >> Hi Lukasz, >> >> >> >> On 26 July 2018 at 03:55, Lukasz Majewski wrote: >> >> > This commit allows by default booting Odroid XU3 from the SD card >> >> > (when e.g. eMMC module is not present). >> >> > >> >> > Signed-off-by: Lukasz Majewski >> >> > >> >> > --- >> >> > >> >> > include/configs/odroid_xu3.h | 7 +-- >> >> > 1 file changed, 5 insertions(+), 2 deletions(-) >> >> > >> >> > diff --git a/include/configs/odroid_xu3.h >> >> > b/include/configs/odroid_xu3.h index f495f6219ba9..818a06515cb2 >> >> > 100644 --- a/include/configs/odroid_xu3.h >> >> > +++ b/include/configs/odroid_xu3.h >> >> > @@ -94,6 +94,9 @@ >> >> > #undef CONFIG_SYS_BOARD >> >> > #define CONFIG_SYS_BOARD "odroid" >> >> > >> >> > +#undef CONFIG_SYS_MMC_ENV_DEV >> >> > +#define CONFIG_SYS_MMC_ENV_DEV 2 >> >> > + >> >> > /* Define new extra env settings, including DFU settings */ >> >> > #undef CONFIG_EXTRA_ENV_SETTINGS >> >> > #define CONFIG_EXTRA_ENV_SETTINGS \ >> >> > @@ -105,8 +108,8 @@ >> >> > "console=" CONFIG_DEFAULT_CONSOLE "\0"\ >> >> > "fdtfile=exynos5422-odroidxu3.dtb\0" \ >> >> > "boardname=odroidxu3\0" \ >> >> > - "mmcbootdev=0\0" \ >> >> > - "mmcrootdev=0\0" \ >> >> > + "mmcbootdev=2\0" \ >> >> > + "mmcrootdev=1\0" \ >> >> > "mmcbootpart=1\0" \ >> >> > "mmcrootpart=2\0" \ >> >> > "dfu_alt_system="CONFIG_DFU_ALT_SYSTEM \ >> >> > -- >> >> > 2.11.0 >> >> > >> >> >> >> This changes probably breaks the booting from eMMC on Odroid-XU4 >> > >> > I suppose, that XU4 is also equipped with SD card slot as XU3. >> > >> > Nonetheless, as I don't have eMMC card for mine XU3, the only way to >> > boot my device is SD card. >> > >> > If you believe that this may be a problem, then I can drop this >> > patch. >> > >> > Have you checked patches from 1-8? >> > Does it work for you? If yes, please send tested-by tag. >> > >> >> Yes you probably need to drop this patch, >> I had some tough time recovering my eMMC back to flash new u-boot. >> >> I have tested my eMMC with default boot.scr its boot good. >> Need to modify the boot.scr to boot into SD card. > > SD card has different layout than eMMC. > > Despite above - you just shall need to apply patch 9/9 to get the board > running from SD card. > Actually SD card are easy to modify and tune with just adding setenv mmcrootdev "1" to autoboot.cmd from sdcard. but with eMMC module it's bit difficult to make this work, even if we modify the autoboot.cmd and with new boot.scr changes do not work out. I have hard time to recover my eMMC module to boot again. well I have to boot from SD card with eMMC attach and then flash the new bootloader to eMMC to make this work. best regards -Anand ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name
Am 27.07.2018 um 08:42 schrieb Michal Simek: On 26.7.2018 22:04, Stefan Herbrechtsmeier wrote: Am 26.07.2018 um 10:22 schrieb Michal Simek: On 25.7.2018 21:17, Stefan Herbrechtsmeier wrote: Am 25.07.2018 um 08:07 schrieb Michal Simek: On 24.7.2018 21:39, Stefan Herbrechtsmeier wrote: Am 24.07.2018 um 10:37 schrieb Michal Simek: On 23.7.2018 20:29, Stefan Herbrechtsmeier wrote: Am 23.07.2018 um 11:08 schrieb Michal Simek: On 20.7.2018 21:31, Stefan Herbrechtsmeier wrote: Am 12.07.2018 um 16:04 schrieb Michal Simek: There should be proper bank name setup to distiguish between different gpio drivers. Use dev->name for it. Signed-off-by: Michal Simek --- drivers/gpio/zynq_gpio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c index 26f69b1a713f..f793ee5754a8 100644 --- a/drivers/gpio/zynq_gpio.c +++ b/drivers/gpio/zynq_gpio.c @@ -337,6 +337,8 @@ static int zynq_gpio_probe(struct udevice *dev) struct zynq_gpio_privdata *priv = dev_get_priv(dev); struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev); + uc_priv->bank_name = dev->name; + if (priv->p_data) uc_priv->gpio_count = priv->p_data->ngpio; Does this not lead to ugly names because the gpio number is append to the bank_name? Have you check the "gpio status -a" output? Yes I was checking it. Names are composed together but also just numbers works as before. gpio@ff0a0: input: 0 [ ] gpio@ff0a1: input: 0 [ ] gpio@ff0a2: input: 0 [ ] gpio@ff0a3: input: 0 [ ] gpio@ff0a4: input: 0 [ ] gpio@ff0a5: input: 0 [ ] gpio@ff0a6: input: 0 [ ] gpio@ff0a7: input: 0 [ ] gpio@ff0a8: input: 0 [ ] gpio@ff0a9: input: 0 [ ] Do you think that this are meaningful names? It isn't possible to separate the device and pin number as well as it mix hex and decimal numbers. If you know better way how to setup a bank name please let me know but I need to distinguish ps gpio from pl one and for pl we need to know the address. I know the use case. A lot of drivers use the bank_name from the device tree, some drivers append an underscore to the bank name and others add the req_seq of the device to an alphabetic character. Other drivers use the gpio-bank-name from the device tree. I can't see this property inside Linux kernel. If this has been reviewed by dt guys please let me know. This property is only used by u-boot. I think it isn't needed by the Linux kernel. I am happy to use consistent solution but what's that? Consistent solution between what? all drivers. Name should be composed consistently among all drivers. It means drivers shouldn't add additional "_" in driver code for example. Mixing name with hex and int is not nice but adding "_" or something else is just a pain in driver code. If this is done in core I am fine with that but adding this code to all drivers don't look like generic solution at all. Normally the bank name is an alphabetic character or string. Maybe we could add the device name to the gpio_lookup_name function and add an additional optional device name parameter to the gpio command. Using additional u-boot property is not good too. I have mentioned in "gpio: xilinx: Convert driver to DM" (sha1:10441ec9224d0d269dc512819a32c0785a6338d3) that uc-priv->name is completely unused. Maybe this should be dev->name and bank_name should be really used for banks. Isn't the uc-priv->name used for the label of the request? Last time when I looked at it and I didn't see this name listed anywhere in output. Then in gpio status -a can be Device gpio@a0001000: Bank: ... but not sure how gpio commands will work to address exact pin from prompt. Because this is normally working gpio toggle gpio@a00010001 With an optional device name this would be: gpio toggle gpio@a0001000 1 Alternative the gpio command could support the requested labels: gpio toggle second-gpio I am open to see this solution. Feel free to invest your time support this but I have no time for that. What does this mean? I understand that you don't have the time to develop a new common solution. But the discussion disappoints me. You misuse the bank name in a poor way and decline alternative solutions with additional requirements even if they are already used in u-boot. The name "gpio@a000100011" for pin 11 of the device gpio@a0001000 isn't consistent between the u-boot drivers nor is the name used in Linux. A bank-name from the device tree is used by several u-boot drivers even if it isn't consistent between the drivers. I am sorry that you feel like that. It is not about declining alternative solution. I want to know what's the right solution is. Thanks a lot for taking the time to write a detail explanation. Using bank-name/gpio-bank-name via DT is something what is IMHO not correct. The first thing is if this is used just by u-boot it should have at least u-boot prefix. It means u-boot,b
[U-Boot] [PATCH] board_f: drop 'dead code' in ram_top computation
gd->ram_top is assigned to twice on consecutive lines and the compiler
won't be able to tell that the first assignment is dead (including its
r-value) due to the r-value containing a (side-effect free) function
call.
This drops the first assignment.
Signed-off-by: Philipp Tomsich
---
common/board_f.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index 88d7700..1b8a003 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -283,7 +283,6 @@ static int setup_dest_addr(void)
#ifdef CONFIG_SYS_SDRAM_BASE
gd->ram_base = CONFIG_SYS_SDRAM_BASE;
#endif
- gd->ram_top = gd->ram_base + get_effective_memsize();
gd->ram_top = board_get_usable_ram_top(gd->mon_len);
gd->relocaddr = gd->ram_top;
debug("Ram top: %08lX\n", (ulong)gd->ram_top);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board_f: drop 'dead code' in ram_top computation
On Fri, Jul 27, 2018 at 5:16 PM, Philipp Tomsich wrote: > gd->ram_top is assigned to twice on consecutive lines and the compiler > won't be able to tell that the first assignment is dead (including its > r-value) due to the r-value containing a (side-effect free) function > call. > > This drops the first assignment. > > Signed-off-by: Philipp Tomsich > --- > > common/board_f.c | 1 - > 1 file changed, 1 deletion(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board_f: drop 'dead code' in ram_top computation
> On 27 Jul 2018, at 11:16, Philipp Tomsich
> wrote:
>
> gd->ram_top is assigned to twice on consecutive lines and the compiler
> won't be able to tell that the first assignment is dead (including its
> r-value) due to the r-value containing a (side-effect free) function
> call.
>
> This drops the first assignment.
>
> Signed-off-by: Philipp Tomsich
> ---
>
> common/board_f.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/common/board_f.c b/common/board_f.c
> index 88d7700..1b8a003 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -283,7 +283,6 @@ static int setup_dest_addr(void)
> #ifdef CONFIG_SYS_SDRAM_BASE
> gd->ram_base = CONFIG_SYS_SDRAM_BASE;
> #endif
> - gd->ram_top = gd->ram_base + get_effective_memsize();
> gd->ram_top = board_get_usable_ram_top(gd->mon_len);
> gd->relocaddr = gd->ram_top;
> debug("Ram top: %08lX\n", (ulong)gd->ram_top);
> --
> 2.1.4
>
Oh my, I’ll need to revise, as board_get_usable_ram_top is implemented as
follows:
> /* Get the top of usable RAM */
> __weak ulong board_get_usable_ram_top(ulong total_size)
> {
> #ifdef CONFIG_SYS_SDRAM_BASE
> /*
> * Detect whether we have so much RAM that it goes past the end of
> our
> * 32-bit address space. If so, clip the usable RAM so it doesn't.
>
> */
> if (gd->ram_top < CONFIG_SYS_SDRAM_BASE)
> /*
> * Will wrap back to top of 32-bit space when reservations
>
> * are made.
>
> */
> return 0;
> #endif
> return gd->ram_top;
> }
I.e. it consumes the previous value of gd->ram_top and ignores its argument.
I’ll clean this up before someone else falls into the same pit.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] musb-new startup timeout
We've been chasing a problem for a while where we've got USB3 devices
plugged in (on AM3352 board), this is using the musb-new driver.
The symptoms are you plug in a device in and run `usb start` and get
`USB0: Port not available.`, having watched the timings (and from
our reading of the USB spec - though this is spec in one hand and
analyser in the other...) we think that the USB device should raise
the D+ line within 100ms to indicate that it is present. With a USB
2.0 hubs we see this very quickly, but with some USB3 hubs (and some
USB3 memory sticks) this takes on the order of 800ms. We failed to
find the right part of the USB3 spec, so not sure if this is normal.
There's a timeout in musb_uboot.c of 1s:
int musb_lowlevel_init(struct musb_host_data *host)
{
void *mbase;
/* USB spec says it may take up to 1 second for a device to connect */
unsigned long timeout = get_timer(0) + 1000;
int ret;
...
If we bump that timeout to 1200ms then devices that were unreliable
now work, but obviously the longer the delay, the more time the boot
process takes when there's no USB (assuming there's a `usb start` in
there).
Would making that timeout configurable be a crazy thing to do, or are
these devices which we're trying to use just broken and we should
avoid them. Given the timeout's down in a driver, I assume other
drivers have the same 1s timeout?
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 9/9] ARM: Odroid XU3: Modify Odroid XU3 config to boot by default from SD card
On Fri, 27 Jul 2018 14:42:32 +0530 Anand Moon wrote: > Hi Lukasz, > > On 27 July 2018 at 13:54, Lukasz Majewski wrote: > > On Fri, 27 Jul 2018 08:34:15 +0530 > > Anand Moon wrote: > > > >> Hi Lukasz, > >> > >> On 26 July 2018 at 21:23, Lukasz Majewski wrote: > >> > Hi Anand, > >> > > >> >> Hi Lukasz, > >> >> > >> >> On 26 July 2018 at 03:55, Lukasz Majewski > >> >> wrote: > >> >> > This commit allows by default booting Odroid XU3 from the SD > >> >> > card (when e.g. eMMC module is not present). > >> >> > > >> >> > Signed-off-by: Lukasz Majewski > >> >> > > >> >> > --- > >> >> > > >> >> > include/configs/odroid_xu3.h | 7 +-- > >> >> > 1 file changed, 5 insertions(+), 2 deletions(-) > >> >> > > >> >> > diff --git a/include/configs/odroid_xu3.h > >> >> > b/include/configs/odroid_xu3.h index > >> >> > f495f6219ba9..818a06515cb2 100644 --- > >> >> > a/include/configs/odroid_xu3.h +++ > >> >> > b/include/configs/odroid_xu3.h @@ -94,6 +94,9 @@ > >> >> > #undef CONFIG_SYS_BOARD > >> >> > #define CONFIG_SYS_BOARD "odroid" > >> >> > > >> >> > +#undef CONFIG_SYS_MMC_ENV_DEV > >> >> > +#define CONFIG_SYS_MMC_ENV_DEV 2 > >> >> > + > >> >> > /* Define new extra env settings, including DFU settings */ > >> >> > #undef CONFIG_EXTRA_ENV_SETTINGS > >> >> > #define CONFIG_EXTRA_ENV_SETTINGS \ > >> >> > @@ -105,8 +108,8 @@ > >> >> > "console=" CONFIG_DEFAULT_CONSOLE "\0"\ > >> >> > "fdtfile=exynos5422-odroidxu3.dtb\0" \ > >> >> > "boardname=odroidxu3\0" \ > >> >> > - "mmcbootdev=0\0" \ > >> >> > - "mmcrootdev=0\0" \ > >> >> > + "mmcbootdev=2\0" \ > >> >> > + "mmcrootdev=1\0" \ > >> >> > "mmcbootpart=1\0" \ > >> >> > "mmcrootpart=2\0" \ > >> >> > "dfu_alt_system="CONFIG_DFU_ALT_SYSTEM \ > >> >> > -- > >> >> > 2.11.0 > >> >> > > >> >> > >> >> This changes probably breaks the booting from eMMC on > >> >> Odroid-XU4 > >> > > >> > I suppose, that XU4 is also equipped with SD card slot as XU3. > >> > > >> > Nonetheless, as I don't have eMMC card for mine XU3, the only > >> > way to boot my device is SD card. > >> > > >> > If you believe that this may be a problem, then I can drop this > >> > patch. > >> > > >> > Have you checked patches from 1-8? > >> > Does it work for you? If yes, please send tested-by tag. > >> > > >> > >> Yes you probably need to drop this patch, > >> I had some tough time recovering my eMMC back to flash new u-boot. > >> > >> I have tested my eMMC with default boot.scr its boot good. > >> Need to modify the boot.scr to boot into SD card. > > > > SD card has different layout than eMMC. > > > > Despite above - you just shall need to apply patch 9/9 to get the > > board running from SD card. > > > > Actually SD card are easy to modify and tune with just adding > setenv mmcrootdev "1" to autoboot.cmd from sdcard. > > but with eMMC module it's bit difficult to make this work, Ach Ok, I see The problem is when you have both attached - the eMMC and SD card. In that case I always thought that one shall boot from eMMC and the SD card shall be used as an extra storage space. Also, please keep in mind that IIRC the ROM first tries to boot from eMMC, so you need BL1, u-boot placed there if it is present. > even if we modify the autoboot.cmd and with new boot.scr > changes do not work out. > > I have hard time to recover my eMMC module to boot again. > well I have to boot from SD card with eMMC attach and then > flash the new bootloader to eMMC to make this work. > > best regards > -Anand 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-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgp9X60HpEkVh.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 0/8] NXP LS1046A SMMU enabling patches
From: Laurentiu Tudor
This patch series adds the required devices setup and device tree
fixups for SMMU enablement on NXP LS1046A chips. The approach taken
tries to mimic the implementation of PAMU LIODN setup on booke powerpc.
First 4 patches contain some fixes and add some missing bits & pieces.
Last 4 patches add the actual infrastructure for ICID setup, qman
portal and fman ICID configuration.
Changes in v5:
- use distinct ICID for SEC JRs (Horia, Bharat)
- moved an #include in the file it's used (Horia)
- fix broken compilation of multiple targets due to removal of SEC
related config (Horia)
- add a missing #include in qds board file
- drop few uses of CONFIG_SYS_FMAN_V3 and consistently use
CONFIG_SYS_DPAA_FMAN everywhere
Changes in v4:
- added missing SEC ICID config
- updated macro params to match arguments
- supplemental comments
Changes in v3:
- cleaner QMAN_BAR setup
- moved SoC specific bits from generic ICID arch setup to board code
Changes in v2:
- drop CONFIG_SYS_ prefix from newly introduced defines in patch [1/8]
Laurentiu Tudor (8):
armv8: fsl-layerscape: add missing register blocks base address
defines
armv8: ls1046a: advertise QMan v3 in configuration
misc: fsl_portals: setup QMAN_BAR{E} also on ARM platforms
armv8: fsl-layerscape: add missing debug stream ID
armv8: ls1046a: initial icid setup support
armv8: ls1046a: add icid setup for qman portals
armv8: ls1046a: setup fman ports ICIDs and device tree
armv8: ls1046a: setup SEC ICIDs and fix up device tree
arch/arm/cpu/armv8/fsl-layerscape/Makefile| 1 +
arch/arm/cpu/armv8/fsl-layerscape/icid.c | 192 ++
.../arm/cpu/armv8/fsl-layerscape/ls1046_ids.c | 89
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 3 +
.../include/asm/arch-fsl-layerscape/config.h | 1 +
.../asm/arch-fsl-layerscape/fsl_icid.h| 115 +++
.../asm/arch-fsl-layerscape/fsl_portals.h | 24 +++
.../asm/arch-fsl-layerscape/immap_lsch2.h | 15 +-
.../asm/arch-fsl-layerscape/stream_id_lsch2.h | 1 +
board/freescale/ls1046aqds/ls1046aqds.c | 3 +
board/freescale/ls1046ardb/ls1046ardb.c | 3 +
drivers/misc/fsl_portals.c| 45 +++-
12 files changed, 480 insertions(+), 12 deletions(-)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/icid.c
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
create mode 100644 arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
create mode 100644 arch/arm/include/asm/arch-fsl-layerscape/fsl_portals.h
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 1/8] armv8: fsl-layerscape: add missing register blocks base address defines
From: Laurentiu Tudor Add defines for the edma and qdma register block base addresses. Signed-off-by: Laurentiu Tudor --- arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h index 5b4767e0fe..644a16dd30 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h @@ -88,8 +88,12 @@ #define LPUART_BASE(CONFIG_SYS_IMMR + 0x0195) +#define EDMA_BASE_ADDR (CONFIG_SYS_IMMR + 0x01c0) + #define AHCI_BASE_ADDR (CONFIG_SYS_IMMR + 0x0220) +#define QDMA_BASE_ADDR (CONFIG_SYS_IMMR + 0x0738) + #define CONFIG_SYS_PCIE1_PHYS_ADDR 0x40ULL #define CONFIG_SYS_PCIE2_PHYS_ADDR 0x48ULL #define CONFIG_SYS_PCIE3_PHYS_ADDR 0x50ULL -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 2/8] armv8: ls1046a: advertise QMan v3 in configuration
From: Laurentiu Tudor The QMan IP block in this SoC is version 3.2 so advertise this in the SoC configuration header. Signed-off-by: Laurentiu Tudor --- arch/arm/include/asm/arch-fsl-layerscape/config.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h b/arch/arm/include/asm/arch-fsl-layerscape/config.h index 23faffd9fc..8a05148136 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h @@ -257,6 +257,7 @@ #elif defined(CONFIG_ARCH_LS1046A) #define CONFIG_SYS_FMAN_V3 +#define CONFIG_SYS_FSL_QMAN_V3 #define CONFIG_SYS_NUM_FMAN1 #define CONFIG_SYS_NUM_FM1_DTSEC 8 #define CONFIG_SYS_NUM_FM1_10GEC 2 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 3/8] misc: fsl_portals: setup QMAN_BAR{E} also on ARM platforms
From: Laurentiu Tudor
QMAN_BAR{E} register setup was disabled on ARM platforms, however the
register does need to be set. Enable the code also on ARMs and fix the
CONFIG_SYS_QMAN_MEM_PHYS define to the correct value so that the newly
enabled code works.
Signed-off-by: Laurentiu Tudor
---
arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h | 3 +--
drivers/misc/fsl_portals.c | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
index 644a16dd30..d22ec70aa5 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
@@ -57,8 +57,7 @@
#define CONFIG_SYS_BMAN_SWP_ISDR_REG0x3E80
#define CONFIG_SYS_QMAN_NUM_PORTALS10
#define CONFIG_SYS_QMAN_MEM_BASE 0x5
-#define CONFIG_SYS_QMAN_MEM_PHYS (0xfull + \
- CONFIG_SYS_QMAN_MEM_BASE)
+#define CONFIG_SYS_QMAN_MEM_PHYS CONFIG_SYS_QMAN_MEM_BASE
#define CONFIG_SYS_QMAN_MEM_SIZE 0x0800
#define CONFIG_SYS_QMAN_SP_CENA_SIZE0x1
#define CONFIG_SYS_QMAN_SP_CINH_SIZE0x1
diff --git a/drivers/misc/fsl_portals.c b/drivers/misc/fsl_portals.c
index 7c22b8d209..22faf16751 100644
--- a/drivers/misc/fsl_portals.c
+++ b/drivers/misc/fsl_portals.c
@@ -24,7 +24,6 @@ void setup_qbman_portals(void)
CONFIG_SYS_BMAN_SWP_ISDR_REG;
void __iomem *qpaddr = (void *)CONFIG_SYS_QMAN_CINH_BASE +
CONFIG_SYS_QMAN_SWP_ISDR_REG;
-#ifdef CONFIG_PPC
struct ccsr_qman *qman = (void *)CONFIG_SYS_FSL_QMAN_ADDR;
/* Set the Qman initiator BAR to match the LAW (for DQRR stashing) */
@@ -32,7 +31,6 @@ void setup_qbman_portals(void)
out_be32(&qman->qcsp_bare, (u32)(CONFIG_SYS_QMAN_MEM_PHYS >> 32));
#endif
out_be32(&qman->qcsp_bar, (u32)CONFIG_SYS_QMAN_MEM_PHYS);
-#endif
#ifdef CONFIG_FSL_CORENET
int i;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 4/8] armv8: fsl-layerscape: add missing debug stream ID
From: Laurentiu Tudor Add a define with a value for the missing debug stream ID. Signed-off-by: Laurentiu Tudor --- arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch2.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch2.h b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch2.h index 61c6e533c6..1b02d484d9 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch2.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch2.h @@ -50,6 +50,7 @@ #define FSL_QDMA_STREAM_ID 7 #define FSL_EDMA_STREAM_ID 8 #define FSL_ETR_STREAM_ID 9 +#define FSL_DEBUG_STREAM_ID10 /* PCI - programmed in PEXn_LUT */ #define FSL_PEX_STREAM_ID_START11 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 7/8] armv8: ls1046a: setup fman ports ICIDs and device tree
From: Laurentiu Tudor
Add support for ICID setting of fman ports and the required device
tree fixups.
Signed-off-by: Laurentiu Tudor
---
arch/arm/cpu/armv8/fsl-layerscape/icid.c | 82 +++
.../arm/cpu/armv8/fsl-layerscape/ls1046_ids.c | 30 +++
.../asm/arch-fsl-layerscape/fsl_icid.h| 10 +++
3 files changed, 122 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/icid.c
b/arch/arm/cpu/armv8/fsl-layerscape/icid.c
index ae3b8daa95..b1a950e7f9 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/icid.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/icid.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
static void set_icid(struct icid_id_table *tbl, int size)
{
@@ -19,10 +20,27 @@ static void set_icid(struct icid_id_table *tbl, int size)
out_be32((u32 *)(tbl[i].reg_addr), tbl[i].reg);
}
+#ifdef CONFIG_SYS_DPAA_FMAN
+void set_fman_icids(struct fman_icid_id_table *tbl, int size)
+{
+ int i;
+ ccsr_fman_t *fm = (void *)CONFIG_SYS_FSL_FM1_ADDR;
+
+ for (i = 0; i < size; i++) {
+ out_be32(&fm->fm_bmi_common.fmbm_ppid[tbl[i].port_id - 1],
+tbl[i].icid);
+ }
+}
+#endif
+
void set_icids(void)
{
/* setup general icid offsets */
set_icid(icid_tbl, icid_tbl_sz);
+
+#ifdef CONFIG_SYS_DPAA_FMAN
+ set_fman_icids(fman_icid_tbl, fman_icid_tbl_sz);
+#endif
}
int fdt_set_iommu_prop(void *blob, int off, int smmu_ph, u32 *ids, int num_ids)
@@ -75,6 +93,66 @@ int fdt_fixup_icid_tbl(void *blob, int smmu_ph,
return 0;
}
+#ifdef CONFIG_SYS_DPAA_FMAN
+int get_fman_port_icid(int port_id, struct fman_icid_id_table *tbl,
+ const int size)
+{
+ int i;
+
+ for (i = 0; i < size; i++) {
+ if (tbl[i].port_id == port_id)
+ return tbl[i].icid;
+ }
+
+ return -1;
+}
+
+void fdt_fixup_fman_port_icid_by_compat(void *blob, int smmu_ph,
+ const char *compat)
+{
+ int noff, len, icid;
+ const u32 *prop;
+
+ noff = fdt_node_offset_by_compatible(blob, -1, compat);
+ while (noff > 0) {
+ prop = fdt_getprop(blob, noff, "cell-index", &len);
+ if (!prop) {
+ printf("WARNING missing cell-index for fman port\n");
+ continue;
+ }
+ if (len != 4) {
+ printf("WARNING bad cell-index size for fman port\n");
+ continue;
+ }
+
+ icid = get_fman_port_icid(fdt32_to_cpu(*prop),
+ fman_icid_tbl, fman_icid_tbl_sz);
+ if (icid < 0) {
+ printf("WARNING unknown ICID for fman port %d\n",
+ *prop);
+ continue;
+ }
+
+ fdt_set_iommu_prop(blob, noff, smmu_ph, (u32 *)&icid, 1);
+
+ noff = fdt_node_offset_by_compatible(blob, noff, compat);
+ }
+}
+
+void fdt_fixup_fman_icids(void *blob, int smmu_ph)
+{
+ static const char * const compats[] = {
+ "fsl,fman-v3-port-oh",
+ "fsl,fman-v3-port-rx",
+ "fsl,fman-v3-port-tx",
+ };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(compats); i++)
+ fdt_fixup_fman_port_icid_by_compat(blob, smmu_ph, compats[i]);
+}
+#endif
+
int fdt_get_smmu_phandle(void *blob)
{
int noff, smmu_ph;
@@ -107,4 +185,8 @@ void fdt_fixup_icid(void *blob)
return;
fdt_fixup_icid_tbl(blob, smmu_ph, icid_tbl, icid_tbl_sz);
+
+#ifdef CONFIG_SYS_DPAA_FMAN
+ fdt_fixup_fman_icids(blob, smmu_ph);
+#endif
}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
index 80e1ceadc0..30c7d8d28a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
@@ -43,3 +43,33 @@ struct icid_id_table icid_tbl[] = {
};
int icid_tbl_sz = ARRAY_SIZE(icid_tbl);
+
+#ifdef CONFIG_SYS_DPAA_FMAN
+struct fman_icid_id_table fman_icid_tbl[] = {
+ /* port id, icid */
+ SET_FMAN_ICID_ENTRY(0x02, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x03, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x04, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x05, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x06, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x07, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x08, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x09, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x0a, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x0b, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x0c, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x0d, FSL_DPAA1_STREAM_ID_END),
+ SET_FMAN_ICID_ENTRY(0x28, FSL_DPAA1_STR
[U-Boot] [PATCH v5 5/8] armv8: ls1046a: initial icid setup support
From: Laurentiu Tudor
Add infrastructure for ICID setup and device tree fixup on ARM
platforms. This include basic ICID setup for several devices.
Signed-off-by: Laurentiu Tudor
---
arch/arm/cpu/armv8/fsl-layerscape/Makefile| 1 +
arch/arm/cpu/armv8/fsl-layerscape/icid.c | 110 ++
.../arm/cpu/armv8/fsl-layerscape/ls1046_ids.c | 29 +
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 3 +
.../asm/arch-fsl-layerscape/fsl_icid.h| 80 +
board/freescale/ls1046aqds/ls1046aqds.c | 3 +
board/freescale/ls1046ardb/ls1046ardb.c | 3 +
7 files changed, 229 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/icid.c
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
create mode 100644 arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 1e9e4680fe..5d6f68aad6 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -37,6 +37,7 @@ endif
ifneq ($(CONFIG_ARCH_LS1046A),)
obj-$(CONFIG_SYS_HAS_SERDES) += ls1046a_serdes.o
+obj-y += icid.o ls1046_ids.o
endif
ifneq ($(CONFIG_ARCH_LS1088A),)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/icid.c
b/arch/arm/cpu/armv8/fsl-layerscape/icid.c
new file mode 100644
index 00..ae3b8daa95
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/icid.c
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static void set_icid(struct icid_id_table *tbl, int size)
+{
+ int i;
+
+ for (i = 0; i < size; i++)
+ out_be32((u32 *)(tbl[i].reg_addr), tbl[i].reg);
+}
+
+void set_icids(void)
+{
+ /* setup general icid offsets */
+ set_icid(icid_tbl, icid_tbl_sz);
+}
+
+int fdt_set_iommu_prop(void *blob, int off, int smmu_ph, u32 *ids, int num_ids)
+{
+ int i, ret;
+ u32 prop[8];
+
+ /*
+* Note: The "iommus" property definition mentions Stream IDs while
+* this code handles ICIDs. The current implementation assumes that
+* ICIDs and Stream IDs are equal.
+*/
+ for (i = 0; i < num_ids; i++) {
+ prop[i * 2] = cpu_to_fdt32(smmu_ph);
+ prop[i * 2 + 1] = cpu_to_fdt32(ids[i]);
+ }
+ ret = fdt_setprop(blob, off, "iommus",
+ prop, sizeof(u32) * num_ids * 2);
+ if (ret) {
+ printf("WARNING unable to set iommus: %s\n", fdt_strerror(ret));
+ return ret;
+ }
+
+ return 0;
+}
+
+int fdt_fixup_icid_tbl(void *blob, int smmu_ph,
+ struct icid_id_table *tbl, int size)
+{
+ int i, err, off;
+
+ for (i = 0; i < size; i++) {
+ if (!tbl[i].compat)
+ continue;
+
+ off = fdt_node_offset_by_compat_reg(blob,
+ tbl[i].compat,
+ tbl[i].compat_addr);
+ if (off > 0) {
+ err = fdt_set_iommu_prop(blob, off, smmu_ph,
+&tbl[i].id, 1);
+ if (err)
+ return err;
+ } else {
+ printf("WARNING could not find node %s: %s.\n",
+ tbl[i].compat, fdt_strerror(off));
+ }
+ }
+
+ return 0;
+}
+
+int fdt_get_smmu_phandle(void *blob)
+{
+ int noff, smmu_ph;
+
+ noff = fdt_node_offset_by_compatible(blob, -1, "arm,mmu-500");
+ if (noff < 0) {
+ printf("WARNING failed to get smmu node: %s\n",
+ fdt_strerror(noff));
+ return noff;
+ }
+
+ smmu_ph = fdt_get_phandle(blob, noff);
+ if (!smmu_ph) {
+ smmu_ph = fdt_create_phandle(blob, noff);
+ if (!smmu_ph) {
+ printf("WARNING failed to get smmu phandle\n");
+ return -1;
+ }
+ }
+
+ return smmu_ph;
+}
+
+void fdt_fixup_icid(void *blob)
+{
+ int smmu_ph;
+
+ smmu_ph = fdt_get_smmu_phandle(blob);
+ if (smmu_ph < 0)
+ return;
+
+ fdt_fixup_icid_tbl(blob, smmu_ph, icid_tbl, icid_tbl_sz);
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
new file mode 100644
index 00..1c528ab751
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP
+ */
+
+#include
+#include
+#include
+
+struct icid_id_table icid_tbl[] = {
+#ifdef CONFIG_SYS_DPAA_QBMAN
+ SET_QMAN_ICID(FSL_DPAA1_STREAM_ID_START),
+ SET_BMAN_ICID(FSL_DPAA1_STREAM_ID_START + 1),
+#endif
+
+
[U-Boot] [PATCH v5 6/8] armv8: ls1046a: add icid setup for qman portals
From: Laurentiu Tudor
Add support for ICID setting of qman portals and the required device
tree fixups. Also fix an endiness issue in portal setup code.
Signed-off-by: Laurentiu Tudor
---
.../arm/cpu/armv8/fsl-layerscape/ls1046_ids.c | 16 +++
.../asm/arch-fsl-layerscape/fsl_portals.h | 24 +++
drivers/misc/fsl_portals.c| 43 +++
3 files changed, 75 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/include/asm/arch-fsl-layerscape/fsl_portals.h
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
index 1c528ab751..80e1ceadc0 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
@@ -6,6 +6,22 @@
#include
#include
#include
+#include
+
+#ifdef CONFIG_SYS_DPAA_QBMAN
+struct qportal_info qp_info[CONFIG_SYS_QMAN_NUM_PORTALS] = {
+ SET_QP_INFO(FSL_DPAA1_STREAM_ID_END, 0),
+ SET_QP_INFO(FSL_DPAA1_STREAM_ID_END, 0),
+ SET_QP_INFO(FSL_DPAA1_STREAM_ID_END, 0),
+ SET_QP_INFO(FSL_DPAA1_STREAM_ID_END, 0),
+ SET_QP_INFO(FSL_DPAA1_STREAM_ID_END, 0),
+ SET_QP_INFO(FSL_DPAA1_STREAM_ID_END, 0),
+ SET_QP_INFO(FSL_DPAA1_STREAM_ID_END, 0),
+ SET_QP_INFO(FSL_DPAA1_STREAM_ID_END, 0),
+ SET_QP_INFO(FSL_DPAA1_STREAM_ID_END, 0),
+ SET_QP_INFO(FSL_DPAA1_STREAM_ID_END, 0),
+};
+#endif
struct icid_id_table icid_tbl[] = {
#ifdef CONFIG_SYS_DPAA_QBMAN
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_portals.h
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_portals.h
new file mode 100644
index 00..1577e935a6
--- /dev/null
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_portals.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018 NXP
+ */
+
+#ifndef _FSL_PORTALS_H_
+#define _FSL_PORTALS_H_
+
+struct qportal_info {
+ u16 dicid; /* DQRR ICID */
+ u16 ficid; /* frame data ICID */
+ u16 icid;
+ u8 sdest;
+};
+
+#define SET_QP_INFO(streamid, dest) \
+ { .dicid = (streamid), .ficid = (streamid), .icid = (streamid), \
+ .sdest = (dest) }
+
+extern struct qportal_info qp_info[];
+void fdt_portal(void *blob, const char *compat, const char *container,
+ u64 addr, u32 size);
+
+#endif
diff --git a/drivers/misc/fsl_portals.c b/drivers/misc/fsl_portals.c
index 22faf16751..a524510707 100644
--- a/drivers/misc/fsl_portals.c
+++ b/drivers/misc/fsl_portals.c
@@ -13,6 +13,9 @@
#ifdef CONFIG_PPC
#include
#include
+#else
+#include
+#include
#endif
#include
@@ -45,6 +48,22 @@ void setup_qbman_portals(void)
/* set frame liodn */
out_be32(&qman->qcsp[i].qcsp_io_cfg, (sdest << 16) | fliodn);
}
+#else
+#ifdef CONFIG_ARM
+ int i;
+
+ for (i = 0; i < CONFIG_SYS_QMAN_NUM_PORTALS; i++) {
+ u8 sdest = qp_info[i].sdest;
+ u16 ficid = qp_info[i].ficid;
+ u16 dicid = qp_info[i].dicid;
+ u16 icid = qp_info[i].icid;
+
+ out_be32(&qman->qcsp[i].qcsp_lio_cfg, (icid << 16) |
+ dicid);
+ /* set frame icid */
+ out_be32(&qman->qcsp[i].qcsp_io_cfg, (sdest << 16) | ficid);
+ }
+#endif
#endif
/* Change default state of BMan ISDR portals to all 1s */
@@ -178,6 +197,10 @@ void fdt_fixup_qportals(void *blob)
char compat[64];
int compat_len;
+#ifndef CONFIG_PPC
+ int smmu_ph = fdt_get_smmu_phandle(blob);
+#endif
+
maj = (rev_1 >> 8) & 0xff;
min = rev_1 & 0xff;
ip_cfg = rev_2 & 0xff;
@@ -188,7 +211,6 @@ void fdt_fixup_qportals(void *blob)
off = fdt_node_offset_by_compatible(blob, -1, "fsl,qman-portal");
while (off != -FDT_ERR_NOTFOUND) {
-#ifdef CONFIG_PPC
#ifdef CONFIG_FSL_CORENET
u32 liodns[2];
#endif
@@ -198,12 +220,7 @@ void fdt_fixup_qportals(void *blob)
if (!ci)
goto err;
- i = *ci;
-#ifdef CONFIG_SYS_DPAA_FMAN
- int j;
-#endif
-
-#endif /* CONFIG_PPC */
+ i = fdt32_to_cpu(*ci);
err = fdt_setprop(blob, off, "compatible", compat, compat_len);
if (err < 0)
goto err;
@@ -235,7 +252,7 @@ void fdt_fixup_qportals(void *blob)
#endif
#ifdef CONFIG_SYS_DPAA_FMAN
- for (j = 0; j < CONFIG_SYS_NUM_FMAN; j++) {
+ for (int j = 0; j < CONFIG_SYS_NUM_FMAN; j++) {
char name[] = "fman@0";
name[sizeof(name) - 2] = '0' + j;
@@ -251,6 +268,16 @@ void fdt_fixup_qportals(void *blob)
if (err < 0)
goto err;
#endif
+#else
+ if (smmu_ph >= 0) {
+ u32 icids[3];
+
+ icids[0] = qp_info[i].icid;
+ icids[1] = qp_inf
[U-Boot] [PATCH v5 8/8] armv8: ls1046a: setup SEC ICIDs and fix up device tree
From: Laurentiu Tudor
Add support for SEC ICID configuration and apply it for ls1046a.
Also add code to make the necessary device tree fixups.
Signed-off-by: Laurentiu Tudor
---
.../arm/cpu/armv8/fsl-layerscape/ls1046_ids.c | 14 +++
.../asm/arch-fsl-layerscape/fsl_icid.h| 25 +++
.../asm/arch-fsl-layerscape/immap_lsch2.h | 8 ++
3 files changed, 47 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
index 30c7d8d28a..bc2fe283a1 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
@@ -40,6 +40,20 @@ struct icid_id_table icid_tbl[] = {
SET_EDMA_ICID(FSL_EDMA_STREAM_ID),
SET_ETR_ICID(FSL_ETR_STREAM_ID),
SET_DEBUG_ICID(FSL_DEBUG_STREAM_ID),
+#ifdef CONFIG_FSL_CAAM
+ SET_SEC_QI_ICID(FSL_DPAA1_STREAM_ID_START + 2),
+ SET_SEC_JR_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 3),
+ SET_SEC_JR_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 4),
+ SET_SEC_JR_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 5),
+ SET_SEC_JR_ICID_ENTRY(3, FSL_DPAA1_STREAM_ID_START + 6),
+ SET_SEC_RTIC_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2),
+ SET_SEC_RTIC_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2),
+ SET_SEC_RTIC_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2),
+ SET_SEC_RTIC_ICID_ENTRY(3, FSL_DPAA1_STREAM_ID_START + 2),
+ SET_SEC_DECO_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2),
+ SET_SEC_DECO_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2),
+ SET_SEC_DECO_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2),
+#endif
};
int icid_tbl_sz = ARRAY_SIZE(icid_tbl);
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
index 5be50a17ab..a70c866651 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
@@ -8,6 +8,7 @@
#include
#include
+#include
struct icid_id_table {
const char *compat;
@@ -82,6 +83,30 @@ void fdt_fixup_icid(void *blob);
#define SET_FMAN_ICID_ENTRY(_port_id, streamid) \
{ .port_id = (_port_id), .icid = (streamid) }
+#define SET_SEC_QI_ICID(streamid) \
+ SET_ICID_ENTRY("fsl,sec-v4.0", streamid, \
+ (((streamid) << 16) | (streamid)), \
+ offsetof(ccsr_sec_t, qilcr_ls) + \
+ CONFIG_SYS_FSL_SEC_ADDR, \
+ CONFIG_SYS_FSL_SEC_ADDR)
+
+#define SET_SEC_JR_ICID_ENTRY(jr_num, streamid) \
+ SET_ICID_ENTRY("fsl,sec-v4.0-job-ring", streamid, \
+ (((streamid) << 16) | (streamid)), \
+ offsetof(ccsr_sec_t, jrliodnr[jr_num].ls) + \
+ CONFIG_SYS_FSL_SEC_ADDR, \
+ FSL_SEC_JR##jr_num##_BASE_ADDR)
+
+#define SET_SEC_DECO_ICID_ENTRY(deco_num, streamid) \
+ SET_ICID_ENTRY(NULL, streamid, (((streamid) << 16) | (streamid)), \
+ offsetof(ccsr_sec_t, decoliodnr[deco_num].ls) + \
+ CONFIG_SYS_FSL_SEC_ADDR, 0)
+
+#define SET_SEC_RTIC_ICID_ENTRY(rtic_num, streamid) \
+ SET_ICID_ENTRY(NULL, streamid, (((streamid) << 16) | (streamid)), \
+ offsetof(ccsr_sec_t, rticliodnr[rtic_num].ls) + \
+ CONFIG_SYS_FSL_SEC_ADDR, 0)
+
extern struct icid_id_table icid_tbl[];
extern struct fman_icid_id_table fman_icid_tbl[];
extern int icid_tbl_sz;
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
index d22ec70aa5..be0a6ae363 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
@@ -200,10 +200,18 @@ struct sys_info {
#define CONFIG_SYS_FSL_SEC_OFFSET 0x70ull
#define CONFIG_SYS_FSL_JR0_OFFSET 0x71ull
+#define FSL_SEC_JR0_OFFSET CONFIG_SYS_FSL_JR0_OFFSET
+#define FSL_SEC_JR1_OFFSET 0x72ull
+#define FSL_SEC_JR2_OFFSET 0x73ull
+#define FSL_SEC_JR3_OFFSET 0x74ull
#define CONFIG_SYS_FSL_SEC_ADDR \
(CONFIG_SYS_IMMR + CONFIG_SYS_FSL_SEC_OFFSET)
#define CONFIG_SYS_FSL_JR0_ADDR \
(CONFIG_SYS_IMMR + CONFIG_SYS_FSL_JR0_OFFSET)
+#define FSL_SEC_JR0_BASE_ADDR (CONFIG_SYS_IMMR + FSL_SEC_JR0_OFFSET)
+#define FSL_SEC_JR1_BASE_ADDR (CONFIG_SYS_IMMR + FSL_SEC_JR1_OFFSET)
+#define FSL_SEC_JR2_BASE_ADDR (CONFIG_SYS_IMMR + FSL_SEC_JR2_OFFSET)
+#define FSL_SEC_JR3_BASE_ADDR (CONFIG_SYS_IMMR + FSL_SEC_JR3_OFFSET)
/* Device Configuration and Pin Control */
#define DCFG_DCSR_PORCR1 0x0
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Thu, 26 Jul 2018 23:14:01 +0200 Marek Vasut wrote: > On 07/26/2018 11:08 PM, Lukasz Majewski wrote: > > On Thu, 26 Jul 2018 21:25:02 +0200 > > Marek Vasut wrote: > > > >> On 07/26/2018 05:14 PM, Tom Rini wrote: > >>> On Thu, Jul 26, 2018 at 09:35:54AM +0200, Marek Vasut wrote: > >>> > The following changes since commit > 323a73adc9a1bf2de43fe03bdd9c3038ce7c2784: > > mtd: nand: add new enum for storing ECC algorithm (2018-07-23 > 14:33:21 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to > 67f1c59f40fde73cb2cbb51ebf0a05156ec403b7: > > usb: dwc3: convert to livetree (2018-07-25 00:13:44 +0200) > > >>> > >>> NAK. This breaks at least: am335x_hs_evm am335x_hs_evm_uart > >>> brppt1_spi brppt1_mmc am335x_evm brppt1_nand and stih410-b2260 > >> > >> CCing the authors, I expect a patch. > >> > > > > Could you share how and where it breaks? > > > > I did standard Travis-CI build test on DFU PR. > > I agree it'd be helpful if Tom shared more information than just > "NAK", yes. Then again, did you try building one of those targets ? > I did the Travis-CI run during the night of Marek's u-boot-usb branch. https://travis-ci.org/lmajewski/u-boot-dfu/jobs/408692849 The problem seems now to be with x86 sandbox. However it seems not to be related to USB: Building current source for 29 boards (2 threads, 1 job per thread) x86: + theadorable-x86-conga-qa3-e3845 +Could not delete: No such file or directory +mv: cannot stat ?board/congatec/conga-qeval20-qa3-e3845/dsdt.hex?: No such file or directory +make[2]: *** [board/congatec/conga-qeval20-qa3-e3845/dsdt.c] Error 1 +make[1]: *** [board/congatec/conga-qeval20-qa3-e3845] Error 2 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-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgpY1T2mie6Fq.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 v5 8/8] armv8: ls1046a: setup SEC ICIDs and fix up device tree
> -Original Message-
> From: laurentiu.tu...@nxp.com [mailto:laurentiu.tu...@nxp.com]
> Sent: Friday, July 27, 2018 3:28 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
> ; York Sun
> Cc: Bharat Bhushan ; Horia Geanta
> ; Laurentiu Tudor
> Subject: [PATCH v5 8/8] armv8: ls1046a: setup SEC ICIDs and fix up device
> tree
>
> From: Laurentiu Tudor
>
> Add support for SEC ICID configuration and apply it for ls1046a.
> Also add code to make the necessary device tree fixups.
>
> Signed-off-by: Laurentiu Tudor
> ---
> .../arm/cpu/armv8/fsl-layerscape/ls1046_ids.c | 14 +++
> .../asm/arch-fsl-layerscape/fsl_icid.h| 25 +++
> .../asm/arch-fsl-layerscape/immap_lsch2.h | 8 ++
> 3 files changed, 47 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
> b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
> index 30c7d8d28a..bc2fe283a1 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
> @@ -40,6 +40,20 @@ struct icid_id_table icid_tbl[] = {
> SET_EDMA_ICID(FSL_EDMA_STREAM_ID),
> SET_ETR_ICID(FSL_ETR_STREAM_ID),
> SET_DEBUG_ICID(FSL_DEBUG_STREAM_ID),
> +#ifdef CONFIG_FSL_CAAM
> + SET_SEC_QI_ICID(FSL_DPAA1_STREAM_ID_START + 2),
> + SET_SEC_JR_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 3),
> + SET_SEC_JR_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 4),
> + SET_SEC_JR_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 5),
> + SET_SEC_JR_ICID_ENTRY(3, FSL_DPAA1_STREAM_ID_START + 6),
> + SET_SEC_RTIC_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2),
> + SET_SEC_RTIC_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2),
> + SET_SEC_RTIC_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2),
> + SET_SEC_RTIC_ICID_ENTRY(3, FSL_DPAA1_STREAM_ID_START + 2),
> + SET_SEC_DECO_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2),
> + SET_SEC_DECO_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2),
> + SET_SEC_DECO_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2),
Here goes my understanding:
RTIC are independent device from JR and QI, So they should be assigned
different unique steam-id. Also each RTIC are independent device, so each RTIC
can also be assigned separate stream-id.
While we can decide to use one stream-id for all RITCs and add a comment that
they are not partitionable.
DECOs can take work from QI or JRs, and in that case they will use the
stream-id of the respective QI or JR, and the stream-id programmed in DECOs is
not used.
While DECOs can be used directly (not via JR and QI) and in that case it will
use the strema-id programmed in it. So in this case also we should be using
unique stream-id for each DECO if partitionable or one for all DECOs
Thanks
-Bharat
> #endif
> };
>
> int icid_tbl_sz = ARRAY_SIZE(icid_tbl); diff --git
> a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> index 5be50a17ab..a70c866651 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
>
> struct icid_id_table {
> const char *compat;
> @@ -82,6 +83,30 @@ void fdt_fixup_icid(void *blob); #define
> SET_FMAN_ICID_ENTRY(_port_id, streamid) \
> { .port_id = (_port_id), .icid = (streamid) }
>
> +#define SET_SEC_QI_ICID(streamid) \
> + SET_ICID_ENTRY("fsl,sec-v4.0", streamid, \
> + (((streamid) << 16) | (streamid)), \
> + offsetof(ccsr_sec_t, qilcr_ls) + \
> + CONFIG_SYS_FSL_SEC_ADDR, \
> + CONFIG_SYS_FSL_SEC_ADDR)
> +
> +#define SET_SEC_JR_ICID_ENTRY(jr_num, streamid) \
> + SET_ICID_ENTRY("fsl,sec-v4.0-job-ring", streamid, \
> + (((streamid) << 16) | (streamid)), \
> + offsetof(ccsr_sec_t, jrliodnr[jr_num].ls) + \
> + CONFIG_SYS_FSL_SEC_ADDR, \
> + FSL_SEC_JR##jr_num##_BASE_ADDR)
> +
> +#define SET_SEC_DECO_ICID_ENTRY(deco_num, streamid) \
> + SET_ICID_ENTRY(NULL, streamid, (((streamid) << 16) | (streamid)), \
> + offsetof(ccsr_sec_t, decoliodnr[deco_num].ls) + \
> + CONFIG_SYS_FSL_SEC_ADDR, 0)
> +
> +#define SET_SEC_RTIC_ICID_ENTRY(rtic_num, streamid) \
> + SET_ICID_ENTRY(NULL, streamid, (((streamid) << 16) | (streamid)), \
> + offsetof(ccsr_sec_t, rticliodnr[rtic_num].ls) + \
> + CONFIG_SYS_FSL_SEC_ADDR, 0)
> +
> extern struct icid_id_table icid_tbl[]; extern struct fman_icid_id_table
> fman_icid_tbl[]; extern int icid_tbl_sz; diff --git
> a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> index d22ec70aa5..be0a6ae363 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> @@ -200,10 +200,18 @@ struct sys_info {
>
> #define CONFIG_SYS_FSL_SEC_OFFSET0
Re: [U-Boot] [PULL] u-boot-usb/master
On Fri, Jul 27, 2018 at 11:59:32AM +0200, Lukasz Majewski wrote:
> On Thu, 26 Jul 2018 23:14:01 +0200
> Marek Vasut wrote:
>
> > On 07/26/2018 11:08 PM, Lukasz Majewski wrote:
> > > On Thu, 26 Jul 2018 21:25:02 +0200
> > > Marek Vasut wrote:
> > >
> > >> On 07/26/2018 05:14 PM, Tom Rini wrote:
> > >>> On Thu, Jul 26, 2018 at 09:35:54AM +0200, Marek Vasut wrote:
> > >>>
> > The following changes since commit
> > 323a73adc9a1bf2de43fe03bdd9c3038ce7c2784:
> >
> > mtd: nand: add new enum for storing ECC algorithm (2018-07-23
> > 14:33:21 -0400)
> >
> > are available in the Git repository at:
> >
> > git://git.denx.de/u-boot-usb.git master
> >
> > for you to fetch changes up to
> > 67f1c59f40fde73cb2cbb51ebf0a05156ec403b7:
> >
> > usb: dwc3: convert to livetree (2018-07-25 00:13:44 +0200)
> >
> > >>>
> > >>> NAK. This breaks at least: am335x_hs_evm am335x_hs_evm_uart
> > >>> brppt1_spi brppt1_mmc am335x_evm brppt1_nand and stih410-b2260
> > >>
> > >> CCing the authors, I expect a patch.
> > >>
> > >
> > > Could you share how and where it breaks?
> > >
> > > I did standard Travis-CI build test on DFU PR.
> >
> > I agree it'd be helpful if Tom shared more information than just
> > "NAK", yes. Then again, did you try building one of those targets ?
> >
>
> I did the Travis-CI run during the night of Marek's u-boot-usb branch.
When I pull -usb right now I see:
Testing /tmp/am335x_hs_evm_uart
Fri Jul 27 07:38:02 EDT 2018
WARNING: no status info for 'pico-pi-imx7d'
WARNING: no maintainers for 'pico-pi-imx7d'
Building current source for 1 boards (1 thread, 16 jobs per thread)
arm: + am335x_hs_evm_uart
+(am335x_hs_evm_uart) drivers/usb/musb-new/ti-musb.c: In function
'ti_musb_wrapper_bind':
+(am335x_hs_evm_uart) drivers/usb/musb-new/ti-musb.c:221:29: error:
incompatible type for argument 1 of 'usb_get_dr_mode'
+(am335x_hs_evm_uart)dr_mode = usb_get_dr_mode(node);
+(am335x_hs_evm_uart) ^~~~
+(am335x_hs_evm_uart) In file included from drivers/usb/musb-new/ti-musb.c:12:0:
+(am335x_hs_evm_uart) include/linux/usb/otg.h:28:18: note: expected 'ofnode
{aka union ofnode_union}' but argument is of type 'int'
+(am335x_hs_evm_uart) enum usb_dr_mode usb_get_dr_mode(ofnode node);
+(am335x_hs_evm_uart) ^~~
+(am335x_hs_evm_uart) make[2]: *** [drivers/usb/musb-new/ti-musb.o] Error 1
+(am335x_hs_evm_uart) make[1]: *** [drivers/usb/musb-new] Error 2
+(am335x_hs_evm_uart) make: *** [sub-make] Error 2
001 /1 am335x_hs_evm_uart
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] openrd: Once again shrink binary size
With some recent changes to relevant drivers here the openrd board
(openrd_client in this case) does not fit within its size constraint.
We can however drop the slightly extended baudrate table and then the
duplication of mtdparts/mtdids in the default environment. These
defaults are set in the environment by the 'mtdparts' command and
otherwise referenced throughout the code.
Signed-off-by: Tom Rini
---
include/configs/mv-common.h | 8
include/configs/openrd.h| 4 +---
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/include/configs/mv-common.h b/include/configs/mv-common.h
index 79d61c599e54..8ae521f7e986 100644
--- a/include/configs/mv-common.h
+++ b/include/configs/mv-common.h
@@ -38,14 +38,6 @@
#define CONFIG_SYS_NS16550_COM1MV_UART_CONSOLE_BASE
#endif
-/*
- * Serial Port configuration
- * The following definitions let you select what serial you want to use
- * for your console driver.
- */
-
-#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, \
- 115200,230400, 460800, 921600 }
/* auto boot */
#define CONFIG_PREBOOT
diff --git a/include/configs/openrd.h b/include/configs/openrd.h
index 2b21003b8b75..17611bc56873 100644
--- a/include/configs/openrd.h
+++ b/include/configs/openrd.h
@@ -60,9 +60,7 @@
CONFIG_MTDPARTS_DEFAULT " rw ubi.mtd=2,2048\0" \
"x_bootcmd_kernel=nand read 0x640 0x10 0x30\0" \
"x_bootcmd_usb=usb start\0" \
- "x_bootargs_root=root=ubi0:rootfs rootfstype=ubifs\0" \
- "mtdids="CONFIG_MTDIDS_DEFAULT"\0"
\
- "mtdparts="CONFIG_MTDPARTS_DEFAULT"\0"
+ "x_bootargs_root=root=ubi0:rootfs rootfstype=ubifs\0"
/*
* Ethernet Driver configuration
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH v2 00/13] Allwinner H6 support (w/ SPL)
On Thu, Jul 26, 2018 at 12:35 PM, Icenowy Zheng wrote: > > > 于 2018年7月26日 GMT+08:00 下午3:02:50, Jagan Teki 写到: >>On Sat, Jul 21, 2018 at 1:50 PM, Icenowy Zheng wrote: >>> This patchset trys to add support for Allwinner H6 SoC to U-Boot. >>> >>> Allwinner H6 is a quite new Allwinner SoC, with several parts changed >>a >>> lot (memory map, DRAM controller, CCU, so on). The position which SPL >>> will be loaded (SRAM A1) also changed to 0x2. >>> >>> The Pine H64 board support comes with this patchset, as this is the >>> first H6 board that I can get (being early bird). >>> >>> Icenowy Zheng (13): >>> sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS >>> sunxi: add basic memory map definitions of H6 SoC >>> sunxi: change RMR64's RVBAR address for H6 >>> sunxi: change ATF position for H6 >>> sunxi: add config for SPL at 0x2 on H6 >>> sunxi: change GIC address on H6 >>> sunxi: add clock code for H6 >>> sunxi: use sun6i-style watchdog for H6 >>> sunxi: add UART0 setup for H6 >>> sunxi: add MMC support for H6 >>> sunxi: add DRAM support to H6 >>> sunxi: add support for Allwinner H6 SoC >>> sunxi: add support for Pine H64 board Reviewed-by: Jagan Teki >> >>Observing SPL hang during relocation switch to board_init_r with >>orangepi board[1], will pine boot? look like both seem similar LPDDR3 >>configs atleast from schematics. > > Use v2.1 DRAM patch. Thanks. Tested-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 8/8] armv8: ls1046a: setup SEC ICIDs and fix up device tree
On 7/27/2018 2:18 PM, Bharat Bhushan wrote:
>
>
>> -Original Message-
>> From: laurentiu.tu...@nxp.com [mailto:laurentiu.tu...@nxp.com]
>> Sent: Friday, July 27, 2018 3:28 PM
>> To: u-boot@lists.denx.de; Prabhakar Kushwaha
>> ; York Sun
>> Cc: Bharat Bhushan ; Horia Geanta
>> ; Laurentiu Tudor
>> Subject: [PATCH v5 8/8] armv8: ls1046a: setup SEC ICIDs and fix up device
>> tree
>>
>> From: Laurentiu Tudor
>>
>> Add support for SEC ICID configuration and apply it for ls1046a.
>> Also add code to make the necessary device tree fixups.
>>
>> Signed-off-by: Laurentiu Tudor
>> ---
>> .../arm/cpu/armv8/fsl-layerscape/ls1046_ids.c | 14 +++
>> .../asm/arch-fsl-layerscape/fsl_icid.h| 25 +++
>> .../asm/arch-fsl-layerscape/immap_lsch2.h | 8 ++
>> 3 files changed, 47 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
>> b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
>> index 30c7d8d28a..bc2fe283a1 100644
>> --- a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
>> @@ -40,6 +40,20 @@ struct icid_id_table icid_tbl[] = {
>> SET_EDMA_ICID(FSL_EDMA_STREAM_ID),
>> SET_ETR_ICID(FSL_ETR_STREAM_ID),
>> SET_DEBUG_ICID(FSL_DEBUG_STREAM_ID),
>> +#ifdef CONFIG_FSL_CAAM
>> +SET_SEC_QI_ICID(FSL_DPAA1_STREAM_ID_START + 2),
>> +SET_SEC_JR_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 3),
>> +SET_SEC_JR_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 4),
>> +SET_SEC_JR_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 5),
>> +SET_SEC_JR_ICID_ENTRY(3, FSL_DPAA1_STREAM_ID_START + 6),
>> +SET_SEC_RTIC_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2),
>> +SET_SEC_RTIC_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2),
>> +SET_SEC_RTIC_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2),
>> +SET_SEC_RTIC_ICID_ENTRY(3, FSL_DPAA1_STREAM_ID_START + 2),
>> +SET_SEC_DECO_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2),
>> +SET_SEC_DECO_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2),
>> +SET_SEC_DECO_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2),
>
> Here goes my understanding:
>
> RTIC are independent device from JR and QI, So they should be assigned
> different unique steam-id. Also each RTIC are independent device, so each
> RTIC can also be assigned separate stream-id.
> While we can decide to use one stream-id for all RITCs and add a comment that
> they are not partitionable.
>
> DECOs can take work from QI or JRs, and in that case they will use the
> stream-id of the respective QI or JR, and the stream-id programmed in DECOs
> is not used.
> While DECOs can be used directly (not via JR and QI) and in that case it will
> use the strema-id programmed in it. So in this case also we should be using
> unique stream-id for each DECO if partitionable or one for all DECOs
>
Considering the HW offers the mechanism to program the ICIDs (and assuming the
HW is correctly designed), it follows that these HW blocks could be used
independently.
The only way to implement a *mechanism* is to provide different ICIDs for all
the blocks.
Any other solution would be imposing a *policy*, thus restricting user's
possibilities. Admittedly there are use cases less "popular" than others, but if
possible it would be best not to decide for the user and provide full
flexibility.
Is there a resource (ICID values) shortage?
Thanks,
Horia
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Hi On 07/26/2018 05:14 PM, Tom Rini wrote: > On Thu, Jul 26, 2018 at 09:35:54AM +0200, Marek Vasut wrote: > >> The following changes since commit 323a73adc9a1bf2de43fe03bdd9c3038ce7c2784: >> >>mtd: nand: add new enum for storing ECC algorithm (2018-07-23 14:33:21 >> -0400) >> >> are available in the Git repository at: >> >>git://git.denx.de/u-boot-usb.git master >> >> for you to fetch changes up to 67f1c59f40fde73cb2cbb51ebf0a05156ec403b7: >> >>usb: dwc3: convert to livetree (2018-07-25 00:13:44 +0200) >> > > NAK. This breaks at least: am335x_hs_evm am335x_hs_evm_uart brppt1_spi > brppt1_mmc am335x_evm brppt1_nand and stih410-b2260 I can provide the fix for stih410-b2260. Patrice > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] dm: led: move default state support in led uclass
Hi Patrick,
> From: Patrick Brünn
> Sent: jeudi 26 juillet 2018 12:40
>
> Hi Patrick,
> sorry, for responding so late, I am in the middle of a vacation at the moment.
It is normal in summer time,
I will be also in holiday at end of next week.
> >From: Patrick Delaunay [mailto:patrick.delau...@st.com]
> >Sent: Dienstag, 24. Juli 2018 10:59
> >Subject: [PATCH v3 3/5] dm: led: move default state support in led
> >uclass
> >
...
> >@@ -63,8 +64,61 @@ int led_set_period(struct udevice *dev, int
> >period_ms) } #endif
...
> >+int led_default_state(void)
> >+{
...
> >+ led_set_state(dev, LEDST_OFF);
> >+ printf("%s: default_state=%d\n",
> >+ uc_pdata->label, uc_pdata->default_state);
> Do you really want to keep this printf()?
No it is debug message keep; I need to remove it
> >b/drivers/led/led_gpio.c index 533587d..93f6b91 100644
> >--- a/drivers/led/led_gpio.c
> >+++ b/drivers/led/led_gpio.c
> >@@ -57,7 +57,6 @@ static int led_gpio_probe(struct udevice *dev) {
> > struct led_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
> > struct led_gpio_priv *priv = dev_get_priv(dev);
> >- const char *default_state;
> > int ret;
> >
> > /* Ignore the top-level LED node */ @@ -68,13 +67,6 @@ static
> >int led_gpio_probe(struct udevice *dev)
> > if (ret)
> > return ret;
> >
> >- default_state = dev_read_string(dev, "default-state");
> >- if (default_state) {
> >- if (!strncmp(default_state, "on", 2))
> >- gpio_led_set_state(dev, LEDST_ON);
> >- else if (!strncmp(default_state, "off", 3))
> >- gpio_led_set_state(dev, LEDST_OFF);
> >- }
> Is it necessary to move this code out of led_gpio_probe()?
No really needed but better I think.
I add this parsing during bind to avoid probing of LED drivers
(and so configuration of the associated device as pincontrol, clock, ...)
when the "default-state" node is not present; That avoid potential issue and
it is faster.
In next function, device_probe() is not called when uc_pdata->default_state =
LED_DEF_NO to avoid it.
So I need the information before the probe...
I choose the u_class bind function, because uclass have no ofdata_to_platdata.
> If possible I would keep it here and implement led_default_state() similar to
> mmc_initialize(->mmc_probe()). Than we could avoid enum led_def_state_t and
> the double evaluation of default_state.
I want to have only probed driver in "dm tree" only the LED driver really
initiliazed
And mmc_initialaze which probe all the mmc drivers
Class Probed Driver Name
led[ + ] gpio_led|-- leds
led[ ] gpio_led| |-- iracibble
led[ ] gpio_led| |-- martinet
led[ + ] gpio_led| |-- default_on
led[ + ] gpio_led| `-- default_off
But after double check, I can move all the treatment in led_default_state()
Without changing the behavior and it is is more simple (no enum and double
evaluation).
>
> > return 0;
> > }
> >
> However, this whole v3 series was:
> Tested-by: Patrick Bruenn Beckhoff Automation
> GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered
> office: Verl, Germany | Register court: Guetersloh HRA 7075
>
Thanks for the tests, I will push a v4 with the proposed code simplification.
Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dm: pci: Assign correct driver data when binding a driver
Hi Simon, On Fri, Jul 27, 2018 at 11:51 AM, Bin Meng wrote: > Hi Simon, > > On Fri, Jul 27, 2018 at 8:35 AM, Simon Glass wrote: >> On 25 July 2018 at 03:39, Bin Meng wrote: >>> The correct driver data comes from the matching 'id' instead of >>> 'find_id' in pci_find_and_bind_driver(). >>> >>> Signed-off-by: Bin Meng >>> --- >>> >>> drivers/pci/pci-uclass.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> Reviewed-by: Simon Glass >> >> Perhaps the pci test should be updated to check this. > > I looked at this and found out that the test to > pci_bind_bus_devices(), the API that calls pci_find_and_bind_driver(), > cannot be done due to a chicken and egg issue. > pci_find_and_bind_driver() will only get called if no PCI device is > explicitly declared in the device tree, however: > > - without a emulation device (eg: "sandbox,swap-case") in the device > tree, the emulation device won't be probed, hence pci_config_read() to > the emulation device returns nothing > - without a vendor id & device id from pci_config_read() results, > pci_find_and_bind_driver() won't work. > > Do you have better ideas? > Looks I figured out a way. I will send v2 to include test cases. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/5] Revert "dm: led: auto probe() LEDs with "default-state""
This reverts commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7.
because this patch adds the probe of LED driver during the
binding phasis. It is not allowed in driver model because
the drivers (clock, pincontrol) needed by the LED driver can
be also probed before the binding of all the device and
it is a source of problems.
Signed-off-by: Patrick Delaunay
---
Changes in v4: None
Changes in v3:
- add motivation in revert commit
Changes in v2: None
drivers/led/led_gpio.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index a36942b..533587d 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -10,7 +10,6 @@
#include
#include
#include
-#include
struct led_gpio_priv {
struct gpio_desc gpio;
@@ -118,14 +117,6 @@ static int led_gpio_bind(struct udevice *parent)
return ret;
uc_plat = dev_get_uclass_platdata(dev);
uc_plat->label = label;
-
- if (ofnode_read_bool(node, "default-state")) {
- struct udevice *devp;
-
- ret = uclass_get_device_tail(dev, 0, &devp);
- if (ret)
- return ret;
- }
}
return 0;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/5] stm32mp1: add gpio led support
This patch add the 4 LED available on the ED1 board and activated
gpio led driver.
Reviewed-by: Simon Glass
Signed-off-by: Patrick Delaunay
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 24
configs/stm32mp15_basic_defconfig| 2 ++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index 39a0ebc..4898483 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -13,6 +13,30 @@
mmc1 = &sdmmc2;
i2c3 = &i2c4;
};
+
+ led {
+ compatible = "gpio-leds";
+
+ red {
+ label = "stm32mp:red:status";
+ gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ green {
+ label = "stm32mp:green:user";
+ gpios = <&gpioa 14 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+ orange {
+ label = "stm32mp:orange:status";
+ gpios = <&gpioh 7 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ blue {
+ label = "stm32mp:blue:user";
+ gpios = <&gpiod 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
};
&uart4_pins_a {
diff --git a/configs/stm32mp15_basic_defconfig
b/configs/stm32mp15_basic_defconfig
index c72a440..2cac114 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -29,6 +29,8 @@ CONFIG_CMD_EXT4_WRITE=y
# CONFIG_SPL_DOS_PARTITION is not set
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_STM32F7=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
CONFIG_DM_MMC=y
CONFIG_STM32_SDMMC2=y
# CONFIG_PINCTRL_FULL is not set
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 3/5] dm: led: move default state support in led uclass
This patch save common LED property "default-state" value
in post bind of LED uclass.
The configuration for this default state is only performed when
led_default_state() is called;
It can be called in your board_init()
or it could added in init_sequence_r[] in future.
Signed-off-by: Patrick Delaunay
---
Changes in v4:
- simplify the uclass impact after Patrick Bruenn review
Changes in v3: None
Changes in v2: None
drivers/led/led-uclass.c | 30 ++
drivers/led/led_gpio.c | 8
include/led.h| 9 +
3 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index 2f4d69e..2859475 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -63,6 +64,35 @@ int led_set_period(struct udevice *dev, int period_ms)
}
#endif
+int led_default_state(void)
+{
+ struct udevice *dev;
+ struct uclass *uc;
+ const char *default_state;
+ int ret;
+
+ ret = uclass_get(UCLASS_LED, &uc);
+ if (ret)
+ return ret;
+ for (uclass_find_first_device(UCLASS_LED, &dev);
+dev;
+uclass_find_next_device(&dev)) {
+ default_state = dev_read_string(dev, "default-state");
+ if (!default_state)
+ continue;
+ ret = device_probe(dev);
+ if (ret)
+ return ret;
+ if (!strncmp(default_state, "on", 2))
+ led_set_state(dev, LEDST_ON);
+ else if (!strncmp(default_state, "off", 3))
+ led_set_state(dev, LEDST_OFF);
+ /* default-state = "keep" : device is only probed */
+ }
+
+ return ret;
+}
+
UCLASS_DRIVER(led) = {
.id = UCLASS_LED,
.name = "led",
diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index 533587d..93f6b91 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -57,7 +57,6 @@ static int led_gpio_probe(struct udevice *dev)
{
struct led_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
struct led_gpio_priv *priv = dev_get_priv(dev);
- const char *default_state;
int ret;
/* Ignore the top-level LED node */
@@ -68,13 +67,6 @@ static int led_gpio_probe(struct udevice *dev)
if (ret)
return ret;
- default_state = dev_read_string(dev, "default-state");
- if (default_state) {
- if (!strncmp(default_state, "on", 2))
- gpio_led_set_state(dev, LEDST_ON);
- else if (!strncmp(default_state, "off", 3))
- gpio_led_set_state(dev, LEDST_OFF);
- }
return 0;
}
diff --git a/include/led.h b/include/led.h
index 940b97f..7bfdddf 100644
--- a/include/led.h
+++ b/include/led.h
@@ -106,4 +106,13 @@ enum led_state_t led_get_state(struct udevice *dev);
*/
int led_set_period(struct udevice *dev, int period_ms);
+/**
+ * led_default_state() - set the default state for all the LED
+ *
+ * This enables all leds which have default state.
+ * see Documentation/devicetree/bindings/leds/common.txt
+ *
+ */
+int led_default_state(void);
+
#endif
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/5] stm32mp1: use new function led default state
Initialize the led with the default state defined in device tree. Reviewed-by: Simon Glass Signed-off-by: Patrick Delaunay --- Changes in v4: None Changes in v3: - minor update after Simon review - include led.h to avoid compilation warning on stm32mp1 board Changes in v2: None board/st/stm32mp1/stm32mp1.c | 4 1 file changed, 4 insertions(+) diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c index cc39fa6..bfc8ab6 100644 --- a/board/st/stm32mp1/stm32mp1.c +++ b/board/st/stm32mp1/stm32mp1.c @@ -4,6 +4,7 @@ */ #include #include +#include #include /* @@ -22,5 +23,8 @@ int board_init(void) /* address of boot parameters */ gd->bd->bi_boot_params = STM32_DDR_BASE + 0x100; + if (IS_ENABLED(CONFIG_LED)) + led_default_state(); + return 0; } -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 5/5] sandbox: led: use new function to configure default state
Initialize the led with the default state defined in device tree
in board_init and solve issue with test for led default state.
Reviewed-by: Simon Glass
Signed-off-by: Patrick Delaunay
---
Led default-state is correctly handle in Sandbox, tested with:
./u-boot -d ./arch/sandbox/dts/test.dtb
=> led list
sandbox:red
sandbox:green
sandbox:default_on on
sandbox:default_off off
This patch solve "make tests" issue introduced by
http://patchwork.ozlabs.org/patch/943651/
Changes in v4:
- remove #ifdef CONFIG_LED for sandbox
Changes in v3: None
Changes in v2:
- add sandbox impact and test update
board/sandbox/sandbox.c | 9 +
common/board_r.c| 3 ++-
test/dm/led.c | 3 +++
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index 195f620..0e87674 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -47,6 +48,14 @@ int dram_init(void)
return 0;
}
+int board_init(void)
+{
+ if (IS_ENABLED(CONFIG_LED))
+ led_default_state();
+
+ return 0;
+}
+
#ifdef CONFIG_BOARD_LATE_INIT
int board_late_init(void)
{
diff --git a/common/board_r.c b/common/board_r.c
index 64f2574..9402c0e 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -690,7 +690,8 @@ static init_fnc_t init_sequence_r[] = {
#ifdef CONFIG_DM
initr_dm,
#endif
-#if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV)
+#if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV) || \
+ defined(CONFIG_SANDBOX)
board_init, /* Setup chipselects */
#endif
/*
diff --git a/test/dm/led.c b/test/dm/led.c
index 0071f21..00de7b3 100644
--- a/test/dm/led.c
+++ b/test/dm/led.c
@@ -32,6 +32,9 @@ static int dm_test_led_default_state(struct unit_test_state
*uts)
{
struct udevice *dev;
+ /* configure the default state (auto-probe) */
+ led_default_state();
+
/* Check that we handle the default-state property correctly. */
ut_assertok(led_get_by_label("sandbox:default_on", &dev));
ut_asserteq(LEDST_ON, led_get_state(dev));
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/5] dm: led: remove auto probe in binding function
Hi, The commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7 introduce auto probe of LED in binding function but that cause issue on my board. This first patch of this patchset activateis the LED on my board to explain the issue, the second patch revert this commit and the third one propose an other solution. For me, this commit is a error because in README of doc/driver-model/ it is indicated: The device's bind() method is permitted to perform simple actions, but should not scan the device tree node, not initialise hardware, nor set up structures or allocate memory. All of these tasks should be left for the probe() method. And in the patch the LED driver is probed during the binding scan. When I activated the LED in my ARM target with the patch "stm32mp1: add gpio led support", I have the sequence: dm_init_and_scan() : 1/ dm_scan_fdt_node() => loop on all the node 2/ scan for LED node => probe of LED driver is forced by "default-state" detection LED1 - "red" => probe of father of "red" node A - led B - soc C - root => probe of node needed by GPIO 1 - pin-controller 2 - gpio@50002000 3 - rcc-clk@5000 4 - rcc@5000 => probe forced by default state for other led LED2 - green LED3 - orange => probe of node needed by GPIO (other bank) 5 - gpio@50009000 3/ dm_extended_scan_fdt scan continue... scan node "fixed-clock" under "/clocks" clk-hse clk-hsi clk-lse clk-lsi clk-csi 4/ probe of all the used devices after dm_extended_scan_fdt() So many driver are probed before the end of the scan binding loop ! And that cause issue in my board (boot failed) because the rcc-clk clock driver found the input frequency with these fixed-clock, which are binded only after the stm32mp1 clock driver probe. For me probe in forbidden in binding function and thus uclass_get_device_tail() is not allowed in the commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7 which need to be reverted. In the third patch I proposed an other solution based on the existing solution in u-class regulator used to enable regulator with "boot on" property (see regulators_enable_boot_on function). I think that adding a function is the better solution in the driver model to force probe for some node according binding information (after dm_init_and_scan call). This new function should be called in board_init function for each board but it could be also added in init_sequence_r[] in future. Changes in v4: - simplify the uclass impact after Patrick Bruenn review - remove #ifdef CONFIG_LED for sandbox Changes in v3: - add motivation in revert commit - minor update after Simon review - include led.h to avoid compilation warning on stm32mp1 board Changes in v2: - add sandbox impact and test update Patrick Delaunay (5): stm32mp1: add gpio led support Revert "dm: led: auto probe() LEDs with "default-state"" dm: led: move default state support in led uclass stm32mp1: use new function led default state sandbox: led: use new function to configure default state arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 24 board/sandbox/sandbox.c | 9 + board/st/stm32mp1/stm32mp1.c | 4 common/board_r.c | 3 ++- configs/stm32mp15_basic_defconfig| 2 ++ drivers/led/led-uclass.c | 30 ++ drivers/led/led_gpio.c | 17 - include/led.h| 9 + test/dm/led.c| 3 +++ 9 files changed, 83 insertions(+), 18 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] armv8: ls1088a: change dpl load command from apply to lazyapply
On 06/04/2018 09:36 AM, Jagdish Gediya wrote: > use "fsl_mc lazyapply dpl addr" instead of "fsl_mc apply dpl addr" > > change dpl load addr to 0x80001000 from 0x8020 because dpl gets > corrupted at 0x8020 during bootm command excecution. > > Signed-off-by: Jagdish Gediya > --- > Changes for v2: > - Change dpl load address from 0x8000 to 0x80001000 as boot.scr > is loaded at 0x8000. Applied to fsl-qoriq, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] LS1043ARBD: Fix SD Boot issue with PPA
On 06/06/2018 09:40 PM, Vinitha V Pillai wrote: > CONFIG_SPL_FSL_LS_PPA is needed only in case of falcon boot > Support for this is not present in PPA currently, so > removing the default option from defconfig > > Signed-off-by: Vinitha V Pillai > Signed-off-by: Ruchika Gupta > --- Applied to fsl-qoriq, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls2080ardb: update copyright claim
On 06/18/2018 05:26 AM, Alison Wang wrote: > This patch updates the copyright claim for the issues reported by Legal > Review. > > Signed-off-by: Alison Wang > --- Applied to fsl-qoriq, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] LS1088ARDB: Secure Boot:Change load address of dpl header in SD
On 06/20/2018 06:34 AM, Vinitha V Pillai wrote: > Change address of DPL header in SD > > Signed-off-by: Vinitha V Pillai > --- Applied to fsl-qoriq, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] configs: Disable 4k erase sector size for spansion "s25fs512s" flash
On 06/26/2018 02:19 AM, Ashish Kumar wrote: > 4K erase size is used only in case of hydrid mode which is not > supported on any NXP platform with flash "s25fs512s". > Supported mode is uniform sector, with erase size 256kiB. > > Signed-off-by: Ashish Kumar > --- > v2: > 1. use make savedefconfig > 2. Include LS1012 qspi defconfigs as well > 3. Tested on LS1088ARDB, LS1088AQDS, LS1046ARDB and LS1012ARDB > Applied to fsl-qoriq, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls2088ardb: Move CONFIG_SPI_FLASH, CONFIG_SPI_FLASH_SPANSION to defconfig
On 06/26/2018 04:21 AM, Ashish Kumar wrote: > Move CONFIG_SPI_FLASH_SPANSION, CONFIG_SPI_FLASH, to defconfig. > Also disable disable 4K erase size option. > > Signed-off-by: Ashish Kumar > --- Applied to fsl-qoriq, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: layerscape: Enabled I-cache for SPL boot
On 06/26/2018 02:26 PM, York Sun wrote:
> Enable I-cache for SPL boot to boost performance. Earlier MMU was
> enabled only for LS2080A and has since been dropped by commit
> f539c8a4a7a5 ("armv8: ls2080a: Drop early MMU for SPL build").
>
> Signed-off-by: York Sun
> ---
Applied to fsl-qoriq, awaiting upstream.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v3] armv8: fsl: remove sata support
On 07/13/2018 02:27 AM, andy.t...@nxp.com wrote: > From: Yuantian Tang > > Remove the old implementation in order to enable DM for sata > > Signed-off-by: Tang Yuantian > --- > v3: > - rebase to latest code > v2: > - no changes > This set has been pplied to fsl-qoriq, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/ddr/fsl: fix '__hwconfig without a buffer' messages
On 07/20/2018 03:00 PM, Jeremy Gebben wrote: > Pass an empty buffer instead of NULL if the hwconfig environment > variable isn't set. > > Signed-off-by: Jeremy Gebben > Cc: Stefano Babic > Cc: York Sun > --- Applied to fsl-qoriq, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls1046ardb: Enable IFC for SPL build
On 06/08/2018 04:38 PM, York Sun wrote:
> Commit a52ff334c5b1 ("armv8: ls1046ardb: SPL size reduction") reduced
> image size for SPL. IFC was disabled. If PPA is loaded in SPL, MMU is
> enabled as a result. Removing IFC skips IFC region in the MMU table,
> causing later failure in RAM version U-boot when accessing CPLD
> through IFC. Only disable IFC if PPA is not enabled for SPL.
>
> Signed-off-by: York Sun
> ---
Applied to fsl-qoriq, awaiting upstream.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/2] armv8: layerscape: Drop u-boot-with-spl.bin for selected boards
On 06/14/2018 02:26 PM, York Sun wrote: > For SPL boot with PBL, u-boot-with-spl-pbl.bin is the final image. > Drop unused u-boot-with-spl.bin. > > Signed-off-by: York Sun > CC: Mingkai Hu > CC: Ruchika Gupta > CC: Prabhakar Kushwaha > CC: Udit Agarwal > CC: Sumit Garg > CC: Priyanka Jain > --- > Applied to fsl-qoriq, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] powerpc: mpc85xx: Drop u-boot-with-spl.bin on selected boards
On 06/14/2018 02:26 PM, York Sun wrote: > For SoCs with PBL, u-boot-with-spl-pbl.bin is the final image for > SPL boot. Drop unused u-boot-with-spl.bin. > > Signed-off-by: York Sun > CC: Ashish Kumar > CC: Ruchika Gupta > CC: Priyanka Jain > CC: Shengzhou Liu > Applied to fsl-qoriq, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls1046ardb: ls1046aqds: Move SPL macros to defconfig
On 06/26/2018 09:42 AM, York Sun wrote: > Instead of defining Kconfig macros in header file, move them to > defconfig files. > > Signed-off-by: York Sun > --- Applied to fsl-qoriq, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] spl: Add option SPL_PAYLOAD
On 06/14/2018 02:39 PM, York Sun wrote: > Some legacy boards use RAW image for SPL boot. Add Kconfig option > SPL_PAYLOAD to set alternative image. > > Signed-off-by: York Sun > > --- Applied to fsl-qoriq, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] env: common: load read-only variables after reset
U-Boot fails to load read-only variables from storage after a reset. It
happens because the environment hash table prevents creating read-only
variables unless the H_FORCE flag is passed.
In the following example, the variable "test" is set to read-only in the
board header file (#define CONFIG_ENV_FLAGS_LIST_DEFAULT "test:sr"):
U-Boot> printenv .flags
.flags=test:sr
U-Boot> setenv -f test 1
U-Boot> printenv test
test=1
U-Boot> savee
Saving Environment to SPI Flash
...
OK
U-Boot> reset
...
Loading Environment from SPI Flash...
## Error: Can't create "test"
himport_r: can't insert "test=1" into hash table
...
U-Boot> printenv test
## Error: "test" not defined
Pass the H_FORCE flag when importing the environment from storage.
Signed-off-by: Yaniv Levinsky
---
env/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/env/common.c b/env/common.c
index 3317cef355..de8dd47e9b 100644
--- a/env/common.c
+++ b/env/common.c
@@ -119,7 +119,7 @@ int env_import(const char *buf, int check)
}
}
- if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0, 0,
+ if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', H_FORCE, 0,
0, NULL)) {
gd->flags |= GD_FLG_ENV_READY;
return 0;
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] armv8: layerscape: spl: Initialize QSPI AHB for QSPI boot
On 06/26/2018 02:49 PM, York Sun wrote: > To get full access of QSPI space, initialize AHB interface. > > Signed-off-by: York Sun > --- Applied to fsl-qoriq, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] armv8: ls1046ardb: Add falcon mode for for QSPI boot
On 06/26/2018 02:49 PM, York Sun wrote: > A new defconfig is introduced to support SPL boot from QSPI NOR > flash. This is to support falcon mode for faster booting into > Linux. > > Signed-off-by: York Sun > --- Applied to fsl-qoriq, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull fsl-qoriq master
Tom, The following changes since commit 08fcdd332f3d6bc7842e21a97c80789d9233e147: Makefile: Fix 'clean' target (2018-07-26 07:12:31 -0400) are available in the git repository at: git://git.denx.de/u-boot-fsl-qoriq.git for you to fetch changes up to 86b840b78d0eba652f65841a870d232ab743612e: drivers/ddr/fsl: fix '__hwconfig without a buffer' messages (2018-07-26 11:54:00 -0700) Travis build log is here https://travis-ci.org/yorksun/u-boot/builds/408648511. I see one compiling warning caused by recent commit 68c7025d99db. Alison Wang (1): armv8: ls2080ardb: update copyright claim Ashish Kumar (2): configs: Disable 4k erase sector size for spansion "s25fs512s" flash armv8: ls2088ardb: Move CONFIG_SPI_FLASH, CONFIG_SPI_FLASH_SPANSION to defconfig Jagdish Gediya (1): armv8: ls1088a: change dpl load command from apply to lazyapply Jeremy Gebben (1): drivers/ddr/fsl: fix '__hwconfig without a buffer' messages Vinitha V Pillai (2): LS1043ARBD: Fix SD Boot issue with PPA LS1088ARDB: Secure Boot:Change load address of dpl header in SD York Sun (8): armv8: ls1046ardb: ls1046aqds: Move SPL macros to defconfig armv8: layerscape: Enabled I-cache for SPL boot armv8: ls1046ardb: Enable IFC for SPL build armv8: layerscape: Drop u-boot-with-spl.bin for selected boards powerpc: mpc85xx: Drop u-boot-with-spl.bin on selected boards spl: Add option SPL_PAYLOAD armv8: layerscape: spl: Initialize QSPI AHB for QSPI boot armv8: ls1046ardb: Add falcon mode for for QSPI boot Yuantian Tang (4): armv8: fsl: remove sata support armv8: dts: fsl-ls1012a: add sata node support scsi: ceva: add ls1012a soc support arm64: ls1012a: enable DM support for sata Makefile | 4 +- .../arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 10 +++ arch/arm/cpu/armv8/fsl-layerscape/soc.c| 54 -- arch/arm/cpu/armv8/fsl-layerscape/spl.c| 8 ++ arch/arm/dts/fsl-ls1012a-2g5rdb.dts| 4 + arch/arm/dts/fsl-ls1012a-qds.dtsi | 4 + arch/arm/dts/fsl-ls1012a-rdb.dtsi | 4 + arch/arm/dts/fsl-ls1012a.dtsi | 8 ++ arch/arm/include/asm/arch-fsl-layerscape/soc.h | 35 + board/freescale/ls1046ardb/ls1046ardb_qspi_pbi.cfg | 26 +++ board/freescale/ls1046ardb/ls1046ardb_rcw_qspi.cfg | 7 ++ board/freescale/ls2080ardb/ls2080ardb.c| 2 +- common/spl/Kconfig | 10 +++ configs/ls1012a2g5rdb_qspi_defconfig | 7 +- configs/ls1012afrdm_qspi_defconfig | 1 + configs/ls1012aqds_qspi_defconfig | 8 +- configs/ls1012ardb_qspi_SECURE_BOOT_defconfig | 8 +- configs/ls1012ardb_qspi_defconfig | 8 +- configs/ls1043ardb_sdcard_defconfig| 1 - configs/ls1046aqds_qspi_defconfig | 1 + configs/ls1046aqds_sdcard_ifc_defconfig| 8 ++ configs/ls1046aqds_sdcard_qspi_defconfig | 9 +++ configs/ls1046ardb_emmc_defconfig | 8 ++ configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1046ardb_qspi_defconfig | 1 + configs/ls1046ardb_qspi_spl_defconfig | 65 configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig| 8 ++ configs/ls1046ardb_sdcard_defconfig| 8 ++ configs/ls1088aqds_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088aqds_qspi_defconfig | 1 + configs/ls1088aqds_sdcard_qspi_defconfig | 1 + configs/ls1088ardb_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_qspi_defconfig | 1 + .../ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_sdcard_qspi_defconfig | 1 + configs/ls2088ardb_qspi_SECURE_BOOT_defconfig | 3 + configs/ls2088ardb_qspi_defconfig | 3 + drivers/ata/sata_ceva.c| 87 +- drivers/ddr/fsl/options.c | 14 ++-- include/configs/B4860QDS.h | 1 - include/configs/T102xQDS.h | 1 - include/configs/T102xRDB.h | 1 - include/configs/T104xRDB.h | 1 - include/configs/T208xQDS.h | 1 - include/configs/T208xRDB.h | 1 - include/configs/T4240QDS.h | 1 - include/configs/T4240RDB.h | 1 - include/configs/ls1043a_common.h | 2 - include/configs/ls1046a_common.h | 32 include/configs/ls1046ardb.h | 12 ++- include/configs/ls1088a_common.h | 11 ++- include/configs/ls1088ardb.h
[U-Boot] [PATCH] video: sunxi: de2: fix SimpleFB node creation when DE2 not probed
Sometimes when a monitor without EDID information is plugged, the DE2
won't be probed (because of lack of timing information), but the HDMI
node is probed, thus a SimpleFB node with invalid information will be
populated.
Also detect whether DE2 is probed when creating SimpleFB node.
Fixes: be5b96f0e411 ("sunxi: setup simplefb for Allwinner DE2")
Signed-off-by: Icenowy Zheng
---
drivers/video/sunxi/sunxi_de2.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/sunxi/sunxi_de2.c b/drivers/video/sunxi/sunxi_de2.c
index 4ed035d556..8333ddc44c 100644
--- a/drivers/video/sunxi/sunxi_de2.c
+++ b/drivers/video/sunxi/sunxi_de2.c
@@ -347,6 +347,9 @@ int sunxi_simplefb_setup(void *blob)
if (ret) {
debug("DE2 not present\n");
return 0;
+ } else if (!device_active(de2)) {
+ debug("DE2 present but not probed\n");
+ return 0;
}
ret = uclass_find_device_by_name(UCLASS_DISPLAY,
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request, u-boot-tegra/master
On Thu, Jul 26, 2018 at 02:08:33PM -0700, Tom Warren wrote: > Tom, > > Please pull u-boot-tegra/master into U-Boot/master. Thanks! > > All Tegra builds are OK, and Stephen's automated test system reports that > all tests pass. > > The following changes since commit 2547e91dc15e5203e15d4ebde9172174743b14a7: > > tegra: Indicate that binman makes all three output files (2018-07-26 > 15:49:40 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-tegra.git master > > for you to fetch changes up to 2eea1269166fd3dccc319629e612edddcd650803: > > tegra: beaver/apalis: Fix DTC warning (2018-07-26 13:15:31 -0700) > 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] Please pull u-boot-dm
On Thu, Jul 26, 2018 at 06:36:12PM -0600, Simon Glass wrote: > Hi Tom, > > Just a few small things. > > > The following changes since commit 0dd1fc09bb16869fd8adaaad082cd554c60b2c1a: > > board/imgtec/boston: Add new defconfigs to the MAINTAINERS list > (2018-07-20 15:55:10 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git > > for you to fetch changes up to ab948cd21d25ba2f54832fc98a59eea90e680eba: > > fdt_support: make FDT_FIXUP_PARTITIONS depend on CMD_MTDPARTS (2018-07-26 > 14:20:27 -0600) > 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 request: u-boot-net.git master
On Thu, Jul 26, 2018 at 02:12:06PM -0500, Joe Hershberger wrote: > Hi Tom, > > All tests are passing: https://travis-ci.org/jhershbe/u-boot/builds/408198713 > > The following changes since commit 08fcdd332f3d6bc7842e21a97c80789d9233e147: > > Makefile: Fix 'clean' target (2018-07-26 07:12:31 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-net.git master > > for you to fetch changes up to 26026e695afa794ac018a09e79a48120d322b60d: > > net: zynq_gem: convert to use livetree (2018-07-26 14:08:23 -0500) > 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] [PATCH] openrd: Once again shrink binary size
On Fri, Jul 27, 2018 at 07:59:31AM -0400, Tom Rini wrote: > With some recent changes to relevant drivers here the openrd board > (openrd_client in this case) does not fit within its size constraint. > We can however drop the slightly extended baudrate table and then the > duplication of mtdparts/mtdids in the default environment. These > defaults are set in the environment by the 'mtdparts' command and > otherwise referenced throughout the code. > > Signed-off-by: Tom Rini 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] [PATCH V2 00/32] i.MX: Add i.MX8QXP support
On 7/27/2018 12:54 AM, Peng Fan wrote: > Hi All, > > I plan to send out V3 early next week. QXP BETA2 has been external released, > so there will be update in README including link to scfw images. > Paste the link here first: > https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-sc-firmware-0.7.bin, use > mx8qx-mek-scfw-tcm.bin for b0 chip. > > Troy, Fabio, Stefano, > > I would like to still keep CONFIG_IMX8, not CONFIG_MX8. Do you have concerns? > > Thanks, > Peng. > I like consistency, but I would not mind changing CONFIG_MX* to CONFIG_IMX* as well. Would it be possibly to change CONFIG_ARCH_MX* to CONFIG_IMX* as well ? I never know which to use when. Linux mainline seems to use CONFIG_SOC_IMX6=y CONFIG_SOC_IMX6Q=y CONFIG_SOC_IMX6SL=y CONFIG_SOC_IMX6SLL=y CONFIG_SOC_IMX6SX=y CONFIG_SOC_IMX6UL=y so maybe changing to that format has merit. But I'll be happy with whatever is decided, as long as the reasons are on record. Troy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] sata: fix sata_Probe return value check
sata_probe returns 1 for failure, so don't checkout for < 0
fixes: f19f1ecb6025 dm: sata: Support driver model with the 'sata' command
Signed-off-by: Troy Kisky
diff --git a/cmd/sata.c b/cmd/sata.c
index cc12afb07e..4f0c6e0137 100644
--- a/cmd/sata.c
+++ b/cmd/sata.c
@@ -107,8 +107,8 @@ static int do_sata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
/* If the user has not yet run `sata init`, do it now */
if (sata_curr_device == -1) {
rc = sata_probe(0);
- if (rc < 0)
- return CMD_RET_FAILURE;
+ if (rc)
+ return rc;
sata_curr_device = 0;
}
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/32] i.MX: Add i.MX8QXP support
> -Original Message- > From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] > Sent: 2018年7月28日 1:58 > To: Peng Fan ; sba...@denx.de; Fabio Estevam > ; Anatolij Gustschin > Cc: u-boot@lists.denx.de; dl-linux-imx > Subject: Re: [PATCH V2 00/32] i.MX: Add i.MX8QXP support > > On 7/27/2018 12:54 AM, Peng Fan wrote: > > Hi All, > > > > I plan to send out V3 early next week. QXP BETA2 has been external released, > so there will be update in README including link to scfw images. > > Paste the link here first: > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.n > xp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2Fimx-sc-firmware-0.7.bin&am > p;data=02%7C01%7Cpeng.fan%40nxp.com%7C52c05286470740a94b8108d5f3 > ea8460%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63668311092 > 8936620&sdata=F%2B5oZqolFv22cWbgAS2CZu4YL4iS%2FhtpKt4MT8DJsQ > U%3D&reserved=0, use mx8qx-mek-scfw-tcm.bin for b0 chip. > > > > Troy, Fabio, Stefano, > > > > I would like to still keep CONFIG_IMX8, not CONFIG_MX8. Do you have > concerns? > > > > Thanks, > > Peng. > > > > I like consistency, but I would not mind changing CONFIG_MX* to CONFIG_IMX* > as well. i.MX6/7 could be the next to be converted. > Would it be possibly to change CONFIG_ARCH_MX* to CONFIG_IMX* as well ? > I never know which to use when. There is no difference now I think. In Linux side there is CONFIG_ARCH_MXC for i.mx6/7/5. In u-boot, each SOC family has its own CONFIG_ARCH_MX*. That could be cleaned up to use CONFIG_IMX* I think. Thanks, Peng. > > Linux mainline seems to use > CONFIG_SOC_IMX6=y > CONFIG_SOC_IMX6Q=y > CONFIG_SOC_IMX6SL=y > CONFIG_SOC_IMX6SLL=y > CONFIG_SOC_IMX6SX=y > CONFIG_SOC_IMX6UL=y > > so maybe changing to that format has merit. > > > But I'll be happy with whatever is decided, as long as the reasons are on > record. > > Troy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
