[PATCH v2 13/19] i2c: Add enums for i2c speed and address size
Some drivers define their own speed enums and use their own constants for
speed. It makes sense to have a unified defition of the different speeds.
Since many controllers have to do different things for fast/high speed, it
is a good idea to have an enum for the mode.
Add these as well as an enum for the address mode.
Signed-off-by: Simon Glass
---
Changes in v2: None
include/i2c.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/include/i2c.h b/include/i2c.h
index 72e2e8e426..0faf8542e2 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -30,6 +30,32 @@ enum dm_i2c_chip_flags {
DM_I2C_CHIP_WR_ADDRESS = 1 << 2, /* Send address for each write byte */
};
+/** enum i2c_speed_mode - standard I2C speed modes */
+enum i2c_speed_mode {
+ IC_SPEED_MODE_STANDARD,
+ IC_SPEED_MODE_FAST,
+ IC_SPEED_MODE_FAST_PLUS,
+ IC_SPEED_MODE_HIGH,
+ IC_SPEED_MODE_FAST_ULTRA,
+
+ IC_SPEED_MODE_COUNT,
+};
+
+/** enum i2c_speed_rate - standard I2C speeds in Hz */
+enum i2c_speed_rate {
+ I2C_SPEED_STANDARD_RATE = 10,
+ I2C_SPEED_FAST_RATE = 40,
+ I2C_SPEED_FAST_PLUS_RATE= 100,
+ I2C_SPEED_HIGH_RATE = 340,
+ I2C_SPEED_FAST_ULTRA_RATE = 500,
+};
+
+/** enum i2c_address_mode - available address modes */
+enum i2c_address_mode {
+ I2C_MODE_7_BIT,
+ I2C_MODE_10_BIT
+};
+
struct udevice;
/**
* struct dm_i2c_chip - information about an i2c chip
--
2.24.1.735.g03f4e72817-goog
[PATCH] net: phy: Fix overlong PHY timeout
Commit 27c3f70f3b50 ("net: phy: Increase link up delay in
genphy_update_link()") increased the per-iteration waiting time from
1ms to 50ms, without adjusting the timeout counter. This lead to the
timeout increasing from the typical 4 seconds to over three minutes.
Adjust the timeout counter evaluation by that factor of 50 to bring the
timeout back to the intended value.
Signed-off-by: Andre Przywara
---
drivers/net/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 80a7664e49..5cf9c165b6 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -244,7 +244,7 @@ int genphy_update_link(struct phy_device *phydev)
/*
* Timeout reached ?
*/
- if (i > PHY_ANEG_TIMEOUT) {
+ if (i > (PHY_ANEG_TIMEOUT / 50)) {
printf(" TIMEOUT !\n");
phydev->link = 0;
return -ETIMEDOUT;
--
2.14.5
[PATCH] lx2160aqds: Fix the the issue that dspi not work in kernel
The DSPI node of DTS in kernel is spi, so fix the "/soc/dspi@"
ot "/soc/spi@".
The DSPI2 and I2C5 is muxed, and the DSPI2 default status is okay,
so must set the DSPI2 status is disabled if the pin use to I2C5.
Signed-off-by: Xiaowei Bao
---
board/freescale/lx2160a/lx2160a.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index eff5d9f..3d7cd8b 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -210,9 +210,9 @@ void esdhc_dspi_status_fixup(void *blob)
{
const char esdhc0_path[] = "/soc/esdhc@214";
const char esdhc1_path[] = "/soc/esdhc@215";
- const char dspi0_path[] = "/soc/dspi@210";
- const char dspi1_path[] = "/soc/dspi@211";
- const char dspi2_path[] = "/soc/dspi@212";
+ const char dspi0_path[] = "/soc/spi@210";
+ const char dspi1_path[] = "/soc/spi@211";
+ const char dspi2_path[] = "/soc/spi@212";
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
u32 sdhc1_base_pmux;
@@ -262,10 +262,12 @@ void esdhc_dspi_status_fixup(void *blob)
& FSL_CHASSIS3_IIC5_PMUX_MASK;
iic5_pmux >>= FSL_CHASSIS3_IIC5_PMUX_SHIFT;
- if (iic5_pmux == IIC5_PMUX_SPI3) {
+ if (iic5_pmux == IIC5_PMUX_SPI3)
do_fixup_by_path(blob, dspi2_path, "status", "okay",
sizeof("okay"), 1);
- }
+ else
+ do_fixup_by_path(blob, dspi2_path, "status", "disabled",
+sizeof("disabled"), 1);
}
#endif
--
2.9.5
[PATCH v2 07/19] i2c: designware_i2c: Bring in the binding file
Bring in this file from Linux v5.4.
Signed-off-by: Simon Glass
---
Changes in v2: None
.../i2c/i2c-designware.txt| 73 +++
1 file changed, 73 insertions(+)
create mode 100644 doc/device-tree-bindings/i2c/i2c-designware.txt
diff --git a/doc/device-tree-bindings/i2c/i2c-designware.txt
b/doc/device-tree-bindings/i2c/i2c-designware.txt
new file mode 100644
index 00..be766be812
--- /dev/null
+++ b/doc/device-tree-bindings/i2c/i2c-designware.txt
@@ -0,0 +1,73 @@
+* Synopsys DesignWare I2C
+
+Required properties :
+
+ - compatible : should be "snps,designware-i2c"
+or "mscc,ocelot-i2c" with "snps,designware-i2c" for fallback
+ - reg : Offset and length of the register set for the device
+ - interrupts : where IRQ is the interrupt number.
+ - clocks : phandles for the clocks, see the description of clock-names below.
+ The phandle for the "ic_clk" clock is required. The phandle for the "pclk"
+ clock is optional. If a single clock is specified but no clock-name, it is
+ the "ic_clk" clock. If both clocks are listed, the "ic_clk" must be first.
+
+Recommended properties :
+
+ - clock-frequency : desired I2C bus clock frequency in Hz.
+
+Optional properties :
+
+ - clock-names : Contains the names of the clocks:
+"ic_clk", for the core clock used to generate the external I2C clock.
+"pclk", the interface clock, required for register access.
+
+ - reg : for "mscc,ocelot-i2c", a second register set to configure the SDA hold
+ time, named ICPU_CFG:TWI_DELAY in the datasheet.
+
+ - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds.
+ This option is only supported in hardware blocks version 1.11a or newer and
+ on Microsemi SoCs ("mscc,ocelot-i2c" compatible).
+
+ - i2c-scl-falling-time-ns : should contain the SCL falling time in
nanoseconds.
+ This value which is by default 300ns is used to compute the tLOW period.
+
+ - i2c-sda-falling-time-ns : should contain the SDA falling time in
nanoseconds.
+ This value which is by default 300ns is used to compute the tHIGH period.
+
+Examples :
+
+ i2c@f {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,designware-i2c";
+ reg = <0xf 0x1000>;
+ interrupts = <11>;
+ clock-frequency = <40>;
+ };
+
+ i2c@112 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,designware-i2c";
+ reg = <0x112 0x1000>;
+ interrupt-parent = <&ictl>;
+ interrupts = <12 1>;
+ clock-frequency = <40>;
+ i2c-sda-hold-time-ns = <300>;
+ i2c-sda-falling-time-ns = <300>;
+ i2c-scl-falling-time-ns = <300>;
+ };x
+
+ i2c@112 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2000 0x100>;
+ clock-frequency = <40>;
+ clocks = <&i2cclk>;
+ interrupts = <0>;
+
+ eeprom@64 {
+ compatible = "linux,slave-24c02";
+ reg = <0x4064>;
+ };
+ };
--
2.24.1.735.g03f4e72817-goog
Re: [PATCH v2 1/1] travis-ci: provide env__efi_fit_tftp_file
On 12/31/19 3:42 AM, Cristian Ciocaltea wrote:
On Mon, Dec 30, 2019 at 09:03:38PM +0100, Heinrich Schuchardt wrote:
On 12/30/19 8:32 PM, Stephen Warren wrote:
On 12/30/19 12:05 PM, Heinrich Schuchardt wrote:
On 12/30/19 5:38 PM, Stephen Warren wrote:
On 12/30/19 3:52 AM, Heinrich Schuchardt wrote:
Provide dictionary env__efi_fit_tftp_file describing the file used for
the
UEFI FIT image test.
diff --git a/py/travis-ci/travis_tftp.py b/py/travis-ci/travis_tftp.py
+def efifit2env(addr=None):
+ """Create dictionary describing file for EFI fit image test
+
+ @addr: address used for loading the file as int (e.g.
0x4040)
+ Return: dictionary describing the file with entries
+ * fn - filename
+ * addr - loading address, optional
+ * dn - tftp directory
+ """
+ tftp_dir = os.environ['UBOOT_TRAVIS_BUILD_DIR']
+
+ ret = {
+ "fn": "test-efi-fit.img",
If this function were to exist, then the filename shouldn't be
hard-coded; it should be a parameter.
Hello Stephen,
thanks for reviewing.
This is the name of a generated file. It does not depend on the board.
What generates the file and when/why?
Generated files should generally be put into
u_boot_console.config.persistent_data_dir, and presumably the name
hard-coded into the test that uses it.
Hello Stephen,
this is the test case:
https://lists.denx.de/pipermail/u-boot/2019-December/394957.html
test/py: Create a test for launching UEFI binaries from FIT images
The test can be run in different styles:
* A complete FIT image can be supplied. In this case the dictionary
must contain a "size" entry.
* The test can generate a FIT image from lib/efi_loader/helloworld.efi.
In this case no "size" entry shall be supplied. The "fn" field
provides the name of the generated file. The file is generated in
cons.config.build_dir. The "dn" field" describes the tFTP root
directory to which the generated file is copied.
A small correction here: if the "size" entry is not provided in the
dictionary, the test generates a FIT image using a hardcoded file
name (test-efi-fit-helloworld.fit), so any "fn" entry provided in the
dictionary is ignored in this case.
Why does the size parameter affect whether the file name parameter is
used? This test sounds like it's doing very odd things with configuration...
I'd propose removing the size and filename parameters completely, and
instead just telling the test where the TFTP directory is. Then, we
don't need any common function at all.
Also, if we do keep a function, then "efifit2env" is a really bad name;
this function is just generating some configuration data, not converting
anything, hence "2" or "to" in the function name doesn't make sense.
[PATCH v2 06/19] i2c: designware_i2c: Use an accurate bus clock instead of MHz
At present the driver uses an approximation for the bus clock, e.g. 166MHz
instead of 166 2/3 MHz.
This can result in small errors in the resulting I2C speed, perhaps 0.5%
or so.
Adjust the existing code to start from the accurate figure, even if later
rounding reduces this accuracy.
Update the bus speed code to work in KHz instead of MHz, which removes
most of the error.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/designware_i2c.c | 18 --
drivers/i2c/designware_i2c.h | 4 ++--
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 2416ef32f9..0a1df8015f 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -55,8 +55,9 @@ static int dw_i2c_enable(struct i2c_regs *i2c_base, bool
enable)
static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs *i2c_base,
struct dw_scl_sda_cfg *scl_sda_cfg,
unsigned int speed,
- unsigned int bus_mhz)
+ unsigned int bus_clk)
{
+ ulong bus_khz = bus_clk / 1000;
enum i2c_speed_mode i2c_spd;
unsigned int cntl;
unsigned int hcnt, lcnt;
@@ -86,8 +87,8 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs
*i2c_base,
hcnt = scl_sda_cfg->fs_hcnt;
lcnt = scl_sda_cfg->fs_lcnt;
} else {
- hcnt = (bus_mhz * MIN_HS_SCL_HIGHTIME) / NANO_TO_MICRO;
- lcnt = (bus_mhz * MIN_HS_SCL_LOWTIME) / NANO_TO_MICRO;
+ hcnt = (bus_khz * MIN_HS_SCL_HIGHTIME) / NANO_TO_KILO;
+ lcnt = (bus_khz * MIN_HS_SCL_LOWTIME) / NANO_TO_KILO;
}
writel(hcnt, &i2c_base->ic_hs_scl_hcnt);
writel(lcnt, &i2c_base->ic_hs_scl_lcnt);
@@ -99,8 +100,8 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs
*i2c_base,
hcnt = scl_sda_cfg->ss_hcnt;
lcnt = scl_sda_cfg->ss_lcnt;
} else {
- hcnt = (bus_mhz * MIN_SS_SCL_HIGHTIME) / NANO_TO_MICRO;
- lcnt = (bus_mhz * MIN_SS_SCL_LOWTIME) / NANO_TO_MICRO;
+ hcnt = (bus_khz * MIN_SS_SCL_HIGHTIME) / NANO_TO_KILO;
+ lcnt = (bus_khz * MIN_SS_SCL_LOWTIME) / NANO_TO_KILO;
}
writel(hcnt, &i2c_base->ic_ss_scl_hcnt);
writel(lcnt, &i2c_base->ic_ss_scl_lcnt);
@@ -113,8 +114,8 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs
*i2c_base,
hcnt = scl_sda_cfg->fs_hcnt;
lcnt = scl_sda_cfg->fs_lcnt;
} else {
- hcnt = (bus_mhz * MIN_FS_SCL_HIGHTIME) / NANO_TO_MICRO;
- lcnt = (bus_mhz * MIN_FS_SCL_LOWTIME) / NANO_TO_MICRO;
+ hcnt = (bus_khz * MIN_FS_SCL_HIGHTIME) / NANO_TO_KILO;
+ lcnt = (bus_khz * MIN_FS_SCL_LOWTIME) / NANO_TO_KILO;
}
writel(hcnt, &i2c_base->ic_fs_scl_hcnt);
writel(lcnt, &i2c_base->ic_fs_scl_lcnt);
@@ -511,9 +512,6 @@ static int designware_i2c_set_bus_speed(struct udevice
*bus, unsigned int speed)
rate = clk_get_rate(&i2c->clk);
if (IS_ERR_VALUE(rate))
return -EINVAL;
-
- /* Convert to MHz */
- rate /= 100;
#else
rate = IC_CLK;
#endif
diff --git a/drivers/i2c/designware_i2c.h b/drivers/i2c/designware_i2c.h
index 06d794ca64..1f9940c2ba 100644
--- a/drivers/i2c/designware_i2c.h
+++ b/drivers/i2c/designware_i2c.h
@@ -59,8 +59,8 @@ struct i2c_regs {
u32 comp_type;
};
-#define IC_CLK 166
-#define NANO_TO_MICRO 1000
+#define IC_CLK 1
+#define NANO_TO_KILO 100
/* High and low times in different speed modes (in ns) */
#define MIN_SS_SCL_HIGHTIME4000
--
2.24.1.735.g03f4e72817-goog
Re: [PATCH 1/5] video: x86: Enable 32-bit graphics by default
Hi Anatolij, On Thu, 2 Jan 2020 at 07:34, Anatolij Gustschin wrote: > > Hi Simon, > > On Fri, 20 Dec 2019 18:10:33 -0700 > Simon Glass s...@chromium.org wrote: > > > Most x86 boards that use video make use of 32bpp graphics. Enable this by > > default. This fixes missing graphics output on some x86 boards. > > Must this patch be applied for v2010.01 release? I think so since these boards don't work for me at present. What do you think, Bin? Regards, SImon
Facilities for successful boot detection
I would like to implement an update system (most likely using SWUpdate) "Double copy with fall-back" and, possibly a "last resort" recovery. I have pretty clear what should be the program flow, but I don't know how to implement it in U-Boot. In particular: * How can I determine, in U-Boot, if previous boot was successful? * Is there a established "best practice" for this? * I would like to avoid rewriting Environment at each reboot (it can happen /many/ times/day and that would kill SPI NOR). * In U-Boot there's a BootCounter, but Ive been unable to understand if/how it works and I strongly doubt it will be useful because it stores the counter itself in a uController register that is cleared on hard reset (and, of course, at power-up). Since my only way to "recover" from a failed boot may well be power-cycle I suspect this method is scarcely usable (but I might have missed something). * OTOH, as said, rewriting Environment (currently in SPI NOR) at each boot doesn't seem advisable. What I am aiming at (but I'm ready to change, if there's a better way) is: * my board (VoCore2 SoM) has: o 128MiB RAM o 16MiB SPI NOR (MTD) o 8GiB SD card (MMC) * On SD I should have: o One FAT-formatted partition containing two kernel images. o Two ext4 partitions containing RootFS (one for each kernel image). o Two ext4 partitions for Application (to be mounted on /usr/local, if it matters). * On MTD1 I should have U-Boot. * MTD2 and MTD3 should contain a "recovery copy" of kernel and RootFS (no Application). * U-Boot should have a notion of "current" and "known good" system and should try booting "current" a few times; if it fails it should try "known good"; if it still fails (e.g.: SD is completely broken) it should boot from "recovery" on SPI NOR. I've seen some `configs` (most notably theadorable-x86) seem to implement something like this, but, sincerely, I've been unable to divine what they're actually doing. If someone could be so kind to point me in the right direction... ;) Thanks in Advance Mauro
Re: [PATCH 1/5] video: x86: Enable 32-bit graphics by default
Hi Simon, On Fri, Jan 3, 2020 at 11:24 AM Simon Glass wrote: > > Hi Bin, > > On Thu, 2 Jan 2020 at 19:41, Bin Meng wrote: > > > > Hi Simon, > > > > On Fri, Jan 3, 2020 at 10:30 AM Simon Glass wrote: > > > > > > Hi Anatolij, > > > > > > On Thu, 2 Jan 2020 at 07:34, Anatolij Gustschin wrote: > > > > > > > > Hi Simon, > > > > > > > > On Fri, 20 Dec 2019 18:10:33 -0700 > > > > Simon Glass s...@chromium.org wrote: > > > > > > > > > Most x86 boards that use video make use of 32bpp graphics. Enable > > > > > this by > > > > > default. This fixes missing graphics output on some x86 boards. > > > > > > > > Must this patch be applied for v2010.01 release? > > > > > > I think so since these boards don't work for me at present. > > > > > > What do you think, Bin? > > > > > > > Which board is currently broken due to missing this config? Should it > > be safer to move this to board defconfig? > > I think any x86 board with graphics would need this. Those that don't > enable VIDEO won't get the change anyway. OK, thanks. I had a test with QEMU x86 and looks good. Reviewed-by: Bin Meng Tested-by: Bin Meng Regards, Bin
Re: [PATCH 2/3] riscv: Add FU540 specific includes
Hi Pragnesh, On Tue, Dec 31, 2019 at 10:00 PM Pragnesh Patel wrote: > > Added headers needed by upcoming SPL support of FU540. > > This headers are leveraged from FSBL > (https://github.com/sifive/freedom-u540-c000-bootloader.git) > > Signed-off-by: Pragnesh Patel > --- > arch/riscv/include/asm/arch-fu540/cache.h | 43 > arch/riscv/include/asm/arch-fu540/clint.h | 20 ++ > arch/riscv/include/asm/arch-fu540/i2c.h | 48 + > arch/riscv/include/asm/arch-fu540/otp.h | 80 + > arch/riscv/include/asm/arch-fu540/spi.h | 86 +++ > arch/riscv/include/asm/arch-fu540/uart.h | 35 + > 6 files changed, 312 insertions(+) > create mode 100644 arch/riscv/include/asm/arch-fu540/cache.h > create mode 100644 arch/riscv/include/asm/arch-fu540/clint.h > create mode 100644 arch/riscv/include/asm/arch-fu540/i2c.h > create mode 100644 arch/riscv/include/asm/arch-fu540/otp.h > create mode 100644 arch/riscv/include/asm/arch-fu540/spi.h > create mode 100644 arch/riscv/include/asm/arch-fu540/uart.h > > diff --git a/arch/riscv/include/asm/arch-fu540/cache.h > b/arch/riscv/include/asm/arch-fu540/cache.h > new file mode 100644 > index 00..9043779650 > --- /dev/null > +++ b/arch/riscv/include/asm/arch-fu540/cache.h > @@ -0,0 +1,43 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright (C) 2019 SiFive, Inc. > + * > + * Authors: > + * Pragnesh Patel > + * Troy Benjegerdes > + */ > + > +#ifndef _CACHE_FU540_H > +#define _CACHE_FU540_H > + > +/* Register offsets */ > +#define CCACHE_INFO 0x000 > +#define CCACHE_ENABLE 0x008 > +#define CCACHE_INJECT 0x040 > +#define CCACHE_META_FIX 0x100 > +#define CCACHE_DATA_FIX 0x140 > +#define CCACHE_DATA_FAIL0x160 > +#define CCACHE_FLUSH64 0x200 > +#define CCACHE_FLUSH32 0x240 > +#define CCACHE_WAYS 0x800 > + > +/* Bytes inside the INFO field */ > +#define CCACHE_INFO_BANKS 0 > +#define CCACHE_INFO_WAYS1 > +#define CCACHE_INFO_LG_SETS 2 > +#define CCACHE_INFO_LG_BLOCKBYTES 3 > + > +/* INJECT types */ > +#define CCACHE_ECC_TOGGLE_DATA 0x0 > +#define CCACHE_ECC_TOGGLE_META 0x1 > + > +/* Offsets per FIX/FAIL */ > +#define CCACHE_ECC_ADDR 0x0 > +#define CCACHE_ECC_COUNT0x8 > + > +/* Interrupt Number offsets from Base */ > +#define CCACHE_INT_META_FIX 0 > +#define CCACHE_INT_DATA_FIX 1 > +#define CCACHE_INT_DATA_FAIL2 > + > +#endif /* _CACHE_FU540_H */ > diff --git a/arch/riscv/include/asm/arch-fu540/clint.h > b/arch/riscv/include/asm/arch-fu540/clint.h > new file mode 100644 > index 00..f740f30f2d > --- /dev/null > +++ b/arch/riscv/include/asm/arch-fu540/clint.h > @@ -0,0 +1,20 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright (C) 2019 SiFive, Inc. > + * > + * Authors: > + * Pragnesh Patel > + * Troy Benjegerdes > + */ > + > +#ifndef _CLINT_FU540_H > +#define _CLINT_FU540_H > + > +#define CLINT_MSIP 0x > +#define CLINT_MSIP_size 0x4 > +#define CLINT_MTIMECMP 0x4000 > +#define CLINT_MTIMECMP_size 0x8 > +#define CLINT_MTIME 0xBFF8 > +#define CLINT_MTIME_size 0x8 > + nits: please have the value indented > +#endif /* _CLINT_FU540_H */ > diff --git a/arch/riscv/include/asm/arch-fu540/i2c.h > b/arch/riscv/include/asm/arch-fu540/i2c.h > new file mode 100644 > index 00..66cc3edd94 > --- /dev/null > +++ b/arch/riscv/include/asm/arch-fu540/i2c.h > @@ -0,0 +1,48 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright (C) 2019 SiFive, Inc. > + * > + * Authors: > + * Pragnesh Patel > + * Troy Benjegerdes > + */ > + > +#ifndef _I2C_FU540_H > +#define _I2C_FU540_H > + > +// CHECK: word vs byte alignment > +// OC I2C Linux driver defines registers w/o alignment: > +// > http://lxr.free-electrons.com/source/drivers/i2c/busses/i2c-ocores.c?v=4.6#L46 > +// > +// However, register accessor functions use reg_shift value > +// > http://lxr.free-electrons.com/source/drivers/i2c/busses/i2c-ocores.c?v=4.6#L80 > +// which is platform specific: > +// > http://lxr.free-electrons.com/source/drivers/i2c/busses/i2c-ocores.c?v=4.6#L346 nits: please use /* */ for the comment format > + > +#define I2C_PRESCALER_LO (0x00) > +#define I2C_PRESCALER_HI (0x04) > +#define I2C_CONTROL (0x08) > +#define I2C_DATA (0x0C) > +#define I2C_CMD (0x10) /* write only */ > +#define I2C_STATUS(0x10) /* read only, same address as I2C_CMD */ > + > +// I2C_CONTROL register > +#define I2C_CONTROL_CORE_EN(x) (((x) & 0x1) << 7) > +#define I2C_CONTROL_INT_EN(x) (((x) & 0x1) << 6) > + > +// I2C_CMD register > +#define I2C_CMD_START(x) (((x) & 0x1) << 7) > +#define I2C_CMD_STOP(x) (((x) & 0x1) << 6) > +#define I2C_CMD_READ(x) (((x) & 0x1) << 5) > +#define I2C_CMD_WRITE(x) (((x) & 0x1) << 4) > +#define I2C_CMD_NACK(x) (((x) & 0x1) << 3) > +#define I2C_CMD_IRQ_ACK(x)
SPI NOR stops working if I put Env in MMC
Hi, I'm facing a strange problem that took quite a while to analyze. I'm porting U-Boot to a new board and thus some problem is expected. I am also trying to configure U-Boot in a useful (for my purposes) way. I decided to switch Environment storage from SPI NOR to SD card (in a file in FAT partition. Before switch I had both SPI NOR (MTD) and MMC working. > U-Boot 2020.01-rc5-00074-g57fe7de5a3-dirty (Jan 04 2020 - 01:38:21 +0100) > > CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) > Model: VoCore2 > DRAM: 128 MiB > MMC: mmc@1013: 0 > Loading Environment from SPI Flash... SF: Detected gd25q128 with page > size 256 Bytes, erase size 4 KiB, total 16 MiB > OK > In: uart2@e00 > Out: uart2@e00 > Err: uart2@e00 > Model: VoCore2 > => mtd list > List of MTD devices: > * nor0 > - type: NOR flash > - block size: 0x1000 bytes > - min I/O: 0x1 bytes > - 0x-0x0100 : "nor0" > - 0x-0x0005 : "u-boot" > - 0x0005-0x0030 : "kernel" > - 0x0030-0x00ffe000 : "squash" > - 0x00ffe000-0x00fff000 : "env" > - 0x00fff000-0x0100 : "factory" > => mmc part > > Partition Map for MMC device 0 -- Partition Type: DOS > > Part Start Sector Num Sectors UUID Type > 1 2048 262144 f31c8249-01 0c > 2 264192 4194304 f31c8249-02 83 > 3 4458496 327680 f31c8249-03 83 > 4 4786176 10737664 f31c8249-04 05 Extd > 5 4788224 2097152 f31c8249-05 83 > 6 6887424 2097152 f31c8249-06 83 > => I made a minimal change in configuration: > mcon@cinderella:/tmp/u-boot$ git diff > diff --git a/configs/vocore_vocore2_defconfig > b/configs/vocore_vocore2_defconfig > index ad1b580431..ece98beea0 100644 > --- a/configs/vocore_vocore2_defconfig > +++ b/configs/vocore_vocore2_defconfig > @@ -1,8 +1,6 @@ > CONFIG_MIPS=y > CONFIG_SYS_TEXT_BASE=0x8001 > CONFIG_ENV_SIZE=0x1000 > -CONFIG_ENV_OFFSET=0x00FFE000 > -CONFIG_ENV_SECT_SIZE=0x1000 > CONFIG_ARCH_MTMIPS=y > CONFIG_BOARD_VOCORE2=y > CONFIG_MIPS_BOOT_FDT=y > @@ -37,8 +35,9 @@ CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" > > CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)" > # CONFIG_ISO_PARTITION is not set > CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2" > -CONFIG_ENV_IS_IN_SPI_FLASH=y > -CONFIG_ENV_ADDR=0x00FFE000 > +CONFIG_ENV_IS_IN_FAT=y > +CONFIG_ENV_FAT_INTERFACE="mmc" > +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" > # CONFIG_NET is not set > # CONFIG_DM_DEVICE_REMOVE is not set > CONFIG_BLK=y > mcon@cinderella:/tmp/u-boot$ ... but it seems very destructive for spi: > U-Boot 2020.01-rc5-00074-g0cac9383d7-dirty (Jan 04 2020 - 01:55:34 +0100) > > CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) > Model: VoCore2 > DRAM: 128 MiB > MMC: mmc@1013: 0 > Loading Environment from FAT... OK > In: uart2@e00 > Out: uart2@e00 > Err: uart2@e00 > Model: VoCore2 > => mmc part > > Partition Map for MMC device 0 -- Partition Type: DOS > > Part Start Sector Num Sectors UUID Type > 1 2048 262144 f31c8249-01 0c > 2 264192 4194304 f31c8249-02 83 > 3 4458496 327680 f31c8249-03 83 > 4 4786176 10737664 f31c8249-04 05 Extd > 5 4788224 2097152 f31c8249-05 83 > 6 6887424 2097152 f31c8249-06 83 > => mtd list > Could not find a valid device for spi0.0 > List of MTD devices: > No MTD device found > => I assume some initialization is not done, but I would like some help to debug this as I did *not* change anything in SPI (aside from setting it in .dts). OTOH I had to change a bit MMC handling, but that shouldn't be relevant, or is it? I attach my complete patch against a fairly recent commit (it was "master" a few hours ago). The patch is to the working ENV_IS_IN_SPI_FLASH version. Changes for "not working" with ENV_IS_IN_FAT are above. Please advise. Thanks in Advance Mauro >From 43e2aa1dd77221e10479a4352a50332942beeb38 Mon Sep 17 00:00:00 2001 From: Mauro Condarelli Date: Sat, 4 Jan 2020 00:31:54 +0100 Subject: [PATCH] Port to VoCore2 board. Signed-off-by: Mauro Condarelli --- arch/mips/dts/Makefile | 1 + arch/mips/dts/mt7628a.dtsi | 18 +- arch/mips/dts/vocore_vocore2.dts | 83 arch/mips/mach-mtmips/Kconfig| 9 +++ board/vocore/vocore2/Kconfig | 11 board/vocore/vocore2/Makefile| 2 + board/vocore/vocore2/board.c | 35 configs/vocore_vocore2_defconfig | 70 +++ drivers/clk/Kconfig | 8 +++ drivers/clk/Makefile | 1 + drivers/clk/clk-mtmips-cg.c | 63 + drivers/phy/Kconfig | 2 + include/configs/vocore2.h
Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
Hi Mauro,
On 30.12.19 13:14, Mauro Condarelli wrote:
On 12/30/19 11:22 AM, Daniel Schwierzeck wrote:
Am 30.12.19 um 10:19 schrieb Mauro Condarelli:
I am having problems with this patch.
Problem is "reset"command fails (for my board) with:
=> reset
resetting ...
### ERROR ### Please RESET the board ###
I traced down problem to "drivers/sysreset/sysreset-uclass.c" requesting
"uclass_first_device(UCLASS_SYSRESET, &dev)", while
"drivers/reset/reset-mips.c"
defines:
static const struct udevice_id mtmips_reset_ids[] = {
{ .compatible = "mediatek,mtmips-reset" },
{ }
};
U_BOOT_DRIVER(mtmips_reset) = {
.name = "mtmips-reset",
.id = UCLASS_RESET,
... so UCLASS_SYSRESET list is empty.
What am I doing wrong?
TiA!
Mauro
do you have the according node with compatible string
"mediatek,mtmips-reset" in your device-tree?
Yes, I do, but problem is elsewhere:
"reset" command looks for a UCLASS_SYSRESET while
drivers/reset/reset-mips.c
(implementing "mediatek,mtmips-reset") provides a UCLASS_RESET.
I know too little about u-boot internals to understand which one I
should "fix" (if any).
I just tested current mainline U-Boot (top-of-tree) on the GARDENA
board and the reset works just fine:
=> reset
resetting ...
U-Boot 2020.01-rc5-00042-g6cb87cbb14 (Jan 02 2020 - 13:27:15 +0100)
CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
Model: GARDENA smart Gateway (MT7688)
DRAM: 128 MiB
WDT: Started with servicing (60s timeout)
Loading Environment from SPI Flash... SF: Detected XM25QH64A with page size 256
Bytes, erase size 4 KiB, total 8 MiB
OK
F-Data:factory-data version 1 detected
Net: eth0: eth@1011
Hit any key to stop autoboot: 0
I didn't check the details of this mail thread, so I can't really
comment on this. Your board is so similar to the GARDENA one (LinkIt)
that it should work there as well. Do you gave some differences in
your defconfig?
Thanks,
Stefan
Re: [PATCH] net: phy: Fix overlong PHY timeout
On 03.01.20 23:08, Andre Przywara wrote:
Commit 27c3f70f3b50 ("net: phy: Increase link up delay in
genphy_update_link()") increased the per-iteration waiting time from
1ms to 50ms, without adjusting the timeout counter. This lead to the
timeout increasing from the typical 4 seconds to over three minutes.
Adjust the timeout counter evaluation by that factor of 50 to bring the
timeout back to the intended value.
Signed-off-by: Andre Przywara
---
drivers/net/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 80a7664e49..5cf9c165b6 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -244,7 +244,7 @@ int genphy_update_link(struct phy_device *phydev)
/*
* Timeout reached ?
*/
- if (i > PHY_ANEG_TIMEOUT) {
+ if (i > (PHY_ANEG_TIMEOUT / 50)) {
printf(" TIMEOUT !\n");
phydev->link = 0;
return -ETIMEDOUT;
Andre, thanks for taking care of this.
Reviewed-by: Stefan Roese
Thanks,
Stefan
Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
On 1/2/20 1:30 PM, Stefan Roese wrote:
> Hi Mauro,
>
> On 30.12.19 13:14, Mauro Condarelli wrote:
>>
>>
>> On 12/30/19 11:22 AM, Daniel Schwierzeck wrote:
>>>
>>> Am 30.12.19 um 10:19 schrieb Mauro Condarelli:
I am having problems with this patch.
Problem is "reset"command fails (for my board) with:
> => reset
> resetting ...
> ### ERROR ### Please RESET the board ###
I traced down problem to "drivers/sysreset/sysreset-uclass.c"
requesting
"uclass_first_device(UCLASS_SYSRESET, &dev)", while
"drivers/reset/reset-mips.c"
defines:
> static const struct udevice_id mtmips_reset_ids[] = {
> { .compatible = "mediatek,mtmips-reset" },
> { }
> };
>
> U_BOOT_DRIVER(mtmips_reset) = {
> .name = "mtmips-reset",
> .id = UCLASS_RESET,
... so UCLASS_SYSRESET list is empty.
What am I doing wrong?
TiA!
Mauro
>>> do you have the according node with compatible string
>>> "mediatek,mtmips-reset" in your device-tree?
>> Yes, I do, but problem is elsewhere:
>> "reset" command looks for a UCLASS_SYSRESET while
>> drivers/reset/reset-mips.c
>> (implementing "mediatek,mtmips-reset") provides a UCLASS_RESET.
>>
>> I know too little about u-boot internals to understand which one I
>> should "fix" (if any).
>
> I just tested current mainline U-Boot (top-of-tree) on the GARDENA
> board and the reset works just fine:
>
> => reset
> resetting ...
>
>
> U-Boot 2020.01-rc5-00042-g6cb87cbb14 (Jan 02 2020 - 13:27:15 +0100)
>
> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
> Model: GARDENA smart Gateway (MT7688)
> DRAM: 128 MiB
> WDT: Started with servicing (60s timeout)
> Loading Environment from SPI Flash... SF: Detected XM25QH64A with page
> size 256 Bytes, erase size 4 KiB, total 8 MiB
> OK
> F-Data:factory-data version 1 detected
> Net: eth0: eth@1011
> Hit any key to stop autoboot: 0
>
> I didn't check the details of this mail thread, so I can't really
> comment on this. Your board is so similar to the GARDENA one (LinkIt)
> that it should work there as well. Do you gave some differences in
> your defconfig?
My defconfig looks very different, mainly due to not having (currently)
any network in u-boot, but I have USB strorage.
I attach the whole vocore2_defconfig.
To me it seems the only difference that *might* be relevant is I don't
have CONFIG_SYSRESET_SYSCON=y.
... enable... compile... load... test...
SUCCESS!!
That was it.
I was thinking reset should have been handled by "reset-mtmips.c" but
apparently "mfd syscon reboot driver" is needed.
THANKS.
I'll send another iteration of my patches soon after a bit of testing.
> Thanks,
> Stefan
>
Regards
Mauro
CONFIG_MIPS=y
CONFIG_SYS_TEXT_BASE=0x8001
CONFIG_ENV_SIZE=0x1000
CONFIG_ENV_OFFSET=0x00FFE000
CONFIG_ENV_SECT_SIZE=0x1000
CONFIG_ARCH_MTMIPS=y
CONFIG_BOARD_VOCORE2=y
CONFIG_MIPS_BOOT_FDT=y
CONFIG_ENV_VARS_UBOOT_CONFIG=y
CONFIG_SYS_BOOT_GET_CMDLINE=y
CONFIG_SYS_BOOT_GET_KBD=y
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_USE_BOOTARGS=y
CONFIG_LOGLEVEL=8
CONFIG_VERSION_VARIABLE=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
# CONFIG_AUTOBOOT is not set
# CONFIG_BOOTM_NETBSD is not set
# CONFIG_BOOTM_PLAN9 is not set
# CONFIG_BOOTM_RTEMS is not set
# CONFIG_BOOTM_VXWORKS is not set
# CONFIG_CMD_XIMG is not set
CONFIG_RANDOM_UUID=y
# CONFIG_CMD_LOADB is not set
# CONFIG_CMD_LOADS is not set
CONFIG_CMD_MMC=y
CONFIG_CMD_MTD=y
CONFIG_CMD_PART=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
CONFIG_CMD_FAT=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_CMD_MTDPARTS=y
CONFIG_MTDIDS_DEFAULT="nor0=spi0.0"
CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)"
# CONFIG_ISO_PARTITION is not set
CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2"
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_ENV_ADDR=0x00FFE000
# CONFIG_NET is not set
# CONFIG_DM_DEVICE_REMOVE is not set
# CONFIG_INPUT is not set
CONFIG_LED=y
CONFIG_LED_BLINK=y
CONFIG_LED_GPIO=y
CONFIG_MMC=y
CONFIG_DM_MMC=y
# CONFIG_MMC_HW_PARTITIONING is not set
CONFIG_MMC_MTK=y
CONFIG_MTD=y
CONFIG_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_SPI_FLASH_MTD=y
# CONFIG_DM_ETH is not set
# CONFIG_RAM_ROCKCHIP_DEBUG is not set
CONFIG_SPECIFY_CONSOLE_INDEX=y
CONFIG_CONS_INDEX=3
CONFIG_SPI=y
CONFIG_MT7621_SPI=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_STORAGE=y
CONFIG_LZMA=y
CONFIG_LZO=y
[PATCH v6 0/6] rockchip: Add Binman support
This is v6 set for Binman support in rockchip, [1] here is previous patchset. This series add single boot image with binman for arm32 and pad_cat for arm64 rockchip platforms both TPL + SPL and SPL-alone targets. Changes for v6: - drop idbloader.img filename change patch - update rockchip.rst to include, rockchip TPL, SPI boot as TODO Changes for v5: - collect kever review tag - drop idbloader.img from clean target Changes for v4: - support all rockchip platforms - add new patches for dtsi changes - update documentation - format proper commit message - rebase on master Changes for v3: - rebase on master - add binman for rk3288, rk3328, rk3368, rk3399 - added rst documentation for rockchip Changes for v2: - Add few clean target patches - update bl31.elf env handling code, with logging - support puma itb, via BL31 and PMUM0 env - enable BUILD_TARGET for ROCKCHIP_RK3399 [1] https://patchwork.ozlabs.org/cover/1216263/ Any inputs? Jagan. Jagan Teki (6): Makefile: Add rockchip image type Makefile: rockchip: Suffix platform type with tpl name Makefile: rockchip: Support SPL-alone mkimage arm: dts: rk3036: Add rk3036-u-boot.dtsi rockchip: Add Single boot image (with binman, pad_cat) doc: boards: Add rockchip documentation Makefile| 36 ++-- arch/arm/Kconfig| 1 + arch/arm/dts/rk3036-sdk-u-boot.dtsi | 2 + arch/arm/dts/rk3036-u-boot.dtsi | 6 ++ arch/arm/dts/rk3288-u-boot.dtsi | 2 + arch/arm/dts/rockchip-u-boot.dtsi | 21 + doc/board/rockchip/index.rst| 10 +++ doc/board/rockchip/rockchip.rst | 130 include/configs/rockchip-common.h | 3 + 9 files changed, 206 insertions(+), 5 deletions(-) create mode 100644 arch/arm/dts/rk3036-u-boot.dtsi create mode 100644 arch/arm/dts/rockchip-u-boot.dtsi create mode 100644 doc/board/rockchip/index.rst create mode 100644 doc/board/rockchip/rockchip.rst -- 2.18.0.321.gffc6fa0e3
Re: qemu_arm64_defconfig: PCI autoconfig fails for qemu-system-aarch64 -m 4G
On 1/2/20 12:28 PM, Tuomas Tynkkynen wrote: Hi Heinrich, On Wed, 1 Jan 2020 at 19:58, Heinrich Schuchardt wrote: Dear all, I want to run qemu_arm64_defconfig with 4G. qemu-system-aarch64 -machine virt -m 4G -smp cores=2 \ -bios u-boot.bin -cpu cortex-a53 -nographic -gdb tcp::1234 \ -netdev user,id=eth0,tftp=tftp -device e1000,netdev=eth0 \ -device virtio-rng-pci Out of curiosity, why E1000 over virtio-net? I see an error: ... pci_hose_phys_to_bus: invalid physical address The error does not occur for a smaller RAM size. I added some debug output: _dm_pci_phys_to_bus: phys_addr 0x00013ffecb40, res->phys_start 0x1000, res->bus_start 0x1000 As qemu_arm64_defconfig does not define CONFIG_SYS_PCI_64BIT the calculated bus address is truncated. Makes sense. If CONFIG_SYS_PCI_64BIT is defined for qemu_arm64_defconfig and the memory is less then 4 GiB an error PCI: Failed autoconfig bar 10 occurs. I believe this happens because the handling of the ranges DT property handling (or it could be in the PCI core itself, not sure) is a bit simplistic in U-Boot. The ranges property in QEMU-generated dtb contains two PCI_REGION_MEM ranges, one below 32-bit boundary and one above it. But decode_regions() in U-Boot only supports one range of given type. When CONFIG_SYS_PCI_64BIT is unset, only the region below 32-bit boundary is used, otherwise the one above 32-bits is used. See commit 52ba907328ec069ff1cec6cbe659f1714c68ed33. Thus with CONFIG_SYS_PCI_64BIT set any PCI devices which do not support 64-bit mem BARs stop working. This should happen regardless of the RAM size, right? For 3GiB memory I observed the following values: _dm_pci_phys_to_bus: phys_addr 0xfffecbc0, res->phys_start 0x1000, res->bus_start 0x1000 When I define type pci_addr_t as 64bit everything works correctly. Why does the number of bits in pci_addr_t depend on CONFIG_SYS_PCI_64BIT and not on the bitness of the system? As I understand it, some PCI host controllers may require using 64-bit PCI bus addresses but still be connected to a 32-bit CPU. It is especially worrisome that CONFIG_SYS_PCI_64BIT is not documented at all. I wonder if Kumar remembers why he introduced it in 2008. I tried to change the definition of the following types in pci.h typedef phys_addr_t pci_addr_t; typedef phys_addr_t pci_size_t; This lets qemu-x86_defconfig fail with Error binding driver 'cpu_qemu': -12 Using typedef unsigned long pci_addr_t; typedef unsigned long pci_size_t; does not produce the error but I am not sure if this is the right approach. One solution would be to fix decode_regions() to work with multiple regions of the same type and then enable CONFIG_SYS_PCI_64BIT. I think another solution would be to simply limit U-Boot from being relocated above the 32-bit boundary. IIRC some other 64-bit boards do this as well. In fact, this might be the better solution because some bus mastering PCI devices cannot access memory above 32-bit. As far as I can tell, E1000 is not affected but for example EHCI is. Hello Tuomas, thank you for your analysis. Changing the relocation address has amongst others the following side effects: * reducing the maximum memory for function tracing * reducing the available memory for UEFI Actually I was increasing RAM for QEMU due to working with function tracing. Where in decode_regions() do you see the limitation to work with multiple regions of the same type? Best regards Heinrich
Re: [PATCH v1] colibri_imx7: disable HAB and CAAM support
Hi Igor, On 27/12/19 10:23, Igor Opaniuk wrote: > Hi Breno, > > On Mon, Dec 23, 2019 at 7:07 PM Breno Matheus Lima > wrote: >> >> Hi Igor, >> >> Em qui., 19 de dez. de 2019 às 07:55, Igor Opaniuk >> escreveu: >>> >>> From: Igor Opaniuk >>> >>> Currently Colibri iMX7 NAND version doesn't boot at all with >>> HABv4 support enabled. If CSF section is included in the final >>> imx binary, BootROM every time switches to usb recovery mode. >>> However eMMC version of the same SoM works without any issues. >>> >>> Disable HAB and CAAM support for now until the problem is properly >>> investigated and fixed. >>> >> >> This issue is also happening with i.MX6ULL, seems that padding the >> U-Boot binary to the size defined in boot data is addressing this >> issue. >> >> Please follow example below. >> >> 1. Dump boot data: >> >> $ hexdump u-boot-dtb.imx | head >> 000 00d1 4020 8780 f42c 877f >> 010 f420 877f f400 877f 6000 878d >> 020 f000 877f b000 000d 01d2 40e8 >> 030 01cc 04e4 0c02 6840 0c02 6c40 >> >> IVT self = 0x877ff400 >> Boot data addr = 0x877ff000 >> Boot data size = 0x000db000 >> >> 2. Calculate image size: >> >> Image offset = IVT self(0x877ff400) - Boot data addr(0x877ff000) = 0x400 >> Total image size = Boot data size(0x000db000) - Image offset(0x400) = 0xdac00 >> >> 3. Pad U-Boot image: >> >> $ objcopy -I binary -O binary --pad-to 0xdac00 --gap-fill=0x00 >> u-boot-dtb.imx u-boot-dtb.imx.pad >> >> Could you please try similar in your i.MX7D board? >> >> Thanks, >> Breno Lima > > Finally, it works! > > Thanks a lot for your help! This should be documented (I'll create a > patch for this) > or padding should implicitly be done in makefiles when building the > final imx image, > including initial padding for 0x400, like here [1]. I left [1] in my queue and I have always asked myself if we really need it. Frankly speaking, I prefer that the case should be clearly documented instead of adding an initial padding. Padding could forbid (or makes more difficult) to pack u-boot inside another container. Regards, Stefano > > Regards, > Igor > > [1] https://patchwork.ozlabs.org/patch/1136343/ > -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Re: [PATCH] Revert "mmc: davinci: drop struct davinci_mmc_plat"
On Fri, Jan 3, 2020 at 12:17 PM Tom Rini wrote:
>
> Adam Ford reports that this change breaks booting on da850-evm and
> Bartosz Golaszewski agrees that with the impending release we should
> revert the change for now. With that noted:
>
Is patchwork working? I tried to go there and I am not seeing any
patches newer than 1 Jan 2020.
I was going to pull the patch and test this.
adam
> This reverts commit 21a4d80a710c79053ac1deaa65ff9b69e6c031d4.
>
> Cc: Adam Ford
> Cc: Bartosz Golaszewski
> Signed-off-by: Tom Rini
> ---
> drivers/mmc/davinci_mmc.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
> index c3f7b57665d3..ef5cd4e7234f 100644
> --- a/drivers/mmc/davinci_mmc.c
> +++ b/drivers/mmc/davinci_mmc.c
> @@ -32,6 +32,10 @@ struct davinci_mmc_priv {
> uint input_clk; /* Input clock to MMC controller */
> struct gpio_desc cd_gpio; /* Card Detect GPIO */
> struct gpio_desc wp_gpio; /* Write Protect GPIO */
> +};
> +
> +struct davinci_mmc_plat
> +{
> struct mmc_config cfg;
> struct mmc mmc;
> };
> @@ -480,8 +484,9 @@ int davinci_mmc_init(bd_t *bis, struct davinci_mmc *host)
> static int davinci_mmc_probe(struct udevice *dev)
> {
> struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct davinci_mmc_plat *plat = dev_get_platdata(dev);
> struct davinci_mmc_priv *priv = dev_get_priv(dev);
> - struct mmc_config *cfg = &priv->cfg;
> + struct mmc_config *cfg = &plat->cfg;
> #ifdef CONFIG_SPL_BUILD
> int ret;
> #endif
> @@ -502,7 +507,7 @@ static int davinci_mmc_probe(struct udevice *dev)
> gpio_request_by_name(dev, "wp-gpios", 0, &priv->wp_gpio, GPIOD_IS_IN);
> #endif
>
> - upriv->mmc = &priv->mmc;
> + upriv->mmc = &plat->mmc;
>
> #ifdef CONFIG_SPL_BUILD
> /*
> @@ -513,7 +518,7 @@ static int davinci_mmc_probe(struct udevice *dev)
> * support in SPL, hence the hard-coded base register address.
> */
> priv->reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE;
> - ret = mmc_bind(dev, &priv->mmc, &priv->cfg);
> + ret = mmc_bind(dev, &plat->mmc, &plat->cfg);
> if (ret)
> return ret;
> #endif
> @@ -523,9 +528,9 @@ static int davinci_mmc_probe(struct udevice *dev)
>
> static int davinci_mmc_bind(struct udevice *dev)
> {
> - struct davinci_mmc_priv *priv = dev_get_priv(dev);
> + struct davinci_mmc_plat *plat = dev_get_platdata(dev);
>
> - return mmc_bind(dev, &priv->mmc, &priv->cfg);
> + return mmc_bind(dev, &plat->mmc, &plat->cfg);
> }
>
> static const struct udevice_id davinci_mmc_ids[] = {
> @@ -542,6 +547,7 @@ U_BOOT_DRIVER(davinci_mmc_drv) = {
> #endif
> .probe = davinci_mmc_probe,
> .ops = &davinci_mmc_ops,
> + .platdata_auto_alloc_size = sizeof(struct davinci_mmc_plat),
> .priv_auto_alloc_size = sizeof(struct davinci_mmc_priv),
> };
> #endif
> --
> 2.17.1
>
[PATCH v6 6/6] doc: boards: Add rockchip documentation
Rockchip has documentation file, doc/README.rockchip but which is not so readable to add or understand the existing contents. Even the format that support is legacy readme in U-Boot. Add rockchip specific documentation file using new rst format, which describes the information about Rockchip supported boards and it's usage steps. Added minimal information about rk3288, rk3328, rk3368 and rk3399 boards and usage. This would indeed updated further based on the requirements and updates. Cc: Kever Yang Cc: Matwey V. Kornilov Signed-off-by: Jagan Teki --- doc/board/rockchip/index.rst| 10 +++ doc/board/rockchip/rockchip.rst | 130 2 files changed, 140 insertions(+) create mode 100644 doc/board/rockchip/index.rst create mode 100644 doc/board/rockchip/rockchip.rst diff --git a/doc/board/rockchip/index.rst b/doc/board/rockchip/index.rst new file mode 100644 index 00..0c377e9bbb --- /dev/null +++ b/doc/board/rockchip/index.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2019 Jagan Teki + +Rockchip + + +.. toctree:: + :maxdepth: 2 + + rockchip diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst new file mode 100644 index 00..6c34f1ab99 --- /dev/null +++ b/doc/board/rockchip/rockchip.rst @@ -0,0 +1,130 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2019 Jagan Teki + +ROCKCHIP + + +About this +-- + +This document describes the information about Rockchip supported boards +and it's usage steps. + +Rockchip boards +--- + +Rockchip is SoC solutions provider for tablets & PCs, streaming media +TV boxes, AI audio & vision, IoT hardware. + +A wide range of Rockchip SoCs with associated boardsare supported in +mainline U-Boot. + +List of mainline supported rockchip boards: + +* rk3288 + - Evb-RK3288 + - Firefly-RK3288 + - mqmaker MiQi + - Phytec RK3288 PCM-947 + - PopMetal-RK3288 + - Radxa Rock 2 Square + - Tinker-RK3288 + - Google Jerry + - Google Mickey + - Google Minnie + - Google Speedy + - Amarula Vyasa-RK3288 +* rk3328 + - Rockchip RK3328 EVB + - Pine64 Rock64 +* rk3368 + - GeekBox + - PX5 EVB + - Rockchip sheep board + - Theobroma Systems RK3368-uQ7 SoM +* rk3399 + - 96boards RK3399 Ficus + - 96boards Rock960 + - Firefly-RK3399 Board + - Firefly ROC-RK3399-PC Board + - FriendlyElec NanoPC-T4 + - FriendlyElec NanoPi M4 + - FriendlyARM NanoPi NEO4 + - Google Bob + - Khadas Edge + - Khadas Edge-Captain + - Khadas Edge-V + - Orange Pi RK3399 Board + - Pine64 RockPro64 + - Radxa ROCK Pi 4 + - Rockchip RK3399 Evaluation Board + - Theobroma Systems RK3399-Q7 SoM + +Building + + +TF-A + + +TF-A would require to build for ARM64 Rockchip SoCs platforms. + +To build TF-A:: + +git clone https://github.com/ARM-software/arm-trusted-firmware.git +cd arm-trusted-firmware +make realclean +make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 + +Specify the PLAT= with desired rockchip platform to build TF-A for. + +U-Boot +^^ + +To build rk3328 boards:: + +export BL31=/path/to/arm-trusted-firmware/to/bl31.elf +make evb-rk3328_defconfig +make + +To build rk3288 boards:: + +make evb-rk3288_defconfig +make + +To build rk3368 boards:: + +export BL31=/path/to/arm-trusted-firmware/to/bl31.elf +make evb-px5_defconfig +make + +To build rk3399 boards:: + +export BL31=/path/to/arm-trusted-firmware/to/bl31.elf +make evb-rk3399_defconfig +make + +Flashing + + +SD Card +^^^ + +All rockchip platforms, except rk3128 (which doesn't use SPL) are now +supporting single boot image using binman and pad_cat. + +To write an image that boots from an SD card (assumed to be /dev/sda):: + +sudo dd if=u-boot-rockchip.bin of=/dev/sda seek=64 +sync + +TODO + + +- Add rockchip idbloader image building +- Add rockchip TPL image building +- Document SPI flash boot +- Describe steps for eMMC flashing +- Add missing SoC's with it boards list + +.. Jagan Teki +.. Sat Jan 4 14:00:54 IST 2020 -- 2.18.0.321.gffc6fa0e3
[PATCH v2 15/19] i2c: designware_i2c: Update to use standard enums for speed
Update this driver to use the new standard enums for speed.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/designware_i2c.c | 10 +-
drivers/i2c/designware_i2c.h | 13 -
2 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 4aee25c543..1f41e3eae0 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -103,21 +103,21 @@ struct i2c_mode_info {
static const struct i2c_mode_info info_for_mode[] = {
[IC_SPEED_MODE_STANDARD] = {
- I2C_STANDARD_SPEED,
+ I2C_SPEED_STANDARD_RATE,
MIN_SS_SCL_HIGHTIME,
MIN_SS_SCL_LOWTIME,
1000,
300,
},
[IC_SPEED_MODE_FAST] = {
- I2C_FAST_SPEED,
+ I2C_SPEED_FAST_RATE,
MIN_FS_SCL_HIGHTIME,
MIN_FS_SCL_LOWTIME,
300,
300,
},
[IC_SPEED_MODE_HIGH] = {
- I2C_HIGH_SPEED,
+ I2C_SPEED_HIGH_RATE,
MIN_HS_SCL_HIGHTIME,
MIN_HS_SCL_LOWTIME,
120,
@@ -226,10 +226,10 @@ static unsigned int __dw_i2c_set_bus_speed(struct dw_i2c
*priv,
if (priv)
scl_sda_cfg = priv->scl_sda_cfg;
/* Allow high speed if there is no config, or the config allows it */
- if (speed >= I2C_HIGH_SPEED &&
+ if (speed >= I2C_SPEED_HIGH_RATE &&
(!scl_sda_cfg || scl_sda_cfg->has_high_speed))
i2c_spd = IC_SPEED_MODE_HIGH;
- else if (speed >= I2C_FAST_SPEED)
+ else if (speed >= I2C_SPEED_FAST_RATE)
i2c_spd = IC_SPEED_MODE_FAST;
else
i2c_spd = IC_SPEED_MODE_STANDARD;
diff --git a/drivers/i2c/designware_i2c.h b/drivers/i2c/designware_i2c.h
index 2c572a9e1f..4738f4642d 100644
--- a/drivers/i2c/designware_i2c.h
+++ b/drivers/i2c/designware_i2c.h
@@ -134,19 +134,6 @@ struct i2c_regs {
#define IC_STATUS_TFNF 0x0002
#define IC_STATUS_ACT 0x0001
-/* Speed Selection */
-enum i2c_speed_mode {
- IC_SPEED_MODE_STANDARD,
- IC_SPEED_MODE_FAST,
- IC_SPEED_MODE_HIGH,
-
- IC_SPEED_MODE_COUNT,
-};
-
-#define I2C_HIGH_SPEED 340
-#define I2C_FAST_SPEED 40
-#define I2C_STANDARD_SPEED 10
-
/**
* struct dw_scl_sda_cfg - I2C timing configuration
*
--
2.24.1.735.g03f4e72817-goog
Re: [PATCH] .gitignore: ignore files generated by asn1 compiler
On Sun, Dec 29, 2019 at 01:47:32PM +0100, Dario Binacchi wrote: > As described in doc/README.asn1 document the tools/asn1_compiler is used > to "generate bytecode as a C file (*.asn1.[ch]) from *.asn1 file". > > Signed-off-by: Dario Binacchi Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v2 03/19] i2c: designware_i2c: Include clk.h in the header file
We use struct clk here so really should include this header file to avoid
build errors. Also switch the order of clk.h in the C file to match the
required code style.
Signed-off-by: Simon Glass
Reviewed-by: Ley Foon Tan
---
Changes in v2: None
drivers/i2c/designware_i2c.c | 2 +-
drivers/i2c/designware_i2c.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index b8cdd1c661..138fc72561 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -4,8 +4,8 @@
* Vipin Kumar, ST Micoelectronics, vipin.ku...@st.com.
*/
-#include
#include
+#include
#include
#include
#include
diff --git a/drivers/i2c/designware_i2c.h b/drivers/i2c/designware_i2c.h
index 0eb28191d2..39e62bcf51 100644
--- a/drivers/i2c/designware_i2c.h
+++ b/drivers/i2c/designware_i2c.h
@@ -7,6 +7,7 @@
#ifndef __DW_I2C_H_
#define __DW_I2C_H_
+#include
#include
struct i2c_regs {
--
2.24.1.735.g03f4e72817-goog
[PATCH v2 00/19] i2c: designware_ic2: Improvements to timing and general cleanup
This series updates the Designware I2C driver to support reading its timing from the device tree and handling it in units of nanoseconds instead of clock cycles. A new function converts from nanoseconds to the units used by the I2C controller and makes sure that the requested bus speed is not exceeded. This is more accurate than the existing method. The series includes a few smaller clean-ups in the same driver. In addition the v2 series adds enums for i2c speed and updates drivers to use them. There is currently an existing configuration method used just for a few x86 boards (Baytrail). This method is retained but it should be removed in favour of using the device tree. I have not done this in this series since I am not sure of the timings to use. Changes in v2: - Fix 'previde' typo - Add a few more clean-up patches for i2c Simon Glass (19): i2c: designware_i2c: Add more registers i2c: designware_i2c: Don't allow changing IC_CLK i2c: designware_i2c: Include clk.h in the header file i2c: designware_i2c: Rename 'max' speed to 'high' speed i2c: designware_i2c: Use an enum for selected speed mode i2c: designware_i2c: Use an accurate bus clock instead of MHz i2c: designware_i2c: Bring in the binding file i2c: designware_i2c: Read device-tree properties i2c: designware_i2c: Drop scl_sda_cfg parameter i2c: designware_i2c: Put hold config in a struct i2c: designware_i2c: Rewrite timing calculation i2c: designware_i2c: Add spike supression i2c: Add enums for i2c speed and address size i2c: ast_i2c: Update to use standard enums for speed i2c: designware_i2c: Update to use standard enums for speed i2c: kona_i2c: Update to use standard enums for speed i2c: omap: Update to use standard enums for speed i2c: stm32: Update to use standard enums for speed i2c: Update drivers to use enum for speed .../i2c/i2c-designware.txt| 73 + drivers/i2c/ast_i2c.c | 2 +- drivers/i2c/ast_i2c.h | 2 - drivers/i2c/designware_i2c.c | 265 ++ drivers/i2c/designware_i2c.h | 50 ++-- drivers/i2c/designware_i2c_pci.c | 4 +- drivers/i2c/exynos_hs_i2c.c | 4 +- drivers/i2c/fsl_i2c.c | 3 +- drivers/i2c/i2c-cdns.c| 2 +- drivers/i2c/i2c-uclass.c | 12 +- drivers/i2c/i2c-uniphier-f.c | 2 +- drivers/i2c/i2c-uniphier.c| 2 +- drivers/i2c/imx_lpi2c.c | 8 +- drivers/i2c/kona_i2c.c| 28 +- drivers/i2c/mv_i2c.c | 4 +- drivers/i2c/mvtwsi.c | 5 +- drivers/i2c/omap24xx_i2c.c| 5 +- drivers/i2c/omap24xx_i2c.h| 4 - drivers/i2c/rcar_i2c.c| 2 +- drivers/i2c/rcar_iic.c| 2 +- drivers/i2c/s3c24x0_i2c.c | 4 +- drivers/i2c/sandbox_i2c.c | 3 +- drivers/i2c/stm32f7_i2c.c | 43 ++- include/i2c.h | 26 ++ 24 files changed, 410 insertions(+), 145 deletions(-) create mode 100644 doc/device-tree-bindings/i2c/i2c-designware.txt -- 2.24.1.735.g03f4e72817-goog
[PATCH v6 4/6] arm: dts: rk3036: Add rk3036-u-boot.dtsi
Add U-Boot specific dtsi file for rk3036 SoC. This
would help to add U-Boot specific dts nodes, properties
which are common across rk3036.
Right now, the file is empty, will add required changes
in future patches.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
---
arch/arm/dts/rk3036-sdk-u-boot.dtsi | 2 ++
arch/arm/dts/rk3036-u-boot.dtsi | 4
2 files changed, 6 insertions(+)
create mode 100644 arch/arm/dts/rk3036-u-boot.dtsi
diff --git a/arch/arm/dts/rk3036-sdk-u-boot.dtsi
b/arch/arm/dts/rk3036-sdk-u-boot.dtsi
index 6f15f4a8ec..754800c6e6 100644
--- a/arch/arm/dts/rk3036-sdk-u-boot.dtsi
+++ b/arch/arm/dts/rk3036-sdk-u-boot.dtsi
@@ -1,3 +1,5 @@
+#include "rk3036-u-boot.dtsi"
+
&uart2 {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/rk3036-u-boot.dtsi b/arch/arm/dts/rk3036-u-boot.dtsi
new file mode 100644
index 00..1e7d079315
--- /dev/null
+++ b/arch/arm/dts/rk3036-u-boot.dtsi
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki
+ */
--
2.18.0.321.gffc6fa0e3
[PATCH v6 3/6] Makefile: rockchip: Support SPL-alone mkimage
Add SPL-alone mkimage tooling support via Makefile for few platforms or boards used in rockchip family. With this users would get rid of explicitly creating mkimage tool for rockchip rksd or rkspi boot modes. Signed-off-by: Jagan Teki Reviewed-by: Kever Yang --- Makefile | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index e519103be4..d8a0f68883 100644 --- a/Makefile +++ b/Makefile @@ -908,7 +908,7 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy) ALL-y += u-boot-with-dtb.bin endif -ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL)$(CONFIG_TPL),yyy) +ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy) ALL-y += idbloader.img endif @@ -1382,11 +1382,19 @@ else ROCKCHIP_IMG_TYPE := rksd endif +# TPL + SPL +ifeq ($(CONFIG_SPL)$(CONFIG_TPL),yy) MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE) tpl/u-boot-tpl-rockchip.bin: tpl/u-boot-tpl.bin FORCE $(call if_changed,mkimage) idbloader.img: tpl/u-boot-tpl-rockchip.bin spl/u-boot-spl.bin FORCE $(call if_changed,cat) +else +MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE) +idbloader.img: spl/u-boot-spl.bin FORCE + $(call if_changed,mkimage) +endif + endif ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy) -- 2.18.0.321.gffc6fa0e3
Re: [PATCH v2] riscv: Add option to print registers on exception
On Wed, Dec 25, 2019 at 1:27 PM Sean Anderson wrote: > > When debugging, it can be helpful to see more information about an > unhandled exception. This patch adds an option to view the registers at > the time of the trap, similar to the linux output on a kernel panic. > > Signed-off-by: Sean Anderson > --- > Changes for v2: >- Renamed "PC" to "EPC" > > arch/riscv/Kconfig | 3 +++ > arch/riscv/cpu/mtrap.S | 3 ++- > arch/riscv/lib/interrupts.c | 50 + > 3 files changed, 44 insertions(+), 12 deletions(-) > Reviewed-by: Bin Meng Tested-by: Bin Meng
MMC failures on Davinci (Da850-evm)
Does anyone with a da850/l-138/am1808 have any issues with MMC on their board? I haven't bisected it yet and only I found it by accident. U-Boot SPL 2020.01-rc5-00073-g4b75aa5aa7 (Jan 03 2020 - 09:08:17 -0600) Trying to boot from SPI U-Boot 2020.01-rc5-00073-g4b75aa5aa7 (Jan 03 2020 - 09:08:17 -0600) DRAM: 128 MiB MMC: : 0 Loading Environment from SPI Flash... SF: Detected m25p64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB OK In:serial@10d000 Out: serial@10d000 Err: serial@10d000 SF: Detected m25p64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB Default using MAC address from environment Net: eth0: ethernet@22 Hit any key to stop autoboot: 0 U-Boot >
Re: [PATCH 8/8] ARM: dts: imx6qdli-icore: Add fec phy-handle
Hi Jagan, Michael,
On 31/12/19 07:21, Jagan Teki wrote:
> On Mon, Dec 30, 2019 at 10:55 PM Michael Nazzareno Trimarchi
> wrote:
>>
>> Hi
>>
>> On Mon, Dec 30, 2019 at 1:04 PM Jagan Teki
>> wrote:
>>>
>>> From: Michael Trimarchi
>>>
>>> LAN8720 needs a reset of every clock enable. The reset needs
>>> to be done at device level, due the flag PHY_RST_AFTER_CLK_EN.
>>>
>>> So, add phy-handle by creating mdio child node inside fec.
>>> This will eventually move the phy-reset-gpio which is defined
>>> in fec node.
>>>
>>> Signed-off-by: Michael Trimarchi
>>> Signed-off-by: Jagan Teki
>>> ---
>>> arch/arm/dts/imx6qdl-icore.dtsi | 15 ++-
>>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/dts/imx6qdl-icore.dtsi
>>> b/arch/arm/dts/imx6qdl-icore.dtsi
>>> index 7814f1ef08..756f3a9f1b 100644
>>> --- a/arch/arm/dts/imx6qdl-icore.dtsi
>>> +++ b/arch/arm/dts/imx6qdl-icore.dtsi
>>> @@ -150,10 +150,23 @@
>>> &fec {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&pinctrl_enet>;
>>> - phy-reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
>>> clocks = <&clks IMX6QDL_CLK_ENET>, <&clks IMX6QDL_CLK_ENET>,
>>> <&rmii_clk>;
>>> phy-mode = "rmii";
>>> + phy-handle = <ð_phy>;
>>> status = "okay";
>>> +
>>> + mdio {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + eth_phy: ethernet-phy@0 {
>>> + compatible = "ethernet-phy-ieee802.3-c22";
>>> + reg = <0>;
>>> + reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
>>> + reset-assert-us = <4000>;
>>> + reset-deassert-us = <4000>;
>>> + };
>>> + };
>>> };
>>
>> This work in linux but not in uboot. I don't think that we have this
>> kind of connection.
>
> Okay. Missed to check will drop this from series.
>
So is it ok if I merge the series with the exception of 8/8 ?
Regards,
Stefano
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
[PATCH v6 1/6] Makefile: Add rockchip image type
Add rockchip image type support. right now the image type marked with rksd, So create image type variable with required image type like rksd or rkspi. Cc: Kever Yang Cc: Matwey V. Kornilov Signed-off-by: Jagan Teki Reviewed-by: Kever Yang --- Makefile | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index e20a206239..9998d238f3 100644 --- a/Makefile +++ b/Makefile @@ -1374,7 +1374,15 @@ u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE $(call if_changed,pad_cat) ifeq ($(CONFIG_ARCH_ROCKCHIP),y) -MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T rksd + +# rockchip image type +ifeq ($(CONFIG_SPI_FLASH_SUPPORT),y) +ROCKCHIP_IMG_TYPE := rkspi +else +ROCKCHIP_IMG_TYPE := rksd +endif + +MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE) tpl/u-boot-tpl.img: tpl/u-boot-tpl.bin FORCE $(call if_changed,mkimage) idbloader.img: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE -- 2.18.0.321.gffc6fa0e3
Re: [PATCH] arm: dts: bcm283x: Allow UARTs to work before relocation
On Thu, Jan 02, 2020 at 07:28:50PM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 2 Jan 2020 at 19:27, Simon Glass wrote:
> >
> > Hi Tom,
> >
> > On Thu, 2 Jan 2020 at 16:11, Tom Rini wrote:
> > >
> > > On Tue, Dec 31, 2019 at 02:28:19PM -0700, Simon Glass wrote:
> > > > Hi Matthias,
> > > >
> > > > On Tue, 10 Dec 2019 at 02:43, Matthias Brugger
> > > > wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On 02/12/2019 16:45, Tom Rini wrote:
> > > > > > On Sun, Dec 01, 2019 at 07:33:56PM -0700, Simon Glass wrote:
> > > > > >
> > > > > >> At present the pinctrl nodes are not enabled in pre-relocation
> > > > > >> U-Boot so
> > > > > >> the UARTs do not correctly select the pinconfig to enable the UART
> > > > > >> pins.
> > > > > >> Fix this so that the U-Boot banner is printed.
> > > > > >>
> > > > > >> Signed-off-by: Simon Glass
> > > > > >> Fixes: 9821636b64 (bcm2835_pinctrl: Probe pre-reloc)
> > > > > >> ---
> > > > > >>
> > > > > >> arch/arm/dts/bcm283x-u-boot.dtsi | 8
> > > > > >> 1 file changed, 8 insertions(+)
> > > > > >>
> > > > > >> diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi
> > > > > >> b/arch/arm/dts/bcm283x-u-boot.dtsi
> > > > > >> index 36548dad62..68d03627f4 100644
> > > > > >> --- a/arch/arm/dts/bcm283x-u-boot.dtsi
> > > > > >> +++ b/arch/arm/dts/bcm283x-u-boot.dtsi
> > > > > >> @@ -19,3 +19,11 @@
> > > > > >> &gpio {
> > > > > >> u-boot,dm-pre-reloc;
> > > > > >> };
> > > > > >> +
> > > > > >> +&uart0_gpio14 {
> > > > > >> +u-boot,dm-pre-reloc;
> > > > > >> +};
> > > > > >> +
> > > > > >> +&uart1_gpio14 {
> > > > > >> +u-boot,dm-pre-reloc;
> > > > > >> +};
> > > > > >
> > > > > > I think this is superseded by the RPi PR that I had been testing and
> > > > > > just now pushed. Can you confirm that master is fine on your Pis as
> > > > > > well? I gather you hit this failure doing pytest on the board,
> > > > > > which is
> > > > > > also how I found it. Thanks!
> > > > > >
> > > > >
> > > > > Can you confirm if this is working with master branch or if we still
> > > > > need your
> > > > > patch. In which situation would we need your patch then?
> > > >
> > > > Unfortunately with the 'next' branch I still need this patch. WIthout
> > > > it I don't get the pre-relocation serial output and tests fail.
> > >
> > > Which Pi exactly? My 3B works with rpi_3_32b, rpi_3 and rpi_arm64
> > > defconfigs and test.py.
> >
> > It is a rpi_3b I believe, and I am using the rpi_3_32b.
> >
> > When I cherry-pick the patch the banner appears but before that it
> > doesn't. Shall I check it again?
>
> Actually, can you please confirm the tree you are using? I was testing
> with -next. I wonder if I was missing a patch?
I just re-confirmed by checking out current 'next' and re-running
test.py on all of the above combinations and they pass.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 00/20] Add i.MXRT family support
Hi Stefano, On 1/3/20 12:39 PM, Stefano Babic wrote: Hi Giulio, On 04/12/19 18:44, Giulio Benetti wrote: This patchset add support for i.MXRT family starting from i.MXRT1050 SoC. It provides: - i.MXRT1050 SoC entry - i.MXRT pinctrl driver - i.MXRT serial driver tweaking - i.MXRT sdram controller driver - i.MXRT usdhc driver tweaking - i.MXRT1050-evk initial support It uses all DM clocks all around and it loads correctly a basic Linux zImage. Lukasz has already reviewed most patches, and a V2 is surely WIP. FYI: I archive this first series, and I'll wait for your next V2 - thanks ! Ok, I'm going to submit it in a couple of weeks! Best regards -- Giulio Benetti Benetti Engineering sas Best regards, Stefano Giulio Benetti (20): armv7m: cache: add mmu_set_region_dcache_behaviour() stub for compatibility spl: fix entry_point equal to load_addr clk: imx: pllv3: register PLLV3 GENERIC and USB as 2 different clocks clk: imx: pllv3: set div_mask differently if PLLV3 is GENERIC or USB clk: imx: pllv3: add enable() support clk: imx: pllv3: add disable() support clk: imx: pllv3: add set_rate() support clk: imx: pllv3: add PLLV3_SYS support clk: imx: pllv3: add support for PLLV3_AV type clk: imx: pfd: add set_rate() clk: imx: add i.IMXRT1050 clk driver pinctrl: add i.MXRT driver ARM: dts: imxrt1050: add dtsi file serial_lpuart: add clock enable if CONFIG_CLK is defined serial_lpuart: add support for i.MXRT ram: add SDRAM driver for i.MXRT SoCs mmc: fsl_esdhc: make if(CONFIG_IS_ENABLED(CLK)) an #if statement mmc: fsl_esdhc: add compatible for fsl, imxrt-usdhc imx: Add basic support for the NXP IMXRT10xx SoC family imx: imxrt1050-evk: Add support for the NXP i.MXRT1050-EVK arch/arm/Kconfig | 10 + arch/arm/Makefile | 4 +- arch/arm/cpu/armv7m/cache.c | 6 + arch/arm/dts/Makefile | 2 + arch/arm/dts/imxrt1050-evk.dts| 209 arch/arm/dts/imxrt1050.dtsi | 146 +++ arch/arm/include/asm/arch-imxrt/clock.h | 10 + arch/arm/include/asm/arch-imxrt/gpio.h| 19 + arch/arm/include/asm/arch-imxrt/imx-regs.h| 20 + arch/arm/include/asm/arch-imxrt/imxrt.h | 11 + arch/arm/include/asm/arch-imxrt/sys_proto.h | 11 + arch/arm/mach-imx/Makefile| 3 +- arch/arm/mach-imx/imxrt/Kconfig | 21 + arch/arm/mach-imx/imxrt/Makefile | 7 + arch/arm/mach-imx/imxrt/soc.c | 35 + board/freescale/imxrt1050-evk/Kconfig | 22 + board/freescale/imxrt1050-evk/MAINTAINERS | 6 + board/freescale/imxrt1050-evk/Makefile| 6 + board/freescale/imxrt1050-evk/README | 31 + board/freescale/imxrt1050-evk/imximage.cfg| 36 + board/freescale/imxrt1050-evk/imxrt1050-evk.c | 81 ++ common/spl/spl.c | 4 +- configs/imxrt1050-evk_defconfig | 74 ++ drivers/clk/imx/Kconfig | 16 + drivers/clk/imx/Makefile | 2 + drivers/clk/imx/clk-imxrt1050.c | 292 + drivers/clk/imx/clk-pfd.c | 22 + drivers/clk/imx/clk-pllv3.c | 218 +++- drivers/mmc/Kconfig | 2 +- drivers/mmc/fsl_esdhc_imx.c | 41 +- drivers/pinctrl/nxp/Kconfig | 14 + drivers/pinctrl/nxp/Makefile | 1 + drivers/pinctrl/nxp/pinctrl-imxrt.c | 40 + drivers/ram/Kconfig | 8 + drivers/ram/Makefile | 2 + drivers/ram/imxrt_sdram.c | 439 drivers/serial/serial_lpuart.c| 28 +- include/configs/imxrt1050-evk.h | 59 ++ include/dt-bindings/clock/imxrt1050-clock.h | 65 ++ include/dt-bindings/memory/imxrt-sdram.h | 100 ++ include/dt-bindings/pinctrl/pins-imxrt1050.h | 993 ++ include/fsl_lpuart.h | 3 +- 42 files changed, 3083 insertions(+), 36 deletions(-) create mode 100644 arch/arm/dts/imxrt1050-evk.dts create mode 100644 arch/arm/dts/imxrt1050.dtsi create mode 100644 arch/arm/include/asm/arch-imxrt/clock.h create mode 100644 arch/arm/include/asm/arch-imxrt/gpio.h create mode 100644 arch/arm/include/asm/arch-imxrt/imx-regs.h create mode 100644 arch/arm/include/asm/arch-imxrt/imxrt.h create mode 100644 arch/arm/include/asm/arch-imxrt/sys_proto.h create mode 100644 arch/arm/mach-imx/imxrt/Kconfig create mode 100644 arch/arm/mach-imx/imxrt/Makefile create mode 100644 arch/arm/mach-imx/imxrt/soc.c create mode 100644 board/freescale/imxrt1050-evk/Kconfig create mode 100644 board/freescale/imxrt1050-evk/MAINTAINERS create mode 100644 board/freescale/imxrt1050-evk/Makefile create mode 100644 b
Re: [PATCH 00/20] Add i.MXRT family support
Hi Giulio, On 04/12/19 18:44, Giulio Benetti wrote: > This patchset add support for i.MXRT family starting from i.MXRT1050 SoC. > It provides: > - i.MXRT1050 SoC entry > - i.MXRT pinctrl driver > - i.MXRT serial driver tweaking > - i.MXRT sdram controller driver > - i.MXRT usdhc driver tweaking > - i.MXRT1050-evk initial support > > It uses all DM clocks all around and it loads correctly a basic Linux zImage. > Lukasz has already reviewed most patches, and a V2 is surely WIP. FYI: I archive this first series, and I'll wait for your next V2 - thanks ! Best regards, Stefano > Giulio Benetti (20): > armv7m: cache: add mmu_set_region_dcache_behaviour() stub for > compatibility > spl: fix entry_point equal to load_addr > clk: imx: pllv3: register PLLV3 GENERIC and USB as 2 different clocks > clk: imx: pllv3: set div_mask differently if PLLV3 is GENERIC or USB > clk: imx: pllv3: add enable() support > clk: imx: pllv3: add disable() support > clk: imx: pllv3: add set_rate() support > clk: imx: pllv3: add PLLV3_SYS support > clk: imx: pllv3: add support for PLLV3_AV type > clk: imx: pfd: add set_rate() > clk: imx: add i.IMXRT1050 clk driver > pinctrl: add i.MXRT driver > ARM: dts: imxrt1050: add dtsi file > serial_lpuart: add clock enable if CONFIG_CLK is defined > serial_lpuart: add support for i.MXRT > ram: add SDRAM driver for i.MXRT SoCs > mmc: fsl_esdhc: make if(CONFIG_IS_ENABLED(CLK)) an #if statement > mmc: fsl_esdhc: add compatible for fsl, imxrt-usdhc > imx: Add basic support for the NXP IMXRT10xx SoC family > imx: imxrt1050-evk: Add support for the NXP i.MXRT1050-EVK > > arch/arm/Kconfig | 10 + > arch/arm/Makefile | 4 +- > arch/arm/cpu/armv7m/cache.c | 6 + > arch/arm/dts/Makefile | 2 + > arch/arm/dts/imxrt1050-evk.dts| 209 > arch/arm/dts/imxrt1050.dtsi | 146 +++ > arch/arm/include/asm/arch-imxrt/clock.h | 10 + > arch/arm/include/asm/arch-imxrt/gpio.h| 19 + > arch/arm/include/asm/arch-imxrt/imx-regs.h| 20 + > arch/arm/include/asm/arch-imxrt/imxrt.h | 11 + > arch/arm/include/asm/arch-imxrt/sys_proto.h | 11 + > arch/arm/mach-imx/Makefile| 3 +- > arch/arm/mach-imx/imxrt/Kconfig | 21 + > arch/arm/mach-imx/imxrt/Makefile | 7 + > arch/arm/mach-imx/imxrt/soc.c | 35 + > board/freescale/imxrt1050-evk/Kconfig | 22 + > board/freescale/imxrt1050-evk/MAINTAINERS | 6 + > board/freescale/imxrt1050-evk/Makefile| 6 + > board/freescale/imxrt1050-evk/README | 31 + > board/freescale/imxrt1050-evk/imximage.cfg| 36 + > board/freescale/imxrt1050-evk/imxrt1050-evk.c | 81 ++ > common/spl/spl.c | 4 +- > configs/imxrt1050-evk_defconfig | 74 ++ > drivers/clk/imx/Kconfig | 16 + > drivers/clk/imx/Makefile | 2 + > drivers/clk/imx/clk-imxrt1050.c | 292 + > drivers/clk/imx/clk-pfd.c | 22 + > drivers/clk/imx/clk-pllv3.c | 218 +++- > drivers/mmc/Kconfig | 2 +- > drivers/mmc/fsl_esdhc_imx.c | 41 +- > drivers/pinctrl/nxp/Kconfig | 14 + > drivers/pinctrl/nxp/Makefile | 1 + > drivers/pinctrl/nxp/pinctrl-imxrt.c | 40 + > drivers/ram/Kconfig | 8 + > drivers/ram/Makefile | 2 + > drivers/ram/imxrt_sdram.c | 439 > drivers/serial/serial_lpuart.c| 28 +- > include/configs/imxrt1050-evk.h | 59 ++ > include/dt-bindings/clock/imxrt1050-clock.h | 65 ++ > include/dt-bindings/memory/imxrt-sdram.h | 100 ++ > include/dt-bindings/pinctrl/pins-imxrt1050.h | 993 ++ > include/fsl_lpuart.h | 3 +- > 42 files changed, 3083 insertions(+), 36 deletions(-) > create mode 100644 arch/arm/dts/imxrt1050-evk.dts > create mode 100644 arch/arm/dts/imxrt1050.dtsi > create mode 100644 arch/arm/include/asm/arch-imxrt/clock.h > create mode 100644 arch/arm/include/asm/arch-imxrt/gpio.h > create mode 100644 arch/arm/include/asm/arch-imxrt/imx-regs.h > create mode 100644 arch/arm/include/asm/arch-imxrt/imxrt.h > create mode 100644 arch/arm/include/asm/arch-imxrt/sys_proto.h > create mode 100644 arch/arm/mach-imx/imxrt/Kconfig > create mode 100644 arch/arm/mach-imx/imxrt/Makefile > create mode 100644 arch/arm/mach-imx/imxrt/soc.c > create mode 100644 board/freescale/imxrt1050-evk/Kconfig > create mode 100644 board/freescale/imxrt1050-evk/MAINTAINERS > create mode 100644 board/freescale/imxrt1050-evk/Makefile > create mode 100644 board/freescale/imxrt1050-evk/README > create mode 100644 board
[PATCH v2] board/lx2160aqds: Update the DSPI status fixup
The dts node of the DSPI controller in kernel is spi instead of dspi,
it is not correct if use "/soc/dspi@" to fix up the status of the dts
in kernel, so, modify it to "/soc/spi@".
The DSPI2 and I2C5 are muxed, and the status of DSPI2 node in kernel dts
default value is okay, set the status of DSPI2 node is disabled if it
used to I2C5.
Signed-off-by: Xiaowei Bao
---
v2:
- Modify the subject and commit message.
board/freescale/lx2160a/lx2160a.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index eff5d9f..3d7cd8b 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -210,9 +210,9 @@ void esdhc_dspi_status_fixup(void *blob)
{
const char esdhc0_path[] = "/soc/esdhc@214";
const char esdhc1_path[] = "/soc/esdhc@215";
- const char dspi0_path[] = "/soc/dspi@210";
- const char dspi1_path[] = "/soc/dspi@211";
- const char dspi2_path[] = "/soc/dspi@212";
+ const char dspi0_path[] = "/soc/spi@210";
+ const char dspi1_path[] = "/soc/spi@211";
+ const char dspi2_path[] = "/soc/spi@212";
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
u32 sdhc1_base_pmux;
@@ -262,10 +262,12 @@ void esdhc_dspi_status_fixup(void *blob)
& FSL_CHASSIS3_IIC5_PMUX_MASK;
iic5_pmux >>= FSL_CHASSIS3_IIC5_PMUX_SHIFT;
- if (iic5_pmux == IIC5_PMUX_SPI3) {
+ if (iic5_pmux == IIC5_PMUX_SPI3)
do_fixup_by_path(blob, dspi2_path, "status", "okay",
sizeof("okay"), 1);
- }
+ else
+ do_fixup_by_path(blob, dspi2_path, "status", "disabled",
+sizeof("disabled"), 1);
}
#endif
--
2.9.5
[PATCH v6 5/6] rockchip: Add Single boot image (with binman, pad_cat)
All rockchip platforms support TPL or SPL-based bootloader
in mainline with U-Boot proper as final stage. For each
stage we need to burn the image on to flash with respective
offsets.
This patch creates a single boot image component using
- binman, for arm32 rockchip platforms
- pad_cat, for arm64 rockchip platforms.
This would help users to get rid of burning different
boot stage images.
The new image called 'u-boot-rockchip.bin'
which can burn into flash like:
₹ sudo dd if=u-boot-rockchip.bin of=/dev/sda seek=64
This would support all rockchip platforms, except rk3128
since it doesn't support for SPL yet.
Cc: Kever Yang
Cc: Matwey V. Kornilov
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
---
Makefile | 14 --
arch/arm/Kconfig | 1 +
arch/arm/dts/rk3036-u-boot.dtsi | 2 ++
arch/arm/dts/rk3288-u-boot.dtsi | 2 ++
arch/arm/dts/rockchip-u-boot.dtsi | 21 +
include/configs/rockchip-common.h | 3 +++
6 files changed, 41 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/rockchip-u-boot.dtsi
diff --git a/Makefile b/Makefile
index d8a0f68883..cdd3eb4614 100644
--- a/Makefile
+++ b/Makefile
@@ -909,7 +909,7 @@ ALL-y += u-boot-with-dtb.bin
endif
ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
-ALL-y += idbloader.img
+ALL-y += u-boot-rockchip.bin
endif
LDFLAGS_u-boot += $(LDFLAGS_FINAL)
@@ -1395,7 +1395,17 @@ idbloader.img: spl/u-boot-spl.bin FORCE
$(call if_changed,mkimage)
endif
-endif
+ifeq ($(CONFIG_ARM64),)
+u-boot-rockchip.bin: idbloader.img u-boot.img FORCE
+ $(call if_changed,binman)
+else
+OBJCOPYFLAGS_u-boot-rockchip.bin = -I binary -O binary \
+ --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff
+u-boot-rockchip.bin: idbloader.img u-boot.itb FORCE
+ $(call if_changed,pad_cat)
+endif # CONFIG_ARM64
+
+endif # CONFIG_ARCH_ROCKCHIP
ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy)
MKIMAGEFLAGS_lpc32xx-spl.img = -T lpc32xximage -a $(CONFIG_SPL_TEXT_BASE)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f9dab073ea..7bd99ba3bb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1590,6 +1590,7 @@ config ARCH_STM32MP
config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
select BLK
+ select BINMAN if !ARM64
select DM
select DM_GPIO
select DM_I2C
diff --git a/arch/arm/dts/rk3036-u-boot.dtsi b/arch/arm/dts/rk3036-u-boot.dtsi
index 1e7d079315..41ac054b81 100644
--- a/arch/arm/dts/rk3036-u-boot.dtsi
+++ b/arch/arm/dts/rk3036-u-boot.dtsi
@@ -2,3 +2,5 @@
/*
* Copyright (C) 2019 Jagan Teki
*/
+
+#include "rockchip-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 3f00a3b6d3..6d31735362 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright (C) 2019 Rockchip Electronics Co., Ltd
*/
+#include "rockchip-u-boot.dtsi"
+
/ {
chosen {
u-boot,spl-boot-order = \
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
b/arch/arm/dts/rockchip-u-boot.dtsi
new file mode 100644
index 00..a2559e2db0
--- /dev/null
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki
+ */
+
+#include
+
+/ {
+ binman {
+ filename = "u-boot-rockchip.bin";
+ pad-byte = <0xff>;
+
+ blob {
+ filename = "idbloader.img";
+ };
+
+ u-boot-img {
+ offset = ;
+ };
+ };
+};
diff --git a/include/configs/rockchip-common.h
b/include/configs/rockchip-common.h
index 68e1105a4b..b55e09a9ca 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -9,6 +9,9 @@
#define CONFIG_SYS_NS16550_MEM32
+/* ((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512) */
+#define CONFIG_SPL_PAD_TO 8355840
+
#ifndef CONFIG_SPL_BUILD
/* First try to boot from SD (index 0), then eMMC (index 1) */
--
2.18.0.321.gffc6fa0e3
[PATCH v6 2/6] Makefile: rockchip: Suffix platform type with tpl name
Most of the platforms uses the platform type on their boot stage image naming conventions in makefile like, u-boot-x86-start16-tpl.bin - x86 start16 TPL bin u-boot-spl-mtk.bin - Mediatek SPL bin This would help to understand the users to what that particular image belongs to? and less confused. On that note, suffix platform type rockchip for existing u-boot-tpl.img so now it become u-boot-tpl-rockchip.bin Also, bin is more conventional way to include it on tools like binman, pad_cat etc in future patches. Note: usage of platform type doesn't follow consistent order as of now. Signed-off-by: Jagan Teki Reviewed-by: Kever Yang --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 9998d238f3..e519103be4 100644 --- a/Makefile +++ b/Makefile @@ -1382,10 +1382,10 @@ else ROCKCHIP_IMG_TYPE := rksd endif -MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE) -tpl/u-boot-tpl.img: tpl/u-boot-tpl.bin FORCE +MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE) +tpl/u-boot-tpl-rockchip.bin: tpl/u-boot-tpl.bin FORCE $(call if_changed,mkimage) -idbloader.img: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE +idbloader.img: tpl/u-boot-tpl-rockchip.bin spl/u-boot-spl.bin FORCE $(call if_changed,cat) endif -- 2.18.0.321.gffc6fa0e3
[PATCH v2 17/19] i2c: omap: Update to use standard enums for speed
Update this driver to use the new standard enums for speed.
Note: This driver needs to move to driver model.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/omap24xx_i2c.c | 2 +-
drivers/i2c/omap24xx_i2c.h | 4
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 4b93e02bbe..7e6e3c4f81 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -306,7 +306,7 @@ static int __omap24_i2c_setspeed(void __iomem *i2c_base,
int ip_rev, uint speed,
int hsscll = 0, hssclh = 0;
u32 scll = 0, sclh = 0;
- if (speed >= OMAP_I2C_HIGH_SPEED) {
+ if (speed >= I2C_SPEED_HIGH_RATE) {
/* High speed */
psc = I2C_IP_CLK / I2C_INTERNAL_SAMPLING_CLK;
psc -= 1;
diff --git a/drivers/i2c/omap24xx_i2c.h b/drivers/i2c/omap24xx_i2c.h
index 3458cf3a7d..6904f2d9ad 100644
--- a/drivers/i2c/omap24xx_i2c.h
+++ b/drivers/i2c/omap24xx_i2c.h
@@ -81,10 +81,6 @@
#define I2C_SCLH_HSSCLH8
#define I2C_SCLH_HSSCLH_M 0xFF
-#define OMAP_I2C_STANDARD 10
-#define OMAP_I2C_FAST_MODE 40
-#define OMAP_I2C_HIGH_SPEED340
-
#define SYSTEM_CLOCK_121200
#define SYSTEM_CLOCK_131300
#define SYSTEM_CLOCK_192 1920
--
2.24.1.735.g03f4e72817-goog
Re: [PATCH 1/5] video: x86: Enable 32-bit graphics by default
Hi all, On Fri, 3 Jan 2020 23:41:49 +0800 Bin Meng bmeng...@gmail.com wrote: > Hi Simon, > > On Fri, Jan 3, 2020 at 11:24 AM Simon Glass wrote: > > > > Hi Bin, > > > > On Thu, 2 Jan 2020 at 19:41, Bin Meng wrote: > > > > > > Hi Simon, > > > > > > On Fri, Jan 3, 2020 at 10:30 AM Simon Glass wrote: > > > > > > > > Hi Anatolij, > > > > > > > > On Thu, 2 Jan 2020 at 07:34, Anatolij Gustschin wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Fri, 20 Dec 2019 18:10:33 -0700 > > > > > Simon Glass s...@chromium.org wrote: > > > > > > > > > > > Most x86 boards that use video make use of 32bpp graphics. Enable > > > > > > this by > > > > > > default. This fixes missing graphics output on some x86 boards. > > > > > > > > > > Must this patch be applied for v2010.01 release? > > > > > > > > I think so since these boards don't work for me at present. > > > > > > > > What do you think, Bin? > > > > > > > > > > Which board is currently broken due to missing this config? Should it > > > be safer to move this to board defconfig? > > > > I think any x86 board with graphics would need this. Those that don't > > enable VIDEO won't get the change anyway. > > OK, thanks. I had a test with QEMU x86 and looks good. > > Reviewed-by: Bin Meng > Tested-by: Bin Meng Thanks for testing. I've submitted a pull request for this series and Tom already merged the patches in master. -- Anatolij
[PATCH v3] board/lx2160aqds: Update the DSPI status fixup
The dts node of the DSPI controller in kernel is spi instead of dspi,
it is not correct if use "/soc/dspi@" to fix up the status of the dts
in kernel, so, modify it to "/soc/spi@".
The DSPI2 and I2C5 are muxed, and the status of DSPI2 node in kernel dts
default value is okay, set the status of DSPI2 node is disabled if it
used to I2C5.
Signed-off-by: Xiaowei Bao
---
v2:
- Modify the subject and commit message.
v3:
- Modify the Copyright.
board/freescale/lx2160a/lx2160a.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index eff5d9f..184e111 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2018-2019 NXP
+ * Copyright 2018-2020 NXP
*/
#include
@@ -210,9 +210,9 @@ void esdhc_dspi_status_fixup(void *blob)
{
const char esdhc0_path[] = "/soc/esdhc@214";
const char esdhc1_path[] = "/soc/esdhc@215";
- const char dspi0_path[] = "/soc/dspi@210";
- const char dspi1_path[] = "/soc/dspi@211";
- const char dspi2_path[] = "/soc/dspi@212";
+ const char dspi0_path[] = "/soc/spi@210";
+ const char dspi1_path[] = "/soc/spi@211";
+ const char dspi2_path[] = "/soc/spi@212";
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
u32 sdhc1_base_pmux;
@@ -262,10 +262,12 @@ void esdhc_dspi_status_fixup(void *blob)
& FSL_CHASSIS3_IIC5_PMUX_MASK;
iic5_pmux >>= FSL_CHASSIS3_IIC5_PMUX_SHIFT;
- if (iic5_pmux == IIC5_PMUX_SPI3) {
+ if (iic5_pmux == IIC5_PMUX_SPI3)
do_fixup_by_path(blob, dspi2_path, "status", "okay",
sizeof("okay"), 1);
- }
+ else
+ do_fixup_by_path(blob, dspi2_path, "status", "disabled",
+sizeof("disabled"), 1);
}
#endif
--
2.9.5
[PATCH v2 09/19] i2c: designware_i2c: Drop scl_sda_cfg parameter
Instead of passing this parameter into __dw_i2c_set_bus_speed(), pass in
the driver's private data, from which the function can obtain that
information. This allows the function to have access to the full state of
the driver.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/designware_i2c.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 34b6816545..6e5545cd0c 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -52,17 +52,20 @@ static int dw_i2c_enable(struct i2c_regs *i2c_base, bool
enable)
*
* Set the i2c speed.
*/
-static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs *i2c_base,
- struct dw_scl_sda_cfg *scl_sda_cfg,
+static unsigned int __dw_i2c_set_bus_speed(struct dw_i2c *priv,
+ struct i2c_regs *i2c_base,
unsigned int speed,
unsigned int bus_clk)
{
+ const struct dw_scl_sda_cfg *scl_sda_cfg = NULL;
ulong bus_khz = bus_clk / 1000;
enum i2c_speed_mode i2c_spd;
unsigned int cntl;
unsigned int hcnt, lcnt;
unsigned int ena;
+ if (priv)
+ scl_sda_cfg = priv->scl_sda_cfg;
/* Allow high speed if there is no config, or the config allows it */
if (speed >= I2C_HIGH_SPEED &&
(!scl_sda_cfg || scl_sda_cfg->has_high_speed))
@@ -371,7 +374,7 @@ static int __dw_i2c_init(struct i2c_regs *i2c_base, int
speed, int slaveaddr)
writel(IC_TX_TL, &i2c_base->ic_tx_tl);
writel(IC_STOP_DET, &i2c_base->ic_intr_mask);
#ifndef CONFIG_DM_I2C
- __dw_i2c_set_bus_speed(i2c_base, NULL, speed, IC_CLK);
+ __dw_i2c_set_bus_speed(NULL, i2c_base, speed, IC_CLK);
writel(slaveaddr, &i2c_base->ic_sar);
#endif
@@ -416,7 +419,7 @@ static unsigned int dw_i2c_set_bus_speed(struct i2c_adapter
*adap,
unsigned int speed)
{
adap->speed = speed;
- return __dw_i2c_set_bus_speed(i2c_get_base(adap), NULL, speed, IC_CLK);
+ return __dw_i2c_set_bus_speed(NULL, i2c_get_base(adap), speed, IC_CLK);
}
static void dw_i2c_init(struct i2c_adapter *adap, int speed, int slaveaddr)
@@ -515,8 +518,7 @@ static int designware_i2c_set_bus_speed(struct udevice
*bus, unsigned int speed)
#else
rate = IC_CLK;
#endif
- return __dw_i2c_set_bus_speed(i2c->regs, i2c->scl_sda_cfg, speed,
- rate);
+ return __dw_i2c_set_bus_speed(i2c, i2c->regs, speed, rate);
}
static int designware_i2c_probe_chip(struct udevice *bus, uint chip_addr,
--
2.24.1.735.g03f4e72817-goog
[PATCH v2 18/19] i2c: stm32: Update to use standard enums for speed
Update this driver to use the new standard enums for speed.
Note: This driver needs to move to driver model.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/stm32f7_i2c.c | 43 +++
1 file changed, 16 insertions(+), 27 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 2b18735fea..def84f2e0a 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -115,17 +115,6 @@ struct stm32_i2c_regs {
#define STM32_NSEC_PER_SEC 10L
-#define STANDARD_RATE 10
-#define FAST_RATE 40
-#define FAST_PLUS_RATE 100
-
-enum stm32_i2c_speed {
- STM32_I2C_SPEED_STANDARD, /* 100 kHz */
- STM32_I2C_SPEED_FAST, /* 400 kHz */
- STM32_I2C_SPEED_FAST_PLUS, /* 1 MHz */
- STM32_I2C_SPEED_END,
-};
-
/**
* struct stm32_i2c_spec - private i2c specification timing
* @rate: I2C bus speed (Hz)
@@ -164,7 +153,7 @@ struct stm32_i2c_spec {
* @analog_filter: Analog filter delay (On/Off)
*/
struct stm32_i2c_setup {
- enum stm32_i2c_speed speed;
+ enum i2c_speed_mode speed;
u32 speed_freq;
u32 clock_src;
u32 rise_time;
@@ -198,8 +187,8 @@ struct stm32_i2c_priv {
};
static const struct stm32_i2c_spec i2c_specs[] = {
- [STM32_I2C_SPEED_STANDARD] = {
- .rate = STANDARD_RATE,
+ [IC_SPEED_MODE_STANDARD] = {
+ .rate = I2C_SPEED_STANDARD_RATE,
.rate_min = 8000,
.rate_max = 12,
.fall_max = 300,
@@ -210,8 +199,8 @@ static const struct stm32_i2c_spec i2c_specs[] = {
.l_min = 4700,
.h_min = 4000,
},
- [STM32_I2C_SPEED_FAST] = {
- .rate = FAST_RATE,
+ [IC_SPEED_MODE_FAST] = {
+ .rate = I2C_SPEED_FAST_RATE,
.rate_min = 32,
.rate_max = 48,
.fall_max = 300,
@@ -222,8 +211,8 @@ static const struct stm32_i2c_spec i2c_specs[] = {
.l_min = 1300,
.h_min = 600,
},
- [STM32_I2C_SPEED_FAST_PLUS] = {
- .rate = FAST_PLUS_RATE,
+ [IC_SPEED_MODE_FAST_PLUS] = {
+ .rate = I2C_SPEED_FAST_PLUS_RATE,
.rate_min = 80,
.rate_max = 120,
.fall_max = 100,
@@ -648,9 +637,9 @@ static int stm32_i2c_compute_timing(struct stm32_i2c_priv
*i2c_priv,
struct list_head solutions;
int ret;
- if (setup->speed >= STM32_I2C_SPEED_END) {
+ if (setup->speed >= IC_SPEED_MODE_HIGH) {
pr_err("%s: speed out of bound {%d/%d}\n", __func__,
- setup->speed, STM32_I2C_SPEED_END - 1);
+ setup->speed, IC_SPEED_MODE_FAST_PLUS);
return -EINVAL;
}
@@ -719,7 +708,7 @@ static int stm32_i2c_setup_timing(struct stm32_i2c_priv
*i2c_priv,
if (ret) {
debug("%s: failed to compute I2C timings.\n",
__func__);
- if (i2c_priv->speed > STM32_I2C_SPEED_STANDARD) {
+ if (i2c_priv->speed > IC_SPEED_MODE_STANDARD) {
i2c_priv->speed--;
setup->speed = i2c_priv->speed;
setup->speed_freq =
@@ -784,14 +773,14 @@ static int stm32_i2c_set_bus_speed(struct udevice *bus,
unsigned int speed)
struct stm32_i2c_priv *i2c_priv = dev_get_priv(bus);
switch (speed) {
- case STANDARD_RATE:
- i2c_priv->speed = STM32_I2C_SPEED_STANDARD;
+ case I2C_SPEED_STANDARD_RATE:
+ i2c_priv->speed = IC_SPEED_MODE_STANDARD;
break;
- case FAST_RATE:
- i2c_priv->speed = STM32_I2C_SPEED_FAST;
+ case I2C_SPEED_FAST_RATE:
+ i2c_priv->speed = IC_SPEED_MODE_FAST;
break;
- case FAST_PLUS_RATE:
- i2c_priv->speed = STM32_I2C_SPEED_FAST_PLUS;
+ case I2C_SPEED_FAST_PLUS_RATE:
+ i2c_priv->speed = IC_SPEED_MODE_FAST_PLUS;
break;
default:
debug("%s: Speed %d not supported\n", __func__, speed);
--
2.24.1.735.g03f4e72817-goog
Re: [PATCH 0/5] video: Avoid #ifdef to increase build coverage
Hi Simon, On Fri, 20 Dec 2019 18:10:32 -0700 Simon Glass s...@chromium.org wrote: ... > Simon Glass (5): > video: x86: Enable 32-bit graphics by default > video: Avoid using #ifdef in video blitting code > video: Avoid using #ifdef in console_rotate.c > video: Avoid using #ifdef in vidconsole-uclass.c > video: Avoid using #ifdef in video-uclass.c > > drivers/video/Kconfig | 5 +- > drivers/video/console_normal.c| 125 ++-- > drivers/video/console_rotate.c| 325 +++--- > drivers/video/vidconsole-uclass.c | 22 +- > drivers/video/video-uclass.c | 54 +++-- > 5 files changed, 256 insertions(+), 275 deletions(-) Series applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH] video: add wrappers for ttf type files to .gitignore
On Tue, 31 Dec 2019 18:09:14 +0100 Dario Binacchi dario...@libero.it wrote: > drivers/video/fonts/.gitignore | 1 + > 1 file changed, 1 insertion(+) > create mode 100644 drivers/video/fonts/.gitignore Applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH] test: Fix the boardspec for the SPL handoff test
On Fri, Dec 27, 2019 at 07:46:30AM -0700, Simon Glass wrote: > This test currently does not run because it specifies the sandbox board > instead of sandbox_spl. Fix it. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] test_env: don't strip() printenv results
On Wed, Dec 18, 2019 at 11:37:21AM -0700, Stephen Warren wrote: > From: Stephen Warren > > get_env() was originally written to strip() the output of printenv to > isolate the test from any whitespace changes in printenv's output. > However, this throws away any whitespace in the variable value, which can > cause issues when test code expects to see that whitespace. In fact, > printenv never adds any whitespace at all, so there's no need to strip. > > The strip causes a practical problem for test_env_echo_exists() if > state_test_env.get_existent_var() happens to choose a U-Boot variable that > contains trailing whitespace. This is true for variable boot_targets. > > With Python 2, get_existent_var() never returned boot_targets so this > issue never caused a practical problem. > > With Python 3, get_existent_var does sometimes return boot_targets, no > doubt due to Python 3's different dict hash key order implementation, > about 0.5-2% of the time, so this test appears intermittent. With the > strip removed, this intermittency is solved, since the test passes for all > possible U-Boot variables. > > Signed-off-by: Stephen Warren Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v2] board/lx2160aqds: Update the DSPI status fixup
The dts node of the DSPI controller in kernel is spi instead of dspi,
it is not correct if ues "/soc/dspi@" to fix up the status of the dts
in kernel, so, modify it to "/soc/spi@".
The DSPI2 and I2C5 are muxed, and the status of DSPI2 node in kernel dts
default value is okay, set the status of DSPI2 node is disabled if it
used to I2C5.
Signed-off-by: Xiaowei Bao
---
v2:
- Modify the subject and commit message.
board/freescale/lx2160a/lx2160a.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index eff5d9f..3d7cd8b 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -210,9 +210,9 @@ void esdhc_dspi_status_fixup(void *blob)
{
const char esdhc0_path[] = "/soc/esdhc@214";
const char esdhc1_path[] = "/soc/esdhc@215";
- const char dspi0_path[] = "/soc/dspi@210";
- const char dspi1_path[] = "/soc/dspi@211";
- const char dspi2_path[] = "/soc/dspi@212";
+ const char dspi0_path[] = "/soc/spi@210";
+ const char dspi1_path[] = "/soc/spi@211";
+ const char dspi2_path[] = "/soc/spi@212";
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
u32 sdhc1_base_pmux;
@@ -262,10 +262,12 @@ void esdhc_dspi_status_fixup(void *blob)
& FSL_CHASSIS3_IIC5_PMUX_MASK;
iic5_pmux >>= FSL_CHASSIS3_IIC5_PMUX_SHIFT;
- if (iic5_pmux == IIC5_PMUX_SPI3) {
+ if (iic5_pmux == IIC5_PMUX_SPI3)
do_fixup_by_path(blob, dspi2_path, "status", "okay",
sizeof("okay"), 1);
- }
+ else
+ do_fixup_by_path(blob, dspi2_path, "status", "disabled",
+sizeof("disabled"), 1);
}
#endif
--
2.9.5
Re: [PATCH 2/4] mmc: davinci: drop struct davinci_mmc_plat
On Thu, Nov 14, 2019 at 9:10 AM Bartosz Golaszewski wrote:
>
> From: Bartosz Golaszewski
>
> struct mmc_config & struct mmc don't need to be exported over platform
> data, but can instead be private in the driver.
>
> Remove struct davinci_mmc_plat.
This patch appears to break the da850-evm.
With the pending release of 2020.01, is there any way we can revert
before release and try to apply this going forward with more time to
test?
As of now, the da850-evm cannot read/write from the MMC card from
U-Boot which includes MMC booting.
adam
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/mmc/davinci_mmc.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
> index 370b18cc78..a27a039f9b 100644
> --- a/drivers/mmc/davinci_mmc.c
> +++ b/drivers/mmc/davinci_mmc.c
> @@ -32,10 +32,6 @@ struct davinci_mmc_priv {
> uint input_clk; /* Input clock to MMC controller */
> struct gpio_desc cd_gpio; /* Card Detect GPIO */
> struct gpio_desc wp_gpio; /* Write Protect GPIO */
> -};
> -
> -struct davinci_mmc_plat
> -{
> struct mmc_config cfg;
> struct mmc mmc;
> };
> @@ -484,9 +480,8 @@ int davinci_mmc_init(bd_t *bis, struct davinci_mmc *host)
> static int davinci_mmc_probe(struct udevice *dev)
> {
> struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> - struct davinci_mmc_plat *plat = dev_get_platdata(dev);
> struct davinci_mmc_priv *priv = dev_get_priv(dev);
> - struct mmc_config *cfg = &plat->cfg;
> + struct mmc_config *cfg = &priv->cfg;
>
> cfg->f_min = 20;
> cfg->f_max = 2500;
> @@ -504,16 +499,16 @@ static int davinci_mmc_probe(struct udevice *dev)
> gpio_request_by_name(dev, "wp-gpios", 0, &priv->wp_gpio, GPIOD_IS_IN);
> #endif
>
> - upriv->mmc = &plat->mmc;
> + upriv->mmc = &priv->mmc;
>
> return davinci_dm_mmc_init(dev);
> }
>
> static int davinci_mmc_bind(struct udevice *dev)
> {
> - struct davinci_mmc_plat *plat = dev_get_platdata(dev);
> + struct davinci_mmc_priv *priv = dev_get_priv(dev);
>
> - return mmc_bind(dev, &plat->mmc, &plat->cfg);
> + return mmc_bind(dev, &priv->mmc, &priv->cfg);
> }
>
> static const struct udevice_id davinci_mmc_ids[] = {
> @@ -530,7 +525,6 @@ U_BOOT_DRIVER(davinci_mmc_drv) = {
> #endif
> .probe = davinci_mmc_probe,
> .ops = &davinci_mmc_ops,
> - .platdata_auto_alloc_size = sizeof(struct davinci_mmc_plat),
> .priv_auto_alloc_size = sizeof(struct davinci_mmc_priv),
> };
> #endif
> --
> 2.23.0
>
[PATCH v2 14/19] i2c: ast_i2c: Update to use standard enums for speed
Update this driver to use the new standard enums for speed.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/ast_i2c.c | 2 +-
drivers/i2c/ast_i2c.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/ast_i2c.c b/drivers/i2c/ast_i2c.c
index 763183d649..35dc234160 100644
--- a/drivers/i2c/ast_i2c.c
+++ b/drivers/i2c/ast_i2c.c
@@ -314,7 +314,7 @@ static int ast_i2c_set_speed(struct udevice *dev, unsigned
int speed)
divider = i2c_rate / speed;
priv->speed = speed;
- if (speed > I2C_HIGHSPEED_RATE) {
+ if (speed > I2C_SPEED_FAST_RATE) {
debug("Enable High Speed\n");
setbits_le32(®s->fcr, I2CD_M_HIGH_SPEED_EN
| I2CD_M_SDA_DRIVE_1T_EN
diff --git a/drivers/i2c/ast_i2c.h b/drivers/i2c/ast_i2c.h
index 401e0970f7..928785989e 100644
--- a/drivers/i2c/ast_i2c.h
+++ b/drivers/i2c/ast_i2c.h
@@ -126,6 +126,4 @@ struct ast_i2c_regs {
#define I2CD_RX_DATA_SHIFT 8
#define I2CD_RX_DATA_MASK (0xff << I2CD_RX_DATA_SHIFT)
-#define I2C_HIGHSPEED_RATE40
-
#endif /* __AST_I2C_H_ */
--
2.24.1.735.g03f4e72817-goog
Re: [PATCH] Revert "mmc: davinci: drop struct davinci_mmc_plat"
On Fri, Jan 3, 2020 at 12:17 PM Tom Rini wrote:
>
> Adam Ford reports that this change breaks booting on da850-evm and
> Bartosz Golaszewski agrees that with the impending release we should
> revert the change for now. With that noted:
>
> This reverts commit 21a4d80a710c79053ac1deaa65ff9b69e6c031d4.
>
Tested-by: Adam Ford
> Cc: Adam Ford
> Cc: Bartosz Golaszewski
> Signed-off-by: Tom Rini
> ---
> drivers/mmc/davinci_mmc.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
> index c3f7b57665d3..ef5cd4e7234f 100644
> --- a/drivers/mmc/davinci_mmc.c
> +++ b/drivers/mmc/davinci_mmc.c
> @@ -32,6 +32,10 @@ struct davinci_mmc_priv {
> uint input_clk; /* Input clock to MMC controller */
> struct gpio_desc cd_gpio; /* Card Detect GPIO */
> struct gpio_desc wp_gpio; /* Write Protect GPIO */
> +};
> +
> +struct davinci_mmc_plat
> +{
> struct mmc_config cfg;
> struct mmc mmc;
> };
> @@ -480,8 +484,9 @@ int davinci_mmc_init(bd_t *bis, struct davinci_mmc *host)
> static int davinci_mmc_probe(struct udevice *dev)
> {
> struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct davinci_mmc_plat *plat = dev_get_platdata(dev);
> struct davinci_mmc_priv *priv = dev_get_priv(dev);
> - struct mmc_config *cfg = &priv->cfg;
> + struct mmc_config *cfg = &plat->cfg;
> #ifdef CONFIG_SPL_BUILD
> int ret;
> #endif
> @@ -502,7 +507,7 @@ static int davinci_mmc_probe(struct udevice *dev)
> gpio_request_by_name(dev, "wp-gpios", 0, &priv->wp_gpio, GPIOD_IS_IN);
> #endif
>
> - upriv->mmc = &priv->mmc;
> + upriv->mmc = &plat->mmc;
>
> #ifdef CONFIG_SPL_BUILD
> /*
> @@ -513,7 +518,7 @@ static int davinci_mmc_probe(struct udevice *dev)
> * support in SPL, hence the hard-coded base register address.
> */
> priv->reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE;
> - ret = mmc_bind(dev, &priv->mmc, &priv->cfg);
> + ret = mmc_bind(dev, &plat->mmc, &plat->cfg);
> if (ret)
> return ret;
> #endif
> @@ -523,9 +528,9 @@ static int davinci_mmc_probe(struct udevice *dev)
>
> static int davinci_mmc_bind(struct udevice *dev)
> {
> - struct davinci_mmc_priv *priv = dev_get_priv(dev);
> + struct davinci_mmc_plat *plat = dev_get_platdata(dev);
>
> - return mmc_bind(dev, &priv->mmc, &priv->cfg);
> + return mmc_bind(dev, &plat->mmc, &plat->cfg);
> }
>
> static const struct udevice_id davinci_mmc_ids[] = {
> @@ -542,6 +547,7 @@ U_BOOT_DRIVER(davinci_mmc_drv) = {
> #endif
> .probe = davinci_mmc_probe,
> .ops = &davinci_mmc_ops,
> + .platdata_auto_alloc_size = sizeof(struct davinci_mmc_plat),
> .priv_auto_alloc_size = sizeof(struct davinci_mmc_priv),
> };
> #endif
> --
> 2.17.1
>
[PATCH v2 02/19] i2c: designware_i2c: Don't allow changing IC_CLK
If a different input clock is required then the correct way to do this is
with a clock driver. Don't allow boards to override IC_CLK.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/designware_i2c.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/designware_i2c.h b/drivers/i2c/designware_i2c.h
index d359c8c3f8..0eb28191d2 100644
--- a/drivers/i2c/designware_i2c.h
+++ b/drivers/i2c/designware_i2c.h
@@ -58,9 +58,7 @@ struct i2c_regs {
u32 comp_type;
};
-#if !defined(IC_CLK)
#define IC_CLK 166
-#endif
#define NANO_TO_MICRO 1000
/* High and low times in different speed modes (in ns) */
--
2.24.1.735.g03f4e72817-goog
[PATCH] Revert "mmc: davinci: drop struct davinci_mmc_plat"
Adam Ford reports that this change breaks booting on da850-evm and
Bartosz Golaszewski agrees that with the impending release we should
revert the change for now. With that noted:
This reverts commit 21a4d80a710c79053ac1deaa65ff9b69e6c031d4.
Cc: Adam Ford
Cc: Bartosz Golaszewski
Signed-off-by: Tom Rini
---
drivers/mmc/davinci_mmc.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
index c3f7b57665d3..ef5cd4e7234f 100644
--- a/drivers/mmc/davinci_mmc.c
+++ b/drivers/mmc/davinci_mmc.c
@@ -32,6 +32,10 @@ struct davinci_mmc_priv {
uint input_clk; /* Input clock to MMC controller */
struct gpio_desc cd_gpio; /* Card Detect GPIO */
struct gpio_desc wp_gpio; /* Write Protect GPIO */
+};
+
+struct davinci_mmc_plat
+{
struct mmc_config cfg;
struct mmc mmc;
};
@@ -480,8 +484,9 @@ int davinci_mmc_init(bd_t *bis, struct davinci_mmc *host)
static int davinci_mmc_probe(struct udevice *dev)
{
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+ struct davinci_mmc_plat *plat = dev_get_platdata(dev);
struct davinci_mmc_priv *priv = dev_get_priv(dev);
- struct mmc_config *cfg = &priv->cfg;
+ struct mmc_config *cfg = &plat->cfg;
#ifdef CONFIG_SPL_BUILD
int ret;
#endif
@@ -502,7 +507,7 @@ static int davinci_mmc_probe(struct udevice *dev)
gpio_request_by_name(dev, "wp-gpios", 0, &priv->wp_gpio, GPIOD_IS_IN);
#endif
- upriv->mmc = &priv->mmc;
+ upriv->mmc = &plat->mmc;
#ifdef CONFIG_SPL_BUILD
/*
@@ -513,7 +518,7 @@ static int davinci_mmc_probe(struct udevice *dev)
* support in SPL, hence the hard-coded base register address.
*/
priv->reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE;
- ret = mmc_bind(dev, &priv->mmc, &priv->cfg);
+ ret = mmc_bind(dev, &plat->mmc, &plat->cfg);
if (ret)
return ret;
#endif
@@ -523,9 +528,9 @@ static int davinci_mmc_probe(struct udevice *dev)
static int davinci_mmc_bind(struct udevice *dev)
{
- struct davinci_mmc_priv *priv = dev_get_priv(dev);
+ struct davinci_mmc_plat *plat = dev_get_platdata(dev);
- return mmc_bind(dev, &priv->mmc, &priv->cfg);
+ return mmc_bind(dev, &plat->mmc, &plat->cfg);
}
static const struct udevice_id davinci_mmc_ids[] = {
@@ -542,6 +547,7 @@ U_BOOT_DRIVER(davinci_mmc_drv) = {
#endif
.probe = davinci_mmc_probe,
.ops = &davinci_mmc_ops,
+ .platdata_auto_alloc_size = sizeof(struct davinci_mmc_plat),
.priv_auto_alloc_size = sizeof(struct davinci_mmc_priv),
};
#endif
--
2.17.1
[PATCH v2 04/19] i2c: designware_i2c: Rename 'max' speed to 'high' speed
Some SoCs support a higher speed than what is currently called 'max' in
this driver. Rename it to 'high' speed, which is the official name of the
3.4MHz speed.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/designware_i2c.c | 10 +-
drivers/i2c/designware_i2c.h | 8
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 138fc72561..dd1cc0b823 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -62,10 +62,10 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs
*i2c_base,
unsigned int ena;
int i2c_spd;
- /* Allow max speed if there is no config, or the config allows it */
- if (speed >= I2C_MAX_SPEED &&
- (!scl_sda_cfg || scl_sda_cfg->has_max_speed))
- i2c_spd = IC_SPEED_MODE_MAX;
+ /* Allow high speed if there is no config, or the config allows it */
+ if (speed >= I2C_HIGH_SPEED &&
+ (!scl_sda_cfg || scl_sda_cfg->has_high_speed))
+ i2c_spd = IC_SPEED_MODE_HIGH;
else if (speed >= I2C_FAST_SPEED)
i2c_spd = IC_SPEED_MODE_FAST;
else
@@ -80,7 +80,7 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs
*i2c_base,
cntl = (readl(&i2c_base->ic_con) & (~IC_CON_SPD_MSK));
switch (i2c_spd) {
- case IC_SPEED_MODE_MAX:
+ case IC_SPEED_MODE_HIGH:
cntl |= IC_CON_SPD_SS;
if (scl_sda_cfg) {
hcnt = scl_sda_cfg->fs_hcnt;
diff --git a/drivers/i2c/designware_i2c.h b/drivers/i2c/designware_i2c.h
index 39e62bcf51..fcb7dde83a 100644
--- a/drivers/i2c/designware_i2c.h
+++ b/drivers/i2c/designware_i2c.h
@@ -137,16 +137,16 @@ struct i2c_regs {
/* Speed Selection */
#define IC_SPEED_MODE_STANDARD 1
#define IC_SPEED_MODE_FAST 2
-#define IC_SPEED_MODE_MAX 3
+#define IC_SPEED_MODE_HIGH 3
-#define I2C_MAX_SPEED 340
+#define I2C_HIGH_SPEED 340
#define I2C_FAST_SPEED 40
#define I2C_STANDARD_SPEED 10
/**
* struct dw_scl_sda_cfg - I2C timing configuration
*
- * @has_max_speed: Support maximum speed (1Mbps)
+ * @has_high_speed: Support high speed (3.4Mbps)
* @ss_hcnt: Standard speed high time in ns
* @fs_hcnt: Fast speed high time in ns
* @ss_lcnt: Standard speed low time in ns
@@ -154,7 +154,7 @@ struct i2c_regs {
* @sda_hold: SDA hold time
*/
struct dw_scl_sda_cfg {
- bool has_max_speed;
+ bool has_high_speed;
u32 ss_hcnt;
u32 fs_hcnt;
u32 ss_lcnt;
--
2.24.1.735.g03f4e72817-goog
[U-Boot] [PATCH 1/4] arm: mxs: fix register definitions for clkctrl_gpmi and clkctrl_sspX
> I tried clearing a bit by writing to hw_clkctrl_gpmi_clr, then > busy-waiting for it to actually clear. My board hung. The data sheet > agrees, these registers do not have _set, _clr, _tog, so fix up the > definitions. git grep -E 'clkctrl_(gpmi|ssp[0-9])_' says that nobody > uses those non-existing ops registers. > Signed-off-by: Rasmus Villemoes Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v3] mach-imx: bootaux: elf firmware support
> From: Igor Opaniuk
> Currently imx-specific bootaux command doesn't support ELF format
> firmware for Cortex-M4 core.
> This patches introduces a PoC implementation of handling elf firmware
> (load_elf_image_phdr() was copy-pasted from elf.c just for PoC).
> ELF64 binaries isn't supported yet.
> This has the advantage that the user does not need to know to which
> address the binary has been linked to. However, in order to handle
> and load the elf sections to the right address, we need to translate the
> Cortex-M4 core memory addresses to primary/host CPU memory
> addresses (Cortex A7/A9 cores).
> This allows to boot firmwares from any location with just using
> bootaux, e.g.:
> > tftp ${loadaddr} hello_world.elf && bootaux ${loadaddr}
> Similar translation table can be found in the Linux remoteproc
> driver [1].
> [1]
> https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/imx_rproc.c
> Signed-off-by: Igor Opaniuk
> Signed-off-by: Stefan Agner
> Reviewed-by: Oleksandr Suvorov
Applied to u-boot-imx, -next, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
[PATCH 2/3] mx6sllevk: Fix the pmic_get() parameter in the DM case
> When pmic_get() is used with DM the first parameter must be > the complete node name plus the unit address, so fix it > accordingly. > Reported-by: Igor Opaniuk > Signed-off-by: Fabio Estevam > Reviewed-by: Peng Fan Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[U-Boot] [PATCH 3/4] arm: mxs: be more careful when enabling gpmi_clk
> The data sheet says that the DIV field cannot change while the CLKGATE > bit is set or modified. So do it a little more carefully, by first > clearing the bit, waiting for that to appear, then setting the DIV > field. > Signed-off-by: Rasmus Villemoes Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH] ddr: imx8m: Return error values from LPDDR4 training
> From: Frieder Schrempf > In cases when the same SPL should run on boards with i.MX8MM, that > differ in DDR configuration, it is necessary to try different > parameters and check if the training done by the firmware suceeds or > not. > Therefore we return the DDR training/initialization success to the > upper layer in order to be able to retry with different settings if > necessary. > Signed-off-by: Frieder Schrempf Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH] imx8mm_evk: Adjust the environment for booting a mainline kernel
> Adjust the environment for booting a mainline kernel by default. > Signed-off-by: Fabio Estevam > Reviewed-by: Peng Fan Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH 3/3] mx6slevk: Fix the pmic_get() parameter in the DM case
> When pmic_get() is used with DM the first parameter must be > the complete node name plus the unit address, so fix it > accordingly. > Reported-by: Igor Opaniuk > Signed-off-by: Fabio Estevam > Reviewed-by: Peng Fan Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v1] mach-imx: nandbcb: improve cmd help
> From: Igor Opaniuk > Add info about supported i.MX7, improve details the usage of > bcbonly subcommand. > Signed-off-by: Igor Opaniuk > Reviewed-by: Oleksandr Suvorov Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH 1/3] mx7dsabresd: Fix the pmic_get() parameter in the DM case
> When pmic_get() is used with DM the first parameter must be > the complete node name plus the unit address, so fix it > accordingly. > Reported-by: Igor Opaniuk > Signed-off-by: Fabio Estevam > Reviewed-by: Peng Fan Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[U-Boot] [PATCH 2/4] arm: mxs: fix comments in arch_cpu_init to match the code
> The comment says to clear the bypass bit, but in fact it sets it, thus > selecting ref_xtal. And the next line of code does not set the divider > to 12, but to (the reset value of) 1. > Signed-off-by: Rasmus Villemoes Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Re: [PATCH 1/5] video: x86: Enable 32-bit graphics by default
Hi Bin, On Thu, 2 Jan 2020 at 19:41, Bin Meng wrote: > > Hi Simon, > > On Fri, Jan 3, 2020 at 10:30 AM Simon Glass wrote: > > > > Hi Anatolij, > > > > On Thu, 2 Jan 2020 at 07:34, Anatolij Gustschin wrote: > > > > > > Hi Simon, > > > > > > On Fri, 20 Dec 2019 18:10:33 -0700 > > > Simon Glass s...@chromium.org wrote: > > > > > > > Most x86 boards that use video make use of 32bpp graphics. Enable this > > > > by > > > > default. This fixes missing graphics output on some x86 boards. > > > > > > Must this patch be applied for v2010.01 release? > > > > I think so since these boards don't work for me at present. > > > > What do you think, Bin? > > > > Which board is currently broken due to missing this config? Should it > be safer to move this to board defconfig? I think any x86 board with graphics would need this. Those that don't enable VIDEO won't get the change anyway. Regards, Simon
[PATCH] arm: imx: Default to SYS_THUMB_BUILD for i.MX6/7
> In the case of i.MX6 and i.MX7 family SoCs it is safe (from an errata > point of view) to use thumb2 by default to save space. > Cc: Stefano Babic > Cc: Fabio Estevam > Signed-off-by: Tom Rini > Reviewed-by: Fabio Estevam Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH] tools: imx8m_image: Change source path for DDR firmware to build dir
> From: Frieder Schrempf > The DDR firmware binaries are not part of the U-Boot source code, so > we should look for them in the build directory, where they need to be > copied to before building U-Boot. > The ATF binary is already fetched from the build directory, but the > README files for the i.MX8M EVKs claim that it needs to be copied to > the source directory (which is still true for in-tree builds, but not > in general). Therefore we also fix the READMEs to use the build > directory as the correct location for all additional binary files. > Sined-off-by: Frieder Schrempf Applied to u-boot-imx, -next, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Re: [PATCH] [ARM] arch/arm/Kconfig: typo/grammar/punctuation fixes
On Wed, Dec 25, 2019 at 06:34:07AM -0500, Robert P. J. Day wrote: > Various (mostly minor) spelling, grammar and punctuation tweaks for > arch/arm/Kconfig. > > Signed-off-by: Robert P. J. Day > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index f9dab073ea..36c9c2fecd 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/1] travis-ci: provide env__efi_fit_tftp_file
On 1/2/20 6:05 PM, Stephen Warren wrote:
On 12/31/19 3:42 AM, Cristian Ciocaltea wrote:
On Mon, Dec 30, 2019 at 09:03:38PM +0100, Heinrich Schuchardt wrote:
On 12/30/19 8:32 PM, Stephen Warren wrote:
On 12/30/19 12:05 PM, Heinrich Schuchardt wrote:
On 12/30/19 5:38 PM, Stephen Warren wrote:
On 12/30/19 3:52 AM, Heinrich Schuchardt wrote:
Provide dictionary env__efi_fit_tftp_file describing the file
used for
the
UEFI FIT image test.
diff --git a/py/travis-ci/travis_tftp.py
b/py/travis-ci/travis_tftp.py
+def efifit2env(addr=None):
+ """Create dictionary describing file for EFI fit image test
+
+ @addr: address used for loading the file as int (e.g.
0x4040)
+ Return: dictionary describing the file with entries
+ * fn - filename
+ * addr - loading address, optional
+ * dn - tftp directory
+ """
+ tftp_dir = os.environ['UBOOT_TRAVIS_BUILD_DIR']
+
+ ret = {
+ "fn": "test-efi-fit.img",
If this function were to exist, then the filename shouldn't be
hard-coded; it should be a parameter.
Hello Stephen,
thanks for reviewing.
This is the name of a generated file. It does not depend on the board.
What generates the file and when/why?
Generated files should generally be put into
u_boot_console.config.persistent_data_dir, and presumably the name
hard-coded into the test that uses it.
Hello Stephen,
this is the test case:
https://lists.denx.de/pipermail/u-boot/2019-December/394957.html
test/py: Create a test for launching UEFI binaries from FIT images
The test can be run in different styles:
* A complete FIT image can be supplied. In this case the dictionary
must contain a "size" entry.
* The test can generate a FIT image from lib/efi_loader/helloworld.efi.
In this case no "size" entry shall be supplied. The "fn" field
provides the name of the generated file. The file is generated in
cons.config.build_dir. The "dn" field" describes the tFTP root
directory to which the generated file is copied.
A small correction here: if the "size" entry is not provided in the
dictionary, the test generates a FIT image using a hardcoded file
name (test-efi-fit-helloworld.fit), so any "fn" entry provided in the
dictionary is ignored in this case.
Why does the size parameter affect whether the file name parameter is
used? This test sounds like it's doing very odd things with
configuration...
I'd propose removing the size and filename parameters completely, and
instead just telling the test where the TFTP directory is. Then, we
don't need any common function at all.
We will need addr too.
I was wrong in assuming a filename was needed. If size is not provided
to the test, it defaults to filename 'test-efi-fit-helloworld.fit'.
Also, if we do keep a function, then "efifit2env" is a really bad name;
this function is just generating some configuration data, not converting
anything, hence "2" or "to" in the function name doesn't make sense.
I will update the patch accordingly. Thanks for reviewing.
Best regards
Heinrich
[PATCH 1/1] efi_loader: free load options after execution
When be launch a binary via bootefi the bootargs environment variable is
used to set the load options in the loaded image protocol.
Free memory allocated for load options when the UEFI binary exits.
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c | 53 ---
1 file changed, 21 insertions(+), 32 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 78c8b8dbd1..bb8224437e 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -28,11 +28,13 @@ static struct efi_device_path *bootefi_device_path;
/**
* Set the load options of an image from an environment variable.
*
- * @handle:the image handle
- * @env_var: name of the environment variable
- * Return: status code
+ * @handle:the image handle
+ * @env_var: name of the environment variable
+ * @load_options: pointer to load options (output)
+ * Return: status code
*/
-static efi_status_t set_load_options(efi_handle_t handle, const char *env_var)
+static efi_status_t set_load_options(efi_handle_t handle, const char *env_var,
+u16 **load_options)
{
struct efi_loaded_image *loaded_image_info;
size_t size;
@@ -40,6 +42,7 @@ static efi_status_t set_load_options(efi_handle_t handle,
const char *env_var)
u16 *pos;
efi_status_t ret;
+ *load_options = NULL;
ret = EFI_CALL(systab.boottime->open_protocol(
handle,
&efi_guid_loaded_image,
@@ -64,6 +67,7 @@ static efi_status_t set_load_options(efi_handle_t handle,
const char *env_var)
return EFI_OUT_OF_RESOURCES;
}
pos = loaded_image_info->load_options;
+ *load_options = pos;
utf8_utf16_strcpy(&pos, env);
loaded_image_info->load_options_size = size * 2;
@@ -298,9 +302,10 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle)
efi_status_t ret;
efi_uintn_t exit_data_size = 0;
u16 *exit_data = NULL;
+ u16 *load_options;
/* Transfer environment variable as load options */
- ret = set_load_options(handle, "bootargs");
+ ret = set_load_options(handle, "bootargs", &load_options);
if (ret != EFI_SUCCESS)
return ret;
@@ -314,12 +319,7 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle)
efi_restore_gd();
- /*
-* FIXME: Who is responsible for
-* free(loaded_image_info->load_options);
-* Once efi_exit() is implemented correctly,
-* handle itself doesn't exist here.
-*/
+ free(load_options);
return ret;
}
--
2.24.1
Re: [PATCH] dm: Add a debug message when devices are skipped pre-reloc
On Wed, Dec 25, 2019 at 12:52 PM Sean Anderson wrote: > > This adds a message to lists_bind_fdt when it skips initializing a device > pre-relocation. I've had a couple errors where a device didn't initialize > properly because one of its dependencies was missing. > > Signed-off-by: Sean Anderson > --- > drivers/core/lists.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
[PATCH 1/1] efi_loader: define all known warning status codes
Of all warning status codes up to now only EFI_WARN_DELETE_FAILURE is
defined.
The patch adds the missing definitions for later usage.
Signed-off-by: Heinrich Schuchardt
---
.mailmap | 1 +
include/efi.h | 8 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index 98d2131e97..dec2abeffa 100644
--- a/.mailmap
+++ b/.mailmap
@@ -24,6 +24,7 @@ Boris Brezillon
Boris Brezillon
Dirk Behme
Fabio Estevam
+Heinrich Schuchardt
Jagan Teki <402ja...@gmail.com>
Jagan Teki
Jagan Teki
diff --git a/include/efi.h b/include/efi.h
index 5f415a99cc..e12697a5d5 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -91,7 +91,13 @@ typedef struct {
#define EFI_IP_ADDRESS_CONFLICT(EFI_ERROR_MASK | 34)
#define EFI_HTTP_ERROR (EFI_ERROR_MASK | 35)
-#define EFI_WARN_DELETE_FAILURE2
+#define EFI_WARN_UNKNOWN_GLYPH 1
+#define EFI_WARN_DELETE_FAILURE2
+#define EFI_WARN_WRITE_FAILURE 3
+#define EFI_WARN_BUFFER_TOO_SMALL 4
+#define EFI_WARN_STALE_DATA5
+#define EFI_WARN_FILE_SYSTEM 6
+#define EFI_WARN_RESET_REQUIRED7
typedef unsigned long efi_status_t;
typedef u64 efi_physical_addr_t;
--
2.24.1
Re: [PATCH] tools: .gitignore: add asn1_compiler
On Sun, Dec 29, 2019 at 01:44:18PM +0100, Dario Binacchi wrote: > Add the tool to the ignore list to prevent being marked as unversioned. > > Signed-off-by: Dario Binacchi > Reviewed-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/11] clk: Always use the supplied struct clk
+ Lukasz On Wed, Jan 1, 2020 at 4:12 AM Sean Anderson wrote: > > CCF clocks should always use the struct clock passed to their methods for > extracting the driver-specific clock information struct. Previously, many > functions would use the clk->dev->priv if the device was bound. This could > cause > problems with composite clocks. The individual clocks in a composite clock did > not have the ->dev field filled in. This was fine, because the device-specific > clock information would be used. However, since there was no ->dev, there was > no > way to get the parent clock. This caused the recalc_rate method of the CCF > divider clock to fail. One option would be to use the clk->priv field to get > the > composite clock and from there get the appropriate parent device. However, > this > would tie the implementation to the composite clock. In general, different > devices should not rely on the contents of ->priv from another device. > > The simple solution to this problem is to just always use the supplied struct > clock. The composite clock now fills in the ->dev pointer of its child clocks. > This allows child clocks to make calls like clk_get_parent() without issue. > > imx avoided the above problem by using a custom get_rate function with > composite > clocks. > > Signed-off-by: Sean Anderson > --- Acked-by: Jagan Teki
Re: [PATCH 8/8] ARM: dts: imx6qdli-icore: Add fec phy-handle
Hi Stefano,
On Fri, Jan 3, 2020 at 5:03 PM Stefano Babic wrote:
>
> Hi Jagan, Michael,
>
> On 31/12/19 07:21, Jagan Teki wrote:
> > On Mon, Dec 30, 2019 at 10:55 PM Michael Nazzareno Trimarchi
> > wrote:
> >>
> >> Hi
> >>
> >> On Mon, Dec 30, 2019 at 1:04 PM Jagan Teki
> >> wrote:
> >>>
> >>> From: Michael Trimarchi
> >>>
> >>> LAN8720 needs a reset of every clock enable. The reset needs
> >>> to be done at device level, due the flag PHY_RST_AFTER_CLK_EN.
> >>>
> >>> So, add phy-handle by creating mdio child node inside fec.
> >>> This will eventually move the phy-reset-gpio which is defined
> >>> in fec node.
> >>>
> >>> Signed-off-by: Michael Trimarchi
> >>> Signed-off-by: Jagan Teki
> >>> ---
> >>> arch/arm/dts/imx6qdl-icore.dtsi | 15 ++-
> >>> 1 file changed, 14 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/dts/imx6qdl-icore.dtsi
> >>> b/arch/arm/dts/imx6qdl-icore.dtsi
> >>> index 7814f1ef08..756f3a9f1b 100644
> >>> --- a/arch/arm/dts/imx6qdl-icore.dtsi
> >>> +++ b/arch/arm/dts/imx6qdl-icore.dtsi
> >>> @@ -150,10 +150,23 @@
> >>> &fec {
> >>> pinctrl-names = "default";
> >>> pinctrl-0 = <&pinctrl_enet>;
> >>> - phy-reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> >>> clocks = <&clks IMX6QDL_CLK_ENET>, <&clks IMX6QDL_CLK_ENET>,
> >>> <&rmii_clk>;
> >>> phy-mode = "rmii";
> >>> + phy-handle = <ð_phy>;
> >>> status = "okay";
> >>> +
> >>> + mdio {
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + eth_phy: ethernet-phy@0 {
> >>> + compatible = "ethernet-phy-ieee802.3-c22";
> >>> + reg = <0>;
> >>> + reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> >>> + reset-assert-us = <4000>;
> >>> + reset-deassert-us = <4000>;
> >>> + };
> >>> + };
> >>> };
> >>
> >> This work in linux but not in uboot. I don't think that we have this
> >> kind of connection.
> >
> > Okay. Missed to check will drop this from series.
> >
>
> So is it ok if I merge the series with the exception of 8/8 ?
Yes, please.
Re: [PATCH 0/4] arm: mxs: mxs_set_gpmiclk
Hi Rasmus, On 27/09/19 10:33, Rasmus Villemoes wrote: > On 12/09/2019 11.17, Rasmus Villemoes wrote: >> While trying to implement an mxs_set_gpmiclk() I stumbled on a few minor >> things. >> >> Rasmus Villemoes (4): >> arm: mxs: fix register definitions for clkctrl_gpmi and clkctrl_sspX >> arm: mxs: fix comments in arch_cpu_init to match the code >> arm: mxs: be more careful when enabling gpmi_clk >> arm: mxs: implement mxs_set_gpmiclk > > ping > You're right, patch was lost (..just because the list of patches for i.MX was very long and I have not seen..), I found the series again. I applied the first 3 patches, they are improvements / clarifications. The fourth patch has no user, so I ask who is suing it. Nevertheless, patch 4/4 breaks some boards (I found at least "xfi3") because it is compiled even for not i.MX boards and then prototype is missing: arm: + xfi3 +arch/arm/cpu/arm926ejs/mxs/clock.c: In function 'mxs_set_gpmiclk': +arch/arm/cpu/arm926ejs/mxs/clock.c:151:9: error: implicit declaration of function 'mxs_get_ioclk'; did you mean 'mxs_set_ioclk'? [-Werror=implicit-function-declaration] + clk = mxs_get_ioclk(MXC_IOCLK0); + ^ + mxs_set_ioclk +arch/arm/cpu/arm926ejs/mxs/clock.c: At top level: +arch/arm/cpu/arm926ejs/mxs/clock.c:218:17: error: conflicting types for 'mxs_get_ioclk' + static uint32_t mxs_get_ioclk(enum mxs_ioclock io) + ^ +arch/arm/cpu/arm926ejs/mxs/clock.c:151:9: note: previous implicit declaration of 'mxs_get_ioclk' was here +cc1: all warnings being treated as errors +make[3]: *** [arch/arm/cpu/arm926ejs/mxs/clock.o] Error 1 +make[2]: *** [arch/arm/cpu/arm926ejs/mxs] Error 2 +make[1]: *** [arch/arm/cpu/arm926ejs] Error 2 +make: *** [sub-make] Error 2 I have nothing against to merge this, too, but the issue above must be fixed - thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Re: [PATCH 1/1] trace: provide Sphinx style comments
On Wed, 1 Jan 2020 at 07:52, Heinrich Schuchardt wrote: > > Correct some function comments. Convert to Sphinx style. > > Signed-off-by: Heinrich Schuchardt > --- > lib/trace.c | 54 +++-- > 1 file changed, 36 insertions(+), 18 deletions(-) > Reviewed-by: Simon Glass Let's hope this will be the final comment style for U-Boot!
Pull request: u-boot-rockchip-20191231
Hi Tom, Please pull the rockchip updates/fixes: - Fix latest mainline kernel for rk3308 - Update rk3288-evb config to suport OP-TEE - Fix for firefly-px30 DEBUG_UART channel and make it standalone - Script make_fit_atf add python3 support - Fix rk3328 timer with correct COUNTER_FREQUENCY - Fix rk3328 ATF support with enable spl-fifo-mode Travis: https://travis-ci.org/keveryang/u-boot/builds/631247159 Thanks, - Kever The following changes since commit d792b63febf492a07a106245e46532c0d43a7ecd: Merge branch 'master' of git://git.denx.de/u-boot-usb (2019-12-22 09:14:35 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git tags/u-boot-rockchip-20191231 for you to fetch changes up to c0a474b9d9a1c370f46b3f76ea0707f92d55b0b1: rockchip: evb-rk3328: Enable support ATF in SPL (2019-12-31 16:04:16 +0800) Andy Yan (2): rockchip: rk3308: allow loading larger kernel Image doc: rockchip: Fix reference the wrong defconfig name of ROC-CC-RK3308 Jack Mitchell (1): rockchip: make_fit_atf: explicitly use python3 Jeffy Chen (3): rockchip: mkimage: support packing optional second level boot-loader doc: rockchip: document packing second level loader with mkimage rockchip: mkimage: fix wrong range of rc4 encoding for boot image Kever Yang (9): rockchip: fit_spl_optee: get text and optee base from build rockchip: rk3288-evb: update SPL_STACK/MALLOC_LEN config with rk3399 rockchip: rk3288-evb: update CONFIG_NR_DRAM_BANKS to 2 rockchip: rk3288-evb: update config to support OPTEE rockchip: firefly-px30: Fix the MACRO for CONFIG_DEBUG_UART2_CHANNEL rockchip: px30-firefly add standalone dts rockchip: rk3328: add COUNTER_FREQUENCY definition rockchip: rk3328: enable spl-fifo-mode for emmc and sdmmc rockchip: evb-rk3328: Enable support ATF in SPL Thomas Hebb (1): rockchip: add description for TPL_ROCKCHIP_COMMON_BOARD arch/arm/dts/Makefile | 3 +- arch/arm/dts/px30-firefly-u-boot.dtsi | 84 + arch/arm/dts/px30-firefly.dts | 531 arch/arm/dts/rk3328-u-boot.dtsi | 6 + arch/arm/mach-rockchip/Kconfig | 2 +- arch/arm/mach-rockchip/fit_spl_optee.sh | 12 +- arch/arm/mach-rockchip/make_fit_atf.py | 2 +- configs/evb-rk3288_defconfig| 11 +- configs/evb-rk3328_defconfig| 6 +- configs/firefly-px30_defconfig | 6 +- doc/README.rockchip | 15 +- include/configs/rk3308_common.h | 2 +- include/configs/rk3328_common.h | 1 + tools/imagetool.h | 1 + tools/mkimage.c | 8 + tools/rkcommon.c| 242 --- tools/rkcommon.h| 18 +- tools/rkimage.c | 2 +- tools/rksd.c| 35 +-- tools/rkspi.c | 42 +-- 20 files changed, 897 insertions(+), 132 deletions(-) create mode 100644 arch/arm/dts/px30-firefly-u-boot.dtsi create mode 100644 arch/arm/dts/px30-firefly.dts
[PATCH v2 08/19] i2c: designware_i2c: Read device-tree properties
The i2c controller defines a few timing properties. Read these in and
store them for use by the driver.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/designware_i2c.c | 8 ++--
drivers/i2c/designware_i2c.h | 15 +++
drivers/i2c/designware_i2c_pci.c | 2 +-
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 0a1df8015f..34b6816545 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -535,11 +535,15 @@ static int designware_i2c_probe_chip(struct udevice *bus,
uint chip_addr,
return ret;
}
-static int designware_i2c_ofdata_to_platdata(struct udevice *bus)
+int designware_i2c_ofdata_to_platdata(struct udevice *bus)
{
struct dw_i2c *priv = dev_get_priv(bus);
- priv->regs = (struct i2c_regs *)devfdt_get_addr_ptr(bus);
+ if (!priv->regs)
+ priv->regs = (struct i2c_regs *)devfdt_get_addr_ptr(bus);
+ dev_read_u32(bus, "i2c-scl-rising-time-ns", &priv->scl_rise_time_ns);
+ dev_read_u32(bus, "i2c-scl-falling-time-ns", &priv->scl_fall_time_ns);
+ dev_read_u32(bus, "i2c-sda-hold-time-ns", &priv->sda_hold_time_ns);
return 0;
}
diff --git a/drivers/i2c/designware_i2c.h b/drivers/i2c/designware_i2c.h
index 1f9940c2ba..55e440f0c0 100644
--- a/drivers/i2c/designware_i2c.h
+++ b/drivers/i2c/designware_i2c.h
@@ -166,10 +166,24 @@ struct dw_scl_sda_cfg {
u32 sda_hold;
};
+/**
+ * struct dw_i2c - private information for the bus
+ *
+ * @regs: Registers pointer
+ * @scl_sda_cfg: Deprecated information for x86 (should move to device tree)
+ * @resets: Resets for the I2C controller
+ * @scl_rise_time_ns: Configured SCL rise time in nanoseconds
+ * @scl_fall_time_ns: Configured SCL fall time in nanoseconds
+ * @sda_hold_time_ns: Configured SDA hold time in nanoseconds
+ * @clk: Clock input to the I2C controller
+ */
struct dw_i2c {
struct i2c_regs *regs;
struct dw_scl_sda_cfg *scl_sda_cfg;
struct reset_ctl_bulk resets;
+ u32 scl_rise_time_ns;
+ u32 scl_fall_time_ns;
+ u32 sda_hold_time_ns;
#if CONFIG_IS_ENABLED(CLK)
struct clk clk;
#endif
@@ -179,5 +193,6 @@ extern const struct dm_i2c_ops designware_i2c_ops;
int designware_i2c_probe(struct udevice *bus);
int designware_i2c_remove(struct udevice *dev);
+int designware_i2c_ofdata_to_platdata(struct udevice *bus);
#endif /* __DW_I2C_H_ */
diff --git a/drivers/i2c/designware_i2c_pci.c b/drivers/i2c/designware_i2c_pci.c
index 7f0625df66..2b974a07c3 100644
--- a/drivers/i2c/designware_i2c_pci.c
+++ b/drivers/i2c/designware_i2c_pci.c
@@ -63,7 +63,7 @@ static int designware_i2c_pci_ofdata_to_platdata(struct
udevice *dev)
/* Use BayTrail specific timing values */
priv->scl_sda_cfg = &byt_config;
- return 0;
+ return designware_i2c_ofdata_to_platdata(dev);
}
static int designware_i2c_pci_probe(struct udevice *dev)
--
2.24.1.735.g03f4e72817-goog
Re: [PATCH 1/5] video: x86: Enable 32-bit graphics by default
Hi Simon, On Fri, Jan 3, 2020 at 10:30 AM Simon Glass wrote: > > Hi Anatolij, > > On Thu, 2 Jan 2020 at 07:34, Anatolij Gustschin wrote: > > > > Hi Simon, > > > > On Fri, 20 Dec 2019 18:10:33 -0700 > > Simon Glass s...@chromium.org wrote: > > > > > Most x86 boards that use video make use of 32bpp graphics. Enable this by > > > default. This fixes missing graphics output on some x86 boards. > > > > Must this patch be applied for v2010.01 release? > > I think so since these boards don't work for me at present. > > What do you think, Bin? > Which board is currently broken due to missing this config? Should it be safer to move this to board defconfig? Regards, Bin
[PATCH v2 05/19] i2c: designware_i2c: Use an enum for selected speed mode
Group these #defines into an enum to make it easier to understand the
relationship between them.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/designware_i2c.c | 2 +-
drivers/i2c/designware_i2c.h | 10 +++---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index dd1cc0b823..2416ef32f9 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -57,10 +57,10 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs
*i2c_base,
unsigned int speed,
unsigned int bus_mhz)
{
+ enum i2c_speed_mode i2c_spd;
unsigned int cntl;
unsigned int hcnt, lcnt;
unsigned int ena;
- int i2c_spd;
/* Allow high speed if there is no config, or the config allows it */
if (speed >= I2C_HIGH_SPEED &&
diff --git a/drivers/i2c/designware_i2c.h b/drivers/i2c/designware_i2c.h
index fcb7dde83a..06d794ca64 100644
--- a/drivers/i2c/designware_i2c.h
+++ b/drivers/i2c/designware_i2c.h
@@ -135,9 +135,13 @@ struct i2c_regs {
#define IC_STATUS_ACT 0x0001
/* Speed Selection */
-#define IC_SPEED_MODE_STANDARD 1
-#define IC_SPEED_MODE_FAST 2
-#define IC_SPEED_MODE_HIGH 3
+enum i2c_speed_mode {
+ IC_SPEED_MODE_STANDARD,
+ IC_SPEED_MODE_FAST,
+ IC_SPEED_MODE_HIGH,
+
+ IC_SPEED_MODE_COUNT,
+};
#define I2C_HIGH_SPEED 340
#define I2C_FAST_SPEED 40
--
2.24.1.735.g03f4e72817-goog
Re: Pull request: u-boot-rockchip-20191231
On Thu, Jan 02, 2020 at 04:34:23PM +0800, Kever Yang wrote: > Hi Tom, > > Please pull the rockchip updates/fixes: > - Fix latest mainline kernel for rk3308 > - Update rk3288-evb config to suport OP-TEE > - Fix for firefly-px30 DEBUG_UART channel and make it standalone > - Script make_fit_atf add python3 support > - Fix rk3328 timer with correct COUNTER_FREQUENCY > - Fix rk3328 ATF support with enable spl-fifo-mode > > Travis: > https://travis-ci.org/keveryang/u-boot/builds/631247159 > > Thanks, > - Kever > > The following changes since commit d792b63febf492a07a106245e46532c0d43a7ecd: > > Merge branch 'master' of git://git.denx.de/u-boot-usb (2019-12-22 09:14:35 > -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20191231 > > for you to fetch changes up to c0a474b9d9a1c370f46b3f76ea0707f92d55b0b1: > > rockchip: evb-rk3328: Enable support ATF in SPL (2019-12-31 16:04:16 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v2 12/19] i2c: designware_i2c: Add spike supression
Some versions of this peripheral include a spike-suppression phase of the
bus. Add support for this.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add a few more clean-up patches for i2c
drivers/i2c/designware_i2c.c | 10 +-
drivers/i2c/designware_i2c.h | 2 ++
drivers/i2c/designware_i2c_pci.c | 2 ++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 0069602103..4aee25c543 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -220,6 +220,7 @@ static unsigned int __dw_i2c_set_bus_speed(struct dw_i2c
*priv,
enum i2c_speed_mode i2c_spd;
unsigned int cntl;
unsigned int ena;
+ int spk_cnt;
int ret;
if (priv)
@@ -241,6 +242,13 @@ static unsigned int __dw_i2c_set_bus_speed(struct dw_i2c
*priv,
cntl = (readl(&i2c_base->ic_con) & (~IC_CON_SPD_MSK));
+ /* Get the proper spike-suppression count based on target speed */
+ if (!priv || !priv->has_spk_cnt)
+ spk_cnt = 0;
+ else if (i2c_spd >= IC_SPEED_MODE_HIGH)
+ spk_cnt = readl(&i2c_base->hs_spklen);
+ else
+ spk_cnt = readl(&i2c_base->fs_spklen);
if (scl_sda_cfg) {
config.sda_hold = scl_sda_cfg->sda_hold;
if (i2c_spd == IC_SPEED_MODE_STANDARD) {
@@ -251,7 +259,7 @@ static unsigned int __dw_i2c_set_bus_speed(struct dw_i2c
*priv,
config.scl_lcnt = scl_sda_cfg->fs_lcnt;
}
} else {
- ret = dw_i2c_calc_timing(priv, i2c_spd, bus_clk, 0,
+ ret = dw_i2c_calc_timing(priv, i2c_spd, bus_clk, spk_cnt,
&config);
if (ret)
return log_msg_ret("gen_confg", ret);
diff --git a/drivers/i2c/designware_i2c.h b/drivers/i2c/designware_i2c.h
index 55e440f0c0..2c572a9e1f 100644
--- a/drivers/i2c/designware_i2c.h
+++ b/drivers/i2c/designware_i2c.h
@@ -175,6 +175,7 @@ struct dw_scl_sda_cfg {
* @scl_rise_time_ns: Configured SCL rise time in nanoseconds
* @scl_fall_time_ns: Configured SCL fall time in nanoseconds
* @sda_hold_time_ns: Configured SDA hold time in nanoseconds
+ * @has_spk_cnt: true if the spike-count register is present
* @clk: Clock input to the I2C controller
*/
struct dw_i2c {
@@ -184,6 +185,7 @@ struct dw_i2c {
u32 scl_rise_time_ns;
u32 scl_fall_time_ns;
u32 sda_hold_time_ns;
+ bool has_spk_cnt;
#if CONFIG_IS_ENABLED(CLK)
struct clk clk;
#endif
diff --git a/drivers/i2c/designware_i2c_pci.c b/drivers/i2c/designware_i2c_pci.c
index 2b974a07c3..50f03e3d90 100644
--- a/drivers/i2c/designware_i2c_pci.c
+++ b/drivers/i2c/designware_i2c_pci.c
@@ -62,6 +62,8 @@ static int designware_i2c_pci_ofdata_to_platdata(struct
udevice *dev)
if (IS_ENABLED(CONFIG_INTEL_BAYTRAIL))
/* Use BayTrail specific timing values */
priv->scl_sda_cfg = &byt_config;
+ if (dev_get_driver_data(dev) == INTEL_APL)
+ priv->has_spk_cnt = true;
return designware_i2c_ofdata_to_platdata(dev);
}
--
2.24.1.735.g03f4e72817-goog
Re: [PATCH 2/4] mmc: davinci: drop struct davinci_mmc_plat
On Fri, Jan 03, 2020 at 05:50:38PM +0100, Bartosz Golaszewski wrote: > pt., 3 sty 2020 o 17:01 Adam Ford napisał(a): > > > > On Thu, Nov 14, 2019 at 9:10 AM Bartosz Golaszewski wrote: > > > > > > From: Bartosz Golaszewski > > > > > > struct mmc_config & struct mmc don't need to be exported over platform > > > data, but can instead be private in the driver. > > > > > > Remove struct davinci_mmc_plat. > > > > This patch appears to break the da850-evm. > > > > With the pending release of 2020.01, is there any way we can revert > > before release and try to apply this going forward with more time to > > test? > > > > As of now, the da850-evm cannot read/write from the MMC card from > > U-Boot which includes MMC booting. > > > > This is strange, this change doesn't seem to affect the logic. > > This isn't revertible automatically anymore, due to other patches that > came before and after. We can probably try to revert it manually. Doing a git revert and fixing up the one hunk that didn't go cleanly is easy, should I push that? -- Tom signature.asc Description: PGP signature
ATF + u-boot imx8mm combination
HI all I'm trying to work on some imx8mm mainline but I understand that I miss some of the information needed. I would like to work and play with power domain. Can I know where to find all the information to build a version with a valid combination? Michael -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com |
Re: [PATCH] arm: dts: bcm283x: Allow UARTs to work before relocation
Hi Tom,
On Thu, 2 Jan 2020 at 19:27, Simon Glass wrote:
>
> Hi Tom,
>
> On Thu, 2 Jan 2020 at 16:11, Tom Rini wrote:
> >
> > On Tue, Dec 31, 2019 at 02:28:19PM -0700, Simon Glass wrote:
> > > Hi Matthias,
> > >
> > > On Tue, 10 Dec 2019 at 02:43, Matthias Brugger wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On 02/12/2019 16:45, Tom Rini wrote:
> > > > > On Sun, Dec 01, 2019 at 07:33:56PM -0700, Simon Glass wrote:
> > > > >
> > > > >> At present the pinctrl nodes are not enabled in pre-relocation
> > > > >> U-Boot so
> > > > >> the UARTs do not correctly select the pinconfig to enable the UART
> > > > >> pins.
> > > > >> Fix this so that the U-Boot banner is printed.
> > > > >>
> > > > >> Signed-off-by: Simon Glass
> > > > >> Fixes: 9821636b64 (bcm2835_pinctrl: Probe pre-reloc)
> > > > >> ---
> > > > >>
> > > > >> arch/arm/dts/bcm283x-u-boot.dtsi | 8
> > > > >> 1 file changed, 8 insertions(+)
> > > > >>
> > > > >> diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi
> > > > >> b/arch/arm/dts/bcm283x-u-boot.dtsi
> > > > >> index 36548dad62..68d03627f4 100644
> > > > >> --- a/arch/arm/dts/bcm283x-u-boot.dtsi
> > > > >> +++ b/arch/arm/dts/bcm283x-u-boot.dtsi
> > > > >> @@ -19,3 +19,11 @@
> > > > >> &gpio {
> > > > >> u-boot,dm-pre-reloc;
> > > > >> };
> > > > >> +
> > > > >> +&uart0_gpio14 {
> > > > >> +u-boot,dm-pre-reloc;
> > > > >> +};
> > > > >> +
> > > > >> +&uart1_gpio14 {
> > > > >> +u-boot,dm-pre-reloc;
> > > > >> +};
> > > > >
> > > > > I think this is superseded by the RPi PR that I had been testing and
> > > > > just now pushed. Can you confirm that master is fine on your Pis as
> > > > > well? I gather you hit this failure doing pytest on the board, which
> > > > > is
> > > > > also how I found it. Thanks!
> > > > >
> > > >
> > > > Can you confirm if this is working with master branch or if we still
> > > > need your
> > > > patch. In which situation would we need your patch then?
> > >
> > > Unfortunately with the 'next' branch I still need this patch. WIthout
> > > it I don't get the pre-relocation serial output and tests fail.
> >
> > Which Pi exactly? My 3B works with rpi_3_32b, rpi_3 and rpi_arm64
> > defconfigs and test.py.
>
> It is a rpi_3b I believe, and I am using the rpi_3_32b.
>
> When I cherry-pick the patch the banner appears but before that it
> doesn't. Shall I check it again?
Actually, can you please confirm the tree you are using? I was testing
with -next. I wonder if I was missing a patch?
Regards,
SImon
>
> Regards,
> Simon
Re: [PATCH 1/3] riscv: Add place-holder for FU540 clk and gpio
Hi Pragnesh,
On Tue, Dec 31, 2019 at 2:31 PM Pragnesh Patel
wrote:
>
> Added FU540 place-holder so that SoC specific values
> will be kept here.
It looks only clk.h is the placer-holder. gpio.h is not.
Can you please split the gpio.h changes to another patch?
>
> Signed-off-by: Pragnesh Patel
> ---
> arch/riscv/include/asm/arch-fu540/clk.h| 14
> arch/riscv/include/asm/arch-fu540/gpio.h | 42 ++
> arch/riscv/include/asm/arch-generic/gpio.h | 32 ++---
> board/sifive/fu540/Kconfig | 3 ++
> 4 files changed, 62 insertions(+), 29 deletions(-)
> create mode 100644 arch/riscv/include/asm/arch-fu540/clk.h
> create mode 100644 arch/riscv/include/asm/arch-fu540/gpio.h
>
> diff --git a/arch/riscv/include/asm/arch-fu540/clk.h
> b/arch/riscv/include/asm/arch-fu540/clk.h
> new file mode 100644
> index 00..b39f5b55c9
> --- /dev/null
> +++ b/arch/riscv/include/asm/arch-fu540/clk.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2019 SiFive, Inc.
> + *
> + * Authors:
> + * Pragnesh Patel
> + */
> +
> +#ifndef _CLK_FU540_H
> +#define _CLK_FU540_H
> +
> +/* Note: This is a placeholder header for driver compilation. */
> +
> +#endif
> diff --git a/arch/riscv/include/asm/arch-fu540/gpio.h
> b/arch/riscv/include/asm/arch-fu540/gpio.h
It looks this file is a copy of
arch/riscv/include/asm/arch-generic/gpio.h. Can you explain this a
little bit?
> new file mode 100644
> index 00..f8ddd75852
> --- /dev/null
> +++ b/arch/riscv/include/asm/arch-fu540/gpio.h
> @@ -0,0 +1,42 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2019 SiFive, Inc.
> + *
> + * Authors:
> + * Sagar Shrikant Kadam
> + */
> +
> +#ifndef _GPIO_FU540_H
> +#define _GPIO_FU540_H
> +
> +#define GPIO_INPUT_VAL (0x00)
> +#define GPIO_INPUT_EN (0x04)
> +#define GPIO_OUTPUT_EN (0x08)
> +#define GPIO_OUTPUT_VAL (0x0C)
> +#define GPIO_PULLUP_EN (0x10)
> +#define GPIO_DRIVE (0x14)
> +#define GPIO_RISE_IE(0x18)
> +#define GPIO_RISE_IP(0x1C)
> +#define GPIO_FALL_IE(0x20)
> +#define GPIO_FALL_IP(0x24)
> +#define GPIO_HIGH_IE(0x28)
> +#define GPIO_HIGH_IP(0x2C)
> +#define GPIO_LOW_IE (0x30)
> +#define GPIO_LOW_IP (0x34)
> +#define GPIO_IOF_EN (0x38)
> +#define GPIO_IOF_SEL(0x3C)
> +#define GPIO_OUTPUT_XOR(0x40)
> +
> +#define NR_GPIOS 16
> +
> +enum gpio_state {
> + LOW,
> + HIGH
> +};
> +
> +/* Details about a GPIO bank */
> +struct sifive_gpio_platdata {
> + void *base; /* address of registers in physical memory */
> +};
> +
> +#endif /* _GPIO_FU540_H */
> diff --git a/arch/riscv/include/asm/arch-generic/gpio.h
> b/arch/riscv/include/asm/arch-generic/gpio.h
> index dfcb753051..5f0dc0a801 100644
> --- a/arch/riscv/include/asm/arch-generic/gpio.h
> +++ b/arch/riscv/include/asm/arch-generic/gpio.h
> @@ -3,33 +3,7 @@
> * Copyright (C) 2019 SiFive, Inc.
> */
>
> -#ifndef _GPIO_SIFIVE_H
> -#define _GPIO_SIFIVE_H
> +#ifndef __ASM_RISCV_ARCH_GPIO_H
> +#define __ASM_RISCV_ARCH_GPIO_H
>
> -#define GPIO_INPUT_VAL 0x00
> -#define GPIO_INPUT_EN 0x04
> -#define GPIO_OUTPUT_EN 0x08
> -#define GPIO_OUTPUT_VAL0x0C
> -#define GPIO_RISE_IE 0x18
> -#define GPIO_RISE_IP 0x1C
> -#define GPIO_FALL_IE 0x20
> -#define GPIO_FALL_IP 0x24
> -#define GPIO_HIGH_IE 0x28
> -#define GPIO_HIGH_IP 0x2C
> -#define GPIO_LOW_IE0x30
> -#define GPIO_LOW_IP0x34
> -#define GPIO_OUTPUT_XOR0x40
> -
> -#define NR_GPIOS 16
> -
> -enum gpio_state {
> - LOW,
> - HIGH
> -};
> -
> -/* Details about a GPIO bank */
> -struct sifive_gpio_platdata {
> - void *base; /* address of registers in physical memory */
> -};
> -
> -#endif /* _GPIO_SIFIVE_H */
> +#endif /* __ASM_RISCV_ARCH_GPIO_H */
> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
> index 5ca21474de..816a135b21 100644
> --- a/board/sifive/fu540/Kconfig
> +++ b/board/sifive/fu540/Kconfig
> @@ -12,6 +12,9 @@ config SYS_CPU
> config SYS_CONFIG_NAME
> default "sifive-fu540"
>
> +config SYS_SOC
> + default "fu540"
What about SYS_CPU?
Shouldn't we just rename SYS_CPU to SYS_SOC in this file and assign
"fu540" to it?
> +
> config SYS_TEXT_BASE
> default 0x8000 if !RISCV_SMODE
> default 0x8020 if RISCV_SMODE
> --
Regards,
Bin
Re: [PATCH] pico-imx7d: Convert to DM_ETH
Hi Stefano,
Sorry for the delay,
Le 28/12/2019 à 12:31, Stefano Babic a écrit :
Hi Joris,
On 08/12/19 18:02, Joris Offouga wrote:
Signed-off-by: Joris Offouga
---
board/technexion/pico-imx7d/pico-imx7d.c | 46
configs/pico-dwarf-imx7d_defconfig | 5 +++
configs/pico-hobbit-imx7d_defconfig | 5 +++
configs/pico-imx7d_bl33_defconfig| 5 +++
configs/pico-imx7d_defconfig | 5 +++
configs/pico-nymph-imx7d_defconfig | 5 +++
configs/pico-pi-imx7d_defconfig | 5 +++
include/configs/pico-imx7d.h | 11 --
8 files changed, 30 insertions(+), 57 deletions(-)
I get build errors with pico-imx7d_bl33.
https://travis-ci.org/sbabic/u-boot-imx/jobs/630056283
Could you take a look, please ?
I tried to correct the compilation error but I did not find good ways to
do it, I suggest you remove the usb ethernet support from the
configuration :
-CONFIG_USB_ETHER=y
-CONFIG_USB_ETH_CDC=y
-CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
If you agree I send V2
Best regards,
Joris
Best regards,
Stefano
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c
b/board/technexion/pico-imx7d/pico-imx7d.c
index bcfc7d361e..b7ca2e1315 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
#include "../../freescale/common/pfuze.h"
@@ -26,11 +25,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | \
PAD_CTL_PUS_PU100KOHM | PAD_CTL_HYS)
-#define ENET_PAD_CTRL (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
-#define ENET_PAD_CTRL_MII (PAD_CTL_DSE_3P3V_32OHM)
-
-#define ENET_RX_PAD_CTRL (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
-
#define I2C_PAD_CTRL(PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
@@ -123,44 +117,6 @@ static iomux_v3_cfg_t const uart5_pads[] = {
};
#ifdef CONFIG_FEC_MXC
-static iomux_v3_cfg_t const fec1_pads[] = {
- MX7D_PAD_SD2_CD_B__ENET1_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL_MII),
- MX7D_PAD_SD2_WP__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL_MII),
- MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL |
MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC |
MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 |
MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 |
MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2 |
MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3 |
MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL |
MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
- MX7D_PAD_SD3_STROBE__GPIO6_IO10 | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX7D_PAD_SD3_RESET_B__GPIO6_IO11 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-#define FEC1_RST_GPIO IMX_GPIO_NR(6, 11)
-
-static void setup_iomux_fec(void)
-{
- imx_iomux_v3_setup_multiple_pads(fec1_pads, ARRAY_SIZE(fec1_pads));
- gpio_request(FEC1_RST_GPIO, "phy_rst");
- gpio_direction_output(FEC1_RST_GPIO, 0);
- udelay(500);
- gpio_set_value(FEC1_RST_GPIO, 1);
-}
-
-int board_eth_init(bd_t *bis)
-{
- setup_iomux_fec();
-
- return fecmxc_initialize_multi(bis, 0,
- CONFIG_FEC_MXC_PHYADDR, IMX_FEC_BASE);
-}
-
static int setup_fec(void)
{
struct iomuxc_gpr_base_regs *const iomuxc_gpr_regs
@@ -235,9 +191,7 @@ int board_init(void)
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
#ifdef CONFIG_DM_VIDEO
-
setup_lcd();
-
#endif
#ifdef CONFIG_FEC_MXC
setup_fec();
diff --git a/configs/pico-dwarf-imx7d_defconfig
b/configs/pico-dwarf-imx7d_defconfig
index 94d73ee051..2437a64dd0 100644
--- a/configs/pico-dwarf-imx7d_defconfig
+++ b/configs/pico-dwarf-imx7d_defconfig
@@ -59,6 +59,11 @@ CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_FSL_USDHC=y
CONFIG_MTD=y
CONFIG_PHYLIB=y
+CONFIG_PHY_ATHEROS=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_FEC_MXC=y
+CONFIG_RGMII=y
CONFIG_MII=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX7=y
diff --git a/configs/pico-hobbit-imx7d_defconfig
b/configs/pico-hobbit-imx7d_defconfig
index ef86b0cd66..3467d4c2e4 100644
--- a/configs/pico-hobbit-imx7d_defconfig
+++ b/configs/pico-hobbit-imx7d_defconfig
@@ -59,6 +59,11 @@ CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_FSL_USDHC=y
CONFIG_MTD=y
CONFIG_PHYLIB=y
+CONFIG_PHY_ATHEROS=y
+CONFIG_DM_ET
[PATCH v2 10/19] i2c: designware_i2c: Put hold config in a struct
Create a struct to hold the three timing parameters. This will make it
easier to move these calculations into a separate function in a later
patch.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/designware_i2c.c | 82
1 file changed, 55 insertions(+), 27 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 6e5545cd0c..e50987a717 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -13,6 +13,23 @@
#include
#include "designware_i2c.h"
+/**
+ * struct dw_i2c_speed_config - timings to use for a particular speed
+ *
+ * This holds calculated values to be written to the I2C controller. Each value
+ * is represented as a number of IC clock cycles.
+ *
+ * @scl_lcnt: Low count value for SCL
+ * @scl_hcnt: High count value for SCL
+ * @sda_hold: Data hold count
+ */
+struct dw_i2c_speed_config {
+ /* SCL high and low period count */
+ uint scl_lcnt;
+ uint scl_hcnt;
+ uint sda_hold;
+};
+
#ifdef CONFIG_SYS_I2C_DW_ENABLE_STATUS_UNSUPPORTED
static int dw_i2c_enable(struct i2c_regs *i2c_base, bool enable)
{
@@ -58,10 +75,10 @@ static unsigned int __dw_i2c_set_bus_speed(struct dw_i2c
*priv,
unsigned int bus_clk)
{
const struct dw_scl_sda_cfg *scl_sda_cfg = NULL;
+ struct dw_i2c_speed_config config;
ulong bus_khz = bus_clk / 1000;
enum i2c_speed_mode i2c_spd;
unsigned int cntl;
- unsigned int hcnt, lcnt;
unsigned int ena;
if (priv)
@@ -83,53 +100,64 @@ static unsigned int __dw_i2c_set_bus_speed(struct dw_i2c
*priv,
cntl = (readl(&i2c_base->ic_con) & (~IC_CON_SPD_MSK));
+ config.scl_hcnt = 0;
+ config.scl_lcnt = 0;
+ config.sda_hold = 0;
+ if (scl_sda_cfg) {
+ config.sda_hold = scl_sda_cfg->sda_hold;
+ if (i2c_spd == IC_SPEED_MODE_STANDARD) {
+ config.scl_hcnt = scl_sda_cfg->ss_hcnt;
+ config.scl_lcnt = scl_sda_cfg->ss_lcnt;
+ } else {
+ config.scl_hcnt = scl_sda_cfg->fs_hcnt;
+ config.scl_lcnt = scl_sda_cfg->fs_lcnt;
+ }
+ }
+
switch (i2c_spd) {
case IC_SPEED_MODE_HIGH:
cntl |= IC_CON_SPD_SS;
- if (scl_sda_cfg) {
- hcnt = scl_sda_cfg->fs_hcnt;
- lcnt = scl_sda_cfg->fs_lcnt;
- } else {
- hcnt = (bus_khz * MIN_HS_SCL_HIGHTIME) / NANO_TO_KILO;
- lcnt = (bus_khz * MIN_HS_SCL_LOWTIME) / NANO_TO_KILO;
+ if (!scl_sda_cfg) {
+ config.scl_hcnt = (bus_khz * MIN_HS_SCL_HIGHTIME) /
+NANO_TO_KILO;
+ config.scl_lcnt = (bus_khz * MIN_HS_SCL_LOWTIME) /
+NANO_TO_KILO;
}
- writel(hcnt, &i2c_base->ic_hs_scl_hcnt);
- writel(lcnt, &i2c_base->ic_hs_scl_lcnt);
+ writel(config.scl_hcnt, &i2c_base->ic_hs_scl_hcnt);
+ writel(config.scl_lcnt, &i2c_base->ic_hs_scl_lcnt);
break;
case IC_SPEED_MODE_STANDARD:
cntl |= IC_CON_SPD_SS;
- if (scl_sda_cfg) {
- hcnt = scl_sda_cfg->ss_hcnt;
- lcnt = scl_sda_cfg->ss_lcnt;
- } else {
- hcnt = (bus_khz * MIN_SS_SCL_HIGHTIME) / NANO_TO_KILO;
- lcnt = (bus_khz * MIN_SS_SCL_LOWTIME) / NANO_TO_KILO;
+ if (!scl_sda_cfg) {
+ config.scl_hcnt = (bus_khz * MIN_SS_SCL_HIGHTIME) /
+NANO_TO_KILO;
+ config.scl_lcnt = (bus_khz * MIN_SS_SCL_LOWTIME) /
+NANO_TO_KILO;
}
- writel(hcnt, &i2c_base->ic_ss_scl_hcnt);
- writel(lcnt, &i2c_base->ic_ss_scl_lcnt);
+ writel(config.scl_hcnt, &i2c_base->ic_ss_scl_hcnt);
+ writel(config.scl_lcnt, &i2c_base->ic_ss_scl_lcnt);
break;
case IC_SPEED_MODE_FAST:
default:
cntl |= IC_CON_SPD_FS;
- if (scl_sda_cfg) {
- hcnt = scl_sda_cfg->fs_hcnt;
- lcnt = scl_sda_cfg->fs_lcnt;
- } else {
- hcnt = (bus_khz * MIN_FS_SCL_HIGHTIME) / NANO_TO_KILO;
- lcnt = (bus_khz * MIN_FS_SCL_LOWTIME) / NANO_TO_KILO;
+ if (!scl_sda_cfg) {
+ config.scl_hcnt = (bus_khz * MIN_FS_SCL_HIGHTIME) /
+NANO_TO_KILO;
+ config.scl_lcnt = (bus_khz * MIN_FS_SCL_LOWTIME) /
+NANO_TO_KILO;
}
- writel
[PATCH v2 11/19] i2c: designware_i2c: Rewrite timing calculation
At present the driver can end up with timing parameters which are slightly
faster than those expected. It is possible to optimise the parameters to
get the best possible result.
Create a new function to handle the timing calculation. This uses a table
of defaults for each speed mode rather than writing it in code.
The function works by calculating the 'period' of each bit on the bus in
terms of the input clock to the controller (IC_CLK). It makes sure that
the constraints are met and that the different components of that period
add up correctly.
This code was taken from coreboot which has ended up with this same
driver, but now in a much-different form.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/designware_i2c.c | 169 ++-
1 file changed, 147 insertions(+), 22 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index e50987a717..0069602103 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -63,6 +63,147 @@ static int dw_i2c_enable(struct i2c_regs *i2c_base, bool
enable)
}
#endif
+/* High and low times in different speed modes (in ns) */
+enum {
+ /* SDA Hold Time */
+ DEFAULT_SDA_HOLD_TIME = 300,
+};
+
+/**
+ * calc_counts() - Convert a period to a number of IC clk cycles
+ *
+ * @ic_clk: Input clock in Hz
+ * @period_ns: Period to represent, in ns
+ * @return calculated count
+ */
+static uint calc_counts(uint ic_clk, uint period_ns)
+{
+ return DIV_ROUND_UP(ic_clk / 1000 * period_ns, NANO_TO_KILO);
+}
+
+/**
+ * struct i2c_mode_info - Information about an I2C speed mode
+ *
+ * Each speed mode has its own characteristics. This struct holds these to aid
+ * calculations in dw_i2c_calc_timing().
+ *
+ * @speed: Speed in Hz
+ * @min_scl_lowtime_ns: Minimum value for SCL low period in ns
+ * @min_scl_hightime_ns: Minimum value for SCL high period in ns
+ * @def_rise_time_ns: Default rise time in ns
+ * @def_fall_time_ns: Default fall time in ns
+ */
+struct i2c_mode_info {
+ int speed;
+ int min_scl_hightime_ns;
+ int min_scl_lowtime_ns;
+ int def_rise_time_ns;
+ int def_fall_time_ns;
+};
+
+static const struct i2c_mode_info info_for_mode[] = {
+ [IC_SPEED_MODE_STANDARD] = {
+ I2C_STANDARD_SPEED,
+ MIN_SS_SCL_HIGHTIME,
+ MIN_SS_SCL_LOWTIME,
+ 1000,
+ 300,
+ },
+ [IC_SPEED_MODE_FAST] = {
+ I2C_FAST_SPEED,
+ MIN_FS_SCL_HIGHTIME,
+ MIN_FS_SCL_LOWTIME,
+ 300,
+ 300,
+ },
+ [IC_SPEED_MODE_HIGH] = {
+ I2C_HIGH_SPEED,
+ MIN_HS_SCL_HIGHTIME,
+ MIN_HS_SCL_LOWTIME,
+ 120,
+ 120,
+ },
+};
+
+/**
+ * dw_i2c_calc_timing() - Calculate the timings to use for a bus
+ *
+ * @priv: Bus private information (NULL if not using driver model)
+ * @mode: Speed mode to use
+ * @ic_clk: IC clock speed in Hz
+ * @spk_cnt: Spike-suppression count
+ * @config: Returns value to use
+ * @return 0 if OK, -EINVAL if the calculation failed due to invalid data
+ */
+static int dw_i2c_calc_timing(struct dw_i2c *priv, enum i2c_speed_mode mode,
+ int ic_clk, int spk_cnt,
+ struct dw_i2c_speed_config *config)
+{
+ int fall_cnt, rise_cnt, min_tlow_cnt, min_thigh_cnt;
+ int hcnt, lcnt, period_cnt, diff, tot;
+ int sda_hold_time_ns, scl_rise_time_ns, scl_fall_time_ns;
+ const struct i2c_mode_info *info;
+
+ /*
+* Find the period, rise, fall, min tlow, and min thigh in terms of
+* counts of the IC clock
+*/
+ info = &info_for_mode[mode];
+ period_cnt = ic_clk / info->speed;
+ scl_rise_time_ns = priv && priv->scl_rise_time_ns ?
+priv->scl_rise_time_ns : info->def_rise_time_ns;
+ scl_fall_time_ns = priv && priv->scl_fall_time_ns ?
+priv->scl_fall_time_ns : info->def_fall_time_ns;
+ rise_cnt = calc_counts(ic_clk, scl_rise_time_ns);
+ fall_cnt = calc_counts(ic_clk, scl_fall_time_ns);
+ min_tlow_cnt = calc_counts(ic_clk, info->min_scl_lowtime_ns);
+ min_thigh_cnt = calc_counts(ic_clk, info->min_scl_hightime_ns);
+
+ debug("dw_i2c: period %d rise %d fall %d tlow %d thigh %d spk %d\n",
+ period_cnt, rise_cnt, fall_cnt, min_tlow_cnt, min_thigh_cnt,
+ spk_cnt);
+
+ /*
+* Back-solve for hcnt and lcnt according to the following equations:
+* SCL_High_time = [(HCNT + IC_*_SPKLEN + 7) * ic_clk] + SCL_Fall_time
+* SCL_Low_time = [(LCNT + 1) * ic_clk] - SCL_Fall_time + SCL_Rise_time
+*/
+ hcnt = min_thigh_cnt - fall_cnt - 7 - spk_cnt;
+ lcnt = min_tlow_cnt - rise_cnt + fall_cnt - 1;
+
+ if (hcnt < 0 || lcnt < 0) {
+ debug("dw_i2c: bad counts. hcnt = %d lcn
Re: [PATCH 2/4] mmc: davinci: drop struct davinci_mmc_plat
pt., 3 sty 2020 o 17:01 Adam Ford napisał(a): > > On Thu, Nov 14, 2019 at 9:10 AM Bartosz Golaszewski wrote: > > > > From: Bartosz Golaszewski > > > > struct mmc_config & struct mmc don't need to be exported over platform > > data, but can instead be private in the driver. > > > > Remove struct davinci_mmc_plat. > > This patch appears to break the da850-evm. > > With the pending release of 2020.01, is there any way we can revert > before release and try to apply this going forward with more time to > test? > > As of now, the da850-evm cannot read/write from the MMC card from > U-Boot which includes MMC booting. > This is strange, this change doesn't seem to affect the logic. This isn't revertible automatically anymore, due to other patches that came before and after. We can probably try to revert it manually. Bart
[PATCH v2 16/19] i2c: kona_i2c: Update to use standard enums for speed
Update this driver to use the new standard enums for speed.
Note: This driver needs to move to driver model.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/kona_i2c.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/kona_i2c.c b/drivers/i2c/kona_i2c.c
index d13e4deee5..0726b4c956 100644
--- a/drivers/i2c/kona_i2c.c
+++ b/drivers/i2c/kona_i2c.c
@@ -98,12 +98,6 @@ enum bcm_kona_cmd_t {
BCM_CMD_STOP,
};
-enum bus_speed_index {
- BCM_SPD_100K = 0,
- BCM_SPD_400K,
- BCM_SPD_1MHZ,
-};
-
/* Internal divider settings for standard mode, fast mode and fast mode plus */
struct bus_speed_cfg {
uint8_t time_m; /* Number of cycles for setup time */
@@ -115,9 +109,9 @@ struct bus_speed_cfg {
};
static const struct bus_speed_cfg std_cfg_table[] = {
- [BCM_SPD_100K] = {0x01, 0x01, 0x03, 0x06, 0x00, 0x02},
- [BCM_SPD_400K] = {0x05, 0x01, 0x03, 0x05, 0x01, 0x02},
- [BCM_SPD_1MHZ] = {0x01, 0x01, 0x03, 0x01, 0x01, 0x03},
+ [IC_SPEED_MODE_STANDARD] = {0x01, 0x01, 0x03, 0x06, 0x00, 0x02},
+ [IC_SPEED_MODE_FAST] = {0x05, 0x01, 0x03, 0x05, 0x01, 0x02},
+ [IC_SPEED_MODE_FAST_PLUS] = {0x01, 0x01, 0x03, 0x01, 0x01, 0x03},
};
struct bcm_kona_i2c_dev {
@@ -127,8 +121,8 @@ struct bcm_kona_i2c_dev {
};
/* Keep these two defines in sync */
-#define DEF_SPD 10
-#define DEF_SPD_ENUM BCM_SPD_100K
+#define DEF_SPD I2C_SPEED_STANDARD_RATE
+#define DEF_SPD_ENUM IC_SPEED_MODE_STANDARD
#define DEF_DEVICE(num) \
{(void *)CONFIG_SYS_I2C_BASE##num, DEF_SPD, &std_cfg_table[DEF_SPD_ENUM]}
@@ -560,14 +554,14 @@ static uint bcm_kona_i2c_assign_bus_speed(struct
bcm_kona_i2c_dev *dev,
uint speed)
{
switch (speed) {
- case 10:
- dev->std_cfg = &std_cfg_table[BCM_SPD_100K];
+ case I2C_SPEED_STANDARD_RATE:
+ dev->std_cfg = &std_cfg_table[IC_SPEED_MODE_STANDARD];
break;
- case 40:
- dev->std_cfg = &std_cfg_table[BCM_SPD_400K];
+ case I2C_SPEED_FAST_RATE:
+ dev->std_cfg = &std_cfg_table[IC_SPEED_MODE_FAST];
break;
- case 100:
- dev->std_cfg = &std_cfg_table[BCM_SPD_1MHZ];
+ case I2C_SPEED_FAST_PLUS_RATE:
+ dev->std_cfg = &std_cfg_table[IC_SPEED_MODE_FAST_PLUS];
break;
default:
printf("%d hz bus speed not supported\n", speed);
--
2.24.1.735.g03f4e72817-goog
Re: qemu_arm64_defconfig: PCI autoconfig fails for qemu-system-aarch64 -m 4G
Hi Heinrich, On Wed, 1 Jan 2020 at 19:58, Heinrich Schuchardt wrote: > > Dear all, > > I want to run qemu_arm64_defconfig with 4G. > > qemu-system-aarch64 -machine virt -m 4G -smp cores=2 \ > -bios u-boot.bin -cpu cortex-a53 -nographic -gdb tcp::1234 \ > -netdev user,id=eth0,tftp=tftp -device e1000,netdev=eth0 \ > -device virtio-rng-pci Out of curiosity, why E1000 over virtio-net? > I see an error: > ... > pci_hose_phys_to_bus: invalid physical address > > The error does not occur for a smaller RAM size. > > I added some debug output: > > _dm_pci_phys_to_bus: > phys_addr 0x00013ffecb40, > res->phys_start 0x1000, > res->bus_start 0x1000 > > As qemu_arm64_defconfig does not define CONFIG_SYS_PCI_64BIT the > calculated bus address is truncated. Makes sense. > If CONFIG_SYS_PCI_64BIT is defined for qemu_arm64_defconfig and the > memory is less then 4 GiB an error > PCI: Failed autoconfig bar 10 > occurs. I believe this happens because the handling of the ranges DT property handling (or it could be in the PCI core itself, not sure) is a bit simplistic in U-Boot. The ranges property in QEMU-generated dtb contains two PCI_REGION_MEM ranges, one below 32-bit boundary and one above it. But decode_regions() in U-Boot only supports one range of given type. When CONFIG_SYS_PCI_64BIT is unset, only the region below 32-bit boundary is used, otherwise the one above 32-bits is used. See commit 52ba907328ec069ff1cec6cbe659f1714c68ed33. Thus with CONFIG_SYS_PCI_64BIT set any PCI devices which do not support 64-bit mem BARs stop working. This should happen regardless of the RAM size, right? > For 3GiB memory I observed the following values: > > _dm_pci_phys_to_bus: > phys_addr 0xfffecbc0, > res->phys_start 0x1000, > res->bus_start 0x1000 > > When I define type pci_addr_t as 64bit everything works correctly. > > Why does the number of bits in pci_addr_t depend on CONFIG_SYS_PCI_64BIT > and not on the bitness of the system? As I understand it, some PCI host controllers may require using 64-bit PCI bus addresses but still be connected to a 32-bit CPU. > It is especially worrisome that CONFIG_SYS_PCI_64BIT is not documented > at all. I wonder if Kumar remembers why he introduced it in 2008. > > I tried to change the definition of the following types in pci.h > > typedef phys_addr_t pci_addr_t; > typedef phys_addr_t pci_size_t; > > This lets qemu-x86_defconfig fail with > Error binding driver 'cpu_qemu': -12 > > Using > > typedef unsigned long pci_addr_t; > typedef unsigned long pci_size_t; > > does not produce the error but I am not sure if this is the right approach. > One solution would be to fix decode_regions() to work with multiple regions of the same type and then enable CONFIG_SYS_PCI_64BIT. I think another solution would be to simply limit U-Boot from being relocated above the 32-bit boundary. IIRC some other 64-bit boards do this as well. In fact, this might be the better solution because some bus mastering PCI devices cannot access memory above 32-bit. As far as I can tell, E1000 is not affected but for example EHCI is.
Re: [PATCH 00/22] imx: add i.MX8MP support
Hi Peng, On Mon, Dec 30, 2019 at 10:31 PM Peng Fan wrote: > This is no public AT-F and ddr firmware for this board now. We are at early > stage currently. until NXP software release, there will be public AT-F and > ddr firmware. Ok, understood, but please add a README file when these components become public. What about i.MX8MN EVK board? There is still a missing README there and the AT-F and firmwares are public at this point. It is getting hard to find the combination of U-Boot mainline + AT-F + firmware for i.MX8 family if they are not documented. Thanks
Re: [PATCH v5 6/7] rockchip: Add Single boot image (with binman, pad_cat)
On Tue, Dec 31, 2019 at 1:34 PM Matwey V. Kornilov
wrote:
>
> вт, 31 дек. 2019 г. в 10:54, Matwey V. Kornilov :
> >
> > пн, 30 дек. 2019 г. в 11:28, Jagan Teki :
> > >
> > > All rockchip platforms support TPL or SPL-based bootloader
> > > in mainline with U-Boot proper as final stage. For each
> > > stage we need to burn the image on to flash with respective
> > > offsets.
> > >
> > > This patch creates a single boot image component using
> > > - binman, for arm32 rockchip platforms
> > > - pad_cat, for arm64 rockchip platforms.
> > >
> > > This would help users to get rid of burning different
> > > boot stage images.
> > >
> > > The new image called 'u-boot-rockchip.bin'
> > > which can burn into flash like:
> > >
> > > ₹ sudo dd if=u-boot-rockchip.bin of=/dev/sda seek=64
> > >
> > > This would support all rockchip platforms, except rk3128
> > > since it doesn't support for SPL yet.
> > >
> > > Cc: Kever Yang
> > > Cc: Matwey V. Kornilov
> > > Signed-off-by: Jagan Teki
> > > Reviewed-by: Kever Yang
> > > ---
> > > Makefile | 18 ++
> > > arch/arm/Kconfig | 1 +
> > > arch/arm/dts/rk3036-u-boot.dtsi | 2 ++
> > > arch/arm/dts/rk3288-u-boot.dtsi | 2 ++
> > > arch/arm/dts/rockchip-u-boot.dtsi | 21 +
> > > include/configs/rockchip-common.h | 2 ++
> > > 6 files changed, 42 insertions(+), 4 deletions(-)
> > > create mode 100644 arch/arm/dts/rockchip-u-boot.dtsi
> > >
> > > diff --git a/Makefile b/Makefile
> > > index b48693e560..d5b6c45c89 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -909,7 +909,7 @@ ALL-y += u-boot-with-dtb.bin
> > > endif
> > >
> > > ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
> > > -ALL-y += u-boot-spl-rockchip.bin
> > > +ALL-y += u-boot-rockchip.bin
> > > endif
> > >
> > > LDFLAGS_u-boot += $(LDFLAGS_FINAL)
> > > @@ -1387,15 +1387,25 @@ ifeq ($(CONFIG_SPL)$(CONFIG_TPL),yy)
> > > MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T
> > > $(ROCKCHIP_IMG_TYPE)
> > > tpl/u-boot-tpl-rockchip.bin: tpl/u-boot-tpl.bin FORCE
> > > $(call if_changed,mkimage)
> > > -u-boot-spl-rockchip.bin: tpl/u-boot-tpl-rockchip.bin spl/u-boot-spl.bin
> > > FORCE
> > > +spl/u-boot-spl-rockchip.bin: tpl/u-boot-tpl-rockchip.bin
> > > spl/u-boot-spl.bin FORCE
> > > $(call if_changed,cat)
> > > else
> > > MKIMAGEFLAGS_u-boot-spl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T
> > > $(ROCKCHIP_IMG_TYPE)
> > > -u-boot-spl-rockchip.bin: spl/u-boot-spl.bin FORCE
> > > +spl/u-boot-spl-rockchip.bin: spl/u-boot-spl.bin FORCE
> > > $(call if_changed,mkimage)
> > > endif
> > >
> > > -endif
> > > +ifeq ($(CONFIG_ARM64),)
> > > +u-boot-rockchip.bin: spl/u-boot-spl-rockchip.bin u-boot.img FORCE
> > > + $(call if_changed,binman)
> > > +else
> > > +OBJCOPYFLAGS_u-boot-rockchip.bin = -I binary -O binary \
> > > + --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff
> > > +u-boot-rockchip.bin: spl/u-boot-spl-rockchip.bin u-boot.itb FORCE
> > > + $(call if_changed,pad_cat)
> > > +endif # CONFIG_ARM64
> > > +
> > > +endif # CONFIG_ARCH_ROCKCHIP
> > >
> > > ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy)
> > > MKIMAGEFLAGS_lpc32xx-spl.img = -T lpc32xximage -a $(CONFIG_SPL_TEXT_BASE)
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index f9dab073ea..7bd99ba3bb 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -1590,6 +1590,7 @@ config ARCH_STM32MP
> > > config ARCH_ROCKCHIP
> > > bool "Support Rockchip SoCs"
> > > select BLK
> > > + select BINMAN if !ARM64
> > > select DM
> > > select DM_GPIO
> > > select DM_I2C
> > > diff --git a/arch/arm/dts/rk3036-u-boot.dtsi
> > > b/arch/arm/dts/rk3036-u-boot.dtsi
> > > index 1e7d079315..41ac054b81 100644
> > > --- a/arch/arm/dts/rk3036-u-boot.dtsi
> > > +++ b/arch/arm/dts/rk3036-u-boot.dtsi
> > > @@ -2,3 +2,5 @@
> > > /*
> > > * Copyright (C) 2019 Jagan Teki
> > > */
> > > +
> > > +#include "rockchip-u-boot.dtsi"
> > > diff --git a/arch/arm/dts/rk3288-u-boot.dtsi
> > > b/arch/arm/dts/rk3288-u-boot.dtsi
> > > index 3f00a3b6d3..6d31735362 100644
> > > --- a/arch/arm/dts/rk3288-u-boot.dtsi
> > > +++ b/arch/arm/dts/rk3288-u-boot.dtsi
> > > @@ -3,6 +3,8 @@
> > > * Copyright (C) 2019 Rockchip Electronics Co., Ltd
> > > */
> > >
> > > +#include "rockchip-u-boot.dtsi"
> > > +
> > > / {
> > > chosen {
> > > u-boot,spl-boot-order = \
> > > diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
> > > b/arch/arm/dts/rockchip-u-boot.dtsi
> > > new file mode 100644
> > > index 00..bc0b1412a2
> > > --- /dev/null
> > > +++ b/arch/arm/dts/rockchip-u-boot.dtsi
> > > @@ -0,0 +1,21 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (C) 2019 Jagan Teki
> > > + */
> > > +
> > > +#include
> > > +
> > > +/ {
> > > + binman {
> > > + filename = "u-boot-rockchip.bin";
> > > + pad-byte = <0
[PATCH v2 19/19] i2c: Update drivers to use enum for speed
Convert the obvious uses of i2c bus speeds to use the enum.
Use livetree access for code changes.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/i2c/exynos_hs_i2c.c | 4 ++--
drivers/i2c/fsl_i2c.c| 3 ++-
drivers/i2c/i2c-cdns.c | 2 +-
drivers/i2c/i2c-uclass.c | 12 ++--
drivers/i2c/i2c-uniphier-f.c | 2 +-
drivers/i2c/i2c-uniphier.c | 2 +-
drivers/i2c/imx_lpi2c.c | 8
drivers/i2c/mv_i2c.c | 4 ++--
drivers/i2c/mvtwsi.c | 5 +++--
drivers/i2c/omap24xx_i2c.c | 3 ++-
drivers/i2c/rcar_i2c.c | 2 +-
drivers/i2c/rcar_iic.c | 2 +-
drivers/i2c/s3c24x0_i2c.c| 4 ++--
drivers/i2c/sandbox_i2c.c| 3 ++-
14 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/drivers/i2c/exynos_hs_i2c.c b/drivers/i2c/exynos_hs_i2c.c
index a0821c9257..048272c6b5 100644
--- a/drivers/i2c/exynos_hs_i2c.c
+++ b/drivers/i2c/exynos_hs_i2c.c
@@ -527,8 +527,8 @@ static int s3c_i2c_ofdata_to_platdata(struct udevice *dev)
i2c_bus->id = pinmux_decode_periph_id(blob, node);
- i2c_bus->clock_frequency = fdtdec_get_int(blob, node,
- "clock-frequency", 10);
+ i2c_bus->clock_frequency = dev_read_u32_default(dev, "clock-frequency",
+ I2C_SPEED_STANDARD_RATE);
i2c_bus->node = node;
i2c_bus->bus_num = dev->seq;
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index bbbd6ef5bf..097c54388f 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -584,7 +584,8 @@ static int fsl_i2c_ofdata_to_platdata(struct udevice *bus)
dev->index = dev_read_u32_default(bus, "cell-index", -1);
dev->slaveadd = dev_read_u32_default(bus, "u-boot,i2c-slave-addr",
0x7f);
- dev->speed = dev_read_u32_default(bus, "clock-frequency", 40);
+ dev->speed = dev_read_u32_default(bus, "clock-frequency",
+ I2C_SPEED_FAST_RATE);
if (!clk_get_by_index(bus, 0, &clock))
dev->i2c_clk = clk_get_rate(&clock);
diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
index ff3956d8c2..ac15da2c67 100644
--- a/drivers/i2c/i2c-cdns.c
+++ b/drivers/i2c/i2c-cdns.c
@@ -213,7 +213,7 @@ static int cdns_i2c_set_bus_speed(struct udevice *dev,
unsigned int speed)
unsigned long speed_p = speed;
int ret = 0;
- if (speed > 40) {
+ if (speed > I2C_SPEED_FAST_RATE) {
debug("%s, failed to set clock speed to %u\n", __func__,
speed);
return -EINVAL;
diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index fe77e64619..2aa3efe8aa 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -641,7 +641,8 @@ static int i2c_post_probe(struct udevice *dev)
#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
struct dm_i2c_bus *i2c = dev_get_uclass_priv(dev);
- i2c->speed_hz = dev_read_u32_default(dev, "clock-frequency", 10);
+ i2c->speed_hz = dev_read_u32_default(dev, "clock-frequency",
+I2C_SPEED_STANDARD_RATE);
return dm_i2c_set_bus_speed(dev, i2c->speed_hz);
#else
@@ -699,11 +700,10 @@ int i2c_uclass_init(struct uclass *class)
return -ENOMEM;
/* Get the last allocated alias. */
-#if CONFIG_IS_ENABLED(OF_CONTROL)
- priv->max_id = dev_read_alias_highest_id("i2c");
-#else
- priv->max_id = -1;
-#endif
+ if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA))
+ priv->max_id = dev_read_alias_highest_id("i2c");
+ else
+ priv->max_id = -1;
debug("%s: highest alias id is %d\n", __func__, priv->max_id);
diff --git a/drivers/i2c/i2c-uniphier-f.c b/drivers/i2c/i2c-uniphier-f.c
index ced606bf36..62acd28e1b 100644
--- a/drivers/i2c/i2c-uniphier-f.c
+++ b/drivers/i2c/i2c-uniphier-f.c
@@ -281,7 +281,7 @@ static int uniphier_fi2c_set_bus_speed(struct udevice *bus,
unsigned int speed)
struct uniphier_fi2c_regs __iomem *regs = priv->regs;
/* max supported frequency is 400 kHz */
- if (speed > 40)
+ if (speed > I2C_SPEED_FAST_RATE)
return -EINVAL;
ret = uniphier_fi2c_check_bus_busy(priv);
diff --git a/drivers/i2c/i2c-uniphier.c b/drivers/i2c/i2c-uniphier.c
index e427415e7e..07a7e03033 100644
--- a/drivers/i2c/i2c-uniphier.c
+++ b/drivers/i2c/i2c-uniphier.c
@@ -177,7 +177,7 @@ static int uniphier_i2c_set_bus_speed(struct udevice *bus,
unsigned int speed)
struct uniphier_i2c_priv *priv = dev_get_priv(bus);
/* max supported frequency is 400 kHz */
- if (speed > 40)
+ if (speed > I2C_SPEED_FAST_RATE)
return -EINVAL;
/* bus reset: make sure the bus is idle when change the frequency */
diff
[PATCH v2 01/19] i2c: designware_i2c: Add more registers
Some versions of this peripherals provide more control of the bus
behaviour. Add definitions for these registers.
Signed-off-by: Simon Glass
Reviewed-by: Ley Foon Tan
Reviewed-by: Jun Chen
---
Changes in v2:
- Fix 'previde' typo
drivers/i2c/designware_i2c.h | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/designware_i2c.h b/drivers/i2c/designware_i2c.h
index 48766d0806..d359c8c3f8 100644
--- a/drivers/i2c/designware_i2c.h
+++ b/drivers/i2c/designware_i2c.h
@@ -43,8 +43,19 @@ struct i2c_regs {
u32 ic_rxflr; /* 0x78 */
u32 ic_sda_hold;/* 0x7c */
u32 ic_tx_abrt_source; /* 0x80 */
- u8 res1[0x18]; /* 0x84 */
+ u32 slv_data_nak_only;
+ u32 dma_cr;
+ u32 dma_tdlr;
+ u32 dma_rdlr;
+ u32 sda_setup;
+ u32 ack_general_call;
u32 ic_enable_status; /* 0x9c */
+ u32 fs_spklen;
+ u32 hs_spklen;
+ u32 clr_restart_det;
+ u32 comp_param1;
+ u32 comp_version;
+ u32 comp_type;
};
#if !defined(IC_CLK)
--
2.24.1.735.g03f4e72817-goog
Re: [PATCH 2/4] mmc: davinci: drop struct davinci_mmc_plat
On Fri, Jan 3, 2020 at 10:59 AM Tom Rini wrote: > > On Fri, Jan 03, 2020 at 05:50:38PM +0100, Bartosz Golaszewski wrote: > > pt., 3 sty 2020 o 17:01 Adam Ford napisał(a): > > > > > > On Thu, Nov 14, 2019 at 9:10 AM Bartosz Golaszewski wrote: > > > > > > > > From: Bartosz Golaszewski > > > > > > > > struct mmc_config & struct mmc don't need to be exported over platform > > > > data, but can instead be private in the driver. > > > > > > > > Remove struct davinci_mmc_plat. > > > > > > This patch appears to break the da850-evm. > > > > > > With the pending release of 2020.01, is there any way we can revert > > > before release and try to apply this going forward with more time to > > > test? > > > > > > As of now, the da850-evm cannot read/write from the MMC card from > > > U-Boot which includes MMC booting. > > > > > > > This is strange, this change doesn't seem to affect the logic. > > > > This isn't revertible automatically anymore, due to other patches that > > came before and after. We can probably try to revert it manually. > > Doing a git revert and fixing up the one hunk that didn't go cleanly is > easy, should I push that? That would make me happy. :-) I don't know about Bartosz. If you have a patch, I can quickly test it today. adam > > -- > Tom
Re: [PATCH] arm: dts: bcm283x: Allow UARTs to work before relocation
Hi Tom,
On Thu, 2 Jan 2020 at 16:11, Tom Rini wrote:
>
> On Tue, Dec 31, 2019 at 02:28:19PM -0700, Simon Glass wrote:
> > Hi Matthias,
> >
> > On Tue, 10 Dec 2019 at 02:43, Matthias Brugger wrote:
> > >
> > > Hi Simon,
> > >
> > > On 02/12/2019 16:45, Tom Rini wrote:
> > > > On Sun, Dec 01, 2019 at 07:33:56PM -0700, Simon Glass wrote:
> > > >
> > > >> At present the pinctrl nodes are not enabled in pre-relocation U-Boot
> > > >> so
> > > >> the UARTs do not correctly select the pinconfig to enable the UART
> > > >> pins.
> > > >> Fix this so that the U-Boot banner is printed.
> > > >>
> > > >> Signed-off-by: Simon Glass
> > > >> Fixes: 9821636b64 (bcm2835_pinctrl: Probe pre-reloc)
> > > >> ---
> > > >>
> > > >> arch/arm/dts/bcm283x-u-boot.dtsi | 8
> > > >> 1 file changed, 8 insertions(+)
> > > >>
> > > >> diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi
> > > >> b/arch/arm/dts/bcm283x-u-boot.dtsi
> > > >> index 36548dad62..68d03627f4 100644
> > > >> --- a/arch/arm/dts/bcm283x-u-boot.dtsi
> > > >> +++ b/arch/arm/dts/bcm283x-u-boot.dtsi
> > > >> @@ -19,3 +19,11 @@
> > > >> &gpio {
> > > >> u-boot,dm-pre-reloc;
> > > >> };
> > > >> +
> > > >> +&uart0_gpio14 {
> > > >> +u-boot,dm-pre-reloc;
> > > >> +};
> > > >> +
> > > >> +&uart1_gpio14 {
> > > >> +u-boot,dm-pre-reloc;
> > > >> +};
> > > >
> > > > I think this is superseded by the RPi PR that I had been testing and
> > > > just now pushed. Can you confirm that master is fine on your Pis as
> > > > well? I gather you hit this failure doing pytest on the board, which is
> > > > also how I found it. Thanks!
> > > >
> > >
> > > Can you confirm if this is working with master branch or if we still need
> > > your
> > > patch. In which situation would we need your patch then?
> >
> > Unfortunately with the 'next' branch I still need this patch. WIthout
> > it I don't get the pre-relocation serial output and tests fail.
>
> Which Pi exactly? My 3B works with rpi_3_32b, rpi_3 and rpi_arm64
> defconfigs and test.py.
It is a rpi_3b I believe, and I am using the rpi_3_32b.
When I cherry-pick the patch the banner appears but before that it
doesn't. Shall I check it again?
Regards,
Simon
i2c_class_init problem
Hi Simon U-Boot SPL 2020.01-rc5-00071-g82f6f6e4e4-dirty (Jan 04 2020 - 13:39:54 +0100) spl_early_init i2c_uclass_init: highest alias id is 2 i2c_post_bind: i2c@30a2, req_seq=-1 i2c_post_bind: i2c@30a2, new req_seq=3 i2c_post_bind: i2c@30a4, req_seq=-1 i2c_post_bind: i2c@30a4, new req_seq=4 When I try to use usb bus from spl, I have a strange mapping of i2c bus i2c1 and i2c3 are in use (ok) and defined in uboot.dtsi part. req_seq get the max alias and add 1 so i2c1 is 3 and i2c3 is 4. Now all the function that need to work for reading in my case the eeprom needs to use 3 and 4. Can you explain a bit more how this should work? Michael -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com |
Re: [PATCH v1] mailmap: Update mail address for Igor Opaniuk
On Tue, Dec 17, 2019 at 02:48:54PM +0200, Igor Opaniuk wrote: > My address at Linaro doesn't exist anymore, so people > keep getting mail delivery error responses. Map this address > to the actual one. > > Signed-off-by: Igor Opaniuk > Reviewed-by: Oleksandr Suvorov Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-video
On Thu, Jan 02, 2020 at 08:54:51PM +0100, Anatolij Gustschin wrote: > Hi Tom, > > please pull more video fixes for v2020.01. > > gitlab CI: > https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/1736 > Travis-CI: https://travis-ci.org/vdsao/u-boot-video/builds/631914464 > > Thanks, > Anatolij > > The following changes since commit 6cb87cbb1475f668689f95911d1521ee6ba7f55c: > > Merge tag 'u-boot-imx-20191228' of > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2019-12-28 08:07:16 > -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-video.git > tags/fixes-v2020.01 > > for you to fetch changes up to bf8363931f8bc2a2746f892f154efd170bd5b42e: > > video: add wrappers for ttf type files to .gitignore (2020-01-02 17:45:42 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] colibri_imx7: disable HAB and CAAM support
Hi Stefano, On Fri, Jan 3, 2020 at 1:23 PM Stefano Babic wrote: > > Hi Igor, > > On 27/12/19 10:23, Igor Opaniuk wrote: > > Hi Breno, > > > > On Mon, Dec 23, 2019 at 7:07 PM Breno Matheus Lima > > wrote: > >> > >> Hi Igor, > >> > >> Em qui., 19 de dez. de 2019 às 07:55, Igor Opaniuk > >> escreveu: > >>> > >>> From: Igor Opaniuk > >>> > >>> Currently Colibri iMX7 NAND version doesn't boot at all with > >>> HABv4 support enabled. If CSF section is included in the final > >>> imx binary, BootROM every time switches to usb recovery mode. > >>> However eMMC version of the same SoM works without any issues. > >>> > >>> Disable HAB and CAAM support for now until the problem is properly > >>> investigated and fixed. > >>> > >> > >> This issue is also happening with i.MX6ULL, seems that padding the > >> U-Boot binary to the size defined in boot data is addressing this > >> issue. > >> > >> Please follow example below. > >> > >> 1. Dump boot data: > >> > >> $ hexdump u-boot-dtb.imx | head > >> 000 00d1 4020 8780 f42c 877f > >> 010 f420 877f f400 877f 6000 878d > >> 020 f000 877f b000 000d 01d2 40e8 > >> 030 01cc 04e4 0c02 6840 0c02 6c40 > >> > >> IVT self = 0x877ff400 > >> Boot data addr = 0x877ff000 > >> Boot data size = 0x000db000 > >> > >> 2. Calculate image size: > >> > >> Image offset = IVT self(0x877ff400) - Boot data addr(0x877ff000) = 0x400 > >> Total image size = Boot data size(0x000db000) - Image offset(0x400) = > >> 0xdac00 > >> > >> 3. Pad U-Boot image: > >> > >> $ objcopy -I binary -O binary --pad-to 0xdac00 --gap-fill=0x00 > >> u-boot-dtb.imx u-boot-dtb.imx.pad > >> > >> Could you please try similar in your i.MX7D board? > >> > >> Thanks, > >> Breno Lima > > > > Finally, it works! > > > > Thanks a lot for your help! This should be documented (I'll create a > > patch for this) > > or padding should implicitly be done in makefiles when building the > > final imx image, > > including initial padding for 0x400, like here [1]. > > I left [1] in my queue and I have always asked myself if we really need > it. Frankly speaking, I prefer that the case should be clearly > documented instead of adding an initial padding. Padding could forbid > (or makes more difficult) to pack u-boot inside another container. I would say that [1] is a dirty workaround. I'm currently trying to understand if it's possible to address both issues in tools/imximage.c, so please just ignore [1]. > > Regards, > Stefano > > > > > Regards, > > Igor > > > > [1] https://patchwork.ozlabs.org/patch/1136343/ > > > > -- > = > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > = Thanks -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk
