[U-Boot] [PATCH v2 5/5] configs: sama5d2_xplained: add #ifndef before CONFIG_ATMEL_PIO4
Since CONFIG_ATMEL_PIO4 options is added to Kconfig, to avoid compilation warnings when the option is enabled, add #ifndef CONFIG_DM_GPIO before #define CONFIG_ATMEL_PIO4 to avoid compilation warnings. Signed-off-by: Wenyou Yang --- Changes in v2: - integrate the gpio rework patch into this patch series. - add the new patch to move the PIO4 definitions to head file and rephrase them. - add the new patch to add #ifndef before CONFIG_ATMEL_PIO4 in configs/sama5d2_xplained.h include/configs/sama5d2_xplained.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/sama5d2_xplained.h b/include/configs/sama5d2_xplained.h index f9a8f6f..d477ff8 100644 --- a/include/configs/sama5d2_xplained.h +++ b/include/configs/sama5d2_xplained.h @@ -34,8 +34,10 @@ #define CONFIG_SYS_LOAD_ADDR 0x2200 /* load address */ +#ifndef CONFIG_DM_GPIO #undef CONFIG_AT91_GPIO #define CONFIG_ATMEL_PIO4 +#endif /* SerialFlash */ #ifdef CONFIG_CMD_SF -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] gpio: atmel_pio4: rework to support driver model & DT
Rework the driver to support the driver model and the device tree.
Signed-off-by: Wenyou Yang
---
Changes in v2: None
drivers/gpio/Kconfig | 2 +-
drivers/gpio/atmel_pio4.c | 104 +-
2 files changed, 85 insertions(+), 21 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 2b4624d..09093b7 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -30,7 +30,7 @@ config DWAPB_GPIO
config ATMEL_PIO4
bool "ATMEL PIO4 driver"
- depends on DM
+ depends on DM_GPIO
default n
help
Say yes here to support the Atmel PIO4 driver.
diff --git a/drivers/gpio/atmel_pio4.c b/drivers/gpio/atmel_pio4.c
index 84e8cc5..218847f 100644
--- a/drivers/gpio/atmel_pio4.c
+++ b/drivers/gpio/atmel_pio4.c
@@ -9,9 +9,12 @@
#include
#include
#include
+#include
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
static struct atmel_pio4_port *atmel_pio4_port_base(u32 port)
{
struct atmel_pio4_port *base = NULL;
@@ -165,14 +168,38 @@ int atmel_pio4_get_pio_input(u32 port, u32 pin)
}
#ifdef CONFIG_DM_GPIO
+
+struct atmel_pioctrl_data {
+ u32 nbanks;
+};
+
+struct atmel_pio4_platdata {
+ struct atmel_pio4_port *reg_base;
+};
+
+static struct atmel_pio4_port *atmel_pio4_bank_base(struct udevice *dev,
+ u32 bank)
+{
+ struct atmel_pio4_platdata *plat = dev_get_platdata(dev);
+ struct atmel_pio4_port *port_base =
+ (struct atmel_pio4_port *)((u32)plat->reg_base +
+ ATMEL_PIO_BANK_OFFSET * bank);
+
+ return port_base;
+}
+
static int atmel_pio4_direction_input(struct udevice *dev, unsigned offset)
{
- struct at91_port_platdata *plat = dev_get_platdata(dev);
- struct atmel_pio4_port *port_base = (atmel_pio4_port *)plat->base_addr;
- u32 mask = 0x01 << offset;
- u32 reg = ATMEL_PIO_CFGR_FUNC_GPIO;
+ u32 bank = ATMEL_PIO_BANK(offset);
+ u32 line = ATMEL_PIO_LINE(offset);
+ struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
+ u32 mask = BIT(line);
+ u32 reg;
writel(mask, &port_base->mskr);
+ reg = readl(&port_base->cfgr);
+ reg &= ~ATMEL_PIO_CFGR_FUNC_MASK;
+ reg &= ~ATMEL_PIO_DIR_MASK;
writel(reg, &port_base->cfgr);
return 0;
@@ -181,12 +208,16 @@ static int atmel_pio4_direction_input(struct udevice
*dev, unsigned offset)
static int atmel_pio4_direction_output(struct udevice *dev,
unsigned offset, int value)
{
- struct at91_port_platdata *plat = dev_get_platdata(dev);
- struct atmel_pio4_port *port_base = (atmel_pio4_port *)plat->base_addr;
- u32 mask = 0x01 << offset;
- u32 reg = ATMEL_PIO_CFGR_FUNC_GPIO | ATMEL_PIO_DIR_MASK;
+ u32 bank = ATMEL_PIO_BANK(offset);
+ u32 line = ATMEL_PIO_LINE(offset);
+ struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
+ u32 mask = BIT(line);
+ u32 reg;
writel(mask, &port_base->mskr);
+ reg = readl(&port_base->cfgr);
+ reg &= ~ATMEL_PIO_CFGR_FUNC_MASK;
+ reg |= ATMEL_PIO_DIR_MASK;
writel(reg, &port_base->cfgr);
if (value)
@@ -199,9 +230,10 @@ static int atmel_pio4_direction_output(struct udevice *dev,
static int atmel_pio4_get_value(struct udevice *dev, unsigned offset)
{
- struct at91_port_platdata *plat = dev_get_platdata(dev);
- struct atmel_pio4_port *port_base = (atmel_pio4_port *)plat->base_addr;
- u32 mask = 0x01 << offset;
+ u32 bank = ATMEL_PIO_BANK(offset);
+ u32 line = ATMEL_PIO_LINE(offset);
+ struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
+ u32 mask = BIT(line);
return (readl(&port_base->pdsr) & mask) ? 1 : 0;
}
@@ -209,9 +241,10 @@ static int atmel_pio4_get_value(struct udevice *dev,
unsigned offset)
static int atmel_pio4_set_value(struct udevice *dev,
unsigned offset, int value)
{
- struct at91_port_platdata *plat = dev_get_platdata(dev);
- struct atmel_pio4_port *port_base = (atmel_pio4_port *)plat->base_addr;
- u32 mask = 0x01 << offset;
+ u32 bank = ATMEL_PIO_BANK(offset);
+ u32 line = ATMEL_PIO_LINE(offset);
+ struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
+ u32 mask = BIT(line);
if (value)
writel(mask, &port_base->sodr);
@@ -223,9 +256,10 @@ static int atmel_pio4_set_value(struct udevice *dev,
static int atmel_pio4_get_function(struct udevice *dev, unsigned offset)
{
- struct at91_port_platdata *plat = dev_get_platdata(dev);
- struct atmel_pio4_port *port_base = (atmel_pio4_port *)plat->base_addr;
- u32 mask = 0x01 << offset;
+ u32 bank = ATMEL_PIO_BANK(offset);
+ u32 line = ATMEL_PIO_LINE(offset);
+ struct
[U-Boot] [PATCH v2 0/5] ARM: AT91: add AT91 PIO4 pinctrl driver
AT91 PIO4 controller is a combined gpio-controller, pin-mux and pin-config module. This patch is to add the pinctrl driver with driver model and device tree support. Changes in v2: - remove meaningless comment. - add else path for argument of pinconf. - add inline attribute for atmel_pio4_bank_base(). - add handle if the pinmux entries is greater maximum value. - add detailed example to show how to configure pinctrl for device. - remove interrupt and gpio property description. - add reviewed-by tag. - integrate the gpio rework patch into this patch series. - add the new patch to move the PIO4 definitions to head file and rephrase them. - add the new patch to add #ifndef before CONFIG_ATMEL_PIO4 in configs/sama5d2_xplained.h Wenyou Yang (5): gpio: atmel_pio4: move PIO4 definitions to head file pinctrl: at91-pio4: add pinctrl driver atmel: bring in at91 pio4 device tree file and bindings gpio: atmel_pio4: rework to support driver model & DT configs: sama5d2_xplained: add #ifndef before CONFIG_ATMEL_PIO4 arch/arm/dts/sama5d2-pinfunc.h | 880 + arch/arm/mach-at91/include/mach/atmel_pio4.h | 35 + .../pinctrl/atmel,at91-pio4-pinctrl.txt| 66 ++ drivers/gpio/Kconfig | 2 +- drivers/gpio/atmel_pio4.c | 167 ++-- drivers/pinctrl/Kconfig| 7 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-at91-pio4.c| 181 + include/configs/sama5d2_xplained.h | 2 + 9 files changed, 1271 insertions(+), 70 deletions(-) create mode 100644 arch/arm/dts/sama5d2-pinfunc.h create mode 100644 doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] atmel: bring in at91 pio4 device tree file and bindings
Bring in required device tree file and bindings from Linux. Signed-off-by: Wenyou Yang Reviewed-by: Andreas Bießmann --- Changes in v2: - add detailed example to show how to configure pinctrl for device. - remove interrupt and gpio property description. - add reviewed-by tag. arch/arm/dts/sama5d2-pinfunc.h | 880 + .../pinctrl/atmel,at91-pio4-pinctrl.txt| 66 ++ 2 files changed, 946 insertions(+) create mode 100644 arch/arm/dts/sama5d2-pinfunc.h create mode 100644 doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt diff --git a/arch/arm/dts/sama5d2-pinfunc.h b/arch/arm/dts/sama5d2-pinfunc.h new file mode 100644 index 000..b0c912f --- /dev/null +++ b/arch/arm/dts/sama5d2-pinfunc.h @@ -0,0 +1,880 @@ +#define PINMUX_PIN(no, func, ioset) \ +(((no) & 0x) | (((func) & 0xf) << 16) | (((ioset) & 0xff) << 20)) + +#define PIN_PA00 +#define PIN_PA0__GPIO PINMUX_PIN(PIN_PA0, 0, 0) +#define PIN_PA0__SDMMC0_CK PINMUX_PIN(PIN_PA0, 1, 1) +#define PIN_PA0__QSPI0_SCK PINMUX_PIN(PIN_PA0, 2, 1) +#define PIN_PA0__D0PINMUX_PIN(PIN_PA0, 6, 2) +#define PIN_PA11 +#define PIN_PA1__GPIO PINMUX_PIN(PIN_PA1, 0, 0) +#define PIN_PA1__SDMMC0_CMDPINMUX_PIN(PIN_PA1, 1, 1) +#define PIN_PA1__QSPI0_CS PINMUX_PIN(PIN_PA1, 2, 1) +#define PIN_PA1__D1PINMUX_PIN(PIN_PA1, 6, 2) +#define PIN_PA22 +#define PIN_PA2__GPIO PINMUX_PIN(PIN_PA2, 0, 0) +#define PIN_PA2__SDMMC0_DAT0 PINMUX_PIN(PIN_PA2, 1, 1) +#define PIN_PA2__QSPI0_IO0 PINMUX_PIN(PIN_PA2, 2, 1) +#define PIN_PA2__D2PINMUX_PIN(PIN_PA2, 6, 2) +#define PIN_PA33 +#define PIN_PA3__GPIO PINMUX_PIN(PIN_PA3, 0, 0) +#define PIN_PA3__SDMMC0_DAT1 PINMUX_PIN(PIN_PA3, 1, 1) +#define PIN_PA3__QSPI0_IO1 PINMUX_PIN(PIN_PA3, 2, 1) +#define PIN_PA3__D3PINMUX_PIN(PIN_PA3, 6, 2) +#define PIN_PA44 +#define PIN_PA4__GPIO PINMUX_PIN(PIN_PA4, 0, 0) +#define PIN_PA4__SDMMC0_DAT2 PINMUX_PIN(PIN_PA4, 1, 1) +#define PIN_PA4__QSPI0_IO2 PINMUX_PIN(PIN_PA4, 2, 1) +#define PIN_PA4__D4PINMUX_PIN(PIN_PA4, 6, 2) +#define PIN_PA55 +#define PIN_PA5__GPIO PINMUX_PIN(PIN_PA5, 0, 0) +#define PIN_PA5__SDMMC0_DAT3 PINMUX_PIN(PIN_PA5, 1, 1) +#define PIN_PA5__QSPI0_IO3 PINMUX_PIN(PIN_PA5, 2, 1) +#define PIN_PA5__D5PINMUX_PIN(PIN_PA5, 6, 2) +#define PIN_PA66 +#define PIN_PA6__GPIO PINMUX_PIN(PIN_PA6, 0, 0) +#define PIN_PA6__SDMMC0_DAT4 PINMUX_PIN(PIN_PA6, 1, 1) +#define PIN_PA6__QSPI1_SCK PINMUX_PIN(PIN_PA6, 2, 1) +#define PIN_PA6__TIOA5 PINMUX_PIN(PIN_PA6, 4, 1) +#define PIN_PA6__FLEXCOM2_IO0 PINMUX_PIN(PIN_PA6, 5, 1) +#define PIN_PA6__D6PINMUX_PIN(PIN_PA6, 6, 2) +#define PIN_PA77 +#define PIN_PA7__GPIO PINMUX_PIN(PIN_PA7, 0, 0) +#define PIN_PA7__SDMMC0_DAT5 PINMUX_PIN(PIN_PA7, 1, 1) +#define PIN_PA7__QSPI1_IO0 PINMUX_PIN(PIN_PA7, 2, 1) +#define PIN_PA7__TIOB5 PINMUX_PIN(PIN_PA7, 4, 1) +#define PIN_PA7__FLEXCOM2_IO1 PINMUX_PIN(PIN_PA7, 5, 1) +#define PIN_PA7__D7PINMUX_PIN(PIN_PA7, 6, 2) +#define PIN_PA88 +#define PIN_PA8__GPIO PINMUX_PIN(PIN_PA8, 0, 0) +#define PIN_PA8__SDMMC0_DAT6 PINMUX_PIN(PIN_PA8, 1, 1) +#define PIN_PA8__QSPI1_IO1 PINMUX_PIN(PIN_PA8, 2, 1) +#define PIN_PA8__TCLK5 PINMUX_PIN(PIN_PA8, 4, 1) +#define PIN_PA8__FLEXCOM2_IO2 PINMUX_PIN(PIN_PA8, 5, 1) +#define PIN_PA8__NWE_NANDWEPINMUX_PIN(PIN_PA8, 6, 2) +#define PIN_PA99 +#define PIN_PA9__GPIO PINMUX_PIN(PIN_PA9, 0, 0) +#define PIN_PA9__SDMMC0_DAT7 PINMUX_PIN(PIN_PA9, 1, 1) +#define PIN_PA9__QSPI1_IO2 PINMUX_PIN(PIN_PA9, 2, 1) +#define PIN_PA9__TIOA4 PINMUX_PIN(PIN_PA9, 4, 1) +#define PIN_PA9__FLEXCOM2_IO3 PINMUX_PIN(PIN_PA9, 5, 1) +#define PIN_PA9__NCS3 PINMUX_PIN(PIN_PA9, 6, 2) +#define PIN_PA10 10 +#define PIN_PA10__GPIO PINMUX_PIN(PIN_PA10, 0, 0) +#define PIN_PA10__SDMMC0_RSTN PINMUX_PIN(PIN_PA10, 1, 1) +#define PIN_PA10__QSPI1_IO3PINMUX_PIN(PIN_PA10, 2, 1) +#define PIN_PA10__TIOB4PINMUX_PIN(PIN_PA10, 4, 1) +#define PIN_PA10__FLEXCOM2_IO4 PINMUX_PIN(PIN_PA10, 5, 1) +#define PIN_PA10__A21_NANDALE PINMUX_P
[U-Boot] [PATCH v2 1/5] gpio: atmel_pio4: move PIO4 definitions to head file
In order to make these PIO4 definitions shared with the at91 PIO4
pinctrl driver, move them from the existing GPIO driver to the
head file, rephrase them in the meanwhile.
Signed-off-by: Wenyou Yang
---
Changes in v2: None
arch/arm/mach-at91/include/mach/atmel_pio4.h | 35 ++
drivers/gpio/atmel_pio4.c| 71 +++-
2 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/arch/arm/mach-at91/include/mach/atmel_pio4.h
b/arch/arm/mach-at91/include/mach/atmel_pio4.h
index 8bb4b12..6760bec 100644
--- a/arch/arm/mach-at91/include/mach/atmel_pio4.h
+++ b/arch/arm/mach-at91/include/mach/atmel_pio4.h
@@ -29,6 +29,41 @@ struct atmel_pio4_port {
#endif
+/*
+ * PIO Configuration Register Fields
+ */
+#define ATMEL_PIO_CFGR_FUNC_MASK GENMASK(2, 0)
+#define ATMEL_PIO_CFGR_FUNC_GPIO (0x0 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_A (0x1 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_B (0x2 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_C (0x3 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_D (0x4 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_E (0x5 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_F (0x6 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_G (0x7 << 0)
+#define ATMEL_PIO_DIR_MASK BIT(8)
+#define ATMEL_PIO_PUEN_MASKBIT(9)
+#define ATMEL_PIO_PDEN_MASKBIT(10)
+#define ATMEL_PIO_IFEN_MASKBIT(12)
+#define ATMEL_PIO_IFSCEN_MASK BIT(13)
+#define ATMEL_PIO_OPD_MASK BIT(14)
+#define ATMEL_PIO_SCHMITT_MASK BIT(15)
+#define ATMEL_PIO_CFGR_EVTSEL_MASK GENMASK(26, 24)
+#define ATMEL_PIO_CFGR_EVTSEL_FALLING (0 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_RISING (1 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_BOTH (2 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_LOW (3 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_HIGH (4 << 24)
+
+#define ATMEL_PIO_NPINS_PER_BANK 32
+#define ATMEL_PIO_BANK(pin_id) (pin_id / ATMEL_PIO_NPINS_PER_BANK)
+#define ATMEL_PIO_LINE(pin_id) (pin_id % ATMEL_PIO_NPINS_PER_BANK)
+#define ATMEL_PIO_BANK_OFFSET 0x40
+
+#define ATMEL_GET_PIN_NO(pinfunc) ((pinfunc) & 0xff)
+#define ATMEL_GET_PIN_FUNC(pinfunc)((pinfunc >> 16) & 0xf)
+#define ATMEL_GET_PIN_IOSET(pinfunc) ((pinfunc >> 20) & 0xf)
+
#define AT91_PIO_PORTA 0x0
#define AT91_PIO_PORTB 0x1
#define AT91_PIO_PORTC 0x2
diff --git a/drivers/gpio/atmel_pio4.c b/drivers/gpio/atmel_pio4.c
index d71f525..84e8cc5 100644
--- a/drivers/gpio/atmel_pio4.c
+++ b/drivers/gpio/atmel_pio4.c
@@ -12,41 +12,6 @@
#include
#include
-#define ATMEL_PIO4_PINS_PER_BANK 32
-
-/*
- * Register Field Definitions
- */
-#define ATMEL_PIO4_CFGR_FUNC (0x7 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_GPIO (0x0 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_A (0x1 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_B (0x2 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_C (0x3 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_D (0x4 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_E (0x5 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_F (0x6 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_G (0x7 << 0)
-#define ATMEL_PIO4_CFGR_DIR(0x1 << 8)
-#define ATMEL_PIO4_CFGR_PUEN (0x1 << 9)
-#define ATMEL_PIO4_CFGR_PDEN (0x1 << 10)
-#define ATMEL_PIO4_CFGR_IFEN (0x1 << 12)
-#define ATMEL_PIO4_CFGR_IFSCEN (0x1 << 13)
-#define ATMEL_PIO4_CFGR_OPD(0x1 << 14)
-#define ATMEL_PIO4_CFGR_SCHMITT(0x1 << 15)
-#define ATMEL_PIO4_CFGR_DRVSTR (0x3 << 16)
-#defineATMEL_PIO4_CFGR_DRVSTR_LOW0 (0x0 << 16)
-#defineATMEL_PIO4_CFGR_DRVSTR_LOW1 (0x1 << 16)
-#defineATMEL_PIO4_CFGR_DRVSTR_MEDIUM (0x2 << 16)
-#defineATMEL_PIO4_CFGR_DRVSTR_HIGH (0x3 << 16)
-#define ATMEL_PIO4_CFGR_EVTSEL (0x7 << 24)
-#defineATMEL_PIO4_CFGR_EVTSEL_FALLING (0x0 << 24)
-#defineATMEL_PIO4_CFGR_EVTSEL_RISING (0x1 << 24)
-#defineATMEL_PIO4_CFGR_EVTSEL_BOTH (0x2 << 24)
-#defineATMEL_PIO4_CFGR_EVTSEL_LOW (0x3 << 24)
-#defineATMEL_PIO4_CFGR_EVTSEL_HIGH (0x4 << 24)
-#define ATMEL_PIO4_CFGR_PCFS (0x1 << 29)
-#define ATMEL_PIO4_CFGR_ICFS (0x1 << 30)
-
static struct atmel_pio4_port *atmel_pio4_port_base(u32 port)
{
struct atmel_pio4_port *base = NULL;
@@ -79,7 +44,7 @@ static int atmel_pio4_config_io_func(u32 port, u32 pin,
struct atmel_pio4_port *port_base;
u32 reg, mask;
- if (pin >= ATMEL_PIO4_PINS_PER_BANK)
+ if (pin >= ATMEL_PIO_NPINS_PER_BANK)
return -ENODEV;
port_base = atmel_pio4_port_base(port);
@@ -88,7 +53,7 @@ static int atmel_pio4_config_io_func(u32 port, u32 pin,
mask = 1 << pin;
reg = func;
- reg |= use_pullup ? ATMEL_PIO4_CFGR_PUEN : 0;
+ reg |= us
[U-Boot] [PATCH v2 2/5] pinctrl: at91-pio4: add pinctrl driver
AT91 PIO4 controller is a combined gpio-controller, pin-mux and
pin-config module. The peripherals are assigned pins through per-pin
based muxing logic. And the pin configuration are performed on
specific registers which are shared along with the gpio controller.
Signed-off-by: Wenyou Yang
---
Changes in v2:
- remove meaningless comment.
- add else path for argument of pinconf.
- add inline attribute for atmel_pio4_bank_base().
- add handle if the pinmux entries is greater maximum value.
drivers/pinctrl/Kconfig | 7 ++
drivers/pinctrl/Makefile| 1 +
drivers/pinctrl/pinctrl-at91-pio4.c | 181
3 files changed, 189 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 2a69bab..e71f298 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -105,6 +105,13 @@ config SPL_PINCONF
if PINCTRL || SPL_PINCTRL
+config PINCTRL_AT91PIO4
+ bool "AT91 PIO4 pinctrl driver"
+ depends on DM
+ help
+ This option is to enable the AT91 pinctrl driver for AT91 PIO4
+ controller which is available on SAMA5D2 SoC.
+
config ROCKCHIP_PINCTRL
bool "Rockchip pin control driver"
depends on DM
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 37dc904..bd0dea2 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_AT91PIO4) += pinctrl-at91-pio4.o
obj-y += nxp/
obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
obj-$(CONFIG_PINCTRL_SANDBOX) += pinctrl-sandbox.o
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c
b/drivers/pinctrl/pinctrl-at91-pio4.c
new file mode 100644
index 000..7e3abd7
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -0,0 +1,181 @@
+/*
+ * Atmel PIO4 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;
+
+/*
+ * Warning:
+ * In order to not introduce confusion between Atmel PIO groups and pinctrl
+ * framework groups, Atmel PIO groups will be called banks.
+ */
+
+struct atmel_pio4_platdata {
+ struct atmel_pio4_port *reg_base;
+};
+
+static const struct pinconf_param conf_params[] = {
+ { "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
+ { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
+ { "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 1 },
+ { "drive-open-drain", PIN_CONFIG_DRIVE_OPEN_DRAIN, 0 },
+ { "input-schmitt-disable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
+ { "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
+ { "input-debounce", PIN_CONFIG_INPUT_DEBOUNCE, 0 },
+};
+
+static u32 atmel_pinctrl_get_pinconf(const void *blob, int node)
+{
+ const struct pinconf_param *params;
+ u32 param, arg, conf = 0;
+ u32 i;
+
+ for (i = 0; i < ARRAY_SIZE(conf_params); i++) {
+ params = &conf_params[i];
+ if (!fdt_get_property(blob, node, params->property, NULL))
+ continue;
+
+ param = params->param;
+ arg = params->default_value;
+
+ switch (param) {
+ case PIN_CONFIG_BIAS_DISABLE:
+ conf &= (~ATMEL_PIO_PUEN_MASK);
+ conf &= (~ATMEL_PIO_PDEN_MASK);
+ break;
+ case PIN_CONFIG_BIAS_PULL_UP:
+ conf |= ATMEL_PIO_PUEN_MASK;
+ break;
+ case PIN_CONFIG_BIAS_PULL_DOWN:
+ conf |= ATMEL_PIO_PDEN_MASK;
+ break;
+ case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+ if (arg == 0)
+ conf &= (~ATMEL_PIO_OPD_MASK);
+ else
+ conf |= ATMEL_PIO_OPD_MASK;
+ break;
+ case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+ if (arg == 0)
+ conf |= ATMEL_PIO_SCHMITT_MASK;
+ else
+ conf &= (~ATMEL_PIO_SCHMITT_MASK);
+ break;
+ case PIN_CONFIG_INPUT_DEBOUNCE:
+ if (arg == 0) {
+ conf &= (~ATMEL_PIO_IFEN_MASK);
+ conf &= (~ATMEL_PIO_IFSCEN_MASK);
+ } else {
+ conf |= ATMEL_PIO_IFEN_MASK;
+ conf |= ATMEL_PIO_IFSCEN_MASK;
+ }
+ break;
+ default:
+ print
[U-Boot] [PATCH] arm: ls1021a: Enable CONFIG_OF_LIBFDT and CONFIG_FIT in defconfig
In defconfig, enable CONFIG_OF_LIBFDT to support booting DT linux kernel and enable COFNIG_FIT to support FIT image. Signed-off-by: Alison Wang --- configs/ls1021aqds_ddr4_nor_defconfig| 3 +++ configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 3 +++ configs/ls1021aqds_nand_defconfig| 2 ++ configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 2 ++ configs/ls1021aqds_nor_defconfig | 3 +++ configs/ls1021aqds_nor_lpuart_defconfig | 3 +++ configs/ls1021aqds_qspi_defconfig| 3 +++ configs/ls1021aqds_sdcard_ifc_defconfig | 3 +++ configs/ls1021aqds_sdcard_qspi_defconfig | 3 +++ configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 2 ++ configs/ls1021atwr_nor_defconfig | 3 +++ configs/ls1021atwr_nor_lpuart_defconfig | 3 +++ configs/ls1021atwr_qspi_defconfig| 3 +++ configs/ls1021atwr_sdcard_ifc_defconfig | 2 ++ configs/ls1021atwr_sdcard_qspi_defconfig | 3 +++ 15 files changed, 41 insertions(+) diff --git a/configs/ls1021aqds_ddr4_nor_defconfig b/configs/ls1021aqds_ddr4_nor_defconfig index 6feb581..04ded54 100644 --- a/configs/ls1021aqds_ddr4_nor_defconfig +++ b/configs/ls1021aqds_ddr4_nor_defconfig @@ -4,6 +4,9 @@ CONFIG_DM_SERIAL=y CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-duart" CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y +CONFIG_OF_LIBFDT=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4" CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y diff --git a/configs/ls1021aqds_ddr4_nor_lpuart_defconfig b/configs/ls1021aqds_ddr4_nor_lpuart_defconfig index 563af48..7915200 100644 --- a/configs/ls1021aqds_ddr4_nor_lpuart_defconfig +++ b/configs/ls1021aqds_ddr4_nor_lpuart_defconfig @@ -4,6 +4,9 @@ CONFIG_DM_SERIAL=y CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-lpuart" CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y +CONFIG_OF_LIBFDT=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,LPUART" CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y diff --git a/configs/ls1021aqds_nand_defconfig b/configs/ls1021aqds_nand_defconfig index 0786f20..9002a01 100644 --- a/configs/ls1021aqds_nand_defconfig +++ b/configs/ls1021aqds_nand_defconfig @@ -22,3 +22,5 @@ CONFIG_NETDEVICES=y CONFIG_E1000=y CONFIG_SYS_NS16550=y CONFIG_OF_LIBFDT=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y diff --git a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig index 243fcdd..30c2ca5 100644 --- a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig +++ b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig @@ -24,3 +24,5 @@ CONFIG_E1000=y CONFIG_SYS_NS16550=y CONFIG_RSA=y CONFIG_OF_LIBFDT=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y diff --git a/configs/ls1021aqds_nor_defconfig b/configs/ls1021aqds_nor_defconfig index 3cecdfe..a30153a 100644 --- a/configs/ls1021aqds_nor_defconfig +++ b/configs/ls1021aqds_nor_defconfig @@ -4,6 +4,9 @@ CONFIG_DM_SERIAL=y CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-duart" CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y +CONFIG_OF_LIBFDT=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y CONFIG_CMD_GREPENV=y diff --git a/configs/ls1021aqds_nor_lpuart_defconfig b/configs/ls1021aqds_nor_lpuart_defconfig index 75b763e..217cf88 100644 --- a/configs/ls1021aqds_nor_lpuart_defconfig +++ b/configs/ls1021aqds_nor_lpuart_defconfig @@ -4,6 +4,9 @@ CONFIG_DM_SERIAL=y CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-lpuart" CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y +CONFIG_OF_LIBFDT=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y CONFIG_SYS_EXTRA_OPTIONS="LPUART" CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y diff --git a/configs/ls1021aqds_qspi_defconfig b/configs/ls1021aqds_qspi_defconfig index c47fbce..15b0b0d 100644 --- a/configs/ls1021aqds_qspi_defconfig +++ b/configs/ls1021aqds_qspi_defconfig @@ -4,6 +4,9 @@ CONFIG_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-duart" CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y +CONFIG_OF_LIBFDT=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y CONFIG_SYS_EXTRA_OPTIONS="QSPI_BOOT" CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y diff --git a/configs/ls1021aqds_sdcard_ifc_defconfig b/configs/ls1021aqds_sdcard_ifc_defconfig index 61ab251..ef42d3d 100644 --- a/configs/ls1021aqds_sdcard_ifc_defconfig +++ b/configs/ls1021aqds_sdcard_ifc_defconfig @@ -1,6 +1,9 @@ CONFIG_ARM=y CONFIG_TARGET_LS1021AQDS=y CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-duart" +CONFIG_OF_LIBFDT=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT" CONFIG_HUSH_PARSER=y diff --git a/configs/ls1021aqds_sdcard_qspi_defconfig b/configs/ls1021aqds_sdcard_qspi_defconfig index bb88743..69f5b61 100644 --- a/configs/ls1021aqds_sdcard_qspi_defconfig +++ b/configs/ls1021aqds_sdcard_qspi_defconfig @@ -2,6 +2,9 @@ CONFIG_ARM=y CONFIG_TARGET_LS1021AQDS=y CONFIG_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-duart" +CONFIG_OF_LIBFDT=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y CONFIG_SPL=y CONFIG_SYS_EXT
Re: [U-Boot] [PATCH] cmd: replace the cast of the memory access to a fixed bit type in itest
On 04.05.2016 07:20, Masahiro Yamada wrote:
From: Kunihiko Hayashi
This patch fixes a bug that long word(.l) memory access in 'itest'
command reads the 8bytes of the actual memory on 64-bit architecture.
The cast to the memory pointer should use a fixed bit type.
Signed-off-by: Kunihiko Hayashi
Signed-off-by: Masahiro Yamada
---
cmd/itest.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmd/itest.c b/cmd/itest.c
index fb4d797..60626c7 100644
--- a/cmd/itest.c
+++ b/cmd/itest.c
@@ -65,13 +65,13 @@ static long evalexp(char *s, int w)
}
switch (w) {
case 1:
- l = (long)(*(unsigned char *)buf);
+ l = (long)(*(u8 *)buf);
break;
case 2:
- l = (long)(*(unsigned short *)buf);
+ l = (long)(*(u16 *)buf);
break;
case 4:
- l = (long)(*(unsigned long *)buf);
+ l = (long)(*(u32 *)buf);
break;
}
unmap_physmem(buf, w);
Reviewed-by: Stefan Roese
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd: replace the cast of the memory access to a fixed bit type in itest
From: Kunihiko Hayashi
This patch fixes a bug that long word(.l) memory access in 'itest'
command reads the 8bytes of the actual memory on 64-bit architecture.
The cast to the memory pointer should use a fixed bit type.
Signed-off-by: Kunihiko Hayashi
Signed-off-by: Masahiro Yamada
---
cmd/itest.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmd/itest.c b/cmd/itest.c
index fb4d797..60626c7 100644
--- a/cmd/itest.c
+++ b/cmd/itest.c
@@ -65,13 +65,13 @@ static long evalexp(char *s, int w)
}
switch (w) {
case 1:
- l = (long)(*(unsigned char *)buf);
+ l = (long)(*(u8 *)buf);
break;
case 2:
- l = (long)(*(unsigned short *)buf);
+ l = (long)(*(u16 *)buf);
break;
case 4:
- l = (long)(*(unsigned long *)buf);
+ l = (long)(*(u32 *)buf);
break;
}
unmap_physmem(buf, w);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: atmel_pio4: rework to support driver model & DT
Hi Andreas,
> -Original Message-
> From: Andreas Bießmann [mailto:andr...@biessmann.org]
> Sent: 2016年5月3日 19:20
> To: Yang, Wenyou
> Cc: U-Boot Mailing List
> Subject: Re: [U-Boot] [PATCH] gpio: atmel_pio4: rework to support driver
> model &
> DT
>
> Dear Wenyou,
>
> On 2016-04-15 02:49, Wenyou Yang wrote:
> > Rework the driver to support the driver model and the device tree.
>
> Could you please put this one into a series with the pinctrl driver?
Accepted, thank you.
>
> >
> > Signed-off-by: Wenyou Yang
> > ---
> >
> > drivers/gpio/Kconfig | 2 +-
> > drivers/gpio/atmel_pio4.c | 106
> > +-
> > 2 files changed, 86 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index
> > 2311309..62e730d 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -30,7 +30,7 @@ config DWAPB_GPIO
> >
> > config ATMEL_PIO4
> > bool "ATMEL PIO4 driver"
> > - depends on DM
> > + depends on DM_GPIO
> > default n
> > help
> > Say yes here to support the Atmel PIO4 driver.
> > diff --git a/drivers/gpio/atmel_pio4.c b/drivers/gpio/atmel_pio4.c
> > index d71f525..543b037 100644
> > --- a/drivers/gpio/atmel_pio4.c
> > +++ b/drivers/gpio/atmel_pio4.c
> > @@ -9,9 +9,12 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > #define ATMEL_PIO4_PINS_PER_BANK 32
> >
> > /*
> > @@ -200,14 +203,38 @@ int atmel_pio4_get_pio_input(u32 port, u32 pin)
> > }
> >
> > #ifdef CONFIG_DM_GPIO
> > +
> > +struct atmel_pioctrl_data {
> > + u32 nbanks;
> > +};
> > +
> > +struct atmel_pio4_platdata {
> > + struct atmel_pio4_port *reg_base;
> > +};
> > +
> > +static struct atmel_pio4_port *atmel_pio4_bank_base(struct udevice
> > *dev,
> > + u32 bank)
> > +{
> > + struct atmel_pio4_platdata *plat = dev_get_platdata(dev);
> > + struct atmel_pio4_port *port_base =
> > + (struct atmel_pio4_port *)((u32)plat->reg_base +
> > + ATMEL_PIO_BANK_OFFSET * bank);
> > +
> > + return port_base;
> > +}
> > +
> > static int atmel_pio4_direction_input(struct udevice *dev, unsigned
> > offset)
> > {
> > - struct at91_port_platdata *plat = dev_get_platdata(dev);
> > - struct atmel_pio4_port *port_base = (atmel_pio4_port
> > *)plat->base_addr;
> > - u32 mask = 0x01 << offset;
> > - u32 reg = ATMEL_PIO4_CFGR_FUNC_GPIO;
> > + u32 bank = ATMEL_PIO_BANK(offset);
> > + u32 line = ATMEL_PIO_LINE(offset);
> > + struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
> > + u32 mask = BIT(line);
> > + u32 reg;
> >
> > writel(mask, &port_base->mskr);
> > + reg = readl(&port_base->cfgr);
> > + reg &= ~ATMEL_PIO_CFGR_FUNC_MASK;
> > + reg &= ~ATMEL_PIO_DIR_MASK;
> > writel(reg, &port_base->cfgr);
> >
> > return 0;
> > @@ -216,12 +243,16 @@ static int atmel_pio4_direction_input(struct
> > udevice *dev, unsigned offset) static int
> > atmel_pio4_direction_output(struct udevice *dev,
> >unsigned offset, int value) {
> > - struct at91_port_platdata *plat = dev_get_platdata(dev);
> > - struct atmel_pio4_port *port_base = (atmel_pio4_port
> > *)plat->base_addr;
> > - u32 mask = 0x01 << offset;
> > - u32 reg = ATMEL_PIO4_CFGR_FUNC_GPIO | ATMEL_PIO4_CFGR_DIR;
> > + u32 bank = ATMEL_PIO_BANK(offset);
> > + u32 line = ATMEL_PIO_LINE(offset);
> > + struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
> > + u32 mask = BIT(line);
> > + u32 reg;
> >
> > writel(mask, &port_base->mskr);
> > + reg = readl(&port_base->cfgr);
> > + reg &= ~ATMEL_PIO_CFGR_FUNC_MASK;
> > + reg |= ATMEL_PIO_DIR_MASK;
> > writel(reg, &port_base->cfgr);
> >
> > if (value)
> > @@ -234,9 +265,10 @@ static int atmel_pio4_direction_output(struct
> > udevice *dev,
> >
> > static int atmel_pio4_get_value(struct udevice *dev, unsigned offset)
> > {
> > - struct at91_port_platdata *plat = dev_get_platdata(dev);
> > - struct atmel_pio4_port *port_base = (atmel_pio4_port
> > *)plat->base_addr;
> > - u32 mask = 0x01 << offset;
> > + u32 bank = ATMEL_PIO_BANK(offset);
> > + u32 line = ATMEL_PIO_LINE(offset);
> > + struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
> > + u32 mask = BIT(line);
> >
> > return (readl(&port_base->pdsr) & mask) ? 1 : 0; } @@ -244,9
> > +276,10 @@ static int atmel_pio4_get_value(struct udevice *dev,
> > unsigned offset) static int atmel_pio4_set_value(struct udevice *dev,
> > unsigned offset, int value)
> > {
> > - struct at91_port_platdata *plat = dev_get_platdata(dev);
> > - struct atmel_pio4_port *port_base = (atmel_pio4_port
> > *)plat->base_addr;
> > - u32 mask = 0x01 << offset;
> > + u32 bank = ATMEL_PIO_BANK(offset);
> > + u32 line = ATMEL_PIO_LINE(offset);
>
Re: [U-Boot] [PATCH 1/2] pinctrl: at91-pio4: add pinctrl driver
Hi Andreas,
Thank you for your review.
> -Original Message-
> From: Andreas Bießmann [mailto:andr...@biessmann.org]
> Sent: 2016年5月3日 19:18
> To: Yang, Wenyou
> Cc: U-Boot Mailing List
> Subject: Re: [U-Boot] [PATCH 1/2] pinctrl: at91-pio4: add pinctrl driver
>
> Dear Wenyou,
>
> On 2016-04-07 04:15, Wenyou Yang wrote:
> > AT91 PIO4 controller is a combined gpio-controller, pin-mux and
> > pin-config module. The peripherals are assigned pins through per-pin
> > based muxing logic. And the pin configuration are performed on
> > specific registers which are shared along with the gpio controller.
> >
> > Signed-off-by: Wenyou Yang
> > ---
> >
> > arch/arm/mach-at91/include/mach/atmel_pio4.h | 35 ++
> > drivers/pinctrl/Kconfig | 7 ++
> > drivers/pinctrl/Makefile | 1 +
> > drivers/pinctrl/pinctrl-at91-pio4.c | 164
> > +++
> > 4 files changed, 207 insertions(+)
> > create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c
> >
> > diff --git a/arch/arm/mach-at91/include/mach/atmel_pio4.h
> > b/arch/arm/mach-at91/include/mach/atmel_pio4.h
> > index 8bb4b12..6760bec 100644
> > --- a/arch/arm/mach-at91/include/mach/atmel_pio4.h
> > +++ b/arch/arm/mach-at91/include/mach/atmel_pio4.h
> > @@ -29,6 +29,41 @@ struct atmel_pio4_port {
> >
> > #endif
> >
> > +/*
> > + * PIO Configuration Register Fields
> > + */
> > +#define ATMEL_PIO_CFGR_FUNC_MASK GENMASK(2, 0)
> > +#define ATMEL_PIO_CFGR_FUNC_GPIO (0x0 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_A (0x1 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_B (0x2 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_C (0x3 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_D (0x4 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_E (0x5 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_F (0x6 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_G (0x7 << 0)
> > +#define ATMEL_PIO_DIR_MASK BIT(8)
> > +#define ATMEL_PIO_PUEN_MASKBIT(9)
> > +#define ATMEL_PIO_PDEN_MASKBIT(10)
> > +#define ATMEL_PIO_IFEN_MASKBIT(12)
> > +#define ATMEL_PIO_IFSCEN_MASK BIT(13)
> > +#define ATMEL_PIO_OPD_MASK BIT(14)
> > +#define ATMEL_PIO_SCHMITT_MASK BIT(15)
> > +#define ATMEL_PIO_CFGR_EVTSEL_MASK GENMASK(26, 24)
> > +#define ATMEL_PIO_CFGR_EVTSEL_FALLING (0 << 24)
> > +#define ATMEL_PIO_CFGR_EVTSEL_RISING (1 << 24)
> > +#define ATMEL_PIO_CFGR_EVTSEL_BOTH (2 << 24)
> > +#define ATMEL_PIO_CFGR_EVTSEL_LOW (3 << 24)
> > +#define ATMEL_PIO_CFGR_EVTSEL_HIGH (4 << 24)
>
> just realized that most of these definitions are already in the existing GPIO
> driver.
> Could you please put another patch before moving these definitions from the
> driver code to the header. It is ok for me to rephrase them when doing so.
Add a new patch to handle it.
Thank you.
Best Regards,
Wenyou Yang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/15] arm: Kconfig: Add support for AM43xx SoC specific Kconfig
Hello Andreas, Am 28.04.2016 um 15:38 schrieb Andreas Dannenberg: Hi Heiko, let me chime in here and address some of your points... Thanks ... Sorry, missed your email ... On Thu, Apr 28, 2016 at 06:29:31AM +0200, Heiko Schocher wrote: Hello Daniel, Am 27.04.2016 um 22:09 schrieb Daniel Allred: From: Madan Srinivas Adding support for AM43xx secure devices require the addition of some SOC specific config options like the amount of memory used by public ROM and the address of the entry point of u-boot or SPL, as seen by the ROM code, for the image to be built correctly. This mandates the addition of am AM43xx CONFIG option and the ARM Kconfig file has been modified to source this SOC Kconfig file. Moving the TARGET_AM43XX_EVM config option to the SOC KConfig and out of the arch/arm/Kconfig. Updating defconfigs to add the CONFIG_AM43XX=y statement and removing the #define CONFIG_AM43XX from the header file. Signed-off-by: Madan Srinivas Signed-off-by: Daniel Allred Tested-by: Andreas Dannenberg --- V2: Update more defconfigs Replace CREATE_BOARD_SYMLINK with TI_I2C_BOARD_DETECT Rebase against latest master arch/arm/Kconfig | 19 +-- arch/arm/cpu/armv7/am33xx/Kconfig | 13 + ^^ Is this correct? AFAIK AM33xx and AM43xx have gotten lumped together in several places both in U-Boot as well as in the Linux Kernel due to similarities in architecture allowing for code re-use, almost like a "platform" even though of course those are two different devices. I suppose because AM33xx devices were first that's how the folder got its name original name. If you look around in that folder and open some files you should see some code such as in emif4.c where stuff is shared. Ah, yes, thanks. configs/am437x_gp_evm_defconfig | 1 + configs/am437x_sk_evm_defconfig | 1 + configs/am43xx_evm_defconfig | 1 + configs/am43xx_evm_ethboot_defconfig | 1 + configs/am43xx_evm_qspiboot_defconfig | 1 + configs/am43xx_evm_usbhost_boot_defconfig | 1 + include/configs/am43xx_evm.h | 2 -- 9 files changed, 32 insertions(+), 8 deletions(-) Thanks for your patchseries looks very interesting. May you have patches for am335x ? I ask, because I have an am335x based board, which also uses HS boot mode, so I can test your patches, and we can may sync our work. Generally speaking AM335x HS device support in public U-Boot is currently not for us (us, meaning anybody including existing customers) to publicly discuss but you can probably take a guess in which direction things might go after these initial steps taken with Daniel's patch series. If you have inputs/suggestions however please feel free to email me directly and we can take it from there. Ok, thanks. diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 6b65d8e..6577572 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -381,12 +381,6 @@ config TARGET_AM335X_SL50 select DM select DM_SERIAL -config TARGET_AM43XX_EVM - bool "Support am43xx_evm" - select CPU_V7 - select SUPPORT_SPL - select TI_I2C_BOARD_DETECT - config TARGET_BAV335X bool "Support bav335x" select CPU_V7 @@ -507,6 +501,17 @@ config OMAP54XX select CPU_V7 select SUPPORT_SPL +config AM43XX + bool "AM43XX SoC" + select CPU_V7 + select SUPPORT_SPL + help + Support for AM43xx SOC from Texas Instruments. + The AM43xx high performance SOC features a Cortex-A9 + ARM core, a quad core PRU-ICSS for industrial Ethernet + protocols, dual camera support, optional 3D graphics + and an optional customer programmable secure boot. + config RMOBILE bool "Renesas ARM SoCs" select CPU_V7 @@ -777,6 +782,8 @@ source "arch/arm/cpu/armv7/omap4/Kconfig" source "arch/arm/cpu/armv7/omap5/Kconfig" +source "arch/arm/cpu/armv7/am33xx/Kconfig" + source "arch/arm/mach-orion5x/Kconfig" source "arch/arm/cpu/armv7/rmobile/Kconfig" diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig index 39759cd..dc51e9b 100644 --- a/arch/arm/cpu/armv7/am33xx/Kconfig +++ b/arch/arm/cpu/armv7/am33xx/Kconfig @@ -1,3 +1,15 @@ +if AM43XX AM43XX in am33xx/Kconfig? This seems bogus to me. See initial comment.. Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] pinctrl: at91-pio4: add pinctrl driver
Hi Andreas,
All accepted except the output path for gpio.
I don't think we need to configure the output path for gpio from pinconf.
We can use GPIO driver to handle the gpio output.
Are you agree?
> -Original Message-
> From: Andreas Bießmann [mailto:andr...@biessmann.org]
> Sent: 2016年5月3日 18:48
> To: Yang, Wenyou
> Cc: U-Boot Mailing List
> Subject: Re: [U-Boot] [PATCH 1/2] pinctrl: at91-pio4: add pinctrl driver
>
> Dear Wenyou,
>
> On 2016-04-07 04:15, Wenyou Yang wrote:
> > AT91 PIO4 controller is a combined gpio-controller, pin-mux and
> > pin-config module. The peripherals are assigned pins through per-pin
> > based muxing logic. And the pin configuration are performed on
> > specific registers which are shared along with the gpio controller.
> >
> > Signed-off-by: Wenyou Yang
> > ---
> >
> > arch/arm/mach-at91/include/mach/atmel_pio4.h | 35 ++
> > drivers/pinctrl/Kconfig | 7 ++
> > drivers/pinctrl/Makefile | 1 +
> > drivers/pinctrl/pinctrl-at91-pio4.c | 164
> > +++
> > 4 files changed, 207 insertions(+)
> > create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c
> >
> > diff --git a/arch/arm/mach-at91/include/mach/atmel_pio4.h
> > b/arch/arm/mach-at91/include/mach/atmel_pio4.h
> > index 8bb4b12..6760bec 100644
> > --- a/arch/arm/mach-at91/include/mach/atmel_pio4.h
> > +++ b/arch/arm/mach-at91/include/mach/atmel_pio4.h
> > @@ -29,6 +29,41 @@ struct atmel_pio4_port {
> >
> > #endif
> >
> > +/*
> > + * PIO Configuration Register Fields
> > + */
> > +#define ATMEL_PIO_CFGR_FUNC_MASK GENMASK(2, 0)
> > +#define ATMEL_PIO_CFGR_FUNC_GPIO (0x0 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_A (0x1 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_B (0x2 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_C (0x3 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_D (0x4 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_E (0x5 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_F (0x6 << 0)
> > +#define ATMEL_PIO_CFGR_FUNC_PERIPH_G (0x7 << 0)
> > +#define ATMEL_PIO_DIR_MASK BIT(8)
> > +#define ATMEL_PIO_PUEN_MASKBIT(9)
> > +#define ATMEL_PIO_PDEN_MASKBIT(10)
> > +#define ATMEL_PIO_IFEN_MASKBIT(12)
> > +#define ATMEL_PIO_IFSCEN_MASK BIT(13)
> > +#define ATMEL_PIO_OPD_MASK BIT(14)
> > +#define ATMEL_PIO_SCHMITT_MASK BIT(15)
> > +#define ATMEL_PIO_CFGR_EVTSEL_MASK GENMASK(26, 24)
> > +#define ATMEL_PIO_CFGR_EVTSEL_FALLING (0 << 24)
> > +#define ATMEL_PIO_CFGR_EVTSEL_RISING (1 << 24)
> > +#define ATMEL_PIO_CFGR_EVTSEL_BOTH (2 << 24)
> > +#define ATMEL_PIO_CFGR_EVTSEL_LOW (3 << 24)
> > +#define ATMEL_PIO_CFGR_EVTSEL_HIGH (4 << 24)
> > +
> > +#define ATMEL_PIO_NPINS_PER_BANK 32
> > +#define ATMEL_PIO_BANK(pin_id) (pin_id /
> ATMEL_PIO_NPINS_PER_BANK)
> > +#define ATMEL_PIO_LINE(pin_id) (pin_id %
> ATMEL_PIO_NPINS_PER_BANK)
> > +#define ATMEL_PIO_BANK_OFFSET 0x40
> > +
> > +#define ATMEL_GET_PIN_NO(pinfunc) ((pinfunc) & 0xff)
> > +#define ATMEL_GET_PIN_FUNC(pinfunc)((pinfunc >> 16) & 0xf)
> > +#define ATMEL_GET_PIN_IOSET(pinfunc) ((pinfunc >> 20) & 0xf)
> > +
> > #define AT91_PIO_PORTA 0x0
> > #define AT91_PIO_PORTB 0x1
> > #define AT91_PIO_PORTC 0x2
> > diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index
> > 2a69bab..e71f298 100644
> > --- a/drivers/pinctrl/Kconfig
> > +++ b/drivers/pinctrl/Kconfig
> > @@ -105,6 +105,13 @@ config SPL_PINCONF
> >
> > if PINCTRL || SPL_PINCTRL
> >
> > +config PINCTRL_AT91PIO4
> > + bool "AT91 PIO4 pinctrl driver"
> > + depends on DM
> > + help
> > + This option is to enable the AT91 pinctrl driver for AT91 PIO4
> > + controller which is available on SAMA5D2 SoC.
> > +
> > config ROCKCHIP_PINCTRL
> > bool "Rockchip pin control driver"
> > depends on DM
> > diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile index
> > 37dc904..bd0dea2 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_AT91PIO4) += pinctrl-at91-pio4.o
> > obj-y += nxp/
> > obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
> > obj-$(CONFIG_PINCTRL_SANDBOX) += pinctrl-sandbox.o
> > diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c
> > b/drivers/pinctrl/pinctrl-at91-pio4.c
> > new file mode 100644
> > index 000..e4ca5dc
> > --- /dev/null
> > +++ b/drivers/pinctrl/pinctrl-at91-pio4.c
> > @@ -0,0 +1,164 @@
> > +/*
> > + * Atmel PIO4 pinctrl driver
> > + *
> > + * Copyright (C) 2016 Atmel Corporation
> > + * Wenyou.Yang
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> >
Re: [U-Boot] [PATCH 2/2] atmel: bring in at91 pio4 device tree file and bindings
Hi Andreas, > -Original Message- > From: Andreas Bießmann [mailto:andr...@biessmann.org] > Sent: 2016年5月3日 18:15 > To: Yang, Wenyou > Cc: U-Boot Mailing List > Subject: Re: [U-Boot] [PATCH 2/2] atmel: bring in at91 pio4 device tree file > and > bindings > > Dear Wenyou, > > On 2016-04-07 04:16, Wenyou Yang wrote: > > Bring in required device tree files from Linux. > > > > Signed-off-by: Wenyou Yang > > There is a small typo below ... Sorry, I didn't find the typo. Please point to me, thanks. > > > --- > > > > arch/arm/dts/sama5d2-pinfunc.h | 880 > > + > > .../pinctrl/atmel,at91-pio4-pinctrl.txt| 65 ++ > > 2 files changed, 945 insertions(+) > > create mode 100644 arch/arm/dts/sama5d2-pinfunc.h create mode 100644 > > doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt > > > > > diff --git > > a/doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt > > b/doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt > > new file mode 100644 > > index 000..b048eac > > --- /dev/null > > +++ b/doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt > > @@ -0,0 +1,65 @@ > > +* Atmel PIO4 Controller > > + > > +The Atmel PIO4 controller is used to select the function of a pin and > > to > > +configure it. > > + > > +Required properties: > > +- compatible: "atmel,sama5d2-pinctrl". > > +- reg: base address and length of the PIO controller. > > +- interrupts: interrupt outputs from the controller, one for each > > bank. > > +- interrupt-controller: mark the device node as an interrupt > > controller. > > +- #interrupt-cells: should be two. > > +- gpio-controller: mark the device node as a gpio controller. > > +- #gpio-cells: should be two. > > + > > +Please refer to ../gpio/gpio.txt and > > ../interrupt-controller/interrupts.txt for > > +a general description of GPIO and interrupt bindings. > > + > > +Please refer to pinctrl-bindings.txt in this directory for details of > > the > > +common pinctrl bindings used by client devices. > > + > > +Subnode format > > +Each node (or subnode) will list the pins it needs and how to > > configured these > > ... how to configure ... Add more detailed example to show how to configure more clearly. > > Would you upstream this via linux kernel? Yes. I think so. > > Reviewed-by: Andreas Bießmann > > I'll pick this these days in a next branch for 2016.07, hopefully with a > lot more dt bindings. > > Best Regards > > Andreas Best Regards, Wenyou Yang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ELC Europe mini-summit?
Hello Tom, Am 03.05.2016 um 17:25 schrieb Tom Rini: On Mon, Apr 25, 2016 at 05:01:02PM -0400, Tom Rini wrote: Hey all, So, ELC Europe has a location, and dates and a CFP deadline "soon": http://events.linuxfoundation.org/events/embedded-linux-conference-europe Do we as a community wish to continue with our tradition of having something co-located with ELC Europe? If so, now'ish is the time I need to bring this up with Linux Foundation and ask. So, bad news. At this time Linux Foundation isn't able to offer us any space during ELC/IoT summit due to the size of the venue and colocation of the two conferences. I would strongly encourage folks that have a topic they wish to speak about to submit a paper to ELC itself and there's always the hallway track. Bad news, but thanks for your efforts! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] drivers/ddr/fsl: Update clk_adjust of sdram_clk_cntl
The clk_adjust is of SDRAM_CLK_CNTL[5:8] 4-bits on MPC85xx and P-series,
but is of SDRAM_CLK_CNTL[5:9] 5-bits on T-series and LS-series SoCs.
We should update it to adapt the case that clk_adjust is odd data.
Signed-off-by: Shengzhou Liu
---
drivers/ddr/fsl/ctrl_regs.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index 9073917..b26269c 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -1835,10 +1835,17 @@ static void set_ddr_sdram_clk_cntl(fsl_ddr_cfg_regs_t
*ddr,
/* Per FSL Application Note: AN2805 */
ss_en = 1;
#endif
- clk_adjust = popts->clk_adjust;
+ if (fsl_ddr_get_version(0) >= 0x40701) {
+ /* clk_adjust in 5-bits on T-series and LS-series */
+ clk_adjust = (popts->clk_adjust & 0x1F) << 22;
+ } else {
+ /* clk_adjust in 4-bits on earlier MPC85xx and P-series */
+ clk_adjust = (popts->clk_adjust & 0xF) << 23;
+ }
+
ddr->ddr_sdram_clk_cntl = (0
| ((ss_en & 0x1) << 31)
- | ((clk_adjust & 0xF) << 23)
+ | clk_adjust
);
debug("FSLDDR: clk_cntl = 0x%08x\n", ddr->ddr_sdram_clk_cntl);
}
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] board/freescale: Update ddr clk_adjust
This patch updates clk_adjust to actual value for boards with
T-series and LS-series SoCs to match the setting of clk_adjust
in latest ddr driver.
Signed-off-by: Shengzhou Liu
---
board/freescale/ls1021aqds/ddr.h | 28 ++--
board/freescale/ls1043aqds/ddr.h | 28 ++--
board/freescale/ls1043ardb/ddr.h | 6 +++---
board/freescale/ls2080aqds/ddr.h | 32
board/freescale/ls2080ardb/ddr.h | 32
board/freescale/t102xqds/ddr.c | 22 +++---
board/freescale/t102xrdb/ddr.c | 12 ++--
board/freescale/t1040qds/ddr.h | 22 +++---
board/freescale/t104xrdb/ddr.h | 26 +-
board/freescale/t208xqds/ddr.h | 40
board/freescale/t208xrdb/ddr.h | 20 ++--
board/freescale/t4qds/ddr.h | 38 +++---
board/freescale/t4rdb/ddr.h | 38 +++---
13 files changed, 172 insertions(+), 172 deletions(-)
diff --git a/board/freescale/ls1021aqds/ddr.h b/board/freescale/ls1021aqds/ddr.h
index f819c99..b39b561 100644
--- a/board/freescale/ls1021aqds/ddr.h
+++ b/board/freescale/ls1021aqds/ddr.h
@@ -31,21 +31,21 @@ static const struct board_specific_parameters udimm0[] = {
* ranks| mhz| GB |adjst| start | ctl2| ctl3 | |delay |
*/
#ifdef CONFIG_SYS_FSL_DDR4
- {2, 1666, 0, 4, 7, 0x0808090B, 0x0C0D0E0A,},
- {2, 1900, 0, 4, 6, 0x08080A0C, 0x0D0E0F0A,},
- {1, 1666, 0, 4, 8, 0x090A0B0B, 0x0C0D0E0C,},
- {1, 1900, 0, 4, 9, 0x0A0B0C0B, 0x0D0E0F0D,},
- {1, 2200, 0, 4,10, 0x0B0C0D0C, 0x0E0F110E,},
+ {2, 1666, 0, 8, 7, 0x0808090B, 0x0C0D0E0A,},
+ {2, 1900, 0, 8, 6, 0x08080A0C, 0x0D0E0F0A,},
+ {1, 1666, 0, 8, 8, 0x090A0B0B, 0x0C0D0E0C,},
+ {1, 1900, 0, 8, 9, 0x0A0B0C0B, 0x0D0E0F0D,},
+ {1, 2200, 0, 8,10, 0x0B0C0D0C, 0x0E0F110E,},
#elif defined(CONFIG_SYS_FSL_DDR3)
- {1, 833, 1, 6, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
- {1, 1350, 1, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
- {1, 833, 2, 6, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
- {1, 1350, 2, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
- {2, 833, 4, 6, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
- {2, 1350, 4, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
- {2, 1350, 0, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
- {2, 1666, 4, 4, 0xa, 0x0B08090C, 0x0B0E0D0A, 0x1f,2, 0},
- {2, 1666, 0, 4, 0xa, 0x0B08090C, 0x0B0E0D0A, 0x1f,2, 0},
+ {1, 833, 1, 12, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
+ {1, 1350, 1, 12, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
+ {1, 833, 2, 12, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
+ {1, 1350, 2, 12, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
+ {2, 833, 4, 12, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
+ {2, 1350, 4, 12, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
+ {2, 1350, 0, 12, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
+ {2, 1666, 4, 8,0xa, 0x0B08090C, 0x0B0E0D0A, 0x1f,2, 0},
+ {2, 1666, 0, 8,0xa, 0x0B08090C, 0x0B0E0D0A, 0x1f,2, 0},
#else
#error DDR type not defined
#endif
diff --git a/board/freescale/ls1043aqds/ddr.h b/board/freescale/ls1043aqds/ddr.h
index 8adb660..2400ecb 100644
--- a/board/freescale/ls1043aqds/ddr.h
+++ b/board/freescale/ls1043aqds/ddr.h
@@ -32,21 +32,21 @@ static const struct board_specific_parameters udimm0[] = {
* ranks| mhz| GB |adjst| start | ctl2| ctl3 | |delay |
*/
#ifdef CONFIG_SYS_FSL_DDR4
- {2, 1666, 0, 4, 7, 0x0808090B, 0x0C0D0E0A,},
- {2, 1900, 0, 4, 6, 0x08080A0C, 0x0D0E0F0A,},
- {1, 1666, 0, 4, 6, 0x0708090B, 0x0C0D0E0A,},
- {1, 1900, 0, 4, 9, 0x0A0B0C0B, 0x0D0E0F0D,},
- {1, 2200, 0, 4,10, 0x0B0C0D0C, 0x0E0F110E,},
+ {2, 1666, 0, 8, 7, 0x0808090B, 0x0C0D0E0A,},
+ {2, 1900, 0, 8, 6, 0x08080A0C, 0x0D0E0F0A,},
+ {1, 1666, 0, 8, 6, 0x0708090B, 0x0C0D0E0A,},
+ {1, 1900, 0, 8, 9, 0x0A0B0C0B, 0x0D0E0F0D,},
+ {1, 2200, 0, 8,10, 0x0B0C0D0C, 0x0E0F110E,},
#elif defined(CONFIG_SYS_FSL_DDR3)
- {1, 833, 1, 6, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
- {1, 1350, 1, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
- {1, 833, 2, 6, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
- {1, 1350, 2, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
- {2, 833, 4, 6, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
- {2, 1350, 4, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
- {2, 1350, 0, 6, 8, 0x0
Re: [U-Boot] u-boot hangs after enabling secured boot : gumstix-overo
Hi Simon,
Thanks for the help.
There is an update.
I experimented with the two options.
Option 1
=
Like you mentioned, I tried putting all the RSA boot options to
configs/omap3_overo_defconfig.
but surprisingly, the board was not able to boot. it stucks after printing
one line of junk characters.
So I think, putting definitions in include/configs/omap3_overo.h is also
fine ?
Option 2
1. changed u-boot-dtb.img name to u-boot.img .
2. then board is able to boot, but gives the below message when I tried to
use bootm.
Overo #
## Loading kernel from FIT Image at 8200 ...
Using 'conf@1' configuration
Verifying Hash Integrity ... sha1,rsa2048:my_keyRSA: Can't find Modular
Exp implementation
RSA: Can't find Modular Exp implementation
- Failed to verify required signature 'key-my_key'
Bad Data Hash
ERROR: can't get kernel image!
Overo #
As mentioned in doc/uImage.FIT/beaglebone_vboot.txt, I tried the script -
tools/fit_check_sign, and its output is normal. Able to verify the
signature.
So still dont know, what is the exact issue, why I am getting the above
error message.
I searched for UCLASS_MOD_EXP, /* RSA Mod Exp device */, but couldn't
get much info.
What is RSA Mod Exp device and how to make sure that I have that ?
Any input to debugging will be greatly helpful.
Thanks & Regards,
Arun
On Sun, May 1, 2016 at 2:55 PM, Simon Glass wrote:
> Hi Arun,
>
> On 28 April 2016 at 14:48, Arun Kuttiyara Varghese
> wrote:
> > Hi All,
> >
> > I was trying to enable the secured boot in u-boot for gumstix overo
> storm.
> >
> > based on http://www.denx-cs.de/doku/?q=m28verifiedboot
> >
> > After I prepared by SD cards, u-boot is not able to boot
> > and gives the below error message.
> >
> >
> > U-Boot SPL 2015.07 (Apr 28 2016 - 13:53:06)
> > SPL: Please implement spl_start_uboot() for your board
>
> This seems to be implemented for pepper, so to avoid this warning you
> could add this function for your board.
> .
> > SPL: Direct Linux boot not active!
> > reading u-boot.img
> > spl_load_image_fat: error reading image u-boot.img, err - -1
> > SPL: Please implement spl_start_uboot() for your board
> > SPL: Direct Linux boot not active!
> > Failed to mount ext2 filesystem...
> > spl_load_image_ext: ext4fs mount err - 0
> >
> >
> >
> > This is the u-boot.dts file that I am using.
> >
> >
> > /dts-v1/;
> >
> > / {
> > model = "Keys";
> >
> > signature {
> > key-dev {
> > required = "conf";
> > algo = "sha1,rsa2048";
> > key-name-hint = "my_key";
> > };
> > };
> > };
> >
> > compilation using :
> > dtc -p 0x1000 /work/u-boot.dts -O dtb -o /work/u-boot.dtb
> >
> > And these are the conf that I have added to include/configs/omap3_overo.h
> >
> > #define CONFIG_OF_CONTROL
> > #define CONFIG_OF_SEPARATE
> > #define CONFIG_FIT
> > #define CONFIG_FIT_SIGNATURE
> > #define CONFIG_RSA
> > #define CONFIG_FIT_VERBOSE
>
> These are in Kconfig now, so you should add them to
> configs/omap3_overo_defconfig.
>
> I'm not sure what is wrong, but those two things might help.
>
> >
> > and I am compiling u-boot by using below line :
> >
> > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- EXT_DTB=/work/u-boot.dtb
> all
> > -j4
> >
> > Please let me know if you have any ideas on how to debug this issue.
> >
> > Thanks & Regards,
> > Arun
> Regards,
> Simon
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] include/configs: Numerous typo fixes: "controler" -> "controller".
On Tue, May 03, 2016 at 07:52:49PM -0400, Robert P. J. Day wrote: > > Signed-off-by: Robert P. J. Day > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Tue, May 03, 2016 at 05:58:22PM -0500, Joe Hershberger wrote: > Hi Tom, > > Here are the bug fixes for this release. > > The following changes since commit e96e064f51139c4af39f14499564ef76e40bbc29: > > usb: dwc2: Init desc_before_addr (2016-05-03 19:21:18 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-net.git master > > for you to fetch changes up to 700877a62bfa88ef6e0267749db49f4dc63e2ea2: > > net: increase maximum frame size to accomediate VLAN packets (2016-05-03 > 17:52:12 -0500) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] include/configs: Numerous typo fixes: "controler" -> "controller".
Signed-off-by: Robert P. J. Day --- not the typos i was talking about, there are more. diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h index 94c8253..5249751 100644 --- a/include/configs/B4860QDS.h +++ b/include/configs/B4860QDS.h @@ -83,7 +83,7 @@ #define CONFIG_FSL_IFC /* Enable IFC Support */ #define CONFIG_FSL_CAAM/* Enable SEC/CAAM */ #define CONFIG_PCI /* Enable PCI/PCIE */ -#define CONFIG_PCIE1 /* PCIE controler 1 */ +#define CONFIG_PCIE1 /* PCIE controller 1 */ #define CONFIG_FSL_PCI_INIT/* Use common FSL init code */ #define CONFIG_SYS_PCI_64BIT /* enable 64-bit PCI resources */ diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h index 3a73379..aaddfca 100644 --- a/include/configs/BSC9132QDS.h +++ b/include/configs/BSC9132QDS.h @@ -85,7 +85,7 @@ #define CONFIG_PCI /* Enable PCI/PCIE */ #if defined(CONFIG_PCI) -#define CONFIG_PCIE1 /* PCIE controler 1 (slot 1) */ +#define CONFIG_PCIE1 /* PCIE controller 1 (slot 1) */ #define CONFIG_FSL_PCI_INIT/* Use common FSL init code */ #define CONFIG_PCI_INDIRECT_BRIDGE /* indirect PCI bridge support */ #define CONFIG_FSL_PCIE_RESET /* need PCIe reset errata */ diff --git a/include/configs/C29XPCIE.h b/include/configs/C29XPCIE.h index 4d14c8b..1e5b501 100644 --- a/include/configs/C29XPCIE.h +++ b/include/configs/C29XPCIE.h @@ -92,7 +92,7 @@ #define CONFIG_PCI /* Enable PCI/PCIE */ #ifdef CONFIG_PCI -#define CONFIG_PCIE1 /* PCIE controler 1 (slot 1) */ +#define CONFIG_PCIE1 /* PCIE controller 1 (slot 1) */ #define CONFIG_FSL_PCI_INIT/* Use common FSL init code */ #define CONFIG_PCI_INDIRECT_BRIDGE #define CONFIG_FSL_PCIE_RESET /* need PCIe reset errata */ diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h index 8cc7f02..03f17f9 100644 --- a/include/configs/MPC8536DS.h +++ b/include/configs/MPC8536DS.h @@ -51,9 +51,9 @@ #define CONFIG_FSL_ELBC1 /* Has Enhanced localbus controller */ #define CONFIG_PCI 1 /* Enable PCI/PCIE */ #define CONFIG_PCI11 /* Enable PCI controller 1 */ -#define CONFIG_PCIE1 1 /* PCIE controler 1 (slot 1) */ -#define CONFIG_PCIE2 1 /* PCIE controler 2 (slot 2) */ -#define CONFIG_PCIE3 1 /* PCIE controler 3 (ULI bridge) */ +#define CONFIG_PCIE1 1 /* PCIE controller 1 (slot 1) */ +#define CONFIG_PCIE2 1 /* PCIE controller 2 (slot 2) */ +#define CONFIG_PCIE3 1 /* PCIE controller 3 (ULI bridge) */ #define CONFIG_FSL_PCI_INIT1 /* Use common FSL init code */ #define CONFIG_PCI_INDIRECT_BRIDGE 1 /* indirect PCI bridge support */ #define CONFIG_FSL_PCIE_RESET 1 /* need PCIe reset errata */ diff --git a/include/configs/MPC8544DS.h b/include/configs/MPC8544DS.h index 6202dff..26d92da 100644 --- a/include/configs/MPC8544DS.h +++ b/include/configs/MPC8544DS.h @@ -25,9 +25,9 @@ #define CONFIG_PCI 1 /* Enable PCI/PCIE */ #define CONFIG_PCI11 /* PCI controller 1 */ -#define CONFIG_PCIE1 1 /* PCIE controler 1 (slot 1) */ -#define CONFIG_PCIE2 1 /* PCIE controler 2 (slot 2) */ -#define CONFIG_PCIE3 1 /* PCIE controler 3 (ULI bridge) */ +#define CONFIG_PCIE1 1 /* PCIE controller 1 (slot 1) */ +#define CONFIG_PCIE2 1 /* PCIE controller 2 (slot 2) */ +#define CONFIG_PCIE3 1 /* PCIE controller 3 (ULI bridge) */ #define CONFIG_FSL_PCI_INIT1 /* Use common FSL init code */ #define CONFIG_PCI_INDIRECT_BRIDGE 1 /* indirect PCI bridge support */ #define CONFIG_FSL_PCIE_RESET 1 /* need PCIe reset errata */ diff --git a/include/configs/MPC8548CDS.h b/include/configs/MPC8548CDS.h index dd07dc4..5de8b19 100644 --- a/include/configs/MPC8548CDS.h +++ b/include/configs/MPC8548CDS.h @@ -34,7 +34,7 @@ #define CONFIG_PCI /* enable any pci type devices */ #define CONFIG_PCI1/* PCI controller 1 */ -#define CONFIG_PCIE1 /* PCIE controler 1 (slot 1) */ +#define CONFIG_PCIE1 /* PCIE controller 1 (slot 1) */ #undef CONFIG_PCI2 #define CONFIG_FSL_PCI_INIT1 /* Use common FSL init code */ #define CONFIG_PCI_INDIRECT_BRIDGE 1 /* indirect PCI bridge support */ diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h index 9144f32..8c4e5e2 100644 --- a/include/configs/MPC8572DS.h +++ b/include/configs/MPC8572DS.h @@ -40,9 +40,9 @@ #define CONFIG_FSL_ELBC1 /* Has Enhanced localbus controller */ #define CONFIG_PCI 1 /* Enable PCI/PCIE */ -#define CONFIG_PCIE1 1 /* PCIE c
Re: [U-Boot] speaking of fixing spelling mistakes and stuff like that ...
On Tue, 3 May 2016, Tom Rini wrote: > On Tue, May 03, 2016 at 06:47:02PM -0400, Robert P. J. Day wrote: > > > > sounds reasonable ... i'll keep tabs on the schedule and try to > > remember to send them all in during that window. i've already got a > > collection. > > "today" is the day, next Monday is release :) Thanks! ack ... early tomorrow morning. promise. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] speaking of fixing spelling mistakes and stuff like that ...
On Tue, May 03, 2016 at 06:47:02PM -0400, Robert P. J. Day wrote: > On Tue, 3 May 2016, Tom Rini wrote: > > > On Tue, May 03, 2016 at 06:17:08AM -0400, Robert P. J. Day wrote: > > > > > as i dig through the u-boot code, i frequently run across spelling > > > mistakes and other apparently non-functional issues, but i don't want > > > to pollute the list with patch after patch of trivial fixups, so i > > > started a local git branch called "typos" to which i add these things > > > and, eventually, i'll just send it in as one big patch, which inspires > > > two questions. > > > > > > first, is it still considered bad form to submit patches which might > > > touch numerous subsystems all over the code base? certainly, actual > > > functional changes shouldn't do that, but what about aesthetic fixes? > > > is it still necessary to CC each subsystem maintainer affected if > > > there are, like, a dozen of them? (whenever i find a particular typo, > > > i do a code-wide grep to nail all of them and add all of them to the > > > typos branch, so i could find them all over the place.) what to do? > > > > > > and second, is it worth (like the kernel folks do) adding a > > > "trivial" branch (in kernel case, email "triv...@kernel.org"), which > > > could collect trivial things like this off to the side, and eventually > > > just add it all as one big patch? > > > > > > i'm happy to send in typo fixes, but i have no interest in > > > generating all that churn if there's a better way. > > > > In my mind, the best time to submit a whole bunch of just typo fixes > > (esp that do not change a CONFIG name/value) is in the last two > > weeks before the release. Why? Because I'm not going to take any > > other big changes in so these aren't going to possibly conflict with > > what other people are doing. Other people doing big series changes > > inside of git for the next release should be able to pull these > > changes in and have git figure out the right thing. > > sounds reasonable ... i'll keep tabs on the schedule and try to > remember to send them all in during that window. i've already got a > collection. "today" is the day, next Monday is release :) Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] speaking of fixing spelling mistakes and stuff like that ...
On Tue, 3 May 2016, Tom Rini wrote: > On Tue, May 03, 2016 at 06:17:08AM -0400, Robert P. J. Day wrote: > > > as i dig through the u-boot code, i frequently run across spelling > > mistakes and other apparently non-functional issues, but i don't want > > to pollute the list with patch after patch of trivial fixups, so i > > started a local git branch called "typos" to which i add these things > > and, eventually, i'll just send it in as one big patch, which inspires > > two questions. > > > > first, is it still considered bad form to submit patches which might > > touch numerous subsystems all over the code base? certainly, actual > > functional changes shouldn't do that, but what about aesthetic fixes? > > is it still necessary to CC each subsystem maintainer affected if > > there are, like, a dozen of them? (whenever i find a particular typo, > > i do a code-wide grep to nail all of them and add all of them to the > > typos branch, so i could find them all over the place.) what to do? > > > > and second, is it worth (like the kernel folks do) adding a > > "trivial" branch (in kernel case, email "triv...@kernel.org"), which > > could collect trivial things like this off to the side, and eventually > > just add it all as one big patch? > > > > i'm happy to send in typo fixes, but i have no interest in > > generating all that churn if there's a better way. > > In my mind, the best time to submit a whole bunch of just typo fixes > (esp that do not change a CONFIG name/value) is in the last two > weeks before the release. Why? Because I'm not going to take any > other big changes in so these aren't going to possibly conflict with > what other people are doing. Other people doing big series changes > inside of git for the next release should be able to pull these > changes in and have git figure out the right thing. sounds reasonable ... i'll keep tabs on the schedule and try to remember to send them all in during that window. i've already got a collection. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-net.git master
Hi Tom, Here are the bug fixes for this release. The following changes since commit e96e064f51139c4af39f14499564ef76e40bbc29: usb: dwc2: Init desc_before_addr (2016-05-03 19:21:18 +0200) are available in the git repository at: git://git.denx.de/u-boot-net.git master for you to fetch changes up to 700877a62bfa88ef6e0267749db49f4dc63e2ea2: net: increase maximum frame size to accomediate VLAN packets (2016-05-03 17:52:12 -0500) Lev Iserovich (1): fdt: fix setting MAC addresses for multiple interfaces Prabhakar Kushwaha (1): drivers: net: ldpaa: Memset pools_params as "0" before use Stefan Agner (2): net: fix vlan validation net: increase maximum frame size to accomediate VLAN packets common/fdt_support.c | 20 ++-- drivers/net/ldpaa_eth/ldpaa_eth.c | 1 + include/env_flags.h | 4 ++-- include/net.h | 16 +--- 4 files changed, 22 insertions(+), 19 deletions(-) Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Tue, May 3, 2016 at 4:34 PM, Tom Rini wrote: > On Tue, May 03, 2016 at 03:01:10PM -0500, Joe Hershberger wrote: > >> Hi Tom, >> >> I left out my semantic patch changes for now since spatch does not generate >> well-formatted multi-line function definitions. I'm looking into improving >> the >> tool, but ocaml is not a language that I'm familiar with. >> >> The following changes since commit e7fbcbc2566ab4bbcb07889a5791972ac49fa407: >> >> igep00x0: Use the SRAM available for SPL. (2016-05-03 12:17:13 -0400) >> >> are available in the git repository at: >> >> git://git.denx.de/u-boot-net.git master >> >> for you to fetch changes up to f0973c9e75deddbde92b6e18187d1ee9b814cf5c: >> >> net: phy: dp83867: Add SGMII helper for configuration (2016-05-03 14:39:35 >> -0500) > > OK, we're less than a week from release. Which things here are > important bugfixes we need for the release? Thanks! Ah, damn... time flies. I'll send a new PR limited to bug fixes and push the rest to next. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Tue, May 03, 2016 at 03:01:10PM -0500, Joe Hershberger wrote: > Hi Tom, > > I left out my semantic patch changes for now since spatch does not generate > well-formatted multi-line function definitions. I'm looking into improving the > tool, but ocaml is not a language that I'm familiar with. > > The following changes since commit e7fbcbc2566ab4bbcb07889a5791972ac49fa407: > > igep00x0: Use the SRAM available for SPL. (2016-05-03 12:17:13 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-net.git master > > for you to fetch changes up to f0973c9e75deddbde92b6e18187d1ee9b814cf5c: > > net: phy: dp83867: Add SGMII helper for configuration (2016-05-03 14:39:35 > -0500) OK, we're less than a week from release. Which things here are important bugfixes we need for the release? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Tue, May 03, 2016 at 08:04:31PM +0200, Marek Vasut wrote: > Hi, > > this stuff is for 2016.05, it's a bunch of fixes. > > The following changes since commit e7fbcbc2566ab4bbcb07889a5791972ac49fa407: > > igep00x0: Use the SRAM available for SPL. (2016-05-03 12:17:13 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to e96e064f51139c4af39f14499564ef76e40bbc29: > > usb: dwc2: Init desc_before_addr (2016-05-03 19:21:18 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: qemu: Move qfw command over to cmd and add Kconfig entry
On Tue, May 03, 2016 at 10:33:38AM +0800, Miao Yan wrote:
> Hi Tom,
>
> 2016-04-30 9:39 GMT+08:00 Tom Rini :
> > - Move the command portion of arch/x86/cpu/qemu/fw_cfg.c into
> > cmd/qemu_fw_cfg.c
> > - Move arch/x86/include/asm/fw_cfg.h to include/qemu_fw_cfg.h
> > - Rename ACPI table portion to arch/x86/cpu/qemu/acpi_table.c
> >
> > Signed-off-by: Tom Rini
> > ---
> > The QEMU firmware interface is more generic feature than just x86/qemu so
> > we need to start by moving the code out of arch/x86 and into cmd
> >
> > arch/x86/cpu/mp_init.c | 2 +-
> > arch/x86/cpu/qemu/Makefile | 3 +-
> > arch/x86/cpu/qemu/acpi_table.c | 243
> >
> > arch/x86/cpu/qemu/cpu.c| 2 +-
> > arch/x86/cpu/qemu/qemu.c | 2 +-
> > arch/x86/lib/acpi_table.c | 2 +-
> > cmd/Kconfig| 6 +
> > cmd/Makefile | 1 +
> > arch/x86/cpu/qemu/fw_cfg.c => cmd/qemu_fw_cfg.c| 245
> > +
> > configs/qemu-x86_defconfig | 1 +
> > .../include/asm/fw_cfg.h => include/qemu_fw_cfg.h | 5 +
> > 11 files changed, 271 insertions(+), 241 deletions(-)
> > create mode 100644 arch/x86/cpu/qemu/acpi_table.c
> > rename arch/x86/cpu/qemu/fw_cfg.c => cmd/qemu_fw_cfg.c (53%)
> > rename arch/x86/include/asm/fw_cfg.h => include/qemu_fw_cfg.h (94%)
> >
> > diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
> > index 2604a68..13bec7a 100644
> > --- a/arch/x86/cpu/mp_init.c
> > +++ b/arch/x86/cpu/mp_init.c
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -21,7 +22,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile
> > index 6eeddf1..97b965c 100644
> > --- a/arch/x86/cpu/qemu/Makefile
> > +++ b/arch/x86/cpu/qemu/Makefile
> > @@ -7,4 +7,5 @@
> > ifndef CONFIG_EFI_STUB
> > obj-y += car.o dram.o
> > endif
> > -obj-y += cpu.o fw_cfg.o qemu.o
> > +obj-y += cpu.o qemu.o
> > +obj-$(CONFIG_QEMU_ACPI_TABLE) += acpi_table.o
> > diff --git a/arch/x86/cpu/qemu/acpi_table.c b/arch/x86/cpu/qemu/acpi_table.c
> > new file mode 100644
> > index 000..49381ac
> > --- /dev/null
> > +++ b/arch/x86/cpu/qemu/acpi_table.c
> > @@ -0,0 +1,243 @@
> > +/*
> > + * (C) Copyright 2015 Miao Yan
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/*
> > + * This function allocates memory for ACPI tables
> > + *
> > + * @entry : BIOS linker command entry which tells where to allocate memory
> > + * (either high memory or low memory)
> > + * @addr : The address that should be used for low memory allcation. If
> > the
> > + * memory allocation request is 'ZONE_HIGH' then this parameter
> > will
> > + * be ignored.
> > + * @return: 0 on success, or negative value on failure
> > + */
> > +static int bios_linker_allocate(struct bios_linker_entry *entry, u32 *addr)
> > +{
> > + uint32_t size, align;
> > + struct fw_file *file;
> > + unsigned long aligned_addr;
> > +
> > + align = le32_to_cpu(entry->alloc.align);
> > + /* align must be power of 2 */
> > + if (align & (align - 1)) {
> > + printf("error: wrong alignment %u\n", align);
> > + return -EINVAL;
> > + }
> > +
> > + file = qemu_fwcfg_find_file(entry->alloc.file);
> > + if (!file) {
> > + printf("error: can't find file %s\n", entry->alloc.file);
> > + return -ENOENT;
> > + }
> > +
> > + size = be32_to_cpu(file->cfg.size);
> > +
> > + /*
> > +* ZONE_HIGH means we need to allocate from high memory, since
> > +* malloc space is already at the end of RAM, so we directly use it.
> > +* If allocation zone is ZONE_FSEG, then we use the 'addr' passed
> > +* in which is low memory
> > +*/
> > + if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_HIGH) {
> > + aligned_addr = (unsigned long)memalign(align, size);
> > + if (!aligned_addr) {
> > + printf("error: allocating resource\n");
> > + return -ENOMEM;
> > + }
> > + } else if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG)
> > {
> > + aligned_addr = ALIGN(*addr, align);
> > + } else {
> > + printf("error: invalid allocation zone\n");
> > + return -EINVAL;
> > + }
> > +
> > + debug("bios_linker_allocate: allocate file %s,
Re: [U-Boot] [PATCH] dfu: avoid memory leak
On Tue, May 03, 2016 at 10:24:52AM +0800, Peng Fan wrote: > When dfu_fill_entity fail, need to free dfu to avoid memory leak. > > Reported by Coverity: > " > Resource leak (RESOURCE_LEAK) > leaked_storage: Variable dfu going out of scope leaks the storage > it points to. > " > > Signed-off-by: Peng Fan > Cc: "Łukasz Majewski" > Cc: Marek Vasut Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: gadget: dfu: discard dead code
On Tue, May 03, 2016 at 10:25:22AM +0800, Peng Fan wrote: > Reported by Coverity: > Logically dead code (DEADCODE) > dead_error_line: Execution cannot reach this statement: > (f_dfu->strings + --i).s = > > If calloc failed, i is still 0 and no need to call free, > so discard the dead code. > > Signed-off-by: Peng Fan > Cc: "Łukasz Majewski" > Cc: Marek Vasut Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] ath79: fix some minor defects
On 04/15/2016 01:19 PM, Daniel Schwierzeck wrote: > > > Am 12.04.2016 um 05:09 schrieb Wills Wang: >> >> These series of patch based on top of mips/next, it fix some defects on >> the previous patch series "add support for atheros ath79 based SOCs". >> >> >> Wills Wang (4): >> ath79: spi: Remove the explicit pinctrl setting >> ar933x: serial: Remove the explicit pinctrl setting >> ath79: ar933x: use BIT macro for bit shift operation >> ath79: add readonly attribute for ath79_soc_desc >> >> arch/mips/mach-ath79/ar933x/ddr.c | 14 +++--- >> arch/mips/mach-ath79/cpu.c| 8 >> drivers/serial/serial_ar933x.c| 16 ++-- >> drivers/spi/ath79_spi.c | 12 >> 4 files changed, 13 insertions(+), 37 deletions(-) >> > > all four patches applied to u-boot-mips/next, thanks! > Can you please update next on top of u-boot/master , so I can submit the ar9344 ? Thanks! -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mkimage: Add a quiet mode
Hi Simon,
On Sun, May 1, 2016 at 2:55 PM, Simon Glass wrote:
> Some build systems want to be quiet unless there is a problem. At present
> mkimage displays quite a bit of information when generating a FIT file. Add
> a '-q' flag to silence this.
>
> Signed-off-by: Simon Glass
Acked-by: Joe Hershberger
With one nit below...
> ---
>
> tools/imagetool.c | 3 ++-
> tools/imagetool.h | 1 +
> tools/mkimage.c | 5 -
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/tools/imagetool.c b/tools/imagetool.c
> index 916ab96..08d191d 100644
> --- a/tools/imagetool.c
> +++ b/tools/imagetool.c
> @@ -51,7 +51,8 @@ int imagetool_verify_print_header(
> * successful
> */
> if ((*curr)->print_header) {
> - (*curr)->print_header(ptr);
> + if (!params->quiet)
This test should be before the test for print_header being NULL above.
It would be silly to get an error saying that print_header is
undefined when you just asked to not call it.
> + (*curr)->print_header(ptr);
> } else {
> fprintf(stderr,
> "%s: print_header undefined
> for %s\n",
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 04/29/2016 09:58 AM, Diego wrote: > In data venerdì 29 aprile 2016 00:49:22, Marek Vasut ha scritto: >> >> Urgh, so you seem to have third revision of this stick. I have two >> sticks which are exactly the same and work in U-Boot on MX6 wandboard: >> > > Hi Marek, > > how big is the file you're trying to load? > For me it fails for files bigger than 16MB: Ha ok, I see it now. According to the bus analyzer, the stick Acks long block transfer, but then just times out, I guess because it prepares the data or something. Just a dummy question, did you try reducing USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work. > U-Boot > usb info > 1: Hub, USB Revision 2.0 > - u-boot EHCI Host Controller > - Class: Hub > - PacketSize: 64 Configurations: 1 > - Vendor: 0x Product 0x Version 1.0 >Configuration: 1 >- Interfaces: 1 Self Powered 0mA > Interface: 0 > - Alternate Setting 0, Endpoints: 1 > - Class Hub > - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms > > 2: Hub, USB Revision 2.0 > - Class: Hub > - PacketSize: 64 Configurations: 1 > - Vendor: 0x0424 Product 0x2513 Version 11.179 >Configuration: 1 >- Interfaces: 1 Self Powered Remote Wakeup 2mA > Interface: 0 > - Alternate Setting 0, Endpoints: 1 > - Class Hub > - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms > - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms > > 3: Mass Storage, USB Revision 2.0 > - Kingston DataTraveler SE9 0019E06B084BFD10470133E8 > - Class: (from Interface) Mass Storage > - PacketSize: 64 Configurations: 1 > - Vendor: 0x0951 Product 0x1689 Version 1.0 >Configuration: 1 >- Interfaces: 1 Bus Powered 100mA > Interface: 0 > - Alternate Setting 0, Endpoints: 2 > - Class Mass Storage, Transp. SCSI, Bulk only > - Endpoint 1 In Bulk MaxPacket 512 > - Endpoint 2 Out Bulk MaxPacket 512 > > U-Boot > load usb 0:1 0x10008000 file1.raw > reading file1.raw > 1048576 bytes read in 59 ms (16.9 MiB/s) > U-Boot > load usb 0:1 0x10008000 file2.raw > reading file2.raw > 2097152 bytes read in 102 ms (19.6 MiB/s) > U-Boot > load usb 0:1 0x10008000 file4.raw > reading file4.raw > 4194304 bytes read in 175 ms (22.9 MiB/s) > U-Boot > load usb 0:1 0x10008000 file6.raw > reading file6.raw > 6291456 bytes read in 255 ms (23.5 MiB/s) > U-Boot > load usb 0:1 0x10008000 file8.raw > reading file8.raw > 8388608 bytes read in 334 ms (24 MiB/s) > U-Boot > load usb 0:1 0x10008000 file10.raw > reading file10.raw > 10485760 bytes read in 408 ms (24.5 MiB/s) > U-Boot > load usb 0:1 0x10008000 file15.raw > reading file15.raw > 15728640 bytes read in 603 ms (24.9 MiB/s) > U-Boot > load usb 0:1 0x10008000 file16.raw > reading file16.raw > EHCI timed out on TD - token=0x90008d80 > EHCI timed out on TD - token=0x10008d80 > EHCI timed out on TD - token=0x10008d80 > Error reading cluster > ** Unable to read file file16.raw ** > U-Boot > load usb 0:1 0x10008000 file20.raw > reading file20.raw > EHCI timed out on TD - token=0xd0008d80 > EHCI timed out on TD - token=0x50008d80 > EHCI timed out on TD - token=0x50008d80 > Error reading cluster > ** Unable to read file file20.raw ** > U-Boot > load usb 0:1 0x10008000 file40.raw > reading file40.raw > EHCI timed out on TD - token=0x1e008d80 > EHCI timed out on TD - token=0x1e008d80 > EHCI timed out on TD - token=0x1e008d80 > Error reading cluster > ** Unable to read file file40.raw ** > U-Boot > > > Bests, > Diego > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/12] drivers: core: device: add support to check dt compatible for a device/machine
Hi Mugunthan,
On 3 May 2016 at 09:36, Mugunthan V N wrote:
>
> On Monday 02 May 2016 12:24 AM, Simon Glass wrote:
> > Hi Mugunthan,
> >
> > On 28 April 2016 at 04:06, Mugunthan V N wrote:
> >> Provide an api to check whether the given device or machine is
> >> compatible with the given compat string which helps in making
> >> decisions in drivers based on device or machine compatible.
> >>
> >> Idea taken from Linux.
> >>
> >> Signed-off-by: Mugunthan V N
> >> Reviewed-by: Joe Hershberger
> >> ---
> >> drivers/core/device.c | 14 ++
> >> include/dm/device.h | 23 +++
> >> 2 files changed, 37 insertions(+)
> >>
> >> diff --git a/drivers/core/device.c b/drivers/core/device.c
> >> index 1322991..8fdd193 100644
> >> --- a/drivers/core/device.c
> >> +++ b/drivers/core/device.c
> >> @@ -715,3 +715,17 @@ int device_set_name(struct udevice *dev, const char
> >> *name)
> >>
> >> return 0;
> >> }
> >> +
> >> +bool of_device_is_compatible(struct udevice *dev, const char *compat)
> >
> > This function is in device.h, so I think device_is_compatible() is a
> > better name. Where does compat come from? Is it another device, or
> > something else entirely?
>
> I have used the funtion names as is from the kernel so that porting
> kernel driver to U-boot will be easier.
>
> The compat comes from the driver which uses the API, compat is the
> device compatible string like "ti,am3517-emac"
OK, please update the function comment. Also what do you think about
adding a new of.h /of.c files to hold this function prototype? I
really want to keep the APIs clean.
>
> >
> >> +{
> >> + const void *fdt = gd->fdt_blob;
> >> +
> >> + return !fdt_node_check_compatible(fdt, dev->of_offset, compat);
> >> +}
> >> +
> >> +bool of_machine_is_compatible(const char *compat)
> >
> > This should go in fdtdec.h I think. It doesn't have anything to do
> > with devices. So fdtdec_machine_is_compatible().
>
> I have used the funtion names as is from the kernel so that porting
> kernel driver to U-boot will be easier.
Does one function really matter? In that case, it should still go in
fdtdec, you can keep the of_ prefix. Perhaps we should use that more
generally. My reason for not is that the current fdtdec API is not the
same as of_. It uses (const void *blob, int offset) instead of (struct
of_node *node), etc.
>
> >
> >> +{
> >> + const void *fdt = gd->fdt_blob;
> >> +
> >> + return !fdt_node_check_compatible(fdt, 0, compat);
> >> +}
> >> diff --git a/include/dm/device.h b/include/dm/device.h
> >> index 8970fc0..cd18e82 100644
> >> --- a/include/dm/device.h
> >> +++ b/include/dm/device.h
> >> @@ -532,6 +532,29 @@ bool device_is_last_sibling(struct udevice *dev);
> >> int device_set_name(struct udevice *dev, const char *name);
> >>
> >> /**
> >> + * of_device_is_compatible() - check if the device is compatible with the
> >> compat
> >> + *
> >> + * This allows to check whether the device is comaptible with the compat.
> >> + *
> >> + * @dev: udevice pointer for which compatible needs to be verified.
> >> + * @compat:Compatible string which needs to verified in the given
> >> + * device
> >> + * @return true if OK, false if the compatible is not found
> >
> > Does this mean false if @compat is not found in the device's
> > compatible string list? Can you beef up the comment a bit to be
> > specific?
>
> Yes, return true if compatible is found. Will modify like below.
>
> @return true if the compatible is found, false if the compatible is not
> found
>
> >
> >> + */
> >> +bool of_device_is_compatible(struct udevice *dev, const char *compat);
> >> +
> >> +/**
> >> + * of_machine_is_compatible() - check if the machine is compatible with
> >> + * the compat
> >> + *
> >> + * This allows to check whether the machine is comaptible with the compat.
> >
> > Again can you beef up the comment? What is machine? Where does it actually
> > look?
> >
>
> Will do.
>
> >> + *
> >> + * @compat:Compatible string which needs to verified
> >> + * @return true if OK, false if the compatible is not found
> >> + */
> >> +bool of_machine_is_compatible(const char *compat);
> >> +
> >> +/**
> >> * device_is_on_pci_bus - Test if a device is on a PCI bus
> >> *
> >> * @dev: device to test
> >> --
> >> 2.8.1.339.g3ad15fd
> >>
> >
>
> Regards
> Mugunthan V N
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver model
On Tue, May 3, 2016 at 1:40 AM, Simon Glass wrote:
> Add driver-model support to this driver. The old code remains for now so
> that we can convert boards one at a time.
>
> Signed-off-by: Simon Glass
Acked-by: Joe Hershberger
But with a nit...
> ---
> +static const struct eth_ops macb_eth_ops = {
> + .start = macb_start,
> + .send = macb_send,
> + .recv = macb_recv,
> + .stop = macb_stop,
> + .free_pkt = macb_free_pkt,
> + .write_hwaddr = macb_write_hwaddr,
> +};
> +
> +static int macb_eth_probe(struct udevice *dev)
> +{
> + struct eth_pdata *pdata = dev_get_platdata(dev);
> + struct macb_device *macb = dev_get_priv(dev);
> +
> + macb->regs = (void *)pdata->iobase;
> +
> + _macb_eth_initialize(macb);
> +#if defined(CONFIG_CMD_MII) || defined(CONFIG_PHYLIB)
> + miiphy_register(dev->name, macb_miiphy_read, macb_miiphy_write);
It's unfortunate that you're proliferating the oldest phy API. My
semantic patch can come along and clean it up later as long as this is
in before I run it again.
> + macb->bus = miiphy_get_dev_by_name(dev->name);
> +#endif
> +
> + return 0;
> +}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] usb: hub: Increase the query delay
Increase the query delay, otherwise some sticks are not detected. The problem shows up on the USB bus analyzer such that the stick takes longer time to switch from FS mode to HS mode than the code allows. Signed-off-by: Marek Vasut Cc: Chin Liang See Cc: Dinh Nguyen Cc: Hans de Goede Cc: Stefan Roese Cc: Stephen Warren --- common/usb_hub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/usb_hub.c b/common/usb_hub.c index 0f39c9f..6cd274a 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -145,7 +145,7 @@ static void usb_hub_power_on(struct usb_hub_device *hub) * Do a minimum delay of the larger value of 100ms or pgood_delay * so that the power can stablize before the devices are queried */ - hub->query_delay = get_timer(0) + max(100, (int)pgood_delay); + hub->query_delay = get_timer(0) + max(1000, (int)pgood_delay); /* * Record the power-on timeout here. The max. delay (timeout) -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] usb: Assure Get Descriptor request is in separate microframe
The Kingston DT Ultimate USB 3.0 stick is sensitive to this first
Get Descriptor request and if the request is not in a separate
microframe, the stick refuses to operate. Add slight delay, which
is enough for one microframe to pass on any USB spec revision.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Hans de Goede
Cc: Stefan Roese
Cc: Stephen Warren
---
common/usb.c | 8
1 file changed, 8 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index 205041b..8d9efe5 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1077,6 +1077,14 @@ int usb_select_config(struct usb_device *dev)
le16_to_cpus(&dev->descriptor.idProduct);
le16_to_cpus(&dev->descriptor.bcdDevice);
+ /*
+* Kingston DT Ultimate 32GB USB 3.0 seems to be extremely sensitive
+* about this first Get Descriptor request. If there are any other
+* requests in the first microframe, the stick crashes. Wait about
+* one microframe duration here (1mS for USB 1.x , 125uS for USB 2.0).
+*/
+ mdelay(1);
+
/* only support for one config for now */
err = usb_get_configuration_len(dev, 0);
if (err >= 0) {
--
2.7.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] usb: dwc2: Resend setup packet in all fail cases
The USB function can respond to a Setup packet with ACK or, in
case it's busy, it can ignore the Setup packet. The USB function
usually gets busy if we hammer it with Control EP transfers too
much (ie. sending multiple Get Descriptor requests in a single
microframe tends to trigger it on certain USB sticks). The DWC2
controller will interpret not receiving an ACK after Setup packet
as XACTERR. Check for this condition and if it happens, retry
sending the Setup packet.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Hans de Goede
Cc: Stefan Roese
Cc: Stephen Warren
---
drivers/usb/host/dwc2.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 30b51b3..8d3949e 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -737,6 +737,7 @@ int wait_for_chhltd(struct dwc2_hc_regs *hc_regs, uint32_t
*sub, u8 *toggle)
{
int ret;
uint32_t hcint, hctsiz;
+ u8 pid = *toggle;
ret = wait_for_bit(__func__, &hc_regs->hcint, DWC2_HCINT_CHHLTD, true,
1000, false);
@@ -758,6 +759,19 @@ int wait_for_chhltd(struct dwc2_hc_regs *hc_regs, uint32_t
*sub, u8 *toggle)
if (hcint & (DWC2_HCINT_NAK | DWC2_HCINT_FRMOVRUN))
return -EAGAIN;
+ /*
+* The USB function can respond to a Setup packet with ACK or, in
+* case it's busy, it can ignore the Setup packet. The USB function
+* usually gets busy if we hammer it with Control EP transfers too
+* much (ie. sending multiple Get Descriptor requests in a single
+* microframe tends to trigger it on certain USB sticks). The DWC2
+* controller will interpret not receiving an ACK after Setup packet
+* as XACTERR. Check for this condition and if it happens, retry
+* sending the Setup packet.
+*/
+ if (hcint & DWC2_HCINT_XACTERR && (pid == DWC2_HC_PID_SETUP))
+ return -EAGAIN;
+
debug("%s: Error (HCINT=%08x)\n", __func__, hcint);
return -EINVAL;
}
--
2.7.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] usb: hub: Don't continue on get_port_status failure
The code shouldn't continue probing the port if get_port_status() failed. Signed-off-by: Marek Vasut Cc: Chin Liang See Cc: Dinh Nguyen Cc: Hans de Goede Cc: Stefan Roese Cc: Stephen Warren --- common/usb_hub.c | 1 + 1 file changed, 1 insertion(+) diff --git a/common/usb_hub.c b/common/usb_hub.c index 4f59802..0f39c9f 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -402,6 +402,7 @@ static int usb_scan_port(struct usb_device_scan *usb_scan) free(usb_scan); return 0; } + return 0; } portstatus = le16_to_cpu(portsts->wPortStatus); -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] usb: Wait after sending Set Configuration request
Some devices, like the SanDisk Cruzer Pop need some time to process
the Set Configuration request, so wait a little until they are ready.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Hans de Goede
Cc: Stefan Roese
Cc: Stephen Warren
---
common/usb.c | 8
1 file changed, 8 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index 63429d4..205041b 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1107,6 +1107,14 @@ int usb_select_config(struct usb_device *dev)
"len %d, status %lX\n", dev->act_len, dev->status);
return err;
}
+
+ /*
+* Wait until the Set Configuration request gets processed by the
+* device. This is required by at least SanDisk Cruzer Pop USB 2.0
+* and Kingston DT Ultimate 32GB USB 3.0 on DWC2 OTG controller.
+*/
+ mdelay(10);
+
debug("new device strings: Mfr=%d, Product=%d, SerialNumber=%d\n",
dev->descriptor.iManufacturer, dev->descriptor.iProduct,
dev->descriptor.iSerialNumber);
--
2.7.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] usb: dwc2: Throttle the setup packet resending
Abort the request in case any of the tokens in the packet failed to
complete transfer 10 times. This is a precaution needed so that we
don't end in endless loop when scanning the bus with some braindead
devices.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Hans de Goede
Cc: Stefan Roese
Cc: Stephen Warren
---
drivers/usb/host/dwc2.c | 44
1 file changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 8d3949e..27fcf7c 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -993,6 +993,8 @@ static int _submit_control_msg(struct dwc2_priv *priv,
struct usb_device *dev,
u8 pid;
/* For CONTROL endpoint pid should start with DATA1 */
int status_direction;
+ int againctr = 0;
+ const int againmax = 10;
if (devnum == priv->root_hub_devnum) {
dev->status = 0;
@@ -1003,25 +1005,37 @@ static int _submit_control_msg(struct dwc2_priv *priv,
struct usb_device *dev,
/* SETUP stage */
pid = DWC2_HC_PID_SETUP;
- do {
+ againctr = 0;
+ while (true) {
ret = chunk_msg(priv, dev, pipe, &pid, 0, setup, 8);
- } while (ret == -EAGAIN);
- if (ret)
- return ret;
+ if (!ret)
+ break;
+ if (ret != -EAGAIN)
+ return ret;
+ if (againctr == againmax)
+ return -EINVAL;
+ againctr++;
+ };
/* DATA stage */
act_len = 0;
if (buffer) {
pid = DWC2_HC_PID_DATA1;
- do {
+ againctr = 0;
+ while (true) {
ret = chunk_msg(priv, dev, pipe, &pid, usb_pipein(pipe),
buffer, len);
act_len += dev->act_len;
buffer += dev->act_len;
len -= dev->act_len;
- } while (ret == -EAGAIN);
- if (ret)
- return ret;
+ if (!ret)
+ break;
+ if (ret != -EAGAIN)
+ return ret;
+ if (againctr == againmax)
+ return -EINVAL;
+ againctr++;
+ };
status_direction = usb_pipeout(pipe);
} else {
/* No-data CONTROL always ends with an IN transaction */
@@ -1030,12 +1044,18 @@ static int _submit_control_msg(struct dwc2_priv *priv,
struct usb_device *dev,
/* STATUS stage */
pid = DWC2_HC_PID_DATA1;
- do {
+ againctr = 0;
+ while (true) {
ret = chunk_msg(priv, dev, pipe, &pid, status_direction,
priv->status_buffer, 0);
- } while (ret == -EAGAIN);
- if (ret)
- return ret;
+ if (!ret)
+ break;
+ if (ret != -EAGAIN)
+ return ret;
+ if (againctr == againmax)
+ return -EINVAL;
+ againctr++;
+ };
dev->act_len = act_len;
--
2.7.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] usb: Don't init pointer to zero, but NULL
The pointer should always be inited to NULL, not zero (0). These are
two different things and not necessarily equal.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Hans de Goede
Cc: Stefan Roese
Cc: Stephen Warren
---
common/usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/usb.c b/common/usb.c
index 4d0de4d..63429d4 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1064,7 +1064,7 @@ static int usb_prepare_device(struct usb_device *dev, int
addr, bool do_read,
int usb_select_config(struct usb_device *dev)
{
- unsigned char *tmpbuf = 0;
+ unsigned char *tmpbuf = NULL;
int err;
err = get_descriptor_len(dev, USB_DT_DEVICE_SIZE, USB_DT_DEVICE_SIZE);
--
2.7.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/18] net: macb: Flush correct cache portion when sending
On Tue, May 3, 2016 at 1:40 AM, Simon Glass wrote: > The end address of the cache flush must be cache-line-aligned since > otherwise (at least on ARM926-EJS) the request is ignored. When the cache > is enabled this means that packets are not sent. > > Signed-off-by: Simon Glass 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] fdt: fix setting MAC addresses for multiple interfaces
Hi Lev,
On Mon, May 2, 2016 at 11:01 AM, Lev Iserovich
wrote:
> Hi,
>
> Updated with C-style comments:
>
> For multiple ethernet interfaces the FDT offset of '/aliases' will change as
> we
> are adding MAC addresses to the FDT.
> Therefore only the first interface ('ethernet0') will get properly updated
> in
> the FDT, with the rest getting FDT errors when we try to set their MAC
> address.
>
> Signed-off-by: Lev Iserovich
> ---
>
> Changes in v2:
>- Rebase on u-boot-net patches:
> http://patchwork.ozlabs.org/patch/539373/
> http://patchwork.ozlabs.org/patch/539374/
>- Recompute offset based on property index
>- C-style comments
I had already applied your previous patch with a few minor
adjustments. Please look at what's in my tree and send a patch on top
of that if you care to make further improvements.
Also, you might want to consider using tools/patman/patman when
working on patches and sending to the list.
Thanks,
-Joe
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commitdiff;h=f383f32d5568a3a1a4d31efa97f5cf991961a5e8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/18] net: macb: Prepare for driver-model conversion
On Tue, May 3, 2016 at 1:39 AM, Simon Glass wrote: > Adjust this driver to avoid using struct netdev in functions that driver > model will call. Also refactor the receive function to be compatible with > driver model. > > Signed-off-by: Simon Glass 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 03/18] bootm: Align cache flush end address correctly
On Tue, May 3, 2016 at 1:39 AM, Simon Glass wrote: > Flushing part of the cache should be done on cache boundaries. Trying to > flush part of a cache line is not supported and the request may be ignored > or print warnings. > > Adjust the bootm code to align the end address to prevent this problem. > > Signed-off-by: Simon Glass Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/18] arm: Allow skipping of low-level init with I-cache on
On Tue, May 3, 2016 at 1:39 AM, Simon Glass wrote: > At present CONFIG_SKIP_LOWLEVEL_INIT prevents U-Boot from calling > lowlevel_init(). This means that the instruction cache is not enabled and > the board runs very slowly. > > What is really needed in many cases is to skip the call to lowlevel_init() > but still perform CP15 init. Add an option to handle this. > > Signed-off-by: Simon Glass Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/18] net: Handle an empty bootp extension section
On Tue, May 3, 2016 at 1:39 AM, Simon Glass wrote: > Avoid generating this section if there is nothing in it. > > Signed-off-by: Simon Glass Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-net.git master
Hi Tom, I left out my semantic patch changes for now since spatch does not generate well-formatted multi-line function definitions. I'm looking into improving the tool, but ocaml is not a language that I'm familiar with. The following changes since commit e7fbcbc2566ab4bbcb07889a5791972ac49fa407: igep00x0: Use the SRAM available for SPL. (2016-05-03 12:17:13 -0400) are available in the git repository at: git://git.denx.de/u-boot-net.git master for you to fetch changes up to f0973c9e75deddbde92b6e18187d1ee9b814cf5c: net: phy: dp83867: Add SGMII helper for configuration (2016-05-03 14:39:35 -0500) Dan Murphy (7): drivers: net: cpsw: Add reading of DT phy-handle node net: zynq_gem: Add the passing of the phy-handle node net: phy: dp83867: Add device tree bindings and documentation net: phy: ti: Allow the driver to be more configurable net: phy: Move is_rgmii helper to phy.h net: phy: Add phy_interface_is_sgmii to phy.h net: phy: dp83867: Add SGMII helper for configuration Kevin Smith (2): net: Remove unused mv88e61xx switch driver net: phy: Add PHY driver for mv88e61xx switches Lev Iserovich (1): fdt: fix setting MAC addresses for multiple interfaces Mugunthan V N (12): drivers: core: device: add support to check dt compatible for a device/machine ti_omap5_common: eth: do not define DM_ETH for spl drivers: net: cpsw: fix cpsw dp parse when num slaves as 1 ARM: omap5: add platform specific ethernet phy modes configurations drivers: net: cpsw: fix get mdio base and gmii_sel reg from DT drivers: net: cpsw: add support for reading mac address from efuse arm: dts: am4372: add syscon node to cpsw to read mac address arm: dts: dra7: add syscon node to cpsw to read mac address arm: dts: dra7: fix ethernet name with proper device address defconfig: am437x_gp_evm: enable eth driver model defconfig: am437x_sk_evm: enable eth driver model defconfig: dra74_evm: enable eth driver model Prabhakar Kushwaha (1): drivers: net: ldpaa: Memset pools_params as "0" before use Stefan Agner (2): net: fix vlan validation net: increase maximum frame size to accomediate VLAN packets arch/arm/dts/am4372.dtsi|1 + arch/arm/dts/dra7.dtsi |3 +- arch/arm/include/asm/arch-omap5/cpu.h | 12 + common/fdt_support.c| 20 +- configs/am437x_gp_evm_defconfig |1 + configs/am437x_sk_evm_defconfig |1 + configs/dra74_evm_defconfig |1 + doc/device-tree-bindings/net/ti,dp83867.txt | 25 + drivers/core/device.c | 14 + drivers/net/Makefile|2 +- drivers/net/cpsw-common.c | 121 +++ drivers/net/cpsw.c | 77 +- drivers/net/ldpaa_eth/ldpaa_eth.c |1 + drivers/net/phy/mv88e61xx.c | 1322 ++- drivers/net/phy/mv88e61xx.h | 61 -- drivers/net/phy/phy.c |3 + drivers/net/phy/ti.c| 88 +- drivers/net/zynq_gem.c | 15 +- include/configs/ti_omap5_common.h |1 + include/cpsw.h |2 + include/dm/device.h | 23 + include/dt-bindings/net/ti-dp83867.h| 35 + include/env_flags.h |4 +- include/net.h | 16 +- include/netdev.h| 58 -- include/phy.h | 23 + 26 files changed, 1322 insertions(+), 608 deletions(-) create mode 100644 doc/device-tree-bindings/net/ti,dp83867.txt create mode 100644 drivers/net/cpsw-common.c delete mode 100644 drivers/net/phy/mv88e61xx.h create mode 100644 include/dt-bindings/net/ti-dp83867.h Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] drivers: net: cpsw: fix cpsw dp parse when num slaves as 1
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616100/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: omap5: add platform specific ethernet phy modes configurations
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616101/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: phy: Add phy_interface_is_sgmii to phy.h
Hi Dan, https://patchwork.ozlabs.org/patch/617695/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: phy: dp83867: Add SGMII helper for configuration
Hi Dan, https://patchwork.ozlabs.org/patch/617699/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: phy: Move is_rgmii helper to phy.h
Hi Dan, https://patchwork.ozlabs.org/patch/617694/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: phy: ti: Allow the driver to be more configurable
Hi Dan, https://patchwork.ozlabs.org/patch/617692/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: phy: dp83867: Add device tree bindings and documentation
Hi Dan, https://patchwork.ozlabs.org/patch/617691/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: zynq_gem: Add the passing of the phy-handle node
Hi Dan, https://patchwork.ozlabs.org/patch/617696/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] defconfig: dra74_evm: enable eth driver model
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616109/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] drivers: net: cpsw: Add reading of DT phy-handle node
Hi Dan, https://patchwork.ozlabs.org/patch/617693/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] defconfig: am437x_gp_evm: enable eth driver model
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616107/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] defconfig: am437x_sk_evm: enable eth driver model
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616108/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: dts: dra7: add syscon node to cpsw to read mac address
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616104/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] drivers: net: cpsw: add support for reading mac address from efuse
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616103/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: dts: dra7: fix ethernet name with proper device address
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616105/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: dts: am4372: add syscon node to cpsw to read mac address
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616106/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] drivers: net: cpsw: fix get mdio base and gmii_sel reg from DT
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616102/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: increase maximum frame size to accomediate VLAN packets
Hi Stefan, https://patchwork.ozlabs.org/patch/610318/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ti_omap5_common: eth: do not define DM_ETH for spl
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616099/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] drivers: core: device: add support to check dt compatible for a device/machine
Hi Mugunthan, https://patchwork.ozlabs.org/patch/616098/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: fix vlan validation
Hi Stefan, https://patchwork.ozlabs.org/patch/610319/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: phy: Add PHY driver for mv88e61xx switches
Hi Kevin, https://patchwork.ozlabs.org/patch/604278/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: Remove unused mv88e61xx switch driver
Hi Kevin, https://patchwork.ozlabs.org/patch/604277/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fdt: fix setting MAC addresses for multiple interfaces
Hi Lev, https://patchwork.ozlabs.org/patch/564594/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] drivers: net: ldpaa: Memset pools_params as "0" before use
Hi Prabhakar, https://patchwork.ozlabs.org/patch/602416/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] speaking of fixing spelling mistakes and stuff like that ...
On Tue, May 03, 2016 at 06:17:08AM -0400, Robert P. J. Day wrote: > as i dig through the u-boot code, i frequently run across spelling > mistakes and other apparently non-functional issues, but i don't want > to pollute the list with patch after patch of trivial fixups, so i > started a local git branch called "typos" to which i add these things > and, eventually, i'll just send it in as one big patch, which inspires > two questions. > > first, is it still considered bad form to submit patches which might > touch numerous subsystems all over the code base? certainly, actual > functional changes shouldn't do that, but what about aesthetic fixes? > is it still necessary to CC each subsystem maintainer affected if > there are, like, a dozen of them? (whenever i find a particular typo, > i do a code-wide grep to nail all of them and add all of them to the > typos branch, so i could find them all over the place.) what to do? > > and second, is it worth (like the kernel folks do) adding a > "trivial" branch (in kernel case, email "triv...@kernel.org"), which > could collect trivial things like this off to the side, and eventually > just add it all as one big patch? > > i'm happy to send in typo fixes, but i have no interest in > generating all that churn if there's a better way. In my mind, the best time to submit a whole bunch of just typo fixes (esp that do not change a CONFIG name/value) is in the last two weeks before the release. Why? Because I'm not going to take any other big changes in so these aren't going to possibly conflict with what other people are doing. Other people doing big series changes inside of git for the next release should be able to pull these changes in and have git figure out the right thing. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
On Tue, May 03, 2016 at 01:37:41PM -0500, Derald Woods wrote:
> On Sun, May 1, 2016 at 12:09 PM, Derald D. Woods
> wrote:
>
> > On 05/01/2016 08:58 AM, Tom Rini wrote:
> >
> >> On Sat, Apr 30, 2016 at 07:12:28PM -0500, Derald D. Woods wrote:
> >>
> >>> On 04/28/2016 06:34 PM, Tom Rini wrote:
> >>>
> On Thu, Apr 28, 2016 at 05:55:17PM -0500, Adam Ford wrote:
>
> I am hoping to look at this tomorrow at work. Any suggested toolchain
> > you
> > recommend?
> >
> gcc-4.9.x fails (too large), gcc-5.3.x succeeds, gcc-6.x is also likely
> fine but I haven't started using those SDKs I just made today.
>
> >>> Hi Tom,
> >>>
> >>> Using gcc-5.3.0, for 'omap3_logic', I get the following:
> >>>
> >>> ---8<--
> >>> arm-cortexa8-linux-gnueabihf-ld.bfd: u-boot-spl section `.data' will
> >>> not fit in region `.sram'
> >>> arm-cortexa8-linux-gnueabihf-ld.bfd: region `.sram' overflowed by 948
> >>> bytes
> >>> ---8<--
> >>>
> >> That's odd, 5.3.1 from debian/unstable works.
> >>
> >> I built the compiler today with crosstool-ng.
> >>>
> >>> gcc version 5.3.0 (crosstool-NG crosstool-ng-1.22.0-134-ge1d494a)
> >>>
> >>> What things could/should be removed, from the configuration, to
> >>> avoid these kinds of things in the future?
> >>>
> >>> I would expect that the default board configuration to be less
> >>> sensitive, in general. I guess I want to know what is the right size
> >>> for an OMAP3 with SPL enabled.
> >>>
> >>> Changing compilers, just for this, can cause quite a ripple on
> >>> projects and the products that are supported by them.
> >>>
> >> So, the first thing to do would be to please try the following patch:
> >>
> >> diff --git a/arch/arm/include/asm/arch-omap3/omap.h
> >> b/arch/arm/include/asm/arch-omap3/omap.h
> >> index bc0e02a..6cef323 100644
> >> --- a/arch/arm/include/asm/arch-omap3/omap.h
> >> +++ b/arch/arm/include/asm/arch-omap3/omap.h
> >> @@ -145,7 +145,7 @@ struct gpio {
> >> #define NON_SECURE_SRAM_START 0x40208000 /* Works for
> >> GP & EMU */
> >> #define NON_SECURE_SRAM_END 0x4021
> >> -#define SRAM_SCRATCH_SPACE_ADDR0x4020E000
> >> +#define SRAM_SCRATCH_SPACE_ADDR0x4020F000
> >> #define LOW_LEVEL_SRAM_STACK0x4020FFFC
> >> diff --git a/doc/SPL/README.omap3 b/doc/SPL/README.omap3
> >> index c77ca43..cc54afe 100644
> >> --- a/doc/SPL/README.omap3
> >> +++ b/doc/SPL/README.omap3
> >> @@ -33,8 +33,9 @@ SRAM: 0x4020 - 0x4020
> >> DDR1: 0x8000 - 0xBFFF
> >> Option 1 (SPL only):
> >> -0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
> >> -0x4020E000 - 0x4020FFFC: Area for the SPL stack.
> >> +0x40200800 - 0x4020EFFF: Area for SPL text, data and rodata
> >> +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*)
> >> +0x4020FCB0 - 0x4020: Area for the SPL stack
> >> 0x8000 - 0x8007: Area for the SPL BSS.
> >> 0x8010: CONFIG_SYS_TEXT_BASE of U-Boot
> >> 0x80208000 - 0x80307FFF: malloc() pool available to SPL.
> >> @@ -42,6 +43,7 @@ Option 1 (SPL only):
> >> Option 2 (SPL or X-Loader):
> >> 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
> >> 0x4020E000 - 0x4020FFFC: Area for the SPL stack.
> >> +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*)
> >> 0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot
> >> 0x8700 - 0x8707: Area for the SPL BSS.
> >> 0x8708 - 0x870F: malloc() pool available to SPL.
> >> diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h
> >> index 6c79643..ed03e07 100644
> >> --- a/include/configs/omap3_logic.h
> >> +++ b/include/configs/omap3_logic.h
> >> @@ -28,13 +28,11 @@
> >> #define CONFIG_SYS_SPL_MALLOC_START 0x80208000
> >> #define CONFIG_SYS_SPL_MALLOC_SIZE0x10
> >> -#include
> >> /* Override default SPL info to minimize empty space and allow BCH8
> >> in SPL */
> >> -#undef CONFIG_SPL_TEXT_BASE
> >> -#undef CONFIG_SPL_MAX_SIZE
> >> #define CONFIG_SPL_TEXT_BASE 0x4020
> >> -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR -
> >> CONFIG_SPL_TEXT_BASE)
> >> +
> >> +#include
> >> /* Display CPU and Board information */
> >> diff --git a/include/configs/omap3_overo.h
> >> b/include/configs/omap3_overo.h
> >> index fbd0c2a..289c8e9 100644
> >> --- a/include/configs/omap3_overo.h
> >> +++ b/include/configs/omap3_overo.h
> >> @@ -10,11 +10,8 @@
> >> #define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be
> >> populated */
> >> #define CONFIG_NAND
> >> -#include
> >> -#undef CONFIG_SPL_MAX_SIZE
> >> -#undef CONFIG_SPL_TEXT_BASE
> >> #define CONFIG_SPL_TEXT_BASE 0x4020
> >> -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR -
> >> CONFIG_SPL_TEXT_BASE)
> >> +#include
> >> #define CONFIG_BCH
> >> diff --git a/include/configs/ti_omap3_common.h
> >> b/inclu
Re: [U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size
On Sun, May 1, 2016 at 12:09 PM, Derald D. Woods
wrote:
> On 05/01/2016 08:58 AM, Tom Rini wrote:
>
>> On Sat, Apr 30, 2016 at 07:12:28PM -0500, Derald D. Woods wrote:
>>
>>> On 04/28/2016 06:34 PM, Tom Rini wrote:
>>>
On Thu, Apr 28, 2016 at 05:55:17PM -0500, Adam Ford wrote:
I am hoping to look at this tomorrow at work. Any suggested toolchain
> you
> recommend?
>
gcc-4.9.x fails (too large), gcc-5.3.x succeeds, gcc-6.x is also likely
fine but I haven't started using those SDKs I just made today.
>>> Hi Tom,
>>>
>>> Using gcc-5.3.0, for 'omap3_logic', I get the following:
>>>
>>> ---8<--
>>> arm-cortexa8-linux-gnueabihf-ld.bfd: u-boot-spl section `.data' will
>>> not fit in region `.sram'
>>> arm-cortexa8-linux-gnueabihf-ld.bfd: region `.sram' overflowed by 948
>>> bytes
>>> ---8<--
>>>
>> That's odd, 5.3.1 from debian/unstable works.
>>
>> I built the compiler today with crosstool-ng.
>>>
>>> gcc version 5.3.0 (crosstool-NG crosstool-ng-1.22.0-134-ge1d494a)
>>>
>>> What things could/should be removed, from the configuration, to
>>> avoid these kinds of things in the future?
>>>
>>> I would expect that the default board configuration to be less
>>> sensitive, in general. I guess I want to know what is the right size
>>> for an OMAP3 with SPL enabled.
>>>
>>> Changing compilers, just for this, can cause quite a ripple on
>>> projects and the products that are supported by them.
>>>
>> So, the first thing to do would be to please try the following patch:
>>
>> diff --git a/arch/arm/include/asm/arch-omap3/omap.h
>> b/arch/arm/include/asm/arch-omap3/omap.h
>> index bc0e02a..6cef323 100644
>> --- a/arch/arm/include/asm/arch-omap3/omap.h
>> +++ b/arch/arm/include/asm/arch-omap3/omap.h
>> @@ -145,7 +145,7 @@ struct gpio {
>> #define NON_SECURE_SRAM_START 0x40208000 /* Works for
>> GP & EMU */
>> #define NON_SECURE_SRAM_END 0x4021
>> -#define SRAM_SCRATCH_SPACE_ADDR0x4020E000
>> +#define SRAM_SCRATCH_SPACE_ADDR0x4020F000
>> #define LOW_LEVEL_SRAM_STACK0x4020FFFC
>> diff --git a/doc/SPL/README.omap3 b/doc/SPL/README.omap3
>> index c77ca43..cc54afe 100644
>> --- a/doc/SPL/README.omap3
>> +++ b/doc/SPL/README.omap3
>> @@ -33,8 +33,9 @@ SRAM: 0x4020 - 0x4020
>> DDR1: 0x8000 - 0xBFFF
>> Option 1 (SPL only):
>> -0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
>> -0x4020E000 - 0x4020FFFC: Area for the SPL stack.
>> +0x40200800 - 0x4020EFFF: Area for SPL text, data and rodata
>> +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*)
>> +0x4020FCB0 - 0x4020: Area for the SPL stack
>> 0x8000 - 0x8007: Area for the SPL BSS.
>> 0x8010: CONFIG_SYS_TEXT_BASE of U-Boot
>> 0x80208000 - 0x80307FFF: malloc() pool available to SPL.
>> @@ -42,6 +43,7 @@ Option 1 (SPL only):
>> Option 2 (SPL or X-Loader):
>> 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
>> 0x4020E000 - 0x4020FFFC: Area for the SPL stack.
>> +0x4020F000 - 0x4020FCAF: Area for scratch space (see OMAP_SRAM_SCRATCH*)
>> 0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot
>> 0x8700 - 0x8707: Area for the SPL BSS.
>> 0x8708 - 0x870F: malloc() pool available to SPL.
>> diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h
>> index 6c79643..ed03e07 100644
>> --- a/include/configs/omap3_logic.h
>> +++ b/include/configs/omap3_logic.h
>> @@ -28,13 +28,11 @@
>> #define CONFIG_SYS_SPL_MALLOC_START 0x80208000
>> #define CONFIG_SYS_SPL_MALLOC_SIZE0x10
>> -#include
>> /* Override default SPL info to minimize empty space and allow BCH8
>> in SPL */
>> -#undef CONFIG_SPL_TEXT_BASE
>> -#undef CONFIG_SPL_MAX_SIZE
>> #define CONFIG_SPL_TEXT_BASE 0x4020
>> -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR -
>> CONFIG_SPL_TEXT_BASE)
>> +
>> +#include
>> /* Display CPU and Board information */
>> diff --git a/include/configs/omap3_overo.h
>> b/include/configs/omap3_overo.h
>> index fbd0c2a..289c8e9 100644
>> --- a/include/configs/omap3_overo.h
>> +++ b/include/configs/omap3_overo.h
>> @@ -10,11 +10,8 @@
>> #define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be
>> populated */
>> #define CONFIG_NAND
>> -#include
>> -#undef CONFIG_SPL_MAX_SIZE
>> -#undef CONFIG_SPL_TEXT_BASE
>> #define CONFIG_SPL_TEXT_BASE 0x4020
>> -#define CONFIG_SPL_MAX_SIZE(SRAM_SCRATCH_SPACE_ADDR -
>> CONFIG_SPL_TEXT_BASE)
>> +#include
>> #define CONFIG_BCH
>> diff --git a/include/configs/ti_omap3_common.h
>> b/include/configs/ti_omap3_common.h
>> index 32877d1..ffd695f 100644
>> --- a/include/configs/ti_omap3_common.h
>> +++ b/include/configs/ti_omap3_common.h
>> @@ -68,9 +68,17 @@
>> /* TWL4030 */
>> #define CONFIG_TWL4030_POWER
>> -/* SPL */
>> +/*
>> + * For SPL we say that our text base is at 0x40200
[U-Boot] [PULL] u-boot-usb/master
Hi, this stuff is for 2016.05, it's a bunch of fixes. The following changes since commit e7fbcbc2566ab4bbcb07889a5791972ac49fa407: igep00x0: Use the SRAM available for SPL. (2016-05-03 12:17:13 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to e96e064f51139c4af39f14499564ef76e40bbc29: usb: dwc2: Init desc_before_addr (2016-05-03 19:21:18 +0200) Marek Vasut (4): usb: dwc2: Pass private data into dwc_otg_core_init() usb: dwc2: Pull Ext VBUS macro from dwc_otg_core_init() usb: dwc2: Make OC protection configurable usb: dwc2: Init desc_before_addr drivers/usb/host/dwc2.c | 40 +++- 1 file changed, 31 insertions(+), 9 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] mtd: cqspi: Simplify indirect read code
The indirect read code is a pile of nastiness. This patch replaces
the whole unmaintainable indirect read implementation with the one
from upcoming Linux CQSPI driver, which went through multiple rounds
of thorough review and testing. All the patch does is it plucks out
duplicate ad-hoc code distributed across the driver and replaces it
with more compact code doing exactly the same thing. There is no
speed change of the read operation.
Signed-off-by: Marek Vasut
Cc: Anatolij Gustschin
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Jagan Teki
Cc: Pavel Machek
Cc: Stefan Roese
Cc: Vignesh R
---
V2: Handle non-4-byte aligned transfers
---
drivers/spi/cadence_qspi_apb.c | 128 ++---
1 file changed, 57 insertions(+), 71 deletions(-)
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 5e84144..a71531d 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -193,64 +193,6 @@ static unsigned int cadence_qspi_apb_cmd2addr(const
unsigned char *addr_buf,
return addr;
}
-static void cadence_qspi_apb_read_fifo_data(void *dest,
- const void *src_ahb_addr, unsigned int bytes)
-{
- unsigned int temp;
- int remaining = bytes;
- unsigned int *dest_ptr = (unsigned int *)dest;
- unsigned int *src_ptr = (unsigned int *)src_ahb_addr;
-
- while (remaining >= sizeof(dest_ptr)) {
- *dest_ptr = readl(src_ptr);
- remaining -= sizeof(src_ptr);
- dest_ptr++;
- }
- if (remaining) {
- /* dangling bytes */
- temp = readl(src_ptr);
- memcpy(dest_ptr, &temp, remaining);
- }
-
- return;
-}
-
-/* Read from SRAM FIFO with polling SRAM fill level. */
-static int qspi_read_sram_fifo_poll(const void *reg_base, void *dest_addr,
- const void *src_addr, unsigned int num_bytes)
-{
- unsigned int remaining = num_bytes;
- unsigned int retry;
- unsigned int sram_level = 0;
- unsigned char *dest = (unsigned char *)dest_addr;
-
- while (remaining > 0) {
- retry = CQSPI_REG_RETRY;
- while (retry--) {
- sram_level = CQSPI_GET_RD_SRAM_LEVEL(reg_base);
- if (sram_level)
- break;
- udelay(1);
- }
-
- if (!retry) {
- printf("QSPI: No receive data after polling for %d
times\n",
- CQSPI_REG_RETRY);
- return -1;
- }
-
- sram_level *= CQSPI_FIFO_WIDTH;
- sram_level = sram_level > remaining ? remaining : sram_level;
-
- /* Read data from FIFO. */
- cadence_qspi_apb_read_fifo_data(dest, src_addr, sram_level);
- dest += sram_level;
- remaining -= sram_level;
- udelay(1);
- }
- return 0;
-}
-
void cadence_qspi_apb_controller_enable(void *reg_base)
{
unsigned int reg;
@@ -679,40 +621,84 @@ int cadence_qspi_apb_indirect_read_setup(struct
cadence_spi_platdata *plat,
return 0;
}
+static u32 cadence_qspi_get_rd_sram_level(struct cadence_spi_platdata *plat)
+{
+ u32 reg = readl(plat->regbase + CQSPI_REG_SDRAMLEVEL);
+ reg >>= CQSPI_REG_SDRAMLEVEL_RD_LSB;
+ return reg & CQSPI_REG_SDRAMLEVEL_RD_MASK;
+}
+
+static int cadence_qspi_wait_for_data(struct cadence_spi_platdata *plat)
+{
+ unsigned int timeout = 1;
+ u32 reg;
+
+ while (timeout--) {
+ reg = cadence_qspi_get_rd_sram_level(plat);
+ if (reg)
+ return reg;
+ udelay(1);
+ }
+
+ return -ETIMEDOUT;
+}
+
int cadence_qspi_apb_indirect_read_execute(struct cadence_spi_platdata *plat,
- unsigned int rxlen, u8 *rxbuf)
+ unsigned int n_rx, u8 *rxbuf)
{
- unsigned int reg;
+ unsigned int remaining = n_rx;
+ unsigned int bytes_to_read = 0;
+ int ret;
- writel(rxlen, plat->regbase + CQSPI_REG_INDIRECTRDBYTES);
+ writel(n_rx, plat->regbase + CQSPI_REG_INDIRECTRDBYTES);
/* Start the indirect read transfer */
writel(CQSPI_REG_INDIRECTRD_START_MASK,
plat->regbase + CQSPI_REG_INDIRECTRD);
- if (qspi_read_sram_fifo_poll(plat->regbase, (void *)rxbuf,
-(const void *)plat->ahbbase, rxlen))
- goto failrd;
+ while (remaining > 0) {
+ ret = cadence_qspi_wait_for_data(plat);
+ if (ret < 0) {
+ printf("Indirect write timed out (%i)\n", ret);
+ goto failrd;
+ }
+
+ bytes_to_read = ret;
+
+ while (bytes_to_read != 0) {
+ bytes_to_read *= CQSPI_FIFO_WIDTH;
+ bytes_to_r
[U-Boot] [PATCH V2 1/2] mtd: cqspi: Simplify indirect write code
The indirect write code is buggy pile of nastiness which fails horribly
when the system runs fast enough to saturate the controller. The failure
results in some pages (256B) not being written to the flash. This can be
observed on systems which run with Dcache enabled and L2 cache enabled,
like the Altera SoCFPGA.
This patch replaces the whole unmaintainable indirect write implementation
with the one from upcoming Linux CQSPI driver, which went through multiple
rounds of thorough review and testing. While this makes the patch look
terrifying and violates all best-practices of software development, all
the patch does is it plucks out duplicate ad-hoc code distributed across
the driver and replaces it with more compact code doing exactly the same
thing.
Signed-off-by: Marek Vasut
Cc: Anatolij Gustschin
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Jagan Teki
Cc: Pavel Machek
Cc: Stefan Roese
Cc: Vignesh R
---
V2: Handle non-4-byte aligned transfers
---
drivers/spi/cadence_qspi_apb.c | 126 ++---
1 file changed, 30 insertions(+), 96 deletions(-)
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 7786dd6..5e84144 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "cadence_qspi.h"
#define CQSPI_REG_POLL_US (1) /* 1us */
@@ -214,32 +215,6 @@ static void cadence_qspi_apb_read_fifo_data(void *dest,
return;
}
-static void cadence_qspi_apb_write_fifo_data(const void *dest_ahb_addr,
- const void *src, unsigned int bytes)
-{
- unsigned int temp = 0;
- int i;
- int remaining = bytes;
- unsigned int *dest_ptr = (unsigned int *)dest_ahb_addr;
- unsigned int *src_ptr = (unsigned int *)src;
-
- while (remaining >= CQSPI_FIFO_WIDTH) {
- for (i = CQSPI_FIFO_WIDTH/sizeof(src_ptr) - 1; i >= 0; i--)
- writel(*(src_ptr+i), dest_ptr+i);
- src_ptr += CQSPI_FIFO_WIDTH/sizeof(src_ptr);
- remaining -= CQSPI_FIFO_WIDTH;
- }
- if (remaining) {
- /* dangling bytes */
- i = remaining/sizeof(dest_ptr);
- memcpy(&temp, src_ptr+i, remaining % sizeof(dest_ptr));
- writel(temp, dest_ptr+i);
- for (--i; i >= 0; i--)
- writel(*(src_ptr+i), dest_ptr+i);
- }
- return;
-}
-
/* Read from SRAM FIFO with polling SRAM fill level. */
static int qspi_read_sram_fifo_poll(const void *reg_base, void *dest_addr,
const void *src_addr, unsigned int num_bytes)
@@ -276,44 +251,6 @@ static int qspi_read_sram_fifo_poll(const void *reg_base,
void *dest_addr,
return 0;
}
-/* Write to SRAM FIFO with polling SRAM fill level. */
-static int qpsi_write_sram_fifo_push(struct cadence_spi_platdata *plat,
- const void *src_addr, unsigned int num_bytes)
-{
- const void *reg_base = plat->regbase;
- void *dest_addr = plat->ahbbase;
- unsigned int retry = CQSPI_REG_RETRY;
- unsigned int sram_level;
- unsigned int wr_bytes;
- unsigned char *src = (unsigned char *)src_addr;
- int remaining = num_bytes;
- unsigned int page_size = plat->page_size;
- unsigned int sram_threshold_words = CQSPI_REG_SRAM_THRESHOLD_WORDS;
-
- while (remaining > 0) {
- retry = CQSPI_REG_RETRY;
- while (retry--) {
- sram_level = CQSPI_GET_WR_SRAM_LEVEL(reg_base);
- if (sram_level <= sram_threshold_words)
- break;
- }
- if (!retry) {
- printf("QSPI: SRAM fill level (0x%08x) not hit lower
expected level (0x%08x)",
- sram_level, sram_threshold_words);
- return -1;
- }
- /* Write a page or remaining bytes. */
- wr_bytes = (remaining > page_size) ?
- page_size : remaining;
-
- cadence_qspi_apb_write_fifo_data(dest_addr, src, wr_bytes);
- src += wr_bytes;
- remaining -= wr_bytes;
- }
-
- return 0;
-}
-
void cadence_qspi_apb_controller_enable(void *reg_base)
{
unsigned int reg;
@@ -810,48 +747,45 @@ int cadence_qspi_apb_indirect_write_setup(struct
cadence_spi_platdata *plat,
}
int cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata *plat,
- unsigned int txlen, const u8 *txbuf)
+ unsigned int n_tx, const u8 *txbuf)
{
- unsigned int reg = 0;
- unsigned int retry;
+ unsigned int page_size = plat->page_size;
+ unsigned int remaining = n_tx;
+ unsigned int write_bytes;
+ int ret;
/* Configure the indirect read transfer bytes */
- writel(txlen
Re: [U-Boot] [PATCH 1/2] mtd: cqspi: Simplify indirect write code
On 05/03/2016 07:00 PM, Stefan Roese wrote:
> On 03.05.2016 18:53, Marek Vasut wrote:
>> On 05/02/2016 05:20 PM, Stefan Roese wrote:
>>> On 29.04.2016 12:13, Marek Vasut wrote:
> On 28.04.2016 00:36, Marek Vasut wrote:
>> The indirect write code is buggy pile of nastiness which fails
>> horribly
>> when the system runs fast enough to saturate the controller. The
>> failure
>> results in some pages (256B) not being written to the flash. This
>> can be
>> observed on systems which run with Dcache enabled and L2 cache
>> enabled,
>> like the Altera SoCFPGA.
>>
>> This patch replaces the whole unmaintainable indirect write
>> implementation
>> with the one from upcoming Linux CQSPI driver, which went through
>> multiple
>> rounds of thorough review and testing. While this makes the patch
>> look
>> terrifying and violates all best-practices of software
>> development, all
>> the patch does is it plucks out duplicate ad-hoc code distributed
>> across
>> the driver and replaces it with more compact code doing exactly
>> the same
>> thing.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Anatolij Gustschin
>> Cc: Chin Liang See
>> Cc: Dinh Nguyen
>> Cc: Jagan Teki
>> Cc: Pavel Machek
>> Cc: Stefan Roese
>> Cc: Vignesh R
>
> I've applied both patches and tested them on SR1500 (SPI-NOR used
> for booting and redundant environment). This is what I get upon
> "saveeenv":
>
> => saveenv
> Saving Environment to SPI Flash...
> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB,
> total 16 MiB
> Erasing SPI flash...Writing to SPI flash...data abort
> pc : [<3ff8368a>] lr : [<3ff8301b>]
> reloc pc : [<010216ca>]lr : [<0102105b>]
> sp : 3bf54eb8 ip : 3ff82f69 fp : 0002
> r10: r9 : 3bf5dee8 r8 :
> r7 : 0001 r6 : 3bf54f9b r5 : 0001 r4 : 3bf5e520
> r3 : r2 : 3bf54f9b r1 : 0001 r0 : ffa0
> Flags: nZCv IRQs off FIQs off Mode SVC_32
> Resetting CPU ...
>
> resetting ...
>
> U-Boot SPL 2016.05-rc3-9-ge1bf9b8 (Apr 29 2016 - 11:25:46)
>
>
> Any idea, what might be going wrong here?
Does it work without the patch ?
>>>
>>> Yes, of course. I wouldn't have posted as a reply to this patch
>>> if this is not the root cause.
>>
>> *grumble*
>
> ?
I just sensed slight USB subtext here ;-)
>>> The board is using SPI NOR for env storage from the beginning.
>>
>> It only happens if you use redundant env in SPI NOR.
>>
>>> Where does your PC point to at the time
of the crash ,which function is it ?
>>>
>>> Its in cadence_qspi_apb_indirect_write_execute().
>>>
>>> I debugged this issue a bit and found the following problem
>>> in cadence_qspi_apb_indirect_write_execute():
>>>
>>> saveenv issues a 1-byte SPI write transfer with a non 4-byte
>>> aligned txbuf. This causes the data-abort here. Here my small
>>> patch that fixes the problem:
>>
>> Thanks, see below.
>>
>>> diff --git a/drivers/spi/cadence_qspi_apb.c
>>> b/drivers/spi/cadence_qspi_apb.c
>>> index ac47c6f..021a3e8 100644
>>> --- a/drivers/spi/cadence_qspi_apb.c
>>> +++ b/drivers/spi/cadence_qspi_apb.c
>>> @@ -745,7 +745,15 @@ int
>>> cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
>>> *plat,
>>>
>>> while (remaining > 0) {
>>> write_bytes = remaining > page_size ? page_size :
>>> remaining;
>>> - writesl(plat->ahbbase, txbuf,
>>> DIV_ROUND_UP(write_bytes, 4));
>>> +
>>> + /*
>>> +* Handle non 4-byte aligned access differently to avoid
>>> +* data-aborts
>>> +*/
>>> + if (((u32)txbuf % 4) || (write_bytes % 4))
>>> + writesb(plat->ahbbase, txbuf, write_bytes);
>>> + else
>>> + writesl(plat->ahbbase, txbuf, write_bytes >> 2);
>>>
>>> ret = wait_for_bit("QSPI", plat->regbase +
>>> CQSPI_REG_SDRAMLEVEL,
>>> CQSPI_REG_SDRAMLEVEL_WR_MASK <<
>>>
>>>
>>> Please fell free to use this patch as-is and squash it into
>>> your patches or enhance it while doing this. The read function
>>> is also missing this unaligned handling.
>>
>> Im afraid of the performance hit that we can suffer if we use byte-level
>> access for every unaligned buffer.
>
> This is why is wrote: "or enhance it while doing this". You might want
> to change the code to first write the (optionally) unaligned bytes,
> then the aligned bytes via writesl() and last the (optionally) unaligned
> bytes.
>
>> What do you think
>> about using a bounce-buffer instead ?
>
> I would prefer the simple solution I've drafted above.
OK, I checked how many aligned and unaligned transfers happens and I
guess it's really not worth going through the bo
Re: [U-Boot] [PATCH 1/2] mtd: cqspi: Simplify indirect write code
On 03.05.2016 18:53, Marek Vasut wrote:
On 05/02/2016 05:20 PM, Stefan Roese wrote:
On 29.04.2016 12:13, Marek Vasut wrote:
On 28.04.2016 00:36, Marek Vasut wrote:
The indirect write code is buggy pile of nastiness which fails horribly
when the system runs fast enough to saturate the controller. The failure
results in some pages (256B) not being written to the flash. This can be
observed on systems which run with Dcache enabled and L2 cache enabled,
like the Altera SoCFPGA.
This patch replaces the whole unmaintainable indirect write implementation
with the one from upcoming Linux CQSPI driver, which went through multiple
rounds of thorough review and testing. While this makes the patch look
terrifying and violates all best-practices of software development, all
the patch does is it plucks out duplicate ad-hoc code distributed across
the driver and replaces it with more compact code doing exactly the same
thing.
Signed-off-by: Marek Vasut
Cc: Anatolij Gustschin
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Jagan Teki
Cc: Pavel Machek
Cc: Stefan Roese
Cc: Vignesh R
I've applied both patches and tested them on SR1500 (SPI-NOR used
for booting and redundant environment). This is what I get upon
"saveeenv":
=> saveenv
Saving Environment to SPI Flash...
SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
Erasing SPI flash...Writing to SPI flash...data abort
pc : [<3ff8368a>] lr : [<3ff8301b>]
reloc pc : [<010216ca>]lr : [<0102105b>]
sp : 3bf54eb8 ip : 3ff82f69 fp : 0002
r10: r9 : 3bf5dee8 r8 :
r7 : 0001 r6 : 3bf54f9b r5 : 0001 r4 : 3bf5e520
r3 : r2 : 3bf54f9b r1 : 0001 r0 : ffa0
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
U-Boot SPL 2016.05-rc3-9-ge1bf9b8 (Apr 29 2016 - 11:25:46)
Any idea, what might be going wrong here?
Does it work without the patch ?
Yes, of course. I wouldn't have posted as a reply to this patch
if this is not the root cause.
*grumble*
?
The board is using SPI NOR for env storage from the beginning.
It only happens if you use redundant env in SPI NOR.
Where does your PC point to at the time
of the crash ,which function is it ?
Its in cadence_qspi_apb_indirect_write_execute().
I debugged this issue a bit and found the following problem
in cadence_qspi_apb_indirect_write_execute():
saveenv issues a 1-byte SPI write transfer with a non 4-byte
aligned txbuf. This causes the data-abort here. Here my small
patch that fixes the problem:
Thanks, see below.
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index ac47c6f..021a3e8 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -745,7 +745,15 @@ int cadence_qspi_apb_indirect_write_execute(struct
cadence_spi_platdata *plat,
while (remaining > 0) {
write_bytes = remaining > page_size ? page_size : remaining;
- writesl(plat->ahbbase, txbuf, DIV_ROUND_UP(write_bytes, 4));
+
+ /*
+* Handle non 4-byte aligned access differently to avoid
+* data-aborts
+*/
+ if (((u32)txbuf % 4) || (write_bytes % 4))
+ writesb(plat->ahbbase, txbuf, write_bytes);
+ else
+ writesl(plat->ahbbase, txbuf, write_bytes >> 2);
ret = wait_for_bit("QSPI", plat->regbase +
CQSPI_REG_SDRAMLEVEL,
CQSPI_REG_SDRAMLEVEL_WR_MASK <<
Please fell free to use this patch as-is and squash it into
your patches or enhance it while doing this. The read function
is also missing this unaligned handling.
Im afraid of the performance hit that we can suffer if we use byte-level
access for every unaligned buffer.
This is why is wrote: "or enhance it while doing this". You might want
to change the code to first write the (optionally) unaligned bytes,
then the aligned bytes via writesl() and last the (optionally) unaligned
bytes.
What do you think
about using a bounce-buffer instead ?
I would prefer the simple solution I've drafted above.
And of course the Linux driver version as well.
Does linux use unaligned buffers internally ?
Frankly, I don't know for sure. But I suspect, that you can also
see unaligned buffers (and sizes!!!) in Linux as well. And you
can't just write a different amount of data to the SPI NOR, which
happens when you use DIV_ROUND_UP on an unaligned size.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mtd: cqspi: Simplify indirect write code
On 05/02/2016 05:20 PM, Stefan Roese wrote:
> On 29.04.2016 12:13, Marek Vasut wrote:
>>> On 28.04.2016 00:36, Marek Vasut wrote:
The indirect write code is buggy pile of nastiness which fails horribly
when the system runs fast enough to saturate the controller. The failure
results in some pages (256B) not being written to the flash. This can be
observed on systems which run with Dcache enabled and L2 cache enabled,
like the Altera SoCFPGA.
This patch replaces the whole unmaintainable indirect write implementation
with the one from upcoming Linux CQSPI driver, which went through multiple
rounds of thorough review and testing. While this makes the patch look
terrifying and violates all best-practices of software development, all
the patch does is it plucks out duplicate ad-hoc code distributed across
the driver and replaces it with more compact code doing exactly the same
thing.
Signed-off-by: Marek Vasut
Cc: Anatolij Gustschin
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Jagan Teki
Cc: Pavel Machek
Cc: Stefan Roese
Cc: Vignesh R
>>>
>>> I've applied both patches and tested them on SR1500 (SPI-NOR used
>>> for booting and redundant environment). This is what I get upon
>>> "saveeenv":
>>>
>>> => saveenv
>>> Saving Environment to SPI Flash...
>>> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16
>>> MiB
>>> Erasing SPI flash...Writing to SPI flash...data abort
>>> pc : [<3ff8368a>] lr : [<3ff8301b>]
>>> reloc pc : [<010216ca>]lr : [<0102105b>]
>>> sp : 3bf54eb8 ip : 3ff82f69 fp : 0002
>>> r10: r9 : 3bf5dee8 r8 :
>>> r7 : 0001 r6 : 3bf54f9b r5 : 0001 r4 : 3bf5e520
>>> r3 : r2 : 3bf54f9b r1 : 0001 r0 : ffa0
>>> Flags: nZCv IRQs off FIQs off Mode SVC_32
>>> Resetting CPU ...
>>>
>>> resetting ...
>>>
>>> U-Boot SPL 2016.05-rc3-9-ge1bf9b8 (Apr 29 2016 - 11:25:46)
>>>
>>>
>>> Any idea, what might be going wrong here?
>>
>> Does it work without the patch ?
>
> Yes, of course. I wouldn't have posted as a reply to this patch
> if this is not the root cause.
*grumble*
> The board is using SPI NOR for env storage from the beginning.
It only happens if you use redundant env in SPI NOR.
> Where does your PC point to at the time
>> of the crash ,which function is it ?
>
> Its in cadence_qspi_apb_indirect_write_execute().
>
> I debugged this issue a bit and found the following problem
> in cadence_qspi_apb_indirect_write_execute():
>
> saveenv issues a 1-byte SPI write transfer with a non 4-byte
> aligned txbuf. This causes the data-abort here. Here my small
> patch that fixes the problem:
Thanks, see below.
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> index ac47c6f..021a3e8 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -745,7 +745,15 @@ int cadence_qspi_apb_indirect_write_execute(struct
> cadence_spi_platdata *plat,
>
> while (remaining > 0) {
> write_bytes = remaining > page_size ? page_size : remaining;
> - writesl(plat->ahbbase, txbuf, DIV_ROUND_UP(write_bytes, 4));
> +
> + /*
> +* Handle non 4-byte aligned access differently to avoid
> +* data-aborts
> +*/
> + if (((u32)txbuf % 4) || (write_bytes % 4))
> + writesb(plat->ahbbase, txbuf, write_bytes);
> + else
> + writesl(plat->ahbbase, txbuf, write_bytes >> 2);
>
> ret = wait_for_bit("QSPI", plat->regbase +
> CQSPI_REG_SDRAMLEVEL,
>CQSPI_REG_SDRAMLEVEL_WR_MASK <<
>
>
> Please fell free to use this patch as-is and squash it into
> your patches or enhance it while doing this. The read function
> is also missing this unaligned handling.
Im afraid of the performance hit that we can suffer if we use byte-level
access for every unaligned buffer. What do you think
about using a bounce-buffer instead ?
> And of course the Linux driver version as well.
Does linux use unaligned buffers internally ?
> Thanks,
> Stefan
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] igep00x0: Use the SRAM available for SPL.
On Tue, May 03, 2016 at 08:59:24AM +0200, Enric Balletbo i Serra wrote: > From: Enric Balletbo i Serra > > Move CONFIG_SPL_TEXT_BASE down to 0x4020 and set CONFIG_SPL_MAX_SIZE > to (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE), so that it's clear > what the limit is. > > This will also help some compilers to fit all the code into the allocated > space. > > Signed-off-by: Enric Balletbo i Serra Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/12] drivers: core: device: add support to check dt compatible for a device/machine
On Monday 02 May 2016 12:24 AM, Simon Glass wrote:
> Hi Mugunthan,
>
> On 28 April 2016 at 04:06, Mugunthan V N wrote:
>> Provide an api to check whether the given device or machine is
>> compatible with the given compat string which helps in making
>> decisions in drivers based on device or machine compatible.
>>
>> Idea taken from Linux.
>>
>> Signed-off-by: Mugunthan V N
>> Reviewed-by: Joe Hershberger
>> ---
>> drivers/core/device.c | 14 ++
>> include/dm/device.h | 23 +++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git a/drivers/core/device.c b/drivers/core/device.c
>> index 1322991..8fdd193 100644
>> --- a/drivers/core/device.c
>> +++ b/drivers/core/device.c
>> @@ -715,3 +715,17 @@ int device_set_name(struct udevice *dev, const char
>> *name)
>>
>> return 0;
>> }
>> +
>> +bool of_device_is_compatible(struct udevice *dev, const char *compat)
>
> This function is in device.h, so I think device_is_compatible() is a
> better name. Where does compat come from? Is it another device, or
> something else entirely?
I have used the funtion names as is from the kernel so that porting
kernel driver to U-boot will be easier.
The compat comes from the driver which uses the API, compat is the
device compatible string like "ti,am3517-emac"
>
>> +{
>> + const void *fdt = gd->fdt_blob;
>> +
>> + return !fdt_node_check_compatible(fdt, dev->of_offset, compat);
>> +}
>> +
>> +bool of_machine_is_compatible(const char *compat)
>
> This should go in fdtdec.h I think. It doesn't have anything to do
> with devices. So fdtdec_machine_is_compatible().
I have used the funtion names as is from the kernel so that porting
kernel driver to U-boot will be easier.
>
>> +{
>> + const void *fdt = gd->fdt_blob;
>> +
>> + return !fdt_node_check_compatible(fdt, 0, compat);
>> +}
>> diff --git a/include/dm/device.h b/include/dm/device.h
>> index 8970fc0..cd18e82 100644
>> --- a/include/dm/device.h
>> +++ b/include/dm/device.h
>> @@ -532,6 +532,29 @@ bool device_is_last_sibling(struct udevice *dev);
>> int device_set_name(struct udevice *dev, const char *name);
>>
>> /**
>> + * of_device_is_compatible() - check if the device is compatible with the
>> compat
>> + *
>> + * This allows to check whether the device is comaptible with the compat.
>> + *
>> + * @dev: udevice pointer for which compatible needs to be verified.
>> + * @compat:Compatible string which needs to verified in the given
>> + * device
>> + * @return true if OK, false if the compatible is not found
>
> Does this mean false if @compat is not found in the device's
> compatible string list? Can you beef up the comment a bit to be
> specific?
Yes, return true if compatible is found. Will modify like below.
@return true if the compatible is found, false if the compatible is not
found
>
>> + */
>> +bool of_device_is_compatible(struct udevice *dev, const char *compat);
>> +
>> +/**
>> + * of_machine_is_compatible() - check if the machine is compatible with
>> + * the compat
>> + *
>> + * This allows to check whether the machine is comaptible with the compat.
>
> Again can you beef up the comment? What is machine? Where does it actually
> look?
>
Will do.
>> + *
>> + * @compat:Compatible string which needs to verified
>> + * @return true if OK, false if the compatible is not found
>> + */
>> +bool of_machine_is_compatible(const char *compat);
>> +
>> +/**
>> * device_is_on_pci_bus - Test if a device is on a PCI bus
>> *
>> * @dev: device to test
>> --
>> 2.8.1.339.g3ad15fd
>>
>
Regards
Mugunthan V N
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ELC Europe mini-summit?
On Mon, Apr 25, 2016 at 05:01:02PM -0400, Tom Rini wrote: > Hey all, > > So, ELC Europe has a location, and dates and a CFP deadline "soon": > http://events.linuxfoundation.org/events/embedded-linux-conference-europe > > Do we as a community wish to continue with our tradition of having > something co-located with ELC Europe? If so, now'ish is the time I need > to bring this up with Linux Foundation and ask. So, bad news. At this time Linux Foundation isn't able to offer us any space during ELC/IoT summit due to the size of the venue and colocation of the two conferences. I would strongly encourage folks that have a topic they wish to speak about to submit a paper to ELC itself and there's always the hallway track. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: fix generation of FIT image
On Tue, May 03, 2016 at 03:17:03PM +0200, Andreas Bießmann wrote: > Commit 7a439cadcf3192eb012a2432ca34670b676c74d2 broke generation of SPL > loadable FIT images (CONFIG_SPL_LOAD_FIT). > Fix it by removing the unnecessary storage of expected image type. This was a > left over of the previous implementation. It is not longer necessary since the > mkimage -b switch always has one parameter. > > Tested-by: Lokesh Vutla > Signed-off-by: Andreas Bießmann Thanks for the quick fix, applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/3] spl: Allow to load a FIT containing U-Boot from FS
On Tuesday 03 May 2016 06:29 PM, Michal Simek wrote:
> On 3.5.2016 11:05, Lokesh Vutla wrote:
>> This provides a way to load a FIT containing U-Boot and a selection of device
>> tree files from a File system. Making sure that all the reads and writes
>> are aligned to their respective needs.
>>
>> Signed-off-by: Lokesh Vutla
>> ---
>> - Assuming info->priv is used for passing filename for now and using this
>> for
>> detecting if it a fs read. If this is not preferred I can create a new
>> field
>> for filename.
>>
>> common/spl/spl_fit.c | 76
>> +---
>> include/spl.h| 10 +++
>> 2 files changed, 71 insertions(+), 15 deletions(-)
>>
>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>> index b1cfa97..d696354 100644
>> --- a/common/spl/spl_fit.c
>> +++ b/common/spl/spl_fit.c
>> @@ -82,6 +82,42 @@ static int spl_fit_select_fdt(const void *fdt, int
>> images, int *fdt_offsetp)
>> return -ENOENT;
>> }
>>
>> +static int get_aligned_image_offset(struct spl_load_info *info, int offset)
>> +{
>> +/*
>> + * If it is a FS read, get the first address before offset which is
>> + * aligned to ARCH_DMA_MINALIGN. If it is raw read return the
>> + * block number to which offset belongs.
>> + */
>> +if (info->priv)
>> +return offset & ~(ARCH_DMA_MINALIGN - 1);
>> +else
>
> remove this else.
Sure.
>
>> +return offset / info->bl_len;
>> +}
>> +
>> +static int get_aligned_image_overhead(struct spl_load_info *info, int
>> offset)
>> +{
>> +/*
>> + * If it is a FS read, get the difference between the offset and
>> + * the first address before offset which is aligned to
>> + * ARCH_DMA_MINALIGN. If it is raw read return the offset within the
>> + * block.
>> + */
>> +if (info->priv)
>> +return offset & (ARCH_DMA_MINALIGN - 1);
>> +else
>
> remove this else.
Sure.
>
>> +return offset % info->bl_len;
>> +}
>> +
>> +static int get_aligned_image_size(struct spl_load_info *info, int data_size,
>> + int offset)
>> +{
>> +if (info->priv)
>> +return data_size + get_aligned_image_overhead(info, offset);
>> +else
>
> remove this else.
Sure.
>
>
>> +return (data_size + info->bl_len - 1) / info->bl_len;
>> +}
>> +
>> int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void *fit)
>> {
>> int sectors;
>> @@ -91,7 +127,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong
>> sector, void *fit)
>> void *load_ptr;
>> int fdt_offset, fdt_len;
>> int data_offset, data_size;
>> -int base_offset;
>> +int base_offset, align_len;
>> int src_sector;
>> void *dst;
>>
>> @@ -117,8 +153,10 @@ int spl_load_simple_fit(struct spl_load_info *info,
>> ulong sector, void *fit)
>> * In fact the FIT has its own load address, but we assume it cannot
>> * be before CONFIG_SYS_TEXT_BASE.
>> */
>> -fit = (void *)(CONFIG_SYS_TEXT_BASE - size - info->bl_len);
>> -sectors = (size + info->bl_len - 1) / info->bl_len;
>> +align_len = ARCH_DMA_MINALIGN - 1;
>> +fit = (void *)((CONFIG_SYS_TEXT_BASE - size - info->bl_len -
>> +align_len) & ~align_len);
>
> Don't you want to use ALIGN macro here?
ALIGN() will return the next aligned address which is equal to:
fit = (void *)((CONFIG_SYS_TEXT_BASE - size - info->bl_len + align_len)
& ~align_len);
But here we need the previous aligned address so that we do not loose
any data.
Thanks and regards,
Lokesh
>
>> +sectors = get_aligned_image_size(info, size, 0);
>> count = info->read(info, sector, sectors, fit);
>> debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu\n",
>>sector, sectors, fit, count);
>> @@ -151,19 +189,23 @@ int spl_load_simple_fit(struct spl_load_info *info,
>> ulong sector, void *fit)
>> * byte will be at 'load'. This may mean we need to load it starting
>> * before then, since we can only read whole blocks.
>> */
>> -sectors = (data_size + info->bl_len - 1) / info->bl_len;
>> +sectors = get_aligned_image_size(info, data_size, data_offset);
>> data_offset += base_offset;
>> load_ptr = (void *)load;
>> debug("U-Boot size %x, data %p\n", data_size, load_ptr);
>> -dst = load_ptr - (data_offset % info->bl_len);
>> +dst = load_ptr;
>>
>> /* Read the image */
>> -src_sector = sector + data_offset / info->bl_len;
>> -debug("image: data_offset=%x, dst=%p, src_sector=%x, sectors=%x\n",
>> - data_offset, dst, src_sector, sectors);
>> +src_sector = sector + get_aligned_image_offset(info, data_offset);
>> +debug("Aligned image read: dst=%p, src_sector=%x, sectors=%x\n",
>> + dst, src_sector, sectors);
>> count = info->read(info, src_sector, sectors, dst);
>> if (count != sectors)
>> return
Re: [U-Boot] [PATCH v4 3/3] spl: Support loading a FIT from FAT FS
On Tuesday 03 May 2016 06:28 PM, Michal Simek wrote:
> On 3.5.2016 11:05, Lokesh Vutla wrote:
>> Detect a FIT when loading from a FAT File system and handle it using the
>> new FIT SPL support.
>>
>> Signed-off-by: Lokesh Vutla
>> ---
>> common/spl/spl_fat.c | 31 +--
>> 1 file changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
>> index d761b26..3788e4d 100644
>> --- a/common/spl/spl_fat.c
>> +++ b/common/spl/spl_fat.c
>> @@ -15,6 +15,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> static int fat_registered;
>>
>> @@ -39,6 +40,20 @@ static int spl_register_fat_device(struct blk_desc
>> *block_dev, int partition)
>> return err;
>> }
>>
>> +static ulong spl_fit_read(struct spl_load_info *load, ulong file_offset,
>> + ulong size, void *buf)
>> +{
>> +loff_t actread;
>> +int ret;
>> +char *filename = (char *)load->priv;
>> +
>> +ret = fat_read_file(filename, buf, file_offset, size, &actread);
>> +if (ret)
>> +return ret;
>> +else
>
> you can remove this else.
Sure. Will fix it in the next version.
Thanks and regards,
Lokesh
>
> Thanks,
> Michal
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: fix generation of FIT image
On Tuesday 03 May 2016 06:47 PM, Andreas Bießmann wrote:
> Commit 7a439cadcf3192eb012a2432ca34670b676c74d2 broke generation of SPL
> loadable FIT images (CONFIG_SPL_LOAD_FIT).
> Fix it by removing the unnecessary storage of expected image type. This was a
> left over of the previous implementation. It is not longer necessary since the
> mkimage -b switch always has one parameter.
Thanks for the Patch. This fixes the build with CONFIG_SPL_LOAD_FIT enabled.
Tested-by: Lokesh Vutla
Thanks and regards,
Lokesh
>
> Signed-off-by: Andreas Bießmann
> ---
>
> tools/mkimage.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/tools/mkimage.c b/tools/mkimage.c
> index b407aed..93d1c16 100644
> --- a/tools/mkimage.c
> +++ b/tools/mkimage.c
> @@ -133,10 +133,8 @@ static void process_args(int argc, char **argv)
> char *ptr;
> int type = IH_TYPE_INVALID;
> char *datafile = NULL;
> - int expecting;
> int opt;
>
> - expecting = IH_TYPE_COUNT; /* Unknown */
> while ((opt = getopt(argc, argv,
>"a:A:b:cC:d:D:e:Ef:Fk:K:ln:O:rR:sT:vVx")) != -1) {
> switch (opt) {
> @@ -154,8 +152,7 @@ static void process_args(int argc, char **argv)
> usage("Invalid architecture");
> break;
> case 'b':
> - expecting = IH_TYPE_FLATDT;
> - if (add_content(expecting, optarg)) {
> + if (add_content(IH_TYPE_FLATDT, optarg)) {
> fprintf(stderr,
> "%s: Out of memory adding content '%s'",
> params.cmdname, optarg);
> @@ -238,7 +235,6 @@ static void process_args(int argc, char **argv)
> show_image_types();
> usage("Invalid image type");
> }
> - expecting = type;
> break;
> case 'v':
> params.vflag++;
> @@ -254,7 +250,8 @@ static void process_args(int argc, char **argv)
> }
> }
>
> - if (optind < argc && expecting == type)
> + /* The last parameter is expected to be the imagefile */
> + if (optind < argc)
> params.imagefile = argv[optind];
>
> /*
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/18] at91: Convert Ethernet and LCD to driver model
This series is mainly designed to move the macb Ethernet to driver model, along with the LCD controller. It also includes a few fixes: - NAND with ECC doesn't build properly - The instruction cache is off by default - Ethernet macb doesn't send packets when the cache is enabled A Snapper 9G45-based board is used for this work. It includes an AT91SAM9G45 CPU so is a good test of driver model on this chip. Simon Glass (18): at91: Add support for the AT91 slow clock controller arm: Allow skipping of low-level init with I-cache on bootm: Align cache flush end address correctly net: Handle an empty bootp extension section net: macb: Prepare for driver-model conversion net: macb: Flush correct cache portion when sending net: macb: Convert to driver model arm: at91: dts: Bring in device tree file for AT91SAM9G45 arm: at91: Add a header file for the real-time clock at91: Correct NAND ECC register access at91: nand: Set up the ECC strength correctly mtd: nand: Drop a blank line in nand_wait() at91: Add driver-model GPIO devices for AT91SAM9G45 at91: mtd: nand: Add dev_warn() to correct build error in driver at91: video: Prepare for driver-model conversion at91: video: Support driver-model for the LCD driver fdt: Correct return value in fdtdec_decode_display_timing() arm: at91: Add support for gurnard README |5 + arch/arm/cpu/arm1136/start.S |2 + arch/arm/cpu/arm920t/start.S |3 +- arch/arm/cpu/arm926ejs/start.S |2 + arch/arm/cpu/arm946es/start.S |2 + arch/arm/cpu/armv7/start.S |5 +- arch/arm/cpu/sa1100/start.S|2 + arch/arm/dts/Makefile |1 + arch/arm/dts/at91sam9g45-gurnard.dts | 157 ++ arch/arm/dts/at91sam9g45.dtsi | 1335 ++ arch/arm/mach-at91/Kconfig |9 + .../mach-at91/arm926ejs/at91sam9m10g45_devices.c | 18 + arch/arm/mach-at91/include/mach/at91_rtc.h | 71 + arch/arm/mach-at91/include/mach/at91_sck.h | 21 + arch/arm/mach-at91/include/mach/at91sam9g45.h |1 + board/bluewater/gurnard/Kconfig| 12 + board/bluewater/gurnard/MAINTAINERS|6 + board/bluewater/gurnard/Makefile | 11 + board/bluewater/gurnard/gurnard.c | 449 board/bluewater/gurnard/splash_logo.h | 2619 common/bootm.c |2 +- configs/gurnard_defconfig | 19 + drivers/mtd/nand/atmel_nand.c |7 +- drivers/mtd/nand/nand_base.c |1 - drivers/net/macb.c | 320 ++- drivers/video/atmel_lcdfb.c| 197 +- include/atmel_lcd.h|9 + include/configs/snapper9g45.h | 156 ++ include/dt-bindings/clock/at91.h | 23 + include/dt-bindings/dma/at91.h | 52 + include/dt-bindings/pinctrl/at91.h | 40 + lib/fdtdec.c |2 +- net/bootp.c|9 + 33 files changed, 5449 insertions(+), 119 deletions(-) create mode 100644 arch/arm/dts/at91sam9g45-gurnard.dts create mode 100644 arch/arm/dts/at91sam9g45.dtsi create mode 100644 arch/arm/mach-at91/include/mach/at91_rtc.h create mode 100644 arch/arm/mach-at91/include/mach/at91_sck.h create mode 100644 board/bluewater/gurnard/Kconfig create mode 100644 board/bluewater/gurnard/MAINTAINERS create mode 100644 board/bluewater/gurnard/Makefile create mode 100644 board/bluewater/gurnard/gurnard.c create mode 100644 board/bluewater/gurnard/splash_logo.h create mode 100644 configs/gurnard_defconfig create mode 100644 include/configs/snapper9g45.h create mode 100644 include/dt-bindings/clock/at91.h create mode 100644 include/dt-bindings/dma/at91.h create mode 100644 include/dt-bindings/pinctrl/at91.h -- 2.8.0.rc3.226.g39d4020 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/3] spl: Allow to load a FIT containing U-Boot from FS
On Tuesday 03 May 2016 06:27 PM, Michal Simek wrote: > Hi, [..snip..] > > this is not working for me. I haven't had a time to look at it > but you might know where the problem is. > > Thanks, > Michal > > U-Boot SPL 2016.05-rc3-00067-g01d410633461-dirty (May 03 2016 - 14:43:30) > Trying to boot from MMC1 > reading u-boot.bin > reading u-boot.img > Found FIT > spl_fit_read: name u-boot.img, file_offset 0, size 44c, buf 7fffb40 > reading u-boot.img > spl_fit_read: error reading image u-boot.img, ret - 0 > fit read sector 0, sectors=1100, dst=07fffb40, count=1100 > data_offset=0, data_size=80310 > U-Boot size 80310, data 0800 > Aligned image read: dst=0800, src_sector=440, sectors=80310 > spl_fit_read: name u-boot.img, file_offset 440, size 80310, buf 800 > reading u-boot.img > spl_fit_read: error reading image u-boot.img, ret - 0 > image: dst=0800, data_offset=44c, size=80310 > Selecting config 'zynqmp-zcu102', fdt 'fdt@1' > FIT: Selected 'zynqmp-zcu102' > spl_fit_read: name u-boot.img, file_offset 80740, size 6603, buf 8080340 > reading u-boot.img > ** Unable to read file u-boot.img ** > spl_fit_read: error reading image u-boot.img, ret - -1 The error started here. It is able to detect fdt from fit header but not able to read it from file. If you don't mind can you tell me what is the size of the file u-boot.img? A dumb question: Can you confirm that on this same HEAD the RFC patch from you works fine? I verified this on 2 different platforms and worked fine. Lets see If I am missing any corner case. Thanks and regards, Lokesh > Aligned fdt read: dst 08080340, src_sector = 80740, sectors 6603 > reading u-boot.img > spl_load_image_fat: error reading image u-boot.img, err - -1 > SPL: failed to boot from all boot devices > ### ERROR ### Please RESET the board ### > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: sunxi: fix device tree name for Pine64+
Hi Peter, On 02/05/16 22:17, Peter Robinson wrote: > Fix the device tree name for the Pine64+ for the naming that's going > into the upstream kernel. While this is a proper observation, it will not help just to fix the name, as U-Boot's build process will look for matching files in the U-Boot tree as well. And the DT is obsolete as well. I have patches ready to fix this properly and will send them later today. Cheers, Andre. > Signed-off-by: Peter Robinson > --- > configs/pine64_plus_defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig > index 0494a9f..0977334 100644 > --- a/configs/pine64_plus_defconfig > +++ b/configs/pine64_plus_defconfig > @@ -4,7 +4,7 @@ CONFIG_MACH_SUN50I=y > CONFIG_DRAM_CLK=672 > CONFIG_DRAM_ZQ=3881915 > # CONFIG_VIDEO is not set > -CONFIG_DEFAULT_DEVICE_TREE="pine64_plus" > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus" > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_HUSH_PARSER=y > # CONFIG_CMD_IMLS is not set > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] SPL: FIT: Enable SPL_FIT_LOAD for sd bootmode for fat partions
On 3.5.2016 11:10, Lokesh Vutla wrote:
>
>
> On Monday 02 May 2016 01:27 PM, Michal Simek wrote:
>> On 2.5.2016 06:06, Lokesh Vutla wrote:
>>> Hi Michal,
>>>
>>> On Thursday 28 April 2016 03:01 PM, Michal Simek wrote:
Support U-Boot SPL to load FIT image from fat partition.
Fit image can be setup via CONFIG_SPL_FS_LOAD_KERNEL_NAME.
Falcon mode is not supported.
Signed-off-by: Michal Simek
---
common/spl/spl_fat.c | 50
--
fs/fat/fat.c | 4 ++--
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
index d16cd540e38a..4e319c5fa470 100644
--- a/common/spl/spl_fat.c
+++ b/common/spl/spl_fat.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -39,6 +40,29 @@ static int spl_register_fat_device(struct blk_desc
*block_dev, int partition)
return err;
}
+#ifdef CONFIG_SPL_LOAD_FIT
+static ulong spl_fat_file_read(struct spl_load_info *load, ulong sector,
+ ulong count, void *buf)
+{
+ int err;
+ loff_t actread;
+ char *filename = (char *)load->priv;
+
+ debug("%s: name %s, sector %lx, count %lx, buf %lx\n",
+__func__, filename, sector, count, (ulong)buf);
+
+ err = file_fat_read_at(filename, sector, buf, count, &actread);
+ if (err < 0) {
+ printf("%s: error reading image %s, err - %d\n",
+ __func__, filename, err);
+ return err;
+ }
+
+ debug("actread %lx\n", (ulong)actread);
+ return actread;
+}
+#endif
+
int spl_load_image_fat(struct blk_desc *block_dev,
int partition,
const char *filename)
@@ -57,16 +81,29 @@ int spl_load_image_fat(struct blk_desc *block_dev,
if (err <= 0)
goto end;
- spl_parse_image_header(header);
+ if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+ image_get_magic(header) == FDT_MAGIC) {
+ struct spl_load_info load;
+
+ debug("Found FIT\n");
+ load.priv = (char *)filename;
+ load.bl_len = 1;
+ load.read = spl_fat_file_read;
+ spl_load_simple_fit(&load, 0, header);
+ } else {
+ debug("Legacy image\n");
- err = file_fat_read(filename, (u8 *)(uintptr_t)spl_image.load_addr, 0);
+ spl_parse_image_header(header);
+ err = file_fat_read(filename,
+ (u8 *)(uintptr_t)spl_image.load_addr, 0);
end:
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
- if (err <= 0)
- printf("%s: error reading image %s, err - %d\n",
- __func__, filename, err);
+ if (err <= 0)
+ printf("%s: error reading image %s, err - %d\n",
+ __func__, filename, err);
#endif
+ }
return (err <= 0);
}
@@ -81,6 +118,7 @@ int spl_load_image_fat_os(struct blk_desc *block_dev,
int partition)
if (err)
return err;
+#if !defined(CONFIG_SPL_LOAD_FIT)
#if defined(CONFIG_SPL_ENV_SUPPORT) && defined(CONFIG_SPL_OS_BOOT)
file = getenv("falcon_args_file");
if (file) {
@@ -116,7 +154,7 @@ defaults:
#endif
return -1;
}
-
+#endif
return spl_load_image_fat(block_dev, partition,
CONFIG_SPL_FS_LOAD_KERNEL_NAME);
}
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 600a90e30922..0d987e0465ee 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -281,9 +281,9 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8
*buffer, unsigned long size)
if ((unsigned long)buffer & (ARCH_DMA_MINALIGN - 1)) {
ALLOC_CACHE_ALIGN_BUFFER(__u8, tmpbuf, mydata->sect_size);
-
+#if !defined(CONFIG_SPL_LOAD_FIT)
printf("FAT: Misaligned buffer address (%p)\n", buffer);
-
+#endif
>>>
>>> IMO, this is a hack. Why should fs worry about if it as fit image or
>>> not. Also the read performance will be very slow if you do not pass the
>>> aligned buffer address. I had a different approach[1] for this: first
>>> copy the image to aligned buffer and then do a memcpy to the proper
>>> destination(which showed a better performance). May be this is wrong.
>>
>> I agree that's why this was RFC not regular patch.
>> I have looked at your solution and also Simon's comments and truth is
>> that your patch has a lot of duplicated stuff.
>> This solution is smaller.
>> Regarding buffer alignment. I think this can
Re: [U-Boot] [PULL] u-boot-atmel/master -> u-boot/master
On Tue, May 03, 2016 at 02:33:06PM +0200, Andreas Bießmann wrote: > Hi Tom, > > On 2016-05-03 14:13, Tom Rini wrote: > >On Tue, May 03, 2016 at 01:35:07PM +0200, Andreas Bießmann wrote: > > > >>Hi Tom, > >> > >>here are some fixes for sama5d2 and a new sama5d2 board for 2016.05. > >> > >>The following changes since commit > >>58abb988ce24525474f0d515d2a36c1b3acf893f: > >> > >> mx6ul_evk: Remove CONFIG_SUPPORT_EMMC_BOOT (2016-05-02 > >>21:04:36 -0400) > >> > >>are available in the git repository at: > >> > >> git://git.denx.de/u-boot-atmel.git master > >> > >>for you to fetch changes up to > >>0b5940e2b24043a7f4c07cca4b11a13522063e02: > >> > >> ARM: sama5d2: Implement boot device autodetection (2016-05-03 > >>13:31:28 +0200) > >> > >> > >>Marek Vasut (2): > >> ARM: atmel: Enable FIT image support for SAMA5Dx > >> ARM: sama5d2: Implement boot device autodetection > >> > >>Wenyou Yang (6): > >> ARM: at91: sama5d2: add macro & field definitions > >> board: atmel: add SAMA5D2 PTC Engineering board > >> board: atmel: sama5d2_xplained: fix the missing pin config > >>of SDMMC0 > >> ARM: at91: clock: fix the GCK's clock source > >> ARM: at91: clock: complete the GCK's clock sources > >> board: sama5d2_xplained: change SDHCI GCK's clock source to UPLL > > > >We're less than a week out from release. Are any of these important > >bugfixes that can't wait? Thanks! > > As I understand these are fixes to get the MMC working in U-Boot and > make the config aligned to Linux: > > * board: atmel: sama5d2_xplained: fix the missing pin config of SDMMC0 > * ARM: at91: clock: fix the GCK's clock source > * ARM: at91: clock: complete the GCK's clock sources > * board: sama5d2_xplained: change SDHCI GCK's clock source to UPLL > > But I do not own such a board and could not test the state before > nor after. > > You'r right, it is really late for this release. So lets shift it to > the next one unless Wenyou says that that board is unusable without > this fix. If so I could prepare another pull request with just the > required patches. > > Is that ok for you? Works for me, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mkimage: fix generation of FIT image
Commit 7a439cadcf3192eb012a2432ca34670b676c74d2 broke generation of SPL
loadable FIT images (CONFIG_SPL_LOAD_FIT).
Fix it by removing the unnecessary storage of expected image type. This was a
left over of the previous implementation. It is not longer necessary since the
mkimage -b switch always has one parameter.
Signed-off-by: Andreas Bießmann
---
tools/mkimage.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index b407aed..93d1c16 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -133,10 +133,8 @@ static void process_args(int argc, char **argv)
char *ptr;
int type = IH_TYPE_INVALID;
char *datafile = NULL;
- int expecting;
int opt;
- expecting = IH_TYPE_COUNT; /* Unknown */
while ((opt = getopt(argc, argv,
"a:A:b:cC:d:D:e:Ef:Fk:K:ln:O:rR:sT:vVx")) != -1) {
switch (opt) {
@@ -154,8 +152,7 @@ static void process_args(int argc, char **argv)
usage("Invalid architecture");
break;
case 'b':
- expecting = IH_TYPE_FLATDT;
- if (add_content(expecting, optarg)) {
+ if (add_content(IH_TYPE_FLATDT, optarg)) {
fprintf(stderr,
"%s: Out of memory adding content '%s'",
params.cmdname, optarg);
@@ -238,7 +235,6 @@ static void process_args(int argc, char **argv)
show_image_types();
usage("Invalid image type");
}
- expecting = type;
break;
case 'v':
params.vflag++;
@@ -254,7 +250,8 @@ static void process_args(int argc, char **argv)
}
}
- if (optind < argc && expecting == type)
+ /* The last parameter is expected to be the imagefile */
+ if (optind < argc)
params.imagefile = argv[optind];
/*
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/26] x86: irq: Reserve IRQ9 for ACPI in PIC mode
Hi Bin,
On 03.05.2016 14:46, Bin Meng wrote:
On Tue, May 3, 2016 at 8:29 PM, Stefan Roese wrote:
Hi Bin,
On 02.05.2016 09:33, Bin Meng wrote:
Reserve IRQ9 which is to be used as SCI interrupt number
for ACPI in PIC mode.
Signed-off-by: Bin Meng
---
arch/x86/cpu/irq.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/cpu/irq.c b/arch/x86/cpu/irq.c
index 2950783..ae90b0c 100644
--- a/arch/x86/cpu/irq.c
+++ b/arch/x86/cpu/irq.c
@@ -120,6 +120,10 @@ static int create_pirq_routing_table(struct udevice
*dev)
priv->irq_mask = fdtdec_get_int(blob, node,
"intel,pirq-mask", PIRQ_BITMAP);
+#ifdef CONFIG_GENERATE_ACPI_TABLE
+ /* Reserve IRQ9 for SCI */
+ priv->irq_mask &= ~(1 << 9);
+#endif
Does it make sense to change this into using IS_ENABLED()?
if (IS_ENABLED(CONFIG_GENERATE_ACPI_TABLE)) {
/* Reserve IRQ9 for SCI */
priv->irq_mask &= ~(1 << 9);
}
To drop the #ifdef here?
Ah, this bothers me sometimes. I see some places in U-Boot uses #ifdef
but IS_ENABLED somewhere else. I am not sure what the recommended
guideline of U-Boot with regard to this?
We definitely strive to remove (or at least not add new) #ifdef's
from the U-Boot code base. And IS_ENABLED() is a good way to
achieve this. But it can only be used with config options available
via Kconfig. And since CONFIG_GENERATE_ACPI_TABLE is a Kconfig
symbol, my recommendation is to use it.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/26] x86: Initial ACPI support for Intel BayTrail
Hi Bin, thank you very much for this patch series. I've given the patchset a quick review and tested it shortly on the BayTrail Congatec board. And have seen no issues so far. Shutdown and reboot also seem to work just fine. I'll definitely give it a more thorough test in the next days / weeks. I've sent you a few minor comments to some of the patches. But please add my: Reviewed-by: Stefan Roese Tested-by: Stefan Roese to all patches. Thanks, Stefan On 02.05.2016 09:33, Bin Meng wrote: This series introduces initial ACPI support for Intel BayTrail. Advanced Configuration and Power Interface (ACPI) aims to establish industry-standard interfaces enabling OS-directed configuration, power management, and thermal management of mobile, desktop, and server platforms. Linux can boot without ACPI with "acpi=off" command line parameter, but with ACPI the kernel gains the capabilities to handle power management. For Windows, ACPI is a must-have firmware feature since Windows Vista. CONFIG_GENERATE_ACPI_TABLE is the config option to turn on ACPI support in U-Boot. This requires Intel ACPI compiler to be installed on your host to compile ACPI DSDT table written in ASL format to AML format. You can get the compiler via "apt-get install iasl" if you are on Ubuntu or download the source from acpica website to compile one by yourself. Current ACPI support in U-Boot is not complete. More features will be added in the future. The status as of today is: * Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables. * Support one static DSDT table only, compiled by Intel ACPI compiler. * Support S0/S5 only, no S3/S4 boot path support yet. * No ACPI global NVS support (this can be optional, but we may need it in the future to simplify ASL code logic when utilizing NVS variables). * No dynamic AML bytecodes insertion at run-time (this is optional as we can always describe the board in the static way). * All ACPI interrupts are routed to SCI for OS to handle. No legacy SMI implementation within U-Boot. * Install Ubuntu from U-Boot plus SeaBIOS does not work. * Install Windows 8.1/10 from U-Boot plus SeaBIOS does not work. So far ACPI is enabled on BayTrail based boards. Testing was done by booting a pre-installed Ubuntu 14.04 from a SATA drive. Most devices seem to work correctly and the board can respond a reboot/shutdown command from Ubuntu. This series is available at u-boot-x86/acpi-working. Bin Meng (26): x86: Drop asm/acpi.h x86: Fix build warning in tables.c when CONFIG_SEABIOS x86: acpi: Fix compiler warnings in write_acpi_tables() x86: irq: Reserve IRQ9 for ACPI in PIC mode x86: irq: Enable SCI on IRQ9 x86: dts: Update to include ACTL register details acpi: Change build log for ASL files acpi: Explicitly spell out dsdt.c in the make rule acpi: Specify U-Boot include path for ASL files acpi: Do not disable all errors/warnings/remarks when compiling ASL x86: acpi: Remove unneeded codes x86: acpi: Various changes to acpi_table.h x86: acpi: Reorder codes in acpi_table.h x86: acpi: Remove acpi_create_ssdt_generator() x86: acpi: Change fill_header() x86: acpi: Adjust orders in acpi_table.c x86: acpi: Change table write routine signature to use u32 x86: acpi: Align FACS table to a 64 byte boundary x86: acpi: Add some generic ASL libraries x86: baytrail: Add platform ASL files x86: baytrail: Generate ACPI FADT/MADT tables x86: baytrail: Enable ACPI table generation for all boards x86: baytrail: Add .gitignore for ACPI enabled boards x86: Remove acpi=off boot parameter when ACPI is on x86: doc: Minor update for accuracy x86: doc: Document ACPI support arch/x86/cpu/baytrail/Makefile | 1 + arch/x86/cpu/baytrail/acpi.c | 162 +++ arch/x86/cpu/irq.c | 29 ++ arch/x86/cpu/ivybridge/lpc.c | 1 - arch/x86/cpu/ivybridge/model_206ax.c | 1 - arch/x86/cpu/ivybridge/northbridge.c | 1 - arch/x86/dts/bayleybay.dts | 1 + arch/x86/dts/conga-qeval20-qa3-e3845.dts | 1 + arch/x86/dts/crownbay.dts | 1 + arch/x86/dts/galileo.dts | 1 + arch/x86/dts/minnowmax.dts | 1 + arch/x86/dts/qemu-x86_q35.dts | 2 + arch/x86/include/asm/acpi.h| 24 - arch/x86/include/asm/acpi/debug.asl| 136 ++ arch/x86/include/asm/acpi/globutil.asl | 113 + arch/x86/include/asm/acpi/statdef.asl | 82 arch/x86/include/asm/acpi_table.h | 447 --- .../include/asm/arch-baytrail/acpi/irq_helper.h| 111 + .../include/asm/arch-baytrail/acpi/irqlinks.asl| 489 + .../include/asm/arch-baytrail/acpi/irqroute.asl| 48
Re: [U-Boot] [PATCH v4 2/3] spl: Allow to load a FIT containing U-Boot from FS
On 3.5.2016 11:05, Lokesh Vutla wrote:
> This provides a way to load a FIT containing U-Boot and a selection of device
> tree files from a File system. Making sure that all the reads and writes
> are aligned to their respective needs.
>
> Signed-off-by: Lokesh Vutla
> ---
> - Assuming info->priv is used for passing filename for now and using this for
> detecting if it a fs read. If this is not preferred I can create a new field
> for filename.
>
> common/spl/spl_fit.c | 76
> +---
> include/spl.h| 10 +++
> 2 files changed, 71 insertions(+), 15 deletions(-)
>
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index b1cfa97..d696354 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -82,6 +82,42 @@ static int spl_fit_select_fdt(const void *fdt, int images,
> int *fdt_offsetp)
> return -ENOENT;
> }
>
> +static int get_aligned_image_offset(struct spl_load_info *info, int offset)
> +{
> + /*
> + * If it is a FS read, get the first address before offset which is
> + * aligned to ARCH_DMA_MINALIGN. If it is raw read return the
> + * block number to which offset belongs.
> + */
> + if (info->priv)
> + return offset & ~(ARCH_DMA_MINALIGN - 1);
> + else
remove this else.
> + return offset / info->bl_len;
> +}
> +
> +static int get_aligned_image_overhead(struct spl_load_info *info, int offset)
> +{
> + /*
> + * If it is a FS read, get the difference between the offset and
> + * the first address before offset which is aligned to
> + * ARCH_DMA_MINALIGN. If it is raw read return the offset within the
> + * block.
> + */
> + if (info->priv)
> + return offset & (ARCH_DMA_MINALIGN - 1);
> + else
remove this else.
> + return offset % info->bl_len;
> +}
> +
> +static int get_aligned_image_size(struct spl_load_info *info, int data_size,
> + int offset)
> +{
> + if (info->priv)
> + return data_size + get_aligned_image_overhead(info, offset);
> + else
remove this else.
> + return (data_size + info->bl_len - 1) / info->bl_len;
> +}
> +
> int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void *fit)
> {
> int sectors;
> @@ -91,7 +127,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong
> sector, void *fit)
> void *load_ptr;
> int fdt_offset, fdt_len;
> int data_offset, data_size;
> - int base_offset;
> + int base_offset, align_len;
> int src_sector;
> void *dst;
>
> @@ -117,8 +153,10 @@ int spl_load_simple_fit(struct spl_load_info *info,
> ulong sector, void *fit)
>* In fact the FIT has its own load address, but we assume it cannot
>* be before CONFIG_SYS_TEXT_BASE.
>*/
> - fit = (void *)(CONFIG_SYS_TEXT_BASE - size - info->bl_len);
> - sectors = (size + info->bl_len - 1) / info->bl_len;
> + align_len = ARCH_DMA_MINALIGN - 1;
> + fit = (void *)((CONFIG_SYS_TEXT_BASE - size - info->bl_len -
> + align_len) & ~align_len);
Don't you want to use ALIGN macro here?
> + sectors = get_aligned_image_size(info, size, 0);
> count = info->read(info, sector, sectors, fit);
> debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu\n",
> sector, sectors, fit, count);
> @@ -151,19 +189,23 @@ int spl_load_simple_fit(struct spl_load_info *info,
> ulong sector, void *fit)
>* byte will be at 'load'. This may mean we need to load it starting
>* before then, since we can only read whole blocks.
>*/
> - sectors = (data_size + info->bl_len - 1) / info->bl_len;
> + sectors = get_aligned_image_size(info, data_size, data_offset);
> data_offset += base_offset;
> load_ptr = (void *)load;
> debug("U-Boot size %x, data %p\n", data_size, load_ptr);
> - dst = load_ptr - (data_offset % info->bl_len);
> + dst = load_ptr;
>
> /* Read the image */
> - src_sector = sector + data_offset / info->bl_len;
> - debug("image: data_offset=%x, dst=%p, src_sector=%x, sectors=%x\n",
> - data_offset, dst, src_sector, sectors);
> + src_sector = sector + get_aligned_image_offset(info, data_offset);
> + debug("Aligned image read: dst=%p, src_sector=%x, sectors=%x\n",
> + dst, src_sector, sectors);
> count = info->read(info, src_sector, sectors, dst);
> if (count != sectors)
> return -EIO;
> + debug("image: dst=%p, data_offset=%x, size=%x\n", dst, data_offset,
> + data_size);
> + memcpy(dst, dst + get_aligned_image_overhead(info, data_offset),
> +data_size);
>
> /* Figure out which device tree the board wants to use */
> fdt_len = spl_fit_select_fdt(fit, images, &fdt_offset);
> @@ -173,14 +215,15 @@ int spl_load_simple_fit(struct spl_load_info *info,
> ulo
