Re: [U-Boot] [PATCH 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now[Please note, mail behalf by 3vnmnxammciszqnjoyvtpbt.vynrlcly.fhunyvjr-jopwz....@chromium-sendgmr.bounces.google.com]
Hi Simon,
On 12/29/2018 09:16 PM, Simon Glass wrote:
> This function causes a 5-second delay and stops the display working on
> minnie.
I don't understand why need 5-second, the logic is to check the adc key
press to decide the mode, maybe because the different usage of the adc
in minnie?
Most of boards(which do not have ec like chromebook) need this check to
get into download mode.
I would prefer chrombook to implement a function to replace the week
rockchip_dnl_mode_check();
Thanks,
- Kever
> This code should be in a driver and should only be enabled by
> a device-tree property, so that it does not affect devices which do not
> have this feature.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/mach-rockchip/boot_mode.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-rockchip/boot_mode.c
> b/arch/arm/mach-rockchip/boot_mode.c
> index f32b3c4ce56..d7997d71e30 100644
> --- a/arch/arm/mach-rockchip/boot_mode.c
> +++ b/arch/arm/mach-rockchip/boot_mode.c
> @@ -61,7 +61,13 @@ int setup_boot_mode(void)
> void *reg = (void *)CONFIG_ROCKCHIP_BOOT_MODE_REG;
> int boot_mode = readl(reg);
>
> - rockchip_dnl_mode_check();
> + /*
> + * This should be handled using a driver-tree property and a suitable
> + * driver which can read the appropriate settings. As it is, this
> + * breaks chromebook_minnie.\
> + *
> + * rockchip_dnl_mode_check();
> + */
>
> boot_mode = readl(reg);
> debug("%s: boot mode 0x%08x\n", __func__, boot_mode);
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10
On Thu, 2019-01-03 at 06:27 +0100, Marek Vasut wrote:
> On 1/3/19 6:07 AM, Chee, Tien Fong wrote:
> >
> > On Tue, 2019-01-01 at 21:27 +0100, Marek Vasut wrote:
> > >
> > > On 1/1/19 4:10 AM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Sun, 2018-12-30 at 16:46 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: Tien Fong Chee
> > > > > >
> > > > > > This patch adds description on properties about file name
> > > > > > used
> > > > > > for
> > > > > > both
> > > > > > peripheral bitstream and core bitstream.
> > > > > >
> > > > > > Signed-off-by: Tien Fong Chee
> > > > > > ---
> > > > > > .../fpga/altera-socfpga-a10-fpga-mgr.txt | 21
> > > > > >
> > > > > > 1 files changed, 21 insertions(+), 0 deletions(-)
> > > > > >
> > > > > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-
> > > > > > a10-
> > > > > > fpga-
> > > > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > fpga-
> > > > > > mgr.txt
> > > > > > index 2fd8e7a..4552edc 100644
> > > > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > fpga-
> > > > > > mgr.txt
> > > > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > fpga-
> > > > > > mgr.txt
> > > > > > @@ -7,13 +7,34 @@ Required properties:
> > > > > > - The second index is for writing FPGA
> > > > > > configuration data.
> > > > > > - resets : Phandle and reset specifier for the
> > > > > > device's
> > > > > > reset.
> > > > > > - clocks : Clocks used by the device.
> > > > > > +- altr,bitstream : File name for FPGA peripheral raw
> > > > > > binary
> > > > > > which
> > > > > > is used
> > > > > > + to initialize FPGA IOs, PLL, IO48 and
> > > > > > DDR.
> > > > > > + or
> > > > > > + File name for full RBF, consist of
> > > > > > periph
> > > > > > RBF
> > > > > > and core RBF
> > > > > > +- altr,bitstream-core : File name for core RBF which
> > > > > > contains
> > > > > > FPGA
> > > > > > design
> > > > > > + which is used to program FPGA CRAM
> > > > > > and
> > > > > > ERAM.
> > > > > >
> > > > > > Example:
> > > > > >
> > > > > > +- Examples for booting with early IO release, enter early
> > > > > > user
> > > > > > mode(periph RBF):
> > > > > > +
> > > > > > + fpga_mgr: fpga-mgr@ffd03000 {
> > > > > > + compatible = "altr,socfpga-a10-fpga-mgr";
> > > > > > + reg = <0xffd03000 0x100
> > > > > > + 0xffcfe400 0x20>;
> > > > > > + clocks = <&l4_mp_clk>;
> > > > > > + resets = <&rst FPGAMGR_RESET>;
> > > > > > + altr,bitstream =
> > > > > > "ghrd_10as066n2.periph.rbf.mkimage";
> > > > > > + altr,bitstream-core =
> > > > > > "ghrd_10as066n2.core.rbf.mkimage";
> > > > > What is this .mkimage format about ? Is that uImage ? Since
> > > > > it's
> > > > > two
> > > > > files, it could probably be bundled into fitImage instead ?
> > > > >
> > > > What is this .mkimage format about ? Is that uImage ?
> > > > mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n
> > > > \"RBF\"
> > > > -d
> > > > ghrd_10as066n2.periph.rbf ghrd_10as066n2.periph.rbf.mkimage.
> > > > Yeah, this is uImage. The reason of using it for appending the
> > > > header
> > > > contains file size and CRC checksum to the
> > > > ghrd_10as066n2.periph.rbf.
> > > > These both file size and CRC checksum are required in socfpga
> > > > loadfs
> > > > driver.
> > > CRC32 is real weak. fitImage supports all kinds of more fitting
> > > checksum
> > > algorithms and more.
> > Okay.
> > >
> > >
> > > >
> > > >
> > > > Since it's two> files, it could probably be bundled into
> > > > fitImage
> > > > instead ?
> > > > I assume you are saying the series fitImage implementation
> > > > patches
> > > > as i
> > > > had previously submitted which contains U-Boot, and FPGA core
> > > > bitstream
> > > > in fitImage.
> > > No, just bundle the bitstream in a fitImage if it's multiple
> > > files
> > > and
> > > if it makes sense.
> > I need to explore 1st what's already supported in mainstream for
> > loading bitstream in a fitImage. That's would be good if you have
> > ideas
> > and details of implementation to share out.
> > >
> > >
> > > >
> > > >
> > > > core bitstream can be bundled into fitImage, with the file
> > > > name as ghrd_10as066n2.core.rbf, without mkimage, so this
> > > > bitstream
> > > > would be loadded into DDR with function fpga load instead of
> > > > fpga
> > > > loadfs. ghrd_10as066n2.periph.rbf.mkimage is separate file
> > > > required
> > > > for
> > > > getting DDR up 1st before loading fitImage.
> > > Does that mean you only need to load one of the files (you can do
> > > that
> > > with fitImage too) ? But then, what's the point of specifying
> > > both in
> > > the DT if only one is needed ?
> > Here
Re: [U-Boot] [PATCH v1 07/14] pinctrl: imx: Replace static soc info definitions with run time allocations
On Wed, 2 Jan 2019 15:14:22 +0100
Marek Vasut wrote:
> On 1/2/19 9:26 AM, Lukasz Majewski wrote:
> > Hi Marek,
> >
> >> On 1/2/19 12:37 AM, Lukasz Majewski wrote:
> >>> This commit is necessary to be able to re-use the pinctrl code in
> >>> early SPL to properly configure pins.
> >>>
> >>> The problem is that those "static" structures are placed in the
> >>> SDRAM area, which corresponds to u-boot proper (not even SPL).
> >>> Hence, when one wants to configure pins before relocation via
> >>> DTS/DM, the board hangs (imx6q SoC powered one) as only OCRAM area
> >>> is available (0x009x).
> >>>
> >>> It is also safe to use calloc in this case, as the early SPL code
> >>> provides it - either full or trimmed version. The allocated memory
> >>> is also correct in respect to the memory area in which the SoC is
> >>> currently running (OCRAM vs. SDRAM).
> >>
> >> You should be able to access static data in early environment, many
> >> other drivers have no problem with it.
> >
> > Have you used pinctrl IMX6Q driver with early DM at SPL?
> >
> >> I believe there is some more
> >> fundamental problem that needs to be fixed,
> >
> > With the current code - which was not used in OCRAM only available
> > memory - the statics are placed in the SDRAM area (0x178x ).
> >
> > Instead of changing linker script (and validate it for all drivers
> > and boards for SPL and u-boot proper) - the code has been rewritten
> > to use malloc (which is available in the early code - either full
> > blown or simple version).
> >
> >> hacking around it like
> >> this is just hiding the real issue.
> >
> > The real issue is that IMX6Q uses SDRAM memory for statics/globals
> > from the very beginning.
> Fix it ? What you're implying here is that rodata (preinitialized
> static variables) are misplaced.
>
The not initialized (as going to be zeroed)
static struct imx_pinctrl_soc_info imx6_pinctrl_soc_info;
goes to bss section, which is located in SDRAM (not available yet).
.bss.imx6_pinctrl_soc_info
0x18200050 0x10 drivers/built-in.o
The other structs in this file, as they have assigned values, are placed
correctly in data (OCRAM area).
I could add __attribute__((section("data"))) in front of this
definition, but this may be a problematic for u-boot proper where this
code is reused (and correctly this data is placed in bss).
Hence, the idea to use calloc explicitly - and with it the correct
(available in the moment) memory is provided.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgp8LVMI2a_01.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 v2] misc: fs_loader: Add support for initializing MMC
On Sun, 2018-12-30 at 09:36 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> Firmware loader would encounter problem if the MMC is accessed before
> initializing it. This patch would adding the support of probing block
> device and initializing MMC before the MMC is accessed by firmware
> loader.
>
> Signed-off-by: Tien Fong Chee
> ---
>
> Changes in v2:
> - Initializing MMC through probing the blk device
Any comment for this patch?
> ---
> drivers/misc/fs_loader.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index 57a14a3..5858073 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> DECLARE_GLOBAL_DATA_PTR;
> @@ -252,6 +253,38 @@ static int fs_loader_ofdata_to_platdata(struct
> udevice *dev)
>
> static int fs_loader_probe(struct udevice *dev)
> {
> +#if defined(CONFIG_DM_MMC) && defined(CONFIG_BLK)
> + int ret;
> + struct device_platdata *plat = dev->platdata;
> +
> + ret = mmc_initialize(NULL);
> + if (ret) {
> + debug("MMC: could not initialize mmc. error: %d\n",
> ret);
> +
> + return ret;
> + }
> +
> + if (plat->phandlepart.phandle) {
> + ofnode node = ofnode_get_by_phandle(plat-
> >phandlepart.phandle);
> +
> + struct udevice *mmc_dev = NULL;
> +
> + ret = device_get_global_by_ofnode(node, &mmc_dev);
> + if (!ret) {
> + struct mmc *mmc = mmc_get_mmc_dev(mmc_dev);
> + struct udevice *dev;
> +
> + ret = blk_get_from_parent(mmc->dev, &dev);
> + if (ret) {
> + debug("MMC: No block device: %d\n",
> + ret);
> +
> + return ret;
> + }
> + }
> + }
> +#endif
> +
> return 0;
> };
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting on RK3399[Please note, mail behalf by s...@google.com]
Hi Simon, It's great to know you would like to support kevin. What we need is ATF instead of OP-TEE, which should be the same one used by Chrome OS support by coreboot, The guide is here and firefly-rk3399 re-use most of evb-rk3399 follow with defconfig use firefly-rk3399_defconfig: board/rockchip/evb_rk3399/README BTW: I would like to enable TPL for RK3399, and also for other SoCs like rk3288, so that we can have a common boot flow, I have done in my local branch. Thanks, - Kever On 01/03/2019 09:15 AM, Simon Glass wrote: > Hi Kever, > > I have a firefly-rk3399 and would like to boot it into U-Boot (as a > start) from an uSD card. > > Are there instructions somewhere on how to do this? I gather that I > need OP-TEE but not how to build it or how to put the image together. > I would like to have instructions in README.rockchip if possible. > > I'm planning to add U-Boot support for bob and maybe kevin (both > Chromebooks) but am not sure where to start. I thought the firefly > might be best since it is pretty common. > > Thanks for any help you can provide. > > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms
Hi Jagan,
> On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot
> wrote:
> >
> >
> > On 29/12/2018 19:49, Jagan Teki wrote:
> > > On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki
> > > wrote:
> > >> On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot
> > >> wrote: Better to have proper commit head that
> > >> tells the real issue.
> >
> > I found it hard to come up with a short description of the real
> > issue.
> >
> > At least this title makes it clear that it is a regression fix, not
> > a new feature.
> >
> > The details of the failures are in the commit log (or so I thought)
> >
> > >>
> > >>> Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for
> > >>> USB gadget devices")
> > >>>
> > >>> The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be
> > >>> declared even for platforms that do not enable DM_USB_GADGET.
> > >>> Otherwise the driver for their usb peripheral controller fails
> > >>> to bind.
> > >> Sorry this is unclear, you are trying to skip DM_USB_GADGET code
> > >> even though UCLASS_USB_GADGET_GENERIC id used. does it make
> > >> sense?
> >
> > Sorry for the delay. This was indeed a vacation time.
> >
> > This patch does not skip DM_USB_GADGET. What it does is declare the
> > UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is
> > not set.
> >
> > DM_USB_GADGET is a new option and not (yet) widely used and some
> > drivers have their own version of the DM support for gadget drivers
> > (ie they implement their own version of usb_gadget_initialize(),
> > usb_gadget_release() and usb_gadget_handle_interrupts()). However
> > all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and
> > thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be
> > declared. In the past they used UCLASS_USB_DEV_GENERIC, but this
> > option is intended for the host side.
>
> Acked-by: Jagan Teki
>
> Marek, any comments?
Yes, lets wait for Marek's comment and I will prepare PR (to Marek),
which also includes some other fixes.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgptbJYjnWV0Y.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] dm: arm: imx: migrate cx9020 to CONFIG_DM_MMC
From: Patrick Bruenn
Enable esdhc1/2 device nodes for cx9020 and build with CONFIG_DM_MMC=y
Signed-off-by: Patrick Bruenn
---
arch/arm/dts/imx53-cx9020.dts | 52 +++
configs/mx53cx9020_defconfig | 1 +
2 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/arch/arm/dts/imx53-cx9020.dts b/arch/arm/dts/imx53-cx9020.dts
index c2e7d86c1b8..36ceae36aa9 100644
--- a/arch/arm/dts/imx53-cx9020.dts
+++ b/arch/arm/dts/imx53-cx9020.dts
@@ -99,20 +99,6 @@
MX53_PAD_KEY_COL1__AUDMUX_AUD5_TXFS
0x8000
MX53_PAD_KEY_ROW1__AUDMUX_AUD5_RXD
0x8000
- MX53_PAD_SD1_DATA0__ESDHC1_DAT0 0x1d5
- MX53_PAD_SD1_DATA1__ESDHC1_DAT1 0x1d5
- MX53_PAD_SD1_DATA2__ESDHC1_DAT2 0x1d5
- MX53_PAD_SD1_DATA3__ESDHC1_DAT3 0x1d5
- MX53_PAD_SD1_CMD__ESDHC1_CMD0x1d5
- MX53_PAD_SD1_CLK__ESDHC1_CLK0x1d5
-
- MX53_PAD_SD2_DATA0__ESDHC2_DAT0 0x1d5
- MX53_PAD_SD2_DATA1__ESDHC2_DAT1 0x1d5
- MX53_PAD_SD2_DATA2__ESDHC2_DAT2 0x1d5
- MX53_PAD_SD2_DATA3__ESDHC2_DAT3 0x1d5
- MX53_PAD_SD2_CMD__ESDHC2_CMD0x1d5
- MX53_PAD_SD2_CLK__ESDHC2_CLK0x1d5
-
MX53_PAD_FEC_MDC__FEC_MDC 0x4
MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
MX53_PAD_FEC_REF_CLK__FEC_TX_CLK0x180
@@ -162,6 +148,28 @@
>;
};
+ pinctrl_esdhc1: esdhc1grp {
+ fsl,pins = <
+ MX53_PAD_SD1_DATA0__ESDHC1_DAT0 0x1d5
+ MX53_PAD_SD1_DATA1__ESDHC1_DAT1 0x1d5
+ MX53_PAD_SD1_DATA2__ESDHC1_DAT2 0x1d5
+ MX53_PAD_SD1_DATA3__ESDHC1_DAT3 0x1d5
+ MX53_PAD_SD1_CMD__ESDHC1_CMD0x1d5
+ MX53_PAD_SD1_CLK__ESDHC1_CLK0x1d5
+ >;
+ };
+
+ pinctrl_esdhc2: esdhc2grp {
+ fsl,pins = <
+ MX53_PAD_SD2_DATA0__ESDHC2_DAT0 0x1d5
+ MX53_PAD_SD2_DATA1__ESDHC2_DAT1 0x1d5
+ MX53_PAD_SD2_DATA2__ESDHC2_DAT2 0x1d5
+ MX53_PAD_SD2_DATA3__ESDHC2_DAT3 0x1d5
+ MX53_PAD_SD2_CMD__ESDHC2_CMD0x1d5
+ MX53_PAD_SD2_CLK__ESDHC2_CLK0x1d5
+ >;
+ };
+
pinctrl_uart2: uart2grp {
fsl,pins = <
MX53_PAD_EIM_D26__UART2_RXD_MUX 0x1e4
@@ -181,6 +189,22 @@
status = "okay";
};
+&esdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_esdhc1>;
+ cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&esdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_esdhc2>;
+ cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ status = "okay";
+};
+
&fec {
pinctrl-names = "default";
phy-mode = "rmii";
diff --git a/configs/mx53cx9020_defconfig b/configs/mx53cx9020_defconfig
index 3cff52031a0..ddd65e8ee15 100644
--- a/configs/mx53cx9020_defconfig
+++ b/configs/mx53cx9020_defconfig
@@ -19,6 +19,7 @@ CONFIG_CMD_EXT2=y
CONFIG_CMD_EXT4=y
CONFIG_CMD_FAT=y
CONFIG_CMD_FS_GENERIC=y
+CONFIG_DM_MMC=y
CONFIG_OF_CONTROL=y
CONFIG_DEFAULT_DEVICE_TREE="imx53-cx9020"
CONFIG_ENV_IS_IN_MMC=y
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] mmc: fsl_esdhc: add compatible for fsl, imx53-esdhc
From: Patrick Bruenn
Add compatible "fsl,imx53-esdhc" to keep mmc working on i.MX53 platforms
with CONFIG_DM_MMC=y
Signed-off-by: Patrick Bruenn
---
drivers/mmc/fsl_esdhc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 3cdfa7f5a68..ff912645f05 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -1579,6 +1579,7 @@ static struct esdhc_soc_data usdhc_imx7d_data = {
};
static const struct udevice_id fsl_esdhc_ids[] = {
+ { .compatible = "fsl,imx53-esdhc", },
{ .compatible = "fsl,imx6ul-usdhc", },
{ .compatible = "fsl,imx6sx-usdhc", },
{ .compatible = "fsl,imx6sl-usdhc", },
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] arm: imx: Add esdhc1/2 nodes to imx53.dtsi
From: Patrick Bruenn
These nodes are required by CX9020 when build with CONFIG_DM_MMC=y
They are copied from Linux 4.20
Signed-off-by: Patrick Bruenn
---
arch/arm/dts/imx53.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/dts/imx53.dtsi b/arch/arm/dts/imx53.dtsi
index 64591f9d476..e13009c8708 100644
--- a/arch/arm/dts/imx53.dtsi
+++ b/arch/arm/dts/imx53.dtsi
@@ -31,6 +31,8 @@
i2c0 = &i2c1;
i2c1 = &i2c2;
i2c2 = &i2c3;
+ mmc0 = &esdhc1;
+ mmc1 = &esdhc2;
};
tzic: tz-interrupt-controller@fffc000 {
@@ -54,6 +56,38 @@
reg = <0x5000 0x1000>;
ranges;
+ spba@5000 {
+ compatible = "fsl,spba-bus", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x5000 0x4>;
+ ranges;
+
+ esdhc1: esdhc@50004000 {
+ compatible = "fsl,imx53-esdhc";
+ reg = <0x50004000 0x4000>;
+ interrupts = <1>;
+ clocks = <&clks
IMX5_CLK_ESDHC1_IPG_GATE>,
+<&clks IMX5_CLK_DUMMY>,
+<&clks
IMX5_CLK_ESDHC1_PER_GATE>;
+ clock-names = "ipg", "ahb", "per";
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ esdhc2: esdhc@50008000 {
+ compatible = "fsl,imx53-esdhc";
+ reg = <0x50008000 0x4000>;
+ interrupts = <2>;
+ clocks = <&clks
IMX5_CLK_ESDHC2_IPG_GATE>,
+<&clks IMX5_CLK_DUMMY>,
+<&clks
IMX5_CLK_ESDHC2_PER_GATE>;
+ clock-names = "ipg", "ahb", "per";
+ bus-width = <4>;
+ status = "disabled";
+ };
+ };
+
iomuxc: iomuxc@53fa8000 {
compatible = "fsl,imx53-iomuxc";
reg = <0x53fa8000 0x4000>;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] Migrate i.MX53 based cx9020 to CONFIG_DM_MMC=y
From: Patrick Bruenn This series is based on v2019.01-rc2. It enables compatible "fsl,imx53-esdhc" for fsl_esdhc driver and copies esdhc1 and esdhc2 device tree nodes from Linux 4.20 into imx53.dtsi. The last patch enables these nodes for imx53-cx9020.dts and adds CONFIG_DM_MMC=y for mx53cx9020_defconfig. I have no other imx53 platform available for testing, but I could add esdhc3/4 and convert more imx53 boards, if wanted. Patrick Bruenn (3): mmc: fsl_esdhc: add compatible for fsl,imx53-esdhc arm: imx: Add esdhc1/2 nodes to imx53.dtsi dm: arm: imx: migrate cx9020 to CONFIG_DM_MMC arch/arm/dts/imx53-cx9020.dts | 52 +++ arch/arm/dts/imx53.dtsi | 34 configs/mx53cx9020_defconfig | 1 + drivers/mmc/fsl_esdhc.c | 1 + 4 files changed, 74 insertions(+), 14 deletions(-) -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10
On Thu, 2019-01-03 at 06:27 +0100, Marek Vasut wrote:
> On 1/3/19 6:07 AM, Chee, Tien Fong wrote:
> >
> > On Tue, 2019-01-01 at 21:27 +0100, Marek Vasut wrote:
> > >
> > > On 1/1/19 4:10 AM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Sun, 2018-12-30 at 16:46 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: Tien Fong Chee
> > > > > >
> > > > > > This patch adds description on properties about file name
> > > > > > used
> > > > > > for
> > > > > > both
> > > > > > peripheral bitstream and core bitstream.
> > > > > >
> > > > > > Signed-off-by: Tien Fong Chee
> > > > > > ---
> > > > > > .../fpga/altera-socfpga-a10-fpga-mgr.txt | 21
> > > > > >
> > > > > > 1 files changed, 21 insertions(+), 0 deletions(-)
> > > > > >
> > > > > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-
> > > > > > a10-
> > > > > > fpga-
> > > > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > fpga-
> > > > > > mgr.txt
> > > > > > index 2fd8e7a..4552edc 100644
> > > > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > fpga-
> > > > > > mgr.txt
> > > > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > fpga-
> > > > > > mgr.txt
> > > > > > @@ -7,13 +7,34 @@ Required properties:
> > > > > > - The second index is for writing FPGA
> > > > > > configuration data.
> > > > > > - resets : Phandle and reset specifier for the
> > > > > > device's
> > > > > > reset.
> > > > > > - clocks : Clocks used by the device.
> > > > > > +- altr,bitstream : File name for FPGA peripheral raw
> > > > > > binary
> > > > > > which
> > > > > > is used
> > > > > > + to initialize FPGA IOs, PLL, IO48 and
> > > > > > DDR.
> > > > > > + or
> > > > > > + File name for full RBF, consist of
> > > > > > periph
> > > > > > RBF
> > > > > > and core RBF
> > > > > > +- altr,bitstream-core : File name for core RBF which
> > > > > > contains
> > > > > > FPGA
> > > > > > design
> > > > > > + which is used to program FPGA CRAM
> > > > > > and
> > > > > > ERAM.
> > > > > >
> > > > > > Example:
> > > > > >
> > > > > > +- Examples for booting with early IO release, enter early
> > > > > > user
> > > > > > mode(periph RBF):
> > > > > > +
> > > > > > + fpga_mgr: fpga-mgr@ffd03000 {
> > > > > > + compatible = "altr,socfpga-a10-fpga-mgr";
> > > > > > + reg = <0xffd03000 0x100
> > > > > > + 0xffcfe400 0x20>;
> > > > > > + clocks = <&l4_mp_clk>;
> > > > > > + resets = <&rst FPGAMGR_RESET>;
> > > > > > + altr,bitstream =
> > > > > > "ghrd_10as066n2.periph.rbf.mkimage";
> > > > > > + altr,bitstream-core =
> > > > > > "ghrd_10as066n2.core.rbf.mkimage";
> > > > > What is this .mkimage format about ? Is that uImage ? Since
> > > > > it's
> > > > > two
> > > > > files, it could probably be bundled into fitImage instead ?
> > > > >
> > > > What is this .mkimage format about ? Is that uImage ?
> > > > mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n
> > > > \"RBF\"
> > > > -d
> > > > ghrd_10as066n2.periph.rbf ghrd_10as066n2.periph.rbf.mkimage.
> > > > Yeah, this is uImage. The reason of using it for appending the
> > > > header
> > > > contains file size and CRC checksum to the
> > > > ghrd_10as066n2.periph.rbf.
> > > > These both file size and CRC checksum are required in socfpga
> > > > loadfs
> > > > driver.
> > > CRC32 is real weak. fitImage supports all kinds of more fitting
> > > checksum
> > > algorithms and more.
> > Okay.
> > >
> > >
> > > >
> > > >
> > > > Since it's two> files, it could probably be bundled into
> > > > fitImage
> > > > instead ?
> > > > I assume you are saying the series fitImage implementation
> > > > patches
> > > > as i
> > > > had previously submitted which contains U-Boot, and FPGA core
> > > > bitstream
> > > > in fitImage.
> > > No, just bundle the bitstream in a fitImage if it's multiple
> > > files
> > > and
> > > if it makes sense.
> > I need to explore 1st what's already supported in mainstream for
> > loading bitstream in a fitImage. That's would be good if you have
> > ideas
> > and details of implementation to share out.
> > >
> > >
> > > >
> > > >
> > > > core bitstream can be bundled into fitImage, with the file
> > > > name as ghrd_10as066n2.core.rbf, without mkimage, so this
> > > > bitstream
> > > > would be loadded into DDR with function fpga load instead of
> > > > fpga
> > > > loadfs. ghrd_10as066n2.periph.rbf.mkimage is separate file
> > > > required
> > > > for
> > > > getting DDR up 1st before loading fitImage.
> > > Does that mean you only need to load one of the files (you can do
> > > that
> > > with fitImage too) ? But then, what's the point of specifying
> > > both in
> > > the DT if only one is needed ?
> > Here
Re: [U-Boot] [PATCH 3/6] ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK
On Tue, 2019-01-01 at 21:29 +0100, Marek Vasut wrote: > On 1/1/19 4:32 AM, Chee, Tien Fong wrote: > > > > On Sun, 2018-12-30 at 16:47 +0100, Marek Vasut wrote: > > > > > > On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote: > > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > Update the default configuration file to enable the necessary > > > > functionality > > > > to get the SoCFPGA loadfs driver support. This would enable the > > > > implementation of programming bitstream into FPGA from MMC. > > > > > > > > Signed-off-by: Tien Fong Chee > > > > --- > > > > configs/socfpga_arria10_defconfig |8 > > > > 1 files changed, 8 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/configs/socfpga_arria10_defconfig > > > > b/configs/socfpga_arria10_defconfig > > > > index 6ebda81..8158dbb 100644 > > > > --- a/configs/socfpga_arria10_defconfig > > > > +++ b/configs/socfpga_arria10_defconfig > > > > @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" > > > > # CONFIG_EFI_PARTITION is not set > > > > CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" > > > > CONFIG_ENV_IS_IN_MMC=y > > > > +CONFIG_SPL_ENV_SUPPORT=y > > > > CONFIG_SPL_DM=y > > > > CONFIG_SPL_DM_SEQ_ALIAS=y > > > > +CONFIG_SPL_DM_MMC=y > > > > +CONFIG_SPL_MMC_SUPPORT=y > > > > +CONFIG_SPL_EXT_SUPPORT=y > > > > +CONFIG_SPL_FAT_SUPPORT=y > > > > +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y > > > > +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 > > > This breaks systems with large FAT clusters. Why is this needed > > > for > > > programming the FPGA from MMC ? > > This is final tuning in term of getting balance between performance > > and > > SPL image size for the socdk devkit. User can change that if they > > need > > large FAT cluster in their design, right? > I think it'd rather make sense to fix the FAT driver to avoid > statically > allocating those massive buffers for big clusters. I think that can > be > done by allocating those on stack instead ... or mallocating them. I need to explore 1st as i'm not familiar with FAT driver. Or can we temporary keeping this patch 1st until FAT issue is separately fixed? > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Add support for loading FPGA bitstream
On Tue, 2019-01-01 at 21:36 +0100, Marek Vasut wrote: > On 1/1/19 3:52 AM, Chee, Tien Fong wrote: > > > > On Sun, 2018-12-30 at 16:44 +0100, Marek Vasut wrote: > > > > > > On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote: > > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > These series of patches enable peripheral bitstream being > > > > programmed into FPGA > > > > to get the DDR up running. This's also called early IO release, > > > > because the > > > > peripheral bitstream is only initializing FPGA IOs, PLL, IO48 > > > > and > > > > DDR. > > > > > > > > Once DDR is up running, core bitstream from MMC which contains > > > > user > > > > FPGA > > > > design would be loaded into DDR location. socfpga loadfs would > > > > be > > > > called to > > > > program core bitstream into FPGA and entering user mode. > > > > > > > > Lastly, u-boot-dtb.img from MMC FAT partition would be loaded > > > > to > > > > DDR, and up > > > > running from there. > > > > > > > > For this whole mechanism to work, the SDMMC flash layout would > > > > be > > > > designed as > > > > shown in below: > > > > > > > > RAW partition: > > > > 1. spl_w_dtb-mkpimage.bin > > > > mkpimage -hv 1 -o spl/spl_w_dtb-mkpimage.bin spl/u-boot-spl- > > > > dtb.bin > > > > spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl- > > > > dtb.bin > > > > > > > > FAT partition contains: > > > > Bitstreams > > > > -- > > > > Early IO release method is recommended for the sake of > > > > performance, > > > > improve > > > > up to 86% compare to full RBF. > > > > > > > > 1. ghrd_10as066n2.periph.rbf.mkimage > > > > mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n > > > > \"RBF\" > > > > -d > > > > ghrd_10as066n2.periph.rbf ghrd_10as066n2.periph.rbf.mkimage > > > > > > > > 2. ghrd_10as066n2.core.rbf.mkimage > > > > mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n > > > > \"RBF\" > > > > -d > > > > ghrd_10as066n2.core.rbf ghrd_10as066n2.core.rbf.mkimage > > > > > > > > OR > > > > > > > > 1. ghrd_10as066n2.rbf.mkimage (full RBF) > > > > mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n > > > > \"RBF\" > > > > -d > > > > ghrd_10as066n2.rbf ghrd_10as066n2.rbf.mkimage > > > > > > > > U-Boot image > > > > > > > > 3. u-boot-dtb.img > > > > > > > > For the testing purpose, these two patches are required to > > > > apply > > > > 1st before > > > > applying this series of patches. > > > > 1. [U-Boot] [PATCH] misc: fs_loader: Switching private data > > > > allocation to DM > > > > auto allocation > > > > https://www.mail-archive.com/u-boot@lists.denx.de/msg308954. > > > > html > > > > Reviewed-by: Simon Glass > > > > > > > > 2. [U-Boot] [PATCH v2] Add support for initializing MMC > > > > https://www.mail-archive.com/u-boot@lists.denx.de/msg310532. > > > > html > > > > Version 2 under review. > > > The above should be made into documentation, since cover letters > > > are > > > dropped. > > Happy new year Marek. > Happy New Year to you too. > > > > > Yeah, the document would be sent out once the implementation is > > finalized. Hence, we need your mercy and help to get this done :-P, > > just kidding. > I hope you can wrap this into V7 . Sure. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On Tue, 2019-01-01 at 21:31 +0100, Marek Vasut wrote:
> On 1/1/19 4:39 AM, Chee, Tien Fong wrote:
> >
> > On Sun, 2018-12-30 at 16:51 +0100, Marek Vasut wrote:
> > >
> > > On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > > >
> > > >
> > > > From: Tien Fong Chee
> > > >
> > > > Add support for loading FPGA bitstream to get DDR up running
> > > > before
> > > > U-Boot is loaded into DDR. Boot device initialization, generic
> > > > firmware
> > > > loader and SPL FAT support are required for this whole
> > > > mechanism to
> > > > work.
> > > >
> > > > Signed-off-by: Tien Fong Chee
> > > > ---
> > > > arch/arm/mach-socfpga/spl_a10.c | 46
> > > > ++-
> > > > 1 files changed, 45 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-
> > > > socfpga/spl_a10.c
> > > > index 3ea64f7..93f5f46 100644
> > > > --- a/arch/arm/mach-socfpga/spl_a10.c
> > > > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > > > @@ -1,6 +1,6 @@
> > > > // SPDX-License-Identifier: GPL-2.0+
> > > > /*
> > > > - * Copyright (C) 2012 Altera Corporation
> > > > + * Copyright (C) 2012-2018 Altera Corporation > > > >
> > > > */
> > > >
> > > > #include
> > > > @@ -23,9 +23,14 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > +#include
> > > >
> > > > DECLARE_GLOBAL_DATA_PTR;
> > > >
> > > > +#define FPGA_SOCFGA_A10_RBF_CORE_LOAD_DDR (1 * 1024)
> > > > +#define FPGA_SOCFGA_A10_RBF_CORE_BUFFER_SIZE (40 * 1024
> > > > *
> > > > 1024)
> > > > +
> > > > static const struct socfpga_system_manager *sysmgr_regs =
> > > > (struct socfpga_system_manager
> > > > *)SOCFPGA_SYSMGR_ADDRESS;
> > > >
> > > > @@ -73,6 +78,45 @@ void spl_board_init(void)
> > > > WATCHDOG_RESET();
> > > >
> > > > arch_early_init_r();
> > > > +
> > > > + /* If the full FPGA is already loaded, ie.from EPCQ,
> > > > config fpga pins */
> > > > + if (is_fpgamgr_user_mode()) {
> > > > + config_pins(gd->fdt_blob, "shared");
> > > > + config_pins(gd->fdt_blob, "fpga");
> > > What happens if config_pins() fails ? The function returns some
> > > return
> > > value.
> > There is return value for config_pins, i can add the debug print
> > out
> > for the return value.
> And if the function fails, for whatever reason, what does that mean
> for
> the system ? Does the system fail ? I think so, right ?
Unexpected behavior. I can put the hang here or you got better idea?
>
> >
> > >
> > > >
> > > > + } else if (!is_fpgamgr_early_user_mode()) {
> > > > + /* Program IOSSM(early IO release) or full
> > > > FPGA */
> > > > + fpga_fs_info fpga_fsinfo;
> > > > + int len;
> > > > + char buf[16 * 1024]
> > > > __aligned(ARCH_DMA_MINALIGN);
> > > > +
> > > > + fpga_fsinfo.filename = (char
> > > > *)get_fpga_filename(
> > > Is the cast needed ?
> > there is a warning
> > arch/arm/mach-socfpga/spl_a10.c:109:24: warning: assignment
> > discards
> > 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
> > fpga_fsinfo.filename = get_fpga_filename(
> Which tells you that you're forcibly turning a string which the
> compiler
> assumes to be constant into one which is not. You're missing const
> somewhere or you need to remove it from somewhere.
Yes, i can fix it.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10
On 1/3/19 6:07 AM, Chee, Tien Fong wrote:
> On Tue, 2019-01-01 at 21:27 +0100, Marek Vasut wrote:
>> On 1/1/19 4:10 AM, Chee, Tien Fong wrote:
>>>
>>> On Sun, 2018-12-30 at 16:46 +0100, Marek Vasut wrote:
On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
>
>
> From: Tien Fong Chee
>
> This patch adds description on properties about file name used
> for
> both
> peripheral bitstream and core bitstream.
>
> Signed-off-by: Tien Fong Chee
> ---
> .../fpga/altera-socfpga-a10-fpga-mgr.txt | 21
>
> 1 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> fpga-
> mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> fpga-
> mgr.txt
> index 2fd8e7a..4552edc 100644
> --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> mgr.txt
> +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> mgr.txt
> @@ -7,13 +7,34 @@ Required properties:
> - The second index is for writing FPGA
> configuration data.
> - resets : Phandle and reset specifier for the device's
> reset.
> - clocks : Clocks used by the device.
> +- altr,bitstream : File name for FPGA peripheral raw binary
> which
> is used
> + to initialize FPGA IOs, PLL, IO48 and DDR.
> + or
> + File name for full RBF, consist of periph
> RBF
> and core RBF
> +- altr,bitstream-core : File name for core RBF which contains
> FPGA
> design
> + which is used to program FPGA CRAM and
> ERAM.
>
> Example:
>
> +- Examples for booting with early IO release, enter early user
> mode(periph RBF):
> +
> + fpga_mgr: fpga-mgr@ffd03000 {
> + compatible = "altr,socfpga-a10-fpga-mgr";
> + reg = <0xffd03000 0x100
> + 0xffcfe400 0x20>;
> + clocks = <&l4_mp_clk>;
> + resets = <&rst FPGAMGR_RESET>;
> + altr,bitstream =
> "ghrd_10as066n2.periph.rbf.mkimage";
> + altr,bitstream-core =
> "ghrd_10as066n2.core.rbf.mkimage";
What is this .mkimage format about ? Is that uImage ? Since it's
two
files, it could probably be bundled into fitImage instead ?
>>> What is this .mkimage format about ? Is that uImage ?
>>> mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n \"RBF\"
>>> -d
>>> ghrd_10as066n2.periph.rbf ghrd_10as066n2.periph.rbf.mkimage.
>>> Yeah, this is uImage. The reason of using it for appending the
>>> header
>>> contains file size and CRC checksum to the
>>> ghrd_10as066n2.periph.rbf.
>>> These both file size and CRC checksum are required in socfpga
>>> loadfs
>>> driver.
>> CRC32 is real weak. fitImage supports all kinds of more fitting
>> checksum
>> algorithms and more.
> Okay.
>>
>>>
>>> Since it's two> files, it could probably be bundled into fitImage
>>> instead ?
>>> I assume you are saying the series fitImage implementation patches
>>> as i
>>> had previously submitted which contains U-Boot, and FPGA core
>>> bitstream
>>> in fitImage.
>> No, just bundle the bitstream in a fitImage if it's multiple files
>> and
>> if it makes sense.
> I need to explore 1st what's already supported in mainstream for
> loading bitstream in a fitImage. That's would be good if you have ideas
> and details of implementation to share out.
>>
>>>
>>> core bitstream can be bundled into fitImage, with the file
>>> name as ghrd_10as066n2.core.rbf, without mkimage, so this bitstream
>>> would be loadded into DDR with function fpga load instead of fpga
>>> loadfs. ghrd_10as066n2.periph.rbf.mkimage is separate file required
>>> for
>>> getting DDR up 1st before loading fitImage.
>> Does that mean you only need to load one of the files (you can do
>> that
>> with fitImage too) ? But then, what's the point of specifying both in
>> the DT if only one is needed ?
> Here is the description of the flow based on the previous submitted
> series patches for setting up the DDR with
> periph.rbf.mkimage(standalone file), then followed by the core.rbf in
> fitImage loading into DDR for programming user design into FPGA. The
> implementation of loading core.rbf in fitImage into DDR is already
> supported in the common code, and programming into FPGA through a
> function called fpga load(which requires DDR get up running 1st).
So the core.rbf is optional ? I think you can try looking at mkimage -E
, which would allow you to do partial image loading in SPL.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10
On Tue, 2019-01-01 at 21:27 +0100, Marek Vasut wrote:
> On 1/1/19 4:10 AM, Chee, Tien Fong wrote:
> >
> > On Sun, 2018-12-30 at 16:46 +0100, Marek Vasut wrote:
> > >
> > > On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > > >
> > > >
> > > > From: Tien Fong Chee
> > > >
> > > > This patch adds description on properties about file name used
> > > > for
> > > > both
> > > > peripheral bitstream and core bitstream.
> > > >
> > > > Signed-off-by: Tien Fong Chee
> > > > ---
> > > > .../fpga/altera-socfpga-a10-fpga-mgr.txt | 21
> > > >
> > > > 1 files changed, 21 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > fpga-
> > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > fpga-
> > > > mgr.txt
> > > > index 2fd8e7a..4552edc 100644
> > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > > > mgr.txt
> > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > > > mgr.txt
> > > > @@ -7,13 +7,34 @@ Required properties:
> > > > - The second index is for writing FPGA
> > > > configuration data.
> > > > - resets : Phandle and reset specifier for the device's
> > > > reset.
> > > > - clocks : Clocks used by the device.
> > > > +- altr,bitstream : File name for FPGA peripheral raw binary
> > > > which
> > > > is used
> > > > + to initialize FPGA IOs, PLL, IO48 and DDR.
> > > > + or
> > > > + File name for full RBF, consist of periph
> > > > RBF
> > > > and core RBF
> > > > +- altr,bitstream-core : File name for core RBF which contains
> > > > FPGA
> > > > design
> > > > + which is used to program FPGA CRAM and
> > > > ERAM.
> > > >
> > > > Example:
> > > >
> > > > +- Examples for booting with early IO release, enter early user
> > > > mode(periph RBF):
> > > > +
> > > > + fpga_mgr: fpga-mgr@ffd03000 {
> > > > + compatible = "altr,socfpga-a10-fpga-mgr";
> > > > + reg = <0xffd03000 0x100
> > > > + 0xffcfe400 0x20>;
> > > > + clocks = <&l4_mp_clk>;
> > > > + resets = <&rst FPGAMGR_RESET>;
> > > > + altr,bitstream =
> > > > "ghrd_10as066n2.periph.rbf.mkimage";
> > > > + altr,bitstream-core =
> > > > "ghrd_10as066n2.core.rbf.mkimage";
> > > What is this .mkimage format about ? Is that uImage ? Since it's
> > > two
> > > files, it could probably be bundled into fitImage instead ?
> > >
> > What is this .mkimage format about ? Is that uImage ?
> > mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n \"RBF\"
> > -d
> > ghrd_10as066n2.periph.rbf ghrd_10as066n2.periph.rbf.mkimage.
> > Yeah, this is uImage. The reason of using it for appending the
> > header
> > contains file size and CRC checksum to the
> > ghrd_10as066n2.periph.rbf.
> > These both file size and CRC checksum are required in socfpga
> > loadfs
> > driver.
> CRC32 is real weak. fitImage supports all kinds of more fitting
> checksum
> algorithms and more.
Okay.
>
> >
> > Since it's two> files, it could probably be bundled into fitImage
> > instead ?
> > I assume you are saying the series fitImage implementation patches
> > as i
> > had previously submitted which contains U-Boot, and FPGA core
> > bitstream
> > in fitImage.
> No, just bundle the bitstream in a fitImage if it's multiple files
> and
> if it makes sense.
I need to explore 1st what's already supported in mainstream for
loading bitstream in a fitImage. That's would be good if you have ideas
and details of implementation to share out.
>
> >
> > core bitstream can be bundled into fitImage, with the file
> > name as ghrd_10as066n2.core.rbf, without mkimage, so this bitstream
> > would be loadded into DDR with function fpga load instead of fpga
> > loadfs. ghrd_10as066n2.periph.rbf.mkimage is separate file required
> > for
> > getting DDR up 1st before loading fitImage.
> Does that mean you only need to load one of the files (you can do
> that
> with fitImage too) ? But then, what's the point of specifying both in
> the DT if only one is needed ?
Here is the description of the flow based on the previous submitted
series patches for setting up the DDR with
periph.rbf.mkimage(standalone file), then followed by the core.rbf in
fitImage loading into DDR for programming user design into FPGA. The
implementation of loading core.rbf in fitImage into DDR is already
supported in the common code, and programming into FPGA through a
function called fpga load(which requires DDR get up running 1st).
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
On Tue, 2019-01-01 at 21:27 +0100, Marek Vasut wrote: > On 1/1/19 4:28 AM, Chee, Tien Fong wrote: > > > > On Sun, 2018-12-30 at 16:45 +0100, Marek Vasut wrote: > > > > > > On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote: > > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > Add FPGA driver to support program FPGA with FPGA bitstream > > > > loading > > > > from > > > > filesystem. The driver are designed based on generic firmware > > > > loader > > > > framework. The driver can handle FPGA program operation from > > > > loading FPGA > > > > bitstream in flash to memory and then to program FPGA. > > > > > > > > Signed-off-by: Tien Fong Chee > > > What changed from V5 in each of those patches ? > > > > > I assume you are saying the v5 i had submmited in 2017. > > > > The major changes i have made are: > > 1. Stripping of the "fpga loadfs" command support layer on U-Boot > > console because the DDR would be corrupted if FPGA is reprogrammed. > > 2. Minor restructure and codes clean up such as understandable name > > for > > functions. > > 3. Using finalized generic firmware loader interface in this > > driver. > This should be in the changelog. Okay. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] configs: update TFABOOT defconfigs for SD boot support
update TFABOOT defconfig for SD boot on below NXP chasis2 and chasis3 platforms: ls1043a, ls1046a, ls1088a and ls2088a. Signed-off-by: Rajesh Bhagat --- Depends on: https://patchwork.ozlabs.org/project/uboot/list/?series=83635 configs/ls1043aqds_tfa_defconfig | 1 + configs/ls1043ardb_tfa_defconfig | 1 + configs/ls1046aqds_tfa_defconfig | 1 + configs/ls1046ardb_tfa_defconfig | 1 + configs/ls1088aqds_tfa_defconfig | 1 + configs/ls1088ardb_tfa_defconfig | 1 + configs/ls2088aqds_tfa_defconfig | 1 + configs/ls2088ardb_tfa_defconfig | 1 + 8 files changed, 8 insertions(+) diff --git a/configs/ls1043aqds_tfa_defconfig b/configs/ls1043aqds_tfa_defconfig index 6fa0418044..a255236758 100644 --- a/configs/ls1043aqds_tfa_defconfig +++ b/configs/ls1043aqds_tfa_defconfig @@ -32,6 +32,7 @@ CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-qds-duart" CONFIG_ENV_IS_IN_FLASH=y CONFIG_ENV_IS_IN_NAND=y CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_ENV_IS_IN_MMC=y CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_FSL_CAAM=y diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index 662a966ebe..3cae0f2356 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -26,6 +26,7 @@ CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-rdb" CONFIG_ENV_IS_IN_FLASH=y CONFIG_ENV_IS_IN_NAND=y +CONFIG_ENV_IS_IN_MMC=y CONFIG_DM=y CONFIG_FSL_CAAM=y CONFIG_DM_MMC=y diff --git a/configs/ls1046aqds_tfa_defconfig b/configs/ls1046aqds_tfa_defconfig index 44c5ca5b30..2412e7ee43 100644 --- a/configs/ls1046aqds_tfa_defconfig +++ b/configs/ls1046aqds_tfa_defconfig @@ -33,6 +33,7 @@ CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-qds-duart" CONFIG_ENV_IS_IN_FLASH=y CONFIG_ENV_IS_IN_NAND=y CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_ENV_IS_IN_MMC=y CONFIG_DM=y CONFIG_FSL_CAAM=y CONFIG_DM_MMC=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index d6595eb246..0533b61b6b 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -26,6 +26,7 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=155.quadspi:1m(rcw),15m(u-boot),48m(kernel CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-rdb" CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_ENV_IS_IN_MMC=y CONFIG_DM=y CONFIG_FSL_CAAM=y CONFIG_FSL_ESDHC=y diff --git a/configs/ls1088aqds_tfa_defconfig b/configs/ls1088aqds_tfa_defconfig index 08744dda2d..857362bb01 100644 --- a/configs/ls1088aqds_tfa_defconfig +++ b/configs/ls1088aqds_tfa_defconfig @@ -33,6 +33,7 @@ CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1088a-qds" CONFIG_ENV_IS_IN_FLASH=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_ENV_IS_IN_NAND=y +CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SCSI_AHCI=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 3328af430d..01fa13c7a8 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -29,6 +29,7 @@ CONFIG_MP=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1088a-rdb" CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SCSI_AHCI=y diff --git a/configs/ls2088aqds_tfa_defconfig b/configs/ls2088aqds_tfa_defconfig index 3a523f74be..b04796cbb7 100644 --- a/configs/ls2088aqds_tfa_defconfig +++ b/configs/ls2088aqds_tfa_defconfig @@ -32,6 +32,7 @@ CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="fsl-ls2080a-qds" CONFIG_ENV_IS_IN_FLASH=y CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_FSL_CAAM=y diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index bb5e4f8bb5..016d8bcdb6 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -33,6 +33,7 @@ CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="fsl-ls2088a-rdb-qspi" CONFIG_ENV_IS_IN_FLASH=y CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_FSL_CAAM=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] env: fix allow to build multiple environments
Patch fixes build error when enabling CONFIG_ENV_IS_IN_SPI_FLASH and CONFIG_ENV_IS_IN_MMC at the same time mentioned issue in below link: Refer: https://lists.denx.de/pipermail/u-boot/2018-February/319565.html build error when enabling CONFIG_ENV_IS_IN_SPI_FLASH and CONFIG_ENV_IS_IN_MMC at the same time. Signed-off-by: Rajesh Bhagat --- Depends on: https://patchwork.ozlabs.org/project/uboot/list/?series=83635 include/environment.h | 9 - include/mmc.h | 3 +++ 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/include/environment.h b/include/environment.h index 7da1291d5b..cd96676141 100644 --- a/include/environment.h +++ b/include/environment.h @@ -162,15 +162,6 @@ extern const unsigned char default_environment[]; extern void env_reloc(void); #endif -#ifdef CONFIG_ENV_IS_IN_MMC -#include - -extern int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr); -# ifdef CONFIG_SYS_MMC_ENV_PART -extern uint mmc_get_env_part(struct mmc *mmc); -# endif -#endif - #ifndef DO_DEPS_ONLY #include diff --git a/include/mmc.h b/include/mmc.h index 95548e94c4..d84e4fca73 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -828,6 +828,9 @@ void board_mmc_power_init(void); int board_mmc_init(bd_t *bis); int cpu_mmc_init(bd_t *bis); int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr); +# ifdef CONFIG_SYS_MMC_ENV_PART +extern uint mmc_get_env_part(struct mmc *mmc); +# endif int mmc_get_env_dev(void); /* Set block count limit because of 16 bit register limit on some hardware*/ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] update TFABOOT defconfigs for SD boot support
- Fixes the MMC environment issue - updates TFABOOT defconfigs for SD boot support Rajesh Bhagat (2): env: fix allow to build multiple environments configs: update TFABOOT defconfigs for SD boot support configs/ls1043aqds_tfa_defconfig | 1 + configs/ls1043ardb_tfa_defconfig | 1 + configs/ls1046aqds_tfa_defconfig | 1 + configs/ls1046ardb_tfa_defconfig | 1 + configs/ls1088aqds_tfa_defconfig | 1 + configs/ls1088ardb_tfa_defconfig | 1 + configs/ls2088aqds_tfa_defconfig | 1 + configs/ls2088ardb_tfa_defconfig | 1 + include/environment.h| 9 - include/mmc.h| 3 +++ 10 files changed, 11 insertions(+), 9 deletions(-) -- Depends on: https://patchwork.ozlabs.org/project/uboot/list/?series=83635 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting on RK3399
HI Mark,
On Wed, 2 Jan 2019 at 18:50, Mark Kettenis wrote:
>
> > From: Simon Glass
> > Date: Wed, 2 Jan 2019 18:15:31 -0700
> >
> > Hi Kever,
> >
> > I have a firefly-rk3399 and would like to boot it into U-Boot (as a start)
> > from an uSD card.
> >
> > Are there instructions somewhere on how to do this? I gather that I need
> > OP-TEE but not how to build it or how to put the image together. I would
> > like to have instructions in README.rockchip if possible.
> >
> > I'm planning to add U-Boot support for bob and maybe kevin (both
> > Chromebooks) but am not sure where to start. I thought the firefly might be
> > best since it is pretty common.
>
> Hi Simon,
>
> The instructions in board/u-boot/rockchip/evb_rk3399/README apply to
> the firefly-rk3399 as well. I've successfully built working firmware
> for my board using the TF-A (ATF) 2.0 release and U-Boot SPL in the
> past that way.
Thanks for the pointer. That was the file I was looking for and I
didn't think to look at the evb.
>
> One complication with the firefly board is that by default it boots
> from eMMC, so you can't easily test new firmware by putting it on uSD
> card unless you make the eMMC unbootable somehow (e.g. by overwriting
> the start of the eMMC storage with zeroes). In that case you can boot
> from uSD card if you write U-Boot SPL and U-Boot proper at the right
> offsets:
>
> # dd if=idbspl.img of=/dev/sd1c seek=64
> # dd if=u-boot.itb of=/dev/sd1c seek=16384
>
> (that's on OpenBSD, on Linux the device names will be different)
Yes I did that with my board, so it already boots from uSD.
>
> Haven't tested flashing eMMC with rkdeveloptool myself, but that
> should work on the firefly as well.
>
> Another complication as that the serial console speed defaults to
> 150 which isn't supported by all serial-to-USB chips and frankly
Yes I seem to have one that supports this, so this is fine.
> too sensitive to wire noise. Also be aware that TF-A built from the
> official ARM sources at
>
> https://github.com/ARM-software/arm-trusted-firmware.git
>
> defaults to 115200 (which is more reasonable IMHO). So I have the
> following diff in my U-Boot tree. The device tree change comes in
> handy if you want to boot from uSD card, otherwise U-Boot SPL will
> attempt to load the full U-Boot from eMMC. Perhaps that bit should be
> committed at some point.
>
> Having support for bob would be great. I have one, and would like to
> make OpenBSD run on it.
OK well I think I'll start with an existing board and then see what is needed.
Regards,
Simon
>
> Cheers,
>
> Mark
>
>
> diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
> index be350866a7..f90e7e88db 100644
> --- a/arch/arm/dts/rk3399-firefly.dts
> +++ b/arch/arm/dts/rk3399-firefly.dts
> @@ -15,7 +15,7 @@
>
> chosen {
> stdout-path = &uart2;
> - u-boot,spl-boot-order = &sdhci, &sdmmc;
> + u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
> };
>
> backlight: backlight {
> diff --git a/configs/firefly-rk3399_defconfig
> b/configs/firefly-rk3399_defconfig
> index 7ac4064a8b..01b3a0771f 100644
> --- a/configs/firefly-rk3399_defconfig
> +++ b/configs/firefly-rk3399_defconfig
> @@ -58,7 +58,7 @@ CONFIG_REGULATOR_RK8XX=y
> CONFIG_PWM_ROCKCHIP=y
> CONFIG_RAM=y
> CONFIG_SPL_RAM=y
> -CONFIG_BAUDRATE=150
> +CONFIG_BAUDRATE=115200
> CONFIG_DEBUG_UART_SHIFT=2
> CONFIG_SYSRESET=y
> CONFIG_USB=y
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC
The LogicPD board uses a Micron Flash with ECC. To boot this from SPL, the ECC needs to be correctly configured or the BCH engine times out. Signed-off-by: Adam Ford diff --git a/drivers/mtd/nand/raw/mxs_nand.c b/drivers/mtd/nand/raw/mxs_nand.c index e3341812a2..2d84bfffe2 100644 --- a/drivers/mtd/nand/raw/mxs_nand.c +++ b/drivers/mtd/nand/raw/mxs_nand.c @@ -1163,6 +1163,12 @@ int mxs_nand_init_spl(struct nand_chip *nand) nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE; nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE; + + if (is_mx6sx() || is_mx7()) + nand_info->max_ecc_strength_supported = 62; + else + nand_info->max_ecc_strength_supported = 40; + err = mxs_nand_alloc_buffers(nand_info); if (err) return err; diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c b/drivers/mtd/nand/raw/mxs_nand_spl.c index c628f3adec..ba85baac60 100644 --- a/drivers/mtd/nand/raw/mxs_nand_spl.c +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c @@ -201,6 +201,7 @@ static int mxs_nand_init(void) /* setup flash layout (does not scan as we override that) */ mtd->size = nand_chip.chipsize; nand_chip.scan_bbt(mtd); + mxs_nand_setup_ecc(mtd); return 0; } -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting on RK3399
> From: Simon Glass
> Date: Wed, 2 Jan 2019 18:15:31 -0700
>
> Hi Kever,
>
> I have a firefly-rk3399 and would like to boot it into U-Boot (as a start)
> from an uSD card.
>
> Are there instructions somewhere on how to do this? I gather that I need
> OP-TEE but not how to build it or how to put the image together. I would
> like to have instructions in README.rockchip if possible.
>
> I'm planning to add U-Boot support for bob and maybe kevin (both
> Chromebooks) but am not sure where to start. I thought the firefly might be
> best since it is pretty common.
Hi Simon,
The instructions in board/u-boot/rockchip/evb_rk3399/README apply to
the firefly-rk3399 as well. I've successfully built working firmware
for my board using the TF-A (ATF) 2.0 release and U-Boot SPL in the
past that way.
One complication with the firefly board is that by default it boots
from eMMC, so you can't easily test new firmware by putting it on uSD
card unless you make the eMMC unbootable somehow (e.g. by overwriting
the start of the eMMC storage with zeroes). In that case you can boot
from uSD card if you write U-Boot SPL and U-Boot proper at the right
offsets:
# dd if=idbspl.img of=/dev/sd1c seek=64
# dd if=u-boot.itb of=/dev/sd1c seek=16384
(that's on OpenBSD, on Linux the device names will be different)
Haven't tested flashing eMMC with rkdeveloptool myself, but that
should work on the firefly as well.
Another complication as that the serial console speed defaults to
150 which isn't supported by all serial-to-USB chips and frankly
too sensitive to wire noise. Also be aware that TF-A built from the
official ARM sources at
https://github.com/ARM-software/arm-trusted-firmware.git
defaults to 115200 (which is more reasonable IMHO). So I have the
following diff in my U-Boot tree. The device tree change comes in
handy if you want to boot from uSD card, otherwise U-Boot SPL will
attempt to load the full U-Boot from eMMC. Perhaps that bit should be
committed at some point.
Having support for bob would be great. I have one, and would like to
make OpenBSD run on it.
Cheers,
Mark
diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
index be350866a7..f90e7e88db 100644
--- a/arch/arm/dts/rk3399-firefly.dts
+++ b/arch/arm/dts/rk3399-firefly.dts
@@ -15,7 +15,7 @@
chosen {
stdout-path = &uart2;
- u-boot,spl-boot-order = &sdhci, &sdmmc;
+ u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
};
backlight: backlight {
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index 7ac4064a8b..01b3a0771f 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -58,7 +58,7 @@ CONFIG_REGULATOR_RK8XX=y
CONFIG_PWM_ROCKCHIP=y
CONFIG_RAM=y
CONFIG_SPL_RAM=y
-CONFIG_BAUDRATE=150
+CONFIG_BAUDRATE=115200
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYSRESET=y
CONFIG_USB=y
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 8/8] arm: imx7s-warp: Convert to DM PMIC
This patch converts the warp7 and warp7_bl33 board ports over to using the
DM PMIC model.
Signed-off-by: Bryan O'Donoghue
Cc: Peng Fan
Cc: Fabio Estevam
Cc: Stefano Babic
---
board/warp7/warp7.c | 27 +++
configs/warp7_bl33_defconfig | 6 ++
configs/warp7_defconfig | 6 ++
include/configs/warp7.h | 6 --
4 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 19f0df4d09..6ebeb08e33 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -64,29 +64,24 @@ int board_early_init_f(void)
return 0;
}
-#ifdef CONFIG_POWER
-#define I2C_PMIC 0
-static struct pmic *pfuze;
+#ifdef CONFIG_DM_PMIC
int power_init_board(void)
{
- int ret;
- unsigned int reg, rev_id;
+ struct udevice *dev;
+ int ret, dev_id, rev_id;
- ret = power_pfuze3000_init(I2C_PMIC);
- if (ret)
+ ret = pmic_get("pfuze3000", &dev);
+ if (ret == -ENODEV)
+ return 0;
+ if (ret != 0)
return ret;
- pfuze = pmic_get("PFUZE3000");
- ret = pmic_probe(pfuze);
- if (ret)
- return ret;
-
- pmic_reg_read(pfuze, PFUZE3000_DEVICEID, ®);
- pmic_reg_read(pfuze, PFUZE3000_REVID, &rev_id);
- printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", reg, rev_id);
+ dev_id = pmic_reg_read(dev, PFUZE3000_DEVICEID);
+ rev_id = pmic_reg_read(dev, PFUZE3000_REVID);
+ printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", dev_id, rev_id);
/* disable Low Power Mode during standby mode */
- pmic_reg_write(pfuze, PFUZE3000_LDOGCTL, 0x1);
+ pmic_clrsetbits(dev, PFUZE3000_LDOGCTL, 0, 1);
return 0;
}
diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
index 2e80011cbc..7b40bfbd6d 100644
--- a/configs/warp7_bl33_defconfig
+++ b/configs/warp7_bl33_defconfig
@@ -45,3 +45,9 @@ CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX7=y
CONFIG_DM_GPIO=y
CONFIG_DM_I2C=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_PFUZE100=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_PFUZE100=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 9f7dc73a11..d1c8e403a7 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -58,3 +58,9 @@ CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX7=y
CONFIG_DM_GPIO=y
CONFIG_DM_I2C=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_PFUZE100=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_PFUZE100=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 41eb8d7e1d..043f2861b6 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -129,12 +129,6 @@
#define CONFIG_SYS_I2C_MXC
#define CONFIG_SYS_I2C_SPEED 10
-/* PMIC */
-#define CONFIG_POWER
-#define CONFIG_POWER_I2C
-#define CONFIG_POWER_PFUZE3000
-#define CONFIG_POWER_PFUZE3000_I2C_ADDR0x08
-
/* environment organization */
#define CONFIG_ENV_SIZESZ_8K
--
2.20.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
u-boot@lists.denx.de
This patch sets up an alias for mmc0 to usdhc3.
Before the DM conversion only usdhc3 was enabled and therefore it appeared
as MMC 0 to u-boot. After enabling MMC DM though usdhc3 defaults to MMC 2,
which left unattended would drive changes to existing warp7 bootscripts and
environment variables that rely on mmc 0.
Setup the alias of mmc0 and usdhc3 so that existing warp7 boot code will
work unmodified.
Signed-off-by: Bryan O'Donoghue
Cc: Albert Aribaud
Cc: Peng Fan
Cc: Fabio Estevam
Cc: Stefano Babic
---
arch/arm/dts/imx7s-warp.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/imx7s-warp.dts b/arch/arm/dts/imx7s-warp.dts
index 615ed7ed80..279f02ecef 100644
--- a/arch/arm/dts/imx7s-warp.dts
+++ b/arch/arm/dts/imx7s-warp.dts
@@ -17,6 +17,10 @@
reg = <0x8000 0x2000>;
};
+ aliases {
+ mmc0 = &usdhc3;
+ };
+
gpio-keys {
compatible = "gpio-keys";
pinctrl-0 = <&pinctrl_gpio>;
--
2.20.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/8] arm: imx7s-warp: Add DT file hooks
This patch adds DT file hooks for imx7s-warp.dtb to the warp7 and warp7_bl33 builds. Signed-off-by: Bryan O'Donoghue Cc: Albert Aribaud Cc: Peng Fan Cc: Fabio Estevam Cc: Stefano Babic --- arch/arm/dts/Makefile| 3 ++- configs/warp7_bl33_defconfig | 3 ++- configs/warp7_defconfig | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index dda4e59491..4fe7e90902 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -460,7 +460,8 @@ dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb dtb-$(CONFIG_MX7) += imx7-colibri.dtb \ imx7d-sdb.dtb \ - imx7d-sdb-qspi.dtb + imx7d-sdb-qspi.dtb \ + imx7s-warp.dtb dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig index a568c6d10e..12141fedd3 100644 --- a/configs/warp7_bl33_defconfig +++ b/configs/warp7_bl33_defconfig @@ -20,6 +20,7 @@ CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y +CONFIG_OF_CONTROL=y CONFIG_CMD_FS_GENERIC=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DFU_MMC=y @@ -37,5 +38,5 @@ CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_ETHER=y CONFIG_USB_ETH_CDC=y CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" -CONFIG_OF_LIBFDT=y CONFIG_OPTEE_TZDRAM_SIZE=0x200 +CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp" diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index 4d443295ba..fee98dfbbe 100644 --- a/configs/warp7_defconfig +++ b/configs/warp7_defconfig @@ -29,6 +29,7 @@ CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y +CONFIG_OF_CONTROL=y CONFIG_CMD_FS_GENERIC=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DFU_MMC=y @@ -47,8 +48,8 @@ CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_ETHER=y CONFIG_USB_ETH_CDC=y CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" -CONFIG_OF_LIBFDT=y CONFIG_OPTEE_LOAD_ADDR=0x8400 CONFIG_OPTEE_TZDRAM_SIZE=0x300 CONFIG_OPTEE_TZDRAM_BASE=0x9d00 CONFIG_BOOTM_OPTEE=y +CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp" -- 2.20.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/8] arm: imx7s-warp: Convert to DM MMC initialization
Converts from fixed initialization of MMC to DM initialization of MMC.
Signed-off-by: Bryan O'Donoghue
Cc: Albert Aribaud
Cc: Peng Fan
Cc: Fabio Estevam
Cc: Stefano Babic
---
arch/arm/dts/imx7s-warp.dts | 11 ---
board/warp7/warp7.c | 34 --
configs/warp7_bl33_defconfig | 1 +
configs/warp7_defconfig | 1 +
4 files changed, 2 insertions(+), 45 deletions(-)
diff --git a/arch/arm/dts/imx7s-warp.dts b/arch/arm/dts/imx7s-warp.dts
index c44db20734..615ed7ed80 100644
--- a/arch/arm/dts/imx7s-warp.dts
+++ b/arch/arm/dts/imx7s-warp.dts
@@ -251,17 +251,6 @@
status = "okay";
};
-&usdhc1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usdhc1>;
- bus-width = <4>;
- keep-power-in-suspend;
- no-1-8-v;
- non-removable;
- vmmc-supply = <®_brcm>;
- status = "okay";
-};
-
&usdhc3 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <&pinctrl_usdhc3>;
diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 3d32b3eb52..146d722b15 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -30,8 +30,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU100KOHM | \
PAD_CTL_HYS)
-#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW |\
- PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
#define I2C_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
@@ -74,43 +72,11 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
};
-static iomux_v3_cfg_t const usdhc3_pads[] = {
- MX7D_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA4__SD3_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA5__SD3_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA6__SD3_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA7__SD3_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_RESET_B__SD3_RESET_B | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-};
-
static void setup_iomux_uart(void)
{
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
};
-static struct fsl_esdhc_cfg usdhc_cfg[1] = {
- {USDHC3_BASE_ADDR},
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- /* Assume uSDHC3 emmc is always present */
- return 1;
-}
-
-int board_mmc_init(bd_t *bis)
-{
- imx_iomux_v3_setup_multiple_pads(usdhc3_pads, ARRAY_SIZE(usdhc3_pads));
- usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
-
- return fsl_esdhc_initialize(bis, &usdhc_cfg[0]);
-}
-
int board_early_init_f(void)
{
setup_iomux_uart();
diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
index 12141fedd3..b2f943c775 100644
--- a/configs/warp7_bl33_defconfig
+++ b/configs/warp7_bl33_defconfig
@@ -24,6 +24,7 @@ CONFIG_OF_CONTROL=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_DFU_MMC=y
+CONFIG_DM_MMC=y
CONFIG_FSL_ESDHC=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index fee98dfbbe..65d801ffe2 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -33,6 +33,7 @@ CONFIG_OF_CONTROL=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_DFU_MMC=y
+CONFIG_DM_MMC=y
CONFIG_FSL_ESDHC=y
CONFIG_OPTEE=y
CONFIG_USB=y
--
2.20.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/8] warp7: defconfig: Switch on IMX7 pinctrl for both ports
Switches on the IMX7 pinctrl driver for the warp7 and warp7_bl33 ports, necessary to convert over to DM for this board. Signed-off-by: Bryan O'Donoghue Cc: Peng Fan Cc: Fabio Estevam Cc: Stefano Babic --- configs/warp7_bl33_defconfig | 2 ++ configs/warp7_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig index b2f943c775..a2c2555315 100644 --- a/configs/warp7_bl33_defconfig +++ b/configs/warp7_bl33_defconfig @@ -41,3 +41,5 @@ CONFIG_USB_ETH_CDC=y CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" CONFIG_OPTEE_TZDRAM_SIZE=0x200 CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp" +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX7=y diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index 65d801ffe2..8691d00491 100644 --- a/configs/warp7_defconfig +++ b/configs/warp7_defconfig @@ -54,3 +54,5 @@ CONFIG_OPTEE_TZDRAM_SIZE=0x300 CONFIG_OPTEE_TZDRAM_BASE=0x9d00 CONFIG_BOOTM_OPTEE=y CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp" +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX7=y -- 2.20.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 7/8] warp7: defconfig: Switch to DM for I2C
This commit switches to DM I2C for warp7 and warp7_bl33 defconfigs.
Signed-off-by: Bryan O'Donoghue
Cc: Peng Fan
Cc: Fabio Estevam
Cc: Stefano Babic
---
board/warp7/warp7.c | 24
configs/warp7_bl33_defconfig | 1 +
configs/warp7_defconfig | 1 +
include/configs/warp7.h | 2 --
4 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 146d722b15..19f0df4d09 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -31,26 +31,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU100KOHM | \
PAD_CTL_HYS)
-#define I2C_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
- PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
-
-#ifdef CONFIG_SYS_I2C_MXC
-#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
-/* I2C1 for PMIC */
-static struct i2c_pads_info i2c_pad_info1 = {
- .scl = {
- .i2c_mode = MX7D_PAD_I2C1_SCL__I2C1_SCL | PC,
- .gpio_mode = MX7D_PAD_I2C1_SCL__GPIO4_IO8 | PC,
- .gp = IMX_GPIO_NR(4, 8),
- },
- .sda = {
- .i2c_mode = MX7D_PAD_I2C1_SDA__I2C1_SDA | PC,
- .gpio_mode = MX7D_PAD_I2C1_SDA__GPIO4_IO9 | PC,
- .gp = IMX_GPIO_NR(4, 9),
- },
-};
-#endif
-
int dram_init(void)
{
gd->ram_size = PHYS_SDRAM_SIZE;
@@ -130,10 +110,6 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
- #ifdef CONFIG_SYS_I2C_MXC
- setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info1);
- #endif
-
return 0;
}
diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
index 7f21bb4f53..2e80011cbc 100644
--- a/configs/warp7_bl33_defconfig
+++ b/configs/warp7_bl33_defconfig
@@ -44,3 +44,4 @@ CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX7=y
CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 2d3171e42a..9f7dc73a11 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -57,3 +57,4 @@ CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX7=y
CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index a391dfb5c1..41eb8d7e1d 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -126,9 +126,7 @@
(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
/* I2C configs */
-#define CONFIG_SYS_I2C
#define CONFIG_SYS_I2C_MXC
-#define CONFIG_SYS_I2C_MXC_I2C1
#define CONFIG_SYS_I2C_SPEED 10
/* PMIC */
--
2.20.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/8] warp7: defconfig: Switch on DM GPIO for both warp7 ports
This patch switches on DM_GPIO for both WaRP7 ports. Signed-off-by: Bryan O'Donoghue Cc: Peng Fan Cc: Fabio Estevam Cc: Stefano Babic --- configs/warp7_bl33_defconfig | 1 + configs/warp7_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig index a2c2555315..7f21bb4f53 100644 --- a/configs/warp7_bl33_defconfig +++ b/configs/warp7_bl33_defconfig @@ -43,3 +43,4 @@ CONFIG_OPTEE_TZDRAM_SIZE=0x200 CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp" CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX7=y +CONFIG_DM_GPIO=y diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index 8691d00491..2d3171e42a 100644 --- a/configs/warp7_defconfig +++ b/configs/warp7_defconfig @@ -56,3 +56,4 @@ CONFIG_BOOTM_OPTEE=y CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp" CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX7=y +CONFIG_DM_GPIO=y -- 2.20.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/8] arm: dts: imx7s-warp: Import Linux warp7 dts
This patch imports the Linux kernel warp7 dts as at upstream kernel commit
cf76c364a1e1.
The following was dropped from the incoming kernel DTS file
-&wdog1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_wdog>;
- fsl,ext-reset-output;
- status = "okay";
-};
-
-
-&iomuxc_lpsr {
- pinctrl_wdog: wdoggrp {
- fsl,pins = <
- MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_B 0x74
- >;
- };
-};
it causes a DTC compile error for me and isn't needed for u-boot in any
case.
Signed-off-by: Bryan O'Donoghue
Cc: Albert Aribaud
Cc: Peng Fan
Cc: Fabio Estevam
Cc: Stefano Babic
---
arch/arm/dts/imx7s-warp.dts | 423
1 file changed, 423 insertions(+)
create mode 100644 arch/arm/dts/imx7s-warp.dts
diff --git a/arch/arm/dts/imx7s-warp.dts b/arch/arm/dts/imx7s-warp.dts
new file mode 100644
index 00..c44db20734
--- /dev/null
+++ b/arch/arm/dts/imx7s-warp.dts
@@ -0,0 +1,423 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2016 NXP Semiconductors.
+ * Author: Fabio Estevam
+ */
+
+/dts-v1/;
+
+#include
+#include "imx7s.dtsi"
+
+/ {
+ model = "Warp i.MX7 Board";
+ compatible = "warp,imx7s-warp", "fsl,imx7s";
+
+ memory@8000 {
+ reg = <0x8000 0x2000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&pinctrl_gpio>;
+ autorepeat;
+
+ back {
+ label = "Back";
+ gpios = <&gpio7 1 GPIO_ACTIVE_HIGH>;
+ linux,code = ;
+ wakeup-source;
+ };
+ };
+
+ reg_brcm: regulator-brcm {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio5 10 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_brcm_reg>;
+ regulator-name = "brcm_reg";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ startup-delay-us = <20>;
+ };
+
+ reg_bt: regulator-bt {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_bt_reg>;
+ enable-active-high;
+ gpio = <&gpio5 17 GPIO_ACTIVE_HIGH>;
+ regulator-name = "bt_reg";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "imx7-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&dailink_master>;
+ simple-audio-card,frame-master = <&dailink_master>;
+ simple-audio-card,cpu {
+ sound-dai = <&sai1>;
+ };
+
+ dailink_master: simple-audio-card,codec {
+ sound-dai = <&codec>;
+ clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+ };
+ };
+};
+
+&clks {
+ assigned-clocks = <&clks IMX7D_PLL_AUDIO_POST_DIV>;
+ assigned-clock-rates = <884736000>;
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ pmic: pfuze3000@8 {
+ compatible = "fsl,pfuze3000";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1a {
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <1475000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ /* use sw1c_reg to align with pfuze100/pfuze200 */
+ sw1c_reg: sw1b {
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <1475000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <185>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3 {
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <165>;
+
[U-Boot] [PATCH 0/8] Convert i.MX7 WaRP7 ports to DM
This series does a minimal conversion of WaRP7 and the BL33 version of WaRP7 to the DM. Pinctrl, GPIO, I2C, Regulators, PMIC and MMC are converted. Later patches will convert USB and UART. Bryan O'Donoghue (8): arm: dts: imx7s-warp: Import Linux warp7 dts arm: imx7s-warp: Add DT file hooks arm: imx7s-warp: Convert to DM MMC initialization arm: dts: imx7s-warp: Create alias for mmc0 to &usdhc3 warp7: defconfig: Switch on IMX7 pinctrl for both ports warp7: defconfig: Switch on DM GPIO for both warp7 ports warp7: defconfig: Switch to DM for I2C arm: imx7s-warp: Convert to DM PMIC arch/arm/dts/Makefile| 3 +- arch/arm/dts/imx7s-warp.dts | 416 +++ board/warp7/warp7.c | 85 +-- configs/warp7_bl33_defconfig | 14 +- configs/warp7_defconfig | 14 +- include/configs/warp7.h | 8 - 6 files changed, 455 insertions(+), 85 deletions(-) create mode 100644 arch/arm/dts/imx7s-warp.dts -- 2.20.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Booting on RK3399
Hi Kever, I have a firefly-rk3399 and would like to boot it into U-Boot (as a start) from an uSD card. Are there instructions somewhere on how to do this? I gather that I need OP-TEE but not how to build it or how to put the image together. I would like to have instructions in README.rockchip if possible. I'm planning to add U-Boot support for bob and maybe kevin (both Chromebooks) but am not sure where to start. I thought the firefly might be best since it is pretty common. Thanks for any help you can provide. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] riscv: remove invalid dcache flush implementation
Hi Lukas
Auer, Lukas 於 2019年1月2日 週三 下午8:22寫道：
>
> Hi Rick,
>
> On Wed, 2019-01-02 at 10:54 +0800, Rick Chen wrote:
> > Hi Lukas
> >
> > > > From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> > > > Sent: Monday, December 31, 2018 2:28 AM
> > > > To: u-boot@lists.denx.de
> > > > Cc: Anup Patel; Lukas Auer; Rick Jian-Zhi Chen(陳建志); Bin Meng;
> > > > Greentime Hu
> > > > Subject: [PATCH 2/6] riscv: remove invalid dcache flush
> > > > implementation
> > > >
> > > > The fence instruction is used to enforce device I/O and memory
> > > > ordering
> > > > constraints in RISC-V. It does not directly affect the data cache
> > > > and particular
> > > > cannot be used to flush or invalidate it. RISC-V does not have
> > > > instructions for
> > > > explicit cache control. Remove the flush_dcache_all
> > > > implementation and its use
> > > > in all dcache-specific functions in lib/cache.c.
> > > >
> >
> > The privileged mention that fence is for the purposes of ordering,
> > but
> > does not say
> > it can not be used to flush or invalidate.
> >
> > Andes's ax25 have no coherence agent. So it need fence instruction to
> > manipulate
> > cache flush or invalidate. Or there will be some data synchronization
> > error
> > occurs on ae350 platform.
> >
>
> I was not aware of this. Does the ax25 flush the whole dcache on any
> fence instruction?
Yes.
It will flush the whole dcache when execute fence.
>
> You are right, we can't remove it in this case. Since it is specific to
> the ax25, should I move it into cpu/ax25/cache.c instead?
OK
It is good to me.
And thanks for your understanding and improvements.
Regards
Rick
>
> Thanks,
> Lukas
>
> > Thanks
> > Rick
> >
> >
> > > > This also adds a missing new line between flush_dcache_all and
> > > > flush_dcache_range in lib/cache.c.
> > > >
> > > > Signed-off-by: Lukas Auer
> > > > ---
> > > > This patch only removes the implementation itself and its use in
> > > > dcache-specific
> > > > functions in lib/cache.c. There are more uses of it in
> > > > arch/riscv/, which this patch
> > > > does not remove.
> > > >
> > > > arch/riscv/lib/cache.c | 4 +---
> > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c
> > > > index
> > > > ae5c60716f..203e287612 100644
> > > > --- a/arch/riscv/lib/cache.c
> > > > +++ b/arch/riscv/lib/cache.c
> > > > @@ -13,11 +13,10 @@ void invalidate_icache_all(void)
> > > >
> > > > void flush_dcache_all(void)
> > > > {
> > > > - asm volatile ("fence" :::"memory");
> > > > }
> > > > +
> > > > void flush_dcache_range(unsigned long start, unsigned long
> > > > end) {
> > > > - flush_dcache_all();
> > > > }
> > > >
> > > > void invalidate_icache_range(unsigned long start, unsigned long
> > > > end) @@ -31,7
> > > > +30,6 @@ void invalidate_icache_range(unsigned long start,
> > > > unsigned long end)
> > > >
> > > > void invalidate_dcache_range(unsigned long start, unsigned long
> > > > end) {
> > > > - flush_dcache_all();
> > > > }
> > > >
> > > > void cache_flush(void)
> > > > --
> > > > 2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bmips: fix config warnings from 2019.01
On Wed, Jan 02, 2019 at 11:11:09PM +0100, Álvaro Fernández Rojas wrote: > Hi Marek, > > Check commits 841d5fbae4e993476fa87d8933db0cd58d3c2d41 and > 109d8bf3ac7b9bb04f3c46bb540eb2bb865f3dd7. > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=841d5fbae4e993476fa87d8933db0cd58d3c2d41 > > > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=109d8bf3ac7b9bb04f3c46bb540eb2bb865f3dd7 Right. But Marek is asking for something more like: - Use of CONFIG_OF_EMBED isn't intended for deployment use, switch to CONFIG_OF_SEPARATE instead. - We can fully migrate to CONIG_DM_USB so enable CONFIG_BLK now. ie why we're changing things, not just that we're fixing the warning. -- 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] bmips: fix config warnings from 2019.01
Hi Marek, Check commits 841d5fbae4e993476fa87d8933db0cd58d3c2d41 and 109d8bf3ac7b9bb04f3c46bb540eb2bb865f3dd7. http://git.denx.de/?p=u-boot.git;a=commitdiff;h=841d5fbae4e993476fa87d8933db0cd58d3c2d41 http://git.denx.de/?p=u-boot.git;a=commitdiff;h=109d8bf3ac7b9bb04f3c46bb540eb2bb865f3dd7 El 01/01/2019 a las 21:24, Marek Vasut escribió: On 1/1/19 7:45 PM, Álvaro Fernández Rojas wrote: - Fixes CONFIG_OF_EMBED warning. - Fixes missing CONFIG_BLK warning for CONFIG_USB. More details on those warnings that are supposedly fixed would be appreciated. It's really unclear what this patch does. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bmips: fix config warnings from 2019.01
I only tested it on Comtrend AR-5387un, I will test it on other boards and report back. El 01/01/2019 a las 20:19, Tom Rini escribió: On Tue, Jan 01, 2019 at 07:45:03PM +0100, Álvaro Fernández Rojas wrote: - Fixes CONFIG_OF_EMBED warning. - Fixes missing CONFIG_BLK warning for CONFIG_USB. Signed-off-by: Álvaro Fernández Rojas To be clear, some number of these have been boot tested too, right? Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v9 09/10] tftp: prevent overwriting reserved memory
On Wed, Dec 19, 2018 at 1:04 PM Simon Goldschmidt
wrote:
>
> This fixes CVE-2018-18439 ("insufficient boundary checks in network
> image boot") by using lmb to check for a valid range to store
> received blocks.
>
> Signed-off-by: Simon Goldschmidt
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: Add clause 45 identifier to phy_device
On Fri, Nov 16, 2018 at 12:26 AM Pankaj Bansal wrote: > > The phy devices can be accessed via clause 22 or via clause 45. > This information can be deduced when we read phy id. if the phy id > is read without giving any MDIO Manageable Device Address (MMD), then > it conforms to clause 22. otherwise it conforms to clause 45. > > Signed-off-by: Pankaj Bansal Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 0/2] net: designware: add meson meson compatibles
On Fri, Nov 9, 2018 at 8:21 AM Neil Armstrong wrote: > > Add the compatible strings in the Synopsys DWMAC driver for : > - The Amlogic GXBB (and other GX) SoC > - The Amlogic AXG (and other GX) SoC > > Neil Armstrong (2): > net: designware: add meson meson gxbb comptatible > net: designware: add meson meson axg compatible Hi Neil, Trying to catch up on patches - I don't see this series in patchwork - should it be? Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 7/8] rockchip: rk3399-puma: enable full pinctrl driver in Puma defconfig.
> This patch enables the full pinctrl driver in the defconfig > for the RK3399-Q7. > > Signed-off-by: Christoph Muellner > --- > > Changes in v4: None > Changes in v3: None > Changes in v2: None > > configs/puma-rk3399_defconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 5/8] rockchip: rk3399: Add improved pinctrl driver.
> The current pinctrl driver for the RK3399 has a range of qulity issues. > E.g. it only implements the .set_state_simple() callback, it > does not parse the available pinctrl information from the DTS > (instead uses hardcoded values), is not flexible enough to cover > devices without 'interrupt' field in the DTS (e.g. PWM), > is not written generic enough to make code reusable among other > rockchip SoCs... > > This patch addresses these issues by reimplementing the whole driver > from scratch using the .set_state() callback. > The new implementation covers all featurese of the old code > (i.e. it supports pinmuxing and pullup/pulldown configuration). > > This patch has been tested on a RK3399-Q7 SoM (Puma). > > Signed-off-by: Christoph Muellner > --- > > Changes in v4: None > Changes in v3: None > Changes in v2: None > > drivers/pinctrl/rockchip/pinctrl_rk3399.c | 227 > ++ > 1 file changed, 227 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 6/8] rockchip: rk3399: Add Kconfig option for full pinctrl driver
> This patch adds a Kconfig option to enable the full pinctrl driver > for the RK3399. This flag needs to be enabed in order to get the > features of the full pinctrl driver compiled in (i.e. a .set_state() > callback). > > Signed-off-by: Christoph Muellner > --- > > Changes in v4: None > Changes in v3: None > Changes in v2: None > > drivers/pinctrl/Kconfig | 10 ++ > drivers/pinctrl/rockchip/pinctrl_rk3399.c | 9 + > 2 files changed, 19 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 8/8] rockchip: rk3399-puma: Set VDD_LOG to 950 mV.
> This patch sets VDD_LOG to 950 mV on RK3399-Q7. > This is required to address stability issues on Puma > in heavy-load use-cases. > > Reported-by: Assaf Agmon > Signed-off-by: Philipp Tomsich > Signed-off-by: Christoph Muellner > --- > > Changes in v4: > - Changed patches according to review feedback. > > Changes in v3: > - Fix message verbosity in pinctrl driver. > - Changed patches according to review feedback. > - Add patch to enable the full pinctrl driver only for Puma boards. > > Changes in v2: > - Changed patches according to review feedback. > - Fix pinctrl infrastructure instead of hacking board_init() code. > > arch/arm/dts/rk3399-puma.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 3/8] rockchip: rk3399-puma: enable PWM regulator in Puma defconfig.
> This patch enables the PWM regulator driver in the defconfig > for the RK3399-Q7. > > Signed-off-by: Christoph Muellner > --- > > Changes in v4: None > Changes in v3: None > Changes in v2: None > > configs/puma-rk3399_defconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 4/8] dm: pinctrl: Add pinctrl_decode_pin_config_dm().
> pinctrl_decode_pin_config_dm() is basically a feature-equivalent > implementation of pinctrl_decode_pin_config(), which operates > on struct udevice devices and uses the dev_read_*() API. > > Signed-off-by: Christoph Muellner > --- > > Changes in v4: None > Changes in v3: None > Changes in v2: None > > drivers/pinctrl/pinctrl-uclass.c | 22 ++ > include/dm/pinctrl.h | 12 > 2 files changed, 34 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 1/8] rockchip: rk3399-puma: Cleanup of vdd_log DTS entry.
> This patch eliminates the non-standard entries "rockchip,pwm_id" > and "rockchip,pwm_voltage". They are neither documented nor > read out by any driver. > > Additionally it introduces the entry regulator-init-microvolt > and sets it to 900 mV, which is the default target value > for VDD_LOG. > > Signed-off-by: Christoph Muellner > --- > > Changes in v4: None > Changes in v3: None > Changes in v2: None > > arch/arm/dts/rk3399-puma.dtsi | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 2/8] power: regulator: Allow PWM regulator to be omitted from SPL.
> This patch allows to enable the PWM regulator driver > independent for U-Boot and SPL. > > Signed-off-by: Christoph Muellner > --- > > Changes in v4: None > Changes in v3: None > Changes in v2: None > > drivers/power/regulator/Kconfig | 7 +++ > drivers/power/regulator/Makefile | 2 +- > 2 files changed, 8 insertions(+), 1 deletion(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] rockchip: ram: update license for sdram driver
> Rockchip may use this sdram copy of source code for both open source > and internal project, update the license to use both GPL2.0+ and > BSD-3 Clause. > > Signed-off-by: Kever Yang > --- > > drivers/ram/rockchip/sdram_rk3128.c | 2 +- > drivers/ram/rockchip/sdram_rk3188.c | 2 +- > drivers/ram/rockchip/sdram_rk322x.c | 2 +- > drivers/ram/rockchip/sdram_rk3288.c | 2 +- > drivers/ram/rockchip/sdram_rk3328.c | 2 +- > drivers/ram/rockchip/sdram_rk3399.c | 2 +- > 6 files changed, 6 insertions(+), 6 deletions(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/2] rockchip: rk3036: ram: update license
> All the source code of sdram_rk3036.c are from Rockchip, update the > copyright to owned by Rockchip. > > Because rockchip may use this copy of code both for open source > project and internal project, update the license to use both > GPL2.0+ and BSD-3 Clause. > > Signed-off-by: Kever Yang > --- > > arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] configs: move CONFIG_SPL_TEXT_BASE to Kconfig
Hi Marek, Am 14.11.2018 um 19:51 schrieb Simon Goldschmidt: On 07.10.2018 02:49, Tom Rini wrote: On Sun, Sep 30, 2018 at 02:31:53PM +0200, Simon Goldschmidt wrote: Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig with help from moveconfig.py (only had to prepare socfpga, stm32f746 and am33x/43x manually) Signed-off-by: Simon Goldschmidt --- This patch is in preparation for boot-from-FPGA for socfpga cyclone5, where we need a different SPL_TEXT_BASE. By moving this to Kconfig, this can then be done via defconfig. I did notice that some defconfig files change more than necessary, it seems like they are out of sync? So, I see at least one set of problems with the conversion, the am33* family gets put to 0x0 which isn't right. I'm going to pull out the print tool I made and posted a while back and use that for conversion. Thanks for the starting point! Tom, what's the status on this? I still can't build an SPL for socfpga gen5 boot from FPGA because I can't change SPL_TEXT_BASE. Marek, if getting CONFIG_SPL_TEXT_BASE into 2019.01 won't work, can we have a separate (k)config option for socfpga only? That might be useful anyway as when booting from fpga, there is no 64 KByte size limit and the "magic value into magic register to unlock support for issuing warm reset" must not be written as the SPL is not in SRAM. But that might have its separate config option, too... Anyway, I just need input to know in which direction I should continue. I'm waiting to get all our versions of SPL and U-Boot running from mainline (with only board configs added for our private boards). I still cannot build an SPL to boot from FPGA since CONFIG_SPL_TEXT_BASE is hard-coded to OnChip RAM (while when booting from FPGA, it has to be placed into the FPGA bridge). Since both Tom and myself did not seem to have immediate luck with bringing CONFIG_SPL_TEXT_BASE to Kconfig, may I suggest to add a Kconfig option 'Boot from FPGA' for socfpga_gen5? Or do you have another idea at hand of how to proceed here? Please note that there might be other settings that may change when booting from FPGA, e.g. the maximum code size for SPL is not limited any more. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] dm: MIGRATION: Update migration plan for SPI
On Wed, Jan 2, 2019 at 12:47 AM Jagan Teki wrote: > > - v2019.04 for no dm conversion drivers > - v2019.07 for partially converted drivers. > > Note: there were many updates on this deadline, so better > not update this again. > > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, Please pull this spi PR as part of 2019.01 thanks, Jagan. The following changes since commit 08337cd64832ed7f8147da75013510b92bbcd188: riscv: bootm: Support booting VxWorks (2018-12-31 08:08:51 -0500) are available in the Git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to 689795242b1cb7de5a3d8c8bf1a9582a8924ff69: dm: MIGRATION: Update migration plan for DM_SPI_FLASH (2019-01-02 01:00:31 +0530) Jagan Teki (2): dm: MIGRATION: Update migration plan for SPI dm: MIGRATION: Update migration plan for DM_SPI_FLASH Nikolai Zhubr (1): mtd: nand: raw: Add Hynix H27UBG8T2BTR id table Stefan Mavrodiev (1): spi: sun4i: Add rx_buf NULL pointer check Makefile| 21 + doc/driver-model/MIGRATION.txt | 10 +++--- drivers/mtd/nand/raw/nand_ids.c | 4 drivers/spi/sun4i_spi.c | 3 ++- 4 files changed, 34 insertions(+), 4 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] tools: imx8image: use correct printf escape sequence
On 12/17/18 10:22 AM, Heinrich Schuchardt wrote:
> core is of type uint64_t. So for printing we need "%"PRIu64 (not "%lu").
>
> Without the patch a warning is issued when building on a 32bit system.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> tools/imx8image.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/tools/imx8image.c b/tools/imx8image.c
> index 6e8ac464e7..f3158bc434 100644
> --- a/tools/imx8image.c
> +++ b/tools/imx8image.c
> @@ -555,7 +555,8 @@ static void set_image_array_entry(flash_header_v3_t
> *container,
> } else if (soc == QM && core == CORE_CA72) {
> meta = IMAGE_A72_DEFAULT_META(custom_partition);
> } else {
> - fprintf(stderr, "Error: invalid AP core id: %lu\n",
> + fprintf(stderr,
> + "Error: invalid AP core id: %" PRIu64 "\n",
> core);
> exit(EXIT_FAILURE);
> }
> @@ -577,7 +578,9 @@ static void set_image_array_entry(flash_header_v3_t
> *container,
> core = CORE_CM4_1;
> meta = IMAGE_M4_1_DEFAULT_META(custom_partition);
> } else {
> - fprintf(stderr, "Error: invalid m4 core id: %lu\n",
> core);
> + fprintf(stderr,
> + "Error: invalid m4 core id: %" PRIu64 "\n",
> + core);
> exit(EXIT_FAILURE);
> }
> img->hab_flags |= IMG_TYPE_EXEC;
>
Hello Stefano,
in patchwork this patch has been assigned to you. Could you, please,
review it.
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cmd: usb: display bus number
On 1/2/19 5:37 PM, Marek Vasut wrote:
> On 1/2/19 5:03 PM, Heinrich Schuchardt wrote:
>> On 1/2/19 3:21 PM, Marek Vasut wrote:
>>> On 1/2/19 12:29 PM, Heinrich Schuchardt wrote:
If multiple USB buses exist, the output of the commands 'usb tree' and 'usb
info' is confusing because it is not clear where the output for a new bus
starts.
Print an additional line for each bus indicating the bus number, e.g.
=> usb tree
USB device tree:
USB bus 0
1 Hub (5 Gb/s, 0mA)
U-Boot XHCI Host Controller
USB bus 1
1 Hub (5 Gb/s, 0mA)
U-Boot XHCI Host Controller
Signed-off-by: Heinrich Schuchardt
---
cmd/usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/usb.c b/cmd/usb.c
index 0ccb1b5148..6da945c376 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -470,6 +470,7 @@ static void usb_for_each_root_dev(usb_dev_func_t func)
if (!device_active(bus))
continue;
+ printf("USB bus %d\n", bus->seq);
>>>
>>> Isn't this only valid if you use SEQ_ALIAS ?
>>
>> Kconfig symbol SEQ_ALIAS does not exist. I assume you mean DM_SEQ_ALIAS.
>>
>> In device_probe() seq is set unconditionally
>> (drivers/core/device.c:306).
>>
>> CONFIG_DM_SEQ_ALIAS=y allows to influence the value of seq via the
>> device tree.
>
> I know what it does. Without this option being set, the bus->seq number
> will be either some obscure gigantic number or undefined, right ?
>
I disabled CONFIG_DM_SEQ_ALIAS and this is the output on my MACCHIATObin
(with the second USB bus enabled in the device tree).
=> usb start
starting USB...
USB0: Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB1: Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
=> usb tree
USB device tree:
USB bus 0
1 Hub (5 Gb/s, 0mA)
U-Boot XHCI Host Controller
USB bus 1
1 Hub (5 Gb/s, 0mA)
U-Boot XHCI Host Controller
Could you, please, indicate under which circumstances seq might be
undefined.
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms
On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot wrote:
>
>
> On 29/12/2018 19:49, Jagan Teki wrote:
> > On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki
> > wrote:
> >> On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot
> >> wrote:
> >> Better to have proper commit head that tells the real issue.
>
> I found it hard to come up with a short description of the real issue.
>
> At least this title makes it clear that it is a regression fix, not a
> new feature.
>
> The details of the failures are in the commit log (or so I thought)
>
> >>
> >>> Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget
> >>> devices")
> >>>
> >>> The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared
> >>> even for platforms that do not enable DM_USB_GADGET. Otherwise the driver
> >>> for their usb peripheral controller fails to bind.
> >> Sorry this is unclear, you are trying to skip DM_USB_GADGET code even
> >> though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
>
> Sorry for the delay. This was indeed a vacation time.
>
> This patch does not skip DM_USB_GADGET. What it does is declare the
> UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
>
> DM_USB_GADGET is a new option and not (yet) widely used and some drivers
> have their own version of the DM support for gadget drivers (ie they
> implement their own version of usb_gadget_initialize(),
> usb_gadget_release() and usb_gadget_handle_interrupts()). However all
> those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the
> UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the
> past they used UCLASS_USB_DEV_GENERIC, but this option is intended for
> the host side.
Acked-by: Jagan Teki
Marek, any comments?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cmd: usb: display bus number
On 1/2/19 5:03 PM, Heinrich Schuchardt wrote:
> On 1/2/19 3:21 PM, Marek Vasut wrote:
>> On 1/2/19 12:29 PM, Heinrich Schuchardt wrote:
>>> If multiple USB buses exist, the output of the commands 'usb tree' and 'usb
>>> info' is confusing because it is not clear where the output for a new bus
>>> starts.
>>>
>>> Print an additional line for each bus indicating the bus number, e.g.
>>>
>>> => usb tree
>>> USB device tree:
>>> USB bus 0
>>> 1 Hub (5 Gb/s, 0mA)
>>> U-Boot XHCI Host Controller
>>>
>>> USB bus 1
>>> 1 Hub (5 Gb/s, 0mA)
>>> U-Boot XHCI Host Controller
>>>
>>> Signed-off-by: Heinrich Schuchardt
>>> ---
>>> cmd/usb.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/cmd/usb.c b/cmd/usb.c
>>> index 0ccb1b5148..6da945c376 100644
>>> --- a/cmd/usb.c
>>> +++ b/cmd/usb.c
>>> @@ -470,6 +470,7 @@ static void usb_for_each_root_dev(usb_dev_func_t func)
>>> if (!device_active(bus))
>>> continue;
>>>
>>> + printf("USB bus %d\n", bus->seq);
>>
>> Isn't this only valid if you use SEQ_ALIAS ?
>
> Kconfig symbol SEQ_ALIAS does not exist. I assume you mean DM_SEQ_ALIAS.
>
> In device_probe() seq is set unconditionally
> (drivers/core/device.c:306).
>
> CONFIG_DM_SEQ_ALIAS=y allows to influence the value of seq via the
> device tree.
I know what it does. Without this option being set, the bus->seq number
will be either some obscure gigantic number or undefined, right ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] lib: fdtdec: fixup fdtdec_get_addr_size
On 12/21/18 9:24 AM, Keerthy wrote: fix up fdtdec_get_addr_size to use fdtdec_get_addr_size_auto_noparent so that the address cells and size cells are obtained from the parent instead of going by the fixed length. This patch makes perfect sense to me. However, I am worried about the potential existence of code that assumes the current fixed-size logic; in the past when fixing similar issues like this we've often run into code that was use "get addr" functions when it should have been using "get u32" functions and similar, which then broke when we fixed the implementation to do the right thing. I guess we should still apply the patch, and fix up any fallout as it appears. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] board: mvebu: drop unused ETH_PHY macro definitions
These macros are not used anywhere in the boards code. Cc: Chris Packham Cc: Dirk Eibach Cc: Mario Six Cc: Dennis Gilmore Signed-off-by: Baruch Siach --- board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 4 board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 4 board/gdsys/a38x/controlcenterdc.c| 4 board/kobol/helios4/helios4.c | 4 board/solidrun/clearfog/clearfog.c| 4 5 files changed, 20 deletions(-) diff --git a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c index bc18fe6ddf4a..922576e9d599 100644 --- a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c +++ b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c @@ -16,10 +16,6 @@ DECLARE_GLOBAL_DATA_PTR; -#define ETH_PHY_CTRL_REG 0 -#define ETH_PHY_CTRL_POWER_DOWN_BIT11 -#define ETH_PHY_CTRL_POWER_DOWN_MASK (1 << ETH_PHY_CTRL_POWER_DOWN_BIT) - /* * Those values and defines are taken from the Marvell U-Boot version * "u-boot-2013.01-2016_T1.0.eng_drop_v10" diff --git a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c index 9368bce26cee..1a0746b9d3d5 100644 --- a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c +++ b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c @@ -16,10 +16,6 @@ DECLARE_GLOBAL_DATA_PTR; -#define ETH_PHY_CTRL_REG 0 -#define ETH_PHY_CTRL_POWER_DOWN_BIT11 -#define ETH_PHY_CTRL_POWER_DOWN_MASK (1 << ETH_PHY_CTRL_POWER_DOWN_BIT) - /* * Those values and defines are taken from the Marvell U-Boot version * "u-boot-2013.01-2014_T3.0" diff --git a/board/gdsys/a38x/controlcenterdc.c b/board/gdsys/a38x/controlcenterdc.c index 86051aedf8e1..9e448fcd10d9 100644 --- a/board/gdsys/a38x/controlcenterdc.c +++ b/board/gdsys/a38x/controlcenterdc.c @@ -22,10 +22,6 @@ DECLARE_GLOBAL_DATA_PTR; -#define ETH_PHY_CTRL_REG 0 -#define ETH_PHY_CTRL_POWER_DOWN_BIT11 -#define ETH_PHY_CTRL_POWER_DOWN_MASK (1 << ETH_PHY_CTRL_POWER_DOWN_BIT) - #define DB_GP_88F68XX_GPP_OUT_ENA_LOW 0x7fff #define DB_GP_88F68XX_GPP_OUT_ENA_MID 0xefff diff --git a/board/kobol/helios4/helios4.c b/board/kobol/helios4/helios4.c index 8c0864bcdd4d..3c3592ecf58b 100644 --- a/board/kobol/helios4/helios4.c +++ b/board/kobol/helios4/helios4.c @@ -17,10 +17,6 @@ DECLARE_GLOBAL_DATA_PTR; -#define ETH_PHY_CTRL_REG 0 -#define ETH_PHY_CTRL_POWER_DOWN_BIT11 -#define ETH_PHY_CTRL_POWER_DOWN_MASK BIT(ETH_PHY_CTRL_POWER_DOWN_BIT) - /* * Those values and defines are taken from the Marvell U-Boot version * "u-boot-2013.01-15t1-helios4" as well as the upstream config for clearfog diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c index 1742aa8921c9..03724fee10c1 100644 --- a/board/solidrun/clearfog/clearfog.c +++ b/board/solidrun/clearfog/clearfog.c @@ -16,10 +16,6 @@ DECLARE_GLOBAL_DATA_PTR; -#define ETH_PHY_CTRL_REG 0 -#define ETH_PHY_CTRL_POWER_DOWN_BIT11 -#define ETH_PHY_CTRL_POWER_DOWN_MASK (1 << ETH_PHY_CTRL_POWER_DOWN_BIT) - /* * Those values and defines are taken from the Marvell U-Boot version * "u-boot-2013.01-15t1-clearfog" -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cmd: usb: display bus number
Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.
Content preview: On 1/2/19 3:21 PM, Marek Vasut wrote: > On 1/2/19 12:29 PM,
Heinrich Schuchardt wrote: >> If multiple USB buses exist, the output of
the commands 'usb tree' and 'usb >> info' is confusing because it is not clear
where the output for a new bus >> starts. >> >> Print an additional line
for each bus indicating the bus number, e.g. >> >> => usb tree >> USB device
tree: >> USB bus 0 >> 1 Hub (5 Gb/s, 0mA) >> U-Boot XHCI Host Controller
>> >> USB bus 1 >> 1 Hub (5 Gb/s, 0mA) >> U-Boot XHCI Host Controller >> >>
Signed-off-by: Heinrich Schuchardt >> --- >> cmd/usb.c | 1 + >> 1 file
changed,
1 insertion(+) >> >> diff --git a/cmd/usb.c b/cmd/usb.c >> index
0ccb1b5148..6da945c376
100644 >> --- a/cmd/usb.c >> +++ b/cmd/usb.c >> @@ -470,6 +470,7 @@ static
void usb_for_each_root_dev(usb_dev_func_t func) >> if (!device_active(bus))
>> continue; >> >> + printf("USB bus %d\n", bus->seq); > > Isn't this only
valid if you use SEQ_ALIAS ? [...]
Content analysis details: (5.5 points, 5.0 required)
pts rule name description
-- --
0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL
was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[212.227.15.19 listed in list.dnswl.org]
3.0 SINGLE_HEADER_3K A single header contains 3K-4K characters
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider
(xypron.glpk[at]gmx.de)
2.5 DRUGS_MUSCLE Refers to a muscle relaxant
--- Begin Message ---
On 1/2/19 3:21 PM, Marek Vasut wrote:
> On 1/2/19 12:29 PM, Heinrich Schuchardt wrote:
>> If multiple USB buses exist, the output of the commands 'usb tree' and 'usb
>> info' is confusing because it is not clear where the output for a new bus
>> starts.
>>
>> Print an additional line for each bus indicating the bus number, e.g.
>>
>> => usb tree
>> USB device tree:
>> USB bus 0
>> 1 Hub (5 Gb/s, 0mA)
>> U-Boot XHCI Host Controller
>>
>> USB bus 1
>> 1 Hub (5 Gb/s, 0mA)
>> U-Boot XHCI Host Controller
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> cmd/usb.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/cmd/usb.c b/cmd/usb.c
>> index 0ccb1b5148..6da945c376 100644
>> --- a/cmd/usb.c
>> +++ b/cmd/usb.c
>> @@ -470,6 +470,7 @@ static void usb_for_each_root_dev(usb_dev_func_t func)
>> if (!device_active(bus))
>> continue;
>>
>> +printf("USB bus %d\n", bus->seq);
>
> Isn't this only valid if you use SEQ_ALIAS ?
Kconfig symbol SEQ_ALIAS does not exist. I assume you mean DM_SEQ_ALIAS.
In device_probe() seq is set unconditionally
(drivers/core/device.c:306).
CONFIG_DM_SEQ_ALIAS=y allows to influence the value of seq via the
device tree.
Best regards
Heinrich
>
>> device_find_first_child(bus, &dev);
>> if (dev && device_active(dev)) {
>> udev = dev_get_parent_priv(dev);
>>
>
>
--- End Message ---
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms
On 02/01/2019 13:15, Lukasz Majewski wrote:
On Wed, 2 Jan 2019 11:38:47 +0100
Jean-Jacques Hiblot wrote:
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki
wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot
wrote: Better to have proper commit head that
tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a
new feature.
The details of the failures are in the commit log (or so I thought)
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for
USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be
declared even for platforms that do not enable DM_USB_GADGET.
Otherwise the driver for their usb peripheral controller fails to
bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code
even though UCLASS_USB_GADGET_GENERIC id used. does it make
sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the
UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not
set.
DM_USB_GADGET is a new option and not (yet) widely used and some
drivers have their own version of the DM support for gadget drivers
(ie they implement their own version of usb_gadget_initialize(),
usb_gadget_release() and usb_gadget_handle_interrupts()). However all
those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus
the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In
the past they used UCLASS_USB_DEV_GENERIC, but this option is
intended for the host side.
Thanks for a detailed explanation. Would you prepare v2 soon?
Honestly I don't know what i would change in a v2.
JJ
Any response on this?
We need the fix asap since the release is about a week.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 05/14] board: cosmetic: Use define to set ENET clock selection mask on TPC70
Hi Marek, > On 1/2/19 11:06 AM, Lukasz Majewski wrote: > > Hi Marek, > > > >> On 1/2/19 12:37 AM, Lukasz Majewski wrote: > >>> This is a cosmetic change, just to use proper define. > >>> > >>> Signed-off-by: Lukasz Majewski > >> > >> The subject tags are wrong, fix globally. > > > > Is there any doc which describes the allowed/not allowed tags > > (either with Linux or U-boot)? > > I am not aware of one, however you can write one if you feel inclined > to do so. I was just curious if I have overlooked something. > > > From my experience it is a some kind of a convention depending on > > the maintainer (which helps him to spot relevant patches on ML). > > Right, and this is ARM imx board, hence those tags should be > included. > > > In [1] - point 14) there is: > > The canonical patch subject line is: > > "Subject: [PATCH 001/123] subsystem: summary phrase" > > > > and the "subsystem: " is the tag. > > > > In the case of this patch -> I do fix stuff in "board(s)" which is > > "cosmetic". > > > > Or will we only stick to tags/mails from ./doc/git-mailrc ? > > > > [1] - > > https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html > > [...] > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpFm1EUNS4B7.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 04/14] DTS: imx: Remove not needed '#address-cells' and '#size-cells' properties
Hi Marek, > On 1/2/19 10:43 AM, Lukasz Majewski wrote: > > Hi Marek, > > > >> On 1/2/19 12:37 AM, Lukasz Majewski wrote: > >>> This commit fixes warnings produced by newest in u-boot DTC > >>> compiler: 'unnecessary #address-cells/#size-cells without "ranges" > >>> or child "reg" property' > >>> > >>> Signed-off-by: Lukasz Majewski > >> > >> I presume the DTSIs are taken from Linux, is this a backport from > >> Linux then ? > > > > Regarding Linux - with Version: DTC 1.4.7-gc86da84d and make W=1 I > > do not see those warnings as in scripts/Makefile.lib : > > > > # Disable noisy checks by default > > ifeq ($(findstring 1,$(KBUILD_ENABLE_EXTRA_GCC_CHECKS)),) > > DTC_FLAGS += -Wno-unit_address_vs_reg \ > > -Wno-unit_address_format \ > > -Wno-avoid_unnecessary_addr_size \ > > > > those warnings are disabled (-Wno-avoid_unnecessary_addr_size). > > > > On the other hand - in u-boot those warnings are checked (maybe are > > necessary for OF_PLATDATA correct operation?). > > No, keep the DTs synced and fix things upstream (in Linux) if needed, > then backport the fixes. Please correct my understanding if I get this wrong. Do you recommend to send this patch to Linux upstream to fix warnings, which are disabled (no checked and not present) by default in Linux ? After this patch is accepted in Linux - I shall backport it to u-boot ? > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpdfeFvFmNTC.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 12/14] imx: mmc: Use 'fsl, usdhc-index' property to provide esdhc controller number
On 1/2/19 11:31 AM, Lukasz Majewski wrote:
> On Wed, 2 Jan 2019 02:18:58 +0100
> Marek Vasut wrote:
>
>> On 1/2/19 12:37 AM, Lukasz Majewski wrote:
>>> With the current code, it is not possible to assign different than
>>> default numbers for mmc controllers.
>>>
>>> Several in-tree boards depend on the pre-dm setup, corresponding to
>>> following aliases:
>>>
>>> mmc0 = &usdhc2; --> fsl,usdhc-index = <1>
>>> mmc1 = &usdhc4; --> fsl,usdhc-index = <3>
>>>
>>> Without this patch we are either forced to use default aliasing -
>>> like:
>>>
>>> mmc0 = &usdhc1;
>>> mmc1 = &usdhc2;
>>> mmc2 = &usdhc3;
>>> mmc3 = &usdhc4;
>>>
>>> to have the proper clocks setup for the controller. However, such
>>> setup is not acceptable for some legacy scripts / code.
>>>
>>> With this patch - by introducing 'fsl,usdhc-index' - one can
>>> configure (get) clock rate corresponding to used controller.
>>>
>>> Moreover, as this code is used in the SPL before relocation (and to
>>> save space we strip the SPL DTS from clocks and its names) adding
>>> separate properties seems to be the best approach here. One also
>>> avoids adding clocks DM code to SPL.
>>>
>>> Signed-off-by: Lukasz Majewski
>>> ---
>>>
>>> drivers/mmc/fsl_esdhc.c | 17 -
>>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
>>> index 3cdfa7f5a6..49a6834a98 100644
>>> --- a/drivers/mmc/fsl_esdhc.c
>>> +++ b/drivers/mmc/fsl_esdhc.c
>>> @@ -1401,6 +1401,7 @@ static int fsl_esdhc_probe(struct udevice
>>> *dev) fdt_addr_t addr;
>>> unsigned int val;
>>> struct mmc *mmc;
>>> + int usdhc_idx;
>>> int ret;
>>>
>>> addr = dev_read_addr(dev);
>>> @@ -1513,7 +1514,21 @@ static int fsl_esdhc_probe(struct udevice
>>> *dev)
>>> priv->sdhc_clk = clk_get_rate(&priv->per_clk);
>>> } else {
>>> - priv->sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK +
>>> dev->seq);
>>> + /*
>>> +* Check for 'fsl,index' DTS property - as one may
>>> want to have
>>> +* following mmc setup:
>>
>> NAK, DT is a hardware description. This is encoding a policy, which
>> should not be in DT.
>
> Please look a few lines up in this file:
>
> mmc0 = &usdhc1;
> mmc1 = &usdhc2;
> mmc2 = &usdhc3;
> mmc3 = &usdhc4;
>
> The fsl_esdhc.c has hardcoded ordering for eMMC devices when
> setting/getting clock.
>
> If you change aliases on your dts (mmc0 -> usdhc2, etc). Then with a
> bit of luck your second controller will be initialized with first's one
> clock value :-). This of course works by chance with default ROM setup.
>
> The problem is that many boards have different mmc ordering (starting
> with mmc0, which in above scheme is usdhc2 controller. Also mmc1 is the
> usdhc4 to which eMMC is connected in many boards). Of course this could
> be changed, but please consider a lot of legacy code pilling up on the
> customer's side.
>
> The clock index @ (drivers/mmc/fsl_esdhc.c - L1517):
> mxc_get_clock(MXC_ESDHC_CLK + dev->seq);
>
> Here the dev->seq is 0,1 (with SEQ_ALIAS), which will provide clock
> values from usdhc1 and usdhc2. However, we use usdhc4 (eMMC) and usdhc2
> (SD).
>
>>
>> This looks like some reimplementation of SEQ_ALIAS stuff.
>
> No, this is a fix for hardcoded (assumed) clock setup in this driver.
>
> The other option is to provide/port clock stuff from linux (and
> implement CLK_DM in u-boot at least for this part). However, this will
> not fix the problem described above (for other boards which use the
> "legacy" approach).
Well fix the clock code then ? All the other subsystems use the
SEQ_ALIAS and DT /aliases node to define ordering, I don't see why FSL
SDHC driver should get some special hacky treatment which will only make
it difficult to maintain in the future .
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM: socfpga: Synchronize the configuration for A10 SoCDK
On 1/2/19 9:50 AM, Chee, Tien Fong wrote: > On Tue, 2019-01-01 at 21:35 +0100, Marek Vasut wrote: >> On 1/1/19 4:51 AM, Chee, Tien Fong wrote: >>> >>> On Sun, 2018-12-30 at 16:54 +0100, Marek Vasut wrote: On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote: > > > From: Marek Vasut > > Update the default configuration file to enable the necessary > functionality > the get the kit working. That includes SPL SD/MMC support, USB, > and > I2C. > > Signed-off-by: Marek Vasut > Signed-off-by: Tien Fong Chee Is this patch needed ? Why ? This enables a whole lot of stuff >>> These settings are mostly syn up from gen5 and our own downstream >>> A10. >>> These settings are mostly required to boot U-Boot and supporting >>> A10 >>> golden system reference design. >> Hmmm, mind you, all the MTD and SPI stuff is not needed for the SDMMC >> configuration of the kit, which this patch would imply is the target. >> You want to split this into smaller config changes which enable >> logical >> blocks, not everything at once, and document why is each thing >> needed. > I can keep them minimal, enable them when required in separate patch. Please do >> >>> > > > --- > configs/socfpga_arria10_defconfig | 38 > +++- > 1 files changed, 32 insertions(+), 6 deletions(-) > > diff --git a/configs/socfpga_arria10_defconfig > b/configs/socfpga_arria10_defconfig > index 8158dbb..4b93321 100644 > --- a/configs/socfpga_arria10_defconfig > +++ b/configs/socfpga_arria10_defconfig > @@ -1,7 +1,7 @@ > CONFIG_ARM=y > CONFIG_ARCH_SOCFPGA=y > CONFIG_SYS_TEXT_BASE=0x0140 > -CONFIG_SYS_MALLOC_F_LEN=0x2000 > +CONFIG_SYS_MALLOC_F_LEN=0x8000 >> Why is this increase in malloc area needed ? > This is set in the arria10_sdmmc_next, i guess you need this value for > your use case? I can revert it if it is no longer required. I mean, you're sending a patch, I'd expect you know what it does ? :-) [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 09/14] imx: serial: dm: Enable DM_FLAG_PRE_RELOC in the IMX uart driver
On 1/2/19 9:42 AM, Lukasz Majewski wrote: > Hi Marek, > >> On 1/2/19 12:37 AM, Lukasz Majewski wrote: >>> The DM_FLAG_PRE_RELOC shall be enabled as this driver is going to be >>> re-used in the i.MX based SoCs. >>> >>> It is crucial to have running the serial console before >>> relocation. >> >> But the patch doesn't do what the subject/commit message claims is >> does. If I understand it correctly, it sets the PRE_RELOC flag >> unconditionally. > > The !CONFIG_IS_ENABLED(OF_CONTROL) [*] was set as a "workaround" for DM > problem: > SHA1: 4687919684e0e4390b9fc20d1809ecaa9dc3cb81 > > Let's look on this check [*] - we add this flag if the board doesn't > support OF_CONTROL. This is a bit strange as the serial_mxc.c can be > used with CONFIG_DM_SERIAL but without corresponding device tree > description (OF_CONTROL). > > Other boards/SoCs have this flag set unconditionally. > > And one more remark - with OF_CONTROL one needs to declare > 'u-boot,dm-pre-reloc;' property in DTS to have the device probed in the > SPL's pre relocation stage. Explain it in the patch description and send V2. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 13/14] DTS: imx: tpc70: Add TPC70 board (imx6q based) device tree description
On 1/2/19 9:49 AM, Lukasz Majewski wrote: > Hi Marek, > >> On 1/2/19 12:37 AM, Lukasz Majewski wrote: >>> This commit defines the TPC70 imx6q board with device tree >>> description. >>> >>> Signed-off-by: Lukasz Majewski >> >> Is this pulled from Linux ? > > Yes, it is - the DTS code corresponds to v4.20 This should be in the commit message, including the commit hash of the commit from which this was taken. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cmd: usb: display bus number
On 1/2/19 12:29 PM, Heinrich Schuchardt wrote:
> If multiple USB buses exist, the output of the commands 'usb tree' and 'usb
> info' is confusing because it is not clear where the output for a new bus
> starts.
>
> Print an additional line for each bus indicating the bus number, e.g.
>
> => usb tree
> USB device tree:
> USB bus 0
> 1 Hub (5 Gb/s, 0mA)
> U-Boot XHCI Host Controller
>
> USB bus 1
> 1 Hub (5 Gb/s, 0mA)
> U-Boot XHCI Host Controller
>
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/usb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/cmd/usb.c b/cmd/usb.c
> index 0ccb1b5148..6da945c376 100644
> --- a/cmd/usb.c
> +++ b/cmd/usb.c
> @@ -470,6 +470,7 @@ static void usb_for_each_root_dev(usb_dev_func_t func)
> if (!device_active(bus))
> continue;
>
> + printf("USB bus %d\n", bus->seq);
Isn't this only valid if you use SEQ_ALIAS ?
> device_find_first_child(bus, &dev);
> if (dev && device_active(dev)) {
> udev = dev_get_parent_priv(dev);
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 10/14] imx: clock: Introduce set_fec_clock() to configure ETH clock (imx6)
On 1/2/19 10:00 AM, Lukasz Majewski wrote: > Hi Marek, > >> On 1/2/19 12:37 AM, Lukasz Majewski wrote: >>> This patch provides a generic way to setup ENET (ETH) clocks for >>> imx6(q) based boards. Previously this was performed per board in the >>> board_eth_init() function. >>> >>> Signed-off-by: Lukasz Majewski >>> --- >>> >>> arch/arm/include/asm/arch-mx6/clock.h | 1 + >>> arch/arm/mach-imx/mx6/clock.c | 17 + >>> 2 files changed, 18 insertions(+) >>> >>> diff --git a/arch/arm/include/asm/arch-mx6/clock.h >>> b/arch/arm/include/asm/arch-mx6/clock.h index >>> a9481a5fea..9a217349f5 100644 --- >>> a/arch/arm/include/asm/arch-mx6/clock.h +++ >>> b/arch/arm/include/asm/arch-mx6/clock.h @@ -72,6 +72,7 @@ int >>> enable_i2c_clk(unsigned char enable, unsigned i2c_num); int >>> enable_spi_clk(unsigned char enable, unsigned spi_num); void >>> enable_ipu_clock(void); int enable_fec_anatop_clock(int fec_id, >>> enum enet_freq freq); +int set_fec_clock(int fec_id, enum enet_freq >>> freq); void enable_enet_clk(unsigned char enable); >>> int enable_lcdif_clock(u32 base_addr, bool enable); >>> void enable_qspi_clk(int qspi_num); >>> diff --git a/arch/arm/mach-imx/mx6/clock.c >>> b/arch/arm/mach-imx/mx6/clock.c index 366a4e3c6b..8a4fb23090 100644 >>> --- a/arch/arm/mach-imx/mx6/clock.c >>> +++ b/arch/arm/mach-imx/mx6/clock.c >>> @@ -902,6 +902,17 @@ void enable_qspi_clk(int qspi_num) >>> #endif >>> >>> #ifdef CONFIG_FEC_MXC >>> +static void select_fec_clock_source(int fec_id) >> >> How is the fec_id() used in here ? > > I guess that you refer to "int fec_id." Yes, how is it used ? I guess it is not ... so why is this parameter even here ? >> Shouldn't this be part of >> enable_fec_anatop_clock() ? > > The enable_fec_anatop_clock() function is used on several board files > - for example: > http://git.denx.de/?p=u-boot.git;a=blob;f=board/dhelectronics/dh_imx6/dh_imx6.c;h=f9ac5c10e1dc954b64605a1c4f84a6c819d183a7;hb=HEAD#l154 > > And changing it could break some boards. > > The select_fec_clock_source() shall be used to replace several: > clrsetbits_le32(&iomuxc_regs->gpr[1], 0x1 << 21, 0x1 << 21); > > clauses for imx6 variants. > > Moreover, I'd pass 'fec_id' parameter anyway - it may be needed by other > imx6 variants. It can be added when it is needed. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 05/14] board: cosmetic: Use define to set ENET clock selection mask on TPC70
On 1/2/19 11:06 AM, Lukasz Majewski wrote: > Hi Marek, > >> On 1/2/19 12:37 AM, Lukasz Majewski wrote: >>> This is a cosmetic change, just to use proper define. >>> >>> Signed-off-by: Lukasz Majewski >> >> The subject tags are wrong, fix globally. > > Is there any doc which describes the allowed/not allowed tags (either > with Linux or U-boot)? I am not aware of one, however you can write one if you feel inclined to do so. > From my experience it is a some kind of a convention depending on the > maintainer (which helps him to spot relevant patches on ML). Right, and this is ARM imx board, hence those tags should be included. > In [1] - point 14) there is: > The canonical patch subject line is: > "Subject: [PATCH 001/123] subsystem: summary phrase" > > and the "subsystem: " is the tag. > > In the case of this patch -> I do fix stuff in "board(s)" which is > "cosmetic". > > Or will we only stick to tags/mails from ./doc/git-mailrc ? > > [1] - > https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 07/14] pinctrl: imx: Replace static soc info definitions with run time allocations
On 1/2/19 9:26 AM, Lukasz Majewski wrote: > Hi Marek, > >> On 1/2/19 12:37 AM, Lukasz Majewski wrote: >>> This commit is necessary to be able to re-use the pinctrl code in >>> early SPL to properly configure pins. >>> >>> The problem is that those "static" structures are placed in the >>> SDRAM area, which corresponds to u-boot proper (not even SPL). >>> Hence, when one wants to configure pins before relocation via >>> DTS/DM, the board hangs (imx6q SoC powered one) as only OCRAM area >>> is available (0x009x). >>> >>> It is also safe to use calloc in this case, as the early SPL code >>> provides it - either full or trimmed version. The allocated memory >>> is also correct in respect to the memory area in which the SoC is >>> currently running (OCRAM vs. SDRAM). >> >> You should be able to access static data in early environment, many >> other drivers have no problem with it. > > Have you used pinctrl IMX6Q driver with early DM at SPL? > >> I believe there is some more >> fundamental problem that needs to be fixed, > > With the current code - which was not used in OCRAM only available > memory - the statics are placed in the SDRAM area (0x178x ). > > Instead of changing linker script (and validate it for all drivers and > boards for SPL and u-boot proper) - the code has been rewritten to use > malloc (which is available in the early code - either full blown or > simple version). > >> hacking around it like >> this is just hiding the real issue. > > The real issue is that IMX6Q uses SDRAM memory for statics/globals from > the very beginning. Fix it ? What you're implying here is that rodata (preinitialized static variables) are misplaced. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 02/14] tpc70: config: Update TPC70 config to support eMMC's boot0 SPL update
On 1/2/19 10:47 AM, Lukasz Majewski wrote:
> Hi Marek,
>
>> On 1/2/19 12:37 AM, Lukasz Majewski wrote:
>>> The TPC70 can boot from eMMC's boot0. This patch allows it to update
>>> this HW partition's SPL.
>>>
>>> Signed-off-by: Lukasz Majewski
>>> ---
>>>
>>> include/configs/kp_imx6q_tpc.h | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/include/configs/kp_imx6q_tpc.h
>>> b/include/configs/kp_imx6q_tpc.h index ee9c56bc21..f26b18442b 100644
>>> --- a/include/configs/kp_imx6q_tpc.h
>>> +++ b/include/configs/kp_imx6q_tpc.h
>>> @@ -49,6 +49,7 @@
>>> #define CONFIG_SYS_FSL_ESDHC_ADDR 0
>>> #define CONFIG_SYS_FSL_USDHC_NUM 2
>>> #define CONFIG_SYS_MMC_ENV_DEV 1 /* 0 = SDHC2, 1 =
>>> SDHC4 (eMMC) */ +#define CONFIG_SUPPORT_EMMC_BOOT
>>>
>>> /* UART */
>>> #define CONFIG_MXC_UART
>>> @@ -109,6 +110,10 @@
>>>"setexpr blkc ${blkc} + 1;" \
>>>"mmc write ${loadaddr} 0x2 ${blkc};" \
>>> "fi;\0" \
>>> + "upd_SPL_mmc=mmc dev 1; mmc partconf 1 0 1 1; run
>>> upd_SPL_sd\0" \
>>
>> If mmc dev 1 fails, this will randomly rewrite or even damage some
>> SD/MMC card that was selected before
>> . Use && ...
>
> Ok - good point.
>
>>
>>> + "upd_uboot_mmc=mmc dev 1; mmc partconf 1 0 1 1; run
>>> upd_uboot_sd\0" \
>>
>> Deduplicate these repeated commands.
>
> Could you be more specific here?
>
> Without mmc dev 1 and partconf I cannot access boot0 eMMC area.
> This particular board has the SD as mmc0 (rescue/devel) and eMMC as
> mmc1 (and eMMC is a production boot medium).
The same commands are called from multiple scripts.
>>> + "up_mmc=run upd_SPL_mmc; run upd_uboot_mmc\0" \
>>> + "up_sd=run upd_SPL_sd; run upd_uboot_sd\0" \
>>> "upd_wic=" \
>>> "if tftp ${loadaddr} ${wic_file}; then " \
>>>"setexpr blkc ${filesize} / 0x200;" \
>>>
>>
>>
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 04/14] DTS: imx: Remove not needed '#address-cells' and '#size-cells' properties
On 1/2/19 10:43 AM, Lukasz Majewski wrote: > Hi Marek, > >> On 1/2/19 12:37 AM, Lukasz Majewski wrote: >>> This commit fixes warnings produced by newest in u-boot DTC >>> compiler: 'unnecessary #address-cells/#size-cells without "ranges" >>> or child "reg" property' >>> >>> Signed-off-by: Lukasz Majewski >> >> I presume the DTSIs are taken from Linux, is this a backport from >> Linux then ? > > Regarding Linux - with Version: DTC 1.4.7-gc86da84d and make W=1 I do > not see those warnings as in scripts/Makefile.lib : > > # Disable noisy checks by default > ifeq ($(findstring 1,$(KBUILD_ENABLE_EXTRA_GCC_CHECKS)),) > DTC_FLAGS += -Wno-unit_address_vs_reg \ > -Wno-unit_address_format \ > -Wno-avoid_unnecessary_addr_size \ > > those warnings are disabled (-Wno-avoid_unnecessary_addr_size). > > On the other hand - in u-boot those warnings are checked (maybe are > necessary for OF_PLATDATA correct operation?). No, keep the DTs synced and fix things upstream (in Linux) if needed, then backport the fixes. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 01/14] tpc70: config: Add script commands to update u-boot and OE's wic
On 1/2/19 10:50 AM, Lukasz Majewski wrote:
> Hi Marek,
>
>> On 1/2/19 12:37 AM, Lukasz Majewski wrote:
>>> Signed-off-by: Lukasz Majewski
>>
>> The tags should be ARM: imx: ...
>>
>> The commit message is missing.
>>
>>> ---
>>>
>>> include/configs/kp_imx6q_tpc.h | 21 +
>>> 1 file changed, 21 insertions(+)
>>>
>>> diff --git a/include/configs/kp_imx6q_tpc.h
>>> b/include/configs/kp_imx6q_tpc.h index b6b27ee1d5..ee9c56bc21 100644
>>> --- a/include/configs/kp_imx6q_tpc.h
>>> +++ b/include/configs/kp_imx6q_tpc.h
>>> @@ -89,11 +89,32 @@
>>> "rdinit=/sbin/init\0" \
>>> "addinitrd=setenv bootargs ${bootargs} rdinit=${rdinit}
>>> ${debug} \0" \ "fit_config=mx6q_tpc70_conf\0" \
>>> + "uboot_file=u-boot.img\0" \
>>> + "SPL_file=SPL\0" \
>>> + "wic_file=kp-image-kpimx6qtpc.wic\0" \
>>
>> Why don't you just generate a fitImage and use the fitupd for this ?
>
> This is one of possible solutions - yes.
It's the only solution if you want to prevent SPL and U-Boot from being
out of sync.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/8] rk3399-puma: Enable PWM regulator for RK3399-Q7
This patch series allows to tune VDD_LOG on RK3399-Q7 Puma boards to a voltage level defined in the DTS using a PWM adjustable regulator. To do so a reimplemenation of the RK3399 pinctrl driver has been done. Although the new pinctrl driver is written in a way, that we could merge it with other rockchip pinctrl drivers, this is not part of this series. The effect of the series is, that VDD_LOG will be set to about 950 mV on Puma. This is required to address stability issues on Puma. As a side effect, the pinctrl settings of all RK3399 boards will be configured according to the description in the DTS. Changes in v4: - Changed patches according to review feedback. Changes in v3: - Fix message verbosity in pinctrl driver. - Changed patches according to review feedback. - Add patch to enable the full pinctrl driver only for Puma boards. Changes in v2: - Changed patches according to review feedback. - Fix pinctrl infrastructure instead of hacking board_init() code. Christoph Muellner (8): rockchip: rk3399-puma: Cleanup of vdd_log DTS entry. power: regulator: Allow PWM regulator to be omitted from SPL. rockchip: rk3399-puma: enable PWM regulator in Puma defconfig. dm: pinctrl: Add pinctrl_decode_pin_config_dm(). rockchip: rk3399: Add improved pinctrl driver. rockchip: rk3399: Add Kconfig option for full pinctrl driver rockchip: rk3399-puma: enable full pinctrl driver in Puma defconfig. rockchip: rk3399-puma: Set VDD_LOG to 950 mV. arch/arm/dts/rk3399-puma.dtsi | 5 +- configs/puma-rk3399_defconfig | 2 + drivers/pinctrl/Kconfig | 10 ++ drivers/pinctrl/pinctrl-uclass.c | 22 +++ drivers/pinctrl/rockchip/pinctrl_rk3399.c | 236 ++ drivers/power/regulator/Kconfig | 7 + drivers/power/regulator/Makefile | 2 +- include/dm/pinctrl.h | 12 ++ 8 files changed, 291 insertions(+), 5 deletions(-) -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 8/8] rockchip: rk3399-puma: Set VDD_LOG to 950 mV.
This patch sets VDD_LOG to 950 mV on RK3399-Q7. This is required to address stability issues on Puma in heavy-load use-cases. Reported-by: Assaf Agmon Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- Changes in v4: - Changed patches according to review feedback. Changes in v3: - Fix message verbosity in pinctrl driver. - Changed patches according to review feedback. - Add patch to enable the full pinctrl driver only for Puma boards. Changes in v2: - Changed patches according to review feedback. - Fix pinctrl infrastructure instead of hacking board_init() code. arch/arm/dts/rk3399-puma.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi index 09f7992f65..8304f67192 100644 --- a/arch/arm/dts/rk3399-puma.dtsi +++ b/arch/arm/dts/rk3399-puma.dtsi @@ -172,7 +172,7 @@ regulator-max-microvolt = <140>; regulator-always-on; regulator-boot-on; - regulator-init-microvolt = <90>; + regulator-init-microvolt = <95>; }; }; -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 7/8] rockchip: rk3399-puma: enable full pinctrl driver in Puma defconfig.
This patch enables the full pinctrl driver in the defconfig for the RK3399-Q7. Signed-off-by: Christoph Muellner --- Changes in v4: None Changes in v3: None Changes in v2: None configs/puma-rk3399_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig index 1afa5a75f9..3c293b69e4 100644 --- a/configs/puma-rk3399_defconfig +++ b/configs/puma-rk3399_defconfig @@ -75,6 +75,7 @@ CONFIG_GMAC_ROCKCHIP=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_ROCKCHIP_RK3399=y +CONFIG_PINCTRL_ROCKCHIP_RK3399_FULL=y CONFIG_DM_PMIC=y CONFIG_DM_PMIC_FAN53555=y CONFIG_PMIC_RK8XX=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 6/8] rockchip: rk3399: Add Kconfig option for full pinctrl driver
This patch adds a Kconfig option to enable the full pinctrl driver
for the RK3399. This flag needs to be enabed in order to get the
features of the full pinctrl driver compiled in (i.e. a .set_state()
callback).
Signed-off-by: Christoph Muellner
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/pinctrl/Kconfig | 10 ++
drivers/pinctrl/rockchip/pinctrl_rk3399.c | 9 +
2 files changed, 19 insertions(+)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 1dbe2b104b..30a6aa6ee8 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -238,6 +238,16 @@ config PINCTRL_ROCKCHIP_RK3399
the GPIO definitions and pin control functions for each available
multiplex function.
+config PINCTRL_ROCKCHIP_RK3399_FULL
+ bool "Rockchip rk3399 pin control driver (full)"
+ depends on PINCTRL_FULL && PINCTRL_ROCKCHIP_RK3399
+ help
+ Support full pin multiplexing control on Rockchip rk3399 SoCs.
+
+ This enables the full pinctrl driver for the RK3399.
+ Contrary to the non-full pinctrl driver, this will evaluate
+ the board DTB to get the pinctrl settings.
+
config PINCTRL_ROCKCHIP_RV1108
bool "Rockchip rv1108 pin control driver"
depends on DM
diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3399.c
b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
index a1d5e8d0d5..c4746b0122 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3399.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
@@ -15,8 +15,10 @@
#include
#include
+#if CONFIG_IS_ENABLED(PINCTRL_ROCKCHIP_RK3399_FULL)
static const u32 RK_GRF_P_PULLUP = 1;
static const u32 RK_GRF_P_PULLDOWN = 2;
+#endif /* PINCTRL_ROCKCHIP_RK3399_FULL */
struct rk3399_pinctrl_priv {
struct rk3399_grf_regs *grf;
@@ -24,6 +26,7 @@ struct rk3399_pinctrl_priv {
struct rockchip_pin_bank *banks;
};
+#if CONFIG_IS_ENABLED(PINCTRL_ROCKCHIP_RK3399_FULL)
/* Location of pinctrl/pinconf registers. */
enum rk_grf_location {
RK_GRF,
@@ -244,6 +247,8 @@ end:
return ret;
}
+#endif /* PINCTRL_ROCKCHIP_RK3399_FULL */
+
static void pinctrl_rk3399_pwm_config(struct rk3399_grf_regs *grf,
struct rk3399_pmugrf_regs *pmugrf, int pwm_id)
{
@@ -693,7 +698,9 @@ static int rk3399_pinctrl_set_state_simple(struct udevice
*dev,
}
static struct pinctrl_ops rk3399_pinctrl_ops = {
+#if CONFIG_IS_ENABLED(PINCTRL_ROCKCHIP_RK3399_FULL)
.set_state = rk3399_pinctrl_set_state,
+#endif
.set_state_simple = rk3399_pinctrl_set_state_simple,
.request= rk3399_pinctrl_request,
.get_periph_id = rk3399_pinctrl_get_periph_id,
@@ -707,7 +714,9 @@ static int rk3399_pinctrl_probe(struct udevice *dev)
priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
debug("%s: grf=%p, pmugrf=%p\n", __func__, priv->grf, priv->pmugrf);
+#if CONFIG_IS_ENABLED(PINCTRL_ROCKCHIP_RK3399_FULL)
priv->banks = rk3399_pin_banks;
+#endif /* PINCTRL_ROCKCHIP_RK3399_FULL */
return ret;
}
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/8] dm: pinctrl: Add pinctrl_decode_pin_config_dm().
pinctrl_decode_pin_config_dm() is basically a feature-equivalent
implementation of pinctrl_decode_pin_config(), which operates
on struct udevice devices and uses the dev_read_*() API.
Signed-off-by: Christoph Muellner
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/pinctrl/pinctrl-uclass.c | 22 ++
include/dm/pinctrl.h | 12
2 files changed, 34 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-uclass.c b/drivers/pinctrl/pinctrl-uclass.c
index 29c910c55f..c8b38d78f6 100644
--- a/drivers/pinctrl/pinctrl-uclass.c
+++ b/drivers/pinctrl/pinctrl-uclass.c
@@ -27,6 +27,28 @@ int pinctrl_decode_pin_config(const void *blob, int node)
return flags;
}
+/*
+ * TODO: this function is temporary for v2019.01.
+ * It should be renamed to pinctrl_decode_pin_config(),
+ * the original pinctrl_decode_pin_config() function should
+ * be removed and all callers of the original function should
+ * be migrated to use the new one.
+ */
+int pinctrl_decode_pin_config_dm(struct udevice *dev)
+{
+ int pinconfig = 0;
+
+ if (dev->uclass->uc_drv->id != UCLASS_PINCONFIG)
+ return -EINVAL;
+
+ if (dev_read_bool(dev, "bias-pull-up"))
+ pinconfig |= 1 << PIN_CONFIG_BIAS_PULL_UP;
+ else if (dev_read_bool(dev, "bias-pull-down"))
+ pinconfig |= 1 << PIN_CONFIG_BIAS_PULL_DOWN;
+
+ return pinconfig;
+}
+
#if CONFIG_IS_ENABLED(PINCTRL_FULL)
/**
* pinctrl_config_one() - apply pinctrl settings for a single node
diff --git a/include/dm/pinctrl.h b/include/dm/pinctrl.h
index 63a7d55b88..ff2b82e7c2 100644
--- a/include/dm/pinctrl.h
+++ b/include/dm/pinctrl.h
@@ -355,6 +355,18 @@ int pinctrl_get_periph_id(struct udevice *dev, struct
udevice *periph);
int pinctrl_decode_pin_config(const void *blob, int node);
/**
+ * pinctrl_decode_pin_config_dm() - decode pin configuration flags
+ *
+ * This decodes some of the PIN_CONFIG values into flags, with each value
+ * being (1 << pin_cfg). This does not support things with values like the
+ * slew rate.
+ *
+ * @pinconfig: Pinconfig udevice
+ * @return decoded flag value, or -ve on error
+ */
+int pinctrl_decode_pin_config_dm(struct udevice *dev);
+
+/**
* pinctrl_get_gpio_mux() - get the mux value for a particular GPIO
*
* This allows the raw mux value for a GPIO to be obtained. It is
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 5/8] rockchip: rk3399: Add improved pinctrl driver.
The current pinctrl driver for the RK3399 has a range of qulity issues.
E.g. it only implements the .set_state_simple() callback, it
does not parse the available pinctrl information from the DTS
(instead uses hardcoded values), is not flexible enough to cover
devices without 'interrupt' field in the DTS (e.g. PWM),
is not written generic enough to make code reusable among other
rockchip SoCs...
This patch addresses these issues by reimplementing the whole driver
from scratch using the .set_state() callback.
The new implementation covers all featurese of the old code
(i.e. it supports pinmuxing and pullup/pulldown configuration).
This patch has been tested on a RK3399-Q7 SoM (Puma).
Signed-off-by: Christoph Muellner
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/pinctrl/rockchip/pinctrl_rk3399.c | 227 ++
1 file changed, 227 insertions(+)
diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3399.c
b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
index bc92dd7c06..a1d5e8d0d5 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3399.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * (C) 2018 Theobroma Systems Design und Consulting GmbH
*/
#include
@@ -14,11 +15,235 @@
#include
#include
+static const u32 RK_GRF_P_PULLUP = 1;
+static const u32 RK_GRF_P_PULLDOWN = 2;
+
struct rk3399_pinctrl_priv {
struct rk3399_grf_regs *grf;
struct rk3399_pmugrf_regs *pmugrf;
+ struct rockchip_pin_bank *banks;
+};
+
+/* Location of pinctrl/pinconf registers. */
+enum rk_grf_location {
+ RK_GRF,
+ RK_PMUGRF,
+};
+
+/**
+ * @nr_pins: number of pins in this bank
+ * @grf_location: location of pinctrl/pinconf registers
+ * @bank_num: number of the bank, to account for holes
+ * @iomux: array describing the 4 iomux sources of the bank
+ */
+struct rockchip_pin_bank {
+ u8 nr_pins;
+ enum rk_grf_location grf_location;
+ size_t iomux_offset;
+ size_t pupd_offset;
+};
+
+#define PIN_BANK(pins, grf, iomux, pupd) \
+ { \
+ .nr_pins = pins,\
+ .grf_location = grf,\
+ .iomux_offset = iomux, \
+ .pupd_offset = pupd,\
+ }
+
+static struct rockchip_pin_bank rk3399_pin_banks[] = {
+ PIN_BANK(16, RK_PMUGRF,
+offsetof(struct rk3399_pmugrf_regs, gpio0a_iomux),
+offsetof(struct rk3399_pmugrf_regs, gpio0_p)),
+ PIN_BANK(32, RK_PMUGRF,
+offsetof(struct rk3399_pmugrf_regs, gpio1a_iomux),
+offsetof(struct rk3399_pmugrf_regs, gpio1_p)),
+ PIN_BANK(32, RK_GRF,
+offsetof(struct rk3399_grf_regs, gpio2a_iomux),
+offsetof(struct rk3399_grf_regs, gpio2_p)),
+ PIN_BANK(32, RK_GRF,
+offsetof(struct rk3399_grf_regs, gpio3a_iomux),
+offsetof(struct rk3399_grf_regs, gpio3_p)),
+ PIN_BANK(32, RK_GRF,
+offsetof(struct rk3399_grf_regs, gpio4a_iomux),
+offsetof(struct rk3399_grf_regs, gpio4_p)),
};
+static void rk_pinctrl_get_info(uintptr_t base, u32 index, uintptr_t *addr,
+ u32 *shift, u32 *mask)
+{
+ /*
+* In general we four subsequent 32-bit configuration registers
+* per bank (e.g. GPIO2A_P, GPIO2B_P, GPIO2C_P, GPIO2D_P).
+* The configuration for each pin has two bits.
+*
+* @base...contains the address to the first register.
+* @index...defines the pin within the bank (0..31).
+* @addr...will be the address of the actual register to use
+* @shift...will be the bit position in the configuration register
+* @mask...will be the (unshifted) mask
+*/
+
+ const u32 pins_per_register = 8;
+ const u32 config_bits_per_pin = 2;
+
+ /* Get the address of the configuration register. */
+ *addr = base + (index / pins_per_register) * sizeof(u32);
+
+ /* Get the bit offset within the configuration register. */
+ *shift = (index & (pins_per_register - 1)) * config_bits_per_pin;
+
+ /* Get the (unshifted) mask for the configuration pins. */
+ *mask = ((1 << config_bits_per_pin) - 1);
+
+ pr_debug("%s: addr=0x%lx, mask=0x%x, shift=0x%x\n",
+__func__, *addr, *mask, *shift);
+}
+
+static void rk3399_pinctrl_set_pin_iomux(uintptr_t grf_addr,
+struct rockchip_pin_bank *bank,
+u32 index, u32 muxval)
+{
+ uintptr_t iomux_base, addr;
+ u32 shift, mask;
+
+ iomux_base = grf_addr + bank->iomux_offset;
+ rk_pinctrl_get_info(iomux_base, index, &addr, &shift, &mask);
+
+ /* Set
[U-Boot] [PATCH v4 3/8] rockchip: rk3399-puma: enable PWM regulator in Puma defconfig.
This patch enables the PWM regulator driver in the defconfig for the RK3399-Q7. Signed-off-by: Christoph Muellner --- Changes in v4: None Changes in v3: None Changes in v2: None configs/puma-rk3399_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig index a45a34be31..1afa5a75f9 100644 --- a/configs/puma-rk3399_defconfig +++ b/configs/puma-rk3399_defconfig @@ -79,6 +79,7 @@ CONFIG_DM_PMIC=y CONFIG_DM_PMIC_FAN53555=y CONFIG_PMIC_RK8XX=y CONFIG_SPL_DM_REGULATOR=y +CONFIG_REGULATOR_PWM=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_SPL_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/8] power: regulator: Allow PWM regulator to be omitted from SPL.
This patch allows to enable the PWM regulator driver independent for U-Boot and SPL. Signed-off-by: Christoph Muellner --- Changes in v4: None Changes in v3: None Changes in v2: None drivers/power/regulator/Kconfig | 7 +++ drivers/power/regulator/Makefile | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig index 09b311de8b..3ed0dd2264 100644 --- a/drivers/power/regulator/Kconfig +++ b/drivers/power/regulator/Kconfig @@ -61,6 +61,13 @@ config REGULATOR_PWM This driver is controlled by a device tree node which includes voltage limits. +config SPL_REGULATOR_PWM + bool "Enable Driver for PWM regulators in SPL" + depends on REGULATOR_PWM + help + This config enables implementation of driver-model regulator uclass + features for PWM regulators in SPL. + config DM_REGULATOR_MAX77686 bool "Enable Driver Model for REGULATOR MAX77686" depends on DM_REGULATOR && DM_PMIC_MAX77686 diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile index 8017045d54..f617ce723a 100644 --- a/drivers/power/regulator/Makefile +++ b/drivers/power/regulator/Makefile @@ -9,7 +9,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o obj-$(CONFIG_REGULATOR_AS3722) += as3722_regulator.o obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o -obj-$(CONFIG_REGULATOR_PWM) += pwm_regulator.o +obj-$(CONFIG_$(SPL_)REGULATOR_PWM) += pwm_regulator.o obj-$(CONFIG_$(SPL_)DM_REGULATOR_FAN53555) += fan53555.o obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/8] rockchip: rk3399-puma: Cleanup of vdd_log DTS entry.
This patch eliminates the non-standard entries "rockchip,pwm_id" and "rockchip,pwm_voltage". They are neither documented nor read out by any driver. Additionally it introduces the entry regulator-init-microvolt and sets it to 900 mV, which is the default target value for VDD_LOG. Signed-off-by: Christoph Muellner --- Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/dts/rk3399-puma.dtsi | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi index 9a61fbb453..09f7992f65 100644 --- a/arch/arm/dts/rk3399-puma.dtsi +++ b/arch/arm/dts/rk3399-puma.dtsi @@ -172,10 +172,7 @@ regulator-max-microvolt = <140>; regulator-always-on; regulator-boot-on; - - /* for rockchip boot on */ - rockchip,pwm_id= <2>; - rockchip,pwm_voltage = <100>; + regulator-init-microvolt = <90>; }; }; -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Re : Re : Re: please pull u-boot-samsung master
Hi,
- Guillaume GARDET a écrit :
>
> Hi,
>
> - Minkyu Kang a écrit :
> > Dear Guillaume GARDET,
> >
> > On 28/12/18 00:41, Tom Rini wrote:
> > > On Thu, Dec 27, 2018 at 12:49:53PM +0900, Minkyu Kang wrote:
> > >
> > >> Dear Tom,
> > >>
> > >> The following changes since commit
> > >> 1f2e948d6d53f77a2ddb2dde3531b0d5bc2815ad:
> > >>
> > >> Prepare v2019.01-rc2 (2018-12-17 20:25:24 -0500)
> > >>
> > >> are available in the git repository at:
> > >>
> > >> git://git.denx.de/u-boot-samsung master
> > >>
> > >> for you to fetch changes up to c96d90367a6a229210b8b16681cfe9e5c8aeced1:
> > >>
> > >> exynos: imply SYS_THUMB_BUILD (2018-12-26 11:57:48 +0900)
> > >>
> > >>
> > >> Anand Moon (2):
> > >> exynos5-dt-types: add missing dtb file for Odroid HC1/HC2
> > >> odroid: Update README.odroid for support of Odroid HC1
> > >>
> > >> Guillaume GARDET (1):
> > >> exynos: imply SYS_THUMB_BUILD
> > >>
> > >> Seung-Woo Kim (1):
> > >> Revert "arm: config: fix default console only to specify the
> > >> device"
> > >>
> > >> arch/arm/Kconfig| 1 +
> > >> doc/README.odroid | 7 +--
> > >> include/configs/odroid.h| 4 ++--
> > >> include/configs/odroid_xu3.h| 5 +++--
> > >> include/configs/s5p_goni.h | 4 ++--
> > >> include/configs/s5pc210_universal.h | 4 ++--
> > >> include/configs/trats.h | 4 ++--
> > >> include/configs/trats2.h| 4 ++--
> > >> 8 files changed, 19 insertions(+), 14 deletions(-)
> > >
> > > NAK:
> > > 18: Merge branch 'master' of git://git.denx.de/u-boot-samsung
> > >arm: + peach-pi smdk5420 peach-pit
> > > +(peach-pi,smdk5420,peach-pit) {standard input}: Assembler messages:
> > > +(peach-pi,smdk5420,peach-pit) {standard input}:117: Error: Thumb
> > > encoding does not support an immediate here -- `msr cpsr_c,#0x13|0xC0'
> > > +(peach-pi,smdk5420,peach-pit) {standard input}:325: Error: Thumb
> > > encoding does not support an immediate here -- `msr cpsr_c,#0x13|0xC0'
> > > +(peach-pi,smdk5420,peach-pit) make[3]: ***
> > > [../scripts/Makefile.build:279: spl/arch/arm/mach-exynos/lowlevel_init.o]
> > > Error 1
> > > +(peach-pi,smdk5420,peach-pit) make[2]: *** [../scripts/Makefile.spl:383:
> > > spl/arch/arm/mach-exynos] Error 2
> > > +(peach-pi,smdk5420,peach-pit) make[1]: *** [Makefile:1597:
> > > spl/u-boot-spl] Error 2
> > > +(peach-pi,smdk5420,peach-pit) make: *** [Makefile:148: sub-make] Error 2
> > >
> >
> > Because of this, thumb build feature cannot applied.
> > Do you have an idea?
>
> We should disable thumb explicitly for this board.
>
> I will not be in front of a computer for the next days, so please wait until
> 2nd of January, or you can do it, if you want.
Instead of disabling thumb for SPL in 3 default configs, I sent a patch to get
it built in thumb mode:
https://lists.denx.de/pipermail/u-boot/2019-January/353347.html
Build tested on peach-pi peach-pit and smdk5420 configs.
Thanks,
Guillaume
>
> Thanks,
> Guillaume
>
> >
> > Thanks,
> > Minkyu Kang.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] exynos: allow SPL to build in thumb mode
Building peach-pi smdk5420 and peach-pit with thumb mode for SPL
ends-up in the following error:
Error: Thumb encoding does not support an immediate here -- `msr
cpsr_c,#0x13|0xC0'
Use an intermediate register to be able to use thumb for exynos5 SPL.
Signed-off-by: Guillaume GARDET
Cc: Albert Aribaud
Cc: Minkyu Kang
Cc: Tom Rini
---
arch/arm/mach-exynos/include/mach/system.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/include/mach/system.h
b/arch/arm/mach-exynos/include/mach/system.h
index 4837781957..81fa9800b4 100644
--- a/arch/arm/mach-exynos/include/mach/system.h
+++ b/arch/arm/mach-exynos/include/mach/system.h
@@ -58,7 +58,8 @@ struct exynos5_sysreg {
/* Move 0xd3 value to CPSR register to enable SVC mode */
#define svc32_mode_en() __asm__ __volatile__ \
("@ I&F disable, Mode: 0x13 - SVC\n\t" \
-"msr cpsr_c, #0x13|0xC0\n\t" : : )
+"mov r0, #0x13|0xC0\n\t" \
+"msr cpsr_c, r0\n\t" : : )
/* Set program counter with the given value */
#define set_pc(x) __asm__ __volatile__ ("mov pc, %0\n\t" : : "r"(x))
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 9/9] ARM: dts: rk322x: Correct the uart2 default pin configuration
To match the iomux setting of uart2 at SPL, correct the uart2
default pin configuration, if not changed, the evb-rk3229 can't
output the log message.
Signed-off-by: David Wu
---
Changes in v2: None
arch/arm/dts/rk322x.dtsi | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/rk322x.dtsi b/arch/arm/dts/rk322x.dtsi
index be026b0e07..4a8be5dabb 100644
--- a/arch/arm/dts/rk322x.dtsi
+++ b/arch/arm/dts/rk322x.dtsi
@@ -206,7 +206,7 @@
clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
clock-names = "baudclk", "apb_pclk";
pinctrl-names = "default";
- pinctrl-0 = <&uart2_xfer>;
+ pinctrl-0 = <&uart21_xfer>;
reg-shift = <2>;
reg-io-width = <4>;
status = "disabled";
@@ -748,7 +748,7 @@
uart2 {
uart2_xfer: uart2-xfer {
- rockchip,pins = <1 RK_PC2 RK_FUNC_2
&pcfg_pull_none>,
+ rockchip,pins = <1 RK_PC2 RK_FUNC_2
&pcfg_pull_up>,
<1 RK_PC3 RK_FUNC_2
&pcfg_pull_none>;
};
@@ -760,6 +760,13 @@
rockchip,pins = <0 RK_PD0 RK_FUNC_1
&pcfg_pull_none>;
};
};
+
+ uart2-1 {
+ uart21_xfer: uart21-xfer {
+ rockchip,pins = <1 10 RK_FUNC_2 &pcfg_pull_up>,
+ <1 9 RK_FUNC_2 &pcfg_pull_none>;
+ };
+ };
};
dmc: dmc@1120 {
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 7/9] rockchip: defconfig: Clean the unused pinctrl config
If we used the pinctrl-rockchip driver, these config is not needed, so remove them. Signed-off-by: David Wu --- Changes in v2: None configs/chromebit_mickey_defconfig | 2 -- configs/chromebook_jerry_defconfig | 2 -- configs/chromebook_minnie_defconfig | 2 -- configs/evb-px5_defconfig | 1 - configs/evb-rk3128_defconfig| 1 - configs/evb-rk3229_defconfig| 1 - configs/evb-rk3288_defconfig| 2 -- configs/evb-rk3399_defconfig| 1 - configs/evb-rv1108_defconfig| 1 - configs/fennec-rk3288_defconfig | 2 -- configs/firefly-rk3288_defconfig| 2 -- configs/firefly-rk3399_defconfig| 1 - configs/geekbox_defconfig | 1 - configs/kylin-rk3036_defconfig | 1 - configs/lion-rk3368_defconfig | 1 - configs/miqi-rk3288_defconfig | 2 -- configs/phycore-rk3288_defconfig| 2 -- configs/popmetal-rk3288_defconfig | 2 -- configs/puma-rk3399_defconfig | 1 - configs/rock2_defconfig | 2 -- configs/rock_defconfig | 1 - configs/sandbox_defconfig | 2 -- configs/sandbox_flattree_defconfig | 2 -- configs/sandbox_noblk_defconfig | 2 -- configs/sheep-rk3368_defconfig | 1 - configs/tinker-rk3288_defconfig | 2 -- configs/vyasa-rk3288_defconfig | 2 -- 27 files changed, 42 deletions(-) diff --git a/configs/chromebit_mickey_defconfig b/configs/chromebit_mickey_defconfig index 5fbb5a4ebc..2b3e7b409a 100644 --- a/configs/chromebit_mickey_defconfig +++ b/configs/chromebit_mickey_defconfig @@ -61,8 +61,6 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y -# CONFIG_SPL_PINCTRL_FULL is not set -CONFIG_PINCTRL_ROCKCHIP_RK3288=y CONFIG_DM_PMIC=y # CONFIG_SPL_PMIC_CHILDREN is not set CONFIG_PMIC_RK8XX=y diff --git a/configs/chromebook_jerry_defconfig b/configs/chromebook_jerry_defconfig index f6f0697050..d8db223e90 100644 --- a/configs/chromebook_jerry_defconfig +++ b/configs/chromebook_jerry_defconfig @@ -63,8 +63,6 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y -# CONFIG_SPL_PINCTRL_FULL is not set -CONFIG_PINCTRL_ROCKCHIP_RK3288=y CONFIG_DM_PMIC=y # CONFIG_SPL_PMIC_CHILDREN is not set CONFIG_PMIC_RK8XX=y diff --git a/configs/chromebook_minnie_defconfig b/configs/chromebook_minnie_defconfig index 705a3cd0e5..ee92a22e18 100644 --- a/configs/chromebook_minnie_defconfig +++ b/configs/chromebook_minnie_defconfig @@ -62,8 +62,6 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y -# CONFIG_SPL_PINCTRL_FULL is not set -CONFIG_PINCTRL_ROCKCHIP_RK3288=y CONFIG_DM_PMIC=y # CONFIG_SPL_PMIC_CHILDREN is not set CONFIG_PMIC_RK8XX=y diff --git a/configs/evb-px5_defconfig b/configs/evb-px5_defconfig index c3bda3bf3b..1d428e7ac8 100644 --- a/configs/evb-px5_defconfig +++ b/configs/evb-px5_defconfig @@ -22,7 +22,6 @@ CONFIG_CLK=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_PINCTRL=y -CONFIG_PINCTRL_ROCKCHIP_RK3368=y CONFIG_RAM=y CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y diff --git a/configs/evb-rk3128_defconfig b/configs/evb-rk3128_defconfig index 044e60735a..17ad6ae58d 100644 --- a/configs/evb-rk3128_defconfig +++ b/configs/evb-rk3128_defconfig @@ -31,7 +31,6 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_PHY=y CONFIG_PINCTRL=y -CONFIG_PINCTRL_ROCKCHIP_RK3128=y CONFIG_REGULATOR_PWM=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_RAM=y diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig index 0cc92a3314..14ff54af20 100644 --- a/configs/evb-rk3229_defconfig +++ b/configs/evb-rk3229_defconfig @@ -44,7 +44,6 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_PHY=y CONFIG_PINCTRL=y -CONFIG_PINCTRL_ROCKCHIP_RK322X=y CONFIG_RAM=y CONFIG_SPL_RAM=y CONFIG_BAUDRATE=150 diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig index 1485844aa6..4bf548790c 100644 --- a/configs/evb-rk3288_defconfig +++ b/configs/evb-rk3288_defconfig @@ -57,8 +57,6 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y -# CONFIG_SPL_PINCTRL_FULL is not set -CONFIG_PINCTRL_ROCKCHIP_RK3288=y CONFIG_DM_PMIC=y CONFIG_PMIC_ACT8846=y CONFIG_REGULATOR_ACT8846=y diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig index 27cf8304be..9746755f1e 100644 --- a/configs/evb-rk3399_defconfig +++ b/configs/evb-rk3399_defconfig @@ -49,7 +49,6 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y -CONFIG_PINCTRL_ROCKCHIP_RK3399=y CONFIG_DM_PMIC=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y diff --git a/configs/evb-rv1108_defconfig b/configs/evb-rv1108_defconfig index 2ef041f2c5..7836a772e2 100644 --- a/configs/evb-rv1108_defconfig +++ b/configs/evb-rv1108_defconfig @@ -37,7 +37,6 @@ CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_PINCTRL=y -CONFIG_PINCTRL_ROCKCHIP_RV1108=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_BAUDRATE=150 # CO
[U-Boot] [PATCH v2 6/9] pinctrl: rockchip: Add common rockchip pinctrl driver
Use this driver to fit all Rockchip SOCs and to support the desired pinctrl configuration via DTS. Signed-off-by: David Wu --- Changes in v2: - Remove px30, rk2928, rk3066*. - Split it to multiple files for the relevant per-SoC data structures. drivers/pinctrl/Kconfig | 91 +- drivers/pinctrl/Makefile | 2 +- drivers/pinctrl/rockchip/Kconfig | 17 + drivers/pinctrl/rockchip/Makefile | 19 +- drivers/pinctrl/rockchip/pinctrl-rk3036.c | 65 ++ drivers/pinctrl/rockchip/pinctrl-rk3128.c | 155 drivers/pinctrl/rockchip/pinctrl-rk3188.c | 82 ++ drivers/pinctrl/rockchip/pinctrl-rk322x.c | 215 + drivers/pinctrl/rockchip/pinctrl-rk3288.c | 157 drivers/pinctrl/rockchip/pinctrl-rk3328.c | 227 + drivers/pinctrl/rockchip/pinctrl-rk3368.c | 116 +++ drivers/pinctrl/rockchip/pinctrl-rk3399.c | 193 + .../pinctrl/rockchip/pinctrl-rockchip-core.c | 788 ++ drivers/pinctrl/rockchip/pinctrl-rockchip.h | 302 +++ drivers/pinctrl/rockchip/pinctrl-rv1108.c | 203 + 15 files changed, 2532 insertions(+), 100 deletions(-) create mode 100644 drivers/pinctrl/rockchip/Kconfig create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3036.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3128.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3188.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk322x.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3288.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3328.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3368.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3399.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rockchip-core.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rockchip.h create mode 100644 drivers/pinctrl/rockchip/pinctrl-rv1108.c diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index 7e6fad305a..d2168f7b72 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -158,96 +158,6 @@ config PINCTRL_QCA953X the GPIO definitions and pin control functions for each available multiplex function. -config PINCTRL_ROCKCHIP_RK3036 - bool "Rockchip rk3036 pin control driver" - depends on DM - help - Support pin multiplexing control on Rockchip rk3036 SoCs. - - The driver is controlled by a device tree node which contains both - the GPIO definitions and pin control functions for each available - multiplex function. - -config PINCTRL_ROCKCHIP_RK3128 - bool "Rockchip rk3128 pin control driver" - depends on DM - help - Support pin multiplexing control on Rockchip rk3128 SoCs. - - The driver is controlled by a device tree node which contains both - the GPIO definitions and pin control functions for each available - multiplex function. - -config PINCTRL_ROCKCHIP_RK3188 - bool "Rockchip rk3188 pin control driver" - depends on DM - help - Support pin multiplexing control on Rockchip rk3188 SoCs. - - The driver is controlled by a device tree node which contains both - the GPIO definitions and pin control functions for each available - multiplex function. - -config PINCTRL_ROCKCHIP_RK322X - bool "Rockchip rk322x pin control driver" - depends on DM - help - Support pin multiplexing control on Rockchip rk322x SoCs. - - The driver is controlled by a device tree node which contains both - the GPIO definitions and pin control functions for each available - multiplex function. - -config PINCTRL_ROCKCHIP_RK3288 - bool "Rockchip rk3288 pin control driver" - depends on DM - help - Support pin multiplexing control on Rockchip rk3288 SoCs. - - The driver is controlled by a device tree node which contains both - the GPIO definitions and pin control functions for each available - multiplex function. - -config PINCTRL_ROCKCHIP_RK3328 - bool "Rockchip rk3328 pin control driver" - depends on DM - help - Support pin multiplexing control on Rockchip rk3328 SoCs. - - The driver is controlled by a device tree node which contains both - the GPIO definitions and pin control functions for each available - multiplex function. - -config PINCTRL_ROCKCHIP_RK3368 - bool "Rockchip RK3368 pin control driver" - depends on DM - help - Support pin multiplexing control on Rockchip rk3368 SoCs. - - The driver is controlled by a device tree node which contains both - the GPIO definitions and pin control functions for each available - multiplex function. - -config PINCTRL_ROCKCHIP_RK3399 - bool "Rockchip rk3399 pin control driver" - depends on DM - help - Support pin multiplexing contr
[U-Boot] [PATCH v2 5/9] rk3288: chrome: defconfig: Enable FDT for new pinctrl driver
The FDT is requested for new pinctrl driver, disable SPL_OF_PLATDATA and enable SPL_OF_LIBFDT to make FDT be built in. Signed-off-by: David Wu --- Changes in v2: None configs/chromebit_mickey_defconfig | 2 -- configs/chromebook_jerry_defconfig | 2 -- configs/chromebook_minnie_defconfig | 2 -- 3 files changed, 6 deletions(-) diff --git a/configs/chromebit_mickey_defconfig b/configs/chromebit_mickey_defconfig index 79ab6acaec..5fbb5a4ebc 100644 --- a/configs/chromebit_mickey_defconfig +++ b/configs/chromebit_mickey_defconfig @@ -38,7 +38,6 @@ CONFIG_SPL_PARTITION_UUIDS=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-mickey" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" -CONFIG_SPL_OF_PLATDATA=y CONFIG_REGMAP=y CONFIG_SPL_REGMAP=y CONFIG_SYSCON=y @@ -93,4 +92,3 @@ CONFIG_DISPLAY_ROCKCHIP_HDMI=y CONFIG_USE_TINY_PRINTF=y CONFIG_CMD_DHRYSTONE=y CONFIG_ERRNO_STR=y -# CONFIG_SPL_OF_LIBFDT is not set diff --git a/configs/chromebook_jerry_defconfig b/configs/chromebook_jerry_defconfig index d892d65bf0..f6f0697050 100644 --- a/configs/chromebook_jerry_defconfig +++ b/configs/chromebook_jerry_defconfig @@ -40,7 +40,6 @@ CONFIG_SPL_PARTITION_UUIDS=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-jerry" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" -CONFIG_SPL_OF_PLATDATA=y CONFIG_REGMAP=y CONFIG_SPL_REGMAP=y CONFIG_SYSCON=y @@ -95,4 +94,3 @@ CONFIG_DISPLAY_ROCKCHIP_HDMI=y CONFIG_USE_TINY_PRINTF=y CONFIG_CMD_DHRYSTONE=y CONFIG_ERRNO_STR=y -# CONFIG_SPL_OF_LIBFDT is not set diff --git a/configs/chromebook_minnie_defconfig b/configs/chromebook_minnie_defconfig index b042874073..705a3cd0e5 100644 --- a/configs/chromebook_minnie_defconfig +++ b/configs/chromebook_minnie_defconfig @@ -39,7 +39,6 @@ CONFIG_SPL_PARTITION_UUIDS=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-minnie" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" -CONFIG_SPL_OF_PLATDATA=y CONFIG_REGMAP=y CONFIG_SPL_REGMAP=y CONFIG_SYSCON=y @@ -95,4 +94,3 @@ CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_USE_TINY_PRINTF=y CONFIG_CMD_DHRYSTONE=y CONFIG_ERRNO_STR=y -# CONFIG_SPL_OF_LIBFDT is not set -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/9] ARM: rockchip: Remove the pinctrl request at rk3288-board-spl
If we use the new pinctrl driver, the pinctrl setup will be done
by device probe. Remove the pinctrl setup at rk3288-board-spl.
Signed-off-by: David Wu
Reviewed-by: Philipp Tomsich
---
Changes in v2: None
arch/arm/mach-rockchip/rk3288-board-spl.c | 79 ---
1 file changed, 79 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c
b/arch/arm/mach-rockchip/rk3288-board-spl.c
index abd62e520f..9463b255e1 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -77,45 +77,6 @@ fallback:
return BOOT_DEVICE_MMC1;
}
-#ifdef CONFIG_SPL_MMC_SUPPORT
-static int configure_emmc(struct udevice *pinctrl)
-{
-#if defined(CONFIG_TARGET_CHROMEBOOK_JERRY)
-
- struct gpio_desc desc;
- int ret;
-
- pinctrl_request_noflags(pinctrl, PERIPH_ID_EMMC);
-
- /*
-* TODO(s...@chromium.org): Pick this up from device tree or perhaps
-* use the EMMC_PWREN setting.
-*/
- ret = dm_gpio_lookup_name("D9", &desc);
- if (ret) {
- debug("gpio ret=%d\n", ret);
- return ret;
- }
- ret = dm_gpio_request(&desc, "emmc_pwren");
- if (ret) {
- debug("gpio_request ret=%d\n", ret);
- return ret;
- }
- ret = dm_gpio_set_dir_flags(&desc, GPIOD_IS_OUT);
- if (ret) {
- debug("gpio dir ret=%d\n", ret);
- return ret;
- }
- ret = dm_gpio_set_value(&desc, 1);
- if (ret) {
- debug("gpio value ret=%d\n", ret);
- return ret;
- }
-#endif
- return 0;
-}
-#endif
-
#if !defined(CONFIG_SPL_OF_PLATDATA)
static int phycore_init(void)
{
@@ -144,7 +105,6 @@ static int phycore_init(void)
void board_init_f(ulong dummy)
{
- struct udevice *pinctrl;
struct udevice *dev;
int ret;
@@ -183,12 +143,6 @@ void board_init_f(ulong dummy)
return;
}
- ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
- if (ret) {
- debug("Pinctrl init failed: %d\n", ret);
- return;
- }
-
#if !defined(CONFIG_SPL_OF_PLATDATA)
if (of_machine_is_compatible("phytec,rk3288-phycore-som")) {
ret = phycore_init();
@@ -239,52 +193,19 @@ static int setup_led(void)
void spl_board_init(void)
{
- struct udevice *pinctrl;
int ret;
ret = setup_led();
-
if (ret) {
debug("LED ret=%d\n", ret);
hang();
}
- ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
- if (ret) {
- debug("%s: Cannot find pinctrl device\n", __func__);
- goto err;
- }
-
-#ifdef CONFIG_SPL_MMC_SUPPORT
- ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_SDCARD);
- if (ret) {
- debug("%s: Failed to set up SD card\n", __func__);
- goto err;
- }
- ret = configure_emmc(pinctrl);
- if (ret) {
- debug("%s: Failed to set up eMMC\n", __func__);
- goto err;
- }
-#endif
-
- /* Enable debug UART */
- ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_UART_DBG);
- if (ret) {
- debug("%s: Failed to set up console UART\n", __func__);
- goto err;
- }
-
preloader_console_init();
#if CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM)
back_to_bootrom(BROM_BOOT_NEXTSTAGE);
#endif
return;
-err:
- printf("spl_board_init: Error %d\n", ret);
-
- /* No way to report error here */
- hang();
}
#ifdef CONFIG_SPL_OS_BOOT
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/9] ARM: rockchip: Kconfig: Remove the SPL_PINCTRL for rk3188
It seems that pinctrl is not requested for rk3188 SPL, remove it so that can save more space for SPL image size. Signed-off-by: David Wu Reviewed-by: Philipp Tomsich --- Changes in v2: None arch/arm/mach-rockchip/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 6dc8e3a017..15c6ed2340 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -29,7 +29,6 @@ config ROCKCHIP_RK3188 select SUPPORT_SPL select SPL select SPL_CLK - select SPL_PINCTRL select SPL_REGMAP select SPL_SYSCON select SPL_RAM -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/9] rockchip: rk3399-evb: defconfig: Enable FDT for new pinctrl driver
The FDT is requested for new pinctrl driver, disable SPL_OF_PLATDATA to make FDT be built in. Signed-off-by: David Wu --- Changes in v2: None configs/evb-rk3399_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig index f173c10a6b..27cf8304be 100644 --- a/configs/evb-rk3399_defconfig +++ b/configs/evb-rk3399_defconfig @@ -31,7 +31,6 @@ CONFIG_CMD_TIME=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" -CONFIG_SPL_OF_PLATDATA=y CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_REGMAP=y -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/9] ARM: rockchip: rk3188: Remove the pinctrl setup and enable uart at SPL
When the boot ROM sets up MMC we don't need to do it again. Remove the
MMC setup code entirely, but we also need to enable uart for debug message.
Signed-off-by: David Wu
---
Changes in v2: None
arch/arm/mach-rockchip/rk3188-board-spl.c | 41 ++-
1 file changed, 2 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3188-board-spl.c
b/arch/arm/mach-rockchip/rk3188-board-spl.c
index 3c6c3d3c09..a5e4d39cb7 100644
--- a/arch/arm/mach-rockchip/rk3188-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3188-board-spl.c
@@ -120,7 +120,7 @@ void board_debug_uart_init(void)
void board_init_f(ulong dummy)
{
- struct udevice *pinctrl, *dev;
+ struct udevice *dev;
int ret;
#define EARLY_UART
@@ -134,10 +134,7 @@ void board_init_f(ulong dummy)
* printascii("string");
*/
debug_uart_init();
- printch('s');
- printch('p');
- printch('l');
- printch('\n');
+ printascii("U-Boot SPL board init");
#endif
#ifdef CONFIG_ROCKCHIP_USB_UART
@@ -171,12 +168,6 @@ void board_init_f(ulong dummy)
return;
}
- ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
- if (ret) {
- debug("Pinctrl init failed: %d\n", ret);
- return;
- }
-
ret = uclass_get_device(UCLASS_RAM, 0, &dev);
if (ret) {
debug("DRAM init failed: %d\n", ret);
@@ -214,7 +205,6 @@ static int setup_led(void)
void spl_board_init(void)
{
- struct udevice *pinctrl;
int ret;
ret = setup_led();
@@ -223,36 +213,9 @@ void spl_board_init(void)
hang();
}
- ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
- if (ret) {
- debug("%s: Cannot find pinctrl device\n", __func__);
- goto err;
- }
-
-#ifdef CONFIG_SPL_MMC_SUPPORT
- ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_SDCARD);
- if (ret) {
- debug("%s: Failed to set up SD card\n", __func__);
- goto err;
- }
-#endif
-
- /* Enable debug UART */
- ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_UART_DBG);
- if (ret) {
- debug("%s: Failed to set up console UART\n", __func__);
- goto err;
- }
-
preloader_console_init();
#if CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM)
back_to_bootrom(BROM_BOOT_NEXTSTAGE);
#endif
return;
-
-err:
- printf("spl_board_init: Error %d\n", ret);
-
- /* No way to report error here */
- hang();
}
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/9] Add common pinctrl driver support for rockchip
The common pinctrl driver for rockchip Socs, it depends the PINCTRL_FULL config. If use it, the default pinctrl setup from DTS could be configured at device probe. Changes in v2: - Remove px30, rk2928, rk3066*. - Split it to multiple files for the relevant per-SoC data structures. David Wu (9): rockchip: rk3399-evb: defconfig: Enable FDT for new pinctrl driver ARM: rockchip: rk3188: Remove the pinctrl setup and enable uart at SPL ARM: rockchip: Kconfig: Remove the SPL_PINCTRL for rk3188 ARM: rockchip: Remove the pinctrl request at rk3288-board-spl rk3288: chrome: defconfig: Enable FDT for new pinctrl driver pinctrl: rockchip: Add common rockchip pinctrl driver rockchip: defconfig: Clean the unused pinctrl config pinctrl: rockchip: Clean the unused rockchip pinctrl drivers ARM: dts: rk322x: Correct the uart2 default pin configuration arch/arm/dts/rk322x.dtsi | 11 +- arch/arm/mach-rockchip/Kconfig| 1 - arch/arm/mach-rockchip/rk3188-board-spl.c | 41 +- arch/arm/mach-rockchip/rk3288-board-spl.c | 79 -- configs/chromebit_mickey_defconfig| 4 - configs/chromebook_jerry_defconfig| 4 - configs/chromebook_minnie_defconfig | 4 - configs/evb-px5_defconfig | 1 - configs/evb-rk3128_defconfig | 1 - configs/evb-rk3229_defconfig | 1 - configs/evb-rk3288_defconfig | 2 - configs/evb-rk3399_defconfig | 2 - configs/evb-rv1108_defconfig | 1 - configs/fennec-rk3288_defconfig | 2 - configs/firefly-rk3288_defconfig | 2 - configs/firefly-rk3399_defconfig | 1 - configs/geekbox_defconfig | 1 - configs/kylin-rk3036_defconfig| 1 - configs/lion-rk3368_defconfig | 1 - configs/miqi-rk3288_defconfig | 2 - configs/phycore-rk3288_defconfig | 2 - configs/popmetal-rk3288_defconfig | 2 - configs/puma-rk3399_defconfig | 1 - configs/rock2_defconfig | 2 - configs/rock_defconfig| 1 - configs/sandbox_defconfig | 2 - configs/sandbox_flattree_defconfig| 2 - configs/sandbox_noblk_defconfig | 2 - configs/sheep-rk3368_defconfig| 1 - configs/tinker-rk3288_defconfig | 2 - configs/vyasa-rk3288_defconfig| 2 - drivers/pinctrl/Kconfig | 91 +- drivers/pinctrl/Makefile | 2 +- drivers/pinctrl/rockchip/Kconfig | 17 + drivers/pinctrl/rockchip/Makefile | 19 +- drivers/pinctrl/rockchip/pinctrl-rk3036.c | 65 ++ drivers/pinctrl/rockchip/pinctrl-rk3128.c | 155 +++ drivers/pinctrl/rockchip/pinctrl-rk3188.c | 82 ++ drivers/pinctrl/rockchip/pinctrl-rk322x.c | 215 drivers/pinctrl/rockchip/pinctrl-rk3288.c | 157 +++ drivers/pinctrl/rockchip/pinctrl-rk3328.c | 227 drivers/pinctrl/rockchip/pinctrl-rk3368.c | 116 ++ drivers/pinctrl/rockchip/pinctrl-rk3399.c | 193 .../pinctrl/rockchip/pinctrl-rockchip-core.c | 788 ++ drivers/pinctrl/rockchip/pinctrl-rockchip.h | 302 ++ drivers/pinctrl/rockchip/pinctrl-rv1108.c | 203 drivers/pinctrl/rockchip/pinctrl_rk3036.c | 671 drivers/pinctrl/rockchip/pinctrl_rk3128.c | 186 drivers/pinctrl/rockchip/pinctrl_rk3188.c | 989 -- drivers/pinctrl/rockchip/pinctrl_rk322x.c | 894 drivers/pinctrl/rockchip/pinctrl_rk3288.c | 869 --- drivers/pinctrl/rockchip/pinctrl_rk3328.c | 705 - drivers/pinctrl/rockchip/pinctrl_rk3368.c | 739 - drivers/pinctrl/rockchip/pinctrl_rk3399.c | 503 - drivers/pinctrl/rockchip/pinctrl_rv1108.c | 580 -- 55 files changed, 2543 insertions(+), 6406 deletions(-) create mode 100644 drivers/pinctrl/rockchip/Kconfig create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3036.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3128.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3188.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk322x.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3288.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3328.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3368.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3399.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rockchip-core.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rockchip.h create mode 100644 drivers/pinctrl/rockchip/pinctrl-rv1108.c delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3036.c delete mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3128.c delete mode 100644 drivers/pinctrl/ro
Re: [U-Boot] [PATCH 2/6] riscv: remove invalid dcache flush implementation
Hi Rick,
On Wed, 2019-01-02 at 10:54 +0800, Rick Chen wrote:
> Hi Lukas
>
> > > From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> > > Sent: Monday, December 31, 2018 2:28 AM
> > > To: u-boot@lists.denx.de
> > > Cc: Anup Patel; Lukas Auer; Rick Jian-Zhi Chen(陳建志); Bin Meng;
> > > Greentime Hu
> > > Subject: [PATCH 2/6] riscv: remove invalid dcache flush
> > > implementation
> > >
> > > The fence instruction is used to enforce device I/O and memory
> > > ordering
> > > constraints in RISC-V. It does not directly affect the data cache
> > > and particular
> > > cannot be used to flush or invalidate it. RISC-V does not have
> > > instructions for
> > > explicit cache control. Remove the flush_dcache_all
> > > implementation and its use
> > > in all dcache-specific functions in lib/cache.c.
> > >
>
> The privileged mention that fence is for the purposes of ordering,
> but
> does not say
> it can not be used to flush or invalidate.
>
> Andes's ax25 have no coherence agent. So it need fence instruction to
> manipulate
> cache flush or invalidate. Or there will be some data synchronization
> error
> occurs on ae350 platform.
>
I was not aware of this. Does the ax25 flush the whole dcache on any
fence instruction?
You are right, we can't remove it in this case. Since it is specific to
the ax25, should I move it into cpu/ax25/cache.c instead?
Thanks,
Lukas
> Thanks
> Rick
>
>
> > > This also adds a missing new line between flush_dcache_all and
> > > flush_dcache_range in lib/cache.c.
> > >
> > > Signed-off-by: Lukas Auer
> > > ---
> > > This patch only removes the implementation itself and its use in
> > > dcache-specific
> > > functions in lib/cache.c. There are more uses of it in
> > > arch/riscv/, which this patch
> > > does not remove.
> > >
> > > arch/riscv/lib/cache.c | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c
> > > index
> > > ae5c60716f..203e287612 100644
> > > --- a/arch/riscv/lib/cache.c
> > > +++ b/arch/riscv/lib/cache.c
> > > @@ -13,11 +13,10 @@ void invalidate_icache_all(void)
> > >
> > > void flush_dcache_all(void)
> > > {
> > > - asm volatile ("fence" :::"memory");
> > > }
> > > +
> > > void flush_dcache_range(unsigned long start, unsigned long
> > > end) {
> > > - flush_dcache_all();
> > > }
> > >
> > > void invalidate_icache_range(unsigned long start, unsigned long
> > > end) @@ -31,7
> > > +30,6 @@ void invalidate_icache_range(unsigned long start,
> > > unsigned long end)
> > >
> > > void invalidate_dcache_range(unsigned long start, unsigned long
> > > end) {
> > > - flush_dcache_all();
> > > }
> > >
> > > void cache_flush(void)
> > > --
> > > 2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms
On Wed, 2 Jan 2019 11:38:47 +0100
Jean-Jacques Hiblot wrote:
> On 29/12/2018 19:49, Jagan Teki wrote:
> > On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki
> > wrote:
> >> On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot
> >> wrote: Better to have proper commit head that
> >> tells the real issue.
>
> I found it hard to come up with a short description of the real issue.
>
> At least this title makes it clear that it is a regression fix, not a
> new feature.
>
> The details of the failures are in the commit log (or so I thought)
>
> >>
> >>> Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for
> >>> USB gadget devices")
> >>>
> >>> The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be
> >>> declared even for platforms that do not enable DM_USB_GADGET.
> >>> Otherwise the driver for their usb peripheral controller fails to
> >>> bind.
> >> Sorry this is unclear, you are trying to skip DM_USB_GADGET code
> >> even though UCLASS_USB_GADGET_GENERIC id used. does it make
> >> sense?
>
> Sorry for the delay. This was indeed a vacation time.
>
> This patch does not skip DM_USB_GADGET. What it does is declare the
> UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not
> set.
>
> DM_USB_GADGET is a new option and not (yet) widely used and some
> drivers have their own version of the DM support for gadget drivers
> (ie they implement their own version of usb_gadget_initialize(),
> usb_gadget_release() and usb_gadget_handle_interrupts()). However all
> those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus
> the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In
> the past they used UCLASS_USB_DEV_GENERIC, but this option is
> intended for the host side.
>
Thanks for a detailed explanation. Would you prepare v2 soon?
>
> JJ
>
> > Any response on this?
> >
> > We need the fix asap since the release is about a week.
> >
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpxWGW5W_MNZ.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 0/5] imx8: several fixes
Ping. Thanks, Peng. > -Original Message- > From: Peng Fan [mailto:peng@nxp.com] > Sent: 2018年12月15日 20:20 > To: sba...@denx.de > Cc: Fabio Estevam ; u-boot@lists.denx.de; > dl-uboot-imx ; Peng Fan > Subject: [PATCH 0/5] imx8: several fixes > > Several fixes when moving to support SPL. > > Peng Fan (5): > clk: imx8: fix build warning > misc: imx: scu: avoid write null pointer > misc: imx8: scu: use platdata instead of priv data > imx8: cpu: correct info > tools: imx8image: set dcd_skip to true > > arch/arm/mach-imx/imx8/cpu.c | 2 +- > drivers/clk/imx/clk-imx8.c | 2 ++ > drivers/misc/imx8/scu.c | 26 +- > drivers/misc/imx8/scu_api.c | 4 ++-- > tools/imx8image.c| 2 +- > 5 files changed, 19 insertions(+), 17 deletions(-) > > -- > 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] cmd: usb: display bus number
If multiple USB buses exist, the output of the commands 'usb tree' and 'usb
info' is confusing because it is not clear where the output for a new bus
starts.
Print an additional line for each bus indicating the bus number, e.g.
=> usb tree
USB device tree:
USB bus 0
1 Hub (5 Gb/s, 0mA)
U-Boot XHCI Host Controller
USB bus 1
1 Hub (5 Gb/s, 0mA)
U-Boot XHCI Host Controller
Signed-off-by: Heinrich Schuchardt
---
cmd/usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/usb.c b/cmd/usb.c
index 0ccb1b5148..6da945c376 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -470,6 +470,7 @@ static void usb_for_each_root_dev(usb_dev_func_t func)
if (!device_active(bus))
continue;
+ printf("USB bus %d\n", bus->seq);
device_find_first_child(bus, &dev);
if (dev && device_active(dev)) {
udev = dev_get_parent_priv(dev);
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] cmd: usb: display bus number
If multiple USB buses exist, the output of the commands 'usb tree' and 'usb
info' is confusing because it is not clear where the output for a new bus
starts.
Print an additional line for each bus indicating the bus number, e.g.
=> usb tree
USB device tree:
USB bus 0
1 Hub (5 Gb/s, 0mA)
U-Boot XHCI Host Controller
USB bus 1
1 Hub (5 Gb/s, 0mA)
U-Boot XHCI Host Controller
Signed-off-by: Heinrich Schuchardt
---
cmd/usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/usb.c b/cmd/usb.c
index 0ccb1b5148..6da945c376 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -470,6 +470,7 @@ static void usb_for_each_root_dev(usb_dev_func_t func)
if (!device_active(bus))
continue;
+ printf("USB bus %d\n", bus->seq);
device_find_first_child(bus, &dev);
if (dev && device_active(dev)) {
udev = dev_get_parent_priv(dev);
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] ddr: vybrid: Support for vf610 built-in DDR3 memory calibration
Hi Fabio, Stefano, > This patch series provides code to perform read leveling - RDLVL, > which is adjusting the DQS strobe in relation to the DQ signals so > that the strobe edge is centered in the window of valid read data. > > The code is based on Vybrid's Reference Manual's: > "VFxxx Controller Reference Manual, Rev. 0, 10/2016", page 1600, > 10.1.6.16.4.1 "Software Read Leveling in MC Evaluation Mode" > > and uses clarification provided by following NXP's community thread: > "Vybrid: About DDR leveling feature on DDRMC." > https://community.nxp.com/thread/395323 > > It depends on a BITMAP rework patch: > usb: composite: Move bitmap related operations > to ./include/linux/bitmap.h http://patchwork.ozlabs.org/patch/1006448/ > The above patch has found its way to main line, so there is no obstacles to pull this code. Moreover, some Stefan's patches: [U-Boot,v1,0/4] ddr: vybrid: various fixes http://patchwork.ozlabs.org/cover/1007547/ Are also related to DDR_MC setup on Vybrid and fix/cleanup some issues. > > Changes in v2: > - CR93_SWLVL_EXIT -> CR94_SWLVL_EXIT (EXIT is in CR94) > - Add more defines to imx-regs.h (moved from *-calibration.h) > - CR93_SWLVL_EXIT -> CR94_SWLVL_EXIT (EXIT is in CR94) > - Update Kconfig information regarding DDRMC_VF610_CALIBRATION > - Update ddrmc-vf610-calibration. comment > - Update code after extending imx-regs.h > - Remove not needed #ifdef > > Lukasz Majewski (3): > ddr: vybrid: Add DDRMC calibration related registers (DQS to DQ) > ddr: vybrid: Provide code to perform on-boot calibration > ddr: vybrid: Add calibration code to memory controler's (DDRMC) > setup code > > arch/arm/include/asm/arch-vf610/imx-regs.h | 14 +- > arch/arm/mach-imx/Kconfig | 12 + > arch/arm/mach-imx/Makefile | 1 + > arch/arm/mach-imx/ddrmc-vf610-calibration.c | 342 > > arch/arm/mach-imx/ddrmc-vf610-calibration.h | 45 > arch/arm/mach-imx/ddrmc-vf610.c | 5 + 6 files changed, > 418 insertions(+), 1 deletion(-) create mode 100644 > arch/arm/mach-imx/ddrmc-vf610-calibration.c create mode 100644 > arch/arm/mach-imx/ddrmc-vf610-calibration.h > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgppf0OdNjNTd.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
