Re: [U-Boot] [PATCH v7 18/21] mtd: nand: Kconfig: Add NAND_MXS entry
On Wed, Oct 12, 2016 at 3:40 AM, Jörg Krause wrote: > On Sa, 2016-10-08 at 18:00 +0530, Jagan Teki wrote: >> From: Jagan Teki >> >> Added kconfig for NAND_MXS driver. >> >> Cc: Scott Wood >> Cc: Simon Glass >> Cc: Fabio Estevam >> Cc: Stefano Babic >> Cc: Peng Fan >> Cc: Matteo Lisi >> Cc: Michael Trimarchi >> Signed-off-by: Jagan Teki >> --- >> drivers/mtd/nand/Kconfig | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig >> index 5ce7d6d..df154bf 100644 >> --- a/drivers/mtd/nand/Kconfig >> +++ b/drivers/mtd/nand/Kconfig >> @@ -80,6 +80,13 @@ config NAND_ARASAN >> controller. This uses the hardware ECC for read and >> write operations. >> >> +config NAND_MXS >> + bool "MXS NAND support" >> + depends on MX6 > > Isn't mxs supposed to be i.MX23/i.MX28 and not i.MX6? Yes will ||ed once the nand config used by MX23/28 are planing to move defconfig. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] power: regulator: Add limits checking while setting voltage and current
On Tuesday 11 October 2016 05:49 AM, Simon Glass wrote:
Hi Keerthy,
On 15 September 2016 at 05:16, Keerthy wrote:
On Thursday 15 September 2016 04:38 PM, Keerthy wrote:
On Thursday 15 September 2016 04:26 PM, Przemyslaw Marczak wrote:
Hello Keerthy,
On 09/15/2016 10:54 AM, Keerthy wrote:
Currently the specific set ops functions are directly
called without any check for voltage/current limits for a regulator.
Check for them and proceed.
Signed-off-by: Keerthy
---
drivers/power/regulator/regulator-uclass.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 4434e36..089455e 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -41,6 +41,11 @@ int regulator_get_value(struct udevice *dev)
int regulator_set_value(struct udevice *dev, int uV)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+struct dm_regulator_uclass_platdata *uc_pdata;
+
+uc_pdata = dev_get_uclass_platdata(dev);
+if (uV < uc_pdata->min_uV || uV > uc_pdata->max_uV)
+return -EINVAL;
if (!ops || !ops->set_value)
return -ENOSYS;
@@ -61,6 +66,11 @@ int regulator_get_current(struct udevice *dev)
int regulator_set_current(struct udevice *dev, int uA)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+struct dm_regulator_uclass_platdata *uc_pdata;
+
+uc_pdata = dev_get_uclass_platdata(dev);
+if (uA < uc_pdata->min_uA || uA > uc_pdata->max_uA)
+return -EINVAL;
if (!ops || !ops->set_current)
return -ENOSYS;
Adding those two checks will conflict with "force" option for
cmd/regulator.c:283.
There was value range checking in the command's code, but it was left
unchecked
for regulator direct calls.
This change is good, but then maybe the "force" option should be removed
from command,
or API's prototypes should be updated by force flag argument?
I assumed that this option could be useful for quick over-voltage
setting (until reboot),
since usually (min_uV == max_uV) - the voltage can't be changed in any
range.
The driver should take care about ignore it or not, however probably
nobody used this.
Of course this could potentially damage the device by wrong use,
which can be also made by passing the force flag as an argument - by
mistake.
What do you thing about, update the dm_regulator_ops by:
- int (*set_value)(struct udevice *dev, int uV, int flag);
- int (*set_current)(struct udevice *dev, int uA, int flag);
I personally do not like setting an extra flag everywhere just because we
want to support force option.
I would rather have 2 functions like:
int (*force_set_value)(struct udevice *dev, int uV);
int (*force_set_current)(struct udevice *dev, int uA);
Where we can set the value ignoring the limits. But again that must be used
with at most caution as setting higher voltages might end up damaging the
device.
That seems OK to me.
and also new flag to the present defined:
- REGULATOR_FLAG_FORCE = 1 << 2
This requires more work, but will provide the functionality in a proper
way.
I do not know cmd_regulator is the right place to check for min_uV and
max_uV. dm_regulator_uclass_platdata has both the limits and this i feel
is a perfectly valid check in generic place else we would be again
checking for the same condition in every possible regulator specific
drivers.
As far as the force option is concerned that i believe is more for
testing and like you said can be implemented by setting a flag.
Just take a simple case of say a driver like mmc which unknowingly
requests a wrong voltage and the base driver has no check against min
and max voltages and assuming the regulator driver goes ahead and sets a
very high voltage. That can be catastrophic right?
What is the status of this patch please?
Also it breaks tests (make tests) - can you please take a look?
Sure Simon. It was hanging somehow. I will redo and repost it.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 2/2] pinctrl: pinctrl-at91: Add pinctrl driver
AT91 PIO controller is a combined gpio-controller, pin-mux and
pin-config module. The peripheral's pins are assigned through
per-pin based muxing logic.
Each soc will have to describe the SoC limitation and pin
configuration via DT. This will allow to do not need to touch
the C code when adding new SoC if the IP version is supported.
Signed-off-by: Wenyou Yang
---
arch/arm/mach-at91/include/mach/at91_pio.h | 6 +-
drivers/pinctrl/Kconfig| 7 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-at91.c | 451 +
4 files changed, 464 insertions(+), 1 deletion(-)
create mode 100644 drivers/pinctrl/pinctrl-at91.c
diff --git a/arch/arm/mach-at91/include/mach/at91_pio.h
b/arch/arm/mach-at91/include/mach/at91_pio.h
index 393a163..f195a7d 100644
--- a/arch/arm/mach-at91/include/mach/at91_pio.h
+++ b/arch/arm/mach-at91/include/mach/at91_pio.h
@@ -107,7 +107,11 @@ typedef struct at91_port {
u32 wpsr; /* 0xE8 Write Protect Status Register */
u32 reserved11[5]; /* */
u32 schmitt;/* 0x100 Schmitt Trigger Register */
- u32 reserved12[63];
+ u32 reserved12[4]; /* 0x104 ~ 0x110 */
+ u32 driver1;/* 0x114 I/O Driver Register1(AT91SAM9x5's
driver1) */
+ u32 driver12; /* 0x118 I/O Driver Register12(AT91SAM9x5's
driver2 or SAMA5D3x's driver1 ) */
+ u32 driver2;/* 0x11C I/O Driver Register2(SAMA5D3x's
driver2) */
+ u32 reserved13[12]; /* 0x120 ~ 0x14C */
} at91_port_t;
typedef union at91_pio {
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 12be3cf..87a7ff0 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -141,6 +141,13 @@ config ROCKCHIP_RK3288_PINCTRL
definitions and pin control functions for each available multiplex
function.
+config PINCTRL_AT91
+ bool "AT91 pinctrl driver"
+ depends on DM
+ help
+ This option is to enable the AT91 pinctrl driver for AT91 PIO
+ controller.
+
config PINCTRL_AT91PIO4
bool "AT91 PIO4 pinctrl driver"
depends on DM
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f28b5c1..a9535fa 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -5,6 +5,7 @@
obj-y += pinctrl-uclass.o
obj-$(CONFIG_$(SPL_)PINCTRL_GENERIC) += pinctrl-generic.o
+obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
obj-$(CONFIG_PINCTRL_AT91PIO4) += pinctrl-at91-pio4.o
obj-y += nxp/
obj-$(CONFIG_ARCH_ATH79) += ath79/
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
new file mode 100644
index 000..c7f75cb
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -0,0 +1,451 @@
+/*
+ * Atmel PIO pinctrl driver
+ *
+ * Copyright (C) 2016 Atmel Corporation
+ * Wenyou.Yang
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MAX_GPIO_BANKS 5
+#define MAX_NB_GPIO_PER_BANK 32
+
+#define MAX_PINMUX_ENTRIES 200
+
+struct at91_pinctrl_priv {
+ struct at91_port *reg_base[MAX_GPIO_BANKS];
+ u32 nbanks;
+};
+
+#define PULL_UPBIT(0)
+#define MULTI_DRIVEBIT(1)
+#define DEGLITCH BIT(2)
+#define PULL_DOWN BIT(3)
+#define DIS_SCHMIT BIT(4)
+#define DRIVE_STRENGTH_SHIFT 5
+#define DRIVE_STRENGTH_MASK0x3
+#define DRIVE_STRENGTH (DRIVE_STRENGTH_MASK << DRIVE_STRENGTH_SHIFT)
+#define DEBOUNCE BIT(16)
+#define DEBOUNCE_VAL_SHIFT 17
+#define DEBOUNCE_VAL (0x3fff << DEBOUNCE_VAL_SHIFT)
+
+/**
+ * These defines will translated the dt binding settings to our internal
+ * settings. They are not necessarily the same value as the register setting.
+ * The actual drive strength current of low, medium and high must be looked up
+ * from the corresponding device datasheet. This value is different for pins
+ * that are even in the same banks. It is also dependent on VCC.
+ * DRIVE_STRENGTH_DEFAULT is just a placeholder to avoid changing the drive
+ * strength when there is no dt config for it.
+ */
+#define DRIVE_STRENGTH_DEFAULT (0 << DRIVE_STRENGTH_SHIFT)
+#define DRIVE_STRENGTH_LOW (1 << DRIVE_STRENGTH_SHIFT)
+#define DRIVE_STRENGTH_MED (2 << DRIVE_STRENGTH_SHIFT)
+#define DRIVE_STRENGTH_HI (3 << DRIVE_STRENGTH_SHIFT)
+
+enum at91_mux {
+ AT91_MUX_GPIO = 0,
+ AT91_MUX_PERIPH_A = 1,
+ AT91_MUX_PERIPH_B = 2,
+ AT91_MUX_PERIPH_C = 3,
+ AT91_MUX_PERIPH_D = 4,
+};
+
+/**
+ * struct at91_pinctrl_mux_ops - describes an AT91 mux ops group
+ * on new IP with support for periph C and D the way to mux in
+ * periph A and B has changed
+ * So provide the right callbacks
+ *
[U-Boot] [PATCH v1 1/2] gpio: at91_gpio: Remove CPU_HAS_PIO3 macro
The intention of this patch is the preparation to introduce
the pinctrl driver for AT91 PIO.
Use "union" to make the PIO3 and PIO2's registers be together
and make their offset aligned.
Signed-off-by: Wenyou Yang
---
arch/arm/mach-at91/include/mach/at91_pio.h | 61
arch/arm/mach-at91/include/mach/at91sam9x5.h| 1 -
arch/arm/mach-at91/include/mach/sama5d3.h | 1 -
arch/arm/mach-at91/include/mach/sama5d4.h | 1 -
board/atmel/sama5d3xek/sama5d3xek.c | 64 -
board/atmel/sama5d4_xplained/sama5d4_xplained.c | 148 ++--
board/atmel/sama5d4ek/sama5d4ek.c | 136 +-
board/denx/ma5d4evk/ma5d4evk.c | 178
board/l+g/vinco/vinco.c | 70 +-
drivers/gpio/at91_gpio.c| 142 +--
10 files changed, 427 insertions(+), 375 deletions(-)
diff --git a/arch/arm/mach-at91/include/mach/at91_pio.h
b/arch/arm/mach-at91/include/mach/at91_pio.h
index 3012278..393a163 100644
--- a/arch/arm/mach-at91/include/mach/at91_pio.h
+++ b/arch/arm/mach-at91/include/mach/at91_pio.h
@@ -63,28 +63,32 @@ typedef struct at91_port {
u32 puer; /* 0x64 Pull-up Enable Register */
u32 pusr; /* 0x68 Pad Pull-up Status Register */
u32 reserved4;
-#if defined(CPU_HAS_PIO3)
- u32 abcdsr1;/* 0x70 Peripheral ABCD Select Register 1 */
- u32 abcdsr2;/* 0x74 Peripheral ABCD Select Register 2 */
- u32 reserved5[2];
- u32 ifscdr; /* 0x80 Input Filter SCLK Disable Register */
- u32 ifscer; /* 0x84 Input Filter SCLK Enable Register */
- u32 ifscsr; /* 0x88 Input Filter SCLK Status Register */
- u32 scdr; /* 0x8C SCLK Divider Debouncing Register */
- u32 ppddr; /* 0x90 Pad Pull-down Disable Register */
- u32 ppder; /* 0x94 Pad Pull-down Enable Register */
- u32 ppdsr; /* 0x98 Pad Pull-down Status Register */
- u32 reserved6; /* */
-#else
- u32 asr;/* 0x70 Select A Register */
- u32 bsr;/* 0x74 Select B Register */
- u32 absr; /* 0x78 AB Select Status Register */
- u32 reserved5[9]; /* */
-#endif
+ union {
+ struct {
+ u32 abcdsr1;/* 0x70 Peripheral ABCD Select
Register 1 */
+ u32 abcdsr2;/* 0x74 Peripheral ABCD Select
Register 2 */
+ u32 reserved5[2];
+ u32 ifscdr; /* 0x80 Input Filter SCLK
Disable Register */
+ u32 ifscer; /* 0x84 Input Filter SCLK
Enable Register */
+ u32 ifscsr; /* 0x88 Input Filter SCLK
Status Register */
+ u32 scdr; /* 0x8C SCLK Divider Debouncing
Register */
+ u32 ppddr; /* 0x90 Pad Pull-down Disable
Register */
+ u32 ppder; /* 0x94 Pad Pull-down Enable
Register */
+ u32 ppdsr; /* 0x98 Pad Pull-down Status
Register */
+ u32 reserved6; /* */
+ } pio3;
+
+ struct {
+ u32 asr;/* 0x70 Select A Register */
+ u32 bsr;/* 0x74 Select B Register */
+ u32 absr; /* 0x78 AB Select Status
Register */
+ u32 reserved5[9]; /* */
+ } pio2;
+ } mux;
+
u32 ower; /* 0xA0 Output Write Enable Register */
u32 owdr; /* 0xA4 Output Write Disable Register */
u32 owsr; /* OxA8 Output Write Status Register */
-#if defined(CPU_HAS_PIO3)
u32 reserved7; /* */
u32 aimer; /* 0xB0 Additional INT Modes Enable Register */
u32 aimdr; /* 0xB4 Additional INT Modes Disable Register */
@@ -104,9 +108,6 @@ typedef struct at91_port {
u32 reserved11[5]; /* */
u32 schmitt;/* 0x100 Schmitt Trigger Register */
u32 reserved12[63];
-#else
- u32 reserved6[85];
-#endif
} at91_port_t;
typedef union at91_pio {
@@ -123,13 +124,6 @@ typedef union at91_pio {
#ifdef CONFIG_AT91_GPIO
int at91_set_a_periph(unsigned port, unsigned pin, int use_pullup);
int at91_set_b_periph(unsigned port, unsigned pin, int use_pullup);
-#if defined(CPU_HAS_PIO3)
-int at91_set_c_periph(unsigned port, unsigned pin, int use_pullup);
-int at91_set_d_periph(unsigned port, unsigned pin, int use_pullup);
-int at91_set_pio_debounce(unsigned port, unsigned pin, int is_on, int div);
-int at91_set_pio_pulldown(unsigned port, unsigned
[U-Boot] [PATCH v1 0/2] pinctrl: at91: Add pinctrl driver
The purpose of this patch set is to add the pinctrl driver for AT91 PIO controller. Wenyou Yang (2): gpio: at91_gpio: Remove CPU_HAS_PIO3 macro pinctrl: pinctrl-at91: Add pinctrl driver arch/arm/mach-at91/include/mach/at91_pio.h | 67 ++-- arch/arm/mach-at91/include/mach/at91sam9x5.h| 1 - arch/arm/mach-at91/include/mach/sama5d3.h | 1 - arch/arm/mach-at91/include/mach/sama5d4.h | 1 - board/atmel/sama5d3xek/sama5d3xek.c | 64 ++-- board/atmel/sama5d4_xplained/sama5d4_xplained.c | 148 board/atmel/sama5d4ek/sama5d4ek.c | 136 +++ board/denx/ma5d4evk/ma5d4evk.c | 178 +- board/l+g/vinco/vinco.c | 70 ++-- drivers/gpio/at91_gpio.c| 142 +--- drivers/pinctrl/Kconfig | 7 + drivers/pinctrl/Makefile| 1 + drivers/pinctrl/pinctrl-at91.c | 451 13 files changed, 891 insertions(+), 376 deletions(-) create mode 100644 drivers/pinctrl/pinctrl-at91.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PicoZed] Error in NET and SD Card
Hi On 10/11/2016 11:08 PM, Oscar Gomez Fuente wrote: > Hi everyone, > > I've just compiled u-boot for a picoZed platform with > the zynq_picozed_defconfig, and I've realised that the NET and SD Card > aren't recognised. In the init I see these messages: > > I boot from the SD Card and I see these messages from my uart terminal: > > - > U-Boot 2016.11-rc1-00139-gf5fd45f (Oct 11 2016 - 15:48:54 +0200) > > Model: Zynq PicoZed Board > Board: Xilinx Zynq > DRAM: ECC disabled 1 GiB > MMC: > Using default environment > > In:serial@e0001000 > Out: serial@e0001000 > Err: serial@e0001000 > Model: Zynq PicoZed Board > Board: Xilinx Zynq > Net: No ethernet found. > ** Bad device mmc 0 ** > Checking if uenvcmd is set ... > Hit any key to stop autoboot: 0 > - > > So, I think something has broken. Could anyone chek this issue? Could you enable the CONFIG_MMC_TRACE? then we can see more information. And which config do you use? Best Regards, Jaehoon Chung > > > Thank you very much. Best regards. > > Oscar Gomez Fuente > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] spi: ti_qspi: Fix baudrate divider calculation
Fix the divider calculation logic to choose a value so that the
resulting baudrate is either equal to or closest possible baudrate less
than the requested value.
Signed-off-by: Vignesh R
---
drivers/spi/ti_qspi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index 52520dff6325..d97e2479d1b3 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -118,7 +119,7 @@ static void ti_spi_set_speed(struct ti_qspi_priv *priv,
uint hz)
if (!hz)
clk_div = 0;
else
- clk_div = (priv->fclk / hz) - 1;
+ clk_div = DIV_ROUND_UP(priv->fclk, hz) - 1;
debug("ti_spi_set_speed: hz: %d, clock divider %d\n", hz, clk_div);
--
2.10.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: dts: dra7xx: Update spi-max-frequency for qspi slave node
Update the spi-max-frequency property of m25p80 flash slave to match
that of TI QSPI controller node, so that QSPI operations happen at
maximum supported frequency of 76.8MHz.
Signed-off-by: Vignesh R
---
arch/arm/dts/dra7-evm.dts | 2 +-
arch/arm/dts/dra72-evm-common.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/dra7-evm.dts b/arch/arm/dts/dra7-evm.dts
index fe755c05841d..be36d456206d 100644
--- a/arch/arm/dts/dra7-evm.dts
+++ b/arch/arm/dts/dra7-evm.dts
@@ -505,7 +505,7 @@
spi-max-frequency = <7680>;
m25p80@0 {
compatible = "s25fl256s1","spi-flash";
- spi-max-frequency = <6400>;
+ spi-max-frequency = <7680>;
reg = <0>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <4>;
diff --git a/arch/arm/dts/dra72-evm-common.dtsi
b/arch/arm/dts/dra72-evm-common.dtsi
index b0993e5bf7e0..1e1ca725577f 100644
--- a/arch/arm/dts/dra72-evm-common.dtsi
+++ b/arch/arm/dts/dra72-evm-common.dtsi
@@ -441,7 +441,7 @@
spi-max-frequency = <7680>;
m25p80@0 {
compatible = "s25fl256s1", "spi-flash";
- spi-max-frequency = <6400>;
+ spi-max-frequency = <7680>;
reg = <0>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <4>;
--
2.10.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.
On 10/11/2016 08:00 PM, Yao Yuan wrote: >> >> Yuan Yao, >> >> I think the procedure can be applied to many of our boards with QSPI, right? >> It >> may be better to move this information out of ls2080aqds. >> > > Hi York, > > Yes, but a little difference for "CCSR write" for different boards. > But the "CCSR write" should be wrote into uboot code or cw. > So, should I remove the notes for "CCSR write" and then move this > information for > all the boards which support QSPI boot? > I think you can put the common practice together with specific examples for LS2080A, and other SoCs. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/11] x86: Clean up unused macros in the configuration headers
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> Legacy video driver macros are not needed. Clean them up. >> >> Signed-off-by: Bin Meng >> >> --- >> >> include/configs/cougarcanyon2.h | 4 >> include/configs/efi-x86.h| 2 -- >> include/configs/galileo.h| 4 >> include/configs/x86-chromebook.h | 12 +++- >> include/configs/x86-common.h | 7 --- >> 5 files changed, 3 insertions(+), 26 deletions(-) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/11] x86: coreboot: Convert to use DM coreboot video driver
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> This converts coreboot to use DM framebuffer driver. >> >> Signed-off-by: Bin Meng >> --- >> >> arch/x86/cpu/coreboot/Kconfig | 4 >> arch/x86/dts/bayleybay.dts | 1 + >> arch/x86/dts/broadwell_som-6896.dts | 1 + >> arch/x86/dts/chromebook_link.dts| 1 + >> arch/x86/dts/chromebook_samus.dts | 1 + >> arch/x86/dts/chromebox_panther.dts | 1 + >> arch/x86/dts/coreboot_fb.dtsi | 5 + >> arch/x86/dts/minnowmax.dts | 1 + >> configs/coreboot-x86_defconfig | 2 ++ >> doc/README.x86 | 4 >> drivers/video/Makefile | 2 +- >> include/configs/som-6896.h | 6 +++--- >> 12 files changed, 21 insertions(+), 8 deletions(-) >> create mode 100644 arch/x86/dts/coreboot_fb.dtsi > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/11] video: Remove legacy VESA and coreboot framebuffer drivers
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> Now that all x86 boards have been converted to DM video, drop the >> legacy drivers. >> >> Signed-off-by: Bin Meng >> --- >> >> drivers/video/coreboot_fb.c | 108 >> >> drivers/video/vesa_fb.c | 63 -- >> 2 files changed, 171 deletions(-) >> delete mode 100644 drivers/video/coreboot_fb.c >> delete mode 100644 drivers/video/vesa_fb.c > > Reviewed-by: Simon Glass > > This is great! applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/11] dm: video: Don't do anything in alloc_fb() when plat->size is zero
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> With DM VESA driver on x86 boards, plat->base/size/align are all >> zeroes and starting address passed to alloc_fb() happens to be 1MB >> aligned, so this routine does not trigger any issue. On QEMU with >> U-Boot as coreboot payload, the starting address is within 1MB >> range (eg: 0x7fb), thus causes failure in video_post_bind(). >> >> Actually if plat->size is zero, it makes no sense to do anything >> in this routine. Add such check there. >> >> Signed-off-by: Bin Meng >> --- >> >> drivers/video/video-uclass.c | 3 +++ >> 1 file changed, 3 insertions(+) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] vbe: Make vbe_setup_video_priv() public
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> vbe_setup_video_priv() might be useful to other drivers. >> >> Signed-off-by: Bin Meng >> --- >> >> drivers/pci/pci_rom.c | 6 +++--- >> include/vbe.h | 4 >> 2 files changed, 7 insertions(+), 3 deletions(-) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/11] dm: video: Add driver for coreboot framebuffer device
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> This adds a DM driver for coreboot framebuffer device. >> >> Signed-off-by: Bin Meng >> --- >> >> drivers/video/Kconfig| 9 ++ >> drivers/video/coreboot.c | 79 >> >> 2 files changed, 88 insertions(+) >> create mode 100644 drivers/video/coreboot.c > > Reviewed-by: Simon Glass > > Nice! > > Nits below > Fixed nits and applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] x86: doc: Document coreboot framebuffer driver issue on QEMU
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> For some unknown reason, coreboot framebuffer driver never works on >> QEMU since day 1. It seems the driver only works on real hardware. >> Document this issue. >> >> Signed-off-by: Bin Meng >> --- >> >> doc/README.x86 | 3 +++ >> 1 file changed, 3 insertions(+) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/11] dm: video: Add driver for VESA compatible device
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> This adds a DM driver for VESA compatible device. > > nit: VESA-compatible Fixed nits, and > >> >> Signed-off-by: Bin Meng >> --- >> >> drivers/video/vesa.c | 34 ++ >> 1 file changed, 34 insertions(+) >> create mode 100644 drivers/video/vesa.c > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/11] x86: Convert to use DM VESA video driver
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> At present only chromebook boards are converted to DM video. Other >> x86 boards are still using the legacy cfb_console driver. This >> switches to use DM version drivers. >> >> Signed-off-by: Bin Meng >> --- >> >> configs/bayleybay_defconfig | 1 + >> configs/chromebox_panther_defconfig | 1 + >> configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 + >> configs/conga-qeval20-qa3-e3845_defconfig | 1 + >> configs/crownbay_defconfig | 1 + >> configs/dfi-bt700-q7x-151_defconfig | 1 + >> configs/minnowmax_defconfig | 1 + >> configs/qemu-x86_defconfig | 1 + >> configs/qemu-x86_efi_payload32_defconfig| 1 + >> configs/qemu-x86_efi_payload64_defconfig| 1 + >> configs/som-db5800-som-6867_defconfig | 1 + >> configs/theadorable-x86-dfi-bt700_defconfig | 1 + >> drivers/video/Makefile | 2 +- >> include/configs/bayleybay.h | 6 +++--- >> include/configs/crownbay.h | 4 ++-- >> include/configs/minnowmax.h | 6 +++--- >> include/configs/qemu-x86.h | 4 ++-- >> include/configs/som-db5800-som-6867.h | 6 +++--- >> 18 files changed, 26 insertions(+), 14 deletions(-) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] dm: video: Output verbose information in vbe_setup_video()
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> With DM conversion, information like "Video: 1024x768x16" is not >> shown anymore. Now add these verbose output back. >> >> Signed-off-by: Bin Meng >> --- >> >> drivers/pci/pci_rom.c | 9 - >> 1 file changed, 8 insertions(+), 1 deletion(-) > > Reviewed-by: Simon Glass > > Although at some point I'd prefer that this is printed by > board_init_r() somehow. applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] x86: doc: Correct qfw command example
On Wed, Oct 12, 2016 at 8:06 AM, Simon Glass wrote: > On 9 October 2016 at 05:14, Bin Meng wrote: >> The kernel load address for zboot should be 0x100. >> >> Signed-off-by: Bin Meng >> --- >> >> doc/README.x86 | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-x86
Hi Tom, The following changes since commit f5fd45ff64e28a73499548358e3d1ceda0de7daf: Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2016-10-08 09:33:37 -0400) are available in the git repository at: git://git.denx.de/u-boot-x86.git master for you to fetch changes up to 00bcaedd5c4063c677d16af264bbcb991fb9675c: x86: Clean up unused macros in the configuration headers (2016-10-12 10:58:24 +0800) Bin Meng (11): x86: doc: Document coreboot framebuffer driver issue on QEMU dm: video: Add driver for VESA-compatible device dm: video: Output verbose information in vbe_setup_video() x86: Convert to use DM VESA video driver x86: doc: Correct qfw command example vbe: Make vbe_setup_video_priv() public dm: video: Add driver for coreboot framebuffer device dm: video: Don't do anything in alloc_fb() when plat->size is zero x86: coreboot: Convert to use DM coreboot video driver video: Remove legacy VESA and coreboot framebuffer drivers x86: Clean up unused macros in the configuration headers Simon Glass (28): Revert "x86: broadwell: gpio: Remove the codes to set up pin control" x86: Add an accelerated memmove() function Fix return value in trailing_strtoln() list: Add list_last_entry() to find the last entry dm: core: Add a function to get a uclass name x86: video: Fix typo in broadwell Kconfig dm: stdio: Allow lazy probing of video devices dm: video: Add driver-model support to vesa graphics dm: x86: video: Add a driver-model driver for ivybridge graphics x86: Adjust config to support DM_VIDEO dm: x86: Move samus to use new driver model support dm: x86: Move link to use driver model for video Add _image_binary_end section declaration bios_emulator: Fix cast for 64-bit compilation board_f: Drop the extra fdtdec_prepare_fdt() elf: Add the Elf64_Rela type rtc: Use CONFIG_X86 instead of __I386__ tpm: Tidy up use of size_t usb: pci: Fix cast for 64-bit compilation x86: Allow interrupts to be disabled in 64-bit mode x86: Correct address casts in cpu code x86: Correct address casts in interrupt code x86: i2c: Fix cast of address to 32-bit value x86: Don't export interrupt handlers with x86_64 x86: ivybridge: Fix PCH power setup x86: ivybridge: Tidy up enable_clock_gating() for 64-bit x86: Drop unused init_helper functions x86: mrccache: Fix error handling in mrccache_get_region() Stefan Roese (3): x86: conga-qeval20-qa3: Add README to explain the console UART options x86: baytrail: Add 2nd eMMC controller to the PCI probe list x86: Fix Linux v4.7+ zimage booting (update bootparam.h) arch/x86/cpu/baytrail/valleyview.c| 5 ++-- arch/x86/cpu/broadwell/sdram.c| 1 - arch/x86/cpu/coreboot/Kconfig | 4 --- arch/x86/cpu/cpu.c| 10 +++ arch/x86/cpu/interrupts.c | 9 -- arch/x86/cpu/ivybridge/Makefile | 1 - arch/x86/cpu/ivybridge/bd82x6x.c | 12 arch/x86/cpu/ivybridge/early_me.c | 1 - arch/x86/cpu/ivybridge/gma.h | 156 -- arch/x86/cpu/ivybridge/lpc.c | 16 +-- arch/x86/cpu/ivybridge/model_206ax.c | 1 - arch/x86/cpu/ivybridge/sata.c | 1 - arch/x86/dts/bayleybay.dts| 1 + arch/x86/dts/broadwell_som-6896.dts | 1 + arch/x86/dts/chromebook_link.dts | 1 + arch/x86/dts/chromebook_samus.dts | 1 + arch/x86/dts/chromebox_panther.dts| 1 + arch/x86/dts/coreboot_fb.dtsi | 5 arch/x86/dts/minnowmax.dts| 1 + arch/x86/include/asm/arch-ivybridge/bd82x6x.h | 12 arch/x86/include/asm/bootparam.h | 3 ++ arch/x86/include/asm/cpu.h| 1 - arch/x86/include/asm/init_helpers.h | 2 -- arch/x86/include/asm/string.h | 2 +- arch/x86/lib/init_helpers.c | 10 --- arch/x86/lib/mrccache.c | 8 -- arch/x86/lib/string.c | 161 ++
[U-Boot] [PicoZed] Error in NET and SD Card
Hi everyone, I've just compiled u-boot for a picoZed platform with the zynq_picozed_defconfig, and I've realised that the NET and SD Card aren't recognised. In the init I see these messages: I boot from the SD Card and I see these messages from my uart terminal: - U-Boot 2016.11-rc1-00139-gf5fd45f (Oct 11 2016 - 15:48:54 +0200) Model: Zynq PicoZed Board Board: Xilinx Zynq DRAM: ECC disabled 1 GiB MMC: Using default environment In:serial@e0001000 Out: serial@e0001000 Err: serial@e0001000 Model: Zynq PicoZed Board Board: Xilinx Zynq Net: No ethernet found. ** Bad device mmc 0 ** Checking if uenvcmd is set ... Hit any key to stop autoboot: 0 - So, I think something has broken. Could anyone chek this issue? Thank you very much. Best regards. Oscar Gomez Fuente ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL load ARM Trusted Firmware BL31?
Hi all > -Original Message- > From: Masahiro Yamada [mailto:yamada.masah...@socionext.com] > Sent: 05 October 2016 04:19 > Hi. > > Recently I implemented ARM Trusted Firmware BL31 for my SoCs. > > But, I am wondering how the boot-flow should be. > I'm no U-Boot expert but as ARM Trusted Firmware (TF) maintainer, I feel I should say something here. In general we expect partners to take the bits of TF that work best for them. So all the bootflows discussed in this thread are valid as far as I'm concerned: Proprietary Boot ROM -> Proprietary firmware -> TF BL31 -> U-Boot -> Linux Proprietary Boot ROM -> U-Boot SPL -> TF BL31 -> Full U-Boot -> Linux TF BL1 -> TF BL2 -> TF BL31 -> U-Boot or UEFI (BL33) -> Linux We've gone to some effort to make TF as interoperable as possible with other boot firmware. If there's more we can do here, please let us know. As Michal said in an earlier mail, which bootflow you choose depends on what brings you the most value. Others have stated the advantages of U-Boot SPL over TF BL2, which I can't disagree with. But there may be other factors to consider, for example: * Interoperability with other boot firmware (e.g. UEFI) or other OS. * Integration with proprietary secure software (which permissively licensed software allows). * Alignment with ARM's Trusted Board Boot Requirements (TBBR) document. Each vendor needs to make their own decisions here. Regarding TF BL31, we'd prefer this to remain the EL3 Runtime Software on AArch64 platforms, because: * It is the deployment vehicle for ARM support code, which is constantly evolving (e.g. ARM architectural support, ARM CPU support, errata workarounds, plus other fundamental IP support). * It has upstream integration with various Trusted OS. * It helps standardization by providing reference code for PSCI and potentially other future industry standards. There may be other runtime resident firmware present, but we expect these to execute at a lower EL. One area that may be worth exploring is whether more can be done to help integration of the early TF secure world initialization code into other boot firmware (e.g. proprietary Boot ROMs or U-Boot SPL). This could be useful on platforms where TF BL1 is not used or TF BL31 is not the first software to execute on the CPU after reset. I hope that helps (and is not too controversial!). Regards Dan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/1] ARM:SUNXI: Update DRAM clock for Olimex A20 boards
Originally dram clock was set to 480MHz, but this behaves unstable. To improve stability the clock is reduced to 384MHz Signed-off-by: Stefan Mavrodiev --- configs/A20-OLinuXino-Lime2_defconfig | 2 +- configs/A20-OLinuXino-Lime_defconfig | 2 +- configs/A20-Olimex-SOM-EVB_defconfig | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configs/A20-OLinuXino-Lime2_defconfig b/configs/A20-OLinuXino-Lime2_defconfig index 5688622..4751fe0 100644 --- a/configs/A20-OLinuXino-Lime2_defconfig +++ b/configs/A20-OLinuXino-Lime2_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_MACH_SUN7I=y -CONFIG_DRAM_CLK=480 +CONFIG_DRAM_CLK=384 CONFIG_MMC0_CD_PIN="PH1" CONFIG_USB0_VBUS_PIN="PC17" CONFIG_USB0_VBUS_DET="PH5" diff --git a/configs/A20-OLinuXino-Lime_defconfig b/configs/A20-OLinuXino-Lime_defconfig index c4f6e1a..024dc2d 100644 --- a/configs/A20-OLinuXino-Lime_defconfig +++ b/configs/A20-OLinuXino-Lime_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_MACH_SUN7I=y -CONFIG_DRAM_CLK=480 +CONFIG_DRAM_CLK=384 CONFIG_MMC0_CD_PIN="PH1" CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set diff --git a/configs/A20-Olimex-SOM-EVB_defconfig b/configs/A20-Olimex-SOM-EVB_defconfig index 7a14a7b..3f4e90d 100644 --- a/configs/A20-Olimex-SOM-EVB_defconfig +++ b/configs/A20-Olimex-SOM-EVB_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_MACH_SUN7I=y -CONFIG_DRAM_CLK=480 +CONFIG_DRAM_CLK=384 CONFIG_MMC0_CD_PIN="PH1" CONFIG_MMC3_CD_PIN="PH0" CONFIG_MMC3_PINS="PH" -- 2.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd/nand.c: Remove unnecessarily repeated step
Getting the current NAND device is already done once as part
of nand command. Therefore, repeating this step as part of
the sub-commands is unnecessary.
Signed-off-by: Ahmed Samir Khalil
---
cmd/nand.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/cmd/nand.c b/cmd/nand.c
index ec7f1df..71ffe85 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -528,8 +528,6 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (set_dev(dev))
return 1;
- mtd = nand_info[dev];
-
memset(&opts, 0, sizeof(opts));
opts.offset = off;
opts.length = size;
@@ -597,8 +595,6 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (set_dev(dev))
return 1;
- mtd = nand_info[dev];
-
if (argc > 4 && !str2long(argv[4], &pagecount)) {
printf("'%s' is not a number\n", argv[4]);
return 1;
@@ -626,8 +622,6 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
rwsize = size;
}
- mtd = nand_info[dev];
-
if (!s || !strcmp(s, ".jffs2") ||
!strcmp(s, ".e") || !strcmp(s, ".i")) {
if (read)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd/nand.c: Debug additional helpful NAND info
While dealing with large chips (e.g. page: 4KB, OOB:224),
we found it helpful to get these additional NAND info by
enabling the DEBUG macro instead of full tracing every time
and consuming time. Especially about the currently in use
scheme for testing & development.
Signed-off-by: Ahmed Samir Khalil
---
cmd/nand.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/cmd/nand.c b/cmd/nand.c
index c16ec77..ec7f1df 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -283,6 +283,9 @@ usage:
static void nand_print_and_set_info(int idx)
{
+#ifdef DEBUG
+ unsigned int i;
+#endif
struct mtd_info *mtd = nand_info[idx];
struct nand_chip *chip = mtd_to_nand(mtd);
@@ -298,6 +301,29 @@ static void nand_print_and_set_info(int idx)
printf(" options 0x%8x\n", chip->options);
printf(" bbt options 0x%8x\n", chip->bbt_options);
+#ifdef DEBUG
+ printf(" Chip delay %7d us\n", chip->chip_delay);
+ printf(" ECC bytes %8d b\n", nand->ecclayout->eccbytes);
+ printf(" OOB available %6d b\n\n", nand->ecclayout->oobavail);
+
+ printf(" OOB free = {\n");
+ for (i=0; i < nand->ecclayout->oobfree[i].length; i++) {
+ if( !(nand->ecclayout->oobfree[i].offset<0) )
+ printf("{.offset=%d, ",
nand->ecclayout->oobfree[i].offset);
+
+ if( !(nand->ecclayout->oobfree[i].length<0) )
+ printf(".length=%d}, \n",
nand->ecclayout->oobfree[i].length);
+ }
+
+ printf(" };\n\n");
+ printf(" ECC positions = {\n");
+ for (i=0; i < MTD_MAX_ECCPOS_ENTRIES_LARGE; i++) {
+ if(nand->ecclayout->eccpos[i]>0)
+ printf("%d, ", nand->ecclayout->eccpos[i]);
+ }
+ printf("\n };\n\n");
+#endif
+
/* Set geometry info */
setenv_hex("nand_writesize", mtd->writesize);
setenv_hex("nand_oobsize", mtd->oobsize);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: LS1021a: enable i-cache in start.S
OK, thanks. Regards, Xiaoliang Yang -Original Message- From: york sun Sent: Sunday, October 09, 2016 1:16 AM To: Xiaoliang Yang; u-boot@lists.denx.de Subject: Re: [PATCH] armv7: LS1021a: enable i-cache in start.S On 09/13/2016 08:48 PM, Xiaoliang Yang wrote: > Delete CONFIG_SKIP_LOWLEVEL_INIT define in ls1021atwr.h and > ls1021aqds.h can let it run cpu_init_cp15 to enable i-cache. First > stage of u-boot can run faster after that. There is a description > about skip lowlevel init in board/freescale/ls1021atwr/README. > > Signed-off-by: Xiaoliang Yang > --- Applied to fsl-qoriq master, awaiting upstream. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 18/21] mtd: nand: Kconfig: Add NAND_MXS entry
On Sa, 2016-10-08 at 18:00 +0530, Jagan Teki wrote: > From: Jagan Teki > > Added kconfig for NAND_MXS driver. > > Cc: Scott Wood > Cc: Simon Glass > Cc: Fabio Estevam > Cc: Stefano Babic > Cc: Peng Fan > Cc: Matteo Lisi > Cc: Michael Trimarchi > Signed-off-by: Jagan Teki > --- > drivers/mtd/nand/Kconfig | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 5ce7d6d..df154bf 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -80,6 +80,13 @@ config NAND_ARASAN > controller. This uses the hardware ECC for read and > write operations. > > +config NAND_MXS > + bool "MXS NAND support" > + depends on MX6 Isn't mxs supposed to be i.MX23/i.MX28 and not i.MX6? > + help > + This enables NAND driver for the NAND flash controller on > the > + MXS processors. > + > comment "Generic NAND options" > > # Enhance depends when converting drivers to Kconfig which use this > config Best regards Jörg Krause ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: smsc95xx: fix DM MAC address reading
Hi Stephen,
On Mon, Oct 10, 2016 at 6:07 PM, Stephen Warren wrote:
> On 09/23/2016 11:43 AM, Joe Hershberger wrote:
>>
>> On Fri, Sep 23, 2016 at 11:31 AM, Stephen Warren
>> wrote:
>>>
>>> On 09/15/2016 01:20 PM, Joe Hershberger wrote:
On Thu, Sep 15, 2016 at 1:53 PM, Stephen Warren
wrote:
>
>
> From: Stephen Warren
>
> eth-uclass.c expects DM-capable Ethernet adapters to implement ops->
> read_rom_hwaddr(), or for some other mechanism to set pdata->enetaddr,
> or
> for the user to set environment variable $usbethaddr. Without any of
> these, it will refuse to initialize the device since no valid MAC
> address
> is known. Implement this function for the smsc95xx driver.
>
> With this feature implemented, there is no point smsc95xx_init_common()
> re-reading the MAC address from ROM, so ifdef out this code when DM_ETH
> is enabled.
>
> This allows (at least) the built-in Ethernet on the NVIDIA Harmony
> board
> to operate again.
>
> Fixes: 0990fcb77219 ("net: smsc95xx: Add driver-model support")
> Signed-off-by: Stephen Warren
Acked-by: Joe Hershberger
>>>
>>>
>>>
>>> Joe, was that ack just so you remember you've reviewed this when you come
>>> to
>>> applying patches later, or was it a signal to someone else that they
>>> should
>>> apply it?
>>
>>
>> No, I'll pull it in.
>
>
> Joe, I can't find this applied anywhere yet.
Sorry about that. I've got it and all other acked patches assigned to
me in a build test. Hopefully tomorrow I'll be able to send a pull
request, but it's a bit up in the since I've already seen some
warnings added by at least one of the patches. :/
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/11] x86: Clean up unused macros in the configuration headers
On 9 October 2016 at 05:14, Bin Meng wrote: > Legacy video driver macros are not needed. Clean them up. > > Signed-off-by: Bin Meng > > --- > > include/configs/cougarcanyon2.h | 4 > include/configs/efi-x86.h| 2 -- > include/configs/galileo.h| 4 > include/configs/x86-chromebook.h | 12 +++- > include/configs/x86-common.h | 7 --- > 5 files changed, 3 insertions(+), 26 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/11] video: Remove legacy VESA and coreboot framebuffer drivers
On 9 October 2016 at 05:14, Bin Meng wrote: > Now that all x86 boards have been converted to DM video, drop the > legacy drivers. > > Signed-off-by: Bin Meng > --- > > drivers/video/coreboot_fb.c | 108 > > drivers/video/vesa_fb.c | 63 -- > 2 files changed, 171 deletions(-) > delete mode 100644 drivers/video/coreboot_fb.c > delete mode 100644 drivers/video/vesa_fb.c Reviewed-by: Simon Glass This is great! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/11] x86: coreboot: Convert to use DM coreboot video driver
On 9 October 2016 at 05:14, Bin Meng wrote: > This converts coreboot to use DM framebuffer driver. > > Signed-off-by: Bin Meng > --- > > arch/x86/cpu/coreboot/Kconfig | 4 > arch/x86/dts/bayleybay.dts | 1 + > arch/x86/dts/broadwell_som-6896.dts | 1 + > arch/x86/dts/chromebook_link.dts| 1 + > arch/x86/dts/chromebook_samus.dts | 1 + > arch/x86/dts/chromebox_panther.dts | 1 + > arch/x86/dts/coreboot_fb.dtsi | 5 + > arch/x86/dts/minnowmax.dts | 1 + > configs/coreboot-x86_defconfig | 2 ++ > doc/README.x86 | 4 > drivers/video/Makefile | 2 +- > include/configs/som-6896.h | 6 +++--- > 12 files changed, 21 insertions(+), 8 deletions(-) > create mode 100644 arch/x86/dts/coreboot_fb.dtsi Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] vbe: Make vbe_setup_video_priv() public
On 9 October 2016 at 05:14, Bin Meng wrote: > vbe_setup_video_priv() might be useful to other drivers. > > Signed-off-by: Bin Meng > --- > > drivers/pci/pci_rom.c | 6 +++--- > include/vbe.h | 4 > 2 files changed, 7 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/11] dm: video: Don't do anything in alloc_fb() when plat->size is zero
On 9 October 2016 at 05:14, Bin Meng wrote: > With DM VESA driver on x86 boards, plat->base/size/align are all > zeroes and starting address passed to alloc_fb() happens to be 1MB > aligned, so this routine does not trigger any issue. On QEMU with > U-Boot as coreboot payload, the starting address is within 1MB > range (eg: 0x7fb), thus causes failure in video_post_bind(). > > Actually if plat->size is zero, it makes no sense to do anything > in this routine. Add such check there. > > Signed-off-by: Bin Meng > --- > > drivers/video/video-uclass.c | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/11] dm: video: Add driver for coreboot framebuffer device
On 9 October 2016 at 05:14, Bin Meng wrote:
> This adds a DM driver for coreboot framebuffer device.
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/video/Kconfig| 9 ++
> drivers/video/coreboot.c | 79
>
> 2 files changed, 88 insertions(+)
> create mode 100644 drivers/video/coreboot.c
Reviewed-by: Simon Glass
Nice!
Nits below
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index fd26690..554a03f 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -101,6 +101,15 @@ config VIDCONSOLE_AS_LCD
> to update the environment, the breakage may be confusing for users.
> This option will be removed around the end of 2016.
>
> +config VIDEO_COREBOOT
> + bool "Enable coreboot framebuffer driver support"
> + depends on X86 && SYS_COREBOOT
> + help
> + Turn on this option to enable a framebuffer driver when U-Boot is
> + loaded by coreboot where graphics device is configured by coreboot
where the graphics device
> + already. This can in principle be used with any platform that
> + coreboot supports.
> +
> config VIDEO_VESA
> bool "Enable VESA video driver support"
> default n
> diff --git a/drivers/video/coreboot.c b/drivers/video/coreboot.c
> new file mode 100644
> index 000..3a94aa1
> --- /dev/null
> +++ b/drivers/video/coreboot.c
> @@ -0,0 +1,79 @@
> +/*
> + * Copyright (C) 2016, Bin Meng
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int save_vesa_mode(struct cb_framebuffer *fb,
> + struct vesa_mode_info *vesa)
> +{
> + /*
> +* If there is no framebuffer structure, bail out and keep
> +* running on the serial console.
> +*/
> + if (!fb)
> + return -ENXIO;
> +
> + vesa->x_resolution = fb->x_resolution;
> + vesa->y_resolution = fb->y_resolution;
> + vesa->bits_per_pixel = fb->bits_per_pixel;
> + vesa->bytes_per_scanline = fb->bytes_per_line;
> + vesa->phys_base_ptr = fb->physical_address;
> + vesa->red_mask_size = fb->red_mask_size;
> + vesa->red_mask_pos = fb->red_mask_pos;
> + vesa->green_mask_size = fb->green_mask_size;
> + vesa->green_mask_pos = fb->green_mask_pos;
> + vesa->blue_mask_size = fb->blue_mask_size;
> + vesa->blue_mask_pos = fb->blue_mask_pos;
> + vesa->reserved_mask_size = fb->reserved_mask_size;
> + vesa->reserved_mask_pos = fb->reserved_mask_pos;
> +
> + return 0;
> +}
> +
> +static int coreboot_video_probe(struct udevice *dev)
> +{
> + struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
> + struct video_priv *uc_priv = dev_get_uclass_priv(dev);
> + struct cb_framebuffer *fb = lib_sysinfo.framebuffer;
> + struct vesa_mode_info *vesa = &mode_info.vesa;
> + int ret;
> +
> + printf("Video: ");
> +
> + /* Initialize vesa_mode_info structure */
> + ret = save_vesa_mode(fb, vesa);
> + if (ret)
> + goto err;
> +
> + ret = vbe_setup_video_priv(vesa, uc_priv, plat);
> + if (ret)
> + goto err;
> +
> + printf("%dx%dx%d\n", uc_priv->xsize, uc_priv->ysize,
> + vesa->bits_per_pixel);
Again at some point (later) it would be good to avoid printing info in drivers.
> +
> + return 0;
> +
> +err:
> + printf("No video mode configured in coreboot!\n");
> + return ret;
> +}
> +
> +static const struct udevice_id coreboot_video_ids[] = {
> + { .compatible = "coreboot-fb" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(coreboot_video) = {
> + .name = "coreboot_video",
> + .id = UCLASS_VIDEO,
> + .of_match = coreboot_video_ids,
> + .probe = coreboot_video_probe,
> +};
> --
> 2.9.2
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/11] x86: Convert to use DM VESA video driver
On 9 October 2016 at 05:14, Bin Meng wrote: > At present only chromebook boards are converted to DM video. Other > x86 boards are still using the legacy cfb_console driver. This > switches to use DM version drivers. > > Signed-off-by: Bin Meng > --- > > configs/bayleybay_defconfig | 1 + > configs/chromebox_panther_defconfig | 1 + > configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 + > configs/conga-qeval20-qa3-e3845_defconfig | 1 + > configs/crownbay_defconfig | 1 + > configs/dfi-bt700-q7x-151_defconfig | 1 + > configs/minnowmax_defconfig | 1 + > configs/qemu-x86_defconfig | 1 + > configs/qemu-x86_efi_payload32_defconfig| 1 + > configs/qemu-x86_efi_payload64_defconfig| 1 + > configs/som-db5800-som-6867_defconfig | 1 + > configs/theadorable-x86-dfi-bt700_defconfig | 1 + > drivers/video/Makefile | 2 +- > include/configs/bayleybay.h | 6 +++--- > include/configs/crownbay.h | 4 ++-- > include/configs/minnowmax.h | 6 +++--- > include/configs/qemu-x86.h | 4 ++-- > include/configs/som-db5800-som-6867.h | 6 +++--- > 18 files changed, 26 insertions(+), 14 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] x86: doc: Correct qfw command example
On 9 October 2016 at 05:14, Bin Meng wrote: > The kernel load address for zboot should be 0x100. > > Signed-off-by: Bin Meng > --- > > doc/README.x86 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] dm: video: Output verbose information in vbe_setup_video()
On 9 October 2016 at 05:14, Bin Meng wrote: > With DM conversion, information like "Video: 1024x768x16" is not > shown anymore. Now add these verbose output back. > > Signed-off-by: Bin Meng > --- > > drivers/pci/pci_rom.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass Although at some point I'd prefer that this is printed by board_init_r() somehow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/11] dm: video: Add driver for VESA compatible device
On 9 October 2016 at 05:14, Bin Meng wrote: > This adds a DM driver for VESA compatible device. nit: VESA-compatible > > Signed-off-by: Bin Meng > --- > > drivers/video/vesa.c | 34 ++ > 1 file changed, 34 insertions(+) > create mode 100644 drivers/video/vesa.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] x86: doc: Document coreboot framebuffer driver issue on QEMU
On 9 October 2016 at 05:14, Bin Meng wrote: > For some unknown reason, coreboot framebuffer driver never works on > QEMU since day 1. It seems the driver only works on real hardware. > Document this issue. > > Signed-off-by: Bin Meng > --- > > doc/README.x86 | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.
On 10/10/2016 11:04 PM, Yuan Yao wrote: > From: Yuan Yao > > Signed-off-by: Yuan Yao > --- > board/freescale/ls2080aqds/README | 35 +++ > 1 file changed, 35 insertions(+) > > diff --git a/board/freescale/ls2080aqds/README > b/board/freescale/ls2080aqds/README > index f288750..0f7446a 100644 > --- a/board/freescale/ls2080aqds/README > +++ b/board/freescale/ls2080aqds/README > @@ -188,3 +188,38 @@ DPMAC14 -> PHY4-P1 > DPMAC15 -> PHY4-P2 > DPMAC16 -> PHY4-P3 > > + > +Booting from QSPI > +--- > +Booting from QSPI requires two images, RCW and u-boot-dtb.bin. > +The difference between QSPI boot RCW image and NOR boot image is the PBI > +command sequence. Below is the setting for PBI commands for QDS which boot > +on QSPI flash device. > + > +1) CCSR 4-byte write to 0x00e00404, data=0x > +2) CCSR 4-byte write to 0x00e00400, data=0x2001 > +The above two commands set bootloc register to 0x_2001 where > +the u-boot code will be running in QSPI flash. > + > +RCW image should be written to the beginning of QSPI flash device. > +Example of using u-boot command > + > +=> sf probe 0:0 > +SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, > total 32 MiB > +=> sf erase 0 + > +SF: 65536 bytes @ 0x0 Erased: OK > +=> sf write 0 > +SF: 164 bytes @ 0x0 Written: OK > + > +To get the QSPI image, build u-boot with QSPI config, for example, > +ls2080aqds_qspi_defconfig. The image needed is u-boot-dtb.bin. > +The u-boot image should be written to 0x1. > + > +=> sf probe 0:0 > +SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, > total 32 MiB > +=> sf erase 1 + > +SF: 589824 bytes @ 0x1 Erased: OK > +=> sf write 1 > +SF: 580966 bytes @ 0x1 Written: OK > + > +With these two images in QSPI flash device, the board can boot from QSPI. > Yuan Yao, I think the procedure can be applied to many of our boards with QSPI, right? It may be better to move this information out of ls2080aqds. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] net: add driver for Synopsys Ethernet QoS device
On Tue, Oct 4, 2016 at 12:45 AM, Stephen Warren wrote:
> From: Stephen Warren
>
> This driver supports the Synopsys Designware Ethernet QoS (Quality of
> Service) a/k/a eqos IP block, which is a different design than the HW
> supported by the existing designware.c driver. The IP supports many
> options for bus type, clocking/reset structure, and feature list. This
> driver currently supports the specific configuration used in NVIDIA's
> Tegra186 chip, but should be extensible to other combinations quite
> easily, as explained in the source.
>
> Signed-off-by: Stephen Warren
> Reviewed-by: Simon Glass # V1
> ---
> v2:
> * Add note about x86 IO coherency.
> * Use wait_bit() where possible.
> * Use a struct definition of the RX and TX descriptors.
> ---
> drivers/net/Kconfig | 11 +
> drivers/net/Makefile |1 +
> drivers/net/dwc_eth_qos.c | 1497
> +
> 3 files changed, 1509 insertions(+)
> create mode 100644 drivers/net/dwc_eth_qos.c
>
snip...
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> new file mode 100644
> index ..f41aba97a494
> --- /dev/null
> +++ b/drivers/net/dwc_eth_qos.c
snip...
> +/*
> + * Warn if the cache-line size is larger than the descriptor size. In such
> + * cases the driver will likely fail because the CPU needs to flush the cache
> + * when requeuing RX buffers, therefore descriptors written by the hardware
> + * may be discarded. Architectures with full IO coherence, such as x86, do
> not
> + * experience this issue, and hence are excluded from this condition.
Great, thanks.
> + *
> + * This can be fixed by defining CONFIG_SYS_NONCACHED_MEMORY which will cause
> + * the driver to allocate descriptors from a pool of non-cached memory.
> + */
> +#if EQOS_DESCRIPTOR_SIZE < ARCH_DMA_MINALIGN
> +#if !defined(CONFIG_SYS_NONCACHED_MEMORY) && \
> + !defined(CONFIG_SYS_DCACHE_OFF) && !defined(CONFIG_X86)
> +#warning Cache line size is larger than descriptor size
> +#endif
> +#endif
> +
> +/*
> + * This represents the "Transmit Normal Descriptor (Read Format). The format
> + * written by HW is different, except for the OWN bit in the flags field.
> Field
"The format written by HW is different, except for the OWN bit in the
flags field."
This sentence is confusing. Different how? If it's written by HW,
isn't it read by driver? Hence it's this format? What is this "Read
Format" naming convention?
> + * naming assumes SW places uses single buffer per descriptor, rather than
> + * separate header/payload buffers, such that a single 64-bit pointer is
> used.
This sentence is also odd. Is this copied from a data sheet that was
processed through Google translate?
> + */
> +struct eqos_tx_desc {
> + u32 buf_lo;
> + u32 buf_hi;
> + u32 length;
> + u32 flags;
> +};
> +
> +/*
> + * This represents the "Receive Normal Descriptor (Read Format). The format
> + * written by HW is different, except for the OWN bit in the flags field.
> Field
> + * naming assumes SW places uses single buffer per descriptor, rather than
> + * separate header/payload buffers, such that a single 64-bit pointer is
> used.
> + */
> +struct eqos_rx_desc {
> + u32 buf_lo;
> + u32 buf_hi;
> + u32 unused;
> + u32 flags;
> +};
snip...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: add driver for Synopsys Ethernet QoS device
Hi Stephen, On Tue, Sep 27, 2016 at 12:02 AM, Stephen Warren wrote: > On 09/23/2016 03:49 PM, Joe Hershberger wrote: >> >> Hi Stephen, >> >> Thanks for sending this! I have some comments below. >> >> Cheers, >> -Joe >> >> On Mon, Sep 12, 2016 at 12:48 PM, Stephen Warren >> wrote: >>> >>> From: Stephen Warren >>> >>> This driver supports the Synopsys Designware Ethernet QoS (Quality of >>> Service) a/k/a eqos IP block, which is a different design than the HW >>> supported by the existing designware.c driver. The IP supports many >>> options for bus type, clocking/reset structure, and feature list. This >>> driver currently supports the specific configuration used in NVIDIA's >>> Tegra186 chip, but should be extensible to other combinations quite >>> easily, as explained in the source. > > >>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c > > >>> +/* Core registers */ >> >> >> Why are registers not defined as a struct? That is the common way that >> is accepted to represent registers in a driver. > > > It is common, but I find using structs has significant disadvantages, which > outweigh any advantages, so I strongly prefer not to use them. > > Disadvantages of structs: > > * Drivers often have to deal with different but similar HW variants. Similar > enough that it makes sense to use the same driver for them, but different > enough that certain registers are placed differently in the memory map. With > structs, there's little choice but to use ifdefs to pick a particular HW > variant and bake that into the driver. This doesn't work well for drivers > that must pick the variant at run-time rather than compile-time, e.g. > drivers for USB or PCIe devices, or when you wish to build a single SW image > that can run on multiple SoCs. Is that really the case here or are you just making a broad statement? Are registers really moving based on IP configuration? That sounds like broken IP / IP generator. > A common variant on this theme is device with different register layouts due > to IP integration issues, such as a UART with byte-wide registers that > appear at consecutive byte offsets in some SoCs, but at separate word > addresses in other SoCs. Again, this sounds like a generic argument that doesn't apply here. > This issue is relevant here since the EQoS block is a generic IP block with > many options that may have different SoC- or IP-version-specific differences > between SoCs. But simply additive, no? Included features add registers or bitfields. > * The register space for the EQoS driver is quite sparse, and U-Boot uses a > subset of the registers effectively making it even more sparse. Defining a > struct to describe this will be a frustrating exercise in calculating the > right amount of padding to place into the struct to get the correct offsets. > Mistakes will be made and it will be annoying. It's also organized into a few blocks. It's preferable to group registers into a struct that represents each block instead of one huge struct. It also hurts nothing to have registers defined in the struct that apply to configurations that may not be enabled in a given instance... the switching can be done at the spot where the register is accessed. And the accesses don't have to be compile-time options so you can have your built-in and your PCIe variants. > * Structs don't translate well to interactive debugging. It's common to > read/write registers using md/mw U-Boot shell commands. With structs, you > need to either (a) use some other data source for the register offsets, (b) > manually add up field sizes (c) write a comment indicating the offset next > to each field. (a) and (b) are both annoying, and by the time you've done > (c) (which is quite complicated in the face of ifdefs) you may as well have > simply used #defines in the first place. (a) is not so bad, but not ideal. I agree that (b) is annoying. I don't agree that you have to ifdef it, see above. I think (c) is a bit nicer than (a), but either are fine. I think the resulting code that is accessing the registers looks more concise and readable than a defined constant that is going to need to contain all of the context / scope in its name for disambiguation in the global namespace. A register name in a struct is scoped to that block and a local variable can be much shorter such that you don't have to keep repeating the same text throughout the function. >>> +/* >>> + * Warn if the cache-line size is larger than the descriptor size. In >>> such >>> + * cases the driver will likely fail because the CPU needs to flush the >>> cache >>> + * when requeuing RX buffers, therefore descriptors written by the >>> hardware >>> + * may be discarded. >>> + * >>> + * This can be fixed by defining CONFIG_SYS_NONCACHED_MEMORY which will >>> cause >>> + * the driver to allocate descriptors from a pool of non-cached memory. >>> + */ >>> +#if EQOS_DESCRIPTOR_SIZE < ARCH_DMA_MINALIGN >>> +#if !defined(CONFIG_SYS_NONCACHED_MEMORY) && \
Re: [U-Boot] [PATCH 2/2] net: add driver for Synopsys Ethernet QoS device
On Tue, Oct 4, 2016 at 12:13 AM, Stephen Warren wrote:
> On 09/23/2016 03:49 PM, Joe Hershberger wrote:
>>
>> Hi Stephen,
>>
>> Thanks for sending this! I have some comments below.
>>
>> Cheers,
>> -Joe
>>
>> On Mon, Sep 12, 2016 at 12:48 PM, Stephen Warren
>> wrote:
>>>
>>> From: Stephen Warren
>>>
>>> This driver supports the Synopsys Designware Ethernet QoS (Quality of
>>> Service) a/k/a eqos IP block, which is a different design than the HW
>>> supported by the existing designware.c driver. The IP supports many
>>> options for bus type, clocking/reset structure, and feature list. This
>>> driver currently supports the specific configuration used in NVIDIA's
>>> Tegra186 chip, but should be extensible to other combinations quite
>>> easily, as explained in the source.
>
>
>>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
>
>
>> +static int eqos_start(struct udevice *dev)
>
>
>>> + /* Update the MAC address */
>>> + val = (plat->enetaddr[5] << 8) |
>>> + (plat->enetaddr[4]);
>>> + writel(val, eqos->regs + EQOS_MAC_ADDRESS0_HIGH);
>>> + val = (plat->enetaddr[3] << 24) |
>>> + (plat->enetaddr[2] << 16) |
>>> + (plat->enetaddr[1] << 8) |
>>> + (plat->enetaddr[0]);
>>> + writel(val, eqos->regs + EQOS_MAC_ADDRESS0_LOW);
>>
>>
>> This should be implemented in write_hwaddr() op.
>
>
> That op is never called because this driver is only instantiated by device
> tree. Since this code can't be skipped, it can't be moved to that op.
I don't understand what you're saying here. That op is called in
eth_initialize() on every device found in device tree.
>>> +int eqos_send(struct udevice *dev, void *packet, int length)
>
>
>>> + for (i = 0; i < 100; i++) {
>>> + eqos_inval_desc(tx_desc);
>>> + if (!(readl(&tx_desc[3]) & EQOS_DESC3_OWN))
>>> + return 0;
>>
>>
>> Use wait_bit() here.
>
>
> That function won't work here due to the need to call
> eqos_inval_desc(tx_desc) inside the loop.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx6sabresd: Add README file
On Tue, Oct 11, 2016 at 3:15 PM, Otavio Salvador wrote: > On Tue, Oct 11, 2016 at 11:09 AM, Diego Dorta wrote: >> Add a README to explain the steps for booting mx6sabresd in different ways: >> 1. Booting via Normal U-Boot (u-boot.imx) >> 2. Booting via SPL (SPL and u-boot.img) >> 3. Booting via Falcon mode (SPL launches the kernel directly) >> >> Signed-off-by: Diego Dorta > > It is not clear if the SPL supports the QDL automatically or not. Also The README mentions that only mx6qsabresd and mx6qpsabresd are supported. > the Falcon mode uses network boot, why not documenting how to use it > from uSD? Network U-Boot? The README shows how to retrieve the SPL and u-boot.img via DHCP. There are many others possibilities such as retrieving them from SATA, USB stick, SPI NOR, etc. Retrieving from DHCP is just an example. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 18/21] mtd: nand: Kconfig: Add NAND_MXS entry
On Wed, 12 Oct 2016, Jörg Krause wrote: On Sa, 2016-10-08 at 18:00 +0530, Jagan Teki wrote: From: Jagan Teki Added kconfig for NAND_MXS driver. Cc: Scott Wood Cc: Simon Glass Cc: Fabio Estevam Cc: Stefano Babic Cc: Peng Fan Cc: Matteo Lisi Cc: Michael Trimarchi Signed-off-by: Jagan Teki --- drivers/mtd/nand/Kconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 5ce7d6d..df154bf 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -80,6 +80,13 @@ config NAND_ARASAN controller. This uses the hardware ECC for read and write operations. +config NAND_MXS + bool "MXS NAND support" + depends on MX6 Isn't mxs supposed to be i.MX23/i.MX28 and not i.MX6? i.MX6 has the same MXS NAND controller. --- ** * KSI@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx6sabresd: Add Falcon mode support
Hi Otavio, On Tue, Oct 11, 2016 at 3:16 PM, Otavio Salvador wrote: > I would prefer if it booted on falcon by default and vol-up could make > it load the U-Boot.img as a recovery option. In this case we would break existing SPL users of mx6sabresd. All of a sudden SPL will no longer boot, which is not a good user experience. Please keep in mind that mx6sabresd is a development board, not a final product, where Falcon mode would make more sense to be enabled by default. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] board: am335x: Always set eth/eth1addr environment variable
On Wed, Aug 24, 2016 at 2:35 PM, Roger Quadros wrote: > Ethernet ports might be used in the kernel even if CPSW driver > is disabled at u-boot. So always set ethaddr and eth1addr > environment variable from efuse. > > Retain usbnet_devaddr as it is required for SPL USB eth boot. > > Signed-off-by: Roger Quadros Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] board: am335x-icev2: add ethernet phy mode detection logic
On Wed, Aug 24, 2016 at 2:35 PM, Roger Quadros wrote: > Both ethernet ports can be used as CPSW ethernet (RMII mode) > or PRU ethernet (MII mode) by setting the jumper near the port. > Read the jumper value and set the pinmux, external mux and > PHY clock accordingly. > > As jumper line is overridden by PHY RX_DV pin immediately > after bootstrap (power-up/reset), we have to use GPIO edge > detection to capture the jumper line status. > > As u-boot doesn't provide any infrastructure for GPIO edge > detection, we directly access the GPIO registers. > > Signed-off-by: Roger Quadros Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8:ls1012a: Update bootargs for fast-boot
> > How much improvement do you get by using "quiet"? We see around 3-4 seconds being saved on ls1012 You didn't mention lpj > in the commit message. Did you get the number from kernel log? LS1012A is > a single core SoC. How much time do you save by setting lpj? Yes, we got the number from kernel log. I don't exactly remember how much but I think it was couple of 10's of milliseconds > > York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/5] net: fec_mxc: Convert into driver model
Hi Jagan, On 9 October 2016 at 08:51, Jagan Teki wrote: > > Hi Simon, > > On Thu, Oct 6, 2016 at 4:25 PM, Jagan Teki wrote: > > From: Jagan Teki > > > > This patch add driver model support for fec_mxc driver. > > > > Cc: Simon Glass > > Cc: Joe Hershberger > > Cc: Peng Fan > > Cc: Stefano Babic > > Cc: Michael Trimarchi > > Signed-off-by: Jagan Teki > > --- > > drivers/net/fec_mxc.c | 314 > > ++ > > drivers/net/fec_mxc.h | 4 + > > 2 files changed, 271 insertions(+), 47 deletions(-) > > > [...] > > This look OK now, let me know if you have any inputs. Is there a change log please? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] ARM: dts: imx6qdl-icore: Add FEC support
On Thu, Oct 6, 2016 at 12:55 PM, Jagan Teki wrote: > From: Jagan Teki > > Add FEC dts support for Engicam i.CoreM6 dql modules. > > Cc: Joe Hershberger > Cc: Stefano Babic > Cc: Matteo Lisi > Cc: Michael Trimarchi > Signed-off-by: Jagan Teki Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/5] net: fec_mxc: Driver cleanups
On Thu, Oct 6, 2016 at 12:55 PM, Jagan Teki wrote: > From: Jagan Teki > > - Remove exctra space > - Add space > - Add tab space > - Fix single line comments quotes > - Fix 'CHECK: Avoid CamelCase' > - Fix 'CHECK: Alignment should match open parenthesis' > - Fix 'WARNING: line over 80 characters' > - Re-arrage header include files > > Cc: Simon Glass > Cc: Joe Hershberger > Cc: Peng Fan > Cc: Stefano Babic > Cc: Michael Trimarchi > Signed-off-by: Jagan Teki Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/5] net: fec_mxc: Remove unneeded eth_device arg from fec_get_hwaddr
On Thu, Oct 6, 2016 at 12:55 PM, Jagan Teki wrote: > fec_get_hwaddr never used eth_device argument, hence removed. > > Cc: Simon Glass > Cc: Joe Hershberger > Cc: Peng Fan > Cc: Stefano Babic > Cc: Michael Trimarchi > Signed-off-by: Jagan Teki Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3] net: Fix cache misalignment message after network load operations
On Thu, Oct 6, 2016 at 2:14 AM, Tom Rini wrote: > On Wed, Sep 14, 2016 at 03:49:22AM +, Peter Chubb wrote: > >> After any operation that downloads a file (e.g., pxe get, or dhcp), the >> buffer containing the downloaded data is flushed. This is unnecessary >> and annoying. Unnecessary, because >> the network driver should already have fliushed the cache for the DMAed area, >> and annoying because it generates a cache misalignment message. >> >> Signed-off-by: Peter Chubb >> Acked-by: Heiko Schocher >> Acked-by: Joe Hershberger > > Reviewed-by: Tom Rini > > Joe, do you want to pick this up or should I? Thanks! I'll get it. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 5/5] icorem6: Use CONFIG_DM_ETH support
On Thu, Oct 6, 2016 at 12:55 PM, Jagan Teki wrote: > From: Jagan Teki > > Use CONFIG_DM_ETH and remove board_eth_init code > from board files. > > Cc: Joe Hershberger > Cc: Peng Fan > Cc: Stefano Babic > Cc: Michael Trimarchi > Signed-off-by: Jagan Teki Your SoB line should be first. Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/5] net: fec_mxc: Convert into driver model
On Thu, Oct 6, 2016 at 12:55 PM, Jagan Teki wrote:
> From: Jagan Teki
>
> This patch add driver model support for fec_mxc driver.
>
> Cc: Simon Glass
> Cc: Joe Hershberger
> Cc: Peng Fan
> Cc: Stefano Babic
> Cc: Michael Trimarchi
> Signed-off-by: Jagan Teki
> ---
> drivers/net/fec_mxc.c | 314
> ++
> drivers/net/fec_mxc.h | 4 +
> 2 files changed, 271 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index 0838d58..c0ec976 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -9,6 +9,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -368,11 +369,8 @@ static int fec_get_hwaddr(int dev_id, unsigned char *mac)
> return !is_valid_ethaddr(mac);
> }
>
> -static int fec_set_hwaddr(struct eth_device *dev)
> +static int _fec_set_hwaddr(struct fec_priv *fec, uchar *mac)
> {
> - uchar *mac = dev->enetaddr;
> - struct fec_priv *fec = (struct fec_priv *)dev->priv;
> -
> writel(0, &fec->eth->iaddr1);
> writel(0, &fec->eth->iaddr2);
> writel(0, &fec->eth->gaddr1);
> @@ -426,9 +424,8 @@ static void fec_reg_setup(struct fec_priv *fec)
> * Start the FEC engine
> * @param[in] dev Our device to handle
> */
> -static int fec_open(struct eth_device *edev)
> +static int fec_open(struct fec_priv *fec)
> {
> - struct fec_priv *fec = (struct fec_priv *)edev->priv;
> int speed;
> uint32_t addr, size;
> int i;
> @@ -534,14 +531,13 @@ static int fec_open(struct eth_device *edev)
> return 0;
> }
>
> -static int fec_init(struct eth_device *dev, bd_t* bd)
> +static int _fec_init(struct fec_priv *fec, uchar *mac)
> {
> - struct fec_priv *fec = (struct fec_priv *)dev->priv;
> uint32_t mib_ptr = (uint32_t)&fec->eth->rmon_t_drop;
> int i;
>
> /* Initialize MAC address */
> - fec_set_hwaddr(dev);
> + _fec_set_hwaddr(fec, mac);
>
> /*
> * Setup transmit descriptors, there are two in total.
> @@ -587,7 +583,7 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
> if (fec->xcv_type != SEVENWIRE)
> miiphy_restart_aneg(dev);
> #endif
> - fec_open(dev);
> + fec_open(fec);
> return 0;
> }
>
> @@ -595,9 +591,8 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
> * Halt the FEC engine
> * @param[in] dev Our device to handle
> */
> -static void fec_halt(struct eth_device *dev)
> +static void _fec_halt(struct fec_priv *fec)
> {
> - struct fec_priv *fec = (struct fec_priv *)dev->priv;
> int counter = 0x;
>
> /*
> @@ -637,7 +632,7 @@ static void fec_halt(struct eth_device *dev)
> * @param[in] length Data count in bytes
> * @return 0 on success
> */
> -static int fec_send(struct eth_device *dev, void *packet, int length)
> +static int _fec_send(struct fec_priv *fec, void *packet, int length)
> {
> unsigned int status;
> uint32_t size, end;
> @@ -649,8 +644,6 @@ static int fec_send(struct eth_device *dev, void *packet,
> int length)
> * This routine transmits one frame. This routine only accepts
> * 6-byte Ethernet addresses.
> */
> - struct fec_priv *fec = (struct fec_priv *)dev->priv;
> -
> /*
> * Check for valid length of data.
> */
> @@ -777,14 +770,14 @@ out:
> return ret;
> }
>
> +
> /**
> * Pull one frame from the card
> * @param[in] dev Our ethernet device to handle
> * @return Length of packet read
> */
> -static int fec_recv(struct eth_device *dev)
> +static int _fec_recv(struct fec_priv *fec, uchar *mac)
> {
> - struct fec_priv *fec = (struct fec_priv *)dev->priv;
> struct fec_bd *rbd = &fec->rbd_base[fec->rbd_index];
> unsigned long ievent;
> int frame_length, len = 0;
> @@ -800,8 +793,8 @@ static int fec_recv(struct eth_device *dev)
> writel(ievent, &fec->eth->ievent);
> debug("fec_recv: ievent 0x%lx\n", ievent);
> if (ievent & FEC_IEVENT_BABR) {
> - fec_halt(dev);
> - fec_init(dev, fec->bd);
> + _fec_halt(fec);
> + _fec_init(fec, mac);
> printf("some error: 0x%08lx\n", ievent);
> return 0;
> }
> @@ -813,10 +806,10 @@ static int fec_recv(struct eth_device *dev)
> if (ievent & FEC_IEVENT_GRA) {
> /* Graceful stop complete */
> if (readl(&fec->eth->x_cntrl) & 0x0001) {
> - fec_halt(dev);
> + _fec_halt(fec);
> writel(~0x0001 & readl(&fec->eth->x_cntrl),
> &fec->eth->x_cntrl);
> - fec_init(dev, fec->bd);
> + _fec_init(fec, mac);
> }
> }
>
> @@ -970,6 +963,71 @@ static void fec_free_descs(
[U-Boot] Please pull u-boot-fdt
Hi Tom, This is mostly syncing up with upstream. I have a few more things to do also (some small, some large). The following changes since commit f5fd45ff64e28a73499548358e3d1ceda0de7daf: Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2016-10-08 09:33:37 -0400) are available in the git repository at: git://git.denx.de/u-boot-fdt.git for you to fetch changes up to 7f899e436fe1e952950a14df92600d68d55dea5c: libfdt: Drop inlining of fdt_path_offset() (2016-10-11 14:26:46 -0600) David Gibson (1): libfdt: Fix undefined behaviour in fdt_offset_ptr() Hannes Schmelzer (1): cmd/fdt: add possibilty to have 'extrasize' on fdt resize Simon Glass (4): libfdt: Sync up with upstream libfdt: Bring in upstream stringlist functions libfdt: Sync fdt_for_each_subnode() with upstream libfdt: Drop inlining of fdt_path_offset() arch/arm/mach-tegra/xusb-padctl-common.c | 18 +- arch/arm/mach-uniphier/board_late_init.c | 5 ++- arch/x86/cpu/irq.c | 5 +-- board/compulab/cm_fx6/cm_fx6.c | 2 +- cmd/fdt.c| 9 +++-- common/fdt_support.c | 3 +- common/image-fdt.c | 2 +- common/image-fit.c | 21 +-- common/image-sig.c | 8 ++--- common/image.c | 19 +- drivers/clk/clk-uclass.c | 6 ++-- drivers/core/device.c| 2 +- drivers/gpio/dwapb_gpio.c| 3 +- drivers/i2c/mxc_i2c.c| 2 +- drivers/mailbox/mailbox-uclass.c | 6 ++-- drivers/net/cpsw.c | 2 +- drivers/net/keystone_net.c | 4 +-- drivers/net/mvpp2.c | 2 +- drivers/net/sun8i_emac.c | 5 +-- drivers/pci/pci_tegra.c | 2 +- drivers/phy/marvell/comphy_core.c| 2 +- drivers/pinctrl/exynos/pinctrl-exynos.c | 9 +++-- drivers/pinctrl/meson/pinctrl-meson.c| 4 +-- drivers/pinctrl/pinctrl-generic.c| 10 +++--- drivers/pinctrl/pinctrl-uclass.c | 2 +- drivers/reset/reset-uclass.c | 6 ++-- drivers/spi/fsl_qspi.c | 2 +- drivers/video/sunxi_display.c| 2 +- include/fdt_support.h| 10 +- include/libfdt.h | 187 +--- - lib/fdtdec.c | 4 +-- lib/libfdt/fdt.c | 13 +++ lib/libfdt/fdt_overlay.c | 8 ++--- lib/libfdt/fdt_ro.c | 119 ++ lib/libfdt/fdt_rw.c | 4 ++- lib/libfdt/fdt_wip.c | 6 ++-- test/overlay/cmd_ut_overlay.c| 5 ++- 37 files changed, 298 insertions(+), 221 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] driver: net: cpsw: add support for RGMII id mode support and RMII clock source selection
On Mon, Oct 10, 2016 at 2:57 PM, Mugunthan V N wrote: > cpsw driver supports only selection of phy mode in control module > but control module has more setting like RGMII ID mode selection, > RMII clock source selection. So ported to cpsw-phy-sel driver > from kernel to u-boot. > > Signed-off-by: Mugunthan V N Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] include: configs: am335x: add Atheros phy support
On Mon, Oct 10, 2016 at 2:57 PM, Mugunthan V N wrote: > In AM335x GP EVM, Atheros 8031 phy is used, enable the driver as > AM335x SoC RGMII delay mode has to be enabled in phy as mentioned > in the silicon errata Advisory 1.0.10 > > Signed-off-by: Mugunthan V N Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] drivers: net: phy: atheros: add separate config for AR8031
On Mon, Oct 10, 2016 at 2:57 PM, Mugunthan V N wrote: > In the current driver implementation, config() callback is common > for AR8035 and AR8031 phy. In config() callback, driver tries to > configure MMD Access Control Register and MMD Access Address Data > Register unconditionally for both phy versions which leads to > auto negotiation failure in AM335x EVMsk second port which uses > AR8031 Giga bit RGMII phy. Fixing this by adding separate config > for AR8031 phy. > > Reviewed-by: Sekhar Nori > Signed-off-by: Mugunthan V N Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] ARM: sun71: dts: add support for Bananapi BPI-R1
Okay, but I could use a little clarity; do you want the u-boot dts to
look just like my (proposed) kernel dts? Or do I start with kernel
dts and remove the gmac/axp209 stuff?
If we can merge all of this feedback into a single list of changes,
then I can take a whack at it later this week (after a few work
things). Back to the test mtg...
Thanks in advance, Steve
On Mon, Oct 10, 2016 at 3:34 AM, Jagan Teki wrote:
> On Mon, Oct 10, 2016 at 2:34 AM, Stephen Arnold
> wrote:
>> From: Steve Arnold
>>
>> * changes from lamobo-r1 required include:
>> - unset ahci power pin
>> - usbvbus gpio pin change
>> - mmc cd gpio pin change
>> - enable uart2, set default LED trigger
>> - CONFIG_GMAC_TX_DELAY change
>>
>> Changes for v2:
>> - incorprated feedback for config options (remove 3, add 1)
>> Changes for v3/v4:
>> - re-submit (no change to patch payload) with cover
>> Changes for v5:
>> - re-submit as one patch (no change to patch payload)
>>
>> Signed-off-by: Steve Arnold
>> Cc: Ian Campbell
>> Cc: Hans De Goede
>>
>> arch/arm/dts/Makefile | 1 +
>> arch/arm/dts/sun7i-a20-bananapi-r1.dts | 376
>> +
>> configs/Bananapi_R1_defconfig | 16 ++
>> 3 files changed, 393 insertions(+)
>> create mode 100644 arch/arm/dts/sun7i-a20-bananapi-r1.dts
>> create mode 100644 configs/Bananapi_R1_defconfig
>>
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index 8458f6b..8aa8646 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -217,6 +217,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>> sun7i-a20-ainol-aw1.dtb \
>> sun7i-a20-bananapi.dtb \
>> sun7i-a20-bananapi-m1-plus.dtb \
>> + sun7i-a20-bananapi-r1.dtb \
>> sun7i-a20-bananapro.dtb \
>> sun7i-a20-cubieboard2.dtb \
>> sun7i-a20-cubietruck.dtb \
>> diff --git a/arch/arm/dts/sun7i-a20-bananapi-r1.dts
>> b/arch/arm/dts/sun7i-a20-bananapi-r1.dts
>> new file mode 100644
>> index 000..1a550f9
>> --- /dev/null
>> +++ b/arch/arm/dts/sun7i-a20-bananapi-r1.dts
>> @@ -0,0 +1,376 @@
>> +/*
>> + * Copyright 2015 Hans de Goede
>> + * Changes copyright 2016 Stephen Arnold
>
> Remove "Changes" text and add your copy on top, it some how look take
> reference from Hans.
>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun7i-a20.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +/ {
>> + model = "Banana Pi BPI-R1";
>> + compatible = "sinovoip,bpi-r1", "allwinner,sun7i-a20";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + serial1 = &uart2;
>> + serial2 = &uart3;
>> + serial3 = &uart7;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> +
Re: [U-Boot] [PATCH 1/2] mx6sabresd: Add Falcon mode support
On Tue, Oct 11, 2016 at 11:09 AM, Diego Dorta wrote:
> Allow i.MX6Q Sabre SD to load the kernel and dtb via SPL in Falcon mode.
>
> Based on the Falcon mode code for MX6 Gateworks Ventana board.
>
> Signed-off-by: Diego Dorta
> ---
> board/freescale/mx6sabresd/mx6sabresd.c | 12
> include/configs/mx6sabresd.h| 12
> 2 files changed, 24 insertions(+)
>
> diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
> b/board/freescale/mx6sabresd/mx6sabresd.c
> index e58c03c..2b6d7be 100644
> --- a/board/freescale/mx6sabresd/mx6sabresd.c
> +++ b/board/freescale/mx6sabresd/mx6sabresd.c
> @@ -57,6 +57,8 @@ DECLARE_GLOBAL_DATA_PTR;
>
> #define DISP0_PWR_EN IMX_GPIO_NR(1, 21)
>
> +#define KEY_VOL_UP IMX_GPIO_NR(1, 4)
> +
> int dram_init(void)
> {
> gd->ram_size = imx_ddr_size();
> @@ -682,6 +684,16 @@ int checkboard(void)
> #include
> #include
>
> +#ifdef CONFIG_SPL_OS_BOOT
> +int spl_start_uboot(void)
> +{
> + gpio_direction_input(KEY_VOL_UP);
> +
> + /* Only enter in Falcon mode if KEY_VOL_UP is pressed */
> + return gpio_get_value(KEY_VOL_UP);
I would prefer if it booted on falcon by default and vol-up could make
it load the U-Boot.img as a recovery option.
> +}
> +#endif
> +
> static void ccgr_init(void)
> {
> struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
> index 5c2734d..6a7a0d3 100644
> --- a/include/configs/mx6sabresd.h
> +++ b/include/configs/mx6sabresd.h
> @@ -11,6 +11,7 @@
>
> #ifdef CONFIG_SPL
> #include "imx6_spl.h"
> +#undef CONFIG_SPL_EXT_SUPPORT
> #endif
>
> #define CONFIG_MACH_TYPE 3980
> @@ -22,6 +23,17 @@
>
> #include "mx6sabre_common.h"
>
> +/* Falcon Mode */
> +#define CONFIG_CMD_SPL
> +#define CONFIG_SPL_OS_BOOT
> +#define CONFIG_SYS_SPL_ARGS_ADDR 0x1800
> +#define CONFIG_CMD_SPL_WRITE_SIZE (128 * SZ_1K)
> +
> +/* Falcon Mode - MMC support: args@1MB kernel@2MB */
> +#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR 0x800 /* 1MB */
> +#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS (CONFIG_CMD_SPL_WRITE_SIZE /
> 512)
> +#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR0x1000 /* 2MB */
> +
> #define CONFIG_SYS_FSL_USDHC_NUM 3
> #if defined(CONFIG_ENV_IS_IN_MMC)
> #define CONFIG_SYS_MMC_ENV_DEV 1 /* SDHC3 */
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx6sabresd: Add README file
On Tue, Oct 11, 2016 at 11:09 AM, Diego Dorta wrote: > Add a README to explain the steps for booting mx6sabresd in different ways: > 1. Booting via Normal U-Boot (u-boot.imx) > 2. Booting via SPL (SPL and u-boot.img) > 3. Booting via Falcon mode (SPL launches the kernel directly) > > Signed-off-by: Diego Dorta It is not clear if the SPL supports the QDL automatically or not. Also the Falcon mode uses network boot, why not documenting how to use it from uSD? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx6sabresd: Add README file
Add a README to explain the steps for booting mx6sabresd in different ways:
1. Booting via Normal U-Boot (u-boot.imx)
2. Booting via SPL (SPL and u-boot.img)
3. Booting via Falcon mode (SPL launches the kernel directly)
Signed-off-by: Diego Dorta
---
board/freescale/mx6sabresd/README | 103 ++
1 file changed, 103 insertions(+)
create mode 100644 board/freescale/mx6sabresd/README
diff --git a/board/freescale/mx6sabresd/README
b/board/freescale/mx6sabresd/README
new file mode 100644
index 000..5814b9d
--- /dev/null
+++ b/board/freescale/mx6sabresd/README
@@ -0,0 +1,103 @@
+How to use and build U-Boot on mx6sabresd:
+--
+
+Currently there are three methods for booting mx6sabresd boards:
+
+1. Booting via Normal U-Boot (u-boot.imx)
+
+2. Booting via SPL (SPL and u-boot.img)
+
+3. Booting via Falcon mode (SPL launches the kernel directly)
+
+
+1. Booting via Normal U-Boot
+
+
+$ make mx6qsabresd_defconfig (If you want to build for mx6qsabresd)
+
+or
+
+$ make mx6dlsabresd_defconfig (If you want to build for mx6dlsabresd)
+
+$ make
+
+This will generate the image called u-boot.imx.
+
+- Flash the u-boot.imx binary into the SD card:
+
+$ sudo dd if=u-boot.imx of=/dev/sdb bs=1K seek=1 && sync
+
+
+2. Booting via SPL
+--
+
+Other method for building U-Boot on mx6qsabresd and mx6qpsabresd is
+through SPL. In order to do so:
+
+$ make mx6sabresd_spl_defconfig
+$ make
+
+This will generate the SPL image called SPL and the u-boot.img.
+
+- Flash the SPL image into the SD card:
+
+$ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 && sync
+
+- Flash the u-boot.img image into the SD card:
+
+$ sudo dd if=u-boot.img of=/dev/sdbbs=1K seek=69 && sync
+
+
+3. Booting via Falcon mode
+--
+
+$ make mx6sabresd_spl_defconfig
+$ make
+
+This will generate the SPL image called SPL and the u-boot.img.
+
+- Flash the SPL image into the SD card:
+
+$ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 oflag=sync status=none && sync
+
+- Flash the u-boot.img image into the SD card:
+
+$ sudo dd if=u-boot.img of=/dev/sdbbs=1K seek=69 oflag=sync status=none && sync
+
+Create a partition for root file system and extract it there:
+
+$ sudo tar xvf rootfs.tar.gz -C /media/root
+
+The SD card must have enough space for raw "args" and "kernel".
+To configure Falcon mode for the first time, on U-Boot do the following
commands:
+
+- Setup the IP server:
+
+# setenv serverip
+
+- Download dtb file:
+
+# dhcp ${fdt_addr} imx6q-sabresd.dtb
+
+- Download kernel image:
+
+# dhcp ${loadaddr} uImage
+
+- Write kernel at 2MB offset:
+
+# mmc write ${loadaddr} 0x1000 0x4000
+
+- Setup kernel bootargs:
+
+# setenv bootargs "console=ttymxc0,115200 root=/dev/mmcblk1p1 rootfstype=ext4
rootwait quiet rw"
+
+- Prepare args:
+
+# spl export fdt ${loadaddr} - ${fdt_addr}
+
+- Write args 1MB data (0x800 sectors) to 1MB offset (0x800 sectors)
+
+# mmc write 1800 0x800 0x800
+
+- Press KEY_VOL_UP key, power up the board and then SPL binary will
+launch the kernel directly.
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ti: common: board_detect: Return a valid empty string for un-initialized eeprom
Current logic for query of revision, board_name, config returns
NULL. Users of these functions do a direct strncmp to compare.
Unfortunately, as per conventions require two valid strings to compare
against and the current implementation causes a crash when compared
with NULL.
We'd still like to maintain the simplistic usage of these APIs instead
of redundant if (string) res=strncmp(fn(),"cmp",n); flowing all over
the place.
Hence, since the version, name and config is already pre-initialized
with empty string, just dont check for invalid header in the first
place and return the empty string to the caller.
Reported-by: Brad Griffis
Signed-off-by: Nishanth Menon
---
board/ti/common/board_detect.c | 12 +++-
board/ti/common/board_detect.h | 6 +++---
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index 13aac2f03037..6e7ca9196d22 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -231,9 +231,7 @@ char * __maybe_unused board_ti_get_rev(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
- if (ep->header == TI_DEAD_EEPROM_MAGIC)
- return NULL;
-
+ /* if ep->header == TI_DEAD_EEPROM_MAGIC, this is empty already */
return ep->version;
}
@@ -241,9 +239,7 @@ char * __maybe_unused board_ti_get_config(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
- if (ep->header == TI_DEAD_EEPROM_MAGIC)
- return NULL;
-
+ /* if ep->header == TI_DEAD_EEPROM_MAGIC, this is empty already */
return ep->config;
}
@@ -251,9 +247,7 @@ char * __maybe_unused board_ti_get_name(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
- if (ep->header == TI_DEAD_EEPROM_MAGIC)
- return NULL;
-
+ /* if ep->header == TI_DEAD_EEPROM_MAGIC, this is empty already */
return ep->name;
}
diff --git a/board/ti/common/board_detect.h b/board/ti/common/board_detect.h
index eb17f6f52a12..2ded3ed7764b 100644
--- a/board/ti/common/board_detect.h
+++ b/board/ti/common/board_detect.h
@@ -141,7 +141,7 @@ bool board_ti_rev_is(char *rev_tag, int cmp_len);
/**
* board_ti_get_rev() - Get board revision for TI EVMs
*
- * Return: NULL if eeprom was'nt read.
+ * Return: Empty string if eeprom was'nt read.
*Board revision otherwise
*/
char *board_ti_get_rev(void);
@@ -149,7 +149,7 @@ char *board_ti_get_rev(void);
/**
* board_ti_get_config() - Get board config for TI EVMs
*
- * Return: NULL if eeprom was'nt read.
+ * Return: Empty string if eeprom was'nt read.
*Board config otherwise
*/
char *board_ti_get_config(void);
@@ -157,7 +157,7 @@ char *board_ti_get_config(void);
/**
* board_ti_get_name() - Get board name for TI EVMs
*
- * Return: NULL if eeprom was'nt read.
+ * Return: Empty string if eeprom was'nt read.
*Board name otherwise
*/
char *board_ti_get_name(void);
--
2.10.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ti: common: board_detect: Setup initial default value for config as well
config should have been initialized along with others as defaults. Signed-off-by: Nishanth Menon --- board/ti/common/board_detect.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c index 7c552d20656a..13aac2f03037 100644 --- a/board/ti/common/board_detect.c +++ b/board/ti/common/board_detect.c @@ -131,6 +131,7 @@ int __maybe_unused ti_i2c_eeprom_am_get(int bus_addr, int dev_addr) ep->name[0] = 0x0; ep->version[0] = 0x0; ep->serial[0] = 0x0; + ep->config[0] = 0x0; rc = ti_i2c_eeprom_get(bus_addr, dev_addr, TI_EEPROM_HEADER_MAGIC, sizeof(am_ep), (uint8_t *)&am_ep); @@ -175,6 +176,7 @@ int __maybe_unused ti_i2c_eeprom_dra7_get(int bus_addr, int dev_addr) ep->name[0] = 0x0; ep->version[0] = 0x0; ep->serial[0] = 0x0; + ep->config[0] = 0x0; ep->emif1_size = 0; ep->emif2_size = 0; -- 2.10.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ti: common: board_detect: Replace hardcoded value with macro
We should have used TI_DEAD_EEPROM_MAGIC in the first place.
Fixes: d3b98a9eb941 ("ti: common: dra7: Add standard access for board
description EEPROM")
Signed-off-by: Nishanth Menon
---
board/ti/common/board_detect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index e0ae1a51a6a4..7c552d20656a 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -171,7 +171,7 @@ int __maybe_unused ti_i2c_eeprom_dra7_get(int bus_addr, int
dev_addr)
goto already_read;
/* Initialize with a known bad marker for i2c fails.. */
- ep->header = 0xADEAD12C;
+ ep->header = TI_DEAD_EEPROM_MAGIC;
ep->name[0] = 0x0;
ep->version[0] = 0x0;
ep->serial[0] = 0x0;
--
2.10.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] ti: common: board_detect: basic fixes for blank eeprom
In some cases where eeprom has not been programmed, Brad reported issues of crash at strcmp against NULL, this series was triggered thanks to issue in manufacturing flow where the mandatory eeprom programming was missed. Nishanth Menon (3): ti: common: board_detect: Replace hardcoded value with macro ti: common: board_detect: Setup initial default value for config as well ti: common: board_detect: Return a valid empty string for un-initialized eeprom board/ti/common/board_detect.c | 16 ++-- board/ti/common/board_detect.h | 6 +++--- 2 files changed, 9 insertions(+), 13 deletions(-) -- 2.10.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-dm
Hi Tom, This includes lp873x PMIC support, moving patman to work with Python 3 (mostly), buildman improvements, cros_ec flashinfo support and sandbox filesystem test fixes. It also includes the MMC patches I've been holding off for months. I still worry that it might cause problems with some boards, but we should find out quickly once this is in. The following changes since commit f5fd45ff64e28a73499548358e3d1ceda0de7daf: Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2016-10-08 09:33:37 -0400) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to bfeba0173aa45c24bbdba45149716c83258d25f6: cmd: cros_ec: Move crosec commands to cmd subdirectory (2016-10-11 10:17:08 -0600) Keerthy (9): power: regulator: Add support for gpio regulators power: regulator: Add ctrl_reg and volt_reg fields for pmic power: pmic: Palmas: Add the base pmic support power: regulator: palmas: Add regulator support configs: dra7xx_evm_defconfig: Enable PALMAS options configs: am57xx_evm_defconfig: Enable PALMAS options configs: am57xx_evm_defconfig: Enable CMD_REG option power: pmic: lp873x: Add the base pmic support power: regulator: lp873x: Add regulator support Moritz Fischer (4): cros_ec: Add function to read back flash parameters cros_ec: Add crosec flashinfo command cros_ec: Fix issue with cros_ec_flash_write command cmd: cros_ec: Move crosec commands to cmd subdirectory Paul Burton (9): patman: Replace tabs with spaces patman: Make print statements python 3.x safe patman: Make exception handling python 3.x safe patman: Import 'configparser' lower case to be python 3.x safe patman: Use items() to iterate over dictionaries patman: Fix doctest StringIO import for python 3.x dtoc: Use items() to iterate over dictionaries in python 3.x dtoc: Decode strings for struct.unpack on python 3.x dtoc: Make integer division python 3.x safe Simon Glass (16): patman: Flush output when there is no newline buildman: Tidy up the 'cloning' message buildman: Print a message when removing old directories buildman: Print a message indicating the build is starting buildman: Put our local libraries first in the path buildman: Allow builds to terminate cleanly buildman: Drop the 'active' flag in the builder buildman: Don't show a stacktrace on Ctrl-C buildman: Drop the 'alive' flag in BuilderThread dtoc: Fix bug in GetProp() dtoc: Adjust GetProps() in fdt_normal to use the node path dtoc: Add a way for tests to request the fallback library dm: mmc: Support erase dm: blk: Enable CONFIG_BLK if DM_MMC is enabled dm: mmc: Enable DM_MMC_OPS by default with DM_MMC sandbox: Use the address in readl/writel() functions Stefan Brüns (5): sandbox/fs: Free memory allocated by os_dirent_ls sandbox/fs: Make linking of nodes in os_dirent_ls more obvious sandbox/fs: Use correct size path name buffer sandbox/fs: Use readdir instead of deprecated readdir_r sandbox/fs: Set correct filetype for unknown filetype York Sun (2): tools: buildman: Remove duplicated code tools: buildman: Add compiler wrapper arch/sandbox/cpu/os.c | 34 +--- arch/sandbox/include/asm/io.h | 12 +-- cmd/Kconfig| 13 +++ cmd/Makefile | 1 + cmd/cros_ec.c | 365 configs/am335x_boneblack_vboot_defconfig | 2 + configs/am335x_evm_defconfig | 2 + configs/am43xx_evm_defconfig | 2 + configs/am43xx_evm_usbhost_boot_defconfig | 2 + configs/am43xx_hs_evm_defconfig| 2 + configs/am57xx_evm_defconfig | 7 ++ configs/am57xx_hs_evm_defconfig| 2 + configs/apalis_t30_defconfig | 2 + configs/beaver_defconfig | 2 + configs/cardhu_defconfig | 2 + configs/cei-tk1-som_defconfig | 2 + configs/colibri_t20_defconfig | 2 + configs/colibri_t30_defconfig | 2 + configs/dalmore_defconfig | 2 + configs/dra7xx_evm_defconfig | 5 ++ configs/dra7xx_hs_evm_defconfig| 2 + configs/e2220-1170_defconfig | 2 + configs/harmony_defconfig | 2 + configs/jetson-tk1_defconfig | 2 + configs/k2g_evm_defconfig | 2 + configs/medcom-wide_defconfig | 2 + configs/mx6ull_14x14_evk_defconfig | 4 +- configs/nyan-big_defconfig | 2 + configs/p2371-_defconfig | 2 +
[U-Boot] [PATCH 1/2] mx6sabresd: Add Falcon mode support
Allow i.MX6Q Sabre SD to load the kernel and dtb via SPL in Falcon mode.
Based on the Falcon mode code for MX6 Gateworks Ventana board.
Signed-off-by: Diego Dorta
---
board/freescale/mx6sabresd/mx6sabresd.c | 12
include/configs/mx6sabresd.h| 12
2 files changed, 24 insertions(+)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index e58c03c..2b6d7be 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -57,6 +57,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define DISP0_PWR_EN IMX_GPIO_NR(1, 21)
+#define KEY_VOL_UP IMX_GPIO_NR(1, 4)
+
int dram_init(void)
{
gd->ram_size = imx_ddr_size();
@@ -682,6 +684,16 @@ int checkboard(void)
#include
#include
+#ifdef CONFIG_SPL_OS_BOOT
+int spl_start_uboot(void)
+{
+ gpio_direction_input(KEY_VOL_UP);
+
+ /* Only enter in Falcon mode if KEY_VOL_UP is pressed */
+ return gpio_get_value(KEY_VOL_UP);
+}
+#endif
+
static void ccgr_init(void)
{
struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
index 5c2734d..6a7a0d3 100644
--- a/include/configs/mx6sabresd.h
+++ b/include/configs/mx6sabresd.h
@@ -11,6 +11,7 @@
#ifdef CONFIG_SPL
#include "imx6_spl.h"
+#undef CONFIG_SPL_EXT_SUPPORT
#endif
#define CONFIG_MACH_TYPE 3980
@@ -22,6 +23,17 @@
#include "mx6sabre_common.h"
+/* Falcon Mode */
+#define CONFIG_CMD_SPL
+#define CONFIG_SPL_OS_BOOT
+#define CONFIG_SYS_SPL_ARGS_ADDR 0x1800
+#define CONFIG_CMD_SPL_WRITE_SIZE (128 * SZ_1K)
+
+/* Falcon Mode - MMC support: args@1MB kernel@2MB */
+#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR 0x800 /* 1MB */
+#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS (CONFIG_CMD_SPL_WRITE_SIZE /
512)
+#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR0x1000 /* 2MB */
+
#define CONFIG_SYS_FSL_USDHC_NUM 3
#if defined(CONFIG_ENV_IS_IN_MMC)
#define CONFIG_SYS_MMC_ENV_DEV 1 /* SDHC3 */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx6sabresd: Add README file
On Tue, Oct 11, 2016 at 11:09 AM, Diego Dorta wrote: > Add a README to explain the steps for booting mx6sabresd in different ways: > 1. Booting via Normal U-Boot (u-boot.imx) > 2. Booting via SPL (SPL and u-boot.img) > 3. Booting via Falcon mode (SPL launches the kernel directly) > > Signed-off-by: Diego Dorta Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx6sabresd: Add Falcon mode support
On Tue, Oct 11, 2016 at 11:09 AM, Diego Dorta wrote: > Allow i.MX6Q Sabre SD to load the kernel and dtb via SPL in Falcon mode. > > Based on the Falcon mode code for MX6 Gateworks Ventana board. > > Signed-off-by: Diego Dorta Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] pci: layerscape: rewrite pci driver based on DM
Hi Bin, Thanks for your suggestion. Please see my comments inline. Thanks, Minghuan > -Original Message- > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: Monday, October 10, 2016 7:49 PM > To: M.H. Lian ; Simon Glass > Cc: U-Boot Mailing List ; Mingkai Hu > ; Leo Li > Subject: Re: [U-Boot] [PATCH 8/9] pci: layerscape: rewrite pci driver based on > DM > > Hi Minghuan, > > On Mon, Oct 10, 2016 at 4:47 PM, Minghuan Lian > wrote: > > There are more than five kinds of Layerscape SoCs. unfortunately, PCIe > > controller of each SoC is a little bit different. In order to avoid > > too many macro definitions, the patch re-implement PCIe driver based > > on DM. PCIe dts node is to describe the difference. > > > > Signed-off-by: Minghuan Lian > > --- > > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 8 - > > drivers/pci/Kconfig| 8 + > > drivers/pci/pcie_layerscape.c | 958 > > +++-- > > include/configs/ls1012a_common.h | 12 + > > include/configs/ls1012aqds.h | 24 - > > include/configs/ls1012ardb.h | 24 - > > include/configs/ls1021aqds.h | 18 +- > > include/configs/ls1021atwr.h | 18 +- > > include/configs/ls1043a_common.h | 23 +- > > include/configs/ls2080a_common.h | 27 +- > > include/configs/ls2080aqds.h | 8 - > > include/configs/ls2080ardb.h | 8 - > > These header file changes should not be put in the same commit of the > layerscape PCIe driver conversion. They should be in a separate commit. So > you are likely to have 3 commits: firstly add DM codes with #ifdef > CONFIG_DM_PCI #endif in the layerscape PCIe driver, without breaking the > existing board support. 2nd commit to update the boards configuration files > (defconfig and the header), and 3rd commit to remove the #ifdef > CONFIG_DM_PCI #endif, only leaving the DM version codes. [Minghuan Lian] Your suggestion is excellent. I will change the patch. For the header and defconfig files, do I need to separate them to several patches for different SoC? I mean a patch is for ls1012, a patch is for ls1043 ... > > > 12 files changed, 526 insertions(+), 610 deletions(-) > > > > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h > > b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h > > index 7acba27..bd07808 100644 > > --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h > > +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h > > @@ -104,14 +104,6 @@ > > #define CONFIG_SYS_PCIE2_PHYS_ADDR 0x12ULL > > #define CONFIG_SYS_PCIE3_PHYS_ADDR 0x14ULL > > #define CONFIG_SYS_PCIE4_PHYS_ADDR 0x16ULL > > -/* LUT registers */ > > -#define PCIE_LUT_BASE 0x8 > > -#define PCIE_LUT_LCTRL00x7F8 > > -#define PCIE_LUT_DBG 0x7FC > > -#define PCIE_LUT_UDR(n) (0x800 + (n) * 8) > > -#define PCIE_LUT_LDR(n) (0x804 + (n) * 8) > > -#define PCIE_LUT_ENABLE (1 << 31) > > -#define PCIE_LUT_ENTRY_COUNT32 > > > > [snip] > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller in pci_bus_to_hose()
Hi Bin, Please see my comments inline. Thanks, Minghuan > -Original Message- > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: Tuesday, October 11, 2016 3:43 PM > To: M.H. Lian > Cc: Simon Glass ; U-Boot Mailing List b...@lists.denx.de>; Mingkai Hu ; Leo Li > > Subject: Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller in > pci_bus_to_hose() > > Hi Minghuan, > > On Tue, Oct 11, 2016 at 3:12 PM, M.H. Lian wrote: > > Hi Bin, > > > > With the patches our Layerscape PCIe driver has been fully based on DM. > > Ethernet driver E1000 needs to define "CONFIG_DM_ETH" to use PCIe DM > API instead of legacy PCI API. > > But our other Ethernet driver FM(drivers/net/fm/eth.c) is still not support > DM. So we cannot define "CONFIG_DM_ETH" > > For LS1021a ethernet, please pick up this patch to see if it works: > http://patchwork.ozlabs.org/patch/566347/ [Minghuan Lian] fm.c is used by ls1043 and ls1046. So if this patch is merged, I may remove " CONFIG_DM_PCI_COMPAT " On LS1021a. > > > Well, we must define "CONFIG_DM_PCI_COMPAT" to support e1000 and > fm at the same time. > > After FM driver is changed to support DM, we can define > "CONFIG_DM_ETH" and remove "CONFIG_DM_PCI_COMPAT " > > > > But the current DM driver has an issue. > > > > 1. > > pci_bus_to_hose(int busnum) defined in driver/pci/pci_compat.c is > > to return the hose associated current busnum(PCIe device) instead of > > PCIe controller (RC) > > > > pci_bus_to_hose(int bus) defined in driver/pci/pci.c for legacy PCI driver > > is > to return the hose pointed to the PCIe controller(RC). > > > > My first patch is to keep consistency and return the hose pointer of the > PCIe controller. > > - return dev_get_uclass_priv(bus); > > + return dev_get_uclass_priv(pci_get_controller(bus)); > > > > 2 > > In pci/pci_common.c phys_addr_t pci_hose_bus_to_phys() > > > > #ifdef CONFIG_DM_PCI > >/* The root controller has the region information */ > >hose = pci_bus_to_hose(0); > > #endif > > > > Is always to return hose of the bus0. > > > > But our SoC has more than one PCIe controllers(RC). > > > > For example: > > PCI0 bus 0 -- e1000#0 bus1 > > PCI1 bus 2 -- e1000#1 bus3. > > I got it. But this does not look that good to me. There are two controllers, > and > bus number should be relative to the controller itself, not system wide. It's > definitely right to assign bus number 0 to both PCIe host controllers, as they > forward the bus number on their own bus link. I am wondering we should > add a controller number to the PCI command, like the storage device > command. The first parameter is the controller number, while the second > parameter is the bus number. [Minghuan Lian] Yes. Linux uses "PCI domain" to isolate PCIe controllers. And config "CONFIG_PCI_DOMAINS" is to enable domain like controllers number. But, under Linux if disable "CONFIG_PCI_DOMAINS ", all PCIe controllers will be assigned continuous bus Number like the current uboot. > > > > > PCI1 is the second PCIe controller (RC) has different PCIe space to PCI0. > > For E1000#1, we want to get the host pointed to PCI1 bus2 not bus0. > > > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] build error with CONFIG_DM_PCI disabled in menuconfig
> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Tuesday, October 11, 2016 11:44 AM
> To: Ding, ChiX
> Cc: Simon Glass ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] build error with CONFIG_DM_PCI disabled in menuconfig
>
> Hi Chi,
>
> On Tue, Oct 11, 2016 at 6:01 PM, Ding, ChiX wrote:
> > Hi Bin
> > Thanks for the reply. I'm working on Intel Denvernton Board. As you
> > suggested I'm debugging it using DM PCI now. In the device tree file,
> > I define PCI as this, but I don't know what is missing so that AHCI isn't
> > probed
> > pci {
> > compatible = "pci-x86";
> > #address-cells = <3>;
> > #size-cells = <2>;
> > u-boot,dm-pre-reloc;
> > };
> >
> > In coreboot.h, I define
> > #define CONFIG_SCSI_AHCI
> > #define CONFIG_SCSI
> >
> > #ifdef CONFIG_SCSI_AHCI
> > #define CONFIG_LIBATA
> > #define CONFIG_SYS_64BIT_LBA
> > #define CONFIG_SCSI_DEV_LIST{PCI_VENDOR_ID_INTEL, \
> > 0x19b2}, \
> > {PCI_VENDOR_ID_INTEL, \
> > 0x19c2}
> >
> > U-Boot dm tree command shows pci isn't probed.
> > => dm tree
> > Class Probed Name
> >
> > root[ + ]root_driver
> > keyboard[ + ]|-- keyboard
> > serial [ + ]|-- serial
> > rtc [ ]|-- rtc
> > timer [ + ]|-- tsc-timer
> > pci [ ]`-- pci
> >
> >
> >
> > => dm uclass
> > uclass 0: root
> > - * root_driver @ 7f4e9040, seq 0, (req -1)
> >
> > uclass 9: simple_bus
> > uclass 11: ahci
> > uclass 12: blk
> > uclass 14: cpu
> > uclass 19: gpio
> > uclass 24: irq
> > uclass 25: keyboard
> > - * keyboard @ 7f4e90c8, seq 0, (req -1)
> >
> > uclass 27: lpc
> > uclass 34: northbridge
> > uclass 37: pch
> > uclass 38: pci
> > - pci @ 7f4e92c0
> >
> > uclass 39: pci_generic
> > uclass 50: rtc
> > - rtc @ 7f4e91d0
> >
> > uclass 51: serial
> > - * serial @ 7f4e9140, seq 0, (req -1)
> >
> > uclass 52: spi
> > uclass 54: spi_flash
> > uclass 55: spi_generic
> > uclass 56: syscon
> > uclass 59: timer
> > - * tsc-timer @ 7f4e9248, seq 0, (req -1)
> >
> > uclass 60: tpm
> >
> >
> > Thanks a lot,
> > Chi
>
> Please do not top-posting.
>
> The reason is that PCI is not probed so that AHCI driver is not probed too.
> Can
> you please run pci command from U-Boot shell?
>
> Regards,
> Bin
Hi Bin
Sorry that outlook does top-posting by default. I just changed it.
I ran "pci" command from U-Boot shell and it says no such bus.
=> pci
No such bus
Thanks,
Chi
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller in pci_bus_to_hose()
Hi Bin, I noticed Sandbox architecture has added PCI menu to the arch/sandbox/Kconfig Could I move this PCI menu to the driver/pci/kconfig? So I could add all PCI related config to defconfig files. Please see my comments inline. Thanks, Minghuan > -Original Message- > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: Tuesday, October 11, 2016 6:35 PM > To: M.H. Lian > Cc: Simon Glass ; U-Boot Mailing List b...@lists.denx.de>; Mingkai Hu ; Leo Li > > Subject: Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller in > pci_bus_to_hose() > > Hi Minghuan, > > On Tue, Oct 11, 2016 at 5:36 PM, M.H. Lian wrote: > > Hi Bin, > > > > Please see my comments inline. > > > > Thanks, > > Minghuan > > > >> -Original Message- > >> From: Bin Meng [mailto:bmeng...@gmail.com] > >> Sent: Tuesday, October 11, 2016 3:43 PM > >> To: M.H. Lian > >> Cc: Simon Glass ; U-Boot Mailing List >> b...@lists.denx.de>; Mingkai Hu ; Leo Li > >> > >> Subject: Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller > >> in > >> pci_bus_to_hose() > >> > >> Hi Minghuan, > >> > >> On Tue, Oct 11, 2016 at 3:12 PM, M.H. Lian > wrote: > >> > Hi Bin, > >> > > >> > With the patches our Layerscape PCIe driver has been fully based on > DM. > >> > Ethernet driver E1000 needs to define "CONFIG_DM_ETH" to use PCIe > >> > DM > >> API instead of legacy PCI API. > >> > But our other Ethernet driver FM(drivers/net/fm/eth.c) is still not > >> > support > >> DM. So we cannot define "CONFIG_DM_ETH" > >> > >> For LS1021a ethernet, please pick up this patch to see if it works: > >> http://patchwork.ozlabs.org/patch/566347/ > > [Minghuan Lian] fm.c is used by ls1043 and ls1046. So if this patch is > > merged, > I may remove " CONFIG_DM_PCI_COMPAT " > > On LS1021a. > >> > > Yep, I think so. > > >> > Well, we must define "CONFIG_DM_PCI_COMPAT" to support e1000 > and > >> fm at the same time. > >> > After FM driver is changed to support DM, we can define > >> "CONFIG_DM_ETH" and remove "CONFIG_DM_PCI_COMPAT " > >> > > >> > But the current DM driver has an issue. > >> > > >> > 1. > >> > pci_bus_to_hose(int busnum) defined in driver/pci/pci_compat.c > >> > is to return the hose associated current busnum(PCIe device) > >> > instead of PCIe controller (RC) > >> > > >> > pci_bus_to_hose(int bus) defined in driver/pci/pci.c for legacy PCI > >> > driver is > >> to return the hose pointed to the PCIe controller(RC). > >> > > >> > My first patch is to keep consistency and return the hose pointer > >> > of the > >> PCIe controller. > >> > - return dev_get_uclass_priv(bus); > >> > + return dev_get_uclass_priv(pci_get_controller(bus)); > >> > > >> > 2 > >> > In pci/pci_common.c phys_addr_t pci_hose_bus_to_phys() > >> > > >> > #ifdef CONFIG_DM_PCI > >> >/* The root controller has the region information */ > >> >hose = pci_bus_to_hose(0); > >> > #endif > >> > > >> > Is always to return hose of the bus0. > >> > > >> > But our SoC has more than one PCIe controllers(RC). > >> > > >> > For example: > >> > PCI0 bus 0 -- e1000#0 bus1 > >> > PCI1 bus 2 -- e1000#1 bus3. > >> > >> I got it. But this does not look that good to me. There are two > >> controllers, and bus number should be relative to the controller > >> itself, not system wide. It's definitely right to assign bus number 0 > >> to both PCIe host controllers, as they forward the bus number on > >> their own bus link. I am wondering we should add a controller number > >> to the PCI command, like the storage device command. The first > >> parameter is the controller number, while the second parameter is the > bus number. > > [Minghuan Lian] Yes. Linux uses "PCI domain" to isolate PCIe controllers. > > And config "CONFIG_PCI_DOMAINS" is to enable domain like controllers > number. > > But, under Linux if disable "CONFIG_PCI_DOMAINS ", all PCIe > > controllers will be assigned continuous bus Number like the current uboot. > > > > Yep, I guess you will need introduce CONFIG_PCI_DOMAINS to U-Boot DM > PCI codes. > [Minghuan Lian] For Linux, "DOMAINS" is an option, not a must. And we need to change many PCIe code carefully to compatible with all PCIe driver. It will take plenty of time. And there are still very pressing jobs on hand. So I will add this to my todo list. > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] dm: pci: remove pci_bus_to_hose(0) calling
Hi Bin, Please see my comments inline. Thanks, Minghuan > -Original Message- > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: Monday, October 10, 2016 7:55 PM > To: M.H. Lian ; Simon Glass > Cc: U-Boot Mailing List ; Mingkai Hu > ; Leo Li > Subject: Re: [U-Boot] [PATCH 2/9] dm: pci: remove pci_bus_to_hose(0) > calling > > +Simon > > Hi Minghuan, > > On Mon, Oct 10, 2016 at 4:47 PM, Minghuan Lian > wrote: > > There may be multiple PCIe controllers in a SoC. > > It is not correct that always calling pci_bus_to_hose(0) to get the > > first PCIe controller for the PCIe device connected other controllers. > > We just remove this calling because hose always point the correct PCIe > > controller. > > > > Signed-off-by: Minghuan Lian > > --- > > drivers/pci/pci_common.c | 10 -- > > 1 file changed, 10 deletions(-) > > > > diff --git a/drivers/pci/pci_common.c b/drivers/pci/pci_common.c index > > 1755914..448e814 100644 > > --- a/drivers/pci/pci_common.c > > +++ b/drivers/pci/pci_common.c > > @@ -181,11 +181,6 @@ phys_addr_t pci_hose_bus_to_phys(struct > pci_controller *hose, > > return phys_addr; > > } > > > > -#ifdef CONFIG_DM_PCI > > - /* The root controller has the region information */ > > - hose = pci_bus_to_hose(0); > > -#endif > > Again if you fully convert the driver to use DM PCI, this API won't be called. > And what's broken here? The comment says "The root controller has the > region information", which is correct. [Minghuan Lian] Our SoCs have multiple PCIe controllers - RCs. Each PCIe controller has different region information. Only the first PCIe controller is assigned to bus number 0. The second/third PCIe controllers may be assigned bus number 2 / 3. pci_bus_to_hose(0) is only correct for the first PCIe controller. > > > - > > /* > > * if PCI_REGION_MEM is set we do a two pass search with preference > > * on matches that don't have PCI_REGION_SYS_MEMORY set @@ > > -248,11 +243,6 @@ pci_addr_t pci_hose_phys_to_bus(struct pci_controller > *hose, > > return bus_addr; > > } > > > > -#ifdef CONFIG_DM_PCI > > - /* The root controller has the region information */ > > - hose = pci_bus_to_hose(0); > > -#endif > > - > > /* > > * if PCI_REGION_MEM is set we do a two pass search with preference > > * on matches that don't have PCI_REGION_SYS_MEMORY set > > -- > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] build error with CONFIG_DM_PCI disabled in menuconfig
Hi Chi,
On Tue, Oct 11, 2016 at 6:01 PM, Ding, ChiX wrote:
> Hi Bin
> Thanks for the reply. I'm working on Intel Denvernton Board. As you
> suggested I'm debugging it
> using DM PCI now. In the device tree file, I define PCI as this, but I don't
> know what is missing so
> that AHCI isn't probed
> pci {
> compatible = "pci-x86";
> #address-cells = <3>;
> #size-cells = <2>;
> u-boot,dm-pre-reloc;
> };
>
> In coreboot.h, I define
> #define CONFIG_SCSI_AHCI
> #define CONFIG_SCSI
>
> #ifdef CONFIG_SCSI_AHCI
> #define CONFIG_LIBATA
> #define CONFIG_SYS_64BIT_LBA
> #define CONFIG_SCSI_DEV_LIST{PCI_VENDOR_ID_INTEL, \
> 0x19b2}, \
> {PCI_VENDOR_ID_INTEL, \
> 0x19c2}
>
> U-Boot dm tree command shows pci isn't probed.
> => dm tree
> Class Probed Name
>
> root[ + ]root_driver
> keyboard[ + ]|-- keyboard
> serial [ + ]|-- serial
> rtc [ ]|-- rtc
> timer [ + ]|-- tsc-timer
> pci [ ]`-- pci
>
>
>
> => dm uclass
> uclass 0: root
> - * root_driver @ 7f4e9040, seq 0, (req -1)
>
> uclass 9: simple_bus
> uclass 11: ahci
> uclass 12: blk
> uclass 14: cpu
> uclass 19: gpio
> uclass 24: irq
> uclass 25: keyboard
> - * keyboard @ 7f4e90c8, seq 0, (req -1)
>
> uclass 27: lpc
> uclass 34: northbridge
> uclass 37: pch
> uclass 38: pci
> - pci @ 7f4e92c0
>
> uclass 39: pci_generic
> uclass 50: rtc
> - rtc @ 7f4e91d0
>
> uclass 51: serial
> - * serial @ 7f4e9140, seq 0, (req -1)
>
> uclass 52: spi
> uclass 54: spi_flash
> uclass 55: spi_generic
> uclass 56: syscon
> uclass 59: timer
> - * tsc-timer @ 7f4e9248, seq 0, (req -1)
>
> uclass 60: tpm
>
>
> Thanks a lot,
> Chi
Please do not top-posting.
The reason is that PCI is not probed so that AHCI driver is not probed
too. Can you please run pci command from U-Boot shell?
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller in pci_bus_to_hose()
Hi Minghuan, On Tue, Oct 11, 2016 at 5:36 PM, M.H. Lian wrote: > Hi Bin, > > Please see my comments inline. > > Thanks, > Minghuan > >> -Original Message- >> From: Bin Meng [mailto:bmeng...@gmail.com] >> Sent: Tuesday, October 11, 2016 3:43 PM >> To: M.H. Lian >> Cc: Simon Glass ; U-Boot Mailing List > b...@lists.denx.de>; Mingkai Hu ; Leo Li >> >> Subject: Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller in >> pci_bus_to_hose() >> >> Hi Minghuan, >> >> On Tue, Oct 11, 2016 at 3:12 PM, M.H. Lian wrote: >> > Hi Bin, >> > >> > With the patches our Layerscape PCIe driver has been fully based on DM. >> > Ethernet driver E1000 needs to define "CONFIG_DM_ETH" to use PCIe DM >> API instead of legacy PCI API. >> > But our other Ethernet driver FM(drivers/net/fm/eth.c) is still not support >> DM. So we cannot define "CONFIG_DM_ETH" >> >> For LS1021a ethernet, please pick up this patch to see if it works: >> http://patchwork.ozlabs.org/patch/566347/ > [Minghuan Lian] fm.c is used by ls1043 and ls1046. So if this patch is > merged, I may remove " CONFIG_DM_PCI_COMPAT " > On LS1021a. >> Yep, I think so. >> > Well, we must define "CONFIG_DM_PCI_COMPAT" to support e1000 and >> fm at the same time. >> > After FM driver is changed to support DM, we can define >> "CONFIG_DM_ETH" and remove "CONFIG_DM_PCI_COMPAT " >> > >> > But the current DM driver has an issue. >> > >> > 1. >> > pci_bus_to_hose(int busnum) defined in driver/pci/pci_compat.c is >> > to return the hose associated current busnum(PCIe device) instead of >> > PCIe controller (RC) >> > >> > pci_bus_to_hose(int bus) defined in driver/pci/pci.c for legacy PCI driver >> > is >> to return the hose pointed to the PCIe controller(RC). >> > >> > My first patch is to keep consistency and return the hose pointer of the >> PCIe controller. >> > - return dev_get_uclass_priv(bus); >> > + return dev_get_uclass_priv(pci_get_controller(bus)); >> > >> > 2 >> > In pci/pci_common.c phys_addr_t pci_hose_bus_to_phys() >> > >> > #ifdef CONFIG_DM_PCI >> >/* The root controller has the region information */ >> >hose = pci_bus_to_hose(0); >> > #endif >> > >> > Is always to return hose of the bus0. >> > >> > But our SoC has more than one PCIe controllers(RC). >> > >> > For example: >> > PCI0 bus 0 -- e1000#0 bus1 >> > PCI1 bus 2 -- e1000#1 bus3. >> >> I got it. But this does not look that good to me. There are two controllers, >> and >> bus number should be relative to the controller itself, not system wide. It's >> definitely right to assign bus number 0 to both PCIe host controllers, as >> they >> forward the bus number on their own bus link. I am wondering we should >> add a controller number to the PCI command, like the storage device >> command. The first parameter is the controller number, while the second >> parameter is the bus number. > [Minghuan Lian] Yes. Linux uses "PCI domain" to isolate PCIe controllers. > And config "CONFIG_PCI_DOMAINS" is to enable domain like controllers number. > But, under Linux if disable "CONFIG_PCI_DOMAINS ", all PCIe controllers will > be assigned continuous bus > Number like the current uboot. > Yep, I guess you will need introduce CONFIG_PCI_DOMAINS to U-Boot DM PCI codes. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] build error with CONFIG_DM_PCI disabled in menuconfig
Hi Bin
Thanks for the reply. I'm working on Intel Denvernton Board. As you suggested
I'm debugging it
using DM PCI now. In the device tree file, I define PCI as this, but I don't
know what is missing so
that AHCI isn't probed
pci {
compatible = "pci-x86";
#address-cells = <3>;
#size-cells = <2>;
u-boot,dm-pre-reloc;
};
In coreboot.h, I define
#define CONFIG_SCSI_AHCI
#define CONFIG_SCSI
#ifdef CONFIG_SCSI_AHCI
#define CONFIG_LIBATA
#define CONFIG_SYS_64BIT_LBA
#define CONFIG_SCSI_DEV_LIST{PCI_VENDOR_ID_INTEL, \
0x19b2}, \
{PCI_VENDOR_ID_INTEL, \
0x19c2}
U-Boot dm tree command shows pci isn't probed.
=> dm tree
Class Probed Name
root[ + ]root_driver
keyboard[ + ]|-- keyboard
serial [ + ]|-- serial
rtc [ ]|-- rtc
timer [ + ]|-- tsc-timer
pci [ ]`-- pci
=> dm uclass
uclass 0: root
- * root_driver @ 7f4e9040, seq 0, (req -1)
uclass 9: simple_bus
uclass 11: ahci
uclass 12: blk
uclass 14: cpu
uclass 19: gpio
uclass 24: irq
uclass 25: keyboard
- * keyboard @ 7f4e90c8, seq 0, (req -1)
uclass 27: lpc
uclass 34: northbridge
uclass 37: pch
uclass 38: pci
- pci @ 7f4e92c0
uclass 39: pci_generic
uclass 50: rtc
- rtc @ 7f4e91d0
uclass 51: serial
- * serial @ 7f4e9140, seq 0, (req -1)
uclass 52: spi
uclass 54: spi_flash
uclass 55: spi_generic
uclass 56: syscon
uclass 59: timer
- * tsc-timer @ 7f4e9248, seq 0, (req -1)
uclass 60: tpm
Thanks a lot,
Chi
-Original Message-
From: Bin Meng [mailto:bmeng...@gmail.com]
Sent: Tuesday, October 11, 2016 2:44 AM
To: Ding, ChiX ; Simon Glass
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] build error with CONFIG_DM_PCI disabled in menuconfig
On Mon, Oct 10, 2016 at 11:47 PM, Ding, ChiX wrote:
> Hi there
> I disabled CONFIG_DM_PCI in menuconfig because I have problem
> detecting AHCI SCSI controller on X86 board with CONFIG_DM_PCI enabled and
> the older code in drivers/pci/pci.c works for me in the previous U-boot
> version.
> Then I got the build error :
> u-boot/arch/x86/cpu/irq.c:29: undefined reference to `dm_pci_read_config8'
> u-boot/arch/x86/cpu/irq.c:104: undefined reference to `dm_pci_get_bdf'
> u-boot/arch/x86/cpu/irq.c:147: undefined reference to `dm_pci_read_config32'
> u-boot/arch/x86/cpu/pci.c:69:
Re: [U-Boot] [PATCH 9/9] armv8: ls1046a: Enable PCIe support
Hi Bin, Please see my comment inline. Thanks, Minghuan > -Original Message- > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: Monday, October 10, 2016 7:42 PM > To: M.H. Lian > Cc: U-Boot Mailing List ; Mingkai Hu > ; Leo Li > Subject: Re: [U-Boot] [PATCH 9/9] armv8: ls1046a: Enable PCIe support > > Hi Minghuan, > > On Mon, Oct 10, 2016 at 4:47 PM, Minghuan Lian > wrote: > > Signed-off-by: Minghuan Lian > > --- > > include/configs/ls1046a_common.h | 15 +++ > > 1 file changed, 15 insertions(+) > > > > diff --git a/include/configs/ls1046a_common.h > > b/include/configs/ls1046a_common.h > > index 7c5e635..f8f5ee2 100644 > > --- a/include/configs/ls1046a_common.h > > +++ b/include/configs/ls1046a_common.h > > @@ -117,6 +117,21 @@ > > #define CONFIG_SYS_I2C_MXC_I2C3 > > #define CONFIG_SYS_I2C_MXC_I2C4 > > > > +/* PCIe */ > > +#define CONFIG_PCI /* Enable PCI/PCIE */ > > +#define CONFIG_DM_PCI /* Enable driver mode for PCI */ > > +#define CONFIG_DM_PCI_COMPAT > > +#define CONFIG_PCIE_LAYERSCAPE /* Use common FSL Layerscape PCIe > code > > +*/ #define CONFIG_SYS_PCI_64BIT > > Please do not add any Kconfig option in the header file any more. > These already converted Kconfig options should be moved to boards' > defconfig files. [Minghuan Lian] Ok. I will move them to defconfig files. > > > + > > +#ifdef CONFIG_PCI > > +#define CONFIG_PCI_PNP > > +#define CONFIG_PCI_SCAN_SHOW > > +#define CONFIG_CMD_PCI > > +#define CONFIG_NET_MULTI > > +#define CONFIG_E1000 > > +#endif > > + > > /* Command line configuration */ > > #define CONFIG_CMD_ENV > > > > -- > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/1] ARM:SUNXI: Update DRAM clock for Olimex A20 boards
Hi, On 10/11/2016 10:44 AM, Stefan Mavrodiev wrote: Originally dram clock was set to 480MHz, but this behaves unstable. To improve stability the clock is reduced to 384MHz Signed-off-by: Stefan Mavrodiev The exact same change is already in u-boot-sunxi/next, and I've already send out a pullreq to get this merged. Regards, Hans --- configs/A20-OLinuXino-Lime2_defconfig | 2 +- configs/A20-OLinuXino-Lime_defconfig | 2 +- configs/A20-Olimex-SOM-EVB_defconfig | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configs/A20-OLinuXino-Lime2_defconfig b/configs/A20-OLinuXino-Lime2_defconfig index 5688622..4751fe0 100644 --- a/configs/A20-OLinuXino-Lime2_defconfig +++ b/configs/A20-OLinuXino-Lime2_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_MACH_SUN7I=y -CONFIG_DRAM_CLK=480 +CONFIG_DRAM_CLK=384 CONFIG_MMC0_CD_PIN="PH1" CONFIG_USB0_VBUS_PIN="PC17" CONFIG_USB0_VBUS_DET="PH5" diff --git a/configs/A20-OLinuXino-Lime_defconfig b/configs/A20-OLinuXino-Lime_defconfig index c4f6e1a..024dc2d 100644 --- a/configs/A20-OLinuXino-Lime_defconfig +++ b/configs/A20-OLinuXino-Lime_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_MACH_SUN7I=y -CONFIG_DRAM_CLK=480 +CONFIG_DRAM_CLK=384 CONFIG_MMC0_CD_PIN="PH1" CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set diff --git a/configs/A20-Olimex-SOM-EVB_defconfig b/configs/A20-Olimex-SOM-EVB_defconfig index 7a14a7b..3f4e90d 100644 --- a/configs/A20-Olimex-SOM-EVB_defconfig +++ b/configs/A20-Olimex-SOM-EVB_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_MACH_SUN7I=y -CONFIG_DRAM_CLK=480 +CONFIG_DRAM_CLK=384 CONFIG_MMC0_CD_PIN="PH1" CONFIG_MMC3_CD_PIN="PH0" CONFIG_MMC3_PINS="PH" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller in pci_bus_to_hose()
Hi Bin, With the patches our Layerscape PCIe driver has been fully based on DM. Ethernet driver E1000 needs to define "CONFIG_DM_ETH" to use PCIe DM API instead of legacy PCI API. But our other Ethernet driver FM(drivers/net/fm/eth.c) is still not support DM. So we cannot define "CONFIG_DM_ETH" Well, we must define "CONFIG_DM_PCI_COMPAT" to support e1000 and fm at the same time. After FM driver is changed to support DM, we can define "CONFIG_DM_ETH" and remove "CONFIG_DM_PCI_COMPAT " But the current DM driver has an issue. 1. pci_bus_to_hose(int busnum) defined in driver/pci/pci_compat.c is to return the hose associated current busnum(PCIe device) instead of PCIe controller (RC) pci_bus_to_hose(int bus) defined in driver/pci/pci.c for legacy PCI driver is to return the hose pointed to the PCIe controller(RC). My first patch is to keep consistency and return the hose pointer of the PCIe controller. - return dev_get_uclass_priv(bus); + return dev_get_uclass_priv(pci_get_controller(bus)); 2 In pci/pci_common.c phys_addr_t pci_hose_bus_to_phys() #ifdef CONFIG_DM_PCI /* The root controller has the region information */ hose = pci_bus_to_hose(0); #endif Is always to return hose of the bus0. But our SoC has more than one PCIe controllers(RC). For example: PCI0 bus 0 -- e1000#0 bus1 PCI1 bus 2 -- e1000#1 bus3. PCI1 is the second PCIe controller (RC) has different PCIe space to PCI0. For E1000#1, we want to get the host pointed to PCI1 bus2 not bus0. Thanks, Minghuan > -Original Message- > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: Monday, October 10, 2016 6:38 PM > To: M.H. Lian > Cc: Simon Glass ; U-Boot Mailing List b...@lists.denx.de>; Mingkai Hu ; Leo Li > > Subject: Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller in > pci_bus_to_hose() > > Hi Minghuan, > > On Mon, Oct 10, 2016 at 5:09 PM, M.H. Lian > wrote: > > Hi Bin， > > > > Thanks for your comments. > > > > The series of patches is to change legacy PCIe driver to DM PCIe driver. > > The first two patches are to change DM to support multiple PCIe controllers. > > I don't understand what is broken. If you fully convert the driver to DM PCI, > I > don't think we need ever touch the pci_compat codes. Could you please > elaborate more? > > > The 8th patch is to change Layerscape PCIe driver based on DM Other > > patches are to add PCIe dts node for five SoCs. > > > > Thanks, > > Minghuan > > > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller in pci_bus_to_hose()
Hi Minghuan, On Tue, Oct 11, 2016 at 3:12 PM, M.H. Lian wrote: > Hi Bin, > > With the patches our Layerscape PCIe driver has been fully based on DM. > Ethernet driver E1000 needs to define "CONFIG_DM_ETH" to use PCIe DM API > instead of legacy PCI API. > But our other Ethernet driver FM(drivers/net/fm/eth.c) is still not support > DM. So we cannot define "CONFIG_DM_ETH" For LS1021a ethernet, please pick up this patch to see if it works: http://patchwork.ozlabs.org/patch/566347/ > Well, we must define "CONFIG_DM_PCI_COMPAT" to support e1000 and fm at the > same time. > After FM driver is changed to support DM, we can define "CONFIG_DM_ETH" and > remove "CONFIG_DM_PCI_COMPAT " > > But the current DM driver has an issue. > > 1. > pci_bus_to_hose(int busnum) defined in driver/pci/pci_compat.c is to > return the hose associated current busnum(PCIe device) instead of PCIe > controller (RC) > > pci_bus_to_hose(int bus) defined in driver/pci/pci.c for legacy PCI driver is > to return the hose pointed to the PCIe controller(RC). > > My first patch is to keep consistency and return the hose pointer of the PCIe > controller. > - return dev_get_uclass_priv(bus); > + return dev_get_uclass_priv(pci_get_controller(bus)); > > 2 > In pci/pci_common.c phys_addr_t pci_hose_bus_to_phys() > > #ifdef CONFIG_DM_PCI >/* The root controller has the region information */ >hose = pci_bus_to_hose(0); > #endif > > Is always to return hose of the bus0. > > But our SoC has more than one PCIe controllers(RC). > > For example: > PCI0 bus 0 -- e1000#0 bus1 > PCI1 bus 2 -- e1000#1 bus3. I got it. But this does not look that good to me. There are two controllers, and bus number should be relative to the controller itself, not system wide. It's definitely right to assign bus number 0 to both PCIe host controllers, as they forward the bus number on their own bus link. I am wondering we should add a controller number to the PCI command, like the storage device command. The first parameter is the controller number, while the second parameter is the bus number. > > PCI1 is the second PCIe controller (RC) has different PCIe space to PCI0. > For E1000#1, we want to get the host pointed to PCI1 bus2 not bus0. > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.
From: Yuan Yao Signed-off-by: Yuan Yao --- board/freescale/ls2080aqds/README | 35 +++ 1 file changed, 35 insertions(+) diff --git a/board/freescale/ls2080aqds/README b/board/freescale/ls2080aqds/README index f288750..0f7446a 100644 --- a/board/freescale/ls2080aqds/README +++ b/board/freescale/ls2080aqds/README @@ -188,3 +188,38 @@ DPMAC14 -> PHY4-P1 DPMAC15 -> PHY4-P2 DPMAC16 -> PHY4-P3 + +Booting from QSPI +--- +Booting from QSPI requires two images, RCW and u-boot-dtb.bin. +The difference between QSPI boot RCW image and NOR boot image is the PBI +command sequence. Below is the setting for PBI commands for QDS which boot +on QSPI flash device. + +1) CCSR 4-byte write to 0x00e00404, data=0x +2) CCSR 4-byte write to 0x00e00400, data=0x2001 +The above two commands set bootloc register to 0x_2001 where +the u-boot code will be running in QSPI flash. + +RCW image should be written to the beginning of QSPI flash device. +Example of using u-boot command + +=> sf probe 0:0 +SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB +=> sf erase 0 + +SF: 65536 bytes @ 0x0 Erased: OK +=> sf write 0 +SF: 164 bytes @ 0x0 Written: OK + +To get the QSPI image, build u-boot with QSPI config, for example, +ls2080aqds_qspi_defconfig. The image needed is u-boot-dtb.bin. +The u-boot image should be written to 0x1. + +=> sf probe 0:0 +SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB +=> sf erase 1 + +SF: 589824 bytes @ 0x1 Erased: OK +=> sf write 1 +SF: 580966 bytes @ 0x1 Written: OK + +With these two images in QSPI flash device, the board can boot from QSPI. -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] pci: layerscape: rewrite pci driver based on DM
Hi Minghuan, On Tue, Oct 11, 2016 at 3:21 PM, M.H. Lian wrote: > Hi Bin, > > Thanks for your suggestion. > Please see my comments inline. > > Thanks, > Minghuan > >> -Original Message- >> From: Bin Meng [mailto:bmeng...@gmail.com] >> Sent: Monday, October 10, 2016 7:49 PM >> To: M.H. Lian ; Simon Glass >> Cc: U-Boot Mailing List ; Mingkai Hu >> ; Leo Li >> Subject: Re: [U-Boot] [PATCH 8/9] pci: layerscape: rewrite pci driver based >> on >> DM >> >> Hi Minghuan, >> >> On Mon, Oct 10, 2016 at 4:47 PM, Minghuan Lian >> wrote: >> > There are more than five kinds of Layerscape SoCs. unfortunately, PCIe >> > controller of each SoC is a little bit different. In order to avoid >> > too many macro definitions, the patch re-implement PCIe driver based >> > on DM. PCIe dts node is to describe the difference. >> > >> > Signed-off-by: Minghuan Lian >> > --- >> > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 8 - >> > drivers/pci/Kconfig| 8 + >> > drivers/pci/pcie_layerscape.c | 958 >> > +++-- >> > include/configs/ls1012a_common.h | 12 + >> > include/configs/ls1012aqds.h | 24 - >> > include/configs/ls1012ardb.h | 24 - >> > include/configs/ls1021aqds.h | 18 +- >> > include/configs/ls1021atwr.h | 18 +- >> > include/configs/ls1043a_common.h | 23 +- >> > include/configs/ls2080a_common.h | 27 +- >> > include/configs/ls2080aqds.h | 8 - >> > include/configs/ls2080ardb.h | 8 - >> >> These header file changes should not be put in the same commit of the >> layerscape PCIe driver conversion. They should be in a separate commit. So >> you are likely to have 3 commits: firstly add DM codes with #ifdef >> CONFIG_DM_PCI #endif in the layerscape PCIe driver, without breaking the >> existing board support. 2nd commit to update the boards configuration files >> (defconfig and the header), and 3rd commit to remove the #ifdef >> CONFIG_DM_PCI #endif, only leaving the DM version codes. > > [Minghuan Lian] Your suggestion is excellent. I will change the patch. > For the header and defconfig files, do I need to separate them to several > patches for different SoC? > I mean a patch is for ls1012, a patch is for ls1043 ... It depends on how you organize your patch series. We should make every commit bisectable, eg: the commit itself does not break build or any functionality. If all SoC header files need to change all together, it should be in one patch. Otherwise, you can put them into separate patch. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] mmc: introduce mmc_power_init
In device tree, there is vmmc-supply property for SD/MMC.
Introduce mmc_power_init function to handle vmmc-supply.
mmc_power_init will first invoke board_mmc_power_init to
avoid break boards which already implement board_mmc_power_init.
If DM_MMC and DM_REGULATOR is defined, the regulator
will be enabled to power up the device.
Signed-off-by: Peng Fan
Cc: Jaehoon Chung
---
V2:
Change function prototype to static.
Use puts to replace debug, when no vmmc-supply.
V1: Use a generic way to handle vmmc supply, but not let vendor driver
to handle it.
The RFC patset thread:
http://lists.denx.de/pipermail/u-boot/2016-April/251019.html
drivers/mmc/mmc.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 0312da9..320413a 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1582,6 +1583,31 @@ __weak void board_mmc_power_init(void)
{
}
+static int mmc_power_init(struct mmc *mmc)
+{
+ board_mmc_power_init();
+
+#if defined(CONFIG_DM_MMC) && defined(CONFIG_DM_REGULATOR) && \
+ !defined(CONFIG_SPL_BUILD)
+ struct udevice *vmmc_supply;
+ int ret;
+
+ ret = device_get_supply_regulator(mmc->dev, "vmmc-supply",
+ &vmmc_supply);
+ if (ret) {
+ puts("No vmmc supply\n");
+ return 0;
+ }
+
+ ret = regulator_set_enable(vmmc_supply, true);
+ if (ret) {
+ puts("Error enabling VMMC supply\n");
+ return ret;
+ }
+#endif
+ return 0;
+}
+
int mmc_start_init(struct mmc *mmc)
{
bool no_card;
@@ -1606,7 +1632,9 @@ int mmc_start_init(struct mmc *mmc)
#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
mmc_adapter_card_type_ident();
#endif
- board_mmc_power_init();
+ err = mmc_power_init(mmc);
+ if (err)
+ return err;
#ifdef CONFIG_DM_MMC_OPS
/* The device has already been probed ready for use */
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
