[U-Boot] [PATCH] fpga: Replace char * with const char * for filename
From: Tien Fong Chee
Ensure the string for filename is always constant, otherwise it can be
corrupted by the writing.
Signed-off-by: Tien Fong Chee
---
drivers/fpga/zynqpl.c |3 ++-
include/fpga.h|2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
index 499310d..683cf14 100644
--- a/drivers/fpga/zynqpl.c
+++ b/drivers/fpga/zynqpl.c
@@ -421,7 +421,8 @@ static int zynq_loadfs(xilinx_desc *desc, const void *buf,
size_t bsize,
loff_t blocksize, actread;
loff_t pos = 0;
int fstype;
- char *interface, *dev_part, *filename;
+ char *interface, *dev_part;
+ const char *filename;
blocksize = fsinfo->blocksize;
interface = fsinfo->interface;
diff --git a/include/fpga.h b/include/fpga.h
index 195f0bd..51de5c5 100644
--- a/include/fpga.h
+++ b/include/fpga.h
@@ -41,7 +41,7 @@ typedef struct {/* typedef fpga_desc */
unsigned int blocksize;
char *interface;
char *dev_part;
- char *filename;
+ const char *filename;
int fstype;
} fpga_fs_info;
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] arm: exynos: Wait till ADC stabilizes before checking Odroid HC1 revision
On Wed, 13 Feb 2019 17:46:44 +0100
Krzysztof Kozlowski wrote:
> Fix detection of Odroid HC1 (Exynos5422) after reboot if kernel
> disabled the LDO4/VDD_ADC regulator.
>
> The LDO4 supplies both ADC block and the ADC input AIN9. Voltage on
> AIN9 will rise slowly, so be patient and wait for it to stabilize.
>
> First reads on Odroid HC1 return 305, 1207, 1297 and finally 1308
> (reference value is 1309).
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> board/samsung/common/exynos5-dt-types.c | 38
> - 1 file changed, 37 insertions(+), 1
> deletion(-)
>
> diff --git a/board/samsung/common/exynos5-dt-types.c
> b/board/samsung/common/exynos5-dt-types.c index
> af711e727a78..8aed64183837 100644 ---
> a/board/samsung/common/exynos5-dt-types.c +++
> b/board/samsung/common/exynos5-dt-types.c @@ -57,12 +57,48 @@ static
> unsigned int odroid_get_rev(void) return 0;
> }
>
> +/*
> + * Read ADC at least twice and check the resuls. If regulator
> providing voltage
> + * on to measured point was just turned on, first reads might
> require time
> + * to stabilize.
> + */
> +static int odroid_get_adc_val(unsigned int *adcval)
> +{
> + unsigned int adcval_prev = 0;
> + int ret, retries = 20;
> +
> + ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
> + _prev);
> + if (ret)
> + return ret;
> +
> + while (retries--) {
> + mdelay(5);
> +
> + ret = adc_channel_single_shot("adc",
> CONFIG_ODROID_REV_AIN,
> + adcval);
> + if (ret)
> + return ret;
> +
> + /*
> + * If difference between ADC reads is less than 3%,
> + * accept the result
> + */
> + if ((100 * abs(*adcval - adcval_prev) / adcval_prev)
> < 3)
> + return ret;
> +
> + adcval_prev = *adcval;
> + }
Is there in the documentation any required time to wait before reading
the ADC value?
If yes then maybe get_timer() based approach shall be used (if
get_timer() is available in this context)?
Please see for example drivers/net/fec_mxc.c for how timeouts are
handled there.
I will test this patch series on XU3 during the weekend. Thanks for
this fix :-)
> +
> + return ret;
> +}
> +
> static int odroid_get_board_type(void)
> {
> unsigned int adcval;
> int ret, i;
>
> - ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
> );
> + ret = odroid_get_adc_val();
> if (ret)
> goto rev_default;
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpd9XrVyIsBQ.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] power: regulator: s2mps11: Add enable delay
On Wed, 13 Feb 2019 17:46:46 +0100
Krzysztof Kozlowski wrote:
> According to datasheet, the output on LDO regulators will start
> appearing after 10-15 us.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/power/regulator/s2mps11_regulator.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/regulator/s2mps11_regulator.c
> b/drivers/power/regulator/s2mps11_regulator.c index
> 723d27f67c9a..1f1581852ee2 100644 ---
> a/drivers/power/regulator/s2mps11_regulator.c +++
> b/drivers/power/regulator/s2mps11_regulator.c @@ -551,7 +551,14 @@
> static int ldo_get_enable(struct udevice *dev)
> static int ldo_set_enable(struct udevice *dev, bool enable)
> {
> - return s2mps11_ldo_enable(dev, PMIC_OP_SET, );
> + int ret;
> +
> + ret = s2mps11_ldo_enable(dev, PMIC_OP_SET, );
> +
> + /* Wait the "enable delay" for voltage to start to rise */
> + udelay(15);
Isn't the enable delay provided/read from dts?
Or is it too early to have dtb parsed?
The udelay(15) seems a bit "magic" value (or is it specified in the
PMIC manual?).
> +
> + return ret;
> }
>
> static int ldo_get_mode(struct udevice *dev)
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpiyU9cjnsTY.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/9] arm: dts: exynos: Add supply for ADC block to Odroid XU3 family
On Wed, 13 Feb 2019 17:46:47 +0100
Krzysztof Kozlowski wrote:
> The ADC block requires VDD supply to be on so provide one.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> arch/arm/dts/exynos5422-odroidxu3.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
> b/arch/arm/dts/exynos5422-odroidxu3.dts index
> e859dd1b981a..9dfae90667cf 100644 ---
> a/arch/arm/dts/exynos5422-odroidxu3.dts +++
> b/arch/arm/dts/exynos5422-odroidxu3.dts @@ -32,6 +32,7 @@
>
> adc@12D1 {
> u-boot,dm-pre-reloc;
> + vdd-supply = <_reg>;
> status = "okay";
> };
>
Reviewed-by: Lukasz Majewski
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpqf6IRL1Wnv.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: mvebu: x530: Enable watchdog in SPL and U-Boot
On Fri, Feb 15, 2019 at 3:12 PM Chris Packham wrote:
>
> Enable the hardware watchdog to guard against system lock ups when
> running in the SPL or U-Boot. Stop the watchdog just before booting so
> that the OS.
D'oh managed to cut off the sentence.
so that the OS can re-enable it if needed.
>
> Signed-off-by: Chris Packham
> ---
>
> arch/arm/dts/armada-385-atl-x530-u-boot.dtsi | 4 ++
> board/alliedtelesis/x530/x530.c | 48
> configs/x530_defconfig | 5 ++
> 3 files changed, 57 insertions(+)
>
> diff --git a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> index 7074a73537fa..79b694cb84bc 100644
> --- a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> +++ b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> @@ -11,3 +11,7 @@
> {
> u-boot,dm-pre-reloc;
> };
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c
> index d7d1942fe686..1b22b6307cd2 100644
> --- a/board/alliedtelesis/x530/x530.c
> +++ b/board/alliedtelesis/x530/x530.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -24,6 +25,10 @@ DECLARE_GLOBAL_DATA_PTR;
> #define CONFIG_NVS_LOCATION0xf480
> #define CONFIG_NVS_SIZE(512 << 10)
>
> +#ifdef CONFIG_WATCHDOG
> +static struct udevice *watchdog_dev;
> +#endif
> +
> static struct serdes_map board_serdes_map[] = {
> {PEX0, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
> {DEFAULT_SERDES, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
> @@ -75,6 +80,10 @@ struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
>
> int board_early_init_f(void)
> {
> +#ifdef CONFIG_WATCHDOG
> + watchdog_dev = NULL;
> +#endif
> +
> /* Configure MPP */
> writel(0x, MVEBU_MPP_BASE + 0x00);
> writel(0x, MVEBU_MPP_BASE + 0x04);
> @@ -88,6 +97,17 @@ int board_early_init_f(void)
> return 0;
> }
>
> +void spl_board_init(void)
> +{
> +#ifdef CONFIG_WATCHDOG
> + int ret;
> +
> + ret = uclass_get_device(UCLASS_WDT, 0, _dev);
> + if (!ret)
> + wdt_start(watchdog_dev, 2500ULL * 120, 0);
> +#endif
> +}
> +
> int board_init(void)
> {
> /* address of boot parameters */
> @@ -100,9 +120,37 @@ int board_init(void)
> /* DEV_READYn is not needed for NVS, ignore it when accessing CS1 */
> writel(0x4001, MVEBU_DEV_BUS_BASE + 0xc8);
>
> + spl_board_init();
> +
> return 0;
> }
>
> +void arch_preboot_os(void)
> +{
> +#ifdef CONFIG_WATCHDOG
> + wdt_stop(watchdog_dev);
> +#endif
> +}
> +
> +#ifdef CONFIG_WATCHDOG
> +void watchdog_reset(void)
> +{
> + static ulong next_reset = 0;
> + ulong now;
> +
> + if (!watchdog_dev)
> + return;
> +
> + now = timer_get_us();
> +
> + /* Do not reset the watchdog too often */
> + if (now > next_reset) {
> + wdt_reset(watchdog_dev);
> + next_reset = now + 1000;
> + }
> +}
> +#endif
> +
> static int led_7seg_init(unsigned int segments)
> {
> int node;
> diff --git a/configs/x530_defconfig b/configs/x530_defconfig
> index 25b9e885d8e6..3bc37b9bee11 100644
> --- a/configs/x530_defconfig
> +++ b/configs/x530_defconfig
> @@ -19,6 +19,8 @@ CONFIG_SILENT_CONSOLE=y
> CONFIG_SILENT_U_BOOT_ONLY=y
> CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC=y
> CONFIG_MISC_INIT_R=y
> +CONFIG_SPL_BOARD_INIT=y
> +CONFIG_SPL_WATCHDOG_SUPPORT=y
> CONFIG_CMD_MEMINFO=y
> # CONFIG_CMD_FLASH is not set
> CONFIG_CMD_GPIO=y
> @@ -70,3 +72,6 @@ CONFIG_USB_STORAGE=y
> CONFIG_USB_HOST_ETHER=y
> CONFIG_USB_ETHER_ASIX=y
> CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_WATCHDOG=y
> +CONFIG_WDT=y
> +CONFIG_WDT_ORION=y
> --
> 2.20.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] power: regulator: s2mps11: Fix step for LDO27 and LDO35
On Wed, 13 Feb 2019 17:46:41 +0100 Krzysztof Kozlowski wrote: > LDO27 and LDO35 have 25 mV step, not 50 mV. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/power/regulator/s2mps11_regulator.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/power/regulator/s2mps11_regulator.c > b/drivers/power/regulator/s2mps11_regulator.c index > ced504eb1476..723d27f67c9a 100644 --- > a/drivers/power/regulator/s2mps11_regulator.c +++ > b/drivers/power/regulator/s2mps11_regulator.c @@ -346,6 +346,8 @@ > static int s2mps11_ldo_hex2volt(int ldo, int hex) case 11: > case 22: > case 23: > + case 27: > + case 35: > uV = hex * S2MPS11_LDO_STEP + S2MPS11_LDO_UV_MIN; > break; > default: > @@ -366,6 +368,8 @@ static int s2mps11_ldo_volt2hex(int ldo, int uV) > case 11: > case 22: > case 23: > + case 27: > + case 35: > hex = (uV - S2MPS11_LDO_UV_MIN) / S2MPS11_LDO_STEP; > break; > default: Reviewed-by: Lukasz Majewski Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgp5WsFZbsu8Z.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] adc: exynos-adc: Fix wrong bit operation used to stop the ADC
On Wed, 13 Feb 2019 17:46:40 +0100 Krzysztof Kozlowski wrote: > When stopping the ADC_V2_CON1_STC_EN should be cleared. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/adc/exynos-adc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/adc/exynos-adc.c b/drivers/adc/exynos-adc.c > index d33e3d632afc..12c49fc8cefb 100644 > --- a/drivers/adc/exynos-adc.c > +++ b/drivers/adc/exynos-adc.c > @@ -62,7 +62,7 @@ int exynos_adc_stop(struct udevice *dev) > > /* Stop conversion */ > cfg = readl(>con1); > - cfg |= ~ADC_V2_CON1_STC_EN; > + cfg &= ~ADC_V2_CON1_STC_EN; > > writel(cfg, >con1); > Reviewed-by: Lukasz Majewski Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgppIqc1MlEfc.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] riscv: add support for multi-hart systems
Hi Lukas > > From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de] > > Sent: Tuesday, February 12, 2019 6:14 AM > > To: u-boot@lists.denx.de > > Cc: Atish Patra; Anup Patel; Bin Meng; Andreas Schwab; Palmer Dabbelt; > > Alexander Graf; Lukas Auer; Anup Patel; Rick Jian-Zhi Chen(陳建志); Baruch > > Siach; > > Stefan Roese > > Subject: [PATCH 5/7] riscv: add support for multi-hart systems > > > > On RISC-V, all harts boot independently. To be able to run on a multi-hart > > system, > > U-Boot must be extended with the functionality to manage all harts in the > > system. A new config option, CONFIG_MAIN_HART, is used to select the hart > > U-Boot runs on. All other harts are halted. > > U-Boot can delegate functions to them using smp_call_function(). > > > > Every hart has a valid pointer to the global data structure and a 8KiB > > stack by > > default. The stack size is set with CONFIG_STACK_SIZE_SHIFT. > > > > Signed-off-by: Lukas Auer > > --- > > > > arch/riscv/Kconfig | 12 + > > arch/riscv/cpu/start.S | 102 ++- > > arch/riscv/include/asm/csr.h | 1 + > > 3 files changed, 114 insertions(+), 1 deletion(-) > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > > 3a51339c4d..af8d0f8d67 > > 100644 > > --- a/arch/riscv/Kconfig > > +++ b/arch/riscv/Kconfig > > @@ -140,4 +140,16 @@ config SBI_IPI > > default y if RISCV_SMODE > > depends on SMP > > > > +config MAIN_HART > > + int "Main hart in system" > > + default 0 > > + help > > + Some SoCs include harts of various sizes, some of which might not > > + be suitable for running U-Boot. CONFIG_MAIN_HART is used to select > > + the hart U-Boot runs on. > > + > > +config STACK_SIZE_SHIFT > > + int > > + default 13 > > + > > endmenu > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index > > a30f6f7194..ce7230df37 100644 > > --- a/arch/riscv/cpu/start.S > > +++ b/arch/riscv/cpu/start.S > > @@ -13,6 +13,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > If u-boot boot from flash by itself in M-mode without any FSBL or gdb, in this case there will be no chance to assign a0. Can we add some code as below : _start: +#ifdef CONFIG_RISCV_MMODE + csrra0, mhartid +#endif /* save hart id and dtb pointer */ mv s0, a0 mv s1, a1 How do you think about it ? Thanks Rick > > @@ -45,6 +46,23 @@ _start: > > /* mask all interrupts */ > > csrwMODE_PREFIX(ie), zero > > > > +#ifdef CONFIG_SMP > > + /* check if hart is within range */ > > + /* s0: hart id */ > > + li t0, CONFIG_NR_CPUS > > + bge s0, t0, hart_out_of_bounds_loop > > +#endif ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/8] spi: sun4i: Access registers and bits via enum offsets
On 2/15/19 1:56 AM, André Przywara wrote:
On 14/02/2019 08:36, Jagan Teki wrote:
Allwinner support two different SPI controllers one for A10 and
another for A31 with minimal changes in register offsets and
respective register bits, but the logic for accessing the SPI
master via SPI slave remains nearly similar.
Add enum offsets for register set and register bits, so-that
it can access both classes of SPI controllers.
Assign same control register for global, transfer and fifo control
registers to make the same code compatible with A31 SPI controller.
Signed-off-by: Jagan Teki
---
Note: SPI_REG still seems to have checkpatch warning.
It's a CHECK, and it's fine, as long as you pass only "priv" in, at
least. I think we can leave it this way.
drivers/spi/sun4i_spi.c | 153 +---
1 file changed, 111 insertions(+), 42 deletions(-)
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index 0b1663038c..afc351c292 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -83,7 +83,6 @@
#define SUN4I_XMIT_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE)
#define SUN4I_FIFO_STA_REG 0x28
-#define SUN4I_FIFO_STA_RF_CNT_MASK 0x7f
#define SUN4I_FIFO_STA_RF_CNT_BITS0
#define SUN4I_FIFO_STA_TF_CNT_MASK0x7f
#define SUN4I_FIFO_STA_TF_CNT_BITS16
@@ -93,28 +92,55 @@
#define SUN4I_SPI_DEFAULT_RATE100
#define SUN4I_SPI_TIMEOUT_US 100
-/* sun4i spi register set */
-struct sun4i_spi_regs {
- u32 rxdata;
- u32 txdata;
- u32 ctl;
- u32 intctl;
- u32 st;
- u32 dmactl;
- u32 wait;
- u32 cctl;
- u32 bc;
- u32 tc;
- u32 fifo_sta;
+#define SPI_REG(priv, reg) ((priv)->base_addr + \
+ (priv)->variant->regs[reg])
+#define SPI_BIT(priv, bit) ((priv)->variant->bits[bit])
+#define SPI_CS(cs, priv) (((cs) << SPI_BIT(priv, SPI_TCR_CS_SEL))
& \
+ SPI_BIT(priv, SPI_TCR_CS_MASK))
Any chance you can swap the order of the parameters for SPI_CS? It's
quite error prone to have it different from the other two macros
+
+/* sun spi register set */
+enum sun4i_spi_regs {
+ SPI_GCR,
+ SPI_TCR,
+ SPI_FCR,
+ SPI_FSR,
+ SPI_CCR,
+ SPI_BC,
+ SPI_TC,
+ SPI_BCTL,
+ SPI_TXD,
+ SPI_RXD,
+};
+
+/* sun spi register bits */
+enum sun4i_spi_bits {
+ SPI_GCR_TP,
+ SPI_TCR_CPHA,
+ SPI_TCR_CPOL,
+ SPI_TCR_CS_ACTIVE_LOW,
+ SPI_TCR_CS_SEL,
+ SPI_TCR_CS_MASK,
+ SPI_TCR_XCH,
+ SPI_TCR_CS_MANUAL,
+ SPI_TCR_CS_LEVEL,
+ SPI_FCR_TF_RST,
+ SPI_FCR_RF_RST,
+ SPI_FSR_RF_CNT_MASK,
+};
+
+struct sun4i_spi_variant {
+ const unsigned long *regs, *bits;
};
struct sun4i_spi_platdata {
+ struct sun4i_spi_variant *variant;
u32 base_addr;
u32 max_hz;
};
struct sun4i_spi_priv {
- struct sun4i_spi_regs *regs;
+ struct sun4i_spi_variant *variant;
+ u32 base_addr;
u32 freq;
u32 mode;
@@ -129,7 +155,7 @@ static inline void sun4i_spi_drain_fifo(struct sun4i_spi_priv *priv, int len)
u8 byte;
while (len--) {
- byte = readb(>regs->rxdata);
+ byte = readb(SPI_REG(priv, SPI_RXD));
if (priv->rx_buf)
*priv->rx_buf++ = byte;
}
@@ -141,7 +167,7 @@ static inline void sun4i_spi_fill_fifo(struct
sun4i_spi_priv *priv, int len)
while (len--) {
byte = priv->tx_buf ? *priv->tx_buf++ : 0;
- writeb(byte, >regs->txdata);
+ writeb(byte, SPI_REG(priv, SPI_TXD));
}
}
@@ -150,17 +176,17 @@ static void sun4i_spi_set_cs(struct udevice *bus, u8 cs, bool enable)
struct sun4i_spi_priv *priv = dev_get_priv(bus);
u32 reg;
- reg = readl(>regs->ctl);
+ reg = readl(SPI_REG(priv, SPI_TCR));
- reg &= ~SUN4I_CTL_CS_MASK;
- reg |= SUN4I_CTL_CS(cs);
+ reg &= ~SPI_BIT(priv, SPI_TCR_CS_MASK);
+ reg |= SPI_CS(cs, priv);
if (enable)
- reg &= ~SUN4I_CTL_CS_LEVEL;
+ reg &= ~SPI_BIT(priv, SPI_TCR_CS_LEVEL);
else
- reg |= SUN4I_CTL_CS_LEVEL;
+ reg |= SPI_BIT(priv, SPI_TCR_CS_LEVEL);
- writel(reg, >regs->ctl);
+ writel(reg, SPI_REG(priv, SPI_TCR));
}
static int sun4i_spi_parse_pins(struct udevice *dev)
@@ -255,6 +281,7 @@ static int sun4i_spi_ofdata_to_platdata(struct udevice *bus)
int node = dev_of_offset(bus);
plat->base_addr = devfdt_get_addr(bus);
+ plat->variant = (struct sun4i_spi_variant *)dev_get_driver_data(bus);
plat->max_hz = fdtdec_get_int(gd->fdt_blob, node,
"spi-max-frequency",
SUN4I_SPI_DEFAULT_RATE);
@@ -273,7 +300,8
[U-Boot] [PATCH] misc: fs_loader: Replace label with DT phandle
From: Tien Fong Chee
In previously label which will be expanded to the node's full path was
used, and now replacing label with most commonly used DT phandle. The
codes were changed accordingly to the use of DT phandle and supporting
multiple instances.
Signed-off-by: Tien Fong Chee
---
doc/driver-model/fs_firmware_loader.txt | 58 +--
drivers/misc/fs_loader.c| 36 ---
2 files changed, 62 insertions(+), 32 deletions(-)
diff --git a/doc/driver-model/fs_firmware_loader.txt
b/doc/driver-model/fs_firmware_loader.txt
index b9aee84..d9f966e 100644
--- a/doc/driver-model/fs_firmware_loader.txt
+++ b/doc/driver-model/fs_firmware_loader.txt
@@ -1,4 +1,4 @@
-# Copyright (C) 2018 Intel Corporation
+# Copyright (C) 2018-2019 Intel Corporation
#
# SPDX-License-Identifier:GPL-2.0
@@ -46,15 +46,48 @@ Firmware storage device described in device tree source
ubivol = "ubi0";
};
- Then, firmware_loader property would be set with the path of fs_loader
- node under /chosen node such as:
+ Then, firmware-loader property can be added with any device node, which
+ driver would use the firmware loader for loading.
+
+ The value of the firmware-loader property should be set with phandle
+ of the fs-loader node.
+ For example:
+ firmware-loader = <_loader0>;
+
+ If there are majority of devices using the same fs-loader node, then
+ firmware-loader property can be added under /chosen node instead of
+ adding to each of device node.
+
+ For example:
/{
chosen {
- firmware_loader = _loader0;
+ firmware-loader = <_loader0>;
};
};
- However, this driver is also designed to support U-boot environment
+ In each respective driver of devices using firmware loader, the firmware
+ loaded instance should be created by DT phandle.
+
+ For example of getting DT phandle from /chosen and creating instance:
+ chosen_node = ofnode_path("/chosen");
+ if (!ofnode_valid(chosen_node)) {
+ debug("/chosen node was not found.\n");
+ return -ENOENT;
+ }
+
+ phandle_p = ofnode_get_property(chosen_node, "firmware-loader", );
+ if (!phandle_p) {
+ debug("firmware-loader property was not found.\n");
+ return -ENOENT;
+ }
+
+ phandle = fdt32_to_cpu(*phandle_p);
+ ret = uclass_get_device_by_phandle_id(UCLASS_FS_FIRMWARE_LOADER,
+phandle, );
+ if (ret)
+ return ret;
+
+ Firmware loader driver is also designed to support U-boot environment
variables, so all these data from FDT can be overwritten
through the U-boot environment variable during run time.
For examples:
@@ -104,9 +137,12 @@ return:
Description:
The firmware is loaded directly into the buffer pointed to by buf
-Example of creating firmware loader instance and calling
-request_firmware_into_buf API:
- if (uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, )) {
- request_firmware_into_buf(dev, filename, buffer_location,
-buffer_size, offset_ofreading);
- }
+Example of calling request_firmware_into_buf API after creating firmware loader
+instance:
+ ret = uclass_get_device_by_phandle_id(UCLASS_FS_FIRMWARE_LOADER,
+phandle, );
+ if (ret)
+ return ret;
+
+ request_firmware_into_buf(dev, filename, buffer_location, buffer_size,
+offset_ofreading);
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
index a2e3763..f42eeff 100644
--- a/drivers/misc/fs_loader.c
+++ b/drivers/misc/fs_loader.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2018 Intel Corporation
+ * Copyright (C) 2018-2019 Intel Corporation
*
*/
#include
@@ -219,32 +219,26 @@ int request_firmware_into_buf(struct udevice *dev,
static int fs_loader_ofdata_to_platdata(struct udevice *dev)
{
- const char *fs_loader_path;
u32 phandlepart[2];
- fs_loader_path = ofnode_get_chosen_prop("firmware-loader");
+ ofnode fs_loader_node = dev_ofnode(dev);
- if (fs_loader_path) {
- ofnode fs_loader_node;
+ if (ofnode_valid(fs_loader_node)) {
+ struct device_platdata *plat;
- fs_loader_node = ofnode_path(fs_loader_path);
- if (ofnode_valid(fs_loader_node)) {
- struct device_platdata *plat;
- plat = dev->platdata;
-
- if (!ofnode_read_u32_array(fs_loader_node,
- "phandlepart",
-
[U-Boot] [PATCH v2] armv8 : fsl-layerscape : Fix hang when TFA is used.
When TFA is used as EL3 firmware, then u-boot is crashing
because DDR is not coherent.
Changing DDR memory attributes to device type fix the issue.
Signed-off-by: Meenakshi Aggarwal
Signed-off-by: Udit Kumar
---
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index be21685..32f3d2a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -100,9 +100,10 @@ static struct mm_region early_map[] = {
#endif
{ CONFIG_SYS_FSL_DRAM_BASE1, CONFIG_SYS_FSL_DRAM_BASE1,
CONFIG_SYS_FSL_DRAM_SIZE1,
-#if defined(CONFIG_TFABOOT) || \
- (defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD))
- PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+#if defined(CONFIG_TFABOOT)
+ PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE)
+#elif defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD)
+ PTE_BLOCK_MEMTYPE(MT_NORMAL)
#else /* Start with nGnRnE and PXN and UXN to prevent speculative access */
PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | PTE_BLOCK_PXN | PTE_BLOCK_UXN |
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: Add Macronix MX25R6435F SPI NOR flash to flash parameters array
On 14/02/19 10:39 PM, Jagan Teki wrote:
> + Vignesh
>
> On Mon, Jan 7, 2019 at 11:05 AM Ye Li wrote:
>>
>> On i.MX7ULP EVK board, we use MX25R6435F NOR flash, add its parameters
>> and IDs to flash parameter array. Otherwise, the flash probe will fails.
>>
>> Signed-off-by: Ye Li
>> ---
>> drivers/mtd/spi/spi_flash_ids.c | 1 +
This file no longer exists after recent SPI NOR migration. Could you
rebase on the latest? The capabilities flags are now same as kernel.
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mtd/spi/spi_flash_ids.c
>> b/drivers/mtd/spi/spi_flash_ids.c
>> index ad0a0c8..17f9893 100644
>> --- a/drivers/mtd/spi/spi_flash_ids.c
>> +++ b/drivers/mtd/spi/spi_flash_ids.c
>> @@ -94,6 +94,7 @@ const struct spi_flash_info spi_flash_ids[] = {
>> {"mx25u25635f",INFO(0xc22539, 0x0, 64 * 1024, 512, RD_FULL |
>> WR_QPP) },
>> {"mx66u51235f",INFO(0xc2253a, 0x0, 64 * 1024, 1024, RD_FULL |
>> WR_QPP) },
>> {"mx66l1g45g", INFO(0xc2201b, 0x0, 64 * 1024, 2048, RD_FULL |
>> WR_QPP) },
>> + {"mx25r6435f", INFO(0xc22817, 0x0, 64 * 1024, 128, RD_FULL |
>> SECT_4K) },
>
> Look like this would also support WR_QPP, how about updating the same?
>
--
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v2, 1/3] mmc: fsl_esdhc: add esdhc_imx flag
> -Original Message-
> From: Y.b. Lu
> Sent: 2019年2月15日 10:26
> To: u-boot@lists.denx.de
> Cc: Jaehoon Chung ; Prabhakar Kushwaha
> ; Peng Fan ; Y.b. Lu
>
> Subject: [v2, 1/3] mmc: fsl_esdhc: add esdhc_imx flag
>
> The fsl_esdhc driver was for Freescale eSDHC on MPC83XX/MPC85XX initially.
> The later QoriQ series processors (which were evolutions of
> MPC83XX/MPC85XX) and i.MX series processors were using this driver for
> their eSDHCs too.
>
> So there are two evolution directions for eSDHC now. For the two series
> processors, the eSDHCs are becoming more and more different.
> We should have split it into two drivers, like them
> (sdhci-of-esdhc.c/sdhci-esdhc-imx.c) in linux kernel. But it seemed to be a
> lot
> of work now. So let's keep as it is. Be very careful to change the driver if
> the
> changes are not common for all eSDHCs, and clarify i.MX eSDHC specific
> things to distingush them with QorIQ eSDHC.
>
> This patch is to added an esdhc_imx flag for the development of i.MX eSDHC,
> to distinguish it with QoriQ eSDHC.
>
> Signed-off-by: Yangbo Lu
> ---
> Changes for v2:
> - Converted to use device_is_compatible().
> ---
> drivers/mmc/fsl_esdhc.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index
> 21fa2ab1d4..a647bc7f1c 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -147,6 +147,7 @@ struct fsl_esdhc_priv {
> struct gpio_desc cd_gpio;
> struct gpio_desc wp_gpio;
> #endif
> + bool esdhc_imx;
> };
>
> /* Return the XFERTYP flags for a given command and data packet */ @@
> -1462,6 +1463,16 @@ static int fsl_esdhc_probe(struct udevice *dev)
> priv->caps = data->caps;
> }
>
> + /*
> + * This is to specify whether current eSDHC is an i.MX eSDHC,
> + * since the i.MX eSDHC has been becoming more and more different
> + * with QorIQ eSDHC and initial MPC83XX/MPC85XX.
> + */
> + if (!device_is_compatible(dev, "fsl,esdhc"))
> + priv->esdhc_imx = true;
> + else
> + priv->esdhc_imx = false;
> +
> val = dev_read_u32_default(dev, "bus-width", -1);
> if (val == 8)
> priv->bus_width = 8;
Reviewed-by: Peng Fan
> --
> 2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx6ul_14x14_evk: Simplify the PMIC register writes
> -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: 2019年2月14日 21:36 > To: sba...@denx.de > Cc: u-boot@lists.denx.de; Peng Fan ; Fabio Estevam > > Subject: [PATCH v2] mx6ul_14x14_evk: Simplify the PMIC register writes > > There is no need to store the values written to the PMIC inside the 'reg' > variable. Make it simpler by writing the values directly. > > Signed-off-by: Fabio Estevam > --- > Changes since v1: > - Remove 1/2 notation, since this is a standalome patch > - Add Peng Fan on Cc > > board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c > b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c > index 595ad76bbe..636c008993 100644 > --- a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c > +++ b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c > @@ -86,16 +86,13 @@ int power_init_board(void) > pmic_reg_write(dev, PFUZE3000_LDOGCTL, reg); > > /* SW1B step ramp up time from 2us to 4us/25mV */ > - reg = 0x40; > - pmic_reg_write(dev, PFUZE3000_SW1BCONF, reg); > + pmic_reg_write(dev, PFUZE3000_SW1BCONF, 0x40); > > /* SW1B mode to APS/PFM */ > - reg = 0xc; > - pmic_reg_write(dev, PFUZE3000_SW1BMODE, reg); > + pmic_reg_write(dev, PFUZE3000_SW1BMODE, 0xc); > > /* SW1B standby voltage set to 0.975V */ > - reg = 0xb; > - pmic_reg_write(dev, PFUZE3000_SW1BSTBY, reg); > + pmic_reg_write(dev, PFUZE3000_SW1BSTBY, 0xb); Reviewed-by: Peng Fan > > return 0; > } > -- > 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] mmc: fsl_esdhc: add esdhc_imx flag
> -Original Message- > From: Peng Fan > Sent: Thursday, February 14, 2019 5:11 PM > To: Y.b. Lu ; u-boot@lists.denx.de > Cc: Jaehoon Chung ; Prabhakar Kushwaha > > Subject: RE: [PATCH 1/3] mmc: fsl_esdhc: add esdhc_imx flag > > > > > -Original Message- > > From: Y.b. Lu > > Sent: 2019年2月14日 16:21 > > To: u-boot@lists.denx.de > > Cc: Jaehoon Chung ; Prabhakar Kushwaha > > ; Peng Fan ; Y.b. Lu > > > > Subject: [PATCH 1/3] mmc: fsl_esdhc: add esdhc_imx flag > > [...] > > + /* > > +* This is to specify whether current eSDHC is an i.MX eSDHC, > > +* since the i.MX eSDHC has been becoming more and more different > > +* with QorIQ eSDHC and initial MPC83XX/MPC85XX. > > +*/ > > + if (!fdt_node_check_compatible(fdt, node, "fsl,esdhc")) > > + priv->esdhc_imx = true; > > + else > > + priv->esdhc_imx = false; > > Suggest use device_is_compatible(dev, "fsl,esdhc") > > Regards, > Peng. > [Y.b. Lu] Sent out v2, and converted to use device_is_compatible(). Thanks a lot. > > + > > val = dev_read_u32_default(dev, "bus-width", -1); > > if (val == 8) > > priv->bus_width = 8; > > -- > > 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [v2, 2/3] mmc: fsl_esdhc: clean up register definition
The fsl_esdhc driver was for Freescale eSDHC on MPC83XX/MPC85XX
initially. The later QoriQ series processors (which are evolutions
of MPC83XX/MPC85XX) and i.MX series processors were using this
driver for their eSDHCs too.
So there are two evolution directions for eSDHC now. For the two
series processors, the eSDHCs are becoming more and more different.
We should have split it into two drivers, like them
(sdhci-of-esdhc.c/sdhci-esdhc-imx.c) in linux kernel. But it seemed
to be a lot of work now. So let's keep as it is. Be very careful to
change the driver if the changes are not common for all eSDHCs, and
clarify i.MX eSDHC specific things to distingush them with QorIQ
eSDHC.
This patch is to clean up register definition. Besides the QorIQ
eSDHC register definition, the i.MX eSDHC specific registers should
be clarified.
Signed-off-by: Yangbo Lu
Acked-by: Peng Fan
---
Changes for v2:
- Added "Acked-by: Peng Fan".
---
drivers/mmc/fsl_esdhc.c | 66 ++---
include/fsl_esdhc.h | 208 ++--
2 files changed, 149 insertions(+), 125 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index a647bc7f1c..e9622ce9a4 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -54,23 +54,23 @@ struct fsl_esdhc {
uintautoc12err; /* Auto CMD error status register */
uinthostcapblt; /* Host controller capabilities register */
uintwml;/* Watermark level register */
- uintmixctrl;/* For USDHC */
+ uintmixctrl;/* For i.MX USDHC */
charreserved1[4]; /* reserved */
uintfevt; /* Force event register */
uintadmaes; /* ADMA error status register */
uintadsaddr;/* ADMA system address register */
charreserved2[4];
- uintdllctrl;
- uintdllstat;
- uintclktunectrlstatus;
+ uintdllctrl;/* For i.MX USDHC */
+ uintdllstat;/* For i.MX USDHC */
+ uintclktunectrlstatus; /* For i.MX USDHC */
charreserved3[4];
- uintstrobe_dllctrl;
- uintstrobe_dllstat;
+ uintstrobe_dllctrl; /* For i.MX USDHC */
+ uintstrobe_dllstat; /* For i.MX USDHC */
charreserved4[72];
- uintvendorspec;
- uintmmcboot;
- uintvendorspec2;
- uinttuning_ctrl;/* on i.MX6/7/8 */
+ uintvendorspec; /* For i.MX USDHC */
+ uintmmcboot;/* For i.MX USDHC */
+ uintvendorspec2;/* For i.MX USDHC */
+ uinttuning_ctrl;/* For i.MX USDHC, on i.MX6/7/8 */
charreserved5[44];
uinthostver;/* Host controller version register */
charreserved6[4]; /* reserved */
@@ -80,11 +80,11 @@ struct fsl_esdhc {
charreserved8[4]; /* reserved */
uinthostcapblt2;/* Host controller capabilities register 2 */
charreserved9[8]; /* reserved */
- uinttcr;/* Tuning control register */
+ uinttbctl; /* Tuning block control register */
charreserved10[28]; /* reserved */
uintsddirctl; /* SD direction control register */
charreserved11[712];/* reserved */
- uintscr;/* eSDHC control register */
+ uintesdhcctl; /* eSDHC control register */
};
struct fsl_esdhc_plat {
@@ -496,7 +496,7 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc,
/* Switch voltage to 1.8V if CMD11 succeeded */
if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
- esdhc_setbits32(>vendorspec, ESDHC_VENDORSPEC_VSELECT);
+ esdhc_setbits32(>vendorspec, VENDORSPEC_VSELECT);
printf("Run CMD11 1.8V switch\n");
/* Sleep for 5 ms - max time for card to switch to 1.8V */
@@ -728,23 +728,23 @@ static void esdhc_set_strobe_dll(struct mmc *mmc)
struct fsl_esdhc *regs = priv->esdhc_regs;
u32 val;
- if (priv->clock > ESDHC_STROBE_DLL_CLK_FREQ) {
- writel(ESDHC_STROBE_DLL_CTRL_RESET, >strobe_dllctrl);
+ if (priv->clock > STROBE_DLL_CLK_FREQ) {
+ writel(STROBE_DLL_CTRL_RESET, >strobe_dllctrl);
/*
* enable strobe dll ctrl and adjust the delay target
* for the uSDHC loopback read clock
*/
- val = ESDHC_STROBE_DLL_CTRL_ENABLE |
+ val = STROBE_DLL_CTRL_ENABLE |
(priv->strobe_dll_delay_target <<
-ESDHC_STROBE_DLL_CTRL_SLV_DLY_TARGET_SHIFT);
+STROBE_DLL_CTRL_SLV_DLY_TARGET_SHIFT);
writel(val, >strobe_dllctrl);
/* wait 1us to make sure strobe dll status register stable */
mdelay(1);
[U-Boot] [v2, 3/3] mmc: fsl_esdhc: clarify i.MX eSDHC specific functions
A previous patch had added SDR104/HS200 support for fsl_esdhc.
However this was only for i.MX eSDHC, and QorIQ eSDHC used
different registers and method.
This patch is to clarify i.MX eSDHC specific functions defined
in that patch, and to use them only for i.MX eSDHC. The QorIQ
eSDHC SDR104/HS200 support will be added in the future.
Fixes: 51313b49f2b8 (mmc: fsl_esdhc: support SDR104 and HS200)
Signed-off-by: Yangbo Lu
Reviewed-by: Peng Fan
---
Changes for v2:
- Added "Reviewed-by: Peng Fan".
---
drivers/mmc/fsl_esdhc.c | 79 +
1 file changed, 41 insertions(+), 38 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index e9622ce9a4..92924b63ac 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -682,7 +682,7 @@ static void esdhc_clock_control(struct fsl_esdhc_priv
*priv, bool enable)
#endif
#ifdef MMC_SUPPORTS_TUNING
-static int esdhc_change_pinstate(struct udevice *dev)
+static int esdhc_imx_change_pinstate(struct udevice *dev)
{
struct fsl_esdhc_priv *priv = dev_get_priv(dev);
int ret;
@@ -708,7 +708,7 @@ static int esdhc_change_pinstate(struct udevice *dev)
return ret;
}
-static void esdhc_reset_tuning(struct mmc *mmc)
+static void esdhc_imx_reset_tuning(struct mmc *mmc)
{
struct fsl_esdhc_priv *priv = dev_get_priv(mmc->dev);
struct fsl_esdhc *regs = priv->esdhc_regs;
@@ -722,7 +722,7 @@ static void esdhc_reset_tuning(struct mmc *mmc)
}
}
-static void esdhc_set_strobe_dll(struct mmc *mmc)
+static void esdhc_imx_set_strobe_dll(struct mmc *mmc)
{
struct fsl_esdhc_priv *priv = dev_get_priv(mmc->dev);
struct fsl_esdhc *regs = priv->esdhc_regs;
@@ -749,7 +749,7 @@ static void esdhc_set_strobe_dll(struct mmc *mmc)
}
}
-static int esdhc_set_timing(struct mmc *mmc)
+static int esdhc_imx_set_timing(struct mmc *mmc)
{
struct fsl_esdhc_priv *priv = dev_get_priv(mmc->dev);
struct fsl_esdhc *regs = priv->esdhc_regs;
@@ -761,13 +761,13 @@ static int esdhc_set_timing(struct mmc *mmc)
switch (mmc->selected_mode) {
case MMC_LEGACY:
case SD_LEGACY:
- esdhc_reset_tuning(mmc);
+ esdhc_imx_reset_tuning(mmc);
writel(mixctrl, >mixctrl);
break;
case MMC_HS_400:
mixctrl |= MIX_CTRL_DDREN | MIX_CTRL_HS400_EN;
writel(mixctrl, >mixctrl);
- esdhc_set_strobe_dll(mmc);
+ esdhc_imx_set_strobe_dll(mmc);
break;
case MMC_HS:
case MMC_HS_52:
@@ -791,14 +791,13 @@ static int esdhc_set_timing(struct mmc *mmc)
priv->mode = mmc->selected_mode;
- return esdhc_change_pinstate(mmc->dev);
+ return esdhc_imx_change_pinstate(mmc->dev);
}
-static int esdhc_set_voltage(struct mmc *mmc)
+static int esdhc_imx_set_voltage(struct mmc *mmc)
{
struct fsl_esdhc_priv *priv = dev_get_priv(mmc->dev);
struct fsl_esdhc *regs = priv->esdhc_regs;
- int ret;
priv->signal_voltage = mmc->signal_voltage;
switch (mmc->signal_voltage) {
@@ -975,18 +974,18 @@ static int esdhc_set_ios_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc)
#endif
}
- if (priv->mode != mmc->selected_mode) {
- ret = esdhc_set_timing(mmc);
+ if (priv->esdhc_imx && priv->mode != mmc->selected_mode) {
+ ret = esdhc_imx_set_timing(mmc);
if (ret) {
- printf("esdhc_set_timing error %d\n", ret);
+ printf("esdhc_imx_set_timing error %d\n", ret);
return ret;
}
}
- if (priv->signal_voltage != mmc->signal_voltage) {
- ret = esdhc_set_voltage(mmc);
+ if (priv->esdhc_imx && priv->signal_voltage != mmc->signal_voltage) {
+ ret = esdhc_imx_set_voltage(mmc);
if (ret) {
- printf("esdhc_set_voltage error %d\n", ret);
+ printf("esdhc_imx_set_voltage error %d\n", ret);
return ret;
}
}
@@ -1267,20 +1266,21 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
- writel(0, >dllctrl);
- if (priv->flags & ESDHC_FLAG_USDHC) {
- if (priv->flags & ESDHC_FLAG_STD_TUNING) {
- u32 val = readl(>tuning_ctrl);
-
- val |= STD_TUNING_EN;
- val &= ~TUNING_START_TAP_MASK;
- val |= priv->tuning_start_tap;
- val &= ~TUNING_STEP_MASK;
- val |= (priv->tuning_step) << TUNING_STEP_SHIFT;
- writel(val, >tuning_ctrl);
+ if (priv->esdhc_imx) {
+ writel(0, >dllctrl);
+ if (priv->flags & ESDHC_FLAG_USDHC) {
+
[U-Boot] [v2, 1/3] mmc: fsl_esdhc: add esdhc_imx flag
The fsl_esdhc driver was for Freescale eSDHC on MPC83XX/MPC85XX
initially. The later QoriQ series processors (which were evolutions
of MPC83XX/MPC85XX) and i.MX series processors were using this
driver for their eSDHCs too.
So there are two evolution directions for eSDHC now. For the two
series processors, the eSDHCs are becoming more and more different.
We should have split it into two drivers, like them
(sdhci-of-esdhc.c/sdhci-esdhc-imx.c) in linux kernel. But it seemed
to be a lot of work now. So let's keep as it is. Be very careful to
change the driver if the changes are not common for all eSDHCs, and
clarify i.MX eSDHC specific things to distingush them with QorIQ
eSDHC.
This patch is to added an esdhc_imx flag for the development of i.MX
eSDHC, to distinguish it with QoriQ eSDHC.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- Converted to use device_is_compatible().
---
drivers/mmc/fsl_esdhc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 21fa2ab1d4..a647bc7f1c 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -147,6 +147,7 @@ struct fsl_esdhc_priv {
struct gpio_desc cd_gpio;
struct gpio_desc wp_gpio;
#endif
+ bool esdhc_imx;
};
/* Return the XFERTYP flags for a given command and data packet */
@@ -1462,6 +1463,16 @@ static int fsl_esdhc_probe(struct udevice *dev)
priv->caps = data->caps;
}
+ /*
+* This is to specify whether current eSDHC is an i.MX eSDHC,
+* since the i.MX eSDHC has been becoming more and more different
+* with QorIQ eSDHC and initial MPC83XX/MPC85XX.
+*/
+ if (!device_is_compatible(dev, "fsl,esdhc"))
+ priv->esdhc_imx = true;
+ else
+ priv->esdhc_imx = false;
+
val = dev_read_u32_default(dev, "bus-width", -1);
if (val == 8)
priv->bus_width = 8;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: da8xxevm: Add NAND instructions for da850-evm to README
The README.da850 file continues information on how to burn NAND for the LCDK, but not the DA850-EVM. This patch adds both the commands and dip switch instructions for burning and booting NAND. Signed-off-by: Adam Ford diff --git a/board/davinci/da8xxevm/README.da850 b/board/davinci/da8xxevm/README.da850 index f24e8b5342..5775b7d80f 100644 --- a/board/davinci/da8xxevm/README.da850 +++ b/board/davinci/da8xxevm/README.da850 @@ -88,6 +88,14 @@ In this case the commands would be simplified to: U-Boot > nand erase.part bootloader U-Boot > nand write 0xc070 bootloader +On the DA850-EVM, NAND can also be written with SW7:7-8 ON and + + sudo mono sfh_OMAP-L138.exe -targetType AM1808 -p /dev/ttyUSB0 \ + -flash_noubl -flashType NAND ~/src/u-boot/u-boot.ais + +To boot the DA850-EVM from NAND, SW7:5 should be switched on and all others +off. + Flashing the images to MMC == If the boot pins are set to boot from mmc, the RBL will try to load the -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] x530: Enable watchdog
We've seen some issues with the x530 under extreme conditions where the DDR gets into a bad state. Generally this results in an application crash, kernel panic then a lock-up in u-boot (generally just as the SPL hands off to u-boot proper). Enabling the watchdog prevents the lock up and will let the DDR training have another go. Sometimes this recovers but even a reboot loop is better than a complete lockup. Chris Packham (2): watchdog: orion_wdt: support SPL usage arm: mvebu: x530: Enable watchdog in SPL and U-Boot arch/arm/dts/armada-385-atl-x530-u-boot.dtsi | 4 ++ board/alliedtelesis/x530/x530.c | 48 configs/x530_defconfig | 5 ++ drivers/watchdog/orion_wdt.c | 4 +- 4 files changed, 58 insertions(+), 3 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] watchdog: orion_wdt: support SPL usage
When run from the SPL the mvebu targets are using the hardware default offset for the SoC peripherals. devfdt_get_addr_size_index() understands how to deal with this via dm_get_translation_offset() so use this instead of fdtdec_get_addr_size_auto_noparent(). Signed-off-by: Chris Packham --- drivers/watchdog/orion_wdt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c index a0df02d10382..c1add3e7c121 100644 --- a/drivers/watchdog/orion_wdt.c +++ b/drivers/watchdog/orion_wdt.c @@ -114,9 +114,7 @@ static inline bool save_reg_from_ofdata(struct udevice *dev, int index, fdt_addr_t addr; fdt_size_t off; - addr = fdtdec_get_addr_size_auto_noparent( - gd->fdt_blob, dev_of_offset(dev), "reg", index, , true); - + addr = devfdt_get_addr_size_index(dev, index, ); if (addr == FDT_ADDR_T_NONE) return false; -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] arm: mvebu: x530: Enable watchdog in SPL and U-Boot
Enable the hardware watchdog to guard against system lock ups when
running in the SPL or U-Boot. Stop the watchdog just before booting so
that the OS.
Signed-off-by: Chris Packham
---
arch/arm/dts/armada-385-atl-x530-u-boot.dtsi | 4 ++
board/alliedtelesis/x530/x530.c | 48
configs/x530_defconfig | 5 ++
3 files changed, 57 insertions(+)
diff --git a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
index 7074a73537fa..79b694cb84bc 100644
--- a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
+++ b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
@@ -11,3 +11,7 @@
{
u-boot,dm-pre-reloc;
};
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c
index d7d1942fe686..1b22b6307cd2 100644
--- a/board/alliedtelesis/x530/x530.c
+++ b/board/alliedtelesis/x530/x530.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,6 +25,10 @@ DECLARE_GLOBAL_DATA_PTR;
#define CONFIG_NVS_LOCATION0xf480
#define CONFIG_NVS_SIZE(512 << 10)
+#ifdef CONFIG_WATCHDOG
+static struct udevice *watchdog_dev;
+#endif
+
static struct serdes_map board_serdes_map[] = {
{PEX0, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
{DEFAULT_SERDES, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
@@ -75,6 +80,10 @@ struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
int board_early_init_f(void)
{
+#ifdef CONFIG_WATCHDOG
+ watchdog_dev = NULL;
+#endif
+
/* Configure MPP */
writel(0x, MVEBU_MPP_BASE + 0x00);
writel(0x, MVEBU_MPP_BASE + 0x04);
@@ -88,6 +97,17 @@ int board_early_init_f(void)
return 0;
}
+void spl_board_init(void)
+{
+#ifdef CONFIG_WATCHDOG
+ int ret;
+
+ ret = uclass_get_device(UCLASS_WDT, 0, _dev);
+ if (!ret)
+ wdt_start(watchdog_dev, 2500ULL * 120, 0);
+#endif
+}
+
int board_init(void)
{
/* address of boot parameters */
@@ -100,9 +120,37 @@ int board_init(void)
/* DEV_READYn is not needed for NVS, ignore it when accessing CS1 */
writel(0x4001, MVEBU_DEV_BUS_BASE + 0xc8);
+ spl_board_init();
+
return 0;
}
+void arch_preboot_os(void)
+{
+#ifdef CONFIG_WATCHDOG
+ wdt_stop(watchdog_dev);
+#endif
+}
+
+#ifdef CONFIG_WATCHDOG
+void watchdog_reset(void)
+{
+ static ulong next_reset = 0;
+ ulong now;
+
+ if (!watchdog_dev)
+ return;
+
+ now = timer_get_us();
+
+ /* Do not reset the watchdog too often */
+ if (now > next_reset) {
+ wdt_reset(watchdog_dev);
+ next_reset = now + 1000;
+ }
+}
+#endif
+
static int led_7seg_init(unsigned int segments)
{
int node;
diff --git a/configs/x530_defconfig b/configs/x530_defconfig
index 25b9e885d8e6..3bc37b9bee11 100644
--- a/configs/x530_defconfig
+++ b/configs/x530_defconfig
@@ -19,6 +19,8 @@ CONFIG_SILENT_CONSOLE=y
CONFIG_SILENT_U_BOOT_ONLY=y
CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC=y
CONFIG_MISC_INIT_R=y
+CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
CONFIG_CMD_MEMINFO=y
# CONFIG_CMD_FLASH is not set
CONFIG_CMD_GPIO=y
@@ -70,3 +72,6 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_HOST_ETHER=y
CONFIG_USB_ETHER_ASIX=y
CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_WATCHDOG=y
+CONFIG_WDT=y
+CONFIG_WDT_ORION=y
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: tegra: enable ums on nyan boards
Am 15.02.2019 00:42 schrieb Stephen Warren :
>
> On 2/14/19 4:25 PM, Tristan Bastian wrote:
> > This patch enables UMS on the nyan devices like the nyan-big.
> > A patch like this has been sent in by Stephen Warren some time ago for
> > other tegra devices: commit e6607cffef965011ef0ddc0fbe6f4b7c0d53aeec
> > But the nyan devices never received that functionality.
> >
> > v2: fixed corrupted patch
>
> That should be below the ---, but I assume Tom can fix that when
> applying the patch.
>
> Acked-by: Stephen Warren
> but...
>
> > diff --git a/arch/arm/dts/tegra124-nyan.dtsi
> > b/arch/arm/dts/tegra124-nyan.dtsi
> > index 51895e4816..2b28fe1497 100644
> > --- a/arch/arm/dts/tegra124-nyan.dtsi
> > +++ b/arch/arm/dts/tegra124-nyan.dtsi
> > @@ -414,6 +414,7 @@
> >
> > usb@7d00 { /* Rear external USB port. */
> > status = "okay";
> > + dr_mode = "otg";
> > nvidia,vbus-gpio = < TEGRA_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
> > };
>
> Do you also need to add aliases for the USB nodes, like I did in my
> similar patch:
>
> > diff --git a/arch/arm/dts/tegra124-jetson-tk1.dts
> > b/arch/arm/dts/tegra124-jetson-tk1.dts
> > index 52e8c0e59c6b..464287e03ecf 100644
> > --- a/arch/arm/dts/tegra124-jetson-tk1.dts
> > +++ b/arch/arm/dts/tegra124-jetson-tk1.dts
> > @@ -17,7 +17,8 @@
> > sdhci1 = "/sdhci@700b0400";
> > spi0 = "/spi@7000d400";
> > spi1 = "/spi@7000da00";
> > - usb0 = "/usb@7d008000";
> > + usb0 = "/usb@7d00";
> > + usb1 = "/usb@7d008000";
> > };
At least for nyan-big this is done in the: tegra124-nyan-big.dts file.
So there is no need to also do this here.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: dts: uniphier: sync with Linux 5.0-rc2
Signed-off-by: Masahiro Yamada
---
arch/arm/dts/uniphier-ld20.dtsi | 11 ---
arch/arm/dts/uniphier-ld4.dtsi | 14 ++
arch/arm/dts/uniphier-pro4.dtsi | 16
arch/arm/dts/uniphier-pxs2.dtsi | 6 --
arch/arm/dts/uniphier-sld8.dtsi | 14 ++
5 files changed, 52 insertions(+), 9 deletions(-)
diff --git a/arch/arm/dts/uniphier-ld20.dtsi b/arch/arm/dts/uniphier-ld20.dtsi
index b9ed613..a411f4a 100644
--- a/arch/arm/dts/uniphier-ld20.dtsi
+++ b/arch/arm/dts/uniphier-ld20.dtsi
@@ -206,13 +206,10 @@
cooling-maps {
map0 {
trip = <_alert>;
- cooling-device = <
- THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
- };
- map1 {
- trip = <_alert>;
- cooling-device = <
- THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ cooling-device = <
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
};
};
};
diff --git a/arch/arm/dts/uniphier-ld4.dtsi b/arch/arm/dts/uniphier-ld4.dtsi
index b73d594..c2706ce 100644
--- a/arch/arm/dts/uniphier-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ld4.dtsi
@@ -235,6 +235,16 @@
};
};
+ dmac: dma-controller@5a00 {
+ compatible = "socionext,uniphier-mio-dmac";
+ reg = <0x5a00 0x1000>;
+ interrupts = <0 68 4>, <0 68 4>, <0 69 4>, <0 70 4>,
+<0 71 4>, <0 72 4>, <0 73 4>;
+ clocks = <_clk 7>;
+ resets = <_rst 7>;
+ #dma-cells = <1>;
+ };
+
sd: sdhc@5a40 {
compatible = "socionext,uniphier-sd-v2.91";
status = "disabled";
@@ -246,6 +256,8 @@
clocks = <_clk 0>;
reset-names = "host", "bridge";
resets = <_rst 0>, <_rst 3>;
+ dma-names = "rx-tx";
+ dmas = < 4>;
bus-width = <4>;
cap-sd-highspeed;
sd-uhs-sdr12;
@@ -263,6 +275,8 @@
clocks = <_clk 1>;
reset-names = "host", "bridge", "hw";
resets = <_rst 1>, <_rst 4>, <_rst 6>;
+ dma-names = "rx-tx";
+ dmas = < 6>;
bus-width = <8>;
cap-mmc-highspeed;
cap-mmc-hw-reset;
diff --git a/arch/arm/dts/uniphier-pro4.dtsi b/arch/arm/dts/uniphier-pro4.dtsi
index ef34208..d090fc7 100644
--- a/arch/arm/dts/uniphier-pro4.dtsi
+++ b/arch/arm/dts/uniphier-pro4.dtsi
@@ -269,6 +269,16 @@
};
};
+ dmac: dma-controller@5a00 {
+ compatible = "socionext,uniphier-mio-dmac";
+ reg = <0x5a00 0x1000>;
+ interrupts = <0 68 4>, <0 68 4>, <0 69 4>, <0 70 4>,
+<0 71 4>, <0 72 4>, <0 73 4>, <0 74 4>;
+ clocks = <_clk 7>;
+ resets = <_rst 7>;
+ #dma-cells = <1>;
+ };
+
sd: sdhc@5a40 {
compatible = "socionext,uniphier-sd-v2.91";
status = "disabled";
@@ -280,6 +290,8 @@
clocks = <_clk 0>;
reset-names = "host", "bridge";
resets = <_rst 0>, <_rst 3>;
+ dma-names = "rx-tx";
+ dmas = < 4>;
bus-width = <4>;
cap-sd-highspeed;
sd-uhs-sdr12;
@@ -297,6 +309,8 @@
clocks = <_clk 1>;
reset-names = "host", "bridge", "hw";
resets = <_rst 1>, <_rst 4>, <_rst 6>;
+ dma-names = "rx-tx";
+ dmas = < 5>;
bus-width = <8>;
cap-mmc-highspeed;
cap-mmc-hw-reset;
@@ -313,6 +327,8 @@
clocks = <_clk 2>;
reset-names = "host", "bridge";
resets = <_rst 2>,
Re: [U-Boot] [PATCH v2 8/8] spi: sun4i: Driver cleanup
On 14/02/2019 08:36, Jagan Teki wrote: > - drop unused macros. > - use base instead of base_addr, for better code readability Actually this part is now pretty pointless, since we use it only a few times, and base_addr is actually more descriptive than just "base". > - move .probe and .ofdata_to_platdata functions in required > places to add platdata support in future. I don't get the reason for that move? > - use sentinel sun4i_spi_ids. > > Signed-off-by: Jagan Teki > --- > drivers/spi/sun4i_spi.c | 190 +--- > image.map | 4 + Please keep this file for you ;-) Cheers, Andre > 2 files changed, 84 insertions(+), 110 deletions(-) > create mode 100644 image.map > > diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c > index 96d0db5929..36afcf2c73 100644 > --- a/drivers/spi/sun4i_spi.c > +++ b/drivers/spi/sun4i_spi.c > @@ -33,57 +33,16 @@ > > #include > > -#define SUN4I_RXDATA_REG 0x00 > - > -#define SUN4I_TXDATA_REG 0x04 > - > -#define SUN4I_CTL_REG0x08 > -#define SUN4I_CTL_ENABLE BIT(0) > -#define SUN4I_CTL_MASTER BIT(1) > -#define SUN4I_CTL_CPHA BIT(2) > -#define SUN4I_CTL_CPOL BIT(3) > -#define SUN4I_CTL_CS_ACTIVE_LOW BIT(4) > -#define SUN4I_CTL_LMTF BIT(6) > -#define SUN4I_CTL_TF_RST BIT(8) > -#define SUN4I_CTL_RF_RST BIT(9) > -#define SUN4I_CTL_XCHBIT(10) > -#define SUN4I_CTL_CS_MASK0x3000 > -#define SUN4I_CTL_CS(cs) (((cs) << 12) & SUN4I_CTL_CS_MASK) > -#define SUN4I_CTL_DHBBIT(15) > -#define SUN4I_CTL_CS_MANUAL BIT(16) > -#define SUN4I_CTL_CS_LEVEL BIT(17) > -#define SUN4I_CTL_TP BIT(18) > - > -#define SUN4I_INT_CTL_REG0x0c > -#define SUN4I_INT_CTL_RF_F34 BIT(4) > -#define SUN4I_INT_CTL_TF_E34 BIT(12) > -#define SUN4I_INT_CTL_TC BIT(16) > - > -#define SUN4I_INT_STA_REG0x10 > - > -#define SUN4I_DMA_CTL_REG0x14 > - > -#define SUN4I_WAIT_REG 0x18 > - > -#define SUN4I_CLK_CTL_REG0x1c > -#define SUN4I_CLK_CTL_CDR2_MASK 0xff > -#define SUN4I_CLK_CTL_CDR2(div) ((div) & > SUN4I_CLK_CTL_CDR2_MASK) > -#define SUN4I_CLK_CTL_CDR1_MASK 0xf > -#define SUN4I_CLK_CTL_CDR1(div) (((div) & > SUN4I_CLK_CTL_CDR1_MASK) << 8) > -#define SUN4I_CLK_CTL_DRSBIT(12) > - > -#define SUN4I_MAX_XFER_SIZE 0xff > - > -#define SUN4I_BURST_CNT_REG 0x20 > -#define SUN4I_BURST_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE) > - > -#define SUN4I_XMIT_CNT_REG 0x24 > -#define SUN4I_XMIT_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE) > +DECLARE_GLOBAL_DATA_PTR; > > -#define SUN4I_FIFO_STA_REG 0x28 > -#define SUN4I_FIFO_STA_RF_CNT_BITS 0 > -#define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f > -#define SUN4I_FIFO_STA_TF_CNT_BITS 16 > +/* sun4i spi registers */ > +#define SUN4I_RXDATA_REG 0x00 > +#define SUN4I_TXDATA_REG 0x04 > +#define SUN4I_CTL_REG0x08 > +#define SUN4I_CLK_CTL_REG0x1c > +#define SUN4I_BURST_CNT_REG 0x20 > +#define SUN4I_XMIT_CNT_REG 0x24 > +#define SUN4I_FIFO_STA_REG 0x28 > > /* sun6i spi registers */ > #define SUN6I_GBL_CTL_REG0x04 > @@ -97,12 +56,25 @@ > #define SUN6I_TXDATA_REG 0x200 > #define SUN6I_RXDATA_REG 0x300 > > -#define SUN4I_SPI_MAX_RATE 2400 > -#define SUN4I_SPI_MIN_RATE 3000 > -#define SUN4I_SPI_DEFAULT_RATE 100 > -#define SUN4I_SPI_TIMEOUT_US 100 > +/* sun spi bits */ > +#define SUN4I_CTL_ENABLE BIT(0) > +#define SUN4I_CTL_MASTER BIT(1) > +#define SUN4I_CLK_CTL_CDR2_MASK 0xff > +#define SUN4I_CLK_CTL_CDR2(div) ((div) & > SUN4I_CLK_CTL_CDR2_MASK) > +#define SUN4I_CLK_CTL_CDR1_MASK 0xf > +#define SUN4I_CLK_CTL_CDR1(div) (((div) & > SUN4I_CLK_CTL_CDR1_MASK) << 8) > +#define SUN4I_CLK_CTL_DRSBIT(12) > +#define SUN4I_MAX_XFER_SIZE 0xff > +#define SUN4I_BURST_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE) > +#define SUN4I_XMIT_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE) > +#define SUN4I_FIFO_STA_RF_CNT_BITS 0 > + > +#define SUN4I_SPI_MAX_RATE 2400 > +#define SUN4I_SPI_MIN_RATE 3000 > +#define SUN4I_SPI_DEFAULT_RATE 100 > +#define SUN4I_SPI_TIMEOUT_US 100 > > -#define SPI_REG(priv, reg) ((priv)->base_addr + \ > +#define SPI_REG(priv, reg) ((priv)->base + \ > (priv)->variant->regs[reg]) > #define SPI_BIT(priv, bit) ((priv)->variant->bits[bit]) > #define SPI_CS(cs, priv) (((cs) << SPI_BIT(priv, > SPI_TCR_CS_SEL)) & \ > @@ -146,7 +118,7 @@ struct
Re: [U-Boot] [PATCH v2 7/8] spi: sun4: Add A31 spi controller support
On 14/02/2019 08:36, Jagan Teki wrote:
Hi,
> Add A31 spi controller support for existing sun4i_spi driver via driver
> data, this would simply add A31 register along with proper register bits
> via enum sets.
>
> Signed-off-by: Jagan Teki
> ---
> drivers/spi/Kconfig | 4 +-
> drivers/spi/sun4i_spi.c | 95 -
> 2 files changed, 96 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index dc561eae4a..c008c5190a 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -220,9 +220,9 @@ config STM32_QSPI
> this ST IP core.
>
> config SUN4I_SPI
I wonder if we should use the opportunity to change this to SUNXI_SPI.
It's only used one more time in the Makefile, so an easy change.
> - bool "Allwinner A10 SoCs SPI controller"
> + bool "Allwinner A10/A31 SoCs SPI controller"
And H3 and A64, ... So you could just drop the numbers and speak of
"Allwinner SoCs SPI controllers"
> help
> - SPI driver for Allwinner sun4i, sun5i and sun7i SoCs
> + This enables using the SPI controller on the Allwinner A10/A31 SoCs.
>
> config TEGRA114_SPI
> bool "nVidia Tegra114 SPI driver"
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index 4f43cc39fb..96d0db5929 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -84,6 +85,18 @@
> #define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
> #define SUN4I_FIFO_STA_TF_CNT_BITS 16
>
> +/* sun6i spi registers */
> +#define SUN6I_GBL_CTL_REG0x04
> +#define SUN6I_TFR_CTL_REG0x08
> +#define SUN6I_FIFO_CTL_REG 0x18
> +#define SUN6I_FIFO_STA_REG 0x1c
> +#define SUN6I_CLK_CTL_REG0x24
> +#define SUN6I_BURST_CNT_REG 0x30
> +#define SUN6I_XMIT_CNT_REG 0x34
> +#define SUN6I_BURST_CTL_REG 0x38
> +#define SUN6I_TXDATA_REG 0x200
> +#define SUN6I_RXDATA_REG 0x300
> +
> #define SUN4I_SPI_MAX_RATE 2400
> #define SUN4I_SPI_MIN_RATE 3000
> #define SUN4I_SPI_DEFAULT_RATE 100
> @@ -112,6 +125,7 @@ enum sun4i_spi_regs {
> /* sun spi register bits */
> enum sun4i_spi_bits {
> SPI_GCR_TP,
> + SPI_GCR_SRST,
> SPI_TCR_CPHA,
> SPI_TCR_CPOL,
> SPI_TCR_CS_ACTIVE_LOW,
> @@ -139,6 +153,7 @@ struct sun4i_spi_platdata {
> struct sun4i_spi_priv {
> struct sun4i_spi_variant *variant;
> struct clk clk_ahb, clk_mod;
> + struct reset_ctl reset;
> u32 base_addr;
> u32 freq;
> u32 mode;
> @@ -257,7 +272,10 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
> if (pin < 0)
> break;
>
> - sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SPI0);
> + if (IS_ENABLED(CONFIG_MACH_SUN50I))
> + sunxi_gpio_set_cfgpin(pin, SUN50I_GPC_SPI0);
> + else
> + sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SPI0);
> sunxi_gpio_set_drv(pin, drive);
> sunxi_gpio_set_pull(pin, pull);
> }
> @@ -273,6 +291,8 @@ static inline int sun4i_spi_set_clock(struct udevice
> *dev, bool enable)
> if (!enable) {
> clk_disable(>clk_ahb);
> clk_disable(>clk_mod);
> + if (reset_valid(>reset))
> + reset_assert(>reset);
> return 0;
> }
>
> @@ -288,8 +308,18 @@ static inline int sun4i_spi_set_clock(struct udevice
> *dev, bool enable)
> goto err_ahb;
> }
>
> + if (reset_valid(>reset)) {
> + ret = reset_deassert(>reset);
> + if (ret) {
> + dev_err(dev, "failed to deassert reset\n");
> + goto err_mod;
> + }
> + }
> +
> return 0;
>
> +err_mod:
> + clk_disable(>clk_mod);
> err_ahb:
> clk_disable(>clk_ahb);
> return ret;
> @@ -330,6 +360,12 @@ static int sun4i_spi_probe(struct udevice *bus)
> return ret;
> }
>
> + ret = reset_get_by_index(bus, 0, >reset);
> + if (ret && ret != -ENOENT) {
> + dev_err(dev, "failed to get reset\n");
> + return ret;
> + }
> +
> sun4i_spi_parse_pins(bus);
>
> priv->variant = plat->variant;
> @@ -351,6 +387,10 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
> setbits_le32(SPI_REG(priv, SPI_GCR), SUN4I_CTL_ENABLE |
>SUN4I_CTL_MASTER | SPI_BIT(priv, SPI_GCR_TP));
>
> + if (!device_is_compatible(dev, "allwinner,sun4i-a10-spi"))
> + setbits_le32(SPI_REG(priv, SPI_GCR),
> + SPI_BIT(priv, SPI_GCR_SRST));
> +
> setbits_le32(SPI_REG(priv, SPI_TCR), SPI_BIT(priv, SPI_TCR_CS_MANUAL) |
>
Re: [U-Boot] [PATCH v2 4/8] spi: sun4i: Access registers and bits via enum offsets
On 14/02/2019 08:36, Jagan Teki wrote:
> Allwinner support two different SPI controllers one for A10 and
> another for A31 with minimal changes in register offsets and
> respective register bits, but the logic for accessing the SPI
> master via SPI slave remains nearly similar.
>
> Add enum offsets for register set and register bits, so-that
> it can access both classes of SPI controllers.
>
> Assign same control register for global, transfer and fifo control
> registers to make the same code compatible with A31 SPI controller.
>
> Signed-off-by: Jagan Teki
> ---
> Note: SPI_REG still seems to have checkpatch warning.
It's a CHECK, and it's fine, as long as you pass only "priv" in, at
least. I think we can leave it this way.
>
> drivers/spi/sun4i_spi.c | 153 +---
> 1 file changed, 111 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index 0b1663038c..afc351c292 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -83,7 +83,6 @@
> #define SUN4I_XMIT_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE)
>
> #define SUN4I_FIFO_STA_REG 0x28
> -#define SUN4I_FIFO_STA_RF_CNT_MASK 0x7f
> #define SUN4I_FIFO_STA_RF_CNT_BITS 0
> #define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
> #define SUN4I_FIFO_STA_TF_CNT_BITS 16
> @@ -93,28 +92,55 @@
> #define SUN4I_SPI_DEFAULT_RATE 100
> #define SUN4I_SPI_TIMEOUT_US 100
>
> -/* sun4i spi register set */
> -struct sun4i_spi_regs {
> - u32 rxdata;
> - u32 txdata;
> - u32 ctl;
> - u32 intctl;
> - u32 st;
> - u32 dmactl;
> - u32 wait;
> - u32 cctl;
> - u32 bc;
> - u32 tc;
> - u32 fifo_sta;
> +#define SPI_REG(priv, reg) ((priv)->base_addr + \
> + (priv)->variant->regs[reg])
> +#define SPI_BIT(priv, bit) ((priv)->variant->bits[bit])
> +#define SPI_CS(cs, priv) (((cs) << SPI_BIT(priv,
> SPI_TCR_CS_SEL)) & \
> + SPI_BIT(priv, SPI_TCR_CS_MASK))
Any chance you can swap the order of the parameters for SPI_CS? It's
quite error prone to have it different from the other two macros
> +
> +/* sun spi register set */
> +enum sun4i_spi_regs {
> + SPI_GCR,
> + SPI_TCR,
> + SPI_FCR,
> + SPI_FSR,
> + SPI_CCR,
> + SPI_BC,
> + SPI_TC,
> + SPI_BCTL,
> + SPI_TXD,
> + SPI_RXD,
> +};
> +
> +/* sun spi register bits */
> +enum sun4i_spi_bits {
> + SPI_GCR_TP,
> + SPI_TCR_CPHA,
> + SPI_TCR_CPOL,
> + SPI_TCR_CS_ACTIVE_LOW,
> + SPI_TCR_CS_SEL,
> + SPI_TCR_CS_MASK,
> + SPI_TCR_XCH,
> + SPI_TCR_CS_MANUAL,
> + SPI_TCR_CS_LEVEL,
> + SPI_FCR_TF_RST,
> + SPI_FCR_RF_RST,
> + SPI_FSR_RF_CNT_MASK,
> +};
> +
> +struct sun4i_spi_variant {
> + const unsigned long *regs, *bits;
> };
>
> struct sun4i_spi_platdata {
> + struct sun4i_spi_variant *variant;
> u32 base_addr;
> u32 max_hz;
> };
>
> struct sun4i_spi_priv {
> - struct sun4i_spi_regs *regs;
> + struct sun4i_spi_variant *variant;
> + u32 base_addr;
> u32 freq;
> u32 mode;
>
> @@ -129,7 +155,7 @@ static inline void sun4i_spi_drain_fifo(struct
> sun4i_spi_priv *priv, int len)
> u8 byte;
>
> while (len--) {
> - byte = readb(>regs->rxdata);
> + byte = readb(SPI_REG(priv, SPI_RXD));
> if (priv->rx_buf)
> *priv->rx_buf++ = byte;
> }
> @@ -141,7 +167,7 @@ static inline void sun4i_spi_fill_fifo(struct
> sun4i_spi_priv *priv, int len)
>
> while (len--) {
> byte = priv->tx_buf ? *priv->tx_buf++ : 0;
> - writeb(byte, >regs->txdata);
> + writeb(byte, SPI_REG(priv, SPI_TXD));
> }
> }
>
> @@ -150,17 +176,17 @@ static void sun4i_spi_set_cs(struct udevice *bus, u8
> cs, bool enable)
> struct sun4i_spi_priv *priv = dev_get_priv(bus);
> u32 reg;
>
> - reg = readl(>regs->ctl);
> + reg = readl(SPI_REG(priv, SPI_TCR));
>
> - reg &= ~SUN4I_CTL_CS_MASK;
> - reg |= SUN4I_CTL_CS(cs);
> + reg &= ~SPI_BIT(priv, SPI_TCR_CS_MASK);
> + reg |= SPI_CS(cs, priv);
>
> if (enable)
> - reg &= ~SUN4I_CTL_CS_LEVEL;
> + reg &= ~SPI_BIT(priv, SPI_TCR_CS_LEVEL);
> else
> - reg |= SUN4I_CTL_CS_LEVEL;
> + reg |= SPI_BIT(priv, SPI_TCR_CS_LEVEL);
>
> - writel(reg, >regs->ctl);
> + writel(reg, SPI_REG(priv, SPI_TCR));
> }
>
> static int sun4i_spi_parse_pins(struct udevice *dev)
> @@ -255,6 +281,7 @@ static int sun4i_spi_ofdata_to_platdata(struct udevice
> *bus)
> int node = dev_of_offset(bus);
>
> plat->base_addr = devfdt_get_addr(bus);
> + plat->variant = (struct sun4i_spi_variant *)dev_get_driver_data(bus);
> plat->max_hz = fdtdec_get_int(gd->fdt_blob, node,
>
Re: [U-Boot] [PATCH v2 6/8] spi: sun4i: Add CLK support
On 14/02/2019 08:36, Jagan Teki wrote:
> Add CLK support to enable AHB and MOD SPI clocks on sun4i_spi driver.
>
> Note, that the code will enable and disable clock in claim and release
> calls to make proper clock and reset handling between claiming and
> releasing SPI bus.
That doesn't really explain *why* this change was made.
> Signed-off-by: Jagan Teki
Reviewed-by: Andre Przywara
Cheers,
Andre.
> ---
> drivers/spi/sun4i_spi.c | 56 +++--
> 1 file changed, 48 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index 22edfdcda3..4f43cc39fb 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -19,6 +19,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -29,8 +30,6 @@
> #include
> #include
>
> -#include
> -
> #include
>
> #define SUN4I_RXDATA_REG 0x00
> @@ -139,6 +138,7 @@ struct sun4i_spi_platdata {
>
> struct sun4i_spi_priv {
> struct sun4i_spi_variant *variant;
> + struct clk clk_ahb, clk_mod;
> u32 base_addr;
> u32 freq;
> u32 mode;
> @@ -265,13 +265,34 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
> return 0;
> }
>
> -static inline void sun4i_spi_enable_clock(void)
> +static inline int sun4i_spi_set_clock(struct udevice *dev, bool enable)
> {
> - struct sunxi_ccm_reg *const ccm =
> - (struct sunxi_ccm_reg *const)SUNXI_CCM_BASE;
> + struct sun4i_spi_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + if (!enable) {
> + clk_disable(>clk_ahb);
> + clk_disable(>clk_mod);
> + return 0;
> + }
>
> - setbits_le32(>ahb_gate0, (1 << AHB_GATE_OFFSET_SPI0));
> - writel((1 << 31), >spi0_clk_cfg);
> + ret = clk_enable(>clk_ahb);
> + if (ret) {
> + dev_err(dev, "failed to enable ahb clock (ret=%d)\n", ret);
> + return ret;
> + }
> +
> + ret = clk_enable(>clk_mod);
> + if (ret) {
> + dev_err(dev, "failed to enable mod clock (ret=%d)\n", ret);
> + goto err_ahb;
> + }
> +
> + return 0;
> +
> +err_ahb:
> + clk_disable(>clk_ahb);
> + return ret;
> }
>
> static int sun4i_spi_ofdata_to_platdata(struct udevice *bus)
> @@ -295,8 +316,20 @@ static int sun4i_spi_probe(struct udevice *bus)
> {
> struct sun4i_spi_platdata *plat = dev_get_platdata(bus);
> struct sun4i_spi_priv *priv = dev_get_priv(bus);
> + int ret;
> +
> + ret = clk_get_by_name(bus, "ahb", >clk_ahb);
> + if (ret) {
> + dev_err(dev, "failed to get ahb clock\n");
> + return ret;
> + }
> +
> + ret = clk_get_by_name(bus, "mod", >clk_mod);
> + if (ret) {
> + dev_err(dev, "failed to get mod clock\n");
> + return ret;
> + }
>
> - sun4i_spi_enable_clock();
> sun4i_spi_parse_pins(bus);
>
> priv->variant = plat->variant;
> @@ -309,6 +342,11 @@ static int sun4i_spi_probe(struct udevice *bus)
> static int sun4i_spi_claim_bus(struct udevice *dev)
> {
> struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
> + int ret;
> +
> + ret = sun4i_spi_set_clock(dev->parent, true);
> + if (ret)
> + return ret;
>
> setbits_le32(SPI_REG(priv, SPI_GCR), SUN4I_CTL_ENABLE |
>SUN4I_CTL_MASTER | SPI_BIT(priv, SPI_GCR_TP));
> @@ -325,6 +363,8 @@ static int sun4i_spi_release_bus(struct udevice *dev)
>
> clrbits_le32(SPI_REG(priv, SPI_GCR), SUN4I_CTL_ENABLE);
>
> + sun4i_spi_set_clock(dev->parent, false);
> +
> return 0;
> }
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/8] spi: sun4i: Poll for rxfifo empty
On 14/02/2019 08:36, Jagan Teki wrote:
> To drain rx fifo the fifo need to poll till the fifo
> count become empty.
Thanks for the changes!
Just realised, the description is somewhat misleading: We are not
waiting for the FIFO count to become empty, but actually for the RX FIFO
to fill up. Can you still change this, especially in the code comment below?
With that:
>
> The current code is using wait_for_bit logic on control
> register with exchange burst mode mask, which is not a
> proper way of waiting for draining fifo.
>
> So, add code for polling fifo status register till rxfifo
> count become empty.
>
> Signed-off-by: Jagan Teki
Reviewed-by: Andre Przywara
Cheers,
Andre.
> ---
> drivers/spi/sun4i_spi.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index 38cc743c61..f5f2d5635a 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -31,6 +31,8 @@
>
> #include
>
> +#include
> +
> #define SUN4I_FIFO_DEPTH 64
>
> #define SUN4I_RXDATA_REG 0x00
> @@ -46,7 +48,6 @@
> #define SUN4I_CTL_LMTF BIT(6)
> #define SUN4I_CTL_TF_RST BIT(8)
> #define SUN4I_CTL_RF_RST BIT(9)
> -#define SUN4I_CTL_XCH_MASK 0x0400
> #define SUN4I_CTL_XCHBIT(10)
> #define SUN4I_CTL_CS_MASK0x3000
> #define SUN4I_CTL_CS(cs) (((cs) << 12) & SUN4I_CTL_CS_MASK)
> @@ -308,7 +309,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned
> int bitlen,
> struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
>
> u32 len = bitlen / 8;
> - u32 reg;
> + u32 reg, rx_fifocnt;
> u8 nbytes;
> int ret;
>
> @@ -343,10 +344,12 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned
> int bitlen,
> reg = readl(>regs->ctl);
> writel(reg | SUN4I_CTL_XCH, >regs->ctl);
>
> - /* Wait transfer to complete */
> - ret = wait_for_bit_le32(>regs->ctl, SUN4I_CTL_XCH_MASK,
> - false, SUN4I_SPI_TIMEOUT_US, false);
> - if (ret) {
> + /* Wait till RX FIFO to be empty */
> + ret = readl_poll_timeout(>regs->fifo_sta, rx_fifocnt,
> + (((rx_fifocnt &
> SUN4I_FIFO_STA_RF_CNT_MASK) >>
> + SUN4I_FIFO_STA_RF_CNT_BITS) >= nbytes),
> + SUN4I_SPI_TIMEOUT_US);
> + if (ret < 0) {
> printf("ERROR: sun4i_spi: Timeout transferring data\n");
> sun4i_spi_set_cs(bus, slave_plat->cs, false);
> return ret;
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: tegra: enable ums on nyan boards
On 2/14/19 4:25 PM, Tristan Bastian wrote:
This patch enables UMS on the nyan devices like the nyan-big.
A patch like this has been sent in by Stephen Warren some time ago for other
tegra devices: commit e6607cffef965011ef0ddc0fbe6f4b7c0d53aeec
But the nyan devices never received that functionality.
v2: fixed corrupted patch
That should be below the ---, but I assume Tom can fix that when
applying the patch.
Acked-by: Stephen Warren
but...
diff --git a/arch/arm/dts/tegra124-nyan.dtsi b/arch/arm/dts/tegra124-nyan.dtsi
index 51895e4816..2b28fe1497 100644
--- a/arch/arm/dts/tegra124-nyan.dtsi
+++ b/arch/arm/dts/tegra124-nyan.dtsi
@@ -414,6 +414,7 @@
usb@7d00 { /* Rear external USB port. */
status = "okay";
+ dr_mode = "otg";
nvidia,vbus-gpio = < TEGRA_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
};
Do you also need to add aliases for the USB nodes, like I did in my
similar patch:
diff --git a/arch/arm/dts/tegra124-jetson-tk1.dts
b/arch/arm/dts/tegra124-jetson-tk1.dts
index 52e8c0e59c6b..464287e03ecf 100644
--- a/arch/arm/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/dts/tegra124-jetson-tk1.dts
@@ -17,7 +17,8 @@
sdhci1 = "/sdhci@700b0400";
spi0 = "/spi@7000d400";
spi1 = "/spi@7000da00";
- usb0 = "/usb@7d008000";
+ usb0 = "/usb@7d00";
+ usb1 = "/usb@7d008000";
};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 4/9] arm: imx7d-pico-pi: Convert to DM MMC initialization
Le 15/02/2019 à 00:08, Fabio Estevam a écrit : Hi Joris, On Thu, Feb 14, 2019 at 8:46 PM Joris Offouga wrote: it is not possible to convert that i2c and do not convert the pmic. on Ok, we can skip I2C and PMIC for now. the other hand, even without pmic and usb conversion there is always the dfu error when i try to update u-boot via sudo dfu-util -D u-boot-dtb.img -a u-boot . See this error : Request would exceed designated area! #Deferred dfu_flush() failed!=> Do you only see this error after the DM conversion? Yes it's only after DM conversion I haven't tried dfu yet on your tree. Will try it tomorrow. Ok thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] ARM: tegra: enable ums on nyan boards
This patch enables UMS on the nyan devices like the nyan-big.
A patch like this has been sent in by Stephen Warren some time ago for other
tegra devices: commit e6607cffef965011ef0ddc0fbe6f4b7c0d53aeec
But the nyan devices never received that functionality.
v2: fixed corrupted patch
Signed-off-by: Tristan Bastian
---
arch/arm/dts/tegra124-nyan.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/tegra124-nyan.dtsi b/arch/arm/dts/tegra124-nyan.dtsi
index 51895e4816..2b28fe1497 100644
--- a/arch/arm/dts/tegra124-nyan.dtsi
+++ b/arch/arm/dts/tegra124-nyan.dtsi
@@ -414,6 +414,7 @@
usb@7d00 { /* Rear external USB port. */
status = "okay";
+ dr_mode = "otg";
nvidia,vbus-gpio = < TEGRA_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
};
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 4/9] arm: imx7d-pico-pi: Convert to DM MMC initialization
Hi Joris, On Thu, Feb 14, 2019 at 8:46 PM Joris Offouga wrote: > it is not possible to convert that i2c and do not convert the pmic. on Ok, we can skip I2C and PMIC for now. > the other hand, even without pmic and usb conversion there is always the > dfu error when i try to update u-boot via sudo dfu-util -D > u-boot-dtb.img -a u-boot . > > See this error : > Request would exceed designated area! > #Deferred dfu_flush() failed!=> Do you only see this error after the DM conversion? I haven't tried dfu yet on your tree. Will try it tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] arm: mach-k3: Add secure device build support
On 2/13/19 9:46 PM, Lokesh Vutla wrote: > > > On 14/02/19 12:07 AM, Andrew F. Davis wrote: >> K3 HS devices require signed binaries for boot, use the SECDEV tools >> to sign the boot artifacts during build. >> >> Signed-off-by: Andrew F. Davis >> --- >> MAINTAINERS | 1 + >> arch/arm/mach-k3/config.mk| 25 ++ >> arch/arm/mach-k3/config_secure.mk | 44 +++ >> tools/k3_fit_atf.sh | 8 -- >> 4 files changed, 76 insertions(+), 2 deletions(-) >> create mode 100644 arch/arm/mach-k3/config_secure.mk >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 18cdca9447..ac6bd8cfca 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -717,6 +717,7 @@ F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S >> F: arch/arm/mach-omap2/sec-common.c >> F: arch/arm/mach-omap2/config_secure.mk >> F: arch/arm/mach-k3/security.c >> +F: arch/arm/mach-k3/config_secure.mk >> F: configs/am335x_hs_evm_defconfig >> F: configs/am335x_hs_evm_uart_defconfig >> F: configs/am43xx_hs_evm_defconfig >> diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk >> index be00d79fb0..2d8f61f9db 100644 >> --- a/arch/arm/mach-k3/config.mk >> +++ b/arch/arm/mach-k3/config.mk >> @@ -36,6 +36,14 @@ cmd_gencert = cat $(srctree)/tools/k3_x509template.txt | >> sed $(SED_OPTS) > u-boo >> # If external key is not provided, generate key using openssl. >> ifeq ($(CONFIG_SYS_K3_KEY), "") >> KEY=u-boot-spl-eckey.pem >> +# On HS use real key or warn if not available >> +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) >> +ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/custMpk.pem),) >> +KEY=$(TI_SECURE_DEV_PKG)/keys/custMpk.pem >> +else >> +$(warning "WARNING: signing key not found. Random key will NOT work on HS >> hardware!") >> +endif >> +endif >> else >> KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY)) >> endif >> @@ -65,6 +73,15 @@ ALL-y += tiboot3.bin >> endif >> >> ifdef CONFIG_ARM64 >> +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) >> +SPL_ITS := u-boot-spl-k3_HS.its >> +$(SPL_ITS): FORCE >> +IS_HS=1 \ >> +$(srctree)/tools/k3_fit_atf.sh \ >> +$(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) > $@ >> + >> +ALL-y += tispl.bin_HS >> +else >> SPL_ITS := u-boot-spl-k3.its >> $(SPL_ITS): FORCE >> $(srctree)/tools/k3_fit_atf.sh \ >> @@ -72,7 +89,15 @@ $(SPL_ITS): FORCE >> >> ALL-y += tispl.bin >> endif >> +endif >> + >> +else >> >> +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) >> +ALL-y += u-boot.img_HS >> else >> ALL-y += u-boot.img >> endif >> +endif >> + >> +include $(srctree)/arch/arm/mach-k3/config_secure.mk >> diff --git a/arch/arm/mach-k3/config_secure.mk >> b/arch/arm/mach-k3/config_secure.mk >> new file mode 100644 >> index 00..6d63c57665 >> --- /dev/null >> +++ b/arch/arm/mach-k3/config_secure.mk >> @@ -0,0 +1,44 @@ >> +# SPDX-License-Identifier: GPL-2.0 >> +# >> +# Copyright (C) 2018 Texas Instruments, Incorporated - http://www.ti.com/ >> +# Andrew F. Davis >> + >> +quiet_cmd_k3secureimg = SECURE $@ >> +ifneq ($(TI_SECURE_DEV_PKG),) >> +ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh),) >> +cmd_k3secureimg = $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \ >> +$< $@ \ >> +$(if $(KBUILD_VERBOSE:1=), >/dev/null) >> +else >> +cmd_k3secureimg = echo "WARNING:" \ >> +"$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \ >> +"$@ was NOT secured!"; cp $< $@ >> +endif >> +else >> +cmd_k3secureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \ >> +"variable must be defined for TI secure devices." \ >> +"$@ was NOT secured!"; cp $< $@ >> +endif >> + >> +%.dtb_HS: %.dtb FORCE >> +$(call if_changed,k3secureimg) >> + >> +$(obj)/u-boot-spl-nodtb.bin_HS: $(obj)/u-boot-spl-nodtb.bin FORCE >> +$(call if_changed,k3secureimg) >> + >> +tispl.bin_HS: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst >> %,$(obj)/dts/%.dtb_HS,$(subst ",,$(CONFIG_SPL_OF_LIST))) $(SPL_ITS) FORCE >> +$(call if_changed,mkfitimage) >> + >> +MKIMAGEFLAGS_u-boot.img_HS = -f auto -A $(ARCH) -T firmware -C none -O >> u-boot \ >> +-a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ >> +-n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ >> +$(patsubst %,-b arch/$(ARCH)/dts/%.dtb_HS,$(subst ",,$(CONFIG_OF_LIST))) > > I guess these HS postfixed dtbs will never get cleaned. I see the same issue > with other TI secure devices as well. Can you update the clean rules as well? > tiboot3.bin and tispl.bin also don't seem to be getting cleaned. I tried adding them to clean-files and CLEAN_FILES, neither worked. Outside of manually deleting them on an appended clean rule I don't know what the recommended trick is for this. > Thanks and regards, > Lokesh > >> + >> +OF_LIST_TARGETS = $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst >> ",,$(CONFIG_OF_LIST))) >> +$(OF_LIST_TARGETS): dtbs >> + >> +u-boot-nodtb.bin_HS: u-boot-nodtb.bin
Re: [U-Boot] [PATCH] ARM: tegra: enable ums on nyan boards
On 2/14/19 3:49 PM, Tristan Bastian wrote: This patch enables UMS on the nyan devices like the nyan-big. A patch like this has been sent in by Stephen Warren some time ago for other tegra devices: commit e6607cffef965011ef0ddc0fbe6f4b7c0d53aeec But the nyan devices never received that functionality. Sounds reasonable. I never did this for this board since I don't have a system to test with (well, I do, but it runs ChromeOS and that's useful so I'm not about to repurpose it!) This patch is corrupted; the indentation is broken. Please use git send-email to send patches rather than pasting them into an email client. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: tegra: enable ums on nyan boards
This patch enables UMS on the nyan devices like the nyan-big.
A patch like this has been sent in by Stephen Warren some time ago for
other tegra devices: commit e6607cffef965011ef0ddc0fbe6f4b7c0d53aeec
But the nyan devices never received that functionality.
Signed-off-by: Tristan Bastian
---
arch/arm/dts/tegra124-nyan.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/tegra124-nyan.dtsi
b/arch/arm/dts/tegra124-nyan.dtsi
index 51895e4816..2b28fe1497 100644
--- a/arch/arm/dts/tegra124-nyan.dtsi
+++ b/arch/arm/dts/tegra124-nyan.dtsi
@@ -414,6 +414,7 @@
usb@7d00 { /* Rear external USB port. */
status = "okay";
+ dr_mode = "otg";
nvidia,vbus-gpio = < TEGRA_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
};
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 4/9] arm: imx7d-pico-pi: Convert to DM MMC initialization
Hi Fabio On 14 Feb 2019, at 17:48, Fabio Estevam wrote: Hi Joris, On Thu, Feb 14, 2019 at 2:42 PM Joris Offouga wrote: Since I do not convert the pmic, I do not convert the i2c either ? I think it is OK to convert I2C now. it is not possible to convert that i2c and do not convert the pmic. on the other hand, even without pmic and usb conversion there is always the dfu error when i try to update u-boot via sudo dfu-util -D u-boot-dtb.img -a u-boot . See this error : Request would exceed designated area! #Deferred dfu_flush() failed!=> Thanks for your help Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [REGRESSION] tegra: efi: EFI boot on nyan-big/tegra124 not possible
Hello, On my nyan-big Chromebook(tegra124) efi booting is broken since stable v2019.01. v2018.11 is working fine.. I'm not sure if other tegra devices are working or not.. I'm getting the following output with u-boot v2019.01 if I try to start grub-efi-arm to boot ubuntu: [...] 67482 bytes read in 17 ms (3.8 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi Error: Cannot set up EFI drivers, r = 14 87040 bytes read in 12 ms (6.9 MiB/s) Error: Cannot set up EFI drivers, r = 14 EFI LOAD FAILED: continuing... [...] The same setup is working if I use the v2018.11 branch. Any ideas? Tristan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] nyan-big: change spi delay
Hi Jon, Hi Stephen, could you take a look at these two patches since I didn't get heard anything from Tom.. Thanks, Tristan Am 21.01.19 um 22:55 schrieb Simon Glass: On Thu, 17 Jan 2019 at 10:33, Simon Glass wrote: On Wed, 16 Jan 2019 at 11:50, Tristan Bastian wrote: Internal keyboard of nyan-big is only working when cold booting by pressing [reload/refresh]+[power] button. With this patch keyboard is working by only pressing [power] button. Signed-off-by: Tristan Bastian --- arch/arm/dts/tegra124-nyan-big-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass Adding Tom to apply this as he was not on the original email. - Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded
On 2/13/19 9:32 PM, Lokesh Vutla wrote:
>
>
> On 14/02/19 12:07 AM, Andrew F. Davis wrote:
>> On HS devices the 512b region of reset isolated memory called
>> MCU_PSRAM0 is firewalled by default. Until SYSFW is loaded we
>> cannot use this memory. It is only used to store a single value
>> left at the end of SRAM by ROM that will be needed later. Save
>> that value to a global variable stored in the .data section.
>> This section is used as .bss will be cleared between saving
>> this value and using it.
>>
>> Signed-off-by: Andrew F. Davis
>> ---
>> arch/arm/mach-k3/am6_init.c | 8 +++-
>> arch/arm/mach-k3/include/mach/am6_hardware.h | 3 ---
>> 2 files changed, 3 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
>> index a5553190b4..462538e45d 100644
>> --- a/arch/arm/mach-k3/am6_init.c
>> +++ b/arch/arm/mach-k3/am6_init.c
>> @@ -49,11 +49,11 @@ static void ctrl_mmr_unlock(void)
>> mmr_unlock(CTRL_MMR0_BASE, 7);
>> }
>>
>> +u32 bootindex __attribute__((section(".data")));
>
> After thinking a bit more I realized that backup bootmode might fail. R5 SPL
> is
> fine but when it jumps to A53 SPL it is trying to read the bootindex again
> from
> K3_BOOT_PARAM_TABLE_INDEX_VAL(this is already the case and is wrong). It is
> not
> guaranteed that R5 SPL did not damage this ROM param table. We should somehow
> pass bootindex to A53 SPL using scratchpad space.
>
I don't know of any super good way to pass data from R5-SPL to A53-SPL,
but I don't think MCU_PSRAM0 will be the way to do it. For all we know
before A53-SPL has started the R5-SPL may have shutdown and something
else has booted, which could have used that MCU local RAM space. I think
we need something that gets passed to A53 anyway, maybe a DT fixup?
>> +
>> static void store_boot_index_from_rom(void)
>> {
>> -u32 *boot_index = (u32 *)K3_BOOT_PARAM_TABLE_INDEX_VAL;
>> -
>> -*boot_index = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
>> +bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
>> }
>>
>> void board_init_f(ulong dummy)
>> @@ -94,7 +94,6 @@ u32 spl_boot_mode(const u32 boot_device)
>> {
>> #if defined(CONFIG_SUPPORT_EMMC_BOOT)
>> u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
>> -u32 bootindex = readl(K3_BOOT_PARAM_TABLE_INDEX_VAL);
>>
>> u32 bootmode = (devstat & CTRLMMR_MAIN_DEVSTAT_BOOTMODE_MASK) >>
>> CTRLMMR_MAIN_DEVSTAT_BOOTMODE_SHIFT;
>> @@ -170,7 +169,6 @@ static u32 __get_primary_bootmedia(u32 devstat)
>> u32 spl_boot_device(void)
>> {
>> u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
>> -u32 bootindex = readl(K3_BOOT_PARAM_TABLE_INDEX_VAL);
>>
>> if (bootindex == K3_PRIMARY_BOOTMODE)
>> return __get_primary_bootmedia(devstat);
>> diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h
>> b/arch/arm/mach-k3/include/mach/am6_hardware.h
>> index b5244609af..3343233aa3 100644
>> --- a/arch/arm/mach-k3/include/mach/am6_hardware.h
>> +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h
>> @@ -44,7 +44,4 @@
>> #define CTRLMMR_LOCK_KICK1 0x0100c
>> #define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a
>>
>> -/* MCU SCRATCHPAD usage */
>> -#define K3_BOOT_PARAM_TABLE_INDEX_VAL
>> CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE
>
> Can we move scratchpad base to a different location ? This will be used for
> eeprom storing also.
>
It's okay to use MCU_PSRAM0 after SYSFW has been loaded, does the EEPROM
data need to be moved between SPLs? Or is it local to each?
Andrew
> Thanks and regards,
> Lokesh
>
>> -
>> #endif /* __ASM_ARCH_AM6_HARDWARE_H */
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] configs: rk3288: Tinker Board SPL file must fit into 32 KiB
> On 13.02.2019, at 22:38, Heinrich Schuchardt wrote: > > The SPL image for the Tinker Board has to fit into 32 KiB. This includes > 4 KiB for the device tree and up to 2 KiB for the file header. > > A new configuration variable CONFIG_SPL_WITH_DTB_SIZE_LIMIT is introduced > to define the board specific limit. > > Signed-off-by: Heinrich Schuchardt Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] videomodes: Allow EDID timings where hsync/vsync pulse is 0
On Thu, Feb 14, 2019 at 10:42:51PM +0530, Jagan Teki wrote: > Hi Anatolij, > > On Wed, Dec 19, 2018 at 6:36 PM Priit Laes wrote: > > > > From: Priit Laes > > > > Current EDID detailed timing parser errors out when either > > horizontal or vertical pulse sync width is 0, thus not > > allowing a display with EDID listed below work properly. > > > > Of-course, this is somewhat quirky HDMI display with following > > anti-features: > > - HPD pin is not usable > > - although resolution is 640x480, only top 240 pixels are visible > > > > $ xxd -p display.edid > > 000005a1e0030100150f0103800f05780a0f6ea05748 > > 9a2610474f20010101010101010101010101010101012a08804520e0 > > 0b10200040009536001800fd0034441a2403000a202020202020 > > 001000310a202020202020202020202000102a4030701300 > > 782d111e006b > > > > $ edid-decode display.edid > > EDID version: 1.3 > > Manufacturer: AMA Model 3e0 Serial Number 1 > > Digital display > > Maximum image size: 15 cm x 5 cm > > Gamma: 2.20 > > RGB color display > > First detailed timing is preferred timing > > Display x,y Chromaticity: > > Red: 0.6250, 0.3398 > > Green: 0.2841, 0.6044 > > Blue: 0.1494, 0.0644 > > White: 0.2802, 0.3105 > > Established timings supported: > > 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz > > Standard timings supported: > > Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm > > 640 672 672 709 hborder 0 > > 480 484 484 491 vborder 0 > >-hsync -vsync > >VertFreq: 60 Hz, HorFreq: 29478 Hz > > Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz > > Dummy block > > Dummy block > > Checksum: 0x6b (valid) > > > > Signed-off-by: Priit Laes > > --- > > drivers/video/videomodes.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/drivers/video/videomodes.c b/drivers/video/videomodes.c > > index 74bafff011..1cfeaa980f 100644 > > --- a/drivers/video/videomodes.c > > +++ b/drivers/video/videomodes.c > > @@ -396,9 +396,7 @@ int video_edid_dtd_to_ctfb_res_modes(struct > > edid_detailed_timing *t, > > EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*t) == 0 || > > EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) == 0 || > > EDID_DETAILED_TIMING_HSYNC_OFFSET(*t) == 0 || > > - EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*t) == 0 || > > EDID_DETAILED_TIMING_VSYNC_OFFSET(*t) == 0 || > > - EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*t) == 0 || > > /* 3d formats are not supported*/ > > EDID_DETAILED_TIMING_FLAG_STEREO(*t) != 0) > > return -EINVAL; > > Any comments? I will mark these patches to you will that be OK? This has been already applied via u-boot-video tree. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] sunxi: Fix A33 memory initialization
On 14/02/2019 16:36, Philipp Tomsich wrote: > > >> On 14.02.2019, at 16:58, Michael Trimarchi >> wrote: >> >> Set two rank timing and exit self-refresh timing seems not done >> properly. We know use the same write that we are using >> on H5 silicon. Tested was done in A33 allwinner cpu, dual rank >> connection connected with two MT41K512M16HA-125:A memory model. >> Memory is configure as DDR3 1.5V >> >> Signed-off-by: Michael Trimarchi >> --- >> >> V1->V2: adjust commit message >> >> --- >> arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c >> b/arch/arm/mach-sunxi/dram_sun8i_a33.c >> index d73a93a132..355fe30aba 100644 >> --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c >> +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c >> @@ -146,7 +146,7 @@ static void auto_set_timing_para(struct dram_para *para) >> writel(reg_val, _ctl->dramtmg5); >> /* Set two rank timing and exit self-refresh timing */ >> clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0), >> -0x33 << 8 | (0x8 << 0)); >> +0x33 << 8 | (0x10 << 0)); > > How exactly does the change in constants match up with the commit message? > What is the field at “<< 0”? From looking at the ZynqMP register guide, which is reported to be close to the various Allwinner DRAM controllers, bits [6:0] are tXS: Self refresh exit delay. Increasing that should not hurt, and if I understand it correctly it only affects the time after the self-refresh *exit*, which happens only after (re-)initialisation(?). But it should be noted that this unconditionally affects all A33 boards. > Are you configuring the IOs to 1.5V with this write (as the commit message > would suggest)? I think the voltage is totally unrelated here, this is a pure timing register. Cheers, Andre. > >> /* Set phy interface time */ >> reg_val = (0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8) >> | (wr_latency << 0); >> -- >> 2.17.1 >> >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: am3517_evm: Enable Falcon Mode
The other OMAP3 based Logic PD boards have Falcon Mode enabled, so this patch makes it possible on the AM3517-evm as well. Signed-off-by: Adam Ford diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig index 7a74e9e90d..9ba518f3d2 100644 --- a/configs/am3517_evm_defconfig +++ b/configs/am3517_evm_defconfig @@ -15,6 +15,7 @@ CONFIG_VERSION_VARIABLE=y CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_FS_EXT4 is not set CONFIG_SPL_MTD_SUPPORT=y +CONFIG_SPL_OS_BOOT=y CONFIG_SYS_PROMPT="AM3517_EVM # " # CONFIG_CMD_IMI is not set CONFIG_CMD_SPL=y diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index eb50012ff7..300f56541e 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -71,6 +71,7 @@ #define CONFIG_SYS_NAND_MAX_ECCPOS 56 #define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_NAND_U_BOOT_OFFS0x8 +#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS 0x2a /* NAND block size is 128 KiB. Synchronize these values with * corresponding Device Tree entries in Linux: * MLO(SPL) 4 * NAND_BLOCK_SIZE = 512 KiB @ 0x00 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] configs: move CONFIG_SPL_TEXT_BASE to Kconfig
Am 19.01.2019 um 17:57 schrieb Tom Rini:
On Sat, Jan 19, 2019 at 05:52:46PM +0100, Simon Goldschmidt wrote:
Hi Tom,
Am Fr., 18. Jan. 2019, 23:02 hat Tom Rini geschrieben:
On Mon, Jan 07, 2019 at 10:12:42AM +0100, Simon Goldschmidt wrote:
On Wed, Jan 2, 2019 at 9:13 PM Simon Goldschmidt
wrote:
Hi Marek,
Am 14.11.2018 um 19:51 schrieb Simon Goldschmidt:
On 07.10.2018 02:49, Tom Rini wrote:
On Sun, Sep 30, 2018 at 02:31:53PM +0200, Simon Goldschmidt wrote:
Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig with
help from moveconfig.py (only had to prepare socfpga,
stm32f746 and am33x/43x manually)
Signed-off-by: Simon Goldschmidt
---
This patch is in preparation for boot-from-FPGA for
socfpga cyclone5, where we need a different SPL_TEXT_BASE.
By moving this to Kconfig, this can then be done via
defconfig.
I did notice that some defconfig files change more than
necessary, it seems like they are out of sync?
So, I see at least one set of problems with the conversion, the
am33*
family gets put to 0x0 which isn't right. I'm going to pull out the
print tool I made and posted a while back and use that for
conversion.
Thanks for the starting point!
Tom, what's the status on this? I still can't build an SPL for
socfpga
gen5 boot from FPGA because I can't change SPL_TEXT_BASE.
Marek, if getting CONFIG_SPL_TEXT_BASE into 2019.01 won't work, can
we
have a separate (k)config option for socfpga only? That might be
useful
anyway as when booting from fpga, there is no 64 KByte size limit and
the "magic value into magic register to unlock support for issuing
warm
reset" must not be written as the SPL is not in SRAM. But that might
have its separate config option, too...
Anyway, I just need input to know in which direction I should
continue.
I'm waiting to get all our versions of SPL and U-Boot running from
mainline (with only board configs added for our private boards).
I still cannot build an SPL to boot from FPGA since
CONFIG_SPL_TEXT_BASE
is hard-coded to OnChip RAM (while when booting from FPGA, it has to be
placed into the FPGA bridge).
Since both Tom and myself did not seem to have immediate luck with
bringing CONFIG_SPL_TEXT_BASE to Kconfig, may I suggest to add a
Kconfig
option 'Boot from FPGA' for socfpga_gen5?
Or do you have another idea at hand of how to proceed here?
Please note that there might be other settings that may change when
booting from FPGA, e.g. the maximum code size for SPL is not limited
any
more.
Gentle ping?
I'd really like to get boot-from-FPGA finally working in the next
release!
So, migrating CONFIG_SPL_TEXT_BASE. A problem is that we don't get the
value for CONFIG_SPL_TEXT_BASE, only CONFIG_TEXT_BASE, once we move it
to Kconfig and are building non-SPL. This is a problem for the TI K2
boards. This however can be fixed by leveraging Andrew's patch[1] as
"ISW" is just a generic term and we can set that on the K2 platforms and
adjust CONFIG_SYS_INIT_SP_ADDR to use that. Next, rockchip rk3368 needs
to be updated to make use of CONFIG_TPL_TEXT_BASE via Kconfig, which
exists already, rather than the workaround it's doing. Finally, some
PowerPC boards that are using TPL are in a similar spot where they also
need to use CONFIG_TPL_TEXT_BASE and are using the mechanic where we'll
pass SPL_TEXT_BASE in TPL, if TPL_TEXT_BASE isn't set.
So, what's all this mean? Well, the rockchip issue looks pretty easy to
deal with and verify, so I'll tackle that first and post something
shortly. The PowerPC thing also doesn't look too terrible (it's only a
few headers) so I'll tackle that second. And then the TI one I'll work
on 3rd, after I get Andrew's patch merged in, which should be fairly
soon (v3 fixed a small issue I found when merging v2).
[1]: https://patchwork.ozlabs.org/patch/1026946/
So I'm still kind of waiting for this to get socfpga booting from fpga (at
least gen5 needs a special linker address for spl to boot from fpga).
Do you think this will make it for 2019.04? Because if not, I'll try to
convince Marek to add an socfpga-specific kconfig option "boot from fpga"
to finally get this working...
Good question. I kicked this around, harder, after posting. I have a
re-work of how we generate {spl,tpl}/u-boot-spl.lds which deletes the
Rockchip u-boot-tpl.lds scripts (their functionality goes more broadly
available and is generic) and reworks PowerPC so that we don't need to
abuse CONFIG_SPL_TEXT_BASE for CONFIG_TPL_TEXT_BASE. The only real
"big" thing that got exposed is that for the 32bit Rockchip platform
that uses TPL, it wasn't defining a maximum size. With that
information, I think I could get comfortable doing a before/after test
here since if we save off the u-boot-spl.lds files a quick cmp will show
if any changed.
And another gentle ping on this.
Now that the series you mentioned above [1] has been merged, do you
still plan to get CONFIG_SPL_TEXT_BASE into Kconfig for 2019.04? Or is
it too late for that now, since rc1
Re: [U-Boot] [PATCH] efi_loader: Swap roles with Heinrich
On 2/14/19 2:35 PM, Alexander Graf wrote: > Heinrich is going to take over maintainership of the efi_loader tree > going forward. > > To ensure that I will still receive review mails at least, add me as > reviewer with a stable email address. > > Signed-off-by: Alexander Graf Signed-off-by: Heinrich Schuchardt > --- > MAINTAINERS | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 29449ffed6..d219c06ec9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -453,8 +453,8 @@ F:include/dm/ > F: test/dm/ > > EFI PAYLOAD > -M: Alexander Graf > -R: Heinrich Schuchardt > +M: Heinrich Schuchardt > +R: Alexander Graf > S: Maintained > T: git git://github.com/agraf/u-boot.git > F: doc/README.uefi > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/8] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK
On Thu, 2019-02-14 at 17:26 +0100, Marek Vasut wrote:
> On 2/14/19 4:47 PM, Chee, Tien Fong wrote:
> >
> > On Thu, 2019-02-14 at 16:13 +0100, Marek Vasut wrote:
> > >
> > > On 2/14/19 4:11 PM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Thu, 2019-02-14 at 13:24 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 2/14/19 12:23 PM, Chee, Tien Fong wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, 2019-02-14 at 11:35 +0100, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 2/14/19 7:04 AM, Chee, Tien Fong wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, 2019-02-14 at 00:04 +0100, Marek Vasut wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 2/13/19 11:45 PM, Dalon L Westergreen wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, 2019-02-13 at 17:10 +0100, Marek Vasut
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > From: Tien Fong Chee
> > > > > > > > > > > >
> > > > > > > > > > > > Add default fitImage file bundling FPGA
> > > > > > > > > > > > bitstreams
> > > > > > > > > > > > for
> > > > > > > > > > > > Arria10.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > > > > > ntel
> > > > > > > > > > > > .com
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > ---
> > > > > > > > > > > >
> > > > > > > > > > > > changes for v8
> > > > > > > > > > > > - Changed the FPGA node name to fpga-core and
> > > > > > > > > > > > fpga-
> > > > > > > > > > > > periph
> > > > > > > > > > > > for
> > > > > > > > > > > > both core and
> > > > > > > > > > > > periph bitstreams respectively.
> > > > > > > > > > > > ---
> > > > > > > > > > > > board/altera/arria10-socdk/fit_spl_fpga.its |
> > > > > > > > > > > > 39
> > > > > > > > > > > > +
> > > > > > > > > > > > 1 file changed, 39 insertions(+)
> > > > > > > > > > > > create mode 100644 board/altera/arria10-
> > > > > > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/board/altera/arria10-
> > > > > > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > > > > > > b/board/altera/arria10-socdk/fit_spl_fpga.its
> > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > index 000..8ce175b
> > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > +++ b/board/altera/arria10-
> > > > > > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > > > > > > @@ -0,0 +1,39 @@
> > > > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > > + /*
> > > > > > > > > > > > + * Copyright (C) 2019 Intel Corporation > > > > > > > > > > > ntel
> > > > > > > > > > > > .com
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > + *
> > > > > > > > > > > > + */
> > > > > > > > > > > > +
> > > > > > > > > > > > +/dts-v1/;
> > > > > > > > > > > > +
> > > > > > > > > > > > +/ {
> > > > > > > > > > > > + description = "FIT image with FPGA
> > > > > > > > > > > > bistream";
> > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + images {
> > > > > > > > > > > > + fpga-core@1 {
> > > > > > > > > > > > + description = "FPGA
> > > > > > > > > > > > core
> > > > > > > > > > > > bitstream";
> > > > > > > > > > > > + data =
> > > > > > > > > > > > /incbin/("../../../ghrd_10as066n2.core.rbf");
> > > > > > > > > > > > + type = "fpga";
> > > > > > > > > > > > + arch = "arm";
> > > > > > > > > > > > + compression = "none";
> > > > > > > > > > > > + load = <0x400>;
> > > > > > > > > > > Is the load address required ?
> > > > > > > > It is optional for telling destination address of DDR
> > > > > > > > where
> > > > > > > > this
> > > > > > > > core.rbf going to be loaded. If load property, the
> > > > > > > > default
> > > > > > > > OCRAM
> > > > > > > > buffer
> > > > > > > > would be used, bad for performance when loading chunk
> > > > > > > > by
> > > > > > > > chunk.
> > > > > > > So if I have something at 0x400 in DRAM and use this
> > > > > > > example
> > > > > > > in
> > > > > > > U-
> > > > > > > Boot,
> > > > > > > it will be overwritten ?
> > > > > > This is used for SPL only, at least for now, so that is
> > > > > > before
> > > > > > loading
> > > > > > the
Re: [U-Boot] [PATCH v8 6/8] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On Thu, 2019-02-14 at 17:27 +0100, Marek Vasut wrote:
> On 2/14/19 4:37 PM, Chee, Tien Fong wrote:
> >
> > On Thu, 2019-02-14 at 16:21 +0100, Marek Vasut wrote:
> > >
> > > On 2/14/19 4:15 PM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > From: Tien Fong Chee
> > > > > > > > > >
> > > > > > > > > > Add support for loading FPGA bitstream to get DDR
> > > > > > > > > > up
> > > > > > > > > > running
> > > > > > > > > > before
> > > > > > > > > > U-Boot is loaded into DDR. Boot device
> > > > > > > > > > initialization,
> > > > > > > > > > generic
> > > > > > > > > > firmware
> > > > > > > > > > loader and SPL FAT support are required for this
> > > > > > > > > > whole
> > > > > > > > > > mechanism to
> > > > > > > > > > work.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > > > .com
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > changes for v7
> > > > > > > > > > - Removed casting for get_fpga_filename
> > > > > > > > > > - Removed hard coding DDR address for loading core
> > > > > > > > > > bistream,
> > > > > > > > > > using
> > > > > > > > > > loadable
> > > > > > > > > > property from FIT.
> > > > > > > > > > - Added checking for config_pins, return if error.
> > > > > > > > > > ---
> > > > > > > > > > arch/arm/mach-socfpga/spl_a10.c | 41
> > > > > > > > > > -
> > > > > > > > > > 1 file changed, 40 insertions(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > > > b/arch/arm/mach-
> > > > > > > > > > socfpga/spl_a10.c
> > > > > > > > > > index c97eacb..36003b1 100644
> > > > > > > > > > --- a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > > > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > > > @@ -1,6 +1,6 @@
> > > > > > > > > > // SPDX-License-Identifier: GPL-2.0+
> > > > > > > > > > /*
> > > > > > > > > > - * Copyright (C) 2012 Altera Corporation > > > > > > > > > era.
> > > > > > > > > > com>
> > > > > > > > > > + * Copyright (C) 2012-2019 Altera Corporation > > > > > > > > > w.al
> > > > > > > > > > tera
> > > > > > > > > > .com
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > */
> > > > > > > > > >
> > > > > > > > > > #include
> > > > > > > > > > @@ -23,6 +23,8 @@
> > > > > > > > > > #include
> > > > > > > > > > #include
> > > > > > > > > > #include
> > > > > > > > > > +#include
> > > > > > > > > > +#include
> > > > > > > > > >
> > > > > > > > > > DECLARE_GLOBAL_DATA_PTR;
> > > > > > > > > >
> > > > > > > > > > @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
> > > > > > > > > > boot_device)
> > > > > > > > > >
> > > > > > > > > > void spl_board_init(void)
> > > > > > > > > > {
> > > > > > > > > > + char buf[16 * 1024]
> > > > > > > > > > __aligned(ARCH_DMA_MINALIGN);
> > > > > > > > > ALLOC_CACHE_ALIGN_BUFFER()
> > > > > > > > #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_S
> > > > > > > > IZE
> > > > > > > > They are not same thing?
> > > > > > > See include/memalign.h and other drivers, the macro is
> > > > > > > preferred
> > > > > > > as
> > > > > > > it
> > > > > > > hides the details.
> > > > > > Okay.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > +
> > > > > > > > > > /* enable console uart printing */
> > > > > > > > > > preloader_console_init();
> > > > > > > > > > WATCHDOG_RESET();
> > > > > > > > > >
> > > > > > > > > > arch_early_init_r();
> > > > > > > > > > +
> > > > > > > > > > + /* If the full FPGA is already loaded,
> > > > > > > > > > ie.from
> > > > > > > > > > EPCQ,
> > > > > > > > > > config fpga pins */
> > > > > > > > > > + if (is_fpgamgr_user_mode()) {
> > > > > > > > > > + int ret = config_pins(gd-
> > > > > > > > > > >fdt_blob,
> > > > > > > > > > "shared");
> > > > > > > > > > +
> > > > > > > > > > +
Re: [U-Boot] [PATCH v8 6/8] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On 2/14/19 4:37 PM, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 16:21 +0100, Marek Vasut wrote:
>> On 2/14/19 4:15 PM, Chee, Tien Fong wrote:
>>>
>>> On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
>
>
> On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
>>
>>
>> On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
>>>
>>>
>>>
>>> On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
>
>
>
>
> From: Tien Fong Chee
>
> Add support for loading FPGA bitstream to get DDR up
> running
> before
> U-Boot is loaded into DDR. Boot device initialization,
> generic
> firmware
> loader and SPL FAT support are required for this whole
> mechanism to
> work.
>
> Signed-off-by: Tien Fong Chee >
>
> ---
>
> changes for v7
> - Removed casting for get_fpga_filename
> - Removed hard coding DDR address for loading core
> bistream,
> using
> loadable
> property from FIT.
> - Added checking for config_pins, return if error.
> ---
> arch/arm/mach-socfpga/spl_a10.c | 41
> -
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-socfpga/spl_a10.c
> b/arch/arm/mach-
> socfpga/spl_a10.c
> index c97eacb..36003b1 100644
> --- a/arch/arm/mach-socfpga/spl_a10.c
> +++ b/arch/arm/mach-socfpga/spl_a10.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright (C) 2012 Altera Corporation com>
> + * Copyright (C) 2012-2019 Altera Corporation tera
> .com
>>
>>
>>
> */
>
> #include
> @@ -23,6 +23,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
> boot_device)
>
> void spl_board_init(void)
> {
> + char buf[16 * 1024]
> __aligned(ARCH_DMA_MINALIGN);
ALLOC_CACHE_ALIGN_BUFFER()
>>> #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE
>>> They are not same thing?
>> See include/memalign.h and other drivers, the macro is
>> preferred
>> as
>> it
>> hides the details.
> Okay.
>>
>>
>>
>>>
>>>
>>>
>
>
>
>
> +
> /* enable console uart printing */
> preloader_console_init();
> WATCHDOG_RESET();
>
> arch_early_init_r();
> +
> + /* If the full FPGA is already loaded, ie.from
> EPCQ,
> config fpga pins */
> + if (is_fpgamgr_user_mode()) {
> + int ret = config_pins(gd->fdt_blob,
> "shared");
> +
> + if (ret)
> + return;
> +
> + ret = config_pins(gd->fdt_blob,
> "fpga");
> + if (ret)
> + return;
> + } else if (!is_fpgamgr_early_user_mode()) {
> + /* Program IOSSM(early IO release) or
> full
> FPGA */
> + fpga_fs_info fpga_fsinfo;
> + int len;
> +
> + fpga_fsinfo.filename =
> get_fpga_filename(gd-
>>
>>
>>
>> fdt_blob, );
> +
> + if (fpga_fsinfo.filename)
> + socfpga_loadfs(_fsinfo,
> buf,
> sizeof(buf), 0);
Why is this code here twice ? The same code seems to be
below
...
>>> The 1st calling for periph program, then running ddr
>>> calibration,
>>> then
>>> 2nd calling for core program.
>> Then maybe the code can be deduplicated ?
> Hmm...seems cannot, because
> 1. DDR calibration is not part of fpga code.
> 2. fpga driver can only be used to process one bistream at a
> time,
> because different mode has different handling.
+ } else if (!is_fpgamgr_early_user_mode()) {
+ /* Program IOSSM(early IO release) or full FPGA
*/
+ fpga_fs_info fpga_fsinfo;
+ int len;
+
+ fpga_fsinfo.filename = get_fpga_filename(gd-
>
> fdt_blob, );
+
+ if (fpga_fsinfo.filename)
+ socfpga_loadfs(_fsinfo, buf,
Re: [U-Boot] [PATCH v8 2/8] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK
On 2/14/19 4:47 PM, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 16:13 +0100, Marek Vasut wrote:
>> On 2/14/19 4:11 PM, Chee, Tien Fong wrote:
>>>
>>> On Thu, 2019-02-14 at 13:24 +0100, Marek Vasut wrote:
On 2/14/19 12:23 PM, Chee, Tien Fong wrote:
>
>
> On Thu, 2019-02-14 at 11:35 +0100, Marek Vasut wrote:
>>
>>
>> On 2/14/19 7:04 AM, Chee, Tien Fong wrote:
>>>
>>>
>>>
>>> On Thu, 2019-02-14 at 00:04 +0100, Marek Vasut wrote:
On 2/13/19 11:45 PM, Dalon L Westergreen wrote:
>
>
>
>
> On Wed, 2019-02-13 at 17:10 +0100, Marek Vasut wrote:
>>
>>
>>
>>
>> On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
>>>
>>>
>>>
>>>
>>> From: Tien Fong Chee
>>>
>>> Add default fitImage file bundling FPGA bitstreams
>>> for
>>> Arria10.
>>>
>>> Signed-off-by: Tien Fong Chee >> .com
>>> ---
>>>
>>> changes for v8
>>> - Changed the FPGA node name to fpga-core and fpga-
>>> periph
>>> for
>>> both core and
>>> periph bitstreams respectively.
>>> ---
>>> board/altera/arria10-socdk/fit_spl_fpga.its | 39
>>> +
>>> 1 file changed, 39 insertions(+)
>>> create mode 100644 board/altera/arria10-
>>> socdk/fit_spl_fpga.its
>>>
>>> diff --git a/board/altera/arria10-
>>> socdk/fit_spl_fpga.its
>>> b/board/altera/arria10-socdk/fit_spl_fpga.its
>>> new file mode 100644
>>> index 000..8ce175b
>>> --- /dev/null
>>> +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
>>> @@ -0,0 +1,39 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> + /*
>>> + * Copyright (C) 2019 Intel Corporation >> .com
>>> + *
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +/ {
>>> + description = "FIT image with FPGA
>>> bistream";
>>> + #address-cells = <1>;
>>> +
>>> + images {
>>> + fpga-core@1 {
>>> + description = "FPGA core
>>> bitstream";
>>> + data =
>>> /incbin/("../../../ghrd_10as066n2.core.rbf");
>>> + type = "fpga";
>>> + arch = "arm";
>>> + compression = "none";
>>> + load = <0x400>;
>> Is the load address required ?
>>> It is optional for telling destination address of DDR where
>>> this
>>> core.rbf going to be loaded. If load property, the default
>>> OCRAM
>>> buffer
>>> would be used, bad for performance when loading chunk by
>>> chunk.
>> So if I have something at 0x400 in DRAM and use this example
>> in
>> U-
>> Boot,
>> it will be overwritten ?
> This is used for SPL only, at least for now, so that is before
> loading
> the U-Boot, DDR is blank.
> But, you can define the blank location.
> If load property is not defined, the driver would use small
> buffer
> from
> OCRAM.
>>
>>
>>
>> How is OCRAM bad for performance ?
> With DDR, the performance can up to 85-90%.
> It is because very limited space in OCRAM, so very small buffer
> is
> used
> for loading bitstream, so the bitstream has to be loaded chunk
> by
> chunk.
> For DDR, where whole bitstream can be loaded.
Shouldn't the logic to determine where the buffer is be in the
code ?
I mean, once you have DRAM available, you have all the malloc
space,
so
you can use larger buffer.Why encode that knowledge into the
fitImage
?
>>> In previosly, we hard code the dest location for loading the core
>>> bitstream in SPL, because by that time DDR up running, but malloc
>>> is
>>> still pointed to OCRAM.
>>> Now, we let user to define the dest location through the load
>>> property.
>> But the user shouldn't care where the buffer is, the buffer should be
>> in
>> the best possible location and the SPL can determine that (if DRAM is
>> running, in DRAM, otherwise in OCRAM), no ?
> Yes, most of the time user don't need to change the dest value at load
> property, unless they have very good reason to do so.
> SPL would smart enough to read the load property after the DDR is up
> running, and loading the bitstream to dest location, and programming
> FPGA from there.
Then we don't need the 'load' property by default ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 6/8] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On Thu, 2019-02-14 at 16:33 +, Westergreen, Dalon wrote:
> On Thu, 2019-02-14 at 15:15 +, Chee, Tien Fong wrote:
> >
> > On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
> > >
> > > On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
> > > >
> > > > On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
> > > > >
> > > > > On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
> > > > > >
> > > > > >
> > > > > > On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Tien Fong Chee
> > > > > > > >
> > > > > > > > Add support for loading FPGA bitstream to get DDR up
> > > > > > > > running
> > > > > > > > before
> > > > > > > > U-Boot is loaded into DDR. Boot device initialization,
> > > > > > > > generic
> > > > > > > > firmware
> > > > > > > > loader and SPL FAT support are required for this whole
> > > > > > > > mechanism to
> > > > > > > > work.
> > > > > > > >
> > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > >
> > > > > > > >
> > > > > > > > ---
> > > > > > > >
> > > > > > > > changes for v7
> > > > > > > > - Removed casting for get_fpga_filename
> > > > > > > > - Removed hard coding DDR address for loading core
> > > > > > > > bistream,
> > > > > > > > using
> > > > > > > > loadable
> > > > > > > > property from FIT.
> > > > > > > > - Added checking for config_pins, return if error.
> > > > > > > > ---
> > > > > > > > arch/arm/mach-socfpga/spl_a10.c | 41
> > > > > > > > -
> > > > > > > > 1 file changed, 40 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > b/arch/arm/mach-
> > > > > > > > socfpga/spl_a10.c
> > > > > > > > index c97eacb..36003b1 100644
> > > > > > > > --- a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > @@ -1,6 +1,6 @@
> > > > > > > > // SPDX-License-Identifier: GPL-2.0+
> > > > > > > > /*
> > > > > > > > - * Copyright (C) 2012 Altera Corporation > > > > > > > com>
> > > > > > > > + * Copyright (C) 2012-2019 Altera Corporation > > > > > > > tera
> > > > > > > > .com
> > > > > > > > >
> > > > > > > > >
> > > > > > > > */
> > > > > > > >
> > > > > > > > #include
> > > > > > > > @@ -23,6 +23,8 @@
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > >
> > > > > > > > DECLARE_GLOBAL_DATA_PTR;
> > > > > > > >
> > > > > > > > @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
> > > > > > > > boot_device)
> > > > > > > >
> > > > > > > > void spl_board_init(void)
> > > > > > > > {
> > > > > > > > + char buf[16 * 1024]
> > > > > > > > __aligned(ARCH_DMA_MINALIGN);
> > > > > > > ALLOC_CACHE_ALIGN_BUFFER()
> > > > > > #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE
> > > > > > They are not same thing?
> > > > > See include/memalign.h and other drivers, the macro is
> > > > > preferred
> > > > > as
> > > > > it
> > > > > hides the details.
> > > > Okay.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > +
> > > > > > > > /* enable console uart printing */
> > > > > > > > preloader_console_init();
> > > > > > > > WATCHDOG_RESET();
> > > > > > > >
> > > > > > > > arch_early_init_r();
> > > > > > > > +
> > > > > > > > + /* If the full FPGA is already loaded, ie.from
> > > > > > > > EPCQ,
> > > > > > > > config fpga pins */
> > > > > > > > + if (is_fpgamgr_user_mode()) {
> > > > > > > > + int ret = config_pins(gd->fdt_blob,
> > > > > > > > "shared");
> > > > > > > > +
> > > > > > > > + if (ret)
> > > > > > > > + return;
> > > > > > > > +
> > > > > > > > + ret = config_pins(gd->fdt_blob,
> > > > > > > > "fpga");
> > > > > > > > + if (ret)
> > > > > > > > + return;
> > > > > > > > + } else if (!is_fpgamgr_early_user_mode()) {
> > > > > > > > + /* Program IOSSM(early IO release) or
> > > > > > > > full
> > > > > > > > FPGA */
> > > > > > > > + fpga_fs_info fpga_fsinfo;
> > > > > > > > + int len;
> > > > > > > > +
> > > > > > > > + fpga_fsinfo.filename =
> > > > > > > > get_fpga_filename(gd-
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > fdt_blob, );
> > > > > > > > +
> > > > > > > > + if (fpga_fsinfo.filename)
> > > > > > > > + socfpga_loadfs(_fsinfo,
> > > > > > > > buf,
> > > > > > > > sizeof(buf), 0);
> > > > > > > Why is this code here twice ? The same code seems to be
> > > > > > > below
> > > > > > > ...
> > > > > > The 1st calling for periph program, then running ddr
> > > > > >
Re: [U-Boot] [PATCH v8 6/8] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On Thu, 2019-02-14 at 16:59 +, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 16:33 +, Westergreen, Dalon wrote:
> > On Thu, 2019-02-14 at 15:15 +, Chee, Tien Fong wrote:
> > > On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
> > > > On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
> > > > > On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
> > > > > > On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
> > > > > > >
> > > > > > > On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
> > > > > > > >
> > > > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > From: Tien Fong Chee
> > > > > > > > >
> > > > > > > > > Add support for loading FPGA bitstream to get DDR up
> > > > > > > > > running
> > > > > > > > > before
> > > > > > > > > U-Boot is loaded into DDR. Boot device initialization,
> > > > > > > > > generic
> > > > > > > > > firmware
> > > > > > > > > loader and SPL FAT support are required for this whole
> > > > > > > > > mechanism to
> > > > > > > > > work.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > >
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > changes for v7
> > > > > > > > > - Removed casting for get_fpga_filename
> > > > > > > > > - Removed hard coding DDR address for loading core
> > > > > > > > > bistream,
> > > > > > > > > using
> > > > > > > > > loadable
> > > > > > > > > property from FIT.
> > > > > > > > > - Added checking for config_pins, return if error.
> > > > > > > > > ---
> > > > > > > > > arch/arm/mach-socfpga/spl_a10.c | 41
> > > > > > > > > -
> > > > > > > > > 1 file changed, 40 insertions(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > > b/arch/arm/mach-
> > > > > > > > > socfpga/spl_a10.c
> > > > > > > > > index c97eacb..36003b1 100644
> > > > > > > > > --- a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > > @@ -1,6 +1,6 @@
> > > > > > > > > // SPDX-License-Identifier: GPL-2.0+
> > > > > > > > > /*
> > > > > > > > > - * Copyright (C) 2012 Altera Corporation > > > > > > > > com>
> > > > > > > > > + * Copyright (C) 2012-2019 Altera Corporation > > > > > > > > tera
> > > > > > > > > .com
> > > > > > > > > >
> > > > > > > > > */
> > > > > > > > >
> > > > > > > > > #include
> > > > > > > > > @@ -23,6 +23,8 @@
> > > > > > > > > #include
> > > > > > > > > #include
> > > > > > > > > #include
> > > > > > > > > +#include
> > > > > > > > > +#include
> > > > > > > > >
> > > > > > > > > DECLARE_GLOBAL_DATA_PTR;
> > > > > > > > >
> > > > > > > > > @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
> > > > > > > > > boot_device)
> > > > > > > > >
> > > > > > > > > void spl_board_init(void)
> > > > > > > > > {
> > > > > > > > > + char buf[16 * 1024]
> > > > > > > > > __aligned(ARCH_DMA_MINALIGN);
> > > > > > > > ALLOC_CACHE_ALIGN_BUFFER()
> > > > > > > #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE
> > > > > > > They are not same thing?
> > > > > > See include/memalign.h and other drivers, the macro is
> > > > > > preferred
> > > > > > as
> > > > > > it
> > > > > > hides the details.
> > > > > Okay.
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > +
> > > > > > > > > /* enable console uart printing */
> > > > > > > > > preloader_console_init();
> > > > > > > > > WATCHDOG_RESET();
> > > > > > > > >
> > > > > > > > > arch_early_init_r();
> > > > > > > > > +
> > > > > > > > > + /* If the full FPGA is already loaded, ie.from
> > > > > > > > > EPCQ,
> > > > > > > > > config fpga pins */
> > > > > > > > > + if (is_fpgamgr_user_mode()) {
> > > > > > > > > + int ret = config_pins(gd->fdt_blob,
> > > > > > > > > "shared");
> > > > > > > > > +
> > > > > > > > > + if (ret)
> > > > > > > > > + return;
> > > > > > > > > +
> > > > > > > > > + ret = config_pins(gd->fdt_blob,
> > > > > > > > > "fpga");
> > > > > > > > > + if (ret)
> > > > > > > > > + return;
> > > > > > > > > + } else if (!is_fpgamgr_early_user_mode()) {
> > > > > > > > > + /* Program IOSSM(early IO release) or
> > > > > > > > > full
> > > > > > > > > FPGA */
> > > > > > > > > + fpga_fs_info fpga_fsinfo;
> > > > > > > > > + int len;
> > > > > > > > > +
> > > > > > > > > + fpga_fsinfo.filename =
> > > > > > > > > get_fpga_filename(gd-
> > > > > > > > > >
> > > > > > > > > > fdt_blob, );
> > > > > > > > > +
> > > > > > > > > + if (fpga_fsinfo.filename)
> > > > > > > > > + socfpga_loadfs(_fsinfo,
> > > > > > > > > buf,
> > > > > > > > > sizeof(buf), 0);
> > > > > > > > Why is this code here twice ? The same code seems to be
> > > > > > > > below
> > > > > > > >
[U-Boot] Pull request: u-boot-sunxi/master
Hi Tom, PR about some random fixes. Summary: - MMC CD pin fix on Orangepi Zero plus - SPI boot for Olinuxino Lime2-eMMC boards - Change in dram frequnecy for tbs_a711 The following changes since commit dbe70c7d4e3d5c705a98d82952e05a591efd0683: Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-02-10 08:11:53 -0500) are available in the Git repository at: git://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to d065a6c00a63c2f441bb8b5d31407c5e10da9612: configs: tbs_a711: lower dram frequency (2019-02-12 17:25:44 +0530) Hauke Mehrtens (1): sun50i: h5: Orange Pi Zero Plus: Fix SdCard detection Priit Laes (1): arm: sunxi: Enable SPL/SPI boot for Olinuxino Lime2-eMMC boards Tomas Novotny (1): configs: tbs_a711: lower dram frequency configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + configs/orangepi_zero_plus_defconfig | 3 +-- configs/tbs_a711_defconfig | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] videomodes: Allow EDID timings where hsync/vsync pulse is 0
Hi Anatolij, On Wed, Dec 19, 2018 at 6:36 PM Priit Laes wrote: > > From: Priit Laes > > Current EDID detailed timing parser errors out when either > horizontal or vertical pulse sync width is 0, thus not > allowing a display with EDID listed below work properly. > > Of-course, this is somewhat quirky HDMI display with following > anti-features: > - HPD pin is not usable > - although resolution is 640x480, only top 240 pixels are visible > > $ xxd -p display.edid > 000005a1e0030100150f0103800f05780a0f6ea05748 > 9a2610474f20010101010101010101010101010101012a08804520e0 > 0b10200040009536001800fd0034441a2403000a202020202020 > 001000310a202020202020202020202000102a4030701300 > 782d111e006b > > $ edid-decode display.edid > EDID version: 1.3 > Manufacturer: AMA Model 3e0 Serial Number 1 > Digital display > Maximum image size: 15 cm x 5 cm > Gamma: 2.20 > RGB color display > First detailed timing is preferred timing > Display x,y Chromaticity: > Red: 0.6250, 0.3398 > Green: 0.2841, 0.6044 > Blue: 0.1494, 0.0644 > White: 0.2802, 0.3105 > Established timings supported: > 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz > Standard timings supported: > Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm > 640 672 672 709 hborder 0 > 480 484 484 491 vborder 0 >-hsync -vsync >VertFreq: 60 Hz, HorFreq: 29478 Hz > Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz > Dummy block > Dummy block > Checksum: 0x6b (valid) > > Signed-off-by: Priit Laes > --- > drivers/video/videomodes.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/video/videomodes.c b/drivers/video/videomodes.c > index 74bafff011..1cfeaa980f 100644 > --- a/drivers/video/videomodes.c > +++ b/drivers/video/videomodes.c > @@ -396,9 +396,7 @@ int video_edid_dtd_to_ctfb_res_modes(struct > edid_detailed_timing *t, > EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*t) == 0 || > EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) == 0 || > EDID_DETAILED_TIMING_HSYNC_OFFSET(*t) == 0 || > - EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*t) == 0 || > EDID_DETAILED_TIMING_VSYNC_OFFSET(*t) == 0 || > - EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*t) == 0 || > /* 3d formats are not supported*/ > EDID_DETAILED_TIMING_FLAG_STEREO(*t) != 0) > return -EINVAL; Any comments? I will mark these patches to you will that be OK? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: Add Macronix MX25R6435F SPI NOR flash to flash parameters array
+ Vignesh
On Mon, Jan 7, 2019 at 11:05 AM Ye Li wrote:
>
> On i.MX7ULP EVK board, we use MX25R6435F NOR flash, add its parameters
> and IDs to flash parameter array. Otherwise, the flash probe will fails.
>
> Signed-off-by: Ye Li
> ---
> drivers/mtd/spi/spi_flash_ids.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
> index ad0a0c8..17f9893 100644
> --- a/drivers/mtd/spi/spi_flash_ids.c
> +++ b/drivers/mtd/spi/spi_flash_ids.c
> @@ -94,6 +94,7 @@ const struct spi_flash_info spi_flash_ids[] = {
> {"mx25u25635f",INFO(0xc22539, 0x0, 64 * 1024, 512, RD_FULL |
> WR_QPP) },
> {"mx66u51235f",INFO(0xc2253a, 0x0, 64 * 1024, 1024, RD_FULL |
> WR_QPP) },
> {"mx66l1g45g", INFO(0xc2201b, 0x0, 64 * 1024, 2048, RD_FULL |
> WR_QPP) },
> + {"mx25r6435f", INFO(0xc22817, 0x0, 64 * 1024, 128, RD_FULL |
> SECT_4K) },
Look like this would also support WR_QPP, how about updating the same?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode values from DT
On Tue, Feb 12, 2019 at 7:14 PM Patrick DELAUNAY
wrote:
>
> Hi Jagan
>
> > From: Jagan Teki
> > Sent: samedi 9 février 2019 17:22
> > Subject: Re: [PATCH v3] dm: spi: Read default speed and mode values from DT
> >
> > On Mon, Jan 28, 2019 at 2:37 PM Patrick Delaunay
> > wrote:
> > >
> > > This patch update the behavior introduced by commit 96907c0fe50a ("dm:
> > > spi: Read default speed and mode values from DT")
> > >
> > > In case of DT boot, don't read default speed and mode for SPI from
> > > CONFIG_* but instead read from DT node. This will make sure that
> > > boards with multiple SPI/QSPI controllers can be probed at different
> > > bus frequencies and SPI modes.
> > >
> > > DT values will be always used when available (full DM support of SPI
> > > slave with available DT node) even if speed and mode are requested;
> > > for example in splash screen support (in splash_sf_read_raw) or in SPL
> > > boot (in spl_spi_load_image).
> > > The caller of spi_get_bus_and_cs() no more need to force speed=0.
> > >
> > > But the current behavior don't change if the SPI slave is not present
> > > (device with generic driver is created automatically) or if platdata
> > > is used (CONFIG_OF_PLATDATA).
> > >
> > >
> > > Signed-off-by: Patrick Delaunay
> > > ---
> > >
> > > Changes in v3:
> > > - complete rework of the patch-set to avoid regression
> > >
> > > Changes in v2:
> > > - use variables to avoid duplicated code
> > >
> > > README | 3 +++
> > > cmd/sf.c | 3 +--
> > > common/spl/spl_spi.c | 2 ++
> > > drivers/spi/spi-uclass.c | 4 +++-
> > > include/spi.h| 9 +
> > > 5 files changed, 14 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/README b/README
> > > index 17d56b8..f7fe74f 100644
> > > --- a/README
> > > +++ b/README
> > > @@ -2184,6 +2184,9 @@ The following options need to be configured:
> > > CONFIG_SF_DEFAULT_MODE (see include/spi.h)
> > > CONFIG_SF_DEFAULT_SPEED in Hz
> > >
> > > + In case of DT boot, SPI don't read default speed and mode
> > > + from CONFIG_*, but from platdata values computed from
> > > available
> > > + DT node
> >
> > This has to update in Kconfig help info.
>
> Ok but witch Kconfig ? whitch config ?
>
> drivers/mtd/spi/Kconfig
> config DM_SPI_FLASH
>
> PS: In master branch, these define are not in yet managed in Kconfig, but
> they are still managed by defines:
>scripts/config_whitelist.txt:1713:CONFIG_SF_DEFAULT_MODE
> And so documentation is done in README not in Kconfig
>
> some migration in Kconfig is pending (moveconfig) ?
Yes, moving them and make changes on top would really nice to go. thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 6/8] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On Thu, 2019-02-14 at 16:33 +, Westergreen, Dalon wrote:
> On Thu, 2019-02-14 at 15:15 +, Chee, Tien Fong wrote:
> >
> > On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
> > >
> > > On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
> > > >
> > > > On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
> > > > >
> > > > > On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
> > > > > >
> > > > > >
> > > > > > On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Tien Fong Chee
> > > > > > > >
> > > > > > > > Add support for loading FPGA bitstream to get DDR up
> > > > > > > > running
> > > > > > > > before
> > > > > > > > U-Boot is loaded into DDR. Boot device initialization,
> > > > > > > > generic
> > > > > > > > firmware
> > > > > > > > loader and SPL FAT support are required for this whole
> > > > > > > > mechanism to
> > > > > > > > work.
> > > > > > > >
> > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > >
> > > > > > > >
> > > > > > > > ---
> > > > > > > >
> > > > > > > > changes for v7
> > > > > > > > - Removed casting for get_fpga_filename
> > > > > > > > - Removed hard coding DDR address for loading core
> > > > > > > > bistream,
> > > > > > > > using
> > > > > > > > loadable
> > > > > > > > property from FIT.
> > > > > > > > - Added checking for config_pins, return if error.
> > > > > > > > ---
> > > > > > > > arch/arm/mach-socfpga/spl_a10.c | 41
> > > > > > > > -
> > > > > > > > 1 file changed, 40 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > b/arch/arm/mach-
> > > > > > > > socfpga/spl_a10.c
> > > > > > > > index c97eacb..36003b1 100644
> > > > > > > > --- a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > @@ -1,6 +1,6 @@
> > > > > > > > // SPDX-License-Identifier: GPL-2.0+
> > > > > > > > /*
> > > > > > > > - * Copyright (C) 2012 Altera Corporation > > > > > > > com>
> > > > > > > > + * Copyright (C) 2012-2019 Altera Corporation > > > > > > > tera
> > > > > > > > .com
> > > > > > > > >
> > > > > > > > >
> > > > > > > > */
> > > > > > > >
> > > > > > > > #include
> > > > > > > > @@ -23,6 +23,8 @@
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > >
> > > > > > > > DECLARE_GLOBAL_DATA_PTR;
> > > > > > > >
> > > > > > > > @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
> > > > > > > > boot_device)
> > > > > > > >
> > > > > > > > void spl_board_init(void)
> > > > > > > > {
> > > > > > > > + char buf[16 * 1024]
> > > > > > > > __aligned(ARCH_DMA_MINALIGN);
> > > > > > > ALLOC_CACHE_ALIGN_BUFFER()
> > > > > > #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE
> > > > > > They are not same thing?
> > > > > See include/memalign.h and other drivers, the macro is
> > > > > preferred
> > > > > as
> > > > > it
> > > > > hides the details.
> > > > Okay.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > +
> > > > > > > > /* enable console uart printing */
> > > > > > > > preloader_console_init();
> > > > > > > > WATCHDOG_RESET();
> > > > > > > >
> > > > > > > > arch_early_init_r();
> > > > > > > > +
> > > > > > > > + /* If the full FPGA is already loaded, ie.from
> > > > > > > > EPCQ,
> > > > > > > > config fpga pins */
> > > > > > > > + if (is_fpgamgr_user_mode()) {
> > > > > > > > + int ret = config_pins(gd->fdt_blob,
> > > > > > > > "shared");
> > > > > > > > +
> > > > > > > > + if (ret)
> > > > > > > > + return;
> > > > > > > > +
> > > > > > > > + ret = config_pins(gd->fdt_blob,
> > > > > > > > "fpga");
> > > > > > > > + if (ret)
> > > > > > > > + return;
> > > > > > > > + } else if (!is_fpgamgr_early_user_mode()) {
> > > > > > > > + /* Program IOSSM(early IO release) or
> > > > > > > > full
> > > > > > > > FPGA */
> > > > > > > > + fpga_fs_info fpga_fsinfo;
> > > > > > > > + int len;
> > > > > > > > +
> > > > > > > > + fpga_fsinfo.filename =
> > > > > > > > get_fpga_filename(gd-
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > fdt_blob, );
> > > > > > > > +
> > > > > > > > + if (fpga_fsinfo.filename)
> > > > > > > > + socfpga_loadfs(_fsinfo,
> > > > > > > > buf,
> > > > > > > > sizeof(buf), 0);
> > > > > > > Why is this code here twice ? The same code seems to be
> > > > > > > below
> > > > > > > ...
> > > > > > The 1st calling for periph program, then running ddr
> > > > > >
Re: [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01)
On 2019-02-14, Baruch Siach wrote: > On Thu, Feb 14 2019, Vagrant Cascadian wrote: >> On 2019-02-14, Baruch Siach wrote: >>> On Wed, Feb 13 2019, Fabio Estevam wrote: On Wed, Feb 13, 2019 at 2:52 PM Vagrant Cascadian wrote: > > I *think* this board is getting the wrong fdtfile set: >>> >>> What hardware are you running? Is it a Cubox-i? >> >> Cubox-i4x4. >> >>> What is your actual problem? >> >> Before v2018.07: fdtfile=imx6q-cubox-i.dtb >> >> in v2018.07: fdtfile=imx6q-cubox-i-som-v15.dtb >> >> as of v2019.01: fdtfile=imx6q-cubox-i.dtb >> >> I am not sure which is actually correct, but since it switched once, and >> then switched back, I figured it was a regression. It appears to run ok >> with either .dtb file, though maybe some features I don't use might not >> work correctly. > > Only fdtfile=imx6q-cubox-i.dtb is correct. Cubox-i never shipped with > SOM rev 1.5. So it looks like a bug in v2018.07. > > The kernel has -v15.dts files for Cubox-i only because Russell King has > a few experimental samples for that combination. Ok, thanks for confirming and setting my confusion to rest. live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 4/9] arm: imx7d-pico-pi: Convert to DM MMC initialization
Hi Joris, On Thu, Feb 14, 2019 at 2:42 PM Joris Offouga wrote: > Since I do not convert the pmic, I do not convert the i2c either ? I think it is OK to convert I2C now. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 4/9] arm: imx7d-pico-pi: Convert to DM MMC initialization
Le 14/02/2019 à 13:58, Fabio Estevam a écrit : Hi Joris, On Thu, Feb 14, 2019 at 10:15 AM Offouga Joris wrote: Hi Fabio I am preparing the next and I hope to be able to send it soon. give me the instructions to follow and I will add them Please check the series I have just sent converting pico-mx6ul boards. If you have any questions, just let me know. Since I do not convert the pmic, I do not convert the i2c either ? Regards, Joris Offouga Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] sunxi: Fix A33 memory initialization
Hi Philipp On Thu, Feb 14, 2019 at 5:36 PM Philipp Tomsich wrote: > > > > > On 14.02.2019, at 16:58, Michael Trimarchi > > wrote: > > > > Set two rank timing and exit self-refresh timing seems not done > > properly. We know use the same write that we are using > > on H5 silicon. Tested was done in A33 allwinner cpu, dual rank > > connection connected with two MT41K512M16HA-125:A memory model. > > Memory is configure as DDR3 1.5V > > > > Signed-off-by: Michael Trimarchi > > --- > > > > V1->V2: adjust commit message > > > > --- > > arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c > > b/arch/arm/mach-sunxi/dram_sun8i_a33.c > > index d73a93a132..355fe30aba 100644 > > --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c > > +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c > > @@ -146,7 +146,7 @@ static void auto_set_timing_para(struct dram_para *para) > > writel(reg_val, _ctl->dramtmg5); > > /* Set two rank timing and exit self-refresh timing */ > > clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0), > > - 0x33 << 8 | (0x8 << 0)); > > + 0x33 << 8 | (0x10 << 0)); > > How exactly does the change in constants match up with the commit message? > What is the field at “<< 0”? > I just reduce the code change. Ok, forget to mention in the commit message that I don't have documentation of the cpu. So my fix is based on allwinner architecture comparison and the fact that it fix my issue. I was having a failure rate of 7% before. > Are you configuring the IOs to 1.5V with this write (as the commit message > would suggest)? No, the model of the memory is LPDDR3 but they can work as DDR3 compatible mode if they are powered at 1.5V. A33 has not support for LPDDR3 so make no sense to try to let them work as LPDDR3. I will update the commit message Michael > > > /* Set phy interface time */ > > reg_val = (0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8) > > | (wr_latency << 0); > > -- > > 2.17.1 > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] sunxi: Fix A33 memory initialization
> On 14.02.2019, at 16:58, Michael Trimarchi > wrote: > > Set two rank timing and exit self-refresh timing seems not done > properly. We know use the same write that we are using > on H5 silicon. Tested was done in A33 allwinner cpu, dual rank > connection connected with two MT41K512M16HA-125:A memory model. > Memory is configure as DDR3 1.5V > > Signed-off-by: Michael Trimarchi > --- > > V1->V2: adjust commit message > > --- > arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c > b/arch/arm/mach-sunxi/dram_sun8i_a33.c > index d73a93a132..355fe30aba 100644 > --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c > +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c > @@ -146,7 +146,7 @@ static void auto_set_timing_para(struct dram_para *para) > writel(reg_val, _ctl->dramtmg5); > /* Set two rank timing and exit self-refresh timing */ > clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0), > - 0x33 << 8 | (0x8 << 0)); > + 0x33 << 8 | (0x10 << 0)); How exactly does the change in constants match up with the commit message? What is the field at “<< 0”? Are you configuring the IOs to 1.5V with this write (as the commit message would suggest)? > /* Set phy interface time */ > reg_val = (0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8) > | (wr_latency << 0); > -- > 2.17.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 6/8] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On Thu, 2019-02-14 at 15:15 +, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
> > On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
> > > On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
> > > > On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
> > > > >
> > > > > On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
> > > > > >
> > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > > >
> > > > > > >
> > > > > > > From: Tien Fong Chee
> > > > > > >
> > > > > > > Add support for loading FPGA bitstream to get DDR up
> > > > > > > running
> > > > > > > before
> > > > > > > U-Boot is loaded into DDR. Boot device initialization,
> > > > > > > generic
> > > > > > > firmware
> > > > > > > loader and SPL FAT support are required for this whole
> > > > > > > mechanism to
> > > > > > > work.
> > > > > > >
> > > > > > > Signed-off-by: Tien Fong Chee
> > > > > > >
> > > > > > > ---
> > > > > > >
> > > > > > > changes for v7
> > > > > > > - Removed casting for get_fpga_filename
> > > > > > > - Removed hard coding DDR address for loading core
> > > > > > > bistream,
> > > > > > > using
> > > > > > > loadable
> > > > > > > property from FIT.
> > > > > > > - Added checking for config_pins, return if error.
> > > > > > > ---
> > > > > > > arch/arm/mach-socfpga/spl_a10.c | 41
> > > > > > > -
> > > > > > > 1 file changed, 40 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > b/arch/arm/mach-
> > > > > > > socfpga/spl_a10.c
> > > > > > > index c97eacb..36003b1 100644
> > > > > > > --- a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > @@ -1,6 +1,6 @@
> > > > > > > // SPDX-License-Identifier: GPL-2.0+
> > > > > > > /*
> > > > > > > - * Copyright (C) 2012 Altera Corporation
> > > > > > > + * Copyright (C) 2012-2019 Altera Corporation > > > > > > .com
> > > > > > > >
> > > > > > > */
> > > > > > >
> > > > > > > #include
> > > > > > > @@ -23,6 +23,8 @@
> > > > > > > #include
> > > > > > > #include
> > > > > > > #include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > >
> > > > > > > DECLARE_GLOBAL_DATA_PTR;
> > > > > > >
> > > > > > > @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
> > > > > > > boot_device)
> > > > > > >
> > > > > > > void spl_board_init(void)
> > > > > > > {
> > > > > > > + char buf[16 * 1024] __aligned(ARCH_DMA_MINALIGN);
> > > > > > ALLOC_CACHE_ALIGN_BUFFER()
> > > > > #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE
> > > > > They are not same thing?
> > > > See include/memalign.h and other drivers, the macro is preferred
> > > > as
> > > > it
> > > > hides the details.
> > > Okay.
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > +
> > > > > > > /* enable console uart printing */
> > > > > > > preloader_console_init();
> > > > > > > WATCHDOG_RESET();
> > > > > > >
> > > > > > > arch_early_init_r();
> > > > > > > +
> > > > > > > + /* If the full FPGA is already loaded, ie.from
> > > > > > > EPCQ,
> > > > > > > config fpga pins */
> > > > > > > + if (is_fpgamgr_user_mode()) {
> > > > > > > + int ret = config_pins(gd->fdt_blob,
> > > > > > > "shared");
> > > > > > > +
> > > > > > > + if (ret)
> > > > > > > + return;
> > > > > > > +
> > > > > > > + ret = config_pins(gd->fdt_blob, "fpga");
> > > > > > > + if (ret)
> > > > > > > + return;
> > > > > > > + } else if (!is_fpgamgr_early_user_mode()) {
> > > > > > > + /* Program IOSSM(early IO release) or full
> > > > > > > FPGA */
> > > > > > > + fpga_fs_info fpga_fsinfo;
> > > > > > > + int len;
> > > > > > > +
> > > > > > > + fpga_fsinfo.filename =
> > > > > > > get_fpga_filename(gd-
> > > > > > > >
> > > > > > > > fdt_blob, );
> > > > > > > +
> > > > > > > + if (fpga_fsinfo.filename)
> > > > > > > + socfpga_loadfs(_fsinfo, buf,
> > > > > > > sizeof(buf), 0);
> > > > > > Why is this code here twice ? The same code seems to be below
> > > > > > ...
> > > > > The 1st calling for periph program, then running ddr
> > > > > calibration,
> > > > > then
> > > > > 2nd calling for core program.
> > > > Then maybe the code can be deduplicated ?
> > > Hmm...seems cannot, because
> > > 1. DDR calibration is not part of fpga code.
> > > 2. fpga driver can only be used to process one bistream at a time,
> > > because different mode has different handling.
> > + } else if (!is_fpgamgr_early_user_mode()) {
> > + /* Program IOSSM(early IO release) or full FPGA */
> > + fpga_fs_info fpga_fsinfo;
> > + int len;
> > +
> > + fpga_fsinfo.filename = get_fpga_filename(gd-
> > > fdt_blob, );
> > +
> > + if (fpga_fsinfo.filename)
> > + socfpga_loadfs(_fsinfo, buf,
> > sizeof(buf), 0);
> > ...
> > + if
Re: [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
Hi Igor, On Thu, 14 Feb 2019 at 17:19, Igor Opaniuk wrote: > > Hi Simon, > > I've fixed failing test on sandbox_flattree by keeping all defined > global variables in a driver-private data struct(as you suggested), > which > permits to probe multiple tee sandbox devices (sent v5, kept you R-b > tag, please let me know if there are any objections from your side). > > But the way how dm test framework is invoked and why dm_root is simply > re-allocated (and what happens with the previous one) is still an open > question to me. > If you can confirm that this a bug, I'll try to think about how this > can be fixed. I don't think it is a bug, actually. When the dm_root goes away the devices go away too since they are no-longer accessible. Of course someone might still have a pointer to a device that was active before the root went away. But I don't think we should worry about devices that are implemented with static data. That is not how things are supposed to be implemented. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
HI Igor, On Wed, 13 Feb 2019 at 16:39, Igor Opaniuk wrote: > > Hi Simon, > > Seems that there is an issue in dm test framework (if understood > everything correctly), > > I've noticed that dm_root is updated when dm tests are being invoked, > and that's why the new tee udevice is allocated, consequently, the > second invocation of probe in tee driver occurs. > In dm_test_init() dm_root is re-inited with NULL (then it populates > new dm tree for from scratch, probing all devices), and I can't find > where it is done(or if it's done at all) a proper removal/cleanup of > devices from the previous dm tree before this dm_test initialization > is invoked (I've added a conditional breakpoint for removal of > previously allocated tee device, and it's never being called): I don't believe we clean up the devices when running tests. It looks like there are some static variables in the sandbox optee driver. That is not correct - everything should be stored in driver-private or uclass-private data so that it goes away. Maybe that is the problem? [..] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
Hi Simon, I've fixed failing test on sandbox_flattree by keeping all defined global variables in a driver-private data struct(as you suggested), which permits to probe multiple tee sandbox devices (sent v5, kept you R-b tag, please let me know if there are any objections from your side). But the way how dm test framework is invoked and why dm_root is simply re-allocated (and what happens with the previous one) is still an open question to me. If you can confirm that this a bug, I'll try to think about how this can be fixed. Thanks! On Wed, 13 Feb 2019 at 17:38, Igor Opaniuk wrote: > > Hi Simon, > > Seems that there is an issue in dm test framework (if understood > everything correctly), > > I've noticed that dm_root is updated when dm tests are being invoked, > and that's why the new tee udevice is allocated, consequently, the > second invocation of probe in tee driver occurs. > In dm_test_init() dm_root is re-inited with NULL (then it populates > new dm tree for from scratch, probing all devices), and I can't find > where it is done(or if it's done at all) a proper removal/cleanup of > devices from the previous dm tree before this dm_test initialization > is invoked (I've added a conditional breakpoint for removal of > previously allocated tee device, and it's never being called): > > Hardware watchpoint 4: gd->dm_root > > Old value = (struct udevice *) 0x1593c230 > New value = (struct udevice *) 0x0 > dm_test_init (uts=0x7c5080 , of_live=false) at > ../test/dm/test-main.c:30 > 30 memset(dm_testdrv_op_count, '\0', sizeof(dm_testdrv_op_count)); > (gdb) bt > #0 dm_test_init (uts=0x7c5080 , of_live=false) > at ../test/dm/test-main.c:30 > #1 dm_do_test (uts=0x7c5080 , of_live=false, > test=0x77a208 <_u_boot_list_2_dm_test_2_dm_test_adc_bind>) at > ../test/dm/test-main.c:86 > #2 dm_test_main (test_name=0x1594ccf0 "adc_bind") at > ../test/dm/test-main.c:180 > #3 do_ut_dm (cmdtp=, flag=, > argc=, argv=) at > ../test/dm/test-main.c:206 > #4 0x0042cc43 in cmd_call (repeatable=0x7fffd58c, > argv=0x1594cd10, argc=3, flag=, cmdtp=0x779f90 > <_u_boot_list_2_cmd_2_ut>) at ../common/command.c:565 > #5 cmd_process (flag=, argc=3, argv=0x1594cd10, > repeatable=repeatable@entry=0x78f394 , > ticks=ticks@entry=0x0) at ../common/command.c:606 > #6 0x0041bdcb in run_pipe_real (pi=0x1594cef0) at > ../common/cli_hush.c:1677 > #7 run_list_real (pi=) at ../common/cli_hush.c:1875 > #8 0x0041c1dd in run_list (pi=0x1594cef0) at > ../common/cli_hush.c:2024 > #9 parse_stream_outer (inp=inp@entry=0x7fffd700, > flag=flag@entry=2) at ../common/cli_hush.c:3216 > #10 0x0041c54d in parse_file_outer () at ../common/cli_hush.c:3299 > #11 0x0042c2ce in cli_loop () at ../common/cli.c:217 > #12 0x00419f74 in main_loop () at ../common/main.c:63 > #13 0x0041ccec in run_main_loop () at ../common/board_r.c:631 > #14 0x0041cf41 in initcall_run_list (init_sequence=0x787740 > ) at ../include/initcall.h:35 > #15 board_init_r (new_gd=, dest_addr=dest_addr@entry=0) > at ../common/board_r.c:856 > #16 0x004025ee in main (argc=, argv= out>) at ../arch/sandbox/cpu/start.c:356 > > Have I missed something? > > On Tue, 12 Feb 2019 at 17:31, Simon Glass wrote: > > > > Hi Igor, > > > > On Tue, 12 Feb 2019 at 14:54, Igor Opaniuk wrote: > > > > > > Hi Tom, Simon, > > > > > > So I did a little investigation and found out that, the issue in that > > > hcreate_r() invocation in the tee sandbox driver fails because the > > > hashtable was allocated before. > > > Debugging showed that the sandbox tee driver is probed twice every > > > time (although remove() is never called, it's behaves like there are > > > two "tee" nodes in DT), and still haven't found the root cause (I > > > think Simon can help with the hint where to look). > > > I was assuming that those returned udevice pointers are kept in some > > > global state but seem that they are de-allocated at some point. > > > Have you ever faced the same behavior? > > > > Not really. If the driver is probed before relocation then it may be > > probed again after relocation. You should be able to tell that by > > check gd->flags. > > > > Regards, > > Simon > > > > -- > Regards, > Igor Opaniuk -- Regards, Igor Opaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/7] fs: ext4: do not allow writes if metadata checksum is active
On 01/02/2019 16:23, Tom Rini wrote:
On Fri, Feb 01, 2019 at 03:33:34PM +0100, Jean-Jacques Hiblot wrote:
u-boot does not supports updating the metadata chacksums
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v2:
- Prevent write access if metadata checksum is enabled
fs/ext4/ext4_write.c | 12 ++--
include/ext4fs.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ext4_write.c b/fs/ext4/ext4_write.c
index a7f543f7df..1de29236f0 100644
--- a/fs/ext4/ext4_write.c
+++ b/fs/ext4/ext4_write.c
@@ -858,12 +858,19 @@ int ext4fs_write(const char *fname, unsigned char *buffer,
g_parent_inode = zalloc(fs->inodesz);
if (!g_parent_inode)
- goto fail;
+ goto fail_ext4fs_init;
if (ext4fs_init() != 0) {
printf("error in File System init\n");
- return -1;
+ goto fail_ext4fs_init;
+ }
+
+ if (le32_to_cpu(fs->sb->feature_ro_compat) &
+ EXT4_FEATURE_RO_COMPAT_METADATA_CSUM) {
+ printf("u-boot doesn't support updating the metadata checksums
yet\n");
+ goto fail;
}
+
inodes_per_block = fs->blksz / fs->inodesz;
parent_inodeno = ext4fs_get_parent_inode_num(fname, filename, F_FILE);
if (parent_inodeno == -1)
I'm following up to myself on this one as, Ugh. To repeat myself from a
while back:
commit 6f94ab6656ceffb3f2a972c8de4c554502b6f2b7
Author: Tom Rini
Date: Fri Jul 22 17:59:11 2016 -0400
ext4: Refuse to mount filesystems with 64bit feature set
With e2fsprogs after 1.43 the 64bit and metadata_csum features are
enabled by default. The metadata_csum feature changes how
ext4_group_desc->bg_checksum is calculated, which would break write
support. The 64bit feature however introduces changes such that it
cannot be read by implementations that do not support it. Since we do
not support this, we must not mount it.
Cc: Stephen Warren
Cc: Simon Glass
Cc: Lukasz Majewski
Cc: Stefan Roese
Reported-by: Andrew Bradford
Signed-off-by: Tom Rini
Which means that starting way back then I should have also done
something to say we cannot write to these new images either. It's good
and important to finally catch this failure now. I suspect it's however
going to start to be an unexpected problem. Have you any idea how much
work would go in to supporting the metadata_csum feature? Thanks again!
I had a look and this is going to be a non-trivial job. The ext4 code is
showing its age. And then there would be another couple of flags to
handle too like journal checksuming, and then also hashtree dirs.
There are a couple of ext4 libs out there (I'm thinking of lwext4 or
e2fsprogs) that do a much better job at handling the
compatible/incompatible/read-only flags. I wonder if we wouldn't be
better off adapting one of them than fixing the current implementation.
JJ
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 3/3] sunxi: Fix A33 memory initialization
Set two rank timing and exit self-refresh timing seems not done properly. We know use the same write that we are using on H5 silicon. Tested was done in A33 allwinner cpu, dual rank connection connected with two MT41K512M16HA-125:A memory model. Memory is configure as DDR3 1.5V Signed-off-by: Michael Trimarchi --- V1->V2: adjust commit message --- arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c b/arch/arm/mach-sunxi/dram_sun8i_a33.c index d73a93a132..355fe30aba 100644 --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c @@ -146,7 +146,7 @@ static void auto_set_timing_para(struct dram_para *para) writel(reg_val, _ctl->dramtmg5); /* Set two rank timing and exit self-refresh timing */ clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0), - 0x33 << 8 | (0x8 << 0)); + 0x33 << 8 | (0x10 << 0)); /* Set phy interface time */ reg_val = (0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8) | (wr_latency << 0); -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 2/3] sunxi: Don't change the rank in dram size detection in A33
Change the size create a glitch in the clken signal on second
bank. According to the ddr manual the clken need to be sent
accros the reset signal coming the cpu. The rank is calculated
just before this function is called and the mctl_set_cr should
not change this value anymore
Signed-off-by: Michael Trimarchi
---
V1->V2: Adjust commit description
---
arch/arm/mach-sunxi/dram_sun8i_a33.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c
b/arch/arm/mach-sunxi/dram_sun8i_a33.c
index 83212aaddf..d73a93a132 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
@@ -45,14 +45,12 @@ static void mctl_set_cr(struct dram_para *para)
static void auto_detect_dram_size(struct dram_para *para)
{
- u8 orig_rank = para->rank;
int rows, columns;
/* Row detect */
para->page_size = 512;
para->seq = 1;
para->rows = 16;
- para->rank = 1;
mctl_set_cr(para);
for (rows = 11 ; rows < 16 ; rows++) {
if (mctl_mem_matches(1 << (rows + 9))) /* row-column */
@@ -69,7 +67,6 @@ static void auto_detect_dram_size(struct dram_para *para)
}
para->seq = 0;
- para->rank = orig_rank;
para->rows = rows;
para->page_size = 1 << columns;
mctl_set_cr(para);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 1/3] sunxi: Use clrsetbits_le32 instead of multiple instruction
Signed-off-by: Michael Trimarchi --- V1->V2: none --- arch/arm/mach-sunxi/dram_sun8i_a33.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c b/arch/arm/mach-sunxi/dram_sun8i_a33.c index 1da2727f98..83212aaddf 100644 --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c @@ -148,12 +148,8 @@ static void auto_set_timing_para(struct dram_para *para) reg_val = (tcksrx << 24) | (tcksre << 16) | (tckesr << 8) | (tcke << 0); writel(reg_val, _ctl->dramtmg5); /* Set two rank timing and exit self-refresh timing */ - reg_val = readl(_ctl->dramtmg8); - reg_val &= ~(0xff << 8); - reg_val &= ~(0xff << 0); - reg_val |= (0x33 << 8); - reg_val |= (0x8 << 0); - writel(reg_val, _ctl->dramtmg8); + clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0), + 0x33 << 8 | (0x8 << 0)); /* Set phy interface time */ reg_val = (0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8) | (wr_latency << 0); -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/8] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK
On Thu, 2019-02-14 at 16:13 +0100, Marek Vasut wrote:
> On 2/14/19 4:11 PM, Chee, Tien Fong wrote:
> >
> > On Thu, 2019-02-14 at 13:24 +0100, Marek Vasut wrote:
> > >
> > > On 2/14/19 12:23 PM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Thu, 2019-02-14 at 11:35 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 2/14/19 7:04 AM, Chee, Tien Fong wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, 2019-02-14 at 00:04 +0100, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 2/13/19 11:45 PM, Dalon L Westergreen wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, 2019-02-13 at 17:10 +0100, Marek Vasut wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > From: Tien Fong Chee
> > > > > > > > > >
> > > > > > > > > > Add default fitImage file bundling FPGA bitstreams
> > > > > > > > > > for
> > > > > > > > > > Arria10.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > > > .com
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > changes for v8
> > > > > > > > > > - Changed the FPGA node name to fpga-core and fpga-
> > > > > > > > > > periph
> > > > > > > > > > for
> > > > > > > > > > both core and
> > > > > > > > > > periph bitstreams respectively.
> > > > > > > > > > ---
> > > > > > > > > > board/altera/arria10-socdk/fit_spl_fpga.its | 39
> > > > > > > > > > +
> > > > > > > > > > 1 file changed, 39 insertions(+)
> > > > > > > > > > create mode 100644 board/altera/arria10-
> > > > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > > > >
> > > > > > > > > > diff --git a/board/altera/arria10-
> > > > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > > > > b/board/altera/arria10-socdk/fit_spl_fpga.its
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 000..8ce175b
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
> > > > > > > > > > @@ -0,0 +1,39 @@
> > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > + /*
> > > > > > > > > > + * Copyright (C) 2019 Intel Corporation > > > > > > > > > .com
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > + *
> > > > > > > > > > + */
> > > > > > > > > > +
> > > > > > > > > > +/dts-v1/;
> > > > > > > > > > +
> > > > > > > > > > +/ {
> > > > > > > > > > + description = "FIT image with FPGA
> > > > > > > > > > bistream";
> > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > +
> > > > > > > > > > + images {
> > > > > > > > > > + fpga-core@1 {
> > > > > > > > > > + description = "FPGA core
> > > > > > > > > > bitstream";
> > > > > > > > > > + data =
> > > > > > > > > > /incbin/("../../../ghrd_10as066n2.core.rbf");
> > > > > > > > > > + type = "fpga";
> > > > > > > > > > + arch = "arm";
> > > > > > > > > > + compression = "none";
> > > > > > > > > > + load = <0x400>;
> > > > > > > > > Is the load address required ?
> > > > > > It is optional for telling destination address of DDR where
> > > > > > this
> > > > > > core.rbf going to be loaded. If load property, the default
> > > > > > OCRAM
> > > > > > buffer
> > > > > > would be used, bad for performance when loading chunk by
> > > > > > chunk.
> > > > > So if I have something at 0x400 in DRAM and use this example
> > > > > in
> > > > > U-
> > > > > Boot,
> > > > > it will be overwritten ?
> > > > This is used for SPL only, at least for now, so that is before
> > > > loading
> > > > the U-Boot, DDR is blank.
> > > > But, you can define the blank location.
> > > > If load property is not defined, the driver would use small
> > > > buffer
> > > > from
> > > > OCRAM.
> > > > >
> > > > >
> > > > >
> > > > > How is OCRAM bad for performance ?
> > > > With DDR, the performance can up to 85-90%.
> > > > It is because very limited space in OCRAM, so very small buffer
> > > > is
> > > > used
> > > > for loading bitstream, so the bitstream has to be loaded chunk
> > > > by
> > > > chunk.
> > > > For DDR, where whole bitstream can be loaded.
> > > Shouldn't the logic to determine where the buffer is be in the
> > > code ?
> > > I mean, once you have DRAM available, you have all the malloc
> > > space,
> > > so
> > > you can use larger buffer.Why encode that knowledge into the
> > > fitImage
> > > ?
> > In previosly, we hard code the dest location for loading the core
> > bitstream in SPL, because by that time DDR up running, but malloc
> > is
> > still pointed to OCRAM.
> > Now, we let user to define the dest location through the load
> > property.
> But the user
Re: [U-Boot] [PATCH] arm: socfpga: move gen5 SDR driver to DM
On Thu, Feb 14, 2019 at 4:37 PM Dinh Nguyen wrote: > > Hi Marek, > > On 2/9/19 4:01 AM, Marek Vasut wrote: > > On 2/7/19 10:23 PM, Simon Goldschmidt wrote: > >> To clean up reset handling for socfpga gen5, let's move the code snippet > >> taking the DDR controller out of reset from SPL to the DDR driver. > >> > >> While at it, port the ddr driver to UCLASS_RAM and use dts. > >> > >> Signed-off-by: Simon Goldschmidt > >> --- > >> > >> This is an RFC to show what the SDRAM driver moved to DM (UCLASS_RAM) would > >> look like. It's RFC both because Dinh did not seem too fond of changing the > >> register address of the SDR in devicetree to include what the undocumented > >> registers 'sequencer.c' uses as well as because of my observed code growth. > > > > Dinh, if the SDRAM controller spans some addresses, it should be > > described like so in the DT. Whether those registers are documented or > > not does not matter, DT is a hardware description and should describe > > hardware accurately. > > Yes, I agree with above statement. I'll wait for this patch to land here > and will take the DTS patch to sync up Linux and U-Boot DTS. Thanks. I'll first work up the U-Boot patch and once that's in an acceptable state I'll send v2 of the Linux patch (which has compiler errors in the suspend code in v1). Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] warp7: README: Adjust the binary name after DM conversion
Hi Joris, On Thu, Feb 14, 2019 at 11:43 AM Joris Offouga wrote: > Hi Fabio > > Fix typo warp7_config into warp7_defconig make warp7_config make Also works fine. I agree with you that "make warp_defconfig" is preferable and I will make such change after this one gets applied. Thanks for your suggestion! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: move gen5 SDR driver to DM
Hi Marek, On 2/9/19 4:01 AM, Marek Vasut wrote: > On 2/7/19 10:23 PM, Simon Goldschmidt wrote: >> To clean up reset handling for socfpga gen5, let's move the code snippet >> taking the DDR controller out of reset from SPL to the DDR driver. >> >> While at it, port the ddr driver to UCLASS_RAM and use dts. >> >> Signed-off-by: Simon Goldschmidt >> --- >> >> This is an RFC to show what the SDRAM driver moved to DM (UCLASS_RAM) would >> look like. It's RFC both because Dinh did not seem too fond of changing the >> register address of the SDR in devicetree to include what the undocumented >> registers 'sequencer.c' uses as well as because of my observed code growth. > > Dinh, if the SDRAM controller spans some addresses, it should be > described like so in the DT. Whether those registers are documented or > not does not matter, DT is a hardware description and should describe > hardware accurately. Yes, I agree with above statement. I'll wait for this patch to land here and will take the DTS patch to sync up Linux and U-Boot DTS. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 6/8] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On Thu, 2019-02-14 at 16:21 +0100, Marek Vasut wrote:
> On 2/14/19 4:15 PM, Chee, Tien Fong wrote:
> >
> > On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
> > >
> > > On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Tien Fong Chee
> > > > > > > >
> > > > > > > > Add support for loading FPGA bitstream to get DDR up
> > > > > > > > running
> > > > > > > > before
> > > > > > > > U-Boot is loaded into DDR. Boot device initialization,
> > > > > > > > generic
> > > > > > > > firmware
> > > > > > > > loader and SPL FAT support are required for this whole
> > > > > > > > mechanism to
> > > > > > > > work.
> > > > > > > >
> > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > >
> > > > > > > >
> > > > > > > > ---
> > > > > > > >
> > > > > > > > changes for v7
> > > > > > > > - Removed casting for get_fpga_filename
> > > > > > > > - Removed hard coding DDR address for loading core
> > > > > > > > bistream,
> > > > > > > > using
> > > > > > > > loadable
> > > > > > > > property from FIT.
> > > > > > > > - Added checking for config_pins, return if error.
> > > > > > > > ---
> > > > > > > > arch/arm/mach-socfpga/spl_a10.c | 41
> > > > > > > > -
> > > > > > > > 1 file changed, 40 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > b/arch/arm/mach-
> > > > > > > > socfpga/spl_a10.c
> > > > > > > > index c97eacb..36003b1 100644
> > > > > > > > --- a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > @@ -1,6 +1,6 @@
> > > > > > > > // SPDX-License-Identifier: GPL-2.0+
> > > > > > > > /*
> > > > > > > > - * Copyright (C) 2012 Altera Corporation > > > > > > > com>
> > > > > > > > + * Copyright (C) 2012-2019 Altera Corporation > > > > > > > tera
> > > > > > > > .com
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > */
> > > > > > > >
> > > > > > > > #include
> > > > > > > > @@ -23,6 +23,8 @@
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > > #include
> > > > > > > > +#include
> > > > > > > > +#include
> > > > > > > >
> > > > > > > > DECLARE_GLOBAL_DATA_PTR;
> > > > > > > >
> > > > > > > > @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
> > > > > > > > boot_device)
> > > > > > > >
> > > > > > > > void spl_board_init(void)
> > > > > > > > {
> > > > > > > > + char buf[16 * 1024]
> > > > > > > > __aligned(ARCH_DMA_MINALIGN);
> > > > > > > ALLOC_CACHE_ALIGN_BUFFER()
> > > > > > #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE
> > > > > > They are not same thing?
> > > > > See include/memalign.h and other drivers, the macro is
> > > > > preferred
> > > > > as
> > > > > it
> > > > > hides the details.
> > > > Okay.
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > +
> > > > > > > > /* enable console uart printing */
> > > > > > > > preloader_console_init();
> > > > > > > > WATCHDOG_RESET();
> > > > > > > >
> > > > > > > > arch_early_init_r();
> > > > > > > > +
> > > > > > > > + /* If the full FPGA is already loaded, ie.from
> > > > > > > > EPCQ,
> > > > > > > > config fpga pins */
> > > > > > > > + if (is_fpgamgr_user_mode()) {
> > > > > > > > + int ret = config_pins(gd->fdt_blob,
> > > > > > > > "shared");
> > > > > > > > +
> > > > > > > > + if (ret)
> > > > > > > > + return;
> > > > > > > > +
> > > > > > > > + ret = config_pins(gd->fdt_blob,
> > > > > > > > "fpga");
> > > > > > > > + if (ret)
> > > > > > > > + return;
> > > > > > > > + } else if (!is_fpgamgr_early_user_mode()) {
> > > > > > > > + /* Program IOSSM(early IO release) or
> > > > > > > > full
> > > > > > > > FPGA */
> > > > > > > > + fpga_fs_info fpga_fsinfo;
> > > > > > > > + int len;
> > > > > > > > +
> > > > > > > > + fpga_fsinfo.filename =
> > > > > > > > get_fpga_filename(gd-
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > fdt_blob, );
> > > > > > > > +
> > > > > > > > + if (fpga_fsinfo.filename)
> > > > > > > > + socfpga_loadfs(_fsinfo,
> > > > > > > > buf,
> > > > > > > > sizeof(buf), 0);
> > > > > > > Why is this code here twice ? The same
Re: [U-Boot] [PATCH v8 4/8] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
On 2/14/19 4:23 PM, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 16:15 +0100, Marek Vasut wrote:
>> On 2/14/19 4:14 PM, Chee, Tien Fong wrote:
>>>
>>> On Thu, 2019-02-14 at 13:29 +0100, Marek Vasut wrote:
On 2/14/19 1:14 PM, Chee, Tien Fong wrote:
>
>
> On Thu, 2019-02-14 at 11:41 +0100, Marek Vasut wrote:
>>
>>
>> On 2/14/19 7:44 AM, Chee, Tien Fong wrote:
>>>
>>>
>>>
>>> On Wed, 2019-02-13 at 17:20 +0100, Marek Vasut wrote:
On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
>
>
>
>
> From: Tien Fong Chee
>
> Add FPGA driver to support program FPGA with FPGA
> bitstream
> loading
> from
> filesystem. The driver are designed based on generic
> firmware
> loader
> framework. The driver can handle FPGA program operation
> from
> loading FPGA
> bitstream in flash to memory and then to program FPGA.
>
> Signed-off-by: Tien Fong Chee >
>
> ---
>
> changes for v8
> - Added codes to discern bitstream type based on fpga
> node
> name.
>
> changes for v7
> - Restructure the FPGA driver to support both
> peripheral
> bitstream
> and core
> bitstream bundled into FIT image.
> - Support loadable property for core bitstream. User
> can
> set
> loadable
> in DDR for better performance. This loading would be
> done
> in
> one
> large
> chunk instead of chunk by chunk loading with small
> memory
> buffer.
> ---
> arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts |
> 17 +
> .../include/mach/fpga_manager_arria10.h|
> 39
> +-
> drivers/fpga/socfpga_arria10.c |
> 467
> -
> 3 files changed, 500 insertions(+), 23 deletions(-)
>
> diff --git
> a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> index 998d811..14f1967 100644
> --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> [...]
>
>>
>>
>>>
>>>
>
>
> - * FPGA Manager to program the FPGA. This is the
> interface
> used by
> FPGA driver.
> - * Return 0 for sucess, non-zero for error.
> - */
> +char *get_fpga_filename(const void *fdt, int *len)
> +{
> + char *fpga_filename = NULL;
> + int node_offset;
> +
> + fdtdec_find_aliases_for_id(gd->fdt_blob,
> "fpga_mgr",
> + COMPAT_ALTERA_SOCFPGA_
> FPGA
> 0,
> + _offset, 1);
> +
> + ofnode fpgamgr_node =
> offset_to_ofnode(node_offset);
> +
> + if (ofnode_valid(fpgamgr_node))
> + fpga_filename = (char
> *)ofnode_read_string(fpgamgr_node,
> + "altr,
> bits
> trea
> m");
> +
> +
Why is the cast needed ?
>>> The return string would be eventually set to the char
>>> *filename
>>> in
>>> common struct fpga_fsinfo. So, the cast here is to avoid
>>> the
>>> warning
>>> from compiler.
>> I presume if the compiler generates a warning, it's for a
>> reason.
>> What
>> warning is that ?
> drivers/fpga/socfpga_arria10.c: In function
> 'get_fpga_filename':
> drivers/fpga/socfpga_arria10.c:466:17: warning: assignment
> discards
> 'const' qualifier from pointer target type [-Wdiscarded-
> qualifiers]
> fpga_filename = ofnode_read_string(fpgamgr_node,
Add missing const then ?
>>> Then this requires change on common struct fpga_fsinfo, this would
>>> impact to other user using this. Why the cast is not allow as we
>>> only
>>> reading the filename?
>> If the string isn't const, someone can write it. If someone writes
>> this
>> string, won't it corrupt the DT ?
> Yes, but this would not happen in this driver, right?
> I don't know also why this common struct declare without the const, may
> be it supports the write?
I think so, maybe you should check that.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 4/8] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
On Thu, 2019-02-14 at 16:15 +0100, Marek Vasut wrote:
> On 2/14/19 4:14 PM, Chee, Tien Fong wrote:
> >
> > On Thu, 2019-02-14 at 13:29 +0100, Marek Vasut wrote:
> > >
> > > On 2/14/19 1:14 PM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Thu, 2019-02-14 at 11:41 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 2/14/19 7:44 AM, Chee, Tien Fong wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 2019-02-13 at 17:20 +0100, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Tien Fong Chee
> > > > > > > >
> > > > > > > > Add FPGA driver to support program FPGA with FPGA
> > > > > > > > bitstream
> > > > > > > > loading
> > > > > > > > from
> > > > > > > > filesystem. The driver are designed based on generic
> > > > > > > > firmware
> > > > > > > > loader
> > > > > > > > framework. The driver can handle FPGA program operation
> > > > > > > > from
> > > > > > > > loading FPGA
> > > > > > > > bitstream in flash to memory and then to program FPGA.
> > > > > > > >
> > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > >
> > > > > > > >
> > > > > > > > ---
> > > > > > > >
> > > > > > > > changes for v8
> > > > > > > > - Added codes to discern bitstream type based on fpga
> > > > > > > > node
> > > > > > > > name.
> > > > > > > >
> > > > > > > > changes for v7
> > > > > > > > - Restructure the FPGA driver to support both
> > > > > > > > peripheral
> > > > > > > > bitstream
> > > > > > > > and core
> > > > > > > > bitstream bundled into FIT image.
> > > > > > > > - Support loadable property for core bitstream. User
> > > > > > > > can
> > > > > > > > set
> > > > > > > > loadable
> > > > > > > > in DDR for better performance. This loading would be
> > > > > > > > done
> > > > > > > > in
> > > > > > > > one
> > > > > > > > large
> > > > > > > > chunk instead of chunk by chunk loading with small
> > > > > > > > memory
> > > > > > > > buffer.
> > > > > > > > ---
> > > > > > > > arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts |
> > > > > > > > 17 +
> > > > > > > > .../include/mach/fpga_manager_arria10.h|
> > > > > > > > 39
> > > > > > > > +-
> > > > > > > > drivers/fpga/socfpga_arria10.c |
> > > > > > > > 467
> > > > > > > > -
> > > > > > > > 3 files changed, 500 insertions(+), 23 deletions(-)
> > > > > > > >
> > > > > > > > diff --git
> > > > > > > > a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > > > > > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > > > > > index 998d811..14f1967 100644
> > > > > > > > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > > > > > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > [...]
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > - * FPGA Manager to program the FPGA. This is the
> > > > > > > > interface
> > > > > > > > used by
> > > > > > > > FPGA driver.
> > > > > > > > - * Return 0 for sucess, non-zero for error.
> > > > > > > > - */
> > > > > > > > +char *get_fpga_filename(const void *fdt, int *len)
> > > > > > > > +{
> > > > > > > > + char *fpga_filename = NULL;
> > > > > > > > + int node_offset;
> > > > > > > > +
> > > > > > > > + fdtdec_find_aliases_for_id(gd->fdt_blob,
> > > > > > > > "fpga_mgr",
> > > > > > > > + COMPAT_ALTERA_SOCFPGA_
> > > > > > > > FPGA
> > > > > > > > 0,
> > > > > > > > + _offset, 1);
> > > > > > > > +
> > > > > > > > + ofnode fpgamgr_node =
> > > > > > > > offset_to_ofnode(node_offset);
> > > > > > > > +
> > > > > > > > + if (ofnode_valid(fpgamgr_node))
> > > > > > > > + fpga_filename = (char
> > > > > > > > *)ofnode_read_string(fpgamgr_node,
> > > > > > > > + "altr,
> > > > > > > > bits
> > > > > > > > trea
> > > > > > > > m");
> > > > > > > > +
> > > > > > > > +
> > > > > > > Why is the cast needed ?
> > > > > > The return string would be eventually set to the char
> > > > > > *filename
> > > > > > in
> > > > > > common struct fpga_fsinfo. So, the cast here is to avoid
> > > > > > the
> > > > > > warning
> > > > > > from compiler.
> > > > > I presume if the compiler generates a warning, it's for a
> > > > > reason.
> > > > > What
> > > > > warning is that ?
> > > > drivers/fpga/socfpga_arria10.c: In function
> > > > 'get_fpga_filename':
> > > > drivers/fpga/socfpga_arria10.c:466:17: warning: assignment
> > > > discards
> > > > 'const' qualifier from pointer target type [-Wdiscarded-
> > > > qualifiers]
> > > > fpga_filename = ofnode_read_string(fpgamgr_node,
> > > Add missing const then ?
> > Then this requires change on common struct fpga_fsinfo, this would
> > impact to other user using this. Why the
Re: [U-Boot] [PATCH v8 6/8] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On 2/14/19 4:15 PM, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
>> On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
>>>
>>> On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
>
>
> On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
>>
>>
>> On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
>>>
>>>
>>>
>>> From: Tien Fong Chee
>>>
>>> Add support for loading FPGA bitstream to get DDR up
>>> running
>>> before
>>> U-Boot is loaded into DDR. Boot device initialization,
>>> generic
>>> firmware
>>> loader and SPL FAT support are required for this whole
>>> mechanism to
>>> work.
>>>
>>> Signed-off-by: Tien Fong Chee
>>>
>>> ---
>>>
>>> changes for v7
>>> - Removed casting for get_fpga_filename
>>> - Removed hard coding DDR address for loading core
>>> bistream,
>>> using
>>> loadable
>>> property from FIT.
>>> - Added checking for config_pins, return if error.
>>> ---
>>> arch/arm/mach-socfpga/spl_a10.c | 41
>>> -
>>> 1 file changed, 40 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-socfpga/spl_a10.c
>>> b/arch/arm/mach-
>>> socfpga/spl_a10.c
>>> index c97eacb..36003b1 100644
>>> --- a/arch/arm/mach-socfpga/spl_a10.c
>>> +++ b/arch/arm/mach-socfpga/spl_a10.c
>>> @@ -1,6 +1,6 @@
>>> // SPDX-License-Identifier: GPL-2.0+
>>> /*
>>> - * Copyright (C) 2012 Altera Corporation
>>> + * Copyright (C) 2012-2019 Altera Corporation >> .com
>>> */
>>>
>>> #include
>>> @@ -23,6 +23,8 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> +#include
>>>
>>> DECLARE_GLOBAL_DATA_PTR;
>>>
>>> @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
>>> boot_device)
>>>
>>> void spl_board_init(void)
>>> {
>>> + char buf[16 * 1024] __aligned(ARCH_DMA_MINALIGN);
>> ALLOC_CACHE_ALIGN_BUFFER()
> #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE
> They are not same thing?
See include/memalign.h and other drivers, the macro is preferred
as
it
hides the details.
>>> Okay.
>
>
>>
>>
>>>
>>>
>>>
>>> +
>>> /* enable console uart printing */
>>> preloader_console_init();
>>> WATCHDOG_RESET();
>>>
>>> arch_early_init_r();
>>> +
>>> + /* If the full FPGA is already loaded, ie.from
>>> EPCQ,
>>> config fpga pins */
>>> + if (is_fpgamgr_user_mode()) {
>>> + int ret = config_pins(gd->fdt_blob,
>>> "shared");
>>> +
>>> + if (ret)
>>> + return;
>>> +
>>> + ret = config_pins(gd->fdt_blob, "fpga");
>>> + if (ret)
>>> + return;
>>> + } else if (!is_fpgamgr_early_user_mode()) {
>>> + /* Program IOSSM(early IO release) or full
>>> FPGA */
>>> + fpga_fs_info fpga_fsinfo;
>>> + int len;
>>> +
>>> + fpga_fsinfo.filename =
>>> get_fpga_filename(gd-
fdt_blob, );
>>> +
>>> + if (fpga_fsinfo.filename)
>>> + socfpga_loadfs(_fsinfo, buf,
>>> sizeof(buf), 0);
>> Why is this code here twice ? The same code seems to be below
>> ...
> The 1st calling for periph program, then running ddr
> calibration,
> then
> 2nd calling for core program.
Then maybe the code can be deduplicated ?
>>> Hmm...seems cannot, because
>>> 1. DDR calibration is not part of fpga code.
>>> 2. fpga driver can only be used to process one bistream at a time,
>>> because different mode has different handling.
>> +} else if (!is_fpgamgr_early_user_mode()) {
>> +/* Program IOSSM(early IO release) or full FPGA */
>> +fpga_fs_info fpga_fsinfo;
>> +int len;
>> +
>> +fpga_fsinfo.filename = get_fpga_filename(gd-
>>> fdt_blob, );
>> +
>> +if (fpga_fsinfo.filename)
>> +socfpga_loadfs(_fsinfo, buf,
>> sizeof(buf), 0);
>> ...
>> +if (!is_fpgamgr_user_mode()) {
>> +fpga_fs_info fpga_fsinfo;
>> +int len;
>> +
>> +fpga_fsinfo.filename = get_fpga_filename(gd-
>>> fdt_blob, );
>> +
>> +if (fpga_fsinfo.filename)
>> +socfpga_loadfs(_fsinfo, buf,
>> sizeof(buf), 0);
>>
>> These two chunks look the same to me , no ?
> Yes, they are being called twice at different fpga mode, and different
> sequence, before and after DDR calibration.
So why can't these two chunks of code be de-duplicated ?
--
Best
Re: [U-Boot] [PATCH v8 2/8] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK
On 2/14/19 4:11 PM, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 13:24 +0100, Marek Vasut wrote:
>> On 2/14/19 12:23 PM, Chee, Tien Fong wrote:
>>>
>>> On Thu, 2019-02-14 at 11:35 +0100, Marek Vasut wrote:
On 2/14/19 7:04 AM, Chee, Tien Fong wrote:
>
>
> On Thu, 2019-02-14 at 00:04 +0100, Marek Vasut wrote:
>>
>>
>> On 2/13/19 11:45 PM, Dalon L Westergreen wrote:
>>>
>>>
>>>
>>> On Wed, 2019-02-13 at 17:10 +0100, Marek Vasut wrote:
On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
>
>
>
> From: Tien Fong Chee
>
> Add default fitImage file bundling FPGA bitstreams for
> Arria10.
>
> Signed-off-by: Tien Fong Chee >
>
> ---
>
> changes for v8
> - Changed the FPGA node name to fpga-core and fpga-
> periph
> for
> both core and
> periph bitstreams respectively.
> ---
> board/altera/arria10-socdk/fit_spl_fpga.its | 39
> +
> 1 file changed, 39 insertions(+)
> create mode 100644 board/altera/arria10-
> socdk/fit_spl_fpga.its
>
> diff --git a/board/altera/arria10-
> socdk/fit_spl_fpga.its
> b/board/altera/arria10-socdk/fit_spl_fpga.its
> new file mode 100644
> index 000..8ce175b
> --- /dev/null
> +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
> @@ -0,0 +1,39 @@
> +// SPDX-License-Identifier: GPL-2.0
> + /*
> + * Copyright (C) 2019 Intel Corporation >
> + *
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + description = "FIT image with FPGA bistream";
> + #address-cells = <1>;
> +
> + images {
> + fpga-core@1 {
> + description = "FPGA core
> bitstream";
> + data =
> /incbin/("../../../ghrd_10as066n2.core.rbf");
> + type = "fpga";
> + arch = "arm";
> + compression = "none";
> + load = <0x400>;
Is the load address required ?
> It is optional for telling destination address of DDR where
> this
> core.rbf going to be loaded. If load property, the default
> OCRAM
> buffer
> would be used, bad for performance when loading chunk by chunk.
So if I have something at 0x400 in DRAM and use this example in
U-
Boot,
it will be overwritten ?
>>> This is used for SPL only, at least for now, so that is before
>>> loading
>>> the U-Boot, DDR is blank.
>>> But, you can define the blank location.
>>> If load property is not defined, the driver would use small buffer
>>> from
>>> OCRAM.
How is OCRAM bad for performance ?
>>> With DDR, the performance can up to 85-90%.
>>> It is because very limited space in OCRAM, so very small buffer is
>>> used
>>> for loading bitstream, so the bitstream has to be loaded chunk by
>>> chunk.
>>> For DDR, where whole bitstream can be loaded.
>> Shouldn't the logic to determine where the buffer is be in the code ?
>> I mean, once you have DRAM available, you have all the malloc space,
>> so
>> you can use larger buffer.Why encode that knowledge into the fitImage
>> ?
> In previosly, we hard code the dest location for loading the core
> bitstream in SPL, because by that time DDR up running, but malloc is
> still pointed to OCRAM.
> Now, we let user to define the dest location through the load property.
But the user shouldn't care where the buffer is, the buffer should be in
the best possible location and the SPL can determine that (if DRAM is
running, in DRAM, otherwise in OCRAM), no ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 6/8] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
> On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
> >
> > On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
> > >
> > > On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: Tien Fong Chee
> > > > > >
> > > > > > Add support for loading FPGA bitstream to get DDR up
> > > > > > running
> > > > > > before
> > > > > > U-Boot is loaded into DDR. Boot device initialization,
> > > > > > generic
> > > > > > firmware
> > > > > > loader and SPL FAT support are required for this whole
> > > > > > mechanism to
> > > > > > work.
> > > > > >
> > > > > > Signed-off-by: Tien Fong Chee
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > changes for v7
> > > > > > - Removed casting for get_fpga_filename
> > > > > > - Removed hard coding DDR address for loading core
> > > > > > bistream,
> > > > > > using
> > > > > > loadable
> > > > > > property from FIT.
> > > > > > - Added checking for config_pins, return if error.
> > > > > > ---
> > > > > > arch/arm/mach-socfpga/spl_a10.c | 41
> > > > > > -
> > > > > > 1 file changed, 40 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > b/arch/arm/mach-
> > > > > > socfpga/spl_a10.c
> > > > > > index c97eacb..36003b1 100644
> > > > > > --- a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > > > > > @@ -1,6 +1,6 @@
> > > > > > // SPDX-License-Identifier: GPL-2.0+
> > > > > > /*
> > > > > > - * Copyright (C) 2012 Altera Corporation
> > > > > > + * Copyright (C) 2012-2019 Altera Corporation > > > > > .com
> > > > > > >
> > > > > > >
> > > > > > */
> > > > > >
> > > > > > #include
> > > > > > @@ -23,6 +23,8 @@
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > +#include
> > > > > > +#include
> > > > > >
> > > > > > DECLARE_GLOBAL_DATA_PTR;
> > > > > >
> > > > > > @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
> > > > > > boot_device)
> > > > > >
> > > > > > void spl_board_init(void)
> > > > > > {
> > > > > > + char buf[16 * 1024] __aligned(ARCH_DMA_MINALIGN);
> > > > > ALLOC_CACHE_ALIGN_BUFFER()
> > > > #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE
> > > > They are not same thing?
> > > See include/memalign.h and other drivers, the macro is preferred
> > > as
> > > it
> > > hides the details.
> > Okay.
> > >
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > +
> > > > > > /* enable console uart printing */
> > > > > > preloader_console_init();
> > > > > > WATCHDOG_RESET();
> > > > > >
> > > > > > arch_early_init_r();
> > > > > > +
> > > > > > + /* If the full FPGA is already loaded, ie.from
> > > > > > EPCQ,
> > > > > > config fpga pins */
> > > > > > + if (is_fpgamgr_user_mode()) {
> > > > > > + int ret = config_pins(gd->fdt_blob,
> > > > > > "shared");
> > > > > > +
> > > > > > + if (ret)
> > > > > > + return;
> > > > > > +
> > > > > > + ret = config_pins(gd->fdt_blob, "fpga");
> > > > > > + if (ret)
> > > > > > + return;
> > > > > > + } else if (!is_fpgamgr_early_user_mode()) {
> > > > > > + /* Program IOSSM(early IO release) or full
> > > > > > FPGA */
> > > > > > + fpga_fs_info fpga_fsinfo;
> > > > > > + int len;
> > > > > > +
> > > > > > + fpga_fsinfo.filename =
> > > > > > get_fpga_filename(gd-
> > > > > > >
> > > > > > >
> > > > > > > fdt_blob, );
> > > > > > +
> > > > > > + if (fpga_fsinfo.filename)
> > > > > > + socfpga_loadfs(_fsinfo, buf,
> > > > > > sizeof(buf), 0);
> > > > > Why is this code here twice ? The same code seems to be below
> > > > > ...
> > > > The 1st calling for periph program, then running ddr
> > > > calibration,
> > > > then
> > > > 2nd calling for core program.
> > > Then maybe the code can be deduplicated ?
> > Hmm...seems cannot, because
> > 1. DDR calibration is not part of fpga code.
> > 2. fpga driver can only be used to process one bistream at a time,
> > because different mode has different handling.
> + } else if (!is_fpgamgr_early_user_mode()) {
> + /* Program IOSSM(early IO release) or full FPGA */
> + fpga_fs_info fpga_fsinfo;
> + int len;
> +
> + fpga_fsinfo.filename = get_fpga_filename(gd-
> >fdt_blob, );
> +
> + if (fpga_fsinfo.filename)
> + socfpga_loadfs(_fsinfo, buf,
> sizeof(buf), 0);
> ...
> + if (!is_fpgamgr_user_mode()) {
> + fpga_fs_info fpga_fsinfo;
> + int len;
> +
> + fpga_fsinfo.filename = get_fpga_filename(gd-
>
Re: [U-Boot] [PATCH v8 4/8] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
On 2/14/19 4:14 PM, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 13:29 +0100, Marek Vasut wrote:
>> On 2/14/19 1:14 PM, Chee, Tien Fong wrote:
>>>
>>> On Thu, 2019-02-14 at 11:41 +0100, Marek Vasut wrote:
On 2/14/19 7:44 AM, Chee, Tien Fong wrote:
>
>
> On Wed, 2019-02-13 at 17:20 +0100, Marek Vasut wrote:
>>
>>
>> On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
>>>
>>>
>>>
>>> From: Tien Fong Chee
>>>
>>> Add FPGA driver to support program FPGA with FPGA bitstream
>>> loading
>>> from
>>> filesystem. The driver are designed based on generic
>>> firmware
>>> loader
>>> framework. The driver can handle FPGA program operation
>>> from
>>> loading FPGA
>>> bitstream in flash to memory and then to program FPGA.
>>>
>>> Signed-off-by: Tien Fong Chee
>>>
>>> ---
>>>
>>> changes for v8
>>> - Added codes to discern bitstream type based on fpga node
>>> name.
>>>
>>> changes for v7
>>> - Restructure the FPGA driver to support both peripheral
>>> bitstream
>>> and core
>>> bitstream bundled into FIT image.
>>> - Support loadable property for core bitstream. User can
>>> set
>>> loadable
>>> in DDR for better performance. This loading would be done
>>> in
>>> one
>>> large
>>> chunk instead of chunk by chunk loading with small memory
>>> buffer.
>>> ---
>>> arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 17 +
>>> .../include/mach/fpga_manager_arria10.h| 39
>>> +-
>>> drivers/fpga/socfpga_arria10.c | 467
>>> -
>>> 3 files changed, 500 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
>>> b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
>>> index 998d811..14f1967 100644
>>> --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
>>> +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
>>> [...]
>>>
>
>>
>>>
>>> - * FPGA Manager to program the FPGA. This is the interface
>>> used by
>>> FPGA driver.
>>> - * Return 0 for sucess, non-zero for error.
>>> - */
>>> +char *get_fpga_filename(const void *fdt, int *len)
>>> +{
>>> + char *fpga_filename = NULL;
>>> + int node_offset;
>>> +
>>> + fdtdec_find_aliases_for_id(gd->fdt_blob,
>>> "fpga_mgr",
>>> + COMPAT_ALTERA_SOCFPGA_FPGA
>>> 0,
>>> + _offset, 1);
>>> +
>>> + ofnode fpgamgr_node =
>>> offset_to_ofnode(node_offset);
>>> +
>>> + if (ofnode_valid(fpgamgr_node))
>>> + fpga_filename = (char
>>> *)ofnode_read_string(fpgamgr_node,
>>> + "altr,bits
>>> trea
>>> m");
>>> +
>>> +
>> Why is the cast needed ?
> The return string would be eventually set to the char *filename
> in
> common struct fpga_fsinfo. So, the cast here is to avoid the
> warning
> from compiler.
I presume if the compiler generates a warning, it's for a reason.
What
warning is that ?
>>> drivers/fpga/socfpga_arria10.c: In function 'get_fpga_filename':
>>> drivers/fpga/socfpga_arria10.c:466:17: warning: assignment discards
>>> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>>> fpga_filename = ofnode_read_string(fpgamgr_node,
>> Add missing const then ?
> Then this requires change on common struct fpga_fsinfo, this would
> impact to other user using this. Why the cast is not allow as we only
> reading the filename?
If the string isn't const, someone can write it. If someone writes this
string, won't it corrupt the DT ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 4/8] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
On Thu, 2019-02-14 at 13:29 +0100, Marek Vasut wrote:
> On 2/14/19 1:14 PM, Chee, Tien Fong wrote:
> >
> > On Thu, 2019-02-14 at 11:41 +0100, Marek Vasut wrote:
> > >
> > > On 2/14/19 7:44 AM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Wed, 2019-02-13 at 17:20 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: Tien Fong Chee
> > > > > >
> > > > > > Add FPGA driver to support program FPGA with FPGA bitstream
> > > > > > loading
> > > > > > from
> > > > > > filesystem. The driver are designed based on generic
> > > > > > firmware
> > > > > > loader
> > > > > > framework. The driver can handle FPGA program operation
> > > > > > from
> > > > > > loading FPGA
> > > > > > bitstream in flash to memory and then to program FPGA.
> > > > > >
> > > > > > Signed-off-by: Tien Fong Chee
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > changes for v8
> > > > > > - Added codes to discern bitstream type based on fpga node
> > > > > > name.
> > > > > >
> > > > > > changes for v7
> > > > > > - Restructure the FPGA driver to support both peripheral
> > > > > > bitstream
> > > > > > and core
> > > > > > bitstream bundled into FIT image.
> > > > > > - Support loadable property for core bitstream. User can
> > > > > > set
> > > > > > loadable
> > > > > > in DDR for better performance. This loading would be done
> > > > > > in
> > > > > > one
> > > > > > large
> > > > > > chunk instead of chunk by chunk loading with small memory
> > > > > > buffer.
> > > > > > ---
> > > > > > arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 17 +
> > > > > > .../include/mach/fpga_manager_arria10.h| 39
> > > > > > +-
> > > > > > drivers/fpga/socfpga_arria10.c | 467
> > > > > > -
> > > > > > 3 files changed, 500 insertions(+), 23 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > > > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > > > index 998d811..14f1967 100644
> > > > > > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > > > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > [...]
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > - * FPGA Manager to program the FPGA. This is the interface
> > > > > > used by
> > > > > > FPGA driver.
> > > > > > - * Return 0 for sucess, non-zero for error.
> > > > > > - */
> > > > > > +char *get_fpga_filename(const void *fdt, int *len)
> > > > > > +{
> > > > > > + char *fpga_filename = NULL;
> > > > > > + int node_offset;
> > > > > > +
> > > > > > + fdtdec_find_aliases_for_id(gd->fdt_blob,
> > > > > > "fpga_mgr",
> > > > > > + COMPAT_ALTERA_SOCFPGA_FPGA
> > > > > > 0,
> > > > > > + _offset, 1);
> > > > > > +
> > > > > > + ofnode fpgamgr_node =
> > > > > > offset_to_ofnode(node_offset);
> > > > > > +
> > > > > > + if (ofnode_valid(fpgamgr_node))
> > > > > > + fpga_filename = (char
> > > > > > *)ofnode_read_string(fpgamgr_node,
> > > > > > + "altr,bits
> > > > > > trea
> > > > > > m");
> > > > > > +
> > > > > > +
> > > > > Why is the cast needed ?
> > > > The return string would be eventually set to the char *filename
> > > > in
> > > > common struct fpga_fsinfo. So, the cast here is to avoid the
> > > > warning
> > > > from compiler.
> > > I presume if the compiler generates a warning, it's for a reason.
> > > What
> > > warning is that ?
> > drivers/fpga/socfpga_arria10.c: In function 'get_fpga_filename':
> > drivers/fpga/socfpga_arria10.c:466:17: warning: assignment discards
> > 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
> > fpga_filename = ofnode_read_string(fpgamgr_node,
> Add missing const then ?
Then this requires change on common struct fpga_fsinfo, this would
impact to other user using this. Why the cast is not allow as we only
reading the filename?
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 3/8] fit: Add function declarations to the header file
On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote: > On 2/14/19 12:51 PM, Chee, Tien Fong wrote: > > > > On Wed, 2019-02-13 at 17:11 +0100, Marek Vasut wrote: > > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote: > > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > Adding some function declarations to the header file, so these > > > > functions can be referred by other C files. > > > > > > > > Signed-off-by: Tien Fong Chee > > > > --- > > > > include/image.h | 4 > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/include/image.h b/include/image.h > > > > index 83a2d41..f839443 100644 > > > > --- a/include/image.h > > > > +++ b/include/image.h > > > > @@ -1041,6 +1041,10 @@ int fit_check_format(const void *fit); > > > > > > > > int fit_conf_find_compat(const void *fit, const void *fdt); > > > > int fit_conf_get_node(const void *fit, const char > > > > *conf_uname); > > > > +int fit_conf_get_prop_node_count(const void *fit, int noffset, > > > > + const char *prop_name); > > > > +int fit_conf_get_prop_node_index(const void *fit, int noffset, > > > > + const char *prop_name, int index); > > > Squash this patch with a patch adding those functions. > > Just to confirm again squashing this patch to the patch calling > > these > > function? > Yes Okay. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/8] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK
On Thu, 2019-02-14 at 13:24 +0100, Marek Vasut wrote:
> On 2/14/19 12:23 PM, Chee, Tien Fong wrote:
> >
> > On Thu, 2019-02-14 at 11:35 +0100, Marek Vasut wrote:
> > >
> > > On 2/14/19 7:04 AM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Thu, 2019-02-14 at 00:04 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 2/13/19 11:45 PM, Dalon L Westergreen wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 2019-02-13 at 17:10 +0100, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Tien Fong Chee
> > > > > > > >
> > > > > > > > Add default fitImage file bundling FPGA bitstreams for
> > > > > > > > Arria10.
> > > > > > > >
> > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > >
> > > > > > > >
> > > > > > > > ---
> > > > > > > >
> > > > > > > > changes for v8
> > > > > > > > - Changed the FPGA node name to fpga-core and fpga-
> > > > > > > > periph
> > > > > > > > for
> > > > > > > > both core and
> > > > > > > > periph bitstreams respectively.
> > > > > > > > ---
> > > > > > > > board/altera/arria10-socdk/fit_spl_fpga.its | 39
> > > > > > > > +
> > > > > > > > 1 file changed, 39 insertions(+)
> > > > > > > > create mode 100644 board/altera/arria10-
> > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > >
> > > > > > > > diff --git a/board/altera/arria10-
> > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > > b/board/altera/arria10-socdk/fit_spl_fpga.its
> > > > > > > > new file mode 100644
> > > > > > > > index 000..8ce175b
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
> > > > > > > > @@ -0,0 +1,39 @@
> > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > + /*
> > > > > > > > + * Copyright (C) 2019 Intel Corporation > > > > > > > >
> > > > > > > > + *
> > > > > > > > + */
> > > > > > > > +
> > > > > > > > +/dts-v1/;
> > > > > > > > +
> > > > > > > > +/ {
> > > > > > > > + description = "FIT image with FPGA bistream";
> > > > > > > > + #address-cells = <1>;
> > > > > > > > +
> > > > > > > > + images {
> > > > > > > > + fpga-core@1 {
> > > > > > > > + description = "FPGA core
> > > > > > > > bitstream";
> > > > > > > > + data =
> > > > > > > > /incbin/("../../../ghrd_10as066n2.core.rbf");
> > > > > > > > + type = "fpga";
> > > > > > > > + arch = "arm";
> > > > > > > > + compression = "none";
> > > > > > > > + load = <0x400>;
> > > > > > > Is the load address required ?
> > > > It is optional for telling destination address of DDR where
> > > > this
> > > > core.rbf going to be loaded. If load property, the default
> > > > OCRAM
> > > > buffer
> > > > would be used, bad for performance when loading chunk by chunk.
> > > So if I have something at 0x400 in DRAM and use this example in
> > > U-
> > > Boot,
> > > it will be overwritten ?
> > This is used for SPL only, at least for now, so that is before
> > loading
> > the U-Boot, DDR is blank.
> > But, you can define the blank location.
> > If load property is not defined, the driver would use small buffer
> > from
> > OCRAM.
> > >
> > >
> > > How is OCRAM bad for performance ?
> > With DDR, the performance can up to 85-90%.
> > It is because very limited space in OCRAM, so very small buffer is
> > used
> > for loading bitstream, so the bitstream has to be loaded chunk by
> > chunk.
> > For DDR, where whole bitstream can be loaded.
> Shouldn't the logic to determine where the buffer is be in the code ?
> I mean, once you have DRAM available, you have all the malloc space,
> so
> you can use larger buffer.Why encode that knowledge into the fitImage
> ?
In previosly, we hard code the dest location for loading the core
bitstream in SPL, because by that time DDR up running, but malloc is
still pointed to OCRAM.
Now, we let user to define the dest location through the load property.
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + fpga-periph@2 {
> > > > > > > > + description = "FPGA peripheral
> > > > > > > > bitstream";
> > > > > > > > + data =
> > > > > > > > /incbin/("../../../ghrd_10as066n2.periph.rbf");
> > > > > > > > + type = "fpga";
> > > > > > > > + arch = "arm";
> > > > > > > > + compression = "none";
> > > > > > > > + };
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + configurations {
> > > > > > > > + default = "config-1";
> > > > > > > > + config-1 {
> > > > > > > > + description
Re: [U-Boot] [PATCH v8 4/8] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
On 2/14/19 1:14 PM, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 11:41 +0100, Marek Vasut wrote:
>> On 2/14/19 7:44 AM, Chee, Tien Fong wrote:
>>>
>>> On Wed, 2019-02-13 at 17:20 +0100, Marek Vasut wrote:
On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
>
>
> From: Tien Fong Chee
>
> Add FPGA driver to support program FPGA with FPGA bitstream
> loading
> from
> filesystem. The driver are designed based on generic firmware
> loader
> framework. The driver can handle FPGA program operation from
> loading FPGA
> bitstream in flash to memory and then to program FPGA.
>
> Signed-off-by: Tien Fong Chee
>
> ---
>
> changes for v8
> - Added codes to discern bitstream type based on fpga node
> name.
>
> changes for v7
> - Restructure the FPGA driver to support both peripheral
> bitstream
> and core
> bitstream bundled into FIT image.
> - Support loadable property for core bitstream. User can set
> loadable
> in DDR for better performance. This loading would be done in
> one
> large
> chunk instead of chunk by chunk loading with small memory
> buffer.
> ---
> arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 17 +
> .../include/mach/fpga_manager_arria10.h| 39 +-
> drivers/fpga/socfpga_arria10.c | 467
> -
> 3 files changed, 500 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> index 998d811..14f1967 100644
> --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> [...]
>
> - * FPGA Manager to program the FPGA. This is the interface
> used by
> FPGA driver.
> - * Return 0 for sucess, non-zero for error.
> - */
> +char *get_fpga_filename(const void *fdt, int *len)
> +{
> + char *fpga_filename = NULL;
> + int node_offset;
> +
> + fdtdec_find_aliases_for_id(gd->fdt_blob, "fpga_mgr",
> + COMPAT_ALTERA_SOCFPGA_FPGA0,
> + _offset, 1);
> +
> + ofnode fpgamgr_node = offset_to_ofnode(node_offset);
> +
> + if (ofnode_valid(fpgamgr_node))
> + fpga_filename = (char
> *)ofnode_read_string(fpgamgr_node,
> + "altr,bitstrea
> m");
> +
> +
Why is the cast needed ?
>>> The return string would be eventually set to the char *filename in
>>> common struct fpga_fsinfo. So, the cast here is to avoid the
>>> warning
>>> from compiler.
>> I presume if the compiler generates a warning, it's for a reason.
>> What
>> warning is that ?
> drivers/fpga/socfpga_arria10.c: In function 'get_fpga_filename':
> drivers/fpga/socfpga_arria10.c:466:17: warning: assignment discards
> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
> fpga_filename = ofnode_read_string(fpgamgr_node,
Add missing const then ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 6/8] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
>> On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
>>>
>>> On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
>
>
> From: Tien Fong Chee
>
> Add support for loading FPGA bitstream to get DDR up running
> before
> U-Boot is loaded into DDR. Boot device initialization, generic
> firmware
> loader and SPL FAT support are required for this whole
> mechanism to
> work.
>
> Signed-off-by: Tien Fong Chee
>
> ---
>
> changes for v7
> - Removed casting for get_fpga_filename
> - Removed hard coding DDR address for loading core bistream,
> using
> loadable
> property from FIT.
> - Added checking for config_pins, return if error.
> ---
> arch/arm/mach-socfpga/spl_a10.c | 41
> -
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-
> socfpga/spl_a10.c
> index c97eacb..36003b1 100644
> --- a/arch/arm/mach-socfpga/spl_a10.c
> +++ b/arch/arm/mach-socfpga/spl_a10.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright (C) 2012 Altera Corporation
> + * Copyright (C) 2012-2019 Altera Corporation >
> */
>
> #include
> @@ -23,6 +23,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32 boot_device)
>
> void spl_board_init(void)
> {
> + char buf[16 * 1024] __aligned(ARCH_DMA_MINALIGN);
ALLOC_CACHE_ALIGN_BUFFER()
>>> #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE
>>> They are not same thing?
>> See include/memalign.h and other drivers, the macro is preferred as
>> it
>> hides the details.
> Okay.
>>
>>>
>
>
> +
> /* enable console uart printing */
> preloader_console_init();
> WATCHDOG_RESET();
>
> arch_early_init_r();
> +
> + /* If the full FPGA is already loaded, ie.from EPCQ,
> config fpga pins */
> + if (is_fpgamgr_user_mode()) {
> + int ret = config_pins(gd->fdt_blob, "shared");
> +
> + if (ret)
> + return;
> +
> + ret = config_pins(gd->fdt_blob, "fpga");
> + if (ret)
> + return;
> + } else if (!is_fpgamgr_early_user_mode()) {
> + /* Program IOSSM(early IO release) or full
> FPGA */
> + fpga_fs_info fpga_fsinfo;
> + int len;
> +
> + fpga_fsinfo.filename = get_fpga_filename(gd-
>>
>> fdt_blob, );
> +
> + if (fpga_fsinfo.filename)
> + socfpga_loadfs(_fsinfo, buf,
> sizeof(buf), 0);
Why is this code here twice ? The same code seems to be below ...
>>> The 1st calling for periph program, then running ddr calibration,
>>> then
>>> 2nd calling for core program.
>> Then maybe the code can be deduplicated ?
> Hmm...seems cannot, because
> 1. DDR calibration is not part of fpga code.
> 2. fpga driver can only be used to process one bistream at a time,
> because different mode has different handling.
+ } else if (!is_fpgamgr_early_user_mode()) {
+ /* Program IOSSM(early IO release) or full FPGA */
+ fpga_fs_info fpga_fsinfo;
+ int len;
+
+ fpga_fsinfo.filename = get_fpga_filename(gd->fdt_blob, );
+
+ if (fpga_fsinfo.filename)
+ socfpga_loadfs(_fsinfo, buf, sizeof(buf), 0);
...
+ if (!is_fpgamgr_user_mode()) {
+ fpga_fs_info fpga_fsinfo;
+ int len;
+
+ fpga_fsinfo.filename = get_fpga_filename(gd->fdt_blob, );
+
+ if (fpga_fsinfo.filename)
+ socfpga_loadfs(_fsinfo, buf, sizeof(buf), 0);
These two chunks look the same to me , no ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/8] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK
On 2/14/19 12:23 PM, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 11:35 +0100, Marek Vasut wrote:
>> On 2/14/19 7:04 AM, Chee, Tien Fong wrote:
>>>
>>> On Thu, 2019-02-14 at 00:04 +0100, Marek Vasut wrote:
On 2/13/19 11:45 PM, Dalon L Westergreen wrote:
>
>
> On Wed, 2019-02-13 at 17:10 +0100, Marek Vasut wrote:
>>
>>
>> On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
>>>
>>>
>>> From: Tien Fong Chee
>>>
>>> Add default fitImage file bundling FPGA bitstreams for
>>> Arria10.
>>>
>>> Signed-off-by: Tien Fong Chee
>>>
>>> ---
>>>
>>> changes for v8
>>> - Changed the FPGA node name to fpga-core and fpga-periph
>>> for
>>> both core and
>>> periph bitstreams respectively.
>>> ---
>>> board/altera/arria10-socdk/fit_spl_fpga.its | 39
>>> +
>>> 1 file changed, 39 insertions(+)
>>> create mode 100644 board/altera/arria10-
>>> socdk/fit_spl_fpga.its
>>>
>>> diff --git a/board/altera/arria10-socdk/fit_spl_fpga.its
>>> b/board/altera/arria10-socdk/fit_spl_fpga.its
>>> new file mode 100644
>>> index 000..8ce175b
>>> --- /dev/null
>>> +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
>>> @@ -0,0 +1,39 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> + /*
>>> + * Copyright (C) 2019 Intel Corporation
>>> + *
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +/ {
>>> + description = "FIT image with FPGA bistream";
>>> + #address-cells = <1>;
>>> +
>>> + images {
>>> + fpga-core@1 {
>>> + description = "FPGA core
>>> bitstream";
>>> + data =
>>> /incbin/("../../../ghrd_10as066n2.core.rbf");
>>> + type = "fpga";
>>> + arch = "arm";
>>> + compression = "none";
>>> + load = <0x400>;
>> Is the load address required ?
>>> It is optional for telling destination address of DDR where this
>>> core.rbf going to be loaded. If load property, the default OCRAM
>>> buffer
>>> would be used, bad for performance when loading chunk by chunk.
>> So if I have something at 0x400 in DRAM and use this example in U-
>> Boot,
>> it will be overwritten ?
> This is used for SPL only, at least for now, so that is before loading
> the U-Boot, DDR is blank.
> But, you can define the blank location.
> If load property is not defined, the driver would use small buffer from
> OCRAM.
>>
>> How is OCRAM bad for performance ?
> With DDR, the performance can up to 85-90%.
> It is because very limited space in OCRAM, so very small buffer is used
> for loading bitstream, so the bitstream has to be loaded chunk by
> chunk.
> For DDR, where whole bitstream can be loaded.
Shouldn't the logic to determine where the buffer is be in the code ?
I mean, once you have DRAM available, you have all the malloc space, so
you can use larger buffer. Why encode that knowledge into the fitImage ?
>>>
>>> + };
>>> +
>>> + fpga-periph@2 {
>>> + description = "FPGA peripheral
>>> bitstream";
>>> + data =
>>> /incbin/("../../../ghrd_10as066n2.periph.rbf");
>>> + type = "fpga";
>>> + arch = "arm";
>>> + compression = "none";
>>> + };
>>> + };
>>> +
>>> + configurations {
>>> + default = "config-1";
>>> + config-1 {
>>> + description = "Boot with FPGA
>>> early IO
>>> release config";
>>> + fpga = "fpga-periph@2", "fpga-core
>>> @1";
>> Don't you need to load the core first ?
> No, the periphery is first. This brings up the dram and i/o.
Then why do we have periph@2 above ? Shouldn't those two images
be
swapped to make this look less confusing ?
>>> The ordering in configuration fpga property doesn't matter, the
>>> driver
>>> smart enough to determine what bitstream need to be programmed at
>>> what
>>> FPGA mode.
>> Good, then please order it naturally, @1 then @2 etc .
> Okay.
>>
>>>
>>> The image fpga-core@1 is alligned at 1st just for avoiding
>>> the performance penalty.
>> I thought we concluded this should be fixed elsewhere ?
> May be we can wait until there is a solution? So user can benefit the
> good performance with this default fitIMage?
This will only work for specific cases of specific storage devices and
filesystems .
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 3/8] fit: Add function declarations to the header file
On 2/14/19 12:51 PM, Chee, Tien Fong wrote: > On Wed, 2019-02-13 at 17:11 +0100, Marek Vasut wrote: >> On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote: >>> >>> From: Tien Fong Chee >>> >>> Adding some function declarations to the header file, so these >>> functions can be referred by other C files. >>> >>> Signed-off-by: Tien Fong Chee >>> --- >>> include/image.h | 4 >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/include/image.h b/include/image.h >>> index 83a2d41..f839443 100644 >>> --- a/include/image.h >>> +++ b/include/image.h >>> @@ -1041,6 +1041,10 @@ int fit_check_format(const void *fit); >>> >>> int fit_conf_find_compat(const void *fit, const void *fdt); >>> int fit_conf_get_node(const void *fit, const char *conf_uname); >>> +int fit_conf_get_prop_node_count(const void *fit, int noffset, >>> + const char *prop_name); >>> +int fit_conf_get_prop_node_index(const void *fit, int noffset, >>> + const char *prop_name, int index); >> Squash this patch with a patch adding those functions. > Just to confirm again squashing this patch to the patch calling these > function? Yes -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] warp7: README: Adjust the binary name after DM conversion
Le 09/02/2019 à 15:01, Fabio Estevam a écrit : After the conversion to DM the U-Boot binary is called u-boot-dtb.imx, so fix the README file accordingly. Signed-off-by: Fabio Estevam --- Changes since v1: - Fix all occurrances board/warp7/README | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/board/warp7/README b/board/warp7/README index 60339da543..579bb2de38 100644 --- a/board/warp7/README +++ b/board/warp7/README @@ -17,7 +17,7 @@ $ make mrproper $ make warp7_config Hi Fabio Fix typo warp7_config into warp7_defconig $ make -This will generate the U-Boot binary called u-boot.imx. +This will generate the U-Boot binary called u-boot-dtb.imx. Put warp7 board in USB download mode: @@ -28,11 +28,11 @@ Connect a USB to serial adapter between the host PC and warp7 Connect a USB cable between the OTG warp7 port and the host PC -Copy u-boot.imx to the imx_usb_loader folder. +Copy u-boot-dtb.imx to the imx_usb_loader folder. -Load u-boot.imx via USB: +Load u-boot-dtb.imx via USB: -$ sudo ./imx_usb u-boot.imx +$ sudo ./imx_usb u-boot-dtb.imx Then U-Boot should start and its messages will appear in the console program. @@ -46,9 +46,9 @@ Use the default environment variables: Run the DFU command: => dfu 0 mmc 0 -Transfer u-boot.imx that will be flashed into the eMMC: +Transfer u-boot-dtb.imx that will be flashed into the eMMC: -$ sudo dfu-util -D u-boot.imx -a boot +$ sudo dfu-util -D u-boot-dtb.imx -a boot Then on the U-Boot prompt the following message should be seen after a successful upgrade: ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] rpi: add Compute Module 3+
On 30.01.19 23:24, Jonathan Gray wrote:
> Add Raspberry Pi Compute Module 3+ to list of models, the revision code
> is 0x10 according to the list on raspberrypi.org.
>
> v2: Use the same dtb name as CM3 as CM3+ is a drop in replacement
> for CM3.
>
> Signed-off-by: Jonathan Gray
Reviewed-by: Alexander Graf
Alex
> ---
> board/raspberrypi/rpi/rpi.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index 153a1fdcb7..617c892dde 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -143,6 +143,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
> DTB_DIR "bcm2837-rpi-3-a-plus.dtb",
> false,
> },
> + [0x10] = {
> + "Compute Module 3+",
> + DTB_DIR "bcm2837-rpi-cm3.dtb",
> + false,
> + },
> };
>
> static const struct rpi_model rpi_models_old_scheme[] = {
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] warp7: Fix the write to the LDOGCTL PMIC register
The third parameter of the pmic_clrsetbits() function is the mask
to the register and the correct mask is 1 not 0.
Since the LDOGCTL only contains a single valid bit (bit 0),
we can use pmic_reg_write() and write 1 directly, which fixes
the problem in a simpler way and use the original pmic function
that was used prior to the DM PMIC conversion.
Fixes: 8ba377321c86 ("arm: imx7s-warp: Convert to DM PMIC")
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Fix typo in commit message: "contains a single valid bit"
board/warp7/warp7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 49f290f978..2882dc9870 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -77,7 +77,7 @@ int power_init_board(void)
printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", dev_id, rev_id);
/* disable Low Power Mode during standby mode */
- pmic_clrsetbits(dev, PFUZE3000_LDOGCTL, 0, 1);
+ pmic_reg_write(dev, PFUZE3000_LDOGCTL, 1);
return 0;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rpi: Make Matthias maintainer
Matthias Brugger agreed to take over maintainership from me for the Raspberry Pi tree. Add him to the MAINTAINERS file instead. Signed-off-by: Alexander Graf --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d219c06ec9..f1f8818d6b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -114,7 +114,7 @@ F: include/configs/meson64.h N: meson ARM BROADCOM BCM283X -M: Alexander Graf +M: Matthias Brugger S: Maintained F: arch/arm/mach-bcm283x/ F: drivers/gpio/bcm2835_gpio.c -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] mx6ul_14x14_evk: Simplify the PMIC register writes
There is no need to store the values written to the PMIC inside the 'reg' variable. Make it simpler by writing the values directly. Signed-off-by: Fabio Estevam --- Changes since v1: - Remove 1/2 notation, since this is a standalome patch - Add Peng Fan on Cc board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c index 595ad76bbe..636c008993 100644 --- a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c +++ b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c @@ -86,16 +86,13 @@ int power_init_board(void) pmic_reg_write(dev, PFUZE3000_LDOGCTL, reg); /* SW1B step ramp up time from 2us to 4us/25mV */ - reg = 0x40; - pmic_reg_write(dev, PFUZE3000_SW1BCONF, reg); + pmic_reg_write(dev, PFUZE3000_SW1BCONF, 0x40); /* SW1B mode to APS/PFM */ - reg = 0xc; - pmic_reg_write(dev, PFUZE3000_SW1BMODE, reg); + pmic_reg_write(dev, PFUZE3000_SW1BMODE, 0xc); /* SW1B standby voltage set to 0.975V */ - reg = 0xb; - pmic_reg_write(dev, PFUZE3000_SW1BSTBY, reg); + pmic_reg_write(dev, PFUZE3000_SW1BSTBY, 0xb); return 0; } -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: Swap roles with Heinrich
Heinrich is going to take over maintainership of the efi_loader tree going forward. To ensure that I will still receive review mails at least, add me as reviewer with a stable email address. Signed-off-by: Alexander Graf --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 29449ffed6..d219c06ec9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -453,8 +453,8 @@ F: include/dm/ F: test/dm/ EFI PAYLOAD -M: Alexander Graf -R: Heinrich Schuchardt +M: Heinrich Schuchardt +R: Alexander Graf S: Maintained T: git git://github.com/agraf/u-boot.git F: doc/README.uefi -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx6ul_14x14_evk: Simplify the PMIC register writes
There is no need to store the values written to the PMIC inside the 'reg' variable. Make it simpler by writing the values directly. Signed-off-by: Fabio Estevam --- board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c index 595ad76bbe..636c008993 100644 --- a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c +++ b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c @@ -86,16 +86,13 @@ int power_init_board(void) pmic_reg_write(dev, PFUZE3000_LDOGCTL, reg); /* SW1B step ramp up time from 2us to 4us/25mV */ - reg = 0x40; - pmic_reg_write(dev, PFUZE3000_SW1BCONF, reg); + pmic_reg_write(dev, PFUZE3000_SW1BCONF, 0x40); /* SW1B mode to APS/PFM */ - reg = 0xc; - pmic_reg_write(dev, PFUZE3000_SW1BMODE, reg); + pmic_reg_write(dev, PFUZE3000_SW1BMODE, 0xc); /* SW1B standby voltage set to 0.975V */ - reg = 0xb; - pmic_reg_write(dev, PFUZE3000_SW1BSTBY, reg); + pmic_reg_write(dev, PFUZE3000_SW1BSTBY, 0xb); return 0; } -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] warp7: Fix the write to the LDOGCTL PMIC register
The third parameter of the pmic_clrsetbits() function is the mask
to the register and the correct mask is 1 not 0.
Since the LDOGCTL only contains a single valid register (bit 0),
we can use pmic_reg_write() and write 1 directly, which fixes
the problem in a simpler way and use the original pmic function
that was used prior to the DM PMIC conversion.
Fixes: 8ba377321c86 ("arm: imx7s-warp: Convert to DM PMIC")
Signed-off-by: Fabio Estevam
---
board/warp7/warp7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 49f290f978..2882dc9870 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -77,7 +77,7 @@ int power_init_board(void)
printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", dev_id, rev_id);
/* disable Low Power Mode during standby mode */
- pmic_clrsetbits(dev, PFUZE3000_LDOGCTL, 0, 1);
+ pmic_reg_write(dev, PFUZE3000_LDOGCTL, 1);
return 0;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_selftest: fix memory allocation in HII tests
On 12.02.19 22:01, Heinrich Schuchardt wrote: > In efi_selftest we are in EFI land. We cannot call U-Boot library > functions malloc() and free() but should use the boot time services > instead. > > Signed-off-by: Heinrich Schuchardt Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_selftest: do not use efi_free_pool()
On 12.02.19 22:02, Heinrich Schuchardt wrote: > In efi_selftest we are in EFI land. We should not use U-Boot library > functions but boot time services for memory management. > > Signed-off-by: Heinrich Schuchardt Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: Downgrade SD/MMC from UHS/HS200/HS400 modes before boot
Older kernel versions or systems which do not connect eMMC reset line
properly may not be able to handle situations where either the eMMC
is left in HS200/HS400 mode or SD card in UHS modes by the bootloader
and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card
to non-UHS mode before booting the kernel to allow such older kernels
to work with modern U-Boot.
Signed-off-by: Marek Vasut
Cc: Tom Rini
---
drivers/mmc/mmc-uclass.c | 19 +++
drivers/mmc/mmc.c| 26 ++
include/mmc.h| 6 ++
3 files changed, 51 insertions(+)
diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 76225b7939..a9c8f335c1 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -368,6 +368,19 @@ static int mmc_blk_probe(struct udevice *dev)
return 0;
}
+#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+static int mmc_blk_remove(struct udevice *dev)
+{
+ struct udevice *mmc_dev = dev_get_parent(dev);
+ struct mmc_uclass_priv *upriv = dev_get_uclass_priv(mmc_dev);
+ struct mmc *mmc = upriv->mmc;
+
+ return mmc_deinit(mmc);
+}
+#endif
+
static const struct blk_ops mmc_blk_ops = {
.read = mmc_bread,
#if CONFIG_IS_ENABLED(MMC_WRITE)
@@ -382,6 +395,12 @@ U_BOOT_DRIVER(mmc_blk) = {
.id = UCLASS_BLK,
.ops= _blk_ops,
.probe = mmc_blk_probe,
+#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+ .remove = mmc_blk_remove,
+ .flags = DM_FLAG_OS_PREPARE,
+#endif
};
#endif /* CONFIG_BLK */
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index b04345a1e1..1c1527cc74 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2781,6 +2781,32 @@ int mmc_init(struct mmc *mmc)
return err;
}
+#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+int mmc_deinit(struct mmc *mmc)
+{
+ u32 caps_filtered;
+
+ if (!mmc->has_init)
+ return 0;
+
+ if (IS_SD(mmc)) {
+ caps_filtered = mmc->card_caps &
+ ~(MMC_CAP(UHS_SDR12) | MMC_CAP(UHS_SDR25) |
+ MMC_CAP(UHS_SDR50) | MMC_CAP(UHS_DDR50) |
+ MMC_CAP(UHS_SDR104));
+
+ return sd_select_mode_and_width(mmc, caps_filtered);
+ } else {
+ caps_filtered = mmc->card_caps &
+ ~(MMC_CAP(MMC_HS_200) | MMC_CAP(MMC_HS_400));
+
+ return mmc_select_mode_and_width(mmc, caps_filtered);
+ }
+}
+#endif
+
int mmc_set_dsr(struct mmc *mmc, u16 val)
{
mmc->dsr = val;
diff --git a/include/mmc.h b/include/mmc.h
index d84e4fca73..1f30f71d25 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -690,6 +690,12 @@ int mmc_initialize(bd_t *bis);
int mmc_init(struct mmc *mmc);
int mmc_send_tuning(struct mmc *mmc, u32 opcode, int *cmd_error);
+#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+int mmc_deinit(struct mmc *mmc);
+#endif
+
/**
* mmc_of_parse() - Parse the device tree to get the capabilities of the host
*
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Antwort: Re: [PATCH] zynq: fix I2C in SPL
On 2/14/19 1:26 PM, Michal Simek wrote:
On 14. 02. 19 8:52, Hannes Schmelzer wrote:
Hi,
Hi Michal,
first of all I would rephrase subject a little bit.
Something like:
"ARM: zynq: Add missing i2c get_rate for fixing i2c SPL"
OK.
On 14. 02. 19 6:50, Hannes Schmelzer wrote:
The commit 'f48ef0d81aa837a33020f8d61abb3929ba613774' did break I2C
support because requesting the clock for the I2C ip-block isn't
supported during SPL.
To fixup this we add support requesting clocks for:
- i2c0
- i2c1
Signed-off-by: Hannes Schmelzer
---
drivers/clk/clk_zynq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/clk_zynq.c b/drivers/clk/clk_zynq.c
index 482f093..9a4e949 100644
--- a/drivers/clk/clk_zynq.c
+++ b/drivers/clk/clk_zynq.c
@@ -434,6 +434,9 @@ static ulong zynq_clk_get_rate(struct clk *clk)
case lqspi_clk ... pcap_clk:
case sdio0_clk ... spi1_clk:
return zynq_clk_get_peripheral_rate(priv, id, 0);
+ case i2c0_aper_clk ... i2c1_aper_clk:
+ return zynq_clk_get_cpu_rate(priv, cpu_1x_clk);
+
please remove this empty line.
OK. I'll send V2 patch.
default:
return -ENXIO;
}
I am also curious why you are enabling I2C in SPL. What are you doing
with that?
I have to turn on very early some voltage rails on my board, where i have
to communicate with i2c to a resetcontroller.
ok. How does that code look like?
Just dm_i2c_write?
I have never tried i2c in spl.
hi michal,
here for example:
int board_init(void) /* spl stage */
{
u16 u16buf;
u8 u8buf;
int rc;
struct udevice *dev;
/* peripheral RESET on PSOC reset-controller */
rc = i2c_get_chip_for_busnum(0, RSTCTRL_ADDR_PSOC, 1, );
if (rc == 0) {
u16buf = RSTCTRL_CTRLSPEC_nPCIRST;
rc = dm_i2c_write(dev, RSTCTRL_CTRLSPEC,
(uint8_t *), sizeof(u16buf));
} else {
printf("failed to get i2c chip for PSOC resetcontroller!\n");
}
return 0;
}
later on my plan is to push my board mainline once development has been
finished.
Thanks,
Michal
cheers,
Hannes
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
