[PATCH] omap3: igep0x00: Switch to the I2C driver model
From: Javier Martinez Canillas
When building with the igep00x0_defconfig, the following warning is shown:
$ make -j $(nproc)
...
LD spl/u-boot-spl
OBJCOPY spl/u-boot-spl-nodtb.bin
SYM spl/u-boot-spl.sym
CAT spl/u-boot-spl-dtb.bin
COPYspl/u-boot-spl.bin
MKIMAGE MLO
= WARNING ==
This board does not use CONFIG_DM_I2C (Driver Model
for I2C drivers). Please update the board to use
CONFIG_DM_I2C before the v2022.04 release. Failure to
update by the deadline may result in board removal.
See doc/develop/driver-model/migration.rst for more info.
The only reason why I2C is enabled for the IGEP boards is that the TWL4030
driver requires it.
But both the TWL4034 and the OMAP I2C controller drivers were converted to
the driver model by commits daa69ffe3d4d ("drivers: i2c: omap24xx_i2c:
adopt omap_i2c driver to driver model") and fb1b7712ad3f power: make most
tps drivers and the twl4030 driver compatible with DM_I2C") respectively.
So there's no reason anymore to keep using the I2C legacy API and instead
the DM_I2C option could just be enabled.
Signed-off-by: Javier Martinez Canillas
---
configs/igep00x0_defconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
index 87fd2797eace..473891607b0f 100644
--- a/configs/igep00x0_defconfig
+++ b/configs/igep00x0_defconfig
@@ -68,8 +68,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_VERSION_VARIABLE=y
# CONFIG_NET is not set
CONFIG_SPL_DM=y
-CONFIG_SYS_I2C_LEGACY=y
-CONFIG_SPL_SYS_I2C_LEGACY=y
+CONFIG_DM_I2C=y
+CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
CONFIG_MMC_OMAP_HS=y
CONFIG_MTD=y
CONFIG_SYS_MTDPARTS_RUNTIME=y
--
2.45.2
Re: [RESEND PATCH 0/4] omap3: igep0x00: Fix boot failure and modernize the boards support
Hello Tom, On Mon, Jun 3, 2024 at 7:41 PM Tom Rini wrote: > > On Sat, 18 May 2024 15:06:11 +0200, Javier Martinez Canillas wrote: > > > I noticed that the IGEPv2 board did not boot anymore with mainline U-Boot. > > This was caused by a driver change to allocate its platform data before > > relocation and U-Boot not having enough pre-relocation heap size for this. > > > > This series fixes this issue and also makes the board support more modern, > > by enabling DM for SPL and migrating the IGEP boards to use upstream DTBs. > > > > [...] > > Applied to u-boot/master, thanks! Thanks! And sorry for the spam with this series. Best regards, Javier
[RESEND PATCH 4/4] omap3: igep0x00: Migrate to use upstream DT
Enable OF_UPSTREAM to use upstream DT and add a ti/omap/ prefix to the
DEFAULT_DEVICE_TREE config option.
That way, a DTS from the upstream dts/upstream/src/ directory is used
instead of the arch/$(ARCH)/dts/ directory. These in turn are removed.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/dts/Makefile | 3 -
arch/arm/dts/omap3-igep.dtsi| 247 --
arch/arm/dts/omap3-igep0020-common.dtsi | 261
arch/arm/dts/omap3-igep0020.dts | 47 -
configs/igep00x0_defconfig | 3 +-
5 files changed, 2 insertions(+), 559 deletions(-)
delete mode 100644 arch/arm/dts/omap3-igep.dtsi
delete mode 100644 arch/arm/dts/omap3-igep0020-common.dtsi
delete mode 100644 arch/arm/dts/omap3-igep0020.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a5c82ebf7a5f..a9bd4921718e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1030,9 +1030,6 @@ dtb-$(CONFIG_TARGET_OMAP3_BEAGLE) += \
dtb-$(CONFIG_TARGET_DEVKIT8000) += omap3-devkit8000.dtb
-dtb-$(CONFIG_TARGET_OMAP3_IGEP00X0) += \
- omap3-igep0020.dtb
-
dtb-$(CONFIG_TARGET_OMAP4_PANDA) += \
omap4-panda.dtb \
omap4-panda-es.dtb
diff --git a/arch/arm/dts/omap3-igep.dtsi b/arch/arm/dts/omap3-igep.dtsi
deleted file mode 100644
index 219202610463..
--- a/arch/arm/dts/omap3-igep.dtsi
+++ /dev/null
@@ -1,247 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Common device tree for IGEP boards based on AM/DM37x
- *
- * Copyright (C) 2012 Javier Martinez Canillas
- * Copyright (C) 2012 Enric Balletbo i Serra
- */
-/dts-v1/;
-
-#include "omap36xx.dtsi"
-
-/ {
- memory@8000 {
- device_type = "memory";
- reg = <0x8000 0x2000>; /* 512 MB */
- };
-
- chosen {
- stdout-path = &uart3;
- };
-
- sound {
- compatible = "ti,omap-twl4030";
- ti,model = "igep2";
- ti,mcbsp = <&mcbsp2>;
- };
-
- vdd33: regulator-vdd33 {
- compatible = "regulator-fixed";
- regulator-name = "vdd33";
- regulator-always-on;
- };
-
-};
-
-&omap3_pmx_core {
- gpmc_pins: pinmux_gpmc_pins {
- pinctrl-single,pins = <
- /* OneNAND seems to require PIN_INPUT on clock. */
-OMAP3_CORE1_IOPAD(0x20be, PIN_INPUT | MUX_MODE0)
/* gpmc_clk.gpmc_clk */
- >;
- };
-
- uart1_pins: pinmux_uart1_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x2182, PIN_INPUT | MUX_MODE0)
/* uart1_rx.uart1_rx */
- OMAP3_CORE1_IOPAD(0x217c, PIN_OUTPUT | MUX_MODE0)
/* uart1_tx.uart1_tx */
- >;
- };
-
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | MUX_MODE0)
/* uart3_rx.uart3_rx */
- OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)
/* uart3_tx.uart3_tx */
- >;
- };
-
- mcbsp2_pins: pinmux_mcbsp2_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x213c, PIN_INPUT | MUX_MODE0)
/* mcbsp2_fsx.mcbsp2_fsx */
- OMAP3_CORE1_IOPAD(0x213e, PIN_INPUT | MUX_MODE0)
/* mcbsp2_clkx.mcbsp2_clkx */
- OMAP3_CORE1_IOPAD(0x2140, PIN_INPUT | MUX_MODE0)
/* mcbsp2_dr.mcbsp2.dr */
- OMAP3_CORE1_IOPAD(0x2142, PIN_OUTPUT | MUX_MODE0)
/* mcbsp2_dx.mcbsp2_dx */
- >;
- };
-
- mmc1_pins: pinmux_mmc1_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_clk.sdmmc1_clk */
- OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_cmd.sdmmc1_cmd */
- OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat0.sdmmc1_dat0 */
- OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat1.sdmmc1_dat1 */
- OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat2.sdmmc1_dat2 */
- OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat3.sdmmc1_dat3 */
- >;
- };
-
- mmc2_pins: pinmux_mmc2_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_clk.sdmmc2_clk */
- OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_cmd.sdmmc2_cmd */
- OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX
[RESEND PATCH 3/4] omap3: igep0x00: Update for DM SPL support
This change is heavily based on commit e0cc7df9fdf2 ("omap3_beagle: Update
for DM SPL support"), that did the same update for the OMAP3 Beagle board.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/dts/omap3-igep0020-u-boot.dtsi | 14 ++
board/isee/igep00x0/igep00x0.c | 12
configs/igep00x0_defconfig | 17 -
3 files changed, 10 insertions(+), 33 deletions(-)
diff --git a/arch/arm/dts/omap3-igep0020-u-boot.dtsi
b/arch/arm/dts/omap3-igep0020-u-boot.dtsi
index 41beaf0900c3..2c03701c896a 100644
--- a/arch/arm/dts/omap3-igep0020-u-boot.dtsi
+++ b/arch/arm/dts/omap3-igep0020-u-boot.dtsi
@@ -5,20 +5,10 @@
* (C) Copyright 2017 Derald D. Woods
*/
+#include "omap3-u-boot.dtsi"
+
/ {
chosen {
stdout-path = &uart3;
};
};
-
-&uart1 {
- reg-shift = <2>;
-};
-
-&uart2 {
- reg-shift = <2>;
-};
-
-&uart3 {
- reg-shift = <2>;
-};
diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
index 8a3f290f678f..a35a7cd3b1f7 100644
--- a/board/isee/igep00x0/igep00x0.c
+++ b/board/isee/igep00x0/igep00x0.c
@@ -29,18 +29,6 @@
#include
#include "igep00x0.h"
-static const struct ns16550_plat igep_serial = {
- .base = OMAP34XX_UART3,
- .reg_shift = 2,
- .clock = V_NS16550_CLK,
- .fcr = UART_FCR_DEFVAL,
-};
-
-U_BOOT_DRVINFO(igep_uart) = {
- "ns16550_serial",
- &igep_serial
-};
-
/*
* Routine: get_board_revision
* Description: GPIO_28 and GPIO_129 are used to read board and revision from
diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
index 6df6c33e25ab..c1b873a17efb 100644
--- a/configs/igep00x0_defconfig
+++ b/configs/igep00x0_defconfig
@@ -1,4 +1,6 @@
CONFIG_ARM=y
+# CONFIG_SPL_USE_ARCH_MEMCPY is not set
+# CONFIG_SPL_USE_ARCH_MEMSET is not set
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_SYS_MALLOC_F_LEN=0x4000
CONFIG_TI_COMMON_CMD_OPTIONS=y
@@ -40,16 +42,7 @@ CONFIG_SPL_UBI_LEB_START=2048
CONFIG_SPL_UBI_INFO_ADDR=0x8808
CONFIG_SPL_UBI_VOL_IDS=8
CONFIG_SPL_UBI_LOAD_MONITOR_ID=0
-CONFIG_SPL_UBI_LOAD_KERNEL_ID=3
-CONFIG_SPL_UBI_LOAD_ARGS_ID=4
CONFIG_SPL_ONENAND_SUPPORT=y
-CONFIG_SPL_OS_BOOT=y
-CONFIG_SPL_PAYLOAD_ARGS_ADDR=0x8400
-CONFIG_SYS_NAND_SPL_KERNEL_OFFS=0x28
-CONFIG_SPL_FALCON_BOOT_MMCSD=y
-CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR=0x1700
-CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR=0x1500
-CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS=0x200
CONFIG_CMD_SPL=y
CONFIG_CMD_NAND=y
CONFIG_CMD_ONENAND=y
@@ -59,7 +52,11 @@ CONFIG_CMD_CACHE=y
CONFIG_CMD_MTDPARTS=y
CONFIG_CMD_UBI=y
# CONFIG_CMD_UBIFS is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SPL_PARTITION_UUIDS=y
CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent"
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_IS_IN_UBI=y
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
@@ -69,6 +66,7 @@ CONFIG_ENV_UBI_VOLUME_REDUND="config_r"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_VERSION_VARIABLE=y
# CONFIG_NET is not set
+CONFIG_SPL_DM=y
CONFIG_SYS_I2C_LEGACY=y
CONFIG_SPL_SYS_I2C_LEGACY=y
CONFIG_MMC_OMAP_HS=y
@@ -81,5 +79,6 @@ CONFIG_SYS_NAND_PAGE_SIZE=0x800
CONFIG_SYS_NAND_OOBSIZE=0x40
CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
CONFIG_MTD_UBI_FASTMAP=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
CONFIG_CONS_INDEX=3
CONFIG_BCH=y
--
2.45.0
[RESEND PATCH 2/4] omap3: igep0x00: Drop unused SPI support
There are no SPI peripherals in neither the IGEPv2 board nor the IGEP COM Module, so there's no reason to have this enabled in the boards defconfig. Signed-off-by: Javier Martinez Canillas --- configs/igep00x0_defconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig index e4d25556e3f3..6df6c33e25ab 100644 --- a/configs/igep00x0_defconfig +++ b/configs/igep00x0_defconfig @@ -82,7 +82,4 @@ CONFIG_SYS_NAND_OOBSIZE=0x40 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_CONS_INDEX=3 -CONFIG_SPI=y -CONFIG_DM_SPI=y -CONFIG_OMAP3_SPI=y CONFIG_BCH=y -- 2.45.0
[RESEND PATCH 1/4] omap3: igep00x0: Increase malloc() pool size
The IGEPv2 board boot started to fail since the commit afd4f15a39de ("spi:
omap3_spi: Read platform data in ofdata_to_platdata()"). Because this made
the OMAP3 SPI controller driver to allocate its platform data before doing
a relocation, but the igep0x00 config sets this pool size to just 1 KiB.
Increase the pre-relocation malloc heap size to 16 KiB, as is set by other
OMAP3 boards. This not only restores booting but also makes it consistent.
Leave the SPL pool size to the previous 1 KiB size since 16 KiB may not be
a possible size in that constrained environment and is also the value that
is set by other OMAP3 boards.
Signed-off-by: Javier Martinez Canillas
---
configs/igep00x0_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
index 261f71acc1dd..e4d25556e3f3 100644
--- a/configs/igep00x0_defconfig
+++ b/configs/igep00x0_defconfig
@@ -1,6 +1,6 @@
CONFIG_ARM=y
CONFIG_ARCH_OMAP2PLUS=y
-CONFIG_SYS_MALLOC_F_LEN=0x400
+CONFIG_SYS_MALLOC_F_LEN=0x4000
CONFIG_TI_COMMON_CMD_OPTIONS=y
CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
@@ -10,6 +10,7 @@ CONFIG_DEFAULT_DEVICE_TREE="omap3-igep0020"
CONFIG_SPL_TEXT_BASE=0x4020
CONFIG_TARGET_OMAP3_IGEP00X0=y
CONFIG_SYS_MONITOR_LEN=262144
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
CONFIG_SPL=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTDELAY=3
--
2.45.0
[RESEND PATCH 0/4] omap3: igep0x00: Fix boot failure and modernize the boards support
Hello, I noticed that the IGEPv2 board did not boot anymore with mainline U-Boot. This was caused by a driver change to allocate its platform data before relocation and U-Boot not having enough pre-relocation heap size for this. This series fixes this issue and also makes the board support more modern, by enabling DM for SPL and migrating the IGEP boards to use upstream DTBs. It is a resend because previous emails were blocked on moderator approval due not being subscribed in the mailing list. Hopefully this time makes it through, sorry for the spam to folks Cc'ed. Best regards, Javier Javier Martinez Canillas (4): omap3: igep00x0: Increase malloc() pool size omap3: igep0x00: Drop unused SPI support omap3: igep0x00: Update for DM SPL support omap3: igep0x00: Migrate to use upstream DT arch/arm/dts/Makefile | 3 - arch/arm/dts/omap3-igep.dtsi| 247 -- arch/arm/dts/omap3-igep0020-common.dtsi | 261 arch/arm/dts/omap3-igep0020-u-boot.dtsi | 14 +- arch/arm/dts/omap3-igep0020.dts | 47 - board/isee/igep00x0/igep00x0.c | 12 -- configs/igep00x0_defconfig | 26 ++- 7 files changed, 14 insertions(+), 596 deletions(-) delete mode 100644 arch/arm/dts/omap3-igep.dtsi delete mode 100644 arch/arm/dts/omap3-igep0020-common.dtsi delete mode 100644 arch/arm/dts/omap3-igep0020.dts -- 2.45.0
[RESEND PATCH 4/4] omap3: igep0x00: Migrate to use upstream DT
From: Javier Martinez Canillas
Enable OF_UPSTREAM to use upstream DT and add a ti/omap/ prefix to the
DEFAULT_DEVICE_TREE config option.
That way, a DTS from the upstream dts/upstream/src/ directory is used
instead of the arch/$(ARCH)/dts/ directory. These in turn are removed.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/dts/Makefile | 3 -
arch/arm/dts/omap3-igep.dtsi| 247 --
arch/arm/dts/omap3-igep0020-common.dtsi | 261
arch/arm/dts/omap3-igep0020.dts | 47 -
configs/igep00x0_defconfig | 3 +-
5 files changed, 2 insertions(+), 559 deletions(-)
delete mode 100644 arch/arm/dts/omap3-igep.dtsi
delete mode 100644 arch/arm/dts/omap3-igep0020-common.dtsi
delete mode 100644 arch/arm/dts/omap3-igep0020.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a5c82ebf7a5f..a9bd4921718e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1030,9 +1030,6 @@ dtb-$(CONFIG_TARGET_OMAP3_BEAGLE) += \
dtb-$(CONFIG_TARGET_DEVKIT8000) += omap3-devkit8000.dtb
-dtb-$(CONFIG_TARGET_OMAP3_IGEP00X0) += \
- omap3-igep0020.dtb
-
dtb-$(CONFIG_TARGET_OMAP4_PANDA) += \
omap4-panda.dtb \
omap4-panda-es.dtb
diff --git a/arch/arm/dts/omap3-igep.dtsi b/arch/arm/dts/omap3-igep.dtsi
deleted file mode 100644
index 219202610463..
--- a/arch/arm/dts/omap3-igep.dtsi
+++ /dev/null
@@ -1,247 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Common device tree for IGEP boards based on AM/DM37x
- *
- * Copyright (C) 2012 Javier Martinez Canillas
- * Copyright (C) 2012 Enric Balletbo i Serra
- */
-/dts-v1/;
-
-#include "omap36xx.dtsi"
-
-/ {
- memory@8000 {
- device_type = "memory";
- reg = <0x8000 0x2000>; /* 512 MB */
- };
-
- chosen {
- stdout-path = &uart3;
- };
-
- sound {
- compatible = "ti,omap-twl4030";
- ti,model = "igep2";
- ti,mcbsp = <&mcbsp2>;
- };
-
- vdd33: regulator-vdd33 {
- compatible = "regulator-fixed";
- regulator-name = "vdd33";
- regulator-always-on;
- };
-
-};
-
-&omap3_pmx_core {
- gpmc_pins: pinmux_gpmc_pins {
- pinctrl-single,pins = <
- /* OneNAND seems to require PIN_INPUT on clock. */
-OMAP3_CORE1_IOPAD(0x20be, PIN_INPUT | MUX_MODE0)
/* gpmc_clk.gpmc_clk */
- >;
- };
-
- uart1_pins: pinmux_uart1_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x2182, PIN_INPUT | MUX_MODE0)
/* uart1_rx.uart1_rx */
- OMAP3_CORE1_IOPAD(0x217c, PIN_OUTPUT | MUX_MODE0)
/* uart1_tx.uart1_tx */
- >;
- };
-
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | MUX_MODE0)
/* uart3_rx.uart3_rx */
- OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)
/* uart3_tx.uart3_tx */
- >;
- };
-
- mcbsp2_pins: pinmux_mcbsp2_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x213c, PIN_INPUT | MUX_MODE0)
/* mcbsp2_fsx.mcbsp2_fsx */
- OMAP3_CORE1_IOPAD(0x213e, PIN_INPUT | MUX_MODE0)
/* mcbsp2_clkx.mcbsp2_clkx */
- OMAP3_CORE1_IOPAD(0x2140, PIN_INPUT | MUX_MODE0)
/* mcbsp2_dr.mcbsp2.dr */
- OMAP3_CORE1_IOPAD(0x2142, PIN_OUTPUT | MUX_MODE0)
/* mcbsp2_dx.mcbsp2_dx */
- >;
- };
-
- mmc1_pins: pinmux_mmc1_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_clk.sdmmc1_clk */
- OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_cmd.sdmmc1_cmd */
- OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat0.sdmmc1_dat0 */
- OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat1.sdmmc1_dat1 */
- OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat2.sdmmc1_dat2 */
- OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat3.sdmmc1_dat3 */
- >;
- };
-
- mmc2_pins: pinmux_mmc2_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_clk.sdmmc2_clk */
- OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_cmd.sdmmc2_cmd */
- OMAP3_CORE1_IOPAD(
[RESEND PATCH 2/4] omap3: igep0x00: Drop unused SPI support
From: Javier Martinez Canillas There are no SPI peripherals in neither the IGEPv2 board nor the IGEP COM Module, so there's no reason to have this enabled in the boards defconfig. Signed-off-by: Javier Martinez Canillas --- configs/igep00x0_defconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig index e4d25556e3f3..6df6c33e25ab 100644 --- a/configs/igep00x0_defconfig +++ b/configs/igep00x0_defconfig @@ -82,7 +82,4 @@ CONFIG_SYS_NAND_OOBSIZE=0x40 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_CONS_INDEX=3 -CONFIG_SPI=y -CONFIG_DM_SPI=y -CONFIG_OMAP3_SPI=y CONFIG_BCH=y -- 2.45.0
[RESEND PATCH 3/4] omap3: igep0x00: Update for DM SPL support
From: Javier Martinez Canillas
This change is heavily based on commit e0cc7df9fdf2 ("omap3_beagle: Update
for DM SPL support"), that did the same update for the OMAP3 Beagle board.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/dts/omap3-igep0020-u-boot.dtsi | 14 ++
board/isee/igep00x0/igep00x0.c | 12
configs/igep00x0_defconfig | 17 -
3 files changed, 10 insertions(+), 33 deletions(-)
diff --git a/arch/arm/dts/omap3-igep0020-u-boot.dtsi
b/arch/arm/dts/omap3-igep0020-u-boot.dtsi
index 41beaf0900c3..2c03701c896a 100644
--- a/arch/arm/dts/omap3-igep0020-u-boot.dtsi
+++ b/arch/arm/dts/omap3-igep0020-u-boot.dtsi
@@ -5,20 +5,10 @@
* (C) Copyright 2017 Derald D. Woods
*/
+#include "omap3-u-boot.dtsi"
+
/ {
chosen {
stdout-path = &uart3;
};
};
-
-&uart1 {
- reg-shift = <2>;
-};
-
-&uart2 {
- reg-shift = <2>;
-};
-
-&uart3 {
- reg-shift = <2>;
-};
diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
index 8a3f290f678f..a35a7cd3b1f7 100644
--- a/board/isee/igep00x0/igep00x0.c
+++ b/board/isee/igep00x0/igep00x0.c
@@ -29,18 +29,6 @@
#include
#include "igep00x0.h"
-static const struct ns16550_plat igep_serial = {
- .base = OMAP34XX_UART3,
- .reg_shift = 2,
- .clock = V_NS16550_CLK,
- .fcr = UART_FCR_DEFVAL,
-};
-
-U_BOOT_DRVINFO(igep_uart) = {
- "ns16550_serial",
- &igep_serial
-};
-
/*
* Routine: get_board_revision
* Description: GPIO_28 and GPIO_129 are used to read board and revision from
diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
index 6df6c33e25ab..c1b873a17efb 100644
--- a/configs/igep00x0_defconfig
+++ b/configs/igep00x0_defconfig
@@ -1,4 +1,6 @@
CONFIG_ARM=y
+# CONFIG_SPL_USE_ARCH_MEMCPY is not set
+# CONFIG_SPL_USE_ARCH_MEMSET is not set
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_SYS_MALLOC_F_LEN=0x4000
CONFIG_TI_COMMON_CMD_OPTIONS=y
@@ -40,16 +42,7 @@ CONFIG_SPL_UBI_LEB_START=2048
CONFIG_SPL_UBI_INFO_ADDR=0x8808
CONFIG_SPL_UBI_VOL_IDS=8
CONFIG_SPL_UBI_LOAD_MONITOR_ID=0
-CONFIG_SPL_UBI_LOAD_KERNEL_ID=3
-CONFIG_SPL_UBI_LOAD_ARGS_ID=4
CONFIG_SPL_ONENAND_SUPPORT=y
-CONFIG_SPL_OS_BOOT=y
-CONFIG_SPL_PAYLOAD_ARGS_ADDR=0x8400
-CONFIG_SYS_NAND_SPL_KERNEL_OFFS=0x28
-CONFIG_SPL_FALCON_BOOT_MMCSD=y
-CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR=0x1700
-CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR=0x1500
-CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS=0x200
CONFIG_CMD_SPL=y
CONFIG_CMD_NAND=y
CONFIG_CMD_ONENAND=y
@@ -59,7 +52,11 @@ CONFIG_CMD_CACHE=y
CONFIG_CMD_MTDPARTS=y
CONFIG_CMD_UBI=y
# CONFIG_CMD_UBIFS is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SPL_PARTITION_UUIDS=y
CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent"
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_IS_IN_UBI=y
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
@@ -69,6 +66,7 @@ CONFIG_ENV_UBI_VOLUME_REDUND="config_r"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_VERSION_VARIABLE=y
# CONFIG_NET is not set
+CONFIG_SPL_DM=y
CONFIG_SYS_I2C_LEGACY=y
CONFIG_SPL_SYS_I2C_LEGACY=y
CONFIG_MMC_OMAP_HS=y
@@ -81,5 +79,6 @@ CONFIG_SYS_NAND_PAGE_SIZE=0x800
CONFIG_SYS_NAND_OOBSIZE=0x40
CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
CONFIG_MTD_UBI_FASTMAP=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
CONFIG_CONS_INDEX=3
CONFIG_BCH=y
--
2.45.0
[RESEND PATCH 1/4] omap3: igep00x0: Increase malloc() pool size
From: Javier Martinez Canillas
The IGEPv2 board boot started to fail since the commit afd4f15a39de ("spi:
omap3_spi: Read platform data in ofdata_to_platdata()"). Because this made
the OMAP3 SPI controller driver to allocate its platform data before doing
a relocation, but the igep0x00 config sets this pool size to just 1 KiB.
Increase the pre-relocation malloc heap size to 16 KiB, as is set by other
OMAP3 boards. This not only restores booting but also makes it consistent.
Leave the SPL pool size to the previous 1 KiB size since 16 KiB may not be
a possible size in that constrained environment and is also the value that
is set by other OMAP3 boards.
Signed-off-by: Javier Martinez Canillas
---
configs/igep00x0_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
index 261f71acc1dd..e4d25556e3f3 100644
--- a/configs/igep00x0_defconfig
+++ b/configs/igep00x0_defconfig
@@ -1,6 +1,6 @@
CONFIG_ARM=y
CONFIG_ARCH_OMAP2PLUS=y
-CONFIG_SYS_MALLOC_F_LEN=0x400
+CONFIG_SYS_MALLOC_F_LEN=0x4000
CONFIG_TI_COMMON_CMD_OPTIONS=y
CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
@@ -10,6 +10,7 @@ CONFIG_DEFAULT_DEVICE_TREE="omap3-igep0020"
CONFIG_SPL_TEXT_BASE=0x4020
CONFIG_TARGET_OMAP3_IGEP00X0=y
CONFIG_SYS_MONITOR_LEN=262144
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
CONFIG_SPL=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTDELAY=3
--
2.45.0
[RESEND PATCH 0/4] omap3: igep0x00: Fix boot failure and modernize the boards support
Hello, I noticed that the IGEPv2 board did not boot anymore with mainline U-Boot. This was caused by a driver change to allocate its platform data before relocation and U-Boot not having enough pre-relocation heap size for this. This series fixes this issue and also makes the board support more modern, by enabling DM for SPL and migrating the IGEP boards to use upstream DTBs. It is a resend because previous emails were blocked on moderator approval due not being subscribed in the mailing list. Hopefully this time makes it through, sorry for the spam to folks Cc'ed. Best regards, Javier Javier Martinez Canillas (4): omap3: igep00x0: Increase malloc() pool size omap3: igep0x00: Drop unused SPI support omap3: igep0x00: Update for DM SPL support omap3: igep0x00: Migrate to use upstream DT arch/arm/dts/Makefile | 3 - arch/arm/dts/omap3-igep.dtsi| 247 -- arch/arm/dts/omap3-igep0020-common.dtsi | 261 arch/arm/dts/omap3-igep0020-u-boot.dtsi | 14 +- arch/arm/dts/omap3-igep0020.dts | 47 - board/isee/igep00x0/igep00x0.c | 12 -- configs/igep00x0_defconfig | 26 ++- 7 files changed, 14 insertions(+), 596 deletions(-) delete mode 100644 arch/arm/dts/omap3-igep.dtsi delete mode 100644 arch/arm/dts/omap3-igep0020-common.dtsi delete mode 100644 arch/arm/dts/omap3-igep0020.dts -- 2.45.0
Re: [PATCH] efi_loader: allow to disable GOP support
On Wed, Jun 16, 2021 at 2:20 PM Icenowy Zheng wrote: > > I'm trying RK3399 with Linux. EFIFB never works as intended (maybe it's > because IOMMU is reconfigured), and rockchipdrmfb will be fb1 (leave > non-working EFIFB as fb0), makes fbcon unusable. > > The second problem has a proposed fix, but the first problem is > mystery. > I think that figured out the mystery for your second problem too (if I understood what you meant correctly). The problem is that u-boot initializes the display controller and provides the setup framebuffer memory to the kernel as a GOP. But then the kernel re-initializes the HW again and mess with the resources needed by the display controller that were correctly setup by u-boot. Part of that is the IOMMU as you said, but also the clocks and power domains that Linux will disable because are "unused". So to have a GOP framebuffer that will be available until the rockchip DRM fb emulation takes over (with the patch mentioned by Peter), you will need the following kernel command line options: initcall_blacklist=rk_iommu_init clk_ignore_unused pd_ignore_unused Best regards, Javier
[U-Boot] [PATCH] exynos: video: Enable stdout env var backward compatibility for LCD
Commit bb5930d5c97f ("exynos: video: Convert several boards to driver
model for video") converted the Exynos Chromebooks machines to use DM
for video, but this breaks backward compatibility with the stdout env
var since now stdout is expected to be "vidconsole" instead of "lcd".
This causes display to not work when updating u-boot on these boards
if the old stdout env var is used. Since these are consumer devices,
there's no easy way to have a serial console so users may be confused
thinking that u-boot failed to boot, or in the best case will need to
update the stdout env var blindly to make the display to work again.
There's a CONFIG_VIDCONSOLE_AS_LCD config option to workaround this,
so enable it in the Chromebooks' default configuration files to allow
users to change their stdout env var before the workaround is removed.
Suggested-by: Simon Glass
Signed-off-by: Javier Martinez Canillas
---
configs/peach-pi_defconfig | 1 +
configs/peach-pit_defconfig | 1 +
configs/snow_defconfig | 1 +
configs/spring_defconfig| 1 +
4 files changed, 4 insertions(+)
diff --git a/configs/peach-pi_defconfig b/configs/peach-pi_defconfig
index ef0211842138..fb933efc5a9c 100644
--- a/configs/peach-pi_defconfig
+++ b/configs/peach-pi_defconfig
@@ -60,5 +60,6 @@ CONFIG_DISPLAY=y
CONFIG_VIDEO_BRIDGE=y
CONFIG_VIDEO_BRIDGE_PARADE_PS862X=y
CONFIG_LCD=y
+CONFIG_VIDCONSOLE_AS_LCD=y
CONFIG_TPM=y
CONFIG_ERRNO_STR=y
diff --git a/configs/peach-pit_defconfig b/configs/peach-pit_defconfig
index 14fe00eb2a4d..cbac99dd8362 100644
--- a/configs/peach-pit_defconfig
+++ b/configs/peach-pit_defconfig
@@ -60,5 +60,6 @@ CONFIG_DISPLAY=y
CONFIG_VIDEO_BRIDGE=y
CONFIG_VIDEO_BRIDGE_PARADE_PS862X=y
CONFIG_LCD=y
+CONFIG_VIDCONSOLE_AS_LCD=y
CONFIG_TPM=y
CONFIG_ERRNO_STR=y
diff --git a/configs/snow_defconfig b/configs/snow_defconfig
index 47b498b6b2d9..ea0412a73f06 100644
--- a/configs/snow_defconfig
+++ b/configs/snow_defconfig
@@ -68,5 +68,6 @@ CONFIG_VIDEO_BRIDGE=y
CONFIG_VIDEO_BRIDGE_PARADE_PS862X=y
CONFIG_VIDEO_BRIDGE_NXP_PTN3460=y
CONFIG_LCD=y
+CONFIG_VIDCONSOLE_AS_LCD=y
CONFIG_TPM=y
CONFIG_ERRNO_STR=y
diff --git a/configs/spring_defconfig b/configs/spring_defconfig
index 4a782c80da8f..d20ac0b0e8ce 100644
--- a/configs/spring_defconfig
+++ b/configs/spring_defconfig
@@ -67,5 +67,6 @@ CONFIG_DISPLAY=y
CONFIG_VIDEO_BRIDGE=y
CONFIG_VIDEO_BRIDGE_PARADE_PS862X=y
CONFIG_LCD=y
+CONFIG_VIDCONSOLE_AS_LCD=y
CONFIG_TPM=y
CONFIG_ERRNO_STR=y
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] exynos5: Don't potentially undervoltage the CPU
Hello Sjoerd, On 01/10/2017 08:28 AM, Sjoerd Simons wrote: > For snow when chainloading u-boot the CPU seems to be running at full > speed. The lower CPU voltage seems to be ok for u-boot, but when booting > linux (bringing up all cores) I'm seeing random crashes. > > Bump the voltage up to a level that's safe for all cpu frequencies. > > Signed-off-by: Sjoerd Simons > > --- > Your patch looks good to me, 1.3V matches the operating point defined in the Exynos5250.dtsi for the maximum CPU frequency (1.7 GHz). Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] exynos: Enable XHCI on exynos5250 boards
Hello Sjoerd, On 01/10/2017 10:36 AM, Sjoerd Simons wrote: > Once upon a time u-boot didn't support building with two usb host > controller types, these days it does. Enable XHCI in addition to the > existing EHCI support so user can plug usb devices in all available > ports regardless of the controller type. > > Signed-off-by: Sjoerd Simons > Great, I didn't know u-boot now supported this! It was particularly confusing in Snow IIRC because the ChromiumOS vendor u-boot was built with XHCI support while mainline with EHCI by default. Reviewed-by: Javier Martinez Canillas -- Javier Martinez Canillas Open Source Group Samsung Research America ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 3/3] igep00x0: add Hynix timings
Hello Ladis, On Fri, Nov 4, 2016 at 8:59 AM, Ladislav Michl wrote: > Tested on IGEPv2 with Micron MT29F4G16ABBDA3W and > Hynix H27S4G6F2DKA-BM > > Signed-off-by: Ladislav Michl > --- Reviewed-by: Javier Martinez Canillas I don't have an IGEPv2 with Hynix to test, but everything is working correctly on my IGEPv2 board with a Micron NAND. Tested-by: Javier Martinez Canillas Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 2/3] igep00x0: consolidate defconfigs
Hello Ladis, On Fri, Nov 4, 2016 at 8:57 AM, Ladislav Michl wrote: > Defconfigs should remain the same except CONFIG_SYS_EXTRA_OPTIONS. > Drop NAND specific defconfig as flash type is runtime detected. > > Signed-off-by: Ladislav Michl > --- Reviewed-by: Javier Martinez Canillas I don't have an IGEP COM Module to test but the patch looks good to me. Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 1/3] igep00x0: disable CONFIG_DISPLAY_BOARDINFO
Hello Ladis, On Fri, Nov 4, 2016 at 8:55 AM, Ladislav Michl wrote: > As a single U-Boot binary can now run on various board modifications, > drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information > too early to give us chance to easily detect it. Also saves few bytes > as a bonus. > > Signed-off-by: Ladislav Michl > --- Patch looks good to me. Reviewed-by: Javier Martinez Canillas I've also tested on an IGEPv2 board: Tested-by: Javier Martinez Canillas Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 1/3] igep00x0: disable CONFIG_DISPLAY_BOARDINFO
Hello Ladis, On Fri, Nov 4, 2016 at 2:21 PM, Ladislav Michl wrote: > On Fri, Nov 04, 2016 at 12:42:57PM -0300, Javier Martinez Canillas wrote: >> Hello Ladis, >> >> On 11/04/2016 08:55 AM, Ladislav Michl wrote: >> > As a single U-Boot binary can now run on various board modifications, >> > drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information >> > too early to give us chance to easily detect it. Also saves few bytes >> > as a bonus. >> > >> > Signed-off-by: Ladislav Michl >> > --- >> >> I tried to test your patches on latest u-boot master (sha-1 dd93a8e9e688) >> but my IGEPv2 board fails to boot and prints in an infinite loop following: >> >> "ecc unrecoverable error" > > This comes from SPL, right? That would imply you boot from NAND... > >> This is not related to your patches though, since I've the same issue >> without your patches applied. >> >> Did you see this issue? u-boot works with previous v2016.09 release so >> this is a newly introduced regression. > > No, otherwise I would fix that. Care to send complete boot log if there is > any? > As talked on irc, this is because I don't have an UBI partition on my NAND. I've just commented the error messages for now to be able to boot since this is an unrelated issue. >> Unfortunately I don't have time to dig deeper on this but I may give a >> try next week. > > Thank you, > ladis Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] igep00x0: Use BCH8 ECC
Hello Ladislav, On Mon, Oct 12, 2015 at 6:09 PM, Ladislav Michl wrote: > Used NAND chips requires at least 4-bit error correction, so use BCH8 > as it is what kernel uses. > > Signed-off-by: Ladislav Michl > Thanks for the patch. It looks good to me. Acked-by: Javier Martinez Canillas Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 2/2] Odroid-XU3: Add documentation for Odroid-XU3
Hello Lukasz, On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski wrote: >> I have yet to take him up on that offer though, but it sounds like a >> good way forward. The current layout really isn't practical. >> > > It indeed isn't very practical, but this is what you received from > HardKernel when you buy XU3 board. > > Of course you can grab their sources, modify the layout, prepare > u-boot's SPL and send it to them to be signed. > However, it is not the way the "normal" user do things. > > He or she would like to replace standard (and outdated) HardKernel > u-boot on their SD card and go forward with booting kernel. > I agree with Sjoed that normal users don't replace the low-level components that are provided by the board vendor. After all you can boot a mainline kernel using the vendor u-boot, just append the DTB and create a uImage. The practical reason why someone would want to replace the vendor u-boot is to have more features but is very hard to do if there is a constraint in the maximum u-boot image size (even harder if the maximum is such small like in the XU3). > For now we _must_ focus on supporting XU3 with default BL1/BL2 and hence > we are obliged to have u-boot size smaller than 328 KiB. > > It is challenging but for sure doable. > It is doable but I don't see why the default BL2 _must_ be used. A user that wants to replace the kernel or u-boot is already tech-savy and can for sure replace the BL2 as well if it's publicly available. Maybe hardkernel folks can even make the modified BL2 available on their website and the link added in the comment explaining the layout? Also, it is an artificial constraint after all and can be easily modified. In fact I think we should push hardkernel to change that layout by default and use a BL2/SPL that has more sensible size for the u-boot binary even if they don't need it for their vendor u-boot which seems to be quite small. > Best regards, > Lukasz Majewski > Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v3 1/2] ARM: IGEP0033: rename config file to am335x_igep0033.h
On Thu, Oct 17, 2013 at 6:30 AM, Javier Martinez Canillas
wrote:
> From: Javier Martinez Canillas
>
> There seems to be a naming convention for the configuration
> files for boards using the same SoC family. This makes
> easier to do changes that affect different boards based
> on the same SoC.
>
> Since the IGEP COM AQUILA use TI AM335x processors, is better
> to rename its board config to use this naming scheme.
>
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Enric Balletbo i Serra
> ---
>
> Changes since v2:
> - Rebase patch to adapt to new boards.cfg file format.
>
> Changes since v1:
> - Fix some issues in the commit changelog pointed out by Enric Balletbo.
>
> boards.cfg| 2 +-
> include/configs/{igep0033.h => am335x_igep0033.h} | 0
> 2 files changed, 1 insertion(+), 1 deletion(-)
> rename include/configs/{igep0033.h => am335x_igep0033.h} (100%)
>
> diff --git a/boards.cfg b/boards.cfg
> index aa2ee64..c8b7868 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -246,7 +246,7 @@ Active arm arm946es - armltd
> integrator
> Active arm armv7 - armltd vexpress
> vexpress_ca15_tc2-
>
> -
> Active arm armv7 - armltd vexpress
> vexpress_ca5x2 -
>
> Matt Waddel
> Active arm armv7 - armltd vexpress
> vexpress_ca9x4 -
>
> Matt Waddel
> -Active arm armv7 am33xx iseeigep0033
> igep0033 -
>
> Enric Balletbo i Serra
> +Active arm armv7 am33xx iseeigep0033
> am335x_igep0033 -
>
> Enric Balletbo i Serra
> Active arm armv7 am33xx phytec pcm051
> pcm051 pcm051
>
> Lars Poeschel
> Active arm armv7 am33xx siemens dxr2
> dxr2 -
>
> Roger Meier
> Active arm armv7 am33xx siemens pxm2
> pxm2 -
>
> Roger Meier
> diff --git a/include/configs/igep0033.h b/include/configs/am335x_igep0033.h
> similarity index 100%
> rename from include/configs/igep0033.h
> rename to include/configs/am335x_igep0033.h
> --
> 1.8.4.rc3
>
Hi Tom,
Any comments on these patches?
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v3 1/2] ARM: IGEP0033: rename config file to am335x_igep0033.h
From: Javier Martinez Canillas
There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.
Since the IGEP COM AQUILA use TI AM335x processors, is better
to rename its board config to use this naming scheme.
Signed-off-by: Javier Martinez Canillas
Acked-by: Enric Balletbo i Serra
---
Changes since v2:
- Rebase patch to adapt to new boards.cfg file format.
Changes since v1:
- Fix some issues in the commit changelog pointed out by Enric Balletbo.
boards.cfg| 2 +-
include/configs/{igep0033.h => am335x_igep0033.h} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename include/configs/{igep0033.h => am335x_igep0033.h} (100%)
diff --git a/boards.cfg b/boards.cfg
index aa2ee64..c8b7868 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -246,7 +246,7 @@ Active arm arm946es - armltd
integrator
Active arm armv7 - armltd vexpress
vexpress_ca15_tc2-
-
Active arm armv7 - armltd vexpress
vexpress_ca5x2 -
Matt Waddel
Active arm armv7 - armltd vexpress
vexpress_ca9x4 -
Matt Waddel
-Active arm armv7 am33xx iseeigep0033
igep0033 -
Enric Balletbo i Serra
+Active arm armv7 am33xx iseeigep0033
am335x_igep0033 -
Enric Balletbo i Serra
Active arm armv7 am33xx phytec pcm051
pcm051 pcm051
Lars Poeschel
Active arm armv7 am33xx siemens dxr2
dxr2 -
Roger Meier
Active arm armv7 am33xx siemens pxm2
pxm2 -
Roger Meier
diff --git a/include/configs/igep0033.h b/include/configs/am335x_igep0033.h
similarity index 100%
rename from include/configs/igep0033.h
rename to include/configs/am335x_igep0033.h
--
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v3 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
From: Javier Martinez Canillas
There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.
Since the IGEPv2 board and the IGEP COM Module use a TI
OMAP35xx/DM37xx processor, is better to rename its board
config to use this naming scheme.
Signed-off-by: Javier Martinez Canillas
Acked-by: Enric Balletbo i Serra
---
Changes since v2:
- Rebase patch to adapt to new boards.cfg file format.
Changes since v1:
- Fix some issues in the commit changelog pointed out by Enric Balletbo.
boards.cfg | 10 +-
include/configs/{igep00x0.h => omap3_igep00x0.h} | 0
2 files changed, 5 insertions(+), 5 deletions(-)
rename include/configs/{igep00x0.h => omap3_igep00x0.h} (100%)
diff --git a/boards.cfg b/boards.cfg
index c8b7868..3d35308 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -311,11 +311,11 @@ Active arm armv7 omap3 comelit
dig297
Active arm armv7 omap3 compulabcm_t35
cm_t35 -
Igor Grinberg
Active arm armv7 omap3 corscience tricorder
tricorder-
Thomas Weber
Active arm armv7 omap3 htkwmcx
mcx -
Ilya Yanok
-Active arm armv7 omap3 iseeigep00x0
igep0020
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
Enric Balletbo i Serra
-Active arm armv7 omap3 iseeigep00x0
igep0020_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
-
-Active arm armv7 omap3 iseeigep00x0
igep0030
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
Enric Balletbo i Serra
-Active arm armv7 omap3 iseeigep00x0
igep0030_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
-
-Active arm armv7 omap3 iseeigep00x0
igep0032
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
Enric Balletbo i Serra
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0020
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
Enric Balletbo i Serra
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0020_nand
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
-
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0030
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
Enric Balletbo i Serra
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0030_nand
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
-
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0032
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
Enric Balletbo i Serra
Active arm armv7 omap3 logicpd am3517evm
am3517_evm -
Vaibhav Hiremath
Active arm armv7 omap3 logicpd omap3som
omap3
[U-Boot] [PATCH v3 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.
Since the IGEPv2 board and the IGEP COM Module use a TI
OMAP35xx/DM37xx processor, is better to rename its board
config to use this naming scheme.
Signed-off-by: Javier Martinez Canillas
Acked-by: Enric Balletbo i Serra
---
Changes since v2:
- Rebase patch to adapt to new boards.cfg file format.
Changes since v1:
- Fix some issues in the commit changelog pointed out by Enric Balletbo.
boards.cfg | 10 +-
include/configs/{igep00x0.h => omap3_igep00x0.h} | 0
2 files changed, 5 insertions(+), 5 deletions(-)
rename include/configs/{igep00x0.h => omap3_igep00x0.h} (100%)
diff --git a/boards.cfg b/boards.cfg
index 310c034..075c81c 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -307,11 +307,11 @@ Active arm armv7 omap3 comelit
dig297
Active arm armv7 omap3 compulabcm_t35
cm_t35 -
Igor Grinberg
Active arm armv7 omap3 corscience tricorder
tricorder-
Thomas Weber
Active arm armv7 omap3 htkwmcx
mcx -
Ilya Yanok
-Active arm armv7 omap3 iseeigep00x0
igep0020
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
Enric Balletbo i Serra
-Active arm armv7 omap3 iseeigep00x0
igep0020_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
-
-Active arm armv7 omap3 iseeigep00x0
igep0030
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
Enric Balletbo i Serra
-Active arm armv7 omap3 iseeigep00x0
igep0030_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
-
-Active arm armv7 omap3 iseeigep00x0
igep0032
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
Enric Balletbo i Serra
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0020
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
Enric Balletbo i Serra
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0020_nand
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
-
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0030
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
Enric Balletbo i Serra
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0030_nand
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
-
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0032
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
Enric Balletbo i Serra
Active arm armv7 omap3 logicpd am3517evm
am3517_evm -
Vaibhav Hiremath
Active arm armv7 omap3 logicpd omap3som
omap3
[U-Boot] [PATCH v3 1/2] ARM: IGEP0033: rename config file to am335x_igep0033.h
There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.
Since the IGEP COM AQUILA use TI AM335x processors, is better
to rename its board config to use this naming scheme.
Signed-off-by: Javier Martinez Canillas
Acked-by: Enric Balletbo i Serra
---
Changes since v2:
- Rebase patch to adapt to new boards.cfg file format.
Changes since v1:
- Fix some issues in the commit changelog pointed out by Enric Balletbo.
boards.cfg| 2 +-
include/configs/{igep0033.h => am335x_igep0033.h} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename include/configs/{igep0033.h => am335x_igep0033.h} (100%)
diff --git a/boards.cfg b/boards.cfg
index dbd8479..310c034 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -243,7 +243,7 @@ Active arm arm946es - armltd
integrator
Active arm armv7 - armltd vexpress
vexpress_ca15_tc2-
-
Active arm armv7 - armltd vexpress
vexpress_ca5x2 -
Matt Waddel
Active arm armv7 - armltd vexpress
vexpress_ca9x4 -
Matt Waddel
-Active arm armv7 am33xx iseeigep0033
igep0033 -
Enric Balletbo i Serra
+Active arm armv7 am33xx iseeigep0033
am335x_igep0033 -
Enric Balletbo i Serra
Active arm armv7 am33xx phytec pcm051
pcm051 pcm051
Lars Poeschel
Active arm armv7 am33xx siemens dxr2
dxr2 -
Roger Meier
Active arm armv7 am33xx siemens pxm2
pxm2 -
Roger Meier
diff --git a/include/configs/igep0033.h b/include/configs/am335x_igep0033.h
similarity index 100%
rename from include/configs/igep0033.h
rename to include/configs/am335x_igep0033.h
--
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] ARM: IGEP0033: rename config file to am335x_igep0033.h
There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.
Since the IGEP COM AQUILA use TI AM335x processors, is better
to rename its board config to use this naming scheme.
Signed-off-by: Javier Martinez Canillas
Acked-by: Enric Balletbo i Serra
---
Changes since v2:
- Rebase patch to adapt to new boards.cfg file format.
Changes since v1:
- Fix some issues in the commit changelog pointed out by Enric Balletbo.
boards.cfg| 2 +-
include/configs/{igep0033.h => am335x_igep0033.h} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename include/configs/{igep0033.h => am335x_igep0033.h} (100%)
diff --git a/boards.cfg b/boards.cfg
index dbd8479..310c034 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -243,7 +243,7 @@ Active arm arm946es - armltd
integrator
Active arm armv7 - armltd vexpress
vexpress_ca15_tc2-
-
Active arm armv7 - armltd vexpress
vexpress_ca5x2 -
Matt Waddel
Active arm armv7 - armltd vexpress
vexpress_ca9x4 -
Matt Waddel
-Active arm armv7 am33xx iseeigep0033
igep0033 -
Enric Balletbo i Serra
+Active arm armv7 am33xx iseeigep0033
am335x_igep0033 -
Enric Balletbo i Serra
Active arm armv7 am33xx phytec pcm051
pcm051 pcm051
Lars Poeschel
Active arm armv7 am33xx siemens dxr2
dxr2 -
Roger Meier
Active arm armv7 am33xx siemens pxm2
pxm2 -
Roger Meier
diff --git a/include/configs/igep0033.h b/include/configs/am335x_igep0033.h
similarity index 100%
rename from include/configs/igep0033.h
rename to include/configs/am335x_igep0033.h
--
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.
Since the IGEPv2 board and the IGEP COM Module use a TI
OMAP35xx/DM37xx processor, is better to rename its board
config to use this naming scheme.
Signed-off-by: Javier Martinez Canillas
Acked-by: Enric Balletbo i Serra
---
Changes since v2:
- Rebase patch to adapt to new boards.cfg file format.
Changes since v1:
- Fix some issues in the commit changelog pointed out by Enric Balletbo.
boards.cfg | 10 +-
include/configs/{igep00x0.h => omap3_igep00x0.h} | 0
2 files changed, 5 insertions(+), 5 deletions(-)
rename include/configs/{igep00x0.h => omap3_igep00x0.h} (100%)
diff --git a/boards.cfg b/boards.cfg
index 310c034..075c81c 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -307,11 +307,11 @@ Active arm armv7 omap3 comelit
dig297
Active arm armv7 omap3 compulabcm_t35
cm_t35 -
Igor Grinberg
Active arm armv7 omap3 corscience tricorder
tricorder-
Thomas Weber
Active arm armv7 omap3 htkwmcx
mcx -
Ilya Yanok
-Active arm armv7 omap3 iseeigep00x0
igep0020
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
Enric Balletbo i Serra
-Active arm armv7 omap3 iseeigep00x0
igep0020_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
-
-Active arm armv7 omap3 iseeigep00x0
igep0030
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
Enric Balletbo i Serra
-Active arm armv7 omap3 iseeigep00x0
igep0030_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
-
-Active arm armv7 omap3 iseeigep00x0
igep0032
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
Enric Balletbo i Serra
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0020
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
Enric Balletbo i Serra
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0020_nand
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
-
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0030
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
Enric Balletbo i Serra
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0030_nand
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
-
+Active arm armv7 omap3 iseeigep00x0
omap3_igep0032
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
Enric Balletbo i Serra
Active arm armv7 omap3 logicpd am3517evm
am3517_evm -
Vaibhav Hiremath
Active arm armv7 omap3 logicpd omap3som
omap3
Re: [U-Boot] [PATCH v2 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
On 09/19/2013 05:00 PM, Igor Grinberg wrote:
> Hi Javier,
>
> On 09/19/2013 04:04 PM, Javier Martinez Canillas wrote:
>> On Mon, Sep 2, 2013 at 1:52 PM, Enric Balletbo Serra
>> wrote:
>>> 2013/9/2 Javier Martinez Canillas :
>>>> There seems to be a naming convention for the configuration
>>>> files for boards using the same SoC family. This makes
>>>> easier to do changes that affect different boards based
>>>> on the same SoC.
>>>>
>>>> Since the IGEPv2 board and the IGEP COM Module use a TI
>>>> OMAP35xx/DM37xx processor, is better to rename its board
>>>> config to use this naming scheme.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas
>>>> ---
>>>>
>>>> Changes since v1:
>>>> - Fix some issues in the commit changelog pointed out by Enric Balletbo.
>>>>
>>>> boards.cfg | 10 +-
>>>> include/configs/igep00x0.h | 370
>>>> ---
>>>> include/configs/omap3_igep00x0.h | 370
>>>> +++
>>>> 3 files changed, 375 insertions(+), 375 deletions(-)
>>>> delete mode 100644 include/configs/igep00x0.h
>>>> create mode 100644 include/configs/omap3_igep00x0.h
>>>>
>>>> diff --git a/boards.cfg b/boards.cfg
>>>> index d717226..8f1cb6e 100644
>>>> --- a/boards.cfg
>>>> +++ b/boards.cfg
>>>> @@ -297,11 +297,11 @@ omap3_overo arm armv7
>>>> overo -
>>>> omap3_pandoraarm armv7 pandora
>>>> - omap3
>>>> dig297 arm armv7 dig297
>>>> comelitomap3
>>>> cm_t35 arm armv7 cm_t35
>>>> compulab omap3
>>>> -igep0020 arm armv7 igep00x0
>>>> isee omap3
>>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
>>>> -igep0020_nandarm armv7 igep00x0
>>>> isee omap3
>>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
>>>> -igep0030 arm armv7 igep00x0
>>>> isee omap3
>>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
>>>> -igep0030_nandarm armv7 igep00x0
>>>> isee omap3
>>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
>>>> -igep0032 arm armv7 igep00x0
>>>> isee omap3
>>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
>>>> +omap3_igep0020 arm armv7 igep00x0
>>>> isee omap3
>>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
>>>> +omap3_igep0020_nand arm armv7 igep00x0
>>>> isee omap3
>>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
>>>> +omap3_igep0030 arm armv7 igep00x0
>>>> isee omap3
>>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
>>>> +omap3_igep0030_nand arm armv7 igep00x0
>>>> isee omap3
>>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
>>>> +omap3_igep0032 arm armv7 igep00x0
>>>> isee omap3
>>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
>>>> am335x_igep0033 arm armv7 igep0033
>>>> isee am33xx
>>>> am3517_evm arm armv7 am3517evm
>>>> logicpdomap3
>>>> mt_ventoux arm armv7 mt_ventoux
>>>> teejet omap3
>>
>>> Acked-by: Enric Balletbo i Serra
>>
>> These patches don't apply on master anymore after commit 27af930e9
>> ("Merge and reformat boards.cfg and MAINTAINERS"). I'll rebase the
>> patches and repost.
>
> If you are about to repost, can you please add '-M' flag to
> git format-patch command (if you use this command).
> This will detect renames and lower the patch size...
>
Hi Igor,
Yes I do use git format-patch and I'll use -M for the next version.
Thanks for the feedback and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
On Thu, Sep 19, 2013 at 5:13 PM, Javier Martinez Canillas
wrote:
> On 09/19/2013 05:00 PM, Igor Grinberg wrote:
>> Hi Javier,
>>
>> On 09/19/2013 04:04 PM, Javier Martinez Canillas wrote:
>>> On Mon, Sep 2, 2013 at 1:52 PM, Enric Balletbo Serra
>>> wrote:
>>>> 2013/9/2 Javier Martinez Canillas :
>>>>> There seems to be a naming convention for the configuration
>>>>> files for boards using the same SoC family. This makes
>>>>> easier to do changes that affect different boards based
>>>>> on the same SoC.
>>>>>
>>>>> Since the IGEPv2 board and the IGEP COM Module use a TI
>>>>> OMAP35xx/DM37xx processor, is better to rename its board
>>>>> config to use this naming scheme.
>>>>>
>>>>> Signed-off-by: Javier Martinez Canillas
>>>>> ---
>>>>>
>>>>> Changes since v1:
>>>>> - Fix some issues in the commit changelog pointed out by Enric Balletbo.
>>>>>
>>>>> boards.cfg | 10 +-
>>>>> include/configs/igep00x0.h | 370
>>>>> ---
>>>>> include/configs/omap3_igep00x0.h | 370
>>>>> +++
>>>>> 3 files changed, 375 insertions(+), 375 deletions(-)
>>>>> delete mode 100644 include/configs/igep00x0.h
>>>>> create mode 100644 include/configs/omap3_igep00x0.h
>>>>>
>>>>> diff --git a/boards.cfg b/boards.cfg
>>>>> index d717226..8f1cb6e 100644
>>>>> --- a/boards.cfg
>>>>> +++ b/boards.cfg
>>>>> @@ -297,11 +297,11 @@ omap3_overo arm armv7
>>>>> overo -
>>>>> omap3_pandoraarm armv7 pandora
>>>>> - omap3
>>>>> dig297 arm armv7 dig297
>>>>> comelitomap3
>>>>> cm_t35 arm armv7 cm_t35
>>>>> compulab omap3
>>>>> -igep0020 arm armv7 igep00x0
>>>>> isee omap3
>>>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
>>>>> -igep0020_nandarm armv7 igep00x0
>>>>> isee omap3
>>>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
>>>>> -igep0030 arm armv7 igep00x0
>>>>> isee omap3
>>>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
>>>>> -igep0030_nandarm armv7 igep00x0
>>>>> isee omap3
>>>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
>>>>> -igep0032 arm armv7 igep00x0
>>>>> isee omap3
>>>>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
>>>>> +omap3_igep0020 arm armv7 igep00x0
>>>>> isee omap3
>>>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
>>>>> +omap3_igep0020_nand arm armv7 igep00x0
>>>>> isee omap3
>>>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
>>>>> +omap3_igep0030 arm armv7 igep00x0
>>>>> isee omap3
>>>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
>>>>> +omap3_igep0030_nand arm armv7 igep00x0
>>>>> isee omap3
>>>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
>>>>> +omap3_igep0032 arm armv7 igep00x0
>>>>> isee omap3
>>>>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
>>>>> am335x_igep0033 arm armv7 igep0033
>>>>> isee am33xx
>>>>> am3517_evm arm armv7 am3517evm
>>>>> logicpdomap3
>>>>> mt_ventoux arm armv7 mt_ventoux
>>>>> teejet omap3
>>>
>>>> Acked-by: Enric Balletbo i Serra
>>>
>>> These patches don't apply on master anymore after commit 27af930e9
>>> ("Merge and reformat boards.cfg and MAINTAINERS"). I'll rebase the
>>> patches and repost.
>>
>> If you are about to repost, can you please add '-M' flag to
>> git format-patch command (if you use this command).
>> This will detect renames and lower the patch size...
>>
>
> Hi Igor,
>
> Yes I do use git format-patch and I'll use -M for the next version.
>
> Thanks for the feedback and best regards,
> Javier
Hi Igor,
Yes I do use git format-patch and I'll use -M for the next version.
Thanks for the feedback and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
On Mon, Sep 2, 2013 at 1:52 PM, Enric Balletbo Serra
wrote:
> 2013/9/2 Javier Martinez Canillas :
>> There seems to be a naming convention for the configuration
>> files for boards using the same SoC family. This makes
>> easier to do changes that affect different boards based
>> on the same SoC.
>>
>> Since the IGEPv2 board and the IGEP COM Module use a TI
>> OMAP35xx/DM37xx processor, is better to rename its board
>> config to use this naming scheme.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>>
>> Changes since v1:
>> - Fix some issues in the commit changelog pointed out by Enric Balletbo.
>>
>> boards.cfg | 10 +-
>> include/configs/igep00x0.h | 370
>> ---
>> include/configs/omap3_igep00x0.h | 370
>> +++
>> 3 files changed, 375 insertions(+), 375 deletions(-)
>> delete mode 100644 include/configs/igep00x0.h
>> create mode 100644 include/configs/omap3_igep00x0.h
>>
>> diff --git a/boards.cfg b/boards.cfg
>> index d717226..8f1cb6e 100644
>> --- a/boards.cfg
>> +++ b/boards.cfg
>> @@ -297,11 +297,11 @@ omap3_overo arm armv7
>> overo -
>> omap3_pandoraarm armv7 pandora -
>> omap3
>> dig297 arm armv7 dig297
>> comelitomap3
>> cm_t35 arm armv7 cm_t35
>> compulab omap3
>> -igep0020 arm armv7 igep00x0
>> isee omap3
>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
>> -igep0020_nandarm armv7 igep00x0
>> isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
>> -igep0030 arm armv7 igep00x0
>> isee omap3
>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
>> -igep0030_nandarm armv7 igep00x0
>> isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
>> -igep0032 arm armv7 igep00x0
>> isee omap3
>> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
>> +omap3_igep0020 arm armv7 igep00x0
>> isee omap3
>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
>> +omap3_igep0020_nand arm armv7 igep00x0
>> isee omap3
>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
>> +omap3_igep0030 arm armv7 igep00x0
>> isee omap3
>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
>> +omap3_igep0030_nand arm armv7 igep00x0
>> isee omap3
>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
>> +omap3_igep0032 arm armv7 igep00x0
>> isee omap3
>> omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
>> am335x_igep0033 arm armv7 igep0033
>> isee am33xx
>> am3517_evm arm armv7 am3517evm
>> logicpdomap3
>> mt_ventoux arm armv7 mt_ventoux
>> teejet omap3
> Acked-by: Enric Balletbo i Serra
These patches don't apply on master anymore after commit 27af930e9
("Merge and reformat boards.cfg and MAINTAINERS"). I'll rebase the
patches and repost.
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: IGEP0033: Update timing to run DDR at 400MHz.
On Tue, Sep 10, 2013 at 11:12 AM, Enric Balletbo i Serra
wrote:
> From: Enric Balletbo i Serra
>
> We can run the DDR at 400MHz, so update the timings for that purpose.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> arch/arm/include/asm/arch-am33xx/ddr_defs.h | 24
> board/isee/igep0033/board.c | 4 ++--
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> index 95f7a9a..fe48b5f 100644
> --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> @@ -110,20 +110,20 @@
> #define MT41J512M8RH125_IOCTRL_VALUE 0x18B
>
> /* Samsung K4B2G1646E-BIH9 */
> -#define K4B2G1646EBIH9_EMIF_READ_LATENCY 0x06
> -#define K4B2G1646EBIH9_EMIF_TIM1 0x0888A39B
> -#define K4B2G1646EBIH9_EMIF_TIM2 0x2A04011A
> -#define K4B2G1646EBIH9_EMIF_TIM3 0x501F820F
> -#define K4B2G1646EBIH9_EMIF_SDCFG 0x61C24AB2
> -#define K4B2G1646EBIH9_EMIF_SDREF 0x093B
> +#define K4B2G1646EBIH9_EMIF_READ_LATENCY 0x07
> +#define K4B2G1646EBIH9_EMIF_TIM1 0x0AAAE51B
> +#define K4B2G1646EBIH9_EMIF_TIM2 0x2A1D7FDA
> +#define K4B2G1646EBIH9_EMIF_TIM3 0x501F83FF
> +#define K4B2G1646EBIH9_EMIF_SDCFG 0x61C052B2
> +#define K4B2G1646EBIH9_EMIF_SDREF 0x0C30
> #define K4B2G1646EBIH9_ZQ_CFG 0x50074BE4
> #define K4B2G1646EBIH9_DLL_LOCK_DIFF 0x1
> -#define K4B2G1646EBIH9_RATIO 0x40
> -#define K4B2G1646EBIH9_INVERT_CLKOUT 0x1
> -#define K4B2G1646EBIH9_RD_DQS 0x3B
> -#define K4B2G1646EBIH9_WR_DQS 0x85
> -#define K4B2G1646EBIH9_PHY_FIFO_WE 0x100
> -#define K4B2G1646EBIH9_PHY_WR_DATA 0xC1
> +#define K4B2G1646EBIH9_RATIO 0x80
> +#define K4B2G1646EBIH9_INVERT_CLKOUT 0x0
> +#define K4B2G1646EBIH9_RD_DQS 0x35
> +#define K4B2G1646EBIH9_WR_DQS 0x3A
> +#define K4B2G1646EBIH9_PHY_FIFO_WE 0x97
> +#define K4B2G1646EBIH9_PHY_WR_DATA 0x76
> #define K4B2G1646EBIH9_IOCTRL_VALUE0x18B
>
> /**
> diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
> index 9e91f68..a9c34c6 100644
> --- a/board/isee/igep0033/board.c
> +++ b/board/isee/igep0033/board.c
> @@ -64,7 +64,7 @@ static struct emif_regs ddr3_emif_reg_data = {
>
> #define OSC(V_OSCK/100)
> const struct dpll_params dpll_ddr = {
> - 303, OSC-1, 1, -1, -1, -1, -1};
> + 400, OSC-1, 1, -1, -1, -1, -1};
>
> const struct dpll_params *get_dpll_ddr_params(void)
> {
> @@ -83,7 +83,7 @@ void set_mux_conf_regs(void)
>
> void sdram_init(void)
> {
> - config_ddr(303, K4B2G1646EBIH9_IOCTRL_VALUE, &ddr3_data,
> + config_ddr(400, K4B2G1646EBIH9_IOCTRL_VALUE, &ddr3_data,
>&ddr3_cmd_ctrl_data, &ddr3_emif_reg_data, 0);
> }
> #endif
> --
> 1.8.1.2
>
Reviewed-by: Javier Martinez Canillas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
There seems to be a naming convention for the configuration files for boards using the same SoC family. This makes easier to do changes that affect different boards based on the same SoC. Since the IGEPv2 board and the IGEP COM Module use a TI OMAP35xx/DM37xx processor, is better to rename its board config to use this naming scheme. Signed-off-by: Javier Martinez Canillas --- Changes since v1: - Fix some issues in the commit changelog pointed out by Enric Balletbo. boards.cfg | 10 +- include/configs/igep00x0.h | 370 --- include/configs/omap3_igep00x0.h | 370 +++ 3 files changed, 375 insertions(+), 375 deletions(-) delete mode 100644 include/configs/igep00x0.h create mode 100644 include/configs/omap3_igep00x0.h diff --git a/boards.cfg b/boards.cfg index d717226..8f1cb6e 100644 --- a/boards.cfg +++ b/boards.cfg @@ -297,11 +297,11 @@ omap3_overo arm armv7 overo - omap3_pandoraarm armv7 pandora - omap3 dig297 arm armv7 dig297 comelitomap3 cm_t35 arm armv7 cm_t35 compulab omap3 -igep0020 arm armv7 igep00x0isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND -igep0020_nandarm armv7 igep00x0isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND -igep0030 arm armv7 igep00x0isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND -igep0030_nandarm armv7 igep00x0isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND -igep0032 arm armv7 igep00x0isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND +omap3_igep0020 arm armv7 igep00x0isee omap3 omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND +omap3_igep0020_nand arm armv7 igep00x0isee omap3 omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND +omap3_igep0030 arm armv7 igep00x0isee omap3 omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND +omap3_igep0030_nand arm armv7 igep00x0isee omap3 omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND +omap3_igep0032 arm armv7 igep00x0isee omap3 omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND am335x_igep0033 arm armv7 igep0033isee am33xx am3517_evm arm armv7 am3517evm logicpdomap3 mt_ventoux arm armv7 mt_ventoux teejet omap3 diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h deleted file mode 100644 index 9982cf6..000 --- a/include/configs/igep00x0.h +++ /dev/null @@ -1,370 +0,0 @@ -/* - * Common configuration settings for IGEP technology based boards - * - * (C) Copyright 2012 - * ISEE 2007 SL, - * - * SPDX-License-Identifier:GPL-2.0+ - */ - -#ifndef __IGEP00X0_H -#define __IGEP00X0_H - -#include - -/* - * High Level Configuration Options - */ -#define CONFIG_OMAP1 /* in a TI OMAP core */ -#define CONFIG_OMAP34XX1 /* which is a 34XX */ -#define CONFIG_OMAP_GPIO -#define CONFIG_OMAP_COMMON - -#define CONFIG_SDRC/* The chip has SDRC controller */ - -#include -#include -#include - -/* - * Display CPU and Board information - */ -#define CONFIG_DISPLAY_CPUINFO 1 -#define CONFIG_DISPLAY_BOARDINFO 1 - -/* Clock Defines */ -#define V_OSCK 2600/* Clock output from T2 */ -#define V_SCLK (V_OSCK >> 1) - -#define CONFIG_MISC_INIT_R - -#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ -#define CONFIG_SETUP_MEMORY_TAGS 1 -#define CONFIG_INITRD_TAG 1 -#define CONFIG_REVISION_TAG1 - -#define CONFIG_OF_LIBFDT -#define CONFIG_CMD_BOOTZ -#define CONFIG_SUPPORT_RAW_INITRD - -/* - * NS16550 Configuration - */ - -#define V_NS16550_CLK 4800/* 48MHz (APLL96/2) */ - -#define CONFIG_SYS_NS16550 -#define CONFIG_SYS_NS16550_SERIAL -#define CONFIG_SYS_NS16550_REG_SIZE(-4) -#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK - -/* select serial console configuration */ -#define CONFIG_CONS_INDEX 3 -#define CONFIG_SYS_NS16550_COM3OMAP34XX_UART3 -#define CONFIG_S
[U-Boot] [PATCH 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h
There seems to be a naming convention for the configuration files for boards using the same SoC family. This makes easier to do changes that affect different boards based on the same SoC. Since the IGEP COM AQUILA use an AM3352/AM3354 processor is better to rename its board config to use this naming scheme. Since the IGEPv2 board and the IGEP COM Module use an OMAP3735/OMAP3735 processor is better to rename its board config to use this naming scheme. Signed-off-by: Javier Martinez Canillas --- boards.cfg | 10 +- include/configs/igep00x0.h | 370 -- include/configs/omap3_igep00x0.h | 370 ++ 3 files changed, 375 insertions(+), 375 deletions(-) delete mode 100644 include/configs/igep00x0.h create mode 100644 include/configs/omap3_igep00x0.h diff --git a/boards.cfg b/boards.cfg index d717226..8f1cb6e 100644 --- a/boards.cfg +++ b/boards.cfg @@ -297,11 +297,11 @@ omap3_overo arm armv7 overo - omap3_pandoraarm armv7 pandora - omap3 dig297 arm armv7 dig297 comelitomap3 cm_t35 arm armv7 cm_t35 compulab omap3 -igep0020 arm armv7 igep00x0isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND -igep0020_nandarm armv7 igep00x0isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND -igep0030 arm armv7 igep00x0isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND -igep0030_nandarm armv7 igep00x0isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND -igep0032 arm armv7 igep00x0isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND +omap3_igep0020 arm armv7 igep00x0isee omap3 omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND +omap3_igep0020_nand arm armv7 igep00x0isee omap3 omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND +omap3_igep0030 arm armv7 igep00x0isee omap3 omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND +omap3_igep0030_nand arm armv7 igep00x0isee omap3 omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND +omap3_igep0032 arm armv7 igep00x0isee omap3 omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND am335x_igep0033 arm armv7 igep0033isee am33xx am3517_evm arm armv7 am3517evm logicpdomap3 mt_ventoux arm armv7 mt_ventoux teejet omap3 diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h deleted file mode 100644 index 9982cf6..000 --- a/include/configs/igep00x0.h +++ /dev/null @@ -1,370 +0,0 @@ -/* - * Common configuration settings for IGEP technology based boards - * - * (C) Copyright 2012 - * ISEE 2007 SL, - * - * SPDX-License-Identifier:GPL-2.0+ - */ - -#ifndef __IGEP00X0_H -#define __IGEP00X0_H - -#include - -/* - * High Level Configuration Options - */ -#define CONFIG_OMAP1 /* in a TI OMAP core */ -#define CONFIG_OMAP34XX1 /* which is a 34XX */ -#define CONFIG_OMAP_GPIO -#define CONFIG_OMAP_COMMON - -#define CONFIG_SDRC/* The chip has SDRC controller */ - -#include -#include -#include - -/* - * Display CPU and Board information - */ -#define CONFIG_DISPLAY_CPUINFO 1 -#define CONFIG_DISPLAY_BOARDINFO 1 - -/* Clock Defines */ -#define V_OSCK 2600/* Clock output from T2 */ -#define V_SCLK (V_OSCK >> 1) - -#define CONFIG_MISC_INIT_R - -#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ -#define CONFIG_SETUP_MEMORY_TAGS 1 -#define CONFIG_INITRD_TAG 1 -#define CONFIG_REVISION_TAG1 - -#define CONFIG_OF_LIBFDT -#define CONFIG_CMD_BOOTZ -#define CONFIG_SUPPORT_RAW_INITRD - -/* - * NS16550 Configuration - */ - -#define V_NS16550_CLK 4800/* 48MHz (APLL96/2) */ - -#define CONFIG_SYS_NS16550 -#define CONFIG_SYS_NS16550_SERIAL -#define CONFIG_SYS_NS16550_REG_SIZE(-4) -#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK - -/* select serial console configuration */ -#define CONFIG_CONS_INDEX 3 -#define CONFIG_SYS_NS16550_COM3OMAP34XX
[U-Boot] [PATCH 1/2] ARM: IGEP0033: rename config file to am335x_igep0033.h
There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.
Since the IGEP COM AQUILA use an AM3352/AM3354 processor is
better to rename its board config to use this naming scheme.
Signed-off-by: Javier Martinez Canillas
---
boards.cfg|2 +-
include/configs/am335x_igep0033.h | 291 +
include/configs/igep0033.h| 291 -
3 files changed, 292 insertions(+), 292 deletions(-)
create mode 100644 include/configs/am335x_igep0033.h
delete mode 100644 include/configs/igep0033.h
diff --git a/boards.cfg b/boards.cfg
index 7ccc7ce..d717226 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -302,7 +302,7 @@ igep0020_nandarm armv7
igep00x0isee
igep0030 arm armv7 igep00x0isee
omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
igep0030_nandarm armv7 igep00x0isee
omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
igep0032 arm armv7 igep00x0isee
omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
-igep0033 arm armv7 igep0033isee
am33xx
+am335x_igep0033 arm armv7 igep0033isee
am33xx
am3517_evm arm armv7 am3517evm
logicpdomap3
mt_ventoux arm armv7 mt_ventoux
teejet omap3
omap3_zoom1 arm armv7 zoom1
logicpdomap3
diff --git a/include/configs/am335x_igep0033.h
b/include/configs/am335x_igep0033.h
new file mode 100644
index 000..e08fc14
--- /dev/null
+++ b/include/configs/am335x_igep0033.h
@@ -0,0 +1,291 @@
+/*
+ * Copyright (C) 2013, ISEE 2007 SL - http://www.isee.biz/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __CONFIG_IGEP0033_H
+#define __CONFIG_IGEP0033_H
+
+#define CONFIG_AM33XX
+#define CONFIG_OMAP
+#define CONFIG_OMAP_COMMON
+
+#include
+
+/* Mach type */
+#define MACH_TYPE_IGEP0033 4521/* Until the next sync */
+#define CONFIG_MACH_TYPE MACH_TYPE_IGEP0033
+
+/* Clock defines */
+#define V_OSCK 2400 /* Clock output from T2 */
+#define V_SCLK (V_OSCK)
+
+#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB */
+#define CONFIG_SYS_MALLOC_LEN (1024 << 10)
+#define CONFIG_SYS_LONGHELP/* undef to save memory */
+#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */
+#define CONFIG_SYS_PROMPT "U-Boot# "
+#define CONFIG_SYS_NO_FLASH
+
+/* Display cpuinfo */
+#define CONFIG_DISPLAY_CPUINFO
+
+/* Flattened Device Tree */
+#define CONFIG_OF_LIBFDT
+
+/* Commands to include */
+#include
+
+#define CONFIG_CMD_ASKENV
+#define CONFIG_CMD_BOOTZ
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_ECHO
+#define CONFIG_CMD_EXT4
+#define CONFIG_CMD_FAT
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_MMC
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_CMD_NAND
+#define CONFIG_CMD_NET
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_UBI
+#define CONFIG_CMD_UBIFS
+
+/* Make the verbose messages from UBI stop printing */
+#define CONFIG_UBI_SILENCE_MSG
+#define CONFIG_UBIFS_SILENCE_MSG
+
+#define CONFIG_BOOTDELAY 1 /* negative for no autoboot */
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ "loadaddr=0x80F8\0" \
+ "dtbaddr=0x8020\0" \
+ "bootdir=/boot\0" \
+ "bootfile=zImage\0" \
+ "dtbfile=am335x-base0033.dtb\0" \
+ "console=ttyO0,115200n8\0" \
+ "mtdids=" MTDIDS_DEFAULT "\0" \
+ "mtdparts=" MTDPARTS_DEFAULT "\0" \
+ "mmcdev=0\0" \
+ "mmcroot=/dev/mmcblk0p2 rw\0" \
+ "ubiroot=ubi0:filesystem rw ubi.mtd=3,2048\0" \
+ "mmcrootfstype=ext4 rootwait\0" \
+ "ubirootfstype=ubifs rootwait\0" \
+ "mmcargs=setenv bootargs console=${console} " \
+
Re: [U-Boot] [PATCH 0/2] OMAP3: igep00x0: allow DeviceTree booting
On Wed, Aug 7, 2013 at 5:53 PM, Javier Martinez Canillas
wrote:
> Now that Device Tree support for IGEP boards has been included
> in the mainline Linux kernel, it's better if the default boot
> command has proper support for booting with DT.
>
> This patch-set his composed of the following patches:
>
> Enric Balletbo i Serra (1):
> ARM: igep00x0.h: Enable the use of CMD_EXT4, CMD_FS_GENERIC and zImage.
>
> Javier Martinez Canillas (1):
> OMAP3: igep00x0: allow booting with a FDT from MMC
>
> The first patch adds some improvements to igep00x0.h to support
> loading kernel images from ext{2,3,4} partitions besides FAT and
> using by default a zImage instead of a uImage now that multiplatform
> support has been added to OMAP.
>
> The second patch adds support to boot using a FDT if is present
> in the /boot dir of the rootfs partition and fallback to legacy
> boot if is not present so users that have not migrated to DT can
> still use the default boot command.
>
Hi Tom,
Any comments on this patch-set?
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] ARM: igep00x0.h: Enable raw initrd support
Now that IGEP base boards default environment use the bootz command to boot a zImage instead of a uImage, it makes sense to add support to supply a raw initrd image to the kernel if needed. Signed-off-by: Javier Martinez Canillas --- include/configs/igep00x0.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h index 13d58a4..ed8c927 100644 --- a/include/configs/igep00x0.h +++ b/include/configs/igep00x0.h @@ -44,6 +44,7 @@ #define CONFIG_OF_LIBFDT #define CONFIG_CMD_BOOTZ +#define CONFIG_SUPPORT_RAW_INITRD /* * NS16550 Configuration -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] ARM: IGEP0033: Remove duplicate / unused #defines.
Hi Enric, On Thu, Jul 25, 2013 at 9:27 AM, Enric Balletbo i Serra wrote: > From: Enric Balletbo i Serra > > As config was originally based on am335x_evm.h we have also some > duplicate / unnused #defines. > > Commit 15191c91 removed these #defines on various AM335x boards but not > for IGEP COM AQUILA. This patch simply removes them for this board. > Hi Enric, This is why I think we should rename igep0033.h => am335x_igep0033.h or something and do the same for igep00x0.h. Otherwise we miss fixes/cleanups when people search for a pattern (i.e: include/configs/omap3_*). This is totally unrelated to this patch though, I just wanted to point this out to take into account once we do the refactor to make both igep0033.h and igep00x0.h share common code. > Signed-off-by: Enric Balletbo i Serra > --- > include/configs/igep0033.h | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/include/configs/igep0033.h b/include/configs/igep0033.h > index 3d08cfa..de60f75 100644 > --- a/include/configs/igep0033.h > +++ b/include/configs/igep0033.h > @@ -136,7 +136,6 @@ > /* Boot Argument Buffer Size */ > #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE > #define CONFIG_SYS_LOAD_ADDR 0x8100 /* Default load address */ > -#define CONFIG_SYS_HZ 1000 /* 1ms clock */ > > /* Physical Memory Map */ > #define CONFIG_NR_DRAM_BANKS 1 /* 1 bank of DRAM */ > @@ -149,7 +148,7 @@ > /* Platform/Board specific defs */ > #define CONFIG_SYS_TIMERBASE 0x4804 /* Use Timer2 */ > #define CONFIG_SYS_PTV 2 /* Divisor: 2^(PTV+1) => 8 */ > -#define CONFIG_SYS_HZ 1000 > +#define CONFIG_SYS_HZ 1000/* 1ms clock */ > > /* NS16550 Configuration */ > #define CONFIG_SYS_NS16550 > @@ -158,7 +157,6 @@ > #define CONFIG_SYS_NS16550_CLK (4800) > #define CONFIG_SYS_NS16550_COM10x44e09000 /* UART0 */ > > -#define CONFIG_SERIAL_MULTI > #define CONFIG_CONS_INDEX 1 > #define CONFIG_BAUDRATE115200 > > @@ -272,10 +270,6 @@ > #define CONFIG_SYS_NAND_ECCSIZE512 > #define CONFIG_SYS_NAND_ECCBYTES 14 > > -#define CONFIG_SYS_NAND_ECCSTEPS 4 > -#defineCONFIG_SYS_NAND_ECCTOTAL(CONFIG_SYS_NAND_ECCBYTES * \ > - CONFIG_SYS_NAND_ECCSTEPS) > - > #define CONFIG_SYS_NAND_U_BOOT_STARTCONFIG_SYS_TEXT_BASE > > #define CONFIG_SYS_NAND_U_BOOT_OFFS0x8 > -- > 1.8.1.2 > Reviewed-by: Javier Martinez Canillas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] ARM: IGEP0033: Add support to boot from NAND.
On Thu, Jul 25, 2013 at 9:27 AM, Enric Balletbo i Serra
wrote:
> From: Enric Balletbo i Serra
>
> Add to the default environment the possibily to boot from NAND using
> a ubi rootfs. Also the partition scheme is set as follows:
>
> Start Size
> SPL : 0x 0x0008 (512KiB)
> U-Boot : 0x0008 0x0010 (1MiB)
> U-Boot Env : 0x0018 0x0002 (128KiB)
> File System : 0x001C -
>
> The ubiboot script gets the kernel and the dtb file from the boot directory
> of the File System.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> include/configs/igep0033.h | 32 +++-
> 1 file changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/include/configs/igep0033.h b/include/configs/igep0033.h
> index be210a5..3d08cfa 100644
> --- a/include/configs/igep0033.h
> +++ b/include/configs/igep0033.h
> @@ -62,6 +62,10 @@
> #define CONFIG_CMD_UBI
> #define CONFIG_CMD_UBIFS
>
> +/* Make the verbose messages from UBI stop printing */
> +#define CONFIG_UBI_SILENCE_MSG
> +#define CONFIG_UBIFS_SILENCE_MSG
> +
> #define CONFIG_BOOTDELAY 1 /* negative for no autoboot */
> #define CONFIG_ENV_VARS_UBOOT_CONFIG
> #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> @@ -72,21 +76,34 @@
> "bootfile=zImage\0" \
> "dtbfile=am335x-base0033.dtb\0" \
> "console=ttyO0,115200n8\0" \
> + "mtdids=" MTDIDS_DEFAULT "\0" \
> + "mtdparts=" MTDPARTS_DEFAULT "\0" \
> "mmcdev=0\0" \
> "mmcroot=/dev/mmcblk0p2 rw\0" \
> + "ubiroot=ubi0:filesystem rw ubi.mtd=3,2048\0" \
> "mmcrootfstype=ext4 rootwait\0" \
> + "ubirootfstype=ubifs rootwait\0" \
> "mmcargs=setenv bootargs console=${console} " \
> "root=${mmcroot} " \
> "rootfstype=${mmcrootfstype}\0" \
> + "ubiargs=setenv bootargs console=${console} " \
> + "root=${ubiroot} " \
> + "rootfstype=${ubirootfstype}\0" \
> "bootenv=uEnv.txt\0" \
> "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
> "importbootenv=echo Importing environment from mmc ...; " \
> "env import -t ${loadaddr} ${filesize}\0" \
> "mmcload=load mmc ${mmcdev}:2 ${loadaddr} ${bootdir}/${bootfile}; " \
> "load mmc ${mmcdev}:2 ${dtbaddr} ${bootdir}/${dtbfile}\0" \
> + "ubiload=ubi part filesystem 2048; ubifsmount ubi0; " \
> + "ubifsload ${loadaddr} ${bootdir}/${bootfile}; " \
> + "ubifsload ${dtbaddr} ${bootdir}/${dtbfile} \0" \
> "mmcboot=echo Booting from mmc ...; " \
> "run mmcargs; " \
> "bootz ${loadaddr} - ${dtbaddr}\0" \
> + "ubiboot=echo Booting from nand (ubifs) ...; " \
> + "run ubiargs; run ubiload; " \
> + "bootz ${loadaddr} - ${dtbaddr}\0" \
>
> #define CONFIG_BOOTCOMMAND \
> "mmc dev ${mmcdev}; if mmc rescan; then " \
> @@ -102,6 +119,8 @@
> "if run mmcload; then " \
> "run mmcboot;" \
> "fi;" \
> + "else " \
> + "run ubiboot;" \
> "fi;" \
>
> /* Max number of command args */
> @@ -181,18 +200,21 @@
> #define CONFIG_SYS_MAX_NAND_DEVICE 1
> #define CONFIG_SYS_NAND_ONFI_DETECTION 1
> #define CONFIG_SYS_ENV_SECT_SIZE (128 << 10) /* 128 KiB */
> +#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
> #define CONFIG_ENV_IS_IN_NAND
> -#define CONFIG_ENV_OFFSET 0x26 /* environment starts here */
> +#define CONFIG_ENV_OFFSET 0x18 /* environment starts here */
> +#define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_OFFSET +
> CONFIG_SYS_ENV_SECT_SIZE)
> +#define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SIZE)
>
> #define CONFIG_MTD_PARTITIONS
> #define CONFIG_MTD_DEVICE
> #define CONFIG_RBTREE
> #define CONFIG_LZO
>
> -#define MTDIDS_DEFAULT "nand0=nand"
> -#define MTDPARTS_DEFAULT "mtdparts=nand:512k(SPL),"\
> - "1m(U-Boot),128k(U-Boot Env),"\
> - "5m(Kernel),-(File System)"
> +#define MTDIDS_DEFAULT "nand0=omap2-nand.0"
> +#define MTDPARTS_DEFAULT "mtdparts=omap2-nand.0:512k(spl),"\
> + "1m(uboot),256k(environment),"\
> + "-(filesystem)"
>
> /* Unsupported features */
> #undef CONFIG_USE_IRQ
> --
> 1.8.1.2
>
Reviewed-by: Javier Martinez Canillas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] ARM: IGEP0033: Remove CYGNUS name from header.
On Thu, Jul 25, 2013 at 9:27 AM, Enric Balletbo i Serra wrote: > From: Enric Balletbo i Serra > > We will not use CYGNUS names for any IGEP COM based on AM335x processor, > so, to avoid confusion, remove from headers. > > Signed-off-by: Enric Balletbo i Serra > --- > board/isee/igep0033/board.c | 2 +- > board/isee/igep0033/board.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c > index ea3bea5..b3fcbb3 100644 > --- a/board/isee/igep0033/board.c > +++ b/board/isee/igep0033/board.c > @@ -1,5 +1,5 @@ > /* > - * Board functions for IGEP COM AQUILA/CYGNUS based boards > + * Board functions for IGEP COM AQUILA based boards > * > * Copyright (C) 2013, ISEE 2007 SL - http://www.isee.biz/ > * > diff --git a/board/isee/igep0033/board.h b/board/isee/igep0033/board.h > index 37988e0..4368ee6 100644 > --- a/board/isee/igep0033/board.h > +++ b/board/isee/igep0033/board.h > @@ -1,5 +1,5 @@ > /* > - * IGEP COM AQUILA/CYGNUS boards information header > + * IGEP COM AQUILA boards information header > * > * Copyright (C) 2013, ISEE 2007 SL - http://www.isee.biz/ > * > -- > 1.8.1.2 > Reviewed-by: Javier Martinez Canillas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] OMAP3: igep00x0: allow DeviceTree booting
Now that Device Tree support for IGEP boards has been included
in the mainline Linux kernel, it's better if the default boot
command has proper support for booting with DT.
This patch-set his composed of the following patches:
Enric Balletbo i Serra (1):
ARM: igep00x0.h: Enable the use of CMD_EXT4, CMD_FS_GENERIC and zImage.
Javier Martinez Canillas (1):
OMAP3: igep00x0: allow booting with a FDT from MMC
The first patch adds some improvements to igep00x0.h to support
loading kernel images from ext{2,3,4} partitions besides FAT and
using by default a zImage instead of a uImage now that multiplatform
support has been added to OMAP.
The second patch adds support to boot using a FDT if is present
in the /boot dir of the rootfs partition and fallback to legacy
boot if is not present so users that have not migrated to DT can
still use the default boot command.
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ARM: IGEP0033: Add support for Flattened Device Tree.
On Thu, Jul 25, 2013 at 9:27 AM, Enric Balletbo i Serra
wrote:
> Now, the default kernel to boot the IGEP COM AQUILA is device tree based. As
> old kernel is deprecated we should adapt the boot commands to use DTB files.
>
> Also, with v3.9 and later of the Linux Kernel, uImage isn't builtable anymore
> by default, so we should switch to use the bootz command.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> include/configs/igep0033.h | 33 +
> 1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/include/configs/igep0033.h b/include/configs/igep0033.h
> index 41c083e..be210a5 100644
> --- a/include/configs/igep0033.h
> +++ b/include/configs/igep0033.h
> @@ -41,6 +41,9 @@
> /* Display cpuinfo */
> #define CONFIG_DISPLAY_CPUINFO
>
> +/* Flattened Device Tree */
> +#define CONFIG_OF_LIBFDT
> +
> /* Commands to include */
> #include
>
> @@ -63,37 +66,27 @@
> #define CONFIG_ENV_VARS_UBOOT_CONFIG
> #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> #define CONFIG_EXTRA_ENV_SETTINGS \
> - "loadaddr=0x8020\0" \
> - "rdaddr=0x8100\0" \
> - "bootfile=/boot/uImage\0" \
> + "loadaddr=0x80F8\0" \
> + "dtbaddr=0x8020\0" \
> + "bootdir=/boot\0" \
> + "bootfile=zImage\0" \
> + "dtbfile=am335x-base0033.dtb\0" \
> "console=ttyO0,115200n8\0" \
> - "optargs=\0" \
> "mmcdev=0\0" \
> "mmcroot=/dev/mmcblk0p2 rw\0" \
> "mmcrootfstype=ext4 rootwait\0" \
> - "ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \
> - "ramrootfstype=ext2\0" \
> "mmcargs=setenv bootargs console=${console} " \
> - "${optargs} " \
> "root=${mmcroot} " \
> "rootfstype=${mmcrootfstype}\0" \
> "bootenv=uEnv.txt\0" \
> "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
> "importbootenv=echo Importing environment from mmc ...; " \
> - "env import -t $loadaddr $filesize\0" \
> - "ramargs=setenv bootargs console=${console} " \
> - "${optargs} " \
> - "root=${ramroot} " \
> - "rootfstype=${ramrootfstype}\0" \
> - "loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \
> - "loaduimagefat=load mmc ${mmcdev} ${loadaddr} ${bootfile}\0" \
> - "loaduimage=load mmc ${mmcdev}:2 ${loadaddr} ${bootfile}\0" \
> + "env import -t ${loadaddr} ${filesize}\0" \
> + "mmcload=load mmc ${mmcdev}:2 ${loadaddr} ${bootdir}/${bootfile}; " \
> + "load mmc ${mmcdev}:2 ${dtbaddr} ${bootdir}/${dtbfile}\0" \
> "mmcboot=echo Booting from mmc ...; " \
> "run mmcargs; " \
> - "bootm ${loadaddr}\0" \
> - "ramboot=echo Booting from ramdisk ...; " \
> - "run ramargs; " \
> - "bootm ${loadaddr}\0" \
> + "bootz ${loadaddr} - ${dtbaddr}\0" \
>
> #define CONFIG_BOOTCOMMAND \
> "mmc dev ${mmcdev}; if mmc rescan; then " \
> @@ -106,7 +99,7 @@
> "echo Running uenvcmd ...;" \
> "run uenvcmd;" \
> "fi;" \
> - "if run loaduimage; then " \
> + "if run mmcload; then " \
> "run mmcboot;" \
> "fi;" \
> "fi;" \
> --
> 1.8.1.2
>
Reviewed-by: Javier Martinez Canillas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] ARM: IGEP0033: Remove undef of CONFIG_CMD_MEMTEST
On Thu, Jul 25, 2013 at 9:27 AM, Enric Balletbo i Serra wrote: > From: Enric Balletbo i Serra > > After commit: > > 79cd2f814b1c75efd47161ac27f4cbebf768240f config_cmd_default.h: Remove > CONFIG_CMD_MEMTEST > > It's not necessary to undef the CONFIG_CMD_MEMTEST, so we can remove it from > configuration file. > > Signed-off-by: Enric Balletbo i Serra > --- > include/configs/igep0033.h | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/include/configs/igep0033.h b/include/configs/igep0033.h > index 12f28f8..41c083e 100644 > --- a/include/configs/igep0033.h > +++ b/include/configs/igep0033.h > @@ -59,13 +59,6 @@ > #define CONFIG_CMD_UBI > #define CONFIG_CMD_UBIFS > > -/* > - * Because the issues explained in doc/README.memory-test, the "mtest command > - * is considered deprecated. It should not be enabled in most normal ports of > - * U-Boot. > - */ > -#undef CONFIG_CMD_MEMTEST > - > #define CONFIG_BOOTDELAY 1 /* negative for no autoboot */ > #define CONFIG_ENV_VARS_UBOOT_CONFIG > #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG > -- > 1.8.1.2 > Reviewed-by: Javier Martinez Canillas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: igep00x0.h: Enable the use of CMD_EXT4, CMD_FS_GENERIC and zImage.
From: Enric Balletbo i Serra
Able to load the kernel from some form of ext[234] or FAT. Also, with v3.9 and
later of the Linux Kernel, uImage isn't builtable anymore by default, so we
should switch to use the bootz command.
Signed-off-by: Enric Balletbo i Serra
---
include/configs/igep00x0.h | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index c17267e..b3c57f4 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -97,8 +97,9 @@
#include
#define CONFIG_CMD_CACHE
-#define CONFIG_CMD_EXT2/* EXT2 Support */
+#define CONFIG_CMD_EXT4
#define CONFIG_CMD_FAT /* FAT support */
+#define CONFIG_CMD_FS_GENERIC
#define CONFIG_CMD_I2C /* I2C serial bus support */
#define CONFIG_CMD_MMC /* MMC support */
#ifdef CONFIG_BOOT_ONENAND
@@ -163,17 +164,17 @@
"omapdss.def_disp=${defaultdisplay} " \
"root=${nandroot} " \
"rootfstype=${nandrootfstype}\0" \
- "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+ "loadbootenv=load mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc ...; " \
"env import -t $loadaddr $filesize\0" \
- "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+ "loadzimage=load mmc ${mmcdev} ${loadaddr} zImage\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
- "bootm ${loadaddr}\0" \
+ "bootz ${loadaddr}\0" \
"nandboot=echo Booting from onenand ...; " \
"run nandargs; " \
"onenand read ${loadaddr} 28 40; " \
- "bootm ${loadaddr}\0" \
+ "bootz ${loadaddr}\0" \
#define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
@@ -185,7 +186,7 @@
"echo Running uenvcmd ...;" \
"run uenvcmd;" \
"fi;" \
- "if run loaduimage; then " \
+ "if run loadzimage; then " \
"run mmcboot;" \
"fi;" \
"fi;" \
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] OMAP3: igep00x0: allow booting with a FDT from MMC
IGEP boards now have Device Tree support in the mainline
kernel. To boot an IGEP board using a DT, a uEnv.txt plain
text file could be used to define a custom uenvcmd that will
be run by the default boot command.
It is more convenient to change the default boot command to
allow loading a FDT if it is stored in the boot dir of the
rootfs uSD/MMC partition.
If no FDT is found then the defaul command tries to boot a
zImage without a DT using legacy boot.
Signed-off-by: Javier Martinez Canillas
---
board/isee/igep00x0/igep00x0.c | 14 ++
include/configs/igep00x0.h | 13 -
2 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
index 77a9bc6..7a7500b 100644
--- a/board/isee/igep00x0/igep00x0.c
+++ b/board/isee/igep00x0/igep00x0.c
@@ -138,6 +138,18 @@ int board_mmc_init(bd_t *bis)
}
#endif
+void set_fdt(void)
+{
+ switch (gd->bd->bi_arch_number) {
+ case MACH_TYPE_IGEP0020:
+ setenv("dtbfile", "omap3-igep0020.dtb");
+ break;
+ case MACH_TYPE_IGEP0030:
+ setenv("dtbfile", "omap3-igep0030.dtb");
+ break;
+ }
+}
+
/*
* Routine: misc_init_r
* Description: Configure board specific parts
@@ -150,6 +162,8 @@ int misc_init_r(void)
dieid_num_r();
+ set_fdt();
+
return 0;
}
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index b3c57f4..13d58a4 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -137,6 +137,9 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"usbtty=cdc_acm\0" \
"loadaddr=0x8200\0" \
+ "dtbaddr=0x8160\0" \
+ "bootdir=/boot\0" \
+ "bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
"console=ttyO2,115200n8\0" \
"mpurate=auto\0" \
@@ -167,10 +170,13 @@
"loadbootenv=load mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc ...; " \
"env import -t $loadaddr $filesize\0" \
- "loadzimage=load mmc ${mmcdev} ${loadaddr} zImage\0" \
+ "loadzimage=load mmc ${mmcdev}:2 ${loadaddr} ${bootdir}/${bootfile}\0" \
+ "loadfdt=load mmc ${mmcdev}:2 ${dtbaddr} ${bootdir}/${dtbfile}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"bootz ${loadaddr}\0" \
+ "mmcbootfdt=echo Booting with DT from mmc ...; " \
+ "bootz ${loadaddr} - ${dtbaddr}\0" \
"nandboot=echo Booting from onenand ...; " \
"run nandargs; " \
"onenand read ${loadaddr} 28 40; " \
@@ -187,6 +193,11 @@
"run uenvcmd;" \
"fi;" \
"if run loadzimage; then " \
+ "if test -n $dtbfile; then " \
+ "if run loadfdt; then " \
+ "run mmcbootfdt;" \
+ "fi;" \
+ "fi;" \
"run mmcboot;" \
"fi;" \
"fi;" \
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] OMAP3: igep00x0: allow booting with a FDT from MMC
On Mon, Jul 15, 2013 at 9:43 AM, Enric Balletbo Serra
wrote:
> Hi Javier,
>
Hi Enric,
Thanks a lot for your feedback.
> 2013/7/14 Javier Martinez Canillas :
>> IGEP boards now have Device Tree support in the mainline
>> kernel. To boot an IGEP board using a DT, a uEnv.txt plain
>> text file could be used to define a custom uenvcmd that will
>> be run by the default boot command.
>>
>> It is more convenient to change the default boot command to
>> allow loading a FDT if it is stored in a uSD/MMC partition.
>> If no FDT is found then the command behaves just as it used
>> so this change won't break existing setup for current users.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>> board/isee/igep00x0/igep00x0.c | 14 ++
>> include/configs/igep00x0.h |9 +
>> 2 files changed, 23 insertions(+), 0 deletions(-)
>>
>> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
>> index 0d4679d..fdd2773 100644
>> --- a/board/isee/igep00x0/igep00x0.c
>> +++ b/board/isee/igep00x0/igep00x0.c
>> @@ -154,6 +154,18 @@ int board_mmc_init(bd_t *bis)
>> }
>> #endif
>>
>> +void set_fdt(void)
>> +{
>> + switch (gd->bd->bi_arch_number) {
>> + case MACH_TYPE_IGEP0020:
>> + setenv("fdtfile", "omap3-igep0020.dtb");
>> + break;
>> + case MACH_TYPE_IGEP0030:
>> + setenv("fdtfile", "omap3-igep0030.dtb");
>> + break;
>> + }
>> +}
>> +
>> /*
>> * Routine: misc_init_r
>> * Description: Configure board specific parts
>> @@ -166,6 +178,8 @@ int misc_init_r(void)
>>
>> dieid_num_r();
>>
>> + set_fdt();
>> +
>> return 0;
>> }
>>
>> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
>> index 1d8090b..72752af 100644
>> --- a/include/configs/igep00x0.h
>> +++ b/include/configs/igep00x0.h
>> @@ -149,6 +149,7 @@
>> #define CONFIG_EXTRA_ENV_SETTINGS \
>> "usbtty=cdc_acm\0" \
>> "loadaddr=0x8200\0" \
>> + "fdtaddr=0x8160\0" \
>> "usbtty=cdc_acm\0" \
>> "console=ttyO2,115200n8\0" \
>> "mpurate=auto\0" \
>> @@ -180,9 +181,12 @@
>> "importbootenv=echo Importing environment from mmc ...; " \
>> "env import -t $loadaddr $filesize\0" \
>> "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
>> + "loadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
>> "mmcboot=echo Booting from mmc ...; " \
>> "run mmcargs; " \
>> "bootm ${loadaddr}\0" \
>> + "mmcbootfdt=echo Booting with DT from mmc ...; " \
>> + "bootm ${loadaddr} - ${fdtaddr}\0" \
>> "nandboot=echo Booting from onenand ...; " \
>> "run nandargs; " \
>> "onenand read ${loadaddr} 28 40; " \
>> @@ -199,6 +203,11 @@
>> "run uenvcmd;" \
>> "fi;" \
>> "if run loaduimage; then " \
>> + "if test -n $fdtfile; then " \
>> + "if run loadfdt; then " \
>> + "run mmcbootfdt;" \
>> + "fi;" \
>> + "fi;" \
>> "run mmcboot;" \
>> "fi;" \
>> "fi;" \
>> --
>> 1.7.7.6
>>
>
> As merge window is closed, I think we have time to discuss a bit more
> this patch before sending for next merge window. I think it's time to
> redefine the default boot arguments for all IGEP boards and unify as
> possible the bootargs for IGEP0020, IGEP0030, IGEP0032 and IGEP0033.
>
Yes, I like the idea to redefine the default boot arguments. I just
have been doing minor changes in the past like using ttyO for console,
using EXT4 as mmcrootfstype, etc. But I agree that a major rethink
will be good to make it more usable.
> I made also some work in this line, but is not finished yet. We can
> send a the patch series for next merge window. These are the things
> that I think the patches should have.
>
>1. Enable
[U-Boot] [PATCH 1/1] OMAP3: igep00x0: allow booting with a FDT from MMC
IGEP boards now have Device Tree support in the mainline
kernel. To boot an IGEP board using a DT, a uEnv.txt plain
text file could be used to define a custom uenvcmd that will
be run by the default boot command.
It is more convenient to change the default boot command to
allow loading a FDT if it is stored in a uSD/MMC partition.
If no FDT is found then the command behaves just as it used
so this change won't break existing setup for current users.
Signed-off-by: Javier Martinez Canillas
---
board/isee/igep00x0/igep00x0.c | 14 ++
include/configs/igep00x0.h |9 +
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
index 0d4679d..fdd2773 100644
--- a/board/isee/igep00x0/igep00x0.c
+++ b/board/isee/igep00x0/igep00x0.c
@@ -154,6 +154,18 @@ int board_mmc_init(bd_t *bis)
}
#endif
+void set_fdt(void)
+{
+ switch (gd->bd->bi_arch_number) {
+ case MACH_TYPE_IGEP0020:
+ setenv("fdtfile", "omap3-igep0020.dtb");
+ break;
+ case MACH_TYPE_IGEP0030:
+ setenv("fdtfile", "omap3-igep0030.dtb");
+ break;
+ }
+}
+
/*
* Routine: misc_init_r
* Description: Configure board specific parts
@@ -166,6 +178,8 @@ int misc_init_r(void)
dieid_num_r();
+ set_fdt();
+
return 0;
}
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index 1d8090b..72752af 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -149,6 +149,7 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"usbtty=cdc_acm\0" \
"loadaddr=0x8200\0" \
+ "fdtaddr=0x8160\0" \
"usbtty=cdc_acm\0" \
"console=ttyO2,115200n8\0" \
"mpurate=auto\0" \
@@ -180,9 +181,12 @@
"importbootenv=echo Importing environment from mmc ...; " \
"env import -t $loadaddr $filesize\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+ "loadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"bootm ${loadaddr}\0" \
+ "mmcbootfdt=echo Booting with DT from mmc ...; " \
+ "bootm ${loadaddr} - ${fdtaddr}\0" \
"nandboot=echo Booting from onenand ...; " \
"run nandargs; " \
"onenand read ${loadaddr} 28 40; " \
@@ -199,6 +203,11 @@
"run uenvcmd;" \
"fi;" \
"if run loaduimage; then " \
+ "if test -n $fdtfile; then " \
+ "if run loadfdt; then " \
+ "run mmcbootfdt;" \
+ "fi;" \
+ "fi;" \
"run mmcboot;" \
"fi;" \
"fi;" \
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Require guidance
On Fri, Apr 5, 2013 at 8:57 AM, Rajdeep Vaghasia wrote: > hello, > > I have read about U - boot from Emebedded Linux Primer 2nd Edition. > > I want more in depth knowledge of U - boot. > > Can you please suggest me or give me the references through which I get > more in depth knowledge about U - boot? > > Regards > > Rajdeep Vaghasia > Hi Rajdeep, Since your question was rather generic, my answer will be general too. There are lots of valuable documentation inside the U-Boot code repository: $ git clone git://git.denx.de/u-boot.git $ find u-boot -name README You can also learn by studying the relevant part of the source code that may interest you. Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
board/freescale/mx6qsabrelite/README explain a procedure to
update the SPI-NOR on the SabreLite board without Freescale
manufacturing tool but following this procedure leads to both
"sf erase" and "sf write" failing on a mx6qsabrelite board:
MX6QSABRELITE U-Boot > sf probe 1
MX6QSABRELITE U-Boot > sf erase 0 0x4
SPI flash erase failed
MX6QSABRELITE U-Boot > sf write 0x1080 0 0x4
SPI flash write failed
This is because the chip-select 1 is wrong and the correct
value is 0x7300.
Since commit c1173bd0 ("sf command: allow default bus and chip selects")
the chip-select and bus arguments for the sf probe command are optional
so let's just remove it and use "sf probe" instead.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- Fix the description by explaining that the chip-select can be passed
but the value "1" is wrong and is not strictly required; suggested by
Stefano Babic.
board/freescale/mx6qsabrelite/README |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/README
b/board/freescale/mx6qsabrelite/README
index 6f2f534..324b116 100644
--- a/board/freescale/mx6qsabrelite/README
+++ b/board/freescale/mx6qsabrelite/README
@@ -40,7 +40,7 @@ enter the following commands:
MX6Q SABRELITE U-Boot > mmc dev 0
MX6Q SABRELITE U-Boot > mmc read 0x1080 0 200
- MX6Q SABRELITE U-Boot > sf probe 1
+ MX6Q SABRELITE U-Boot > sf probe
MX6Q SABRELITE U-Boot > sf erase 0 0x4
MX6Q SABRELITE U-Boot > sf write 0x1080 0 0x4
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
On Wed, Apr 3, 2013 at 11:25 AM, Stefano Babic wrote:
> On 25/03/2013 17:13, Javier Martinez Canillas wrote:
>> since commit "c1173bd0: sf command: allow default bus and chip selects"
>> the chip-select and bus arguments for the sf probe command are optional.
>>
>
> Hi Javier,
>
Hi Stefano, thanks a lot for your feedback.
>> Even when passing the chip-select to sf probe says to be optional, it
>> makes "sf erase" and "sf write" to fail on a mx6qsabrelite board. e.g:
>>
>> MX6QSABRELITE U-Boot > sf probe 1
>> MX6QSABRELITE U-Boot > sf erase 0 0x4
>> SPI flash erase failed
>> MX6QSABRELITE U-Boot > sf write 0x1080 0 0x4
>> SPI flash write failed
>
> Well, the real reason is that the passed chipselect is wrong. Checking
> in the configuration file, I see that the value to be passed should be
> 0x7300. I suppose (I am not testing) that "sf probe 0x7300" make sf
> erase and sw write working.
>
Just for curiosity, in which configuration file did you see that? When
I had the issue I looked at
include/configs/{mx6qsabrelite,mx6_common}.h and
board/freescale/mx6qsabrelite/mx6qsabrelite.c but I didn't find what
chip-select was supposed to be used.
>>
>> But just using "sf probe" works well. So, update the mx6qsabrelite
>> README so the commands will work on current U-Boot.
>
> I agree with the patch, but the description is wrong. Can you rewrite it
> simply stating that the chipselect "1" is wrong and that it is not
> strictly required (but again, is not forbidden) to pass it to sf probe ?
>
I'll send a v2 of the patch with this description:
i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
board/freescale/mx6qsabrelite/README explain a procedure to
update the SPI-NOR on the SabreLite board without Freescale
manufacturing tool but following this procedure leads to both
"sf erase" and "sf write" failing on a mx6qsabrelite board:
MX6QSABRELITE U-Boot > sf probe 1
MX6QSABRELITE U-Boot > sf erase 0 0x4
SPI flash erase failed
MX6QSABRELITE U-Boot > sf write 0x1080 0 0x4
SPI flash write failed
This is because the chip-select 1 is wrong and according the
correct value is 0x7300.
Since commit c1173bd0 ("sf command: allow default bus and chip selects"),
the chip-select and bus arguments for the sf probe command are optional
so let's just remove it and use "sf probe" instead.
> Best regards,
> Stefano Babic
>
> --
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v5] omap3_beagle: Flush UART3 xmit on enable if TEMT is broken
On Fri, Mar 29, 2013 at 1:52 PM, Manfred Huber wrote:
> From: Manfred Huber
>
> Flush UART3 xmit on enable if TEMT is broken
>
> On some OMAP3 devices when UART3 is configured for boot mode before SPL starts
> only THRE bit is set. We have to empty the transmitter before initialization
> starts. This patch avoids the use of CONFIG_SYS_NS16550_BROKEN_TEMT.
>
> Signed-off-by: Manfred Huber
> ---
> Changes since v4:
> - Changed multiline comment.
>
> Changes since v3:
> - Changed commit summary and added version history.
>
> Changes since v2:
> - Removing CONFIG_SYS_NS16550_BROKEN_TEMT in README and igep00x0.h.
>
> Changes since v1:
> - Replaced CONFIG_SYS_NS16550_BROKEN_TEMT with initial configuration
> of
> UART.
>
> README |8
> drivers/serial/ns16550.c | 18 --
> include/configs/igep00x0.h |3 ---
> 3 files changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/README b/README
> index a336476..e6b3a50 100644
> --- a/README
> +++ b/README
> @@ -616,14 +616,6 @@ The following options need to be configured:
> boot loader that has already initialized the UART. Define
> this
> variable to flush the UART at init time.
>
> - CONFIG_SYS_NS16550_BROKEN_TEMT
> -
> - 16550 UART set the Transmitter Empty (TEMT) Bit when all
> output
> - has finished and the transmitter is totally empty. U-Boot
> waits
> - for this bit to be set to initialize the serial console. On
> some
> - broken platforms this bit is not set in SPL making U-Boot to
> - hang while waiting for TEMT. Define this option to avoid it.
> -
>
> - Console Interface:
> Depending on board, define exactly one serial port
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 87a0917..a9352fb 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -36,10 +36,24 @@
>
> void NS16550_init(NS16550_t com_port, int baud_divisor)
> {
> -#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
> +#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_OMAP34XX))
> + /*
> +* On some OMAP3 devices when UART3 is configured for boot mode before
> +* SPL starts only THRE bit is set. We have to empty the transmitter
> +* before initialization starts.
> +*/
> + if ((serial_in(&com_port->lsr) & (UART_LSR_TEMT | UART_LSR_THRE))
> +== UART_LSR_THRE) {
> + serial_out(UART_LCR_DLAB, &com_port->lcr);
> + serial_out(baud_divisor & 0xff, &com_port->dll);
> + serial_out((baud_divisor >> 8) & 0xff, &com_port->dlm);
> + serial_out(UART_LCRVAL, &com_port->lcr);
> + serial_out(0, &com_port->mdr1);
> + }
> +#endif
> +
> while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
> ;
> -#endif
>
> serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
> #if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \
> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
> index f8131b1..0617a58 100644
> --- a/include/configs/igep00x0.h
> +++ b/include/configs/igep00x0.h
> @@ -67,9 +67,6 @@
> #define CONFIG_SYS_NS16550_REG_SIZE(-4)
> #define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
>
> -/* define to avoid U-Boot to hang while waiting for TEMT */
> -#define CONFIG_SYS_NS16550_BROKEN_TEMT
> -
> /* select serial console configuration */
> #define CONFIG_CONS_INDEX 3
> #define CONFIG_SYS_NS16550_COM3OMAP34XX_UART3
Hi Manfred,
I tested your patch on my IGEPv2 and is booting correctly, so:
Tested-by: Javier Martinez Canillas
Thanks a lot for working on this!
Best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support of Beagleboard-xm
On Thu, Mar 28, 2013 at 9:04 PM, Tom Rini wrote: > > On Thu, Mar 28, 2013 at 12:52:04PM +0800, Dashi Cao wrote: > > > Hi all, > > I have got a Beagleboard-xm, and I'm feeling that saving environment > > variable is an issue because this board has no NAND. > > > > U-Boot supports environment variable file located in a FAT file system. > > So I set out and made a new board omap3_beagle-xm, copied from > > omap3_beagle, but with environment file on the FAT of the microSD. > > > > I'm not sure if I'm just reinventing the wheel! > > An interesting concept and one I've thought about doing myself at some > point, so thanks! There's a better way to do this however. You can > have boards.cfg take a base config file (say omap3_beagle) and add > additional defines (say CONFIG_ENV_IS_IN_FAT) for a specific build > target (omap3_beagle_env_fat) and not have to copy all of the other > files. Then just modify omap3_beagle.h with: > #ifdef CONFIG_ENV_IS_IN_FAT > #undef CONFIG_ENV_IS_IN_NAND > #define FAT_FILE ... > ... > #endif > Hi Dashi, If you want an example on how to do this, something similar is made for IGEP boards. There are two IGEP board types: IGEP COM Module and IGEPv2. These two boards are very similar and each one can have one of two flash memory types: NAND or OneNAND. The same board file (board/isee/igep00x0/igep00x0.c) is used for every combination and you can choose between 4 base configs defined in boards.cfg: igep0020 => igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND igep0020_nand => igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND igep0030 => igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND igep0030_nand => igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND Hope it helps. > And be set, more or less. And don't re-use the name uEnv.txt please. > How about u-boot-env.txt ? And we shouldn't need to populate to start > with, I hope at least, it should just be OK until the first saveenv > happens. > > -- > Tom > Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v2] omap3_beagle: Enabling UART3 first allows the Transmitter to be empty
On Thu, Mar 28, 2013 at 9:45 AM, Andreas Bießmann wrote: > Dear Manfred Huber, > > On 03/28/2013 07:06 AM, Manfred Huber wrote: >> On 2013-03-27 14:37, Andreas Bießmann wrote: > > > >>> On 03/25/2013 11:02 PM, Manfred Huber wrote: > > > +serial_out(UART_LCR_DLAB, &com_port->lcr); +serial_out(baud_divisor & 0xff, &com_port->dll); +serial_out((baud_divisor >> 8) & 0xff, &com_port->dlm); +serial_out(UART_LCRVAL, &com_port->lcr); +serial_out(0, &com_port->mdr1); >>> >>> Do we need to setup baud a.s.o. here? Isn't it enough to issue an soft >>> reset of the UART? I'm not in this material, I just wonder if we can >>> omit some of the lines here cause we set e.g. the BAUD later on. >>> >> >> The reason to setup the baud is for the shift register. It only works >> with programmed baud registers. A soft reset would also work, but as >> Scott Wood said it would corrupt the last character. On the other hand >> the character should be corrupted by disabling the UART. I have no >> preferred solution: programming the UART or a soft reset. Maybe someone >> wants to decide. > > Well, I think also that re-programming the UART will destroy the last > character in shift register anyway. > I wonder which use-case requires UART flushing in u-boot context before > initializing the UART for u-boot correctly. Can someone explain this to > me? Shouldn't we always start here from the very beginning and setup > UART as configured? > >> +} +#endif + while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT)) ; -#endif serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier); #if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \ >>> >>> I managed to apply your patch anyhow. A short test on a tricorder board >>> showed no harm to the boot process. So please get your patch clean and >>> resend, then I will add my tested-by. >>> >>> As Javier pointed out please think about using the >>> CONFIG_SYS_NS16550_BROKEN_TEMT instead of SPL && OMAP34XX. >>> Another solution could be to have this TEMT | THRE check in >>> unconditionally, this however would require a lot more testing. >>> Especially with the release date in mind. >> >> It's not critical. So I guess it's not needed for this release. > > Well, if there are boards in the field that will not boot with the next > release I think it is critical. > We do have some omap3 (omap35xx and am37xx) based boards here. I can > recall a situation where some few boards did not boot from sd-card while > serial debug cable was attached (AFAIR this was not the case when > booting from NAND). The root cause was never investigated, so maybe we > suffered exactly this bug. > > Best regards > > Andreas Bießmann Hi Andreas, When I first hit this bug I tried removing the serial debug cable and this made my IGEPv2 to boot correctly. Then I looked at the latest changes to the serial ns16550 driver and found that cb55b332 "serial/ns16550: wait for TEMT before initializing" was the culprit commit that made my board to not boot. So, if I remember correctly, it seems as you hit the exact same bug (I didn't try to boot from NAND back then though) Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v2] omap3_beagle: Enabling UART3 first allows the Transmitter to be empty
On Wed, Mar 27, 2013 at 2:37 PM, Andreas Bießmann
wrote:
> Dear Manfred Huber,
>
> ---8<---
> abiessmann@punisher % pwclient get 230994
> Saved patch to
> U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
> abiessmann@punisher % git am
> U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
> Patch does not have a valid e-mail address.
> abiessmann@punisher % ./tools/checkpatch.pl
> U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
> ERROR: trailing whitespace
> #39: FILE: drivers/serial/ns16550.c:40:
> +^Iif ((serial_in(&com_port->lsr) & (UART_LSR_TEMT | UART_LSR_THRE)) == $
>
> ERROR: patch seems to be corrupt (line wrapped?)
> #40: FILE: drivers/serial/ns16550.c:40:
> UART_LSR_THRE) {
>
> total: 2 errors, 0 warnings, 20 lines checked
>
> NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
> scripts/cleanfile
>
> NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
> MULTISTATEMENT_MACRO_USE_DO_WHILE
>
> U-Boot-1-1-v2-omap3_beagle-Enabling-UART3-first-allows-the-Transmitter-to-be-empty.patch
> has style problems, please review.
>
> If any of these errors are false positives, please report
> them to the maintainer, see CHECKPATCH in MAINTAINERS.
> --->8---
>
> Can you please fix these errors?
>
> On 03/25/2013 11:02 PM, Manfred Huber wrote:
>> From: Manfred Huber
>>
>> Due to a Bug in the ROM code of some OMAP3 devices, the TEMT bit is not
>> set if UART3 is configured before (only THRE is set). Reason is the
>> disabling of UART3 even though the Transmitter is not empty. Enabling
>> UART3 allows the Transmitter to be empty.
>>
>> Signed-off-by: Manfred Huber
>> ---
>> drivers/serial/ns16550.c | 12 ++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>> index b2da8b3..24ff84f 100644
>> --- a/drivers/serial/ns16550.c
>> +++ b/drivers/serial/ns16550.c
>> @@ -36,10 +36,18 @@
>>
>> void NS16550_init(NS16550_t com_port, int baud_divisor)
>> {
>> -#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
>> +#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_OMAP34XX))
>
> I think a comment here would be good.
>
>> +if ((serial_in(&com_port->lsr) & (UART_LSR_TEMT | UART_LSR_THRE))
>> == UART_LSR_THRE) {
>
> The patch is broken here, even if you fix the wrapping you will get an
> 'over 80 char' error here.
>
>> +serial_out(UART_LCR_DLAB, &com_port->lcr);
>> +serial_out(baud_divisor & 0xff, &com_port->dll);
>> +serial_out((baud_divisor >> 8) & 0xff, &com_port->dlm);
>> +serial_out(UART_LCRVAL, &com_port->lcr);
>> +serial_out(0, &com_port->mdr1);
>
> Do we need to setup baud a.s.o. here? Isn't it enough to issue an soft
> reset of the UART? I'm not in this material, I just wonder if we can
> omit some of the lines here cause we set e.g. the BAUD later on.
>
>> +}
>> +#endif
>> +
>> while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
>> ;
>> -#endif
>>
>> serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
>> #if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \
>
> I managed to apply your patch anyhow. A short test on a tricorder board
> showed no harm to the boot process. So please get your patch clean and
> resend, then I will add my tested-by.
>
> As Javier pointed out please think about using the
> CONFIG_SYS_NS16550_BROKEN_TEMT instead of SPL && OMAP34XX.
> Another solution could be to have this TEMT | THRE check in
> unconditionally, this however would require a lot more testing.
> Especially with the release date in mind.
>
> Best regards
>
> Andreas Bießmann
Hi Manfred,
I just tested your patch and my IGEPv2 boots correctly.
So, after addressing the issues pointed out by Andreas feel free to
add my Tested-by too.
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v2] omap3_beagle: Enabling UART3 first allows the Transmitter to be empty
On Wed, Mar 27, 2013 at 5:50 AM, Manfred Huber wrote:
> Please test the Patch. It is very simple on a Beagleboard. I guess you
> have flashed the actual SPL and u-boot and Beagleboard boots correctly.
> Now press and hold 'User' button and connect power. SPL should hang.
> You can see some symbols on the console from the ROM code.
>
Hi Manfred,
I don't have access to my IGEP board right now but I'll test your
patch as soon as posible.
> Install the Patch, compile it and flash the NAND. Beagleboard still
> boots correctly. Now press and hold 'User' button again and Beagleboard
> should also boot correctly. The Patch works.
>
> I suspect the IGEP board has the same bug. If so, the Patch should work
> on this board too and we don't need CONFIG_SYS_NS16550_BROKEN_TEMT
> anymore.
>
I still think that we should keep CONFIG_SYS_NS16550_BROKEN_TEMT or
something similar instead of just checking for CONFIG_OMAP34XX. Since
we don't know if this problem is also present on other TI OMAP
platforms (or any other platform). I would just change
CONFIG_SYS_NS16550_BROKEN_TEMT semantics once is confirmed that this
also fixes the issue on IGEP boards.
Also, if you are removing CONFIG_SYS_NS16550_BROKEN_TEMT then you have
to update the README too since it is explained there what this config
option does.
> If you don't want a patch for this bug please let me know. I will not
> bother you again.
>
Thanks a lot for working on this. Some people work on mainline U-Boot
on their free time (like myself) so it can take a few days until you
get a response about a patch. Please be patient :-)
> Best regards,
> Manfred
>
>
Thank a lot and best regards,
Javier
>
> On 2013-03-25 23:02, Manfred Huber wrote:
>>
>> From: Manfred Huber
>>
>> Due to a Bug in the ROM code of some OMAP3 devices, the TEMT bit is not
>> set if UART3 is configured before (only THRE is set). Reason is the
>> disabling of UART3 even though the Transmitter is not empty. Enabling
>> UART3 allows the Transmitter to be empty.
>>
>> Signed-off-by: Manfred Huber
>> ---
>> drivers/serial/ns16550.c | 12 ++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>> index b2da8b3..24ff84f 100644
>> --- a/drivers/serial/ns16550.c
>> +++ b/drivers/serial/ns16550.c
>> @@ -36,10 +36,18 @@
>>
>> void NS16550_init(NS16550_t com_port, int baud_divisor)
>> {
>> -#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
>> +#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_OMAP34XX))
>> +if ((serial_in(&com_port->lsr) & (UART_LSR_TEMT | UART_LSR_THRE))
>> == UART_LSR_THRE) {
>> +serial_out(UART_LCR_DLAB, &com_port->lcr);
>> +serial_out(baud_divisor & 0xff, &com_port->dll);
>> +serial_out((baud_divisor >> 8) & 0xff, &com_port->dlm);
>> +serial_out(UART_LCRVAL, &com_port->lcr);
>> +serial_out(0, &com_port->mdr1);
>> +}
>> +#endif
>> +
>> while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
>> ;
>> -#endif
>>
>> serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
>> #if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
since commit "c1173bd0: sf command: allow default bus and chip selects" the chip-select and bus arguments for the sf probe command are optional. Even when passing the chip-select to sf probe says to be optional, it makes "sf erase" and "sf write" to fail on a mx6qsabrelite board. e.g: MX6QSABRELITE U-Boot > sf probe 1 MX6QSABRELITE U-Boot > sf erase 0 0x4 SPI flash erase failed MX6QSABRELITE U-Boot > sf write 0x1080 0 0x4 SPI flash write failed But just using "sf probe" works well. So, update the mx6qsabrelite README so the commands will work on current U-Boot. Signed-off-by: Javier Martinez Canillas --- board/freescale/mx6qsabrelite/README |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/freescale/mx6qsabrelite/README b/board/freescale/mx6qsabrelite/README index 6f2f534..324b116 100644 --- a/board/freescale/mx6qsabrelite/README +++ b/board/freescale/mx6qsabrelite/README @@ -40,7 +40,7 @@ enter the following commands: MX6Q SABRELITE U-Boot > mmc dev 0 MX6Q SABRELITE U-Boot > mmc read 0x1080 0 200 - MX6Q SABRELITE U-Boot > sf probe 1 + MX6Q SABRELITE U-Boot > sf probe MX6Q SABRELITE U-Boot > sf erase 0 0x4 MX6Q SABRELITE U-Boot > sf write 0x1080 0 0x4 -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3_beagle: Enable CONFIG_SYS_NS16550_BROKEN_TEMT
Hi Manfred,
On Thu, Mar 21, 2013 at 8:03 PM, Manfred Huber wrote:
> From: Manfred Huber
>
> Beagleboard UART (ns16550) doesn't set the Transmitter Empty (TEMT) Bit in
> SPL. Only Transmitter Hold Register Empty (THRE) Bit is set. This makes SPL
> to hang while waiting for TEMT. Adding the CONFIG_SYS_NS16550_BROKEN_TEMT
> config option and waiting for THRE avoid this issue.
>
> Signed-off-by: Manfred Huber
> ---
> drivers/serial/ns16550.c |5 -
> include/configs/omap3_beagle.h |3 +++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index b2da8b3..6379bcc 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -36,7 +36,10 @@
>
> void NS16550_init(NS16550_t com_port, int baud_divisor)
> {
> -#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
> +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SYS_NS16550_BROKEN_TEMT)
> + while (!(serial_in(&com_port->lsr) & UART_LSR_THRE))
> + ;
> +#else
I'm not sure to add this behavior under CONFIG_SYS_NS16550_BROKEN_TEMT
since this option just means:
"On some broken platforms the Transmitter Empty (TEMT) bit is not set
in SPL making U-Boot to hang while waiting for it"
According to your findings it seems that some OMAP3 platforms (at
least DM3730 and 3530) set THRE but I wonder if other broken platforms
will behave the same.
The current CONFIG_SYS_NS16550_BROKEN_TEMT just skips this test so it
can be reused by other platforms, but now your change makes it less
generic since it will only work on platforms that set THRE.
So I would just leave CONFIG_SYS_NS16550_BROKEN_TEMT as is now and be
able to reuse it on other platforms or add a new config option
CONFIG_SYS_NS16550_WAIT_THRE or something that would test for THRE
instead of TEMT and use that for OMAP3 based boards.
I do like your change that adds a test for CONFIG_SPL_BUILD since even
in the README it says that the issue is only present in SPL. So I just
forgot to add this when added the config option.
> while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
> ;
> #endif
> diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
> index 48ce4c0..6ab46d5 100644
> --- a/include/configs/omap3_beagle.h
> +++ b/include/configs/omap3_beagle.h
> @@ -82,6 +82,9 @@
> #define CONFIG_SYS_NS16550_REG_SIZE(-4)
> #define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
>
> +/* define to avoid U-Boot to hang while waiting for TEMT */
> +#define CONFIG_SYS_NS16550_BROKEN_TEMT
> +
> /*
> * select serial console configuration
> */
>
This part of your patch looks good to me but you should split your
changes in two patches. One to change the ns16550 drvier and another
one to add this config option for the Beagleboard.
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Beagleboard: SPL hangs on serial init
On Thu, Mar 21, 2013 at 12:09 AM, Manfred Huber wrote: > Am 20.03.2013 02:27, schrieb Tom Rini: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 03/19/2013 08:05 PM, Javier Martinez Canillas wrote: >>> >>> On Tue, Mar 19, 2013 at 3:49 PM, Tom Rini wrote: >>>> >>>> On Sat, Mar 16, 2013 at 02:13:54PM +0100, Manfred Huber wrote: >>>> >>>>> I'm surprised that no one is interested in a functioning >>>>> Beagleboard. Has no one tested the Beagleboard since >>>>> 2012-09-19? >>>> >>>> >>>> I don't see this problem on mine (classic and xM), which is >>>> probably part of the why. I'm inclined to accept the patch, but >>>> can you try two things please: - How reproducible is this >>>> problem, with the host and beagleboard combination you have? >>>> 100%? - Do you have another beagleboard or another host PC (or >>>> USB-Serial dongle) you can try? >>>> >>>> Thanks! >>>> >>>> -- Tom >>> >>> >>> Hi, >>> >>> I had this issue on another TI OMAP3 based board (IGEPv2) which >>> use an DM3730 processor. Other IGEP board users reported that >>> U-Boot hung on their boards and that a patch to not wait for the >>> Transmitter Empty (TEMT) to initialize the serial console fixed >>> the issue. So I added the CONFIG_SYS_NS16550_BROKEN_TEMT config >>> option and used it for IGEP boards (igep00x0) to make them boot >>> again. >>> >>> Back then I also tested on a Beagleboard Rev. C4 since it has the >>> same ns16550 UART controller than the IGEPv2 as far as I >>> understood. I used the exact U-Boot version, USB-Serial cable, >>> host PC and terminal emulation program that I used for the IGEPv2 >>> and the Beagleboard booted correctly. This is the same behavior >>> that Tom had on his Beagleboard. >>> >>> Since it worked on the Beagle I thought the issue was only present >>> on IGEP boards but now Manfred says that he has the same issue on >>> his Beagleboard. I now wonder if all IGEPv2 are broken or only my >>> board and the ones of the users that cared to report this and >>> other IGEPv2 can boot without CONFIG_SYS_NS16550_BROKEN_TEMT. >> >> >> Yeah, this is very perplexing. I'm thinking we need to enable this >> "quirk" for all of the "omap" platforms except for OMAP3_ZOOM (which >> iirc has a different uart chip wired up rather than the SoC uart). >> >> - -- >> Tom > > > As I described in my first mail the reason is the missing UART_LSR_TEMT bit > in the line status register. Comparing the UART_LSR_THRE bit instead works > in my case. > > Maybe Javier can test on his IGEP board if it works for him to compare the > UART_LSR_THRE bit instead of the UART_LSR_TEMT bit. > I see the same behavior in the IGEPv2. I tested mainline U-boot + your "[PATCH] omap3_beagle: Enable CONFIG_SYS_NS16550_BROKEN_TEMT" patch and SPL boots OK on my board. > Another solution would be to make a soft reset of the UART as first command > in the init function. This works also in my case. > I prefer this approach if it doesn't affect other boards. > On the other hand we can try to identify which OMAP3 has this behavior. The > module version register of the UART returns version 4.6. > > Best regards, > Manfred > > Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Beagleboard: SPL hangs on serial init
On Tue, Mar 19, 2013 at 3:49 PM, Tom Rini wrote: > On Sat, Mar 16, 2013 at 02:13:54PM +0100, Manfred Huber wrote: > >> I'm surprised that no one is interested in a functioning >> Beagleboard. Has no one tested the Beagleboard since 2012-09-19? > > I don't see this problem on mine (classic and xM), which is probably > part of the why. I'm inclined to accept the patch, but can you try two > things please: > - How reproducible is this problem, with the host and beagleboard > combination you have? 100%? > - Do you have another beagleboard or another host PC (or USB-Serial > dongle) you can try? > > Thanks! > > -- > Tom Hi, I had this issue on another TI OMAP3 based board (IGEPv2) which use an DM3730 processor. Other IGEP board users reported that U-Boot hung on their boards and that a patch to not wait for the Transmitter Empty (TEMT) to initialize the serial console fixed the issue. So I added the CONFIG_SYS_NS16550_BROKEN_TEMT config option and used it for IGEP boards (igep00x0) to make them boot again. Back then I also tested on a Beagleboard Rev. C4 since it has the same ns16550 UART controller than the IGEPv2 as far as I understood. I used the exact U-Boot version, USB-Serial cable, host PC and terminal emulation program that I used for the IGEPv2 and the Beagleboard booted correctly. This is the same behavior that Tom had on his Beagleboard. Since it worked on the Beagle I thought the issue was only present on IGEP boards but now Manfred says that he has the same issue on his Beagleboard. I now wonder if all IGEPv2 are broken or only my board and the ones of the users that cared to report this and other IGEPv2 can boot without CONFIG_SYS_NS16550_BROKEN_TEMT. Thanks a lot and best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] igep00x0: Enable CONFIG_CMD_BOOTZ
On Fri, Mar 15, 2013 at 1:32 PM, Enric Balletbo i Serra wrote: > From: Enric Balletbo i Serra > > With v3.9 and later of the Linux Kernel defaulting to multi-platform > images with omap2plus_defconfig, uImage isn't builtable anymore by > default. Add CONFIG_CMD_BOOTZ so that we can still boot something the > kernel spits out. > > Signed-off-by: Enric Balletbo i Serra > --- > include/configs/igep00x0.h |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h > index 0e7f924..670b665 100644 > --- a/include/configs/igep00x0.h > +++ b/include/configs/igep00x0.h > @@ -54,7 +54,8 @@ > #define CONFIG_INITRD_TAG 1 > #define CONFIG_REVISION_TAG1 > > -#define CONFIG_OF_LIBFDT 1 > +#define CONFIG_OF_LIBFDT > +#define CONFIG_CMD_BOOTZ > > /* > * NS16550 Configuration > -- > 1.7.10.4 > Hi Enric, Nice improvement, thanks! Reviewed-by: Javier Martinez Canillas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: AM33XX: Fix typo that causes an AM duplication in CPU name.
On Fri, Mar 15, 2013 at 12:35 PM, Enric Balletbo i Serra
wrote:
> From: Enric Balletbo i Serra
>
> Just fix a typo displaying the CPU info. With CONFIG_DISPLAY_INFO we see
> something like AMAM335X-GP rev 0 instead of AM335X-GP rev 0.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> arch/arm/cpu/armv7/am33xx/sys_info.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv7/am33xx/sys_info.c
> b/arch/arm/cpu/armv7/am33xx/sys_info.c
> index 507b618..db99e95 100644
> --- a/arch/arm/cpu/armv7/am33xx/sys_info.c
> +++ b/arch/arm/cpu/armv7/am33xx/sys_info.c
> @@ -120,7 +120,7 @@ int print_cpuinfo(void)
> sec_s = "?";
> }
>
> - printf("AM%s-%s rev %d\n",
> + printf("%s-%s rev %d\n",
> cpu_s, sec_s, get_cpu_rev());
>
> /* TODO: Print ARM and DDR frequencies */
> --
Hi Enric,
Looks good to me
Reviewed-by: Javier Martinez Canillas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 0/3] new IGEP board support
On Thu, Feb 7, 2013 at 11:40 AM, [Enric Balletbo i Serra wrote: > From: Enric Balletbo i Serra > > Hi all, > > This is the second version to add support to the IGEP COM PROTON board in > current mainline. > > These patches applies on top of u-boot-ti repository as the following patch is > required. > > OMAP3: use a single board file for IGEP devices > commit 076be4528851126b56f2c1b84d07834297797f6c > From Javier Martinez Canillas > > Changes since v1: > * Only define CONFIG_SHOW_BOOT_PROGRESS for the machines that have a boot > progress (thanks to Javier) > * Also define CONFIG_CMD_NET on IGEP0032 machine (thanks to Javier) > * Add new patch in the serie to fix a missing include. > > Thanks a lot for your comments, > > Enric Balletbo i Serra (3): > OMAP3: igep00x0: use official board names. > OMAP3: igep00x0: add missing include mach-types.h in config. > OMAP3: igep00x0: Add new IGEP COM PROTON. > For all the patches: Reviewed-by: Javier Martinez Canillas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] OMAP3: igep00x0: Add new IGEP COM PROTON.
On Wed, Feb 6, 2013 at 3:42 PM, Enric Balletbo Serra
wrote:
> Hi Javier,
>
Hi Enric,
> Thanks for your comments.
>
> 2013/2/6 Javier Martinez Canillas :
>> Hi Enric,
>>
>> On Wed, Feb 6, 2013 at 9:29 AM, Enric Balletbo i Serra
>> wrote:
>>> From: Enric Balletbo i Serra
>>>
>>> The IGEP COM PROTON is a new ultra compact module design with an
>>> on-board ethernet controller.
>>>
>>> Signed-off-by: Enric Balletbo i Serra
>>> ---
>>> MAINTAINERS|1 +
>>> board/isee/igep00x0/igep00x0.c |3 +++
>>> board/isee/igep00x0/igep00x0.h |3 +++
>>> boards.cfg |1 +
>>> 4 files changed, 8 insertions(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index d3ed390..1aed6d9 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -607,6 +607,7 @@ Enric Balletbo i Serra
>>>
>>> igep0020ARM ARMV7 (OMAP3xx SoC)
>>> igep0030ARM ARMV7 (OMAP3xx SoC)
>>> + igep0032ARM ARMV7 (OMAP3xx SoC)
>>>
>>> Eric Benard
>>>
>>> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
>>> index 49fcf34..93aea8b 100644
>>> --- a/board/isee/igep00x0/igep00x0.c
>>> +++ b/board/isee/igep00x0/igep00x0.c
>>> @@ -68,8 +68,11 @@ void show_boot_progress(int val)
>>> return;
>>> }
>>>
>>> +/* Skip in the case of IGEP0032 machine */
>>> +#if !(CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
>>> if (!gpio_request(IGEP00X0_GPIO_LED, ""))
>>> gpio_direction_output(IGEP00X0_GPIO_LED, 1);
>>> +#endif
>>> }
>>> #endif
>>>
>>
>> So, this board doesn't have a GPIO LED to show it boot status?
>>
>
> Yes, it has but not connected to one OMAP GPIO. There is a led to
> indicate power and two leds connected to TWL. Maybe I could use one of
> them but meanwhile I decided don't use these leds.
>
Agree
>> If that's the case I think there is no point to call show_boot_progress().
>> Since this function is only compiled when CONFIG_SHOW_BOOT_PROGRESS
>> is defined. I think that a better approach is to just define it for the
>> machines that have a boot progress GPIO LED. e.g:
>>
>> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
>> index 88eadb4..98eed0f 100644
>> --- a/include/configs/igep00x0.h
>> +++ b/include/configs/igep00x0.h
>> @@ -85,8 +85,11 @@
>> #define CONFIG_OMAP_HSMMC 1
>> #define CONFIG_DOS_PARTITION 1
>>
>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) || \
>> +(CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
>> /* define to enable boot progress via leds */
>> #define CONFIG_SHOW_BOOT_PROGRESS
>> +#endif
>>
>
> The problem is: if I disable the call to show_boot_progress in
> igep00x0.h I'll get a compilation error in this function because
> IGEP00X0_GPIO_LED is undeclared, so necessarily I need to protect the
> call in igep00x0.c against this undefined reference. For that reason I
> used the ifdef inside the show_boot_progress implementation.
>
I'm confused now, why would that happen?
IGEP00X0_GPIO_LED is only used in show_boot_progress and this function
his shielded by:
#if defined(CONFIG_SHOW_BOOT_PROGRESS) && !defined(CONFIG_SPL_BUILD)
void show_boot_progress(int val)
{
if (val < 0) {
/* something went wrong */
return;
}
if (!gpio_request(IGEP00X0_GPIO_LED, ""))
gpio_direction_output(IGEP00X0_GPIO_LED, 1);
}
#endif
Which means that this function is only build when
CONFIG_SHOW_BOOT_PROGRESS is defined.
So, I don't see why not defining CONFIG_SHOW_BOOT_PROGRESS for
MACH_TYPE_IGEP0032
could lead to that build error (after all IGEP00X0_GPIO_LED is not
been used in any other place)
>> /* USB */
>> #define CONFIG_MUSB_UDC1
>>
>>> diff --git a/board/isee/igep00x0/igep00x0.h b/board/isee/igep00x0/igep00x0.h
>>> index dbc7cf6..f5fce9c 100644
>>> --- a/board/isee/igep00x0/igep00x0.h
>>> +++ b/board/isee/igep00x0/igep00x0.h
>>> @@ -39,6 +39,9 @@ const omap3_sysinfo sysinfo = {
>>> #if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
>>> "IGEP COM MODULE/ELECTRON",
>>> #endif
>>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
>>> + "IGEP COM PROTON",
>>> +#endif
>>> #if
Re: [U-Boot] [PATCH 2/2] OMAP3: igep00x0: Add new IGEP COM PROTON.
Hi Enric,
On Wed, Feb 6, 2013 at 9:29 AM, Enric Balletbo i Serra
wrote:
> From: Enric Balletbo i Serra
>
> The IGEP COM PROTON is a new ultra compact module design with an
> on-board ethernet controller.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> MAINTAINERS|1 +
> board/isee/igep00x0/igep00x0.c |3 +++
> board/isee/igep00x0/igep00x0.h |3 +++
> boards.cfg |1 +
> 4 files changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d3ed390..1aed6d9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -607,6 +607,7 @@ Enric Balletbo i Serra
>
> igep0020ARM ARMV7 (OMAP3xx SoC)
> igep0030ARM ARMV7 (OMAP3xx SoC)
> + igep0032ARM ARMV7 (OMAP3xx SoC)
>
> Eric Benard
>
> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
> index 49fcf34..93aea8b 100644
> --- a/board/isee/igep00x0/igep00x0.c
> +++ b/board/isee/igep00x0/igep00x0.c
> @@ -68,8 +68,11 @@ void show_boot_progress(int val)
> return;
> }
>
> +/* Skip in the case of IGEP0032 machine */
> +#if !(CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
> if (!gpio_request(IGEP00X0_GPIO_LED, ""))
> gpio_direction_output(IGEP00X0_GPIO_LED, 1);
> +#endif
> }
> #endif
>
So, this board doesn't have a GPIO LED to show it boot status?
If that's the case I think there is no point to call show_boot_progress().
Since this function is only compiled when CONFIG_SHOW_BOOT_PROGRESS
is defined. I think that a better approach is to just define it for the
machines that have a boot progress GPIO LED. e.g:
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index 88eadb4..98eed0f 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -85,8 +85,11 @@
#define CONFIG_OMAP_HSMMC 1
#define CONFIG_DOS_PARTITION 1
+#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) || \
+(CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
/* define to enable boot progress via leds */
#define CONFIG_SHOW_BOOT_PROGRESS
+#endif
/* USB */
#define CONFIG_MUSB_UDC1
> diff --git a/board/isee/igep00x0/igep00x0.h b/board/isee/igep00x0/igep00x0.h
> index dbc7cf6..f5fce9c 100644
> --- a/board/isee/igep00x0/igep00x0.h
> +++ b/board/isee/igep00x0/igep00x0.h
> @@ -39,6 +39,9 @@ const omap3_sysinfo sysinfo = {
> #if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
> "IGEP COM MODULE/ELECTRON",
> #endif
> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
> + "IGEP COM PROTON",
> +#endif
> #if defined(CONFIG_ENV_IS_IN_ONENAND)
> "ONENAND",
> #else
> diff --git a/boards.cfg b/boards.cfg
> index 691a32a..8453836 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -259,6 +259,7 @@ igep0020 arm armv7
> igep00x0isee
> igep0020_nandarm armv7 igep00x0
> isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
> igep0030 arm armv7 igep00x0
> isee omap3
> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
> igep0030_nandarm armv7 igep00x0
> isee omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
> +igep0032 arm armv7 igep00x0
> isee omap3
> igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
> am3517_evm arm armv7 am3517evm
> logicpdomap3
> mt_ventoux arm armv7 mt_ventoux
> teejet omap3
> omap3_zoom1 arm armv7 zoom1
> logicpdomap3
> --
This doesn't have a NAND version too like IGEP0020 and IGEP0030 boards?
You said that this board has an on-board ethernet controller. Does
this board use the
SMC911X chip connected to the OMAP GPMC too? In that case I guess you need
something like this to have CONFIG_CMD_NET enabled on
board/isee/igep00x0/igep00x0.c
for this board too:
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index 0e7f924..88eadb4 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -118,7 +118,8 @@
#ifdef CONFIG_BOOT_NAND
#define CONFIG_CMD_NAND
#endif
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
+#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) || \
+(CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/
#endif
#define CONFIG_CMD_DHCP
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Want to study U-Boot code
On Sat, Jan 26, 2013 at 2:07 PM, Woody Wu wrote: > 在 2013-1-26 AM5:27，"Robert P. J. Day" 写道： >> >> On Fri, 25 Jan 2013, Wolfgang Denk wrote: >> >> > Dear Woody Wu, >> > >> > In message c5y...@mail.gmail.com> you wrote: >> > > >> > > I want to firstly get a picture to basically understand how u-boot >> > > work, especially on an ARM9 based board. I think not everyone who >> > > want to understand u-boot has to read the full code. Thank. >> > >> > This depends on your definition of "understanding". On a highlevel, >> > you might start with reaing and digesting the manual, eventually >> > trying out how U-Boot works on some (real or emulated) board. >> >> if i can jump in, a good way to start playing is to configure and >> build for the "sandbox" architecture so you can run it on your x86 >> system. for the benefit of a couple friends, i whipped together a >> wiki page for that here: >> >> http://www.crashcourse.ca/wiki/index.php/U-Boot_sandbox >> >> very simple but enough to get you started, and you can match up >> running the commands with the underlying code. >> >> rday > > Sandbox looks amazing! Thanks share me with this info. But i still > wondering that if u-boot doesnt have any book or document explaining how it > work and how it organized, how pepople can join its development? > Hello Woody, I recommend you to start with the README file since it gives you a high level overview of U-Boot and some very good specifics too. Since you are asking about U-Boot source code organization specifically, you can take a look at the "Directory Hierarchy" section of the README file. But as others stated before, you should first narrow your search to an area that interests you. I found that "scratching your own itch" is the best way to learn. There is no documentation that can replace the source code itself, remember that a good documentation shouldn't say how thinks are made (for that you have the code) but why things were made in a certain way and the design decisions behind that. Finally, if you think that the documentation is not enough, feel free to send patches to improve that :-) As Confusios said "I heard and I forget. I see and I remember. I do and I understand" Hope it helps, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Sat, Jan 26, 2013 at 11:55 AM, Albert ARIBAUD
wrote:
> Hi Tom,
>
> On Fri, 25 Jan 2013 17:13:43 -0500, Tom Rini wrote:
>
>> Hello,
>>
>> The following changes since commit 7cb70a34b976e68f6348ea0718780e8f38901482:
>>
>> fdt: fix dts preprocessor options (2013-01-17 09:07:59 -0700)
>>
>> are available in the git repository at:
>>
>> git://git.denx.de/u-boot-ti.git master
>>
>> for you to fetch changes up to e25a6b504bb0c6e7a3a20cc0d2afacb6d88d29b1:
>>
>> AM335X: Set fdt_high for AM335X devices to enable booting with Device Tree
>> (2013-01-25 17:10:43 -0500)
>>
>>
>> Javier Martinez Canillas (3):
>> OMAP3: use a single board file for IGEP devices
>> OMAP3: igep00x0: add boot status GPIO LED
>> omap4: allow the use of a plain text env file instead boot scripts
>>
>> Jeff Lance (1):
>> Add DDR3 support for AM335x-EVM (Version 1.5A)
>>
>> Lars Poeschel (3):
>> am33xx: add a pulldown macro to pinmux config
>> pcm051: Add support for Phytec phyCORE-AM335x
>> am335x: display msg when reading MAC from efuse
>>
>> hvaib...@ti.com (1):
>> AM335X: Set fdt_high for AM335X devices to enable booting with Device
>> Tree
>>
>> MAINTAINERS|3 +
>> arch/arm/include/asm/arch-am33xx/ddr_defs.h| 34 +++
>> arch/arm/include/asm/arch-am33xx/mux.h |3 +-
>> board/isee/igep0020/igep0020.h | 151 --
>> board/isee/igep0030/Makefile | 43 ---
>> board/isee/igep0030/igep0030.c | 117
>> board/isee/{igep0020 => igep00x0}/Makefile |2 +-
>> .../{igep0020/igep0020.c => igep00x0/igep00x0.c} | 51 +++-
>> .../{igep0030/igep0030.h => igep00x0/igep00x0.h} | 35 ++-
>> board/phytec/pcm051/Makefile | 46 +++
>> board/phytec/pcm051/board.c| 266 +
>> board/phytec/pcm051/board.h| 33 +++
>> board/phytec/pcm051/mux.c | 133 +
>> board/ti/am335x/board.c| 43 ++-
>> boards.cfg |9 +-
>> include/configs/am335x_evm.h |1 +
>> include/configs/igep00x0.h |5 +
>> include/configs/omap4_common.h | 17 +-
>> include/configs/pcm051.h | 301
>>
>> 19 files changed, 951 insertions(+), 342 deletions(-)
>> delete mode 100644 board/isee/igep0020/igep0020.h
>> delete mode 100644 board/isee/igep0030/Makefile
>> delete mode 100644 board/isee/igep0030/igep0030.c
>> rename board/isee/{igep0020 => igep00x0}/Makefile (98%)
>> rename board/isee/{igep0020/igep0020.c => igep00x0/igep00x0.c} (86%)
>> rename board/isee/{igep0030/igep0030.h => igep00x0/igep00x0.h} (93%)
>> create mode 100644 board/phytec/pcm051/Makefile
>> create mode 100644 board/phytec/pcm051/board.c
>> create mode 100644 board/phytec/pcm051/board.h
>> create mode 100644 board/phytec/pcm051/mux.c
>> create mode 100644 include/configs/pcm051.h
>
> Tested with ELDK5.3, this PR introduces warnings in 5 boards.
>
> pcm051 (introduced by 372d1d9367265e2ca698f82197ad657567c405f9):
>
> mux.c:66:30: warning: 'gpio0_7_pin_mux' defined but not used
> [-Wunused-variable]
>
> igep0020, igem0020_nand, igep0030, igep0030_nand (introduced by
> b689cd584c17b985e15744c24710d5ad34a450b0):
>
> igep00x0.h:168:24: warning: backslash-newline at end of file [enabled
> by default]
>
> Commit authors CC:ed.
>
> Amicalement,
> --
> Albert.
Hi Albert,
I didn't see the warning until now, sorry for being so carelessly. In
the future I'll always check for warnings before sending patches.
I already sent a patch to fix this which btw is just this one-liner:
diff --git a/board/isee/igep00x0/igep00x0.h b/board/isee/igep00x0/igep00x0.h
index 3a84335..ea1e9ac 100644
--- a/board/isee/igep00x0/igep00x0.h
+++ b/board/isee/igep00x0/igep00x0.h
@@ -167,4 +167,4 @@ static void setup_net_chip(void);
#define MUX_IGEP0030() \
MUX_VAL(CP(UART1_TX), (IDIS | PTD | DIS | M0)) /* UART1_TX */\
- MUX_VAL(CP(UART1_RX), (IEN | PTD | DIS | M0)) /* UART1_RX */\
+ MUX_VAL(CP(UART1_RX), (IEN | PTD | DIS | M0)) /* UART1_RX */
Thanks a lot and sorry for the inconvenience.
Best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] OMAP3: igep00x0: fix a build warning on IGEP boards
commit b689cd5 OMAP3: use a single board file for IGEP devices introduced the following build warning: igep00x0.h:168:24: warning: backslash-newline at end of file [enabled by default] This patch fixes the issue. Signed-off-by: Javier Martinez Canillas --- board/isee/igep00x0/igep00x0.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/isee/igep00x0/igep00x0.h b/board/isee/igep00x0/igep00x0.h index 3a84335..ea1e9ac 100644 --- a/board/isee/igep00x0/igep00x0.h +++ b/board/isee/igep00x0/igep00x0.h @@ -167,4 +167,4 @@ static void setup_net_chip(void); #define MUX_IGEP0030() \ MUX_VAL(CP(UART1_TX), (IDIS | PTD | DIS | M0)) /* UART1_TX */\ - MUX_VAL(CP(UART1_RX), (IEN | PTD | DIS | M0)) /* UART1_RX */\ + MUX_VAL(CP(UART1_RX), (IEN | PTD | DIS | M0)) /* UART1_RX */ -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] omap4: allow the use of a plain text env file instead boot scripts
On Fri, Jan 11, 2013 at 9:55 PM, Nishanth Menon wrote: > On Mon, Jan 7, 2013 at 7:51 AM, Javier Martinez Canillas > wrote: >> For production systems it is better to use script images since >> they are protected by checksums and carry valuable information like >> name and timestamp. Also, you can't validate the content passed to >> env import. >> >> But for development, it is easier to use the env import command and >> plain text files instead of script-images. >> >> Since both OMAP4 supported boards (Panda and TI SDP4430) are used >> primarily for development, this patch allows U-Boot to load env var >> from a text file in case that an boot.scr script-image is not present. >> >> The variable uenvcmd (if existent) will be executed (using run) after >> uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence >> will be started. >> >> Signed-off-by: Javier Martinez Canillas > Acked-by: Nishanth Menon > > Tested on PandaBoard ES. > Regards, > Nishanth Menon Hello Tom, Any comments on this patch? Thanks a lot and best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] OMAP3: igep00x0: add boot status GPIO LED
On Thu, Jan 10, 2013 at 6:26 PM, Tom Rini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/10/2013 11:16 AM, Javier Martinez Canillas wrote: >> On Thu, Jan 10, 2013 at 4:35 PM, Tom Rini wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> >>> On 01/10/2013 04:43 AM, Javier Martinez Canillas wrote: >>>> On Thu, Dec 27, 2012 at 3:25 PM, Igor Grinberg >>>> wrote: >>>>> On 12/27/12 15:36, Javier Martinez Canillas wrote: >>>>>> This patch adds an GPIO LED boot status for IGEP boards. >>>>>> >>>>>> The GPIO LED used is the red LED0 while the Linux kernel >>>>>> uses the green LED0 as the boot status. >>>>>> >>>>>> By using different GPIO LEDs, the user can know in which >>>>>> step of the boot process the board currently is. >>>>>> >>>>>> Signed-off-by: Javier Martinez Canillas >>>>>> >>>>> >>>>> Acked-by: Igor Grinberg >>>>> >>>> >>>> Hello Tom, >>>> >>>> Any news of merging this patch? >>> >>> Things look good, sorry. I'm going to try and get to starting a >>> next branch but I might not get a chance before the next >>> release. >>> >>> - -- Tom >> >> Great, waiting for the next release is not an issue. >> >> There are also two more patches for IGEP boards that were acked >> but not picked for this release: >> >> [U-Boot,v2,1/2] OMAP3: use a single board file for IGEP devices >> [1] [U-Boot,1/1] OMAP3: igep00x0: add CONFIG_SPL_BOARD_INIT for >> CONFIG_SPL_NAND_SUPPORT [2] > > For the second path, did SPL+NAND for the IGEP devices get added already? > > - -- > Tom Yes, it was added on mainline commit d271a6114 "OMAP3: igep00x0: add SPL support for IGEP-based boards" Before posting that patch I only tested SPL booting from the uSD/MMC and later when trying SPL boot from NAND I realized that CONFIG_SPL_BOARD_INIT was missing to initialize the GPMC. Sorry, my bad. I should have tested both MMC and NAND booting before posting the SPL support patch. Thanks a lot and best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] OMAP3: igep00x0: add boot status GPIO LED
On Thu, Jan 10, 2013 at 4:35 PM, Tom Rini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/10/2013 04:43 AM, Javier Martinez Canillas wrote: >> On Thu, Dec 27, 2012 at 3:25 PM, Igor Grinberg >> wrote: >>> On 12/27/12 15:36, Javier Martinez Canillas wrote: >>>> This patch adds an GPIO LED boot status for IGEP boards. >>>> >>>> The GPIO LED used is the red LED0 while the Linux kernel uses >>>> the green LED0 as the boot status. >>>> >>>> By using different GPIO LEDs, the user can know in which step >>>> of the boot process the board currently is. >>>> >>>> Signed-off-by: Javier Martinez Canillas >>>> >>> >>> Acked-by: Igor Grinberg >>> >> >> Hello Tom, >> >> Any news of merging this patch? > > Things look good, sorry. I'm going to try and get to starting a next > branch but I might not get a chance before the next release. > > - -- > Tom Great, waiting for the next release is not an issue. There are also two more patches for IGEP boards that were acked but not picked for this release: [U-Boot,v2,1/2] OMAP3: use a single board file for IGEP devices [1] [U-Boot,1/1] OMAP3: igep00x0: add CONFIG_SPL_BOARD_INIT for CONFIG_SPL_NAND_SUPPORT [2] Thanks a lot and best regards, Javier [1]: http://patchwork.ozlabs.org/patch/208296/ [2]: http://patchwork.ozlabs.org/patch/208481/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] OMAP3: igep00x0: add boot status GPIO LED
On Thu, Dec 27, 2012 at 3:25 PM, Igor Grinberg wrote: > On 12/27/12 15:36, Javier Martinez Canillas wrote: >> This patch adds an GPIO LED boot status for IGEP boards. >> >> The GPIO LED used is the red LED0 while the Linux kernel >> uses the green LED0 as the boot status. >> >> By using different GPIO LEDs, the user can know in which >> step of the boot process the board currently is. >> >> Signed-off-by: Javier Martinez Canillas > > Acked-by: Igor Grinberg > Hello Tom, Any news of merging this patch? Thanks a lot and best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] omap4: allow the use of a plain text env file instead boot scripts
For production systems it is better to use script images since
they are protected by checksums and carry valuable information like
name and timestamp. Also, you can't validate the content passed to
env import.
But for development, it is easier to use the env import command and
plain text files instead of script-images.
Since both OMAP4 supported boards (Panda and TI SDP4430) are used
primarily for development, this patch allows U-Boot to load env var
from a text file in case that an boot.scr script-image is not present.
The variable uenvcmd (if existent) will be executed (using run) after
uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence
will be started.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2:
- Comment the advantages and drawbacks of using env import instead
of boot scripts as explained by Wolfgang Denk.
- Don't break existing users/distributions that rely on boot.scr by
looking for uEnv.txt only if boot.scr does not exist as suggested
by Tom Rini.
include/configs/omap4_common.h | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index a32369a..dfdfea9 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -159,6 +159,9 @@
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
+ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+ "importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
+ "env import -t ${loadaddr} ${filesize}\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
@@ -166,12 +169,20 @@
#define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
+ "echo SD/MMC found on device ${mmcdev};" \
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
- "if run loaduimage; then " \
- "run mmcboot; " \
- "fi; " \
+ "if run loadbootenv; then " \
+ "run importbootenv; " \
+ "fi;" \
+ "if test -n ${uenvcmd}; then " \
+ "echo Running uenvcmd ...;" \
+ "run uenvcmd;" \
+ "fi;" \
+ "fi;" \
+ "if run loaduimage; then " \
+ "run mmcboot; " \
"fi; " \
"fi"
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] serial/ns16550: check UART mode for TEMT value
On Thu, Jan 3, 2013 at 10:04 PM, Tom Rini wrote:
> On Wed, Jan 2, 2013 at 9:58 PM, Scott Wood wrote:
>> On 12/23/2012 05:17:25 PM, Javier Martinez Canillas wrote:
>>>
>>> On Sat, Dec 22, 2012 at 4:40 AM, Javier Martinez Canillas
>>> wrote:
>>> >
>>> > But if I'm the only one having this issue maybe is just my hardware
>>> > behaving
>>> > badly. I'll ask other OMAP3 users if they can boot with mainline U-Boot
>>> > to
>>> > confirm this.
>>> >
>>>
>>> Hello,
>>>
>>> I tested with an Beagleboard which is another OMAP3 board that has the
>>> same PC16550D UART than my OMAP3 IGEPv2 and the board does not hang
>>> while waiting for TEMT. I've also tested with an OMAP4 pandaboard and
>>> it boots correctly too.
>>>
>>> But the hung issue seems to not be an issue with my IGEPv2 board but
>>> with any IGEPv2 board since another user reported that his board hangs
>>> with the latest U-Boot too. Reverting cb55b332 (serial/ns16550: wait
>>> for TEMT before initializing) solved the issue for him.
>>>
>>> Will a patch like this be an acceptable solution?
>>>
>>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>>> index bbd91ca..8106a9a 100644
>>> --- a/drivers/serial/ns16550.c
>>> +++ b/drivers/serial/ns16550.c
>>> @@ -36,8 +36,10 @@
>>>
>>> void NS16550_init(NS16550_t com_port, int baud_divisor)
>>> {
>>> +#if (CONFIG_MACH_TYPE != MACH_TYPE_IGEP0020)
>>> while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
>>> ;
>>> +#endif
>>
>>
>> Probably better to have your board config file define
>> CONFIG_SYS_NS16550_BROKEN_TEMT or similar (and document the symbol in
>> README).
>
> To be clear, yes, please, that way. Thanks!
>
> --
> Tom
Ok, thanks a lot for the suggestion.
I just sent a patch-set that adds this config option and uses it on
IGEP board config file.
Best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] OMAP3: igep00x0: add CONFIG_SYS_NS16550_BROKEN_TEMT
IGEP board PC16550D (ns16550) UART doesn't set the Transmitter Empty (TEMT) Bit in SPL. This makes U-Boot to hang while waiting for TEMT. Add the CONFIG_SYS_NS16550_BROKEN_TEMT config option to avoid this issue. Signed-off-by: Javier Martinez Canillas --- include/configs/igep00x0.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h index 2110e64..a5912f0 100644 --- a/include/configs/igep00x0.h +++ b/include/configs/igep00x0.h @@ -67,6 +67,9 @@ #define CONFIG_SYS_NS16550_REG_SIZE(-4) #define CONFIG_SYS_NS16550_CLK V_NS16550_CLK +/* define to avoid U-Boot to hang while waiting for TEMT */ +#define CONFIG_SYS_NS16550_BROKEN_TEMT + /* select serial console configuration */ #define CONFIG_CONS_INDEX 3 #define CONFIG_SYS_NS16550_COM3OMAP34XX_UART3 -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] serial/ns16550: add an option to avoid hanging on broken platforms
Some platforms (e.g. IGEPv2 board) has a broken ns16550 UART that
does not set the TEMT bit when the transmitter is empty in SPL.
This makes U-Boot to hang while waiting for TEMT to be set.
Add a new option to avoid this:
CONFIG_SYS_NS16550_BROKEN_TEMT
16550 UART set the Transmitter Empty (TEMT) Bit when all output
has finished and the transmitter is totally empty. U-Boot waits
for this bit to be set to initialize the serial console. On some
broken platforms this bit is not set in SPL making U-Boot to
hang while waiting for TEMT. Define this option to avoid it.
Signed-off-by: Javier Martinez Canillas
---
README |8
drivers/serial/ns16550.c |2 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 78f40df..a89861e 100644
--- a/README
+++ b/README
@@ -616,6 +616,14 @@ The following options need to be configured:
boot loader that has already initialized the UART. Define this
variable to flush the UART at init time.
+ CONFIG_SYS_NS16550_BROKEN_TEMT
+
+ 16550 UART set the Transmitter Empty (TEMT) Bit when all output
+ has finished and the transmitter is totally empty. U-Boot waits
+ for this bit to be set to initialize the serial console. On some
+ broken platforms this bit is not set in SPL making U-Boot to
+ hang while waiting for TEMT. Define this option to avoid it.
+
- Console Interface:
Depending on board, define exactly one serial port
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index bbd91ca..87a0917 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,8 +36,10 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
+#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
;
+#endif
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
#if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] omap4: use plain text env file instead boot scripts
On Wed, Jan 2, 2013 at 3:39 PM, Tom Rini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/25/12 09:15, Javier Martinez Canillas wrote: >> Based on commit cf073e49bc3502be1b48a0e3faf0cde9edbb89db for >> beagleboard >> >> Using the new env import command it is possible to use plain text >> files instead of script-images. Plain text files are much easier >> to handle. > > The only problem I see with this is that in beagle-land there was some > regret we didn't make this an either/or. In other words, look for > uEnv.txt, if found, use it, otherwise see if we have a boot.scr, if so > use it, and if we still haven't been then keep trying a "normal" boot > from MMC. This means we don't break existing users (or distributions) > that had been relying on boot.scr being used automatically. > > - -- > Tom Hi Tom, I see, I'll post a v2 then that fallbacks to boot.scr in case uEnv.txt is not found. I'll post a patch to fix the beagle and IGEP boards as well. Thanks a lot and best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] OMAP3: igep00x0: add CONFIG_SPL_BOARD_INIT for CONFIG_SPL_NAND_SUPPORT
When booting an IGEPv2 board from NAND with SPL, U-Boot hangs trying to read the OMAP General Purpose Memory Controller (GPMC). The reason is that the GPMC initialization function is called inside spl_board_init() and this function is only executed when CONFIG_SPL_BOARD_INIT is defined. Signed-off-by: Javier Martinez Canillas --- include/configs/igep00x0.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h index 47f637e..2110e64 100644 --- a/include/configs/igep00x0.h +++ b/include/configs/igep00x0.h @@ -318,6 +318,7 @@ #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1 #define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img" +#define CONFIG_SPL_BOARD_INIT #define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBDISK_SUPPORT #define CONFIG_SPL_I2C_SUPPORT -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] OMAP3: use a single board file for IGEP devices
On Thu, Dec 27, 2012 at 9:07 AM, Igor Grinberg wrote:
> Hi Javier,
>
Hi Igor,
Thanks a lot for your feedback.
> On 12/26/12 05:24, Javier Martinez Canillas wrote:
>> Even when the IGEPv2 board and the IGEP Computer-on-Module
>> are different from a form factor point of view, they are
>> very similar in the fact that share many components and how
>> they are wired.
>>
>> So, it is possible (and better) to have a single board file
>> for both devices and just use the CONFIG_MACH_TYPE to make
>> a differentiation between both boards when needed.
>
> I'm wondering... isn't there a way to distinguish between the boards
> in runtime?
> Because if there is, you could even use the same binary.
> This is what we do on cm-t3530/cm-t3730 and is very maintainable,
> avoids code duplication, and avoids multiple ifdeffery.
>
Sadly there isn't.
It would have been great to have a way to distinguish between the two
boards but it seems the IGEP hardware designers decided this was not
necessary.
>>
>> This change avoids duplication by removing 298 lines of code
>> and makes future maintenance easier.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>> board/isee/igep0020/Makefile | 43 -
>> board/isee/igep0020/igep0020.c | 177 --
>> board/isee/igep0020/igep0020.h | 151
>> board/isee/igep0030/Makefile | 43 -
>> board/isee/igep0030/igep0030.c | 118 -
>> board/isee/igep0030/igep0030.h | 151
>> board/isee/igep00x0/Makefile | 43 +
>> board/isee/igep00x0/igep00x0.c | 186
>>
>> board/isee/igep00x0/igep00x0.h | 165 +++
>> boards.cfg |8 +-
>> 10 files changed, 398 insertions(+), 687 deletions(-)
>> delete mode 100644 board/isee/igep0020/Makefile
>> delete mode 100644 board/isee/igep0020/igep0020.c
>> delete mode 100644 board/isee/igep0020/igep0020.h
>> delete mode 100644 board/isee/igep0030/Makefile
>> delete mode 100644 board/isee/igep0030/igep0030.c
>> delete mode 100644 board/isee/igep0030/igep0030.h
>> create mode 100644 board/isee/igep00x0/Makefile
>> create mode 100644 board/isee/igep00x0/igep00x0.c
>> create mode 100644 board/isee/igep00x0/igep00x0.h
>
> [...]
>
>> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
>> new file mode 100644
>> index 000..c8b2fbf
>> --- /dev/null
>> +++ b/board/isee/igep00x0/igep00x0.c
>
> [...]
>
>> +#include
>> +#include
>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
>> +#include
>> +#include
>> +#include
>> +#endif
>
> Is there a problem including three above files for igep0030?
> If not, then it will be better to remove the if.
>
Ok, will do.
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include "igep00x0.h"
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) && defined(CONFIG_CMD_NET)
>
> Does the igep0030 uses CONFIG_CMD_NET?
> If it does not, then you can just disable CONFIG_CMD_NET for igep0030
> and here (and other net related places) just use
> #ifdef CONFIG_CMD_NET
>
Ok, will simplify this too.
>> +/* GPMC definitions for LAN9221 chips */
>> +static const u32 gpmc_lan_config[] = {
>> + NET_LAN9221_GPMC_CONFIG1,
>> + NET_LAN9221_GPMC_CONFIG2,
>> + NET_LAN9221_GPMC_CONFIG3,
>> + NET_LAN9221_GPMC_CONFIG4,
>> + NET_LAN9221_GPMC_CONFIG5,
>> + NET_LAN9221_GPMC_CONFIG6,
>> +};
>> +#endif
>
> [...]
>
>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) && defined(CONFIG_CMD_NET)
>> +/*
>> + * Routine: setup_net_chip
>> + * Description: Setting up the configuration GPMC registers specific to the
>> + * Ethernet hardware.
>> + */
>> +static void setup_net_chip(void)
>> +{
>> + struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
>> +
>> + enable_gpmc_cs_config(gpmc_lan_config, &gpmc_cfg->cs[5], 0x2C00,
>> + GPMC_SIZE_16M);
>> +
>> + /* Enable off mode for NWE in PADCONF_GPMC_NWE register */
>> + writew(readw(&ctrl_base->gpmc_nwe) | 0x0E00, &ctrl_base->gpmc_nwe);
>> + /* Enable off mode for NOE in PADCONF_GPMC_NADV_ALE register */
>> + writew(readw
[U-Boot] [PATCH v5 2/2] OMAP3: igep00x0: add boot status GPIO LED
This patch adds an GPIO LED boot status for IGEP boards.
The GPIO LED used is the red LED0 while the Linux kernel
uses the green LED0 as the boot status.
By using different GPIO LEDs, the user can know in which
step of the boot process the board currently is.
Signed-off-by: Javier Martinez Canillas
---
Changes since v4:
- Since gpio_direction_output() sets the value, there is no need
to call gpio_set_value() as suggested by Igor Grinberg.
Changes since v3:
- Avoid code duplication but having a single show_boot_progress()
function as suggested by Wolfgang Denk.
Changes since v2:
- Use show_boot_progress() instead implementing yet another boot status
signalling as suggested by Wolfgang Denk.
Changes since v1:
- Don't set gd->bd->bi_arch_number since is done in arch/arm/lib/board.c
- Use CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020 instead of check bi_arch_number
as suggested by Igor Grinberg.
board/isee/igep00x0/igep00x0.c | 13 +
board/isee/igep00x0/igep00x0.h |8
include/configs/igep00x0.h |3 +++
3 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
index fe3522a..931416a 100644
--- a/board/isee/igep00x0/igep00x0.c
+++ b/board/isee/igep00x0/igep00x0.c
@@ -60,6 +60,19 @@ int board_init(void)
return 0;
}
+#if defined(CONFIG_SHOW_BOOT_PROGRESS) && !defined(CONFIG_SPL_BUILD)
+void show_boot_progress(int val)
+{
+ if (val < 0) {
+ /* something went wrong */
+ return;
+ }
+
+ if (!gpio_request(IGEP00X0_GPIO_LED, ""))
+ gpio_direction_output(IGEP00X0_GPIO_LED, 1);
+}
+#endif
+
#ifdef CONFIG_SPL_BUILD
/*
* Routine: omap_rev_string
diff --git a/board/isee/igep00x0/igep00x0.h b/board/isee/igep00x0/igep00x0.h
index 3133e41..fefdb89 100644
--- a/board/isee/igep00x0/igep00x0.h
+++ b/board/isee/igep00x0/igep00x0.h
@@ -23,6 +23,14 @@
#ifndef _IGEP00X0_H_
#define _IGEP00X0_H_
+#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
+#define IGEP00X0_GPIO_LED 27
+#endif
+
+#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
+#define IGEP00X0_GPIO_LED 16
+#endif
+
const omap3_sysinfo sysinfo = {
DDR_STACKED,
#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index 15e233b..47f637e 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -82,6 +82,9 @@
#define CONFIG_OMAP_HSMMC 1
#define CONFIG_DOS_PARTITION 1
+/* define to enable boot progress via leds */
+#define CONFIG_SHOW_BOOT_PROGRESS
+
/* USB */
#define CONFIG_MUSB_UDC1
#define CONFIG_USB_OMAP3 1
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] OMAP3: igep00x0: add boot status GPIO LED
On 12/27/2012 02:16 PM, Igor Grinberg wrote:> On 12/26/12 05:24,
Javier Martinez Canillas wrote:
>> This patch adds an GPIO LED boot status for IGEP boards.
>>
>> The GPIO LED used is the red LED0 while the Linux kernel
>> uses the green LED0 as the boot status.
>>
>> By using different GPIO LEDs, the user can know in which
>> step of the boot process the board currently is.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>>
>> Changes since v3:
>> - Avoid code duplication but having a single show_boot_progress()
>> function as suggested by Wolfgang Denk.
>>
>> Changes since v2:
>> - Use show_boot_progress() instead implementing yet another boot status
>> signalling as suggested by Wolfgang Denk.
>>
>> Changes since v1:
>> - Don't set gd->bd->bi_arch_number since is done in arch/arm/lib/board.c
>> - Use CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020 instead of check
>> bi_arch_number
>> as suggested by Igor Grinberg.
>>
>> board/isee/igep00x0/igep00x0.c | 15 +++
>> board/isee/igep00x0/igep00x0.h |8
>> include/configs/igep00x0.h |3 +++
>> 3 files changed, 26 insertions(+), 0 deletions(-)
>>
>> diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
>> index c8b2fbf..c432129 100644
>> --- a/board/isee/igep00x0/igep00x0.c
>> +++ b/board/isee/igep00x0/igep00x0.c
>> @@ -62,6 +62,21 @@ int board_init(void)
>> return 0;
>> }
>>
>> +#if defined(CONFIG_SHOW_BOOT_PROGRESS) && !defined(CONFIG_SPL_BUILD)
>> +void show_boot_progress(int val)
>> +{
>> +if (val < 0) {
>> +/* something went wrong */
>> +return;
>> +}
>> +
>> +if (!gpio_request(IGEP00X0_GPIO_LED, "")) {
>> +gpio_direction_output(IGEP00X0_GPIO_LED, 0);
>> +gpio_set_value(IGEP00X0_GPIO_LED, 1);
>
> gpio_direction_output() also sets the value.
> Why do you need to call gpio_set_value() afterwards?
> Also, you don't have any delay in between,
> so it does not look like a "blink"...
>
Hi Igor,
Yes, it's not meant to blink, but keep the led on I just didn't know
that it also sets the value.
Will send a new version with gpio_direction_output(IGEP00X0_GPIO_LED,
1) and remove gpio_set_value().
>> +}
>> +}
>> +#endif
>> +
>> #ifdef CONFIG_SPL_BUILD
>> /*
>> * Routine: omap_rev_string
>> diff --git a/board/isee/igep00x0/igep00x0.h b/board/isee/igep00x0/igep00x0.h
>> index 83822d2..4b81960 100644
>> --- a/board/isee/igep00x0/igep00x0.h
>> +++ b/board/isee/igep00x0/igep00x0.h
>> @@ -23,6 +23,14 @@
>> #ifndef _IGEP00X0_H_
>> #define _IGEP00X0_H_
>>
>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
>> +#define IGEP00X0_GPIO_LED 27
>> +#endif
>> +
>> +#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
>> +#define IGEP00X0_GPIO_LED 16
>> +#endif
>> +
>> const omap3_sysinfo sysinfo = {
>> DDR_STACKED,
>> #if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
>> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
>> index be7937d..07b1d3a 100644
>> --- a/include/configs/igep00x0.h
>> +++ b/include/configs/igep00x0.h
>> @@ -82,6 +82,9 @@
>> #define CONFIG_OMAP_HSMMC 1
>> #define CONFIG_DOS_PARTITION1
>>
>> +/* define to enable boot progress via leds */
>> +#define CONFIG_SHOW_BOOT_PROGRESS
>> +
>> /* USB */
>> #define CONFIG_MUSB_UDC 1
>> #define CONFIG_USB_OMAP31
>
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] OMAP3: use a single board file for IGEP devices
Even when the IGEPv2 board and the IGEP Computer-on-Module
are different from a form factor point of view, they are
very similar in the fact that share many components and how
they are wired.
So, it is possible (and better) to have a single board file
for both devices and just use the CONFIG_MACH_TYPE to make
a differentiation between each board when needed.
This change avoids code duplication by removing 298 lines of
code and makes future maintenance easier.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1 (suggested by Igor Grinberg):
- Remove unnecesary ifdeffery
- set CONFIG_CMD_NET just if CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020
- Move board specific muxes configuration to set_muxconf_regs()
board/isee/igep0020/Makefile | 43 -
board/isee/igep0020/igep0020.c | 177 -
board/isee/igep0020/igep0020.h | 151
board/isee/igep0030/Makefile | 43 -
board/isee/igep0030/igep0030.c | 118 -
board/isee/igep0030/igep0030.h | 151
board/isee/igep00x0/Makefile | 43 +
board/isee/igep00x0/igep00x0.c | 189
board/isee/igep00x0/igep00x0.h | 163 ++
boards.cfg |8 +-
include/configs/igep00x0.h |2 +
11 files changed, 401 insertions(+), 687 deletions(-)
delete mode 100644 board/isee/igep0020/Makefile
delete mode 100644 board/isee/igep0020/igep0020.c
delete mode 100644 board/isee/igep0020/igep0020.h
delete mode 100644 board/isee/igep0030/Makefile
delete mode 100644 board/isee/igep0030/igep0030.c
delete mode 100644 board/isee/igep0030/igep0030.h
create mode 100644 board/isee/igep00x0/Makefile
create mode 100644 board/isee/igep00x0/igep00x0.c
create mode 100644 board/isee/igep00x0/igep00x0.h
diff --git a/board/isee/igep0020/Makefile b/board/isee/igep0020/Makefile
deleted file mode 100644
index 00463e1..000
--- a/board/isee/igep0020/Makefile
+++ /dev/null
@@ -1,43 +0,0 @@
-#
-# (C) Copyright 2000, 2001, 2002
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-# MA 02111-1307 USA
-#
-
-include $(TOPDIR)/config.mk
-
-LIB= $(obj)lib$(BOARD).o
-
-COBJS := igep0020.o
-
-SRCS := $(COBJS:.o=.c)
-OBJS := $(addprefix $(obj),$(COBJS))
-
-$(LIB):$(obj).depend $(OBJS)
- $(call cmd_link_o_target, $(OBJS))
-
-#
-
-# defines $(obj).depend target
-include $(SRCTREE)/rules.mk
-
-sinclude $(obj).depend
-
-#
diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c
deleted file mode 100644
index a8257a3..000
--- a/board/isee/igep0020/igep0020.c
+++ /dev/null
@@ -1,177 +0,0 @@
-/*
- * (C) Copyright 2010
- * ISEE 2007 SL,
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "igep0020.h"
-
-DECLARE_GLOBAL_DATA_PTR;
-
-/* GPMC definitions for LAN9221 chips */
-static const u32 gpmc_lan_config[] = {
-NET_LAN9221_GPMC_CONFIG1,
-NET_LAN9221_GPMC_CONFIG2,
-NET_LAN9221_GPMC_CONFIG3,
-NET_LAN9221_GPMC_CONFIG4,
-NET_LAN9221_GPMC_CONFIG5,
-NET_LAN9221_GPMC_CONFIG6,
-};
-
-/*
-
Re: [U-Boot] [PATCH 1/1] omap4: use plain text env file instead boot scripts
On Wed, Dec 26, 2012 at 12:40 PM, Wolfgang Denk wrote: > Dear Javier, > Hello Wolfgang, > In message > you > wrote: >> >> I think this change makes sense not only to be consistent with the >> OMAP3 Beagle board boot sequence but also to make it easier for >> developers to modify U-Boot environment variables. > > I wasn't aware that Beagle implemented such a change (otherwise I > woul dhave raised my concernes then). > The change was introduced on commit "cf073e4 omap3_beagle: enable the use of a plain text file" >> But yes, it's not hard to execute mkimage -T script too, so is your call :-) > > I don't intend to block any such changes. I just wanted to make sure > everybody involved is aware of the consequences. [I would not have > added the text file import mode if I did not consider it useful :-) ] > Indeed :-) > So if you consider this a useful change, please feel free and go > ahead. It is fine with me. > Yes, since this is a development board used primary by developers I think the change is useful. But thanks a lot for raising your concerns and explaining the consequences. > Best regards, > > Wolfgang Denk > Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] omap4: use plain text env file instead boot scripts
On Tue, Dec 25, 2012 at 9:00 PM, Wolfgang Denk wrote: > Dear Javier Martinez Canillas, > Dear Wolfgang, > In message > <1356444923-16737-1-git-send-email-javier.marti...@collabora.co.uk> you wrote: >> Based on commit cf073e49bc3502be1b48a0e3faf0cde9edbb89db for beagleboard >> >> Using the new env import command it is possible to use plain text files >> instead >> of script-images. Plain text files are much easier to handle. > > Are you sure you want to do this in a production environment? The > ease of use may be helpful during development, but please note that > there is no validation of the content passed to env import in any way > - and feeding it crap you can even crash the system - not to mention > from the problems that can result from corrupted environment settings. > > Script images are checksum protected, which appears to be a > significant advantage to me - also, they carry information like name > and timestamp, which in production environments are often very helpful > to diagnose problems (like asking your customers: which exact version > of the environment script are you loading?). > I understand your concern and I do agree that for production environments boot scripts are both better and more secure than just importing a plain text with environment variables. But the Panda board and the Beagle board are not meant to be used to build products but to be evaluation boards for OMAP technology. The official Panda board web site [1] advertise the board as an development platform: "PandaBoard is intended to be used as a platform for software development." And even the Panda board FAQ [2] has an answer for this question: "PandaBoard is designed to be a vehicle for mobile software development. PandaBoard is neither an end product nor is designed to be directly included in an end product." So, If someone wants to use a test/development platform to build a product I think he/she should already have bigger things to worry about. I think this change makes sense not only to be consistent with the OMAP3 Beagle board boot sequence but also to make it easier for developers to modify U-Boot environment variables. But yes, it's not hard to execute mkimage -T script too, so is your call :-) > Best regards, > > Wolfgang Denk > Thanks a lot and best regards, Javier [1]:http://pandaboard.org/content/platform [2]:http://omappedia.org/wiki/PandaBoard_FAQ#Is_PandaBoard_an_end_product.3F_Or.2C_can_I_use_PandaBoard_in_my_end_product.3F ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/2] OMAP3: igep00x0: add boot status GPIO LED
This patch adds an GPIO LED boot status for IGEP boards.
The GPIO LED used is the red LED0 while the Linux kernel
uses the green LED0 as the boot status.
By using different GPIO LEDs, the user can know in which
step of the boot process the board currently is.
Signed-off-by: Javier Martinez Canillas
---
Changes since v3:
- Avoid code duplication but having a single show_boot_progress()
function as suggested by Wolfgang Denk.
Changes since v2:
- Use show_boot_progress() instead implementing yet another boot status
signalling as suggested by Wolfgang Denk.
Changes since v1:
- Don't set gd->bd->bi_arch_number since is done in arch/arm/lib/board.c
- Use CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020 instead of check bi_arch_number
as suggested by Igor Grinberg.
board/isee/igep00x0/igep00x0.c | 15 +++
board/isee/igep00x0/igep00x0.h |8
include/configs/igep00x0.h |3 +++
3 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
index c8b2fbf..c432129 100644
--- a/board/isee/igep00x0/igep00x0.c
+++ b/board/isee/igep00x0/igep00x0.c
@@ -62,6 +62,21 @@ int board_init(void)
return 0;
}
+#if defined(CONFIG_SHOW_BOOT_PROGRESS) && !defined(CONFIG_SPL_BUILD)
+void show_boot_progress(int val)
+{
+ if (val < 0) {
+ /* something went wrong */
+ return;
+ }
+
+ if (!gpio_request(IGEP00X0_GPIO_LED, "")) {
+ gpio_direction_output(IGEP00X0_GPIO_LED, 0);
+ gpio_set_value(IGEP00X0_GPIO_LED, 1);
+ }
+}
+#endif
+
#ifdef CONFIG_SPL_BUILD
/*
* Routine: omap_rev_string
diff --git a/board/isee/igep00x0/igep00x0.h b/board/isee/igep00x0/igep00x0.h
index 83822d2..4b81960 100644
--- a/board/isee/igep00x0/igep00x0.h
+++ b/board/isee/igep00x0/igep00x0.h
@@ -23,6 +23,14 @@
#ifndef _IGEP00X0_H_
#define _IGEP00X0_H_
+#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
+#define IGEP00X0_GPIO_LED 27
+#endif
+
+#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
+#define IGEP00X0_GPIO_LED 16
+#endif
+
const omap3_sysinfo sysinfo = {
DDR_STACKED,
#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index be7937d..07b1d3a 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -82,6 +82,9 @@
#define CONFIG_OMAP_HSMMC 1
#define CONFIG_DOS_PARTITION 1
+/* define to enable boot progress via leds */
+#define CONFIG_SHOW_BOOT_PROGRESS
+
/* USB */
#define CONFIG_MUSB_UDC1
#define CONFIG_USB_OMAP3 1
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] OMAP3: use a single board file for IGEP devices
Even when the IGEPv2 board and the IGEP Computer-on-Module
are different from a form factor point of view, they are
very similar in the fact that share many components and how
they are wired.
So, it is possible (and better) to have a single board file
for both devices and just use the CONFIG_MACH_TYPE to make
a differentiation between both boards when needed.
This change avoids duplication by removing 298 lines of code
and makes future maintenance easier.
Signed-off-by: Javier Martinez Canillas
---
board/isee/igep0020/Makefile | 43 -
board/isee/igep0020/igep0020.c | 177 --
board/isee/igep0020/igep0020.h | 151
board/isee/igep0030/Makefile | 43 -
board/isee/igep0030/igep0030.c | 118 -
board/isee/igep0030/igep0030.h | 151
board/isee/igep00x0/Makefile | 43 +
board/isee/igep00x0/igep00x0.c | 186
board/isee/igep00x0/igep00x0.h | 165 +++
boards.cfg |8 +-
10 files changed, 398 insertions(+), 687 deletions(-)
delete mode 100644 board/isee/igep0020/Makefile
delete mode 100644 board/isee/igep0020/igep0020.c
delete mode 100644 board/isee/igep0020/igep0020.h
delete mode 100644 board/isee/igep0030/Makefile
delete mode 100644 board/isee/igep0030/igep0030.c
delete mode 100644 board/isee/igep0030/igep0030.h
create mode 100644 board/isee/igep00x0/Makefile
create mode 100644 board/isee/igep00x0/igep00x0.c
create mode 100644 board/isee/igep00x0/igep00x0.h
diff --git a/board/isee/igep0020/Makefile b/board/isee/igep0020/Makefile
deleted file mode 100644
index 00463e1..000
--- a/board/isee/igep0020/Makefile
+++ /dev/null
@@ -1,43 +0,0 @@
-#
-# (C) Copyright 2000, 2001, 2002
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-# MA 02111-1307 USA
-#
-
-include $(TOPDIR)/config.mk
-
-LIB= $(obj)lib$(BOARD).o
-
-COBJS := igep0020.o
-
-SRCS := $(COBJS:.o=.c)
-OBJS := $(addprefix $(obj),$(COBJS))
-
-$(LIB):$(obj).depend $(OBJS)
- $(call cmd_link_o_target, $(OBJS))
-
-#
-
-# defines $(obj).depend target
-include $(SRCTREE)/rules.mk
-
-sinclude $(obj).depend
-
-#
diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c
deleted file mode 100644
index a8257a3..000
--- a/board/isee/igep0020/igep0020.c
+++ /dev/null
@@ -1,177 +0,0 @@
-/*
- * (C) Copyright 2010
- * ISEE 2007 SL,
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "igep0020.h"
-
-DECLARE_GLOBAL_DATA_PTR;
-
-/* GPMC definitions for LAN9221 chips */
-static const u32 gpmc_lan_config[] = {
-NET_LAN9221_GPMC_CONFIG1,
-NET_LAN9221_GPMC_CONFIG2,
-NET_LAN9221_GPMC_CONFIG3,
-NET_LAN9221_GPMC_CONFIG4,
-NET_LAN9221_GPMC_CONFIG5,
-NET_LAN9221_GPMC_CONFIG6,
-};
-
-/*
- * Routine: board_init
- * Description: Early hardware init.
- */
-int board_init(void)
-{
- gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
- /* boot param addr */
- gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
-
- return
Re: [U-Boot] [PATCH v3 1/1] OMAP3: add boot status GPIO LED for IGEP boards
On Tue, Dec 25, 2012 at 8:57 PM, Wolfgang Denk wrote:
> Dear Javier Martinez Canillas,
>
Hello Wolfang,
Thanks a lot for your suggestions.
> In message
> <1356349896-11693-1-git-send-email-javier.marti...@collabora.co.uk> you wrote:
>> This patch adds an GPIO LED boot status for IGEP boards.
>>
>> The GPIO LED used is the red LED0 while the Linux kernel
>> uses the green LED0 as the boot status.
>>
>> By using different GPIO LEDs, the user can know in which
>> step of the boot process the board currently is.
>>
>> Signed-off-by: Javier Martinez Canillas
> ...
>> --- a/board/isee/igep0020/igep0020.c
>> +++ b/board/isee/igep0020/igep0020.c
> ...
>> +#if defined(CONFIG_SHOW_BOOT_PROGRESS) && !defined(CONFIG_SPL_BUILD)
>> +void show_boot_progress(int val)
>> +{
>> + if (val < 0) {
>> + /* something went wrong */
>> + return;
>> + }
>> +
>> + if (!gpio_request(IGEP0020_GPIO_LED, "")) {
>> + gpio_direction_output(IGEP0020_GPIO_LED, 0);
>> + gpio_set_value(IGEP0020_GPIO_LED, 1);
>> + }
>> +}
>> +#endif
> ...
>> --- a/board/isee/igep0030/igep0030.c
>> +++ b/board/isee/igep0030/igep0030.c
> ...
>> +#if defined(CONFIG_SHOW_BOOT_PROGRESS) && !defined(CONFIG_SPL_BUILD)
>> +void show_boot_progress(int val)
>> +{
>> + if (val < 0) {
>> + /* something went wrong */
>> + return;
>> + }
>> +
>> + if (!gpio_request(IGEP0030_GPIO_LED, "")) {
>> + gpio_direction_output(IGEP0030_GPIO_LED, 0);
>> + gpio_set_value(IGEP0030_GPIO_LED, 1);
>> + }
>> +}
>> +#endif
>
> Can we not avoid duplicating this code? If you change
> IGEP0020_GPIO_LED and IGEP0030_GPIO_LED into some common name like
> IGEP00XX_GPIO_LED, you can use common code for all such boards.
>
Yes, in fact I'm going to send a patch that removes the code
duplication between igep0020 and igep0030 by using a single board file
for both devices and a following patch that adds a single GPIO LED
support function for both boards.
> Thanks.
>
> Best regards,
>
> Wolfgang Denk
>
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] omap4: use plain text env file instead boot scripts
Based on commit cf073e49bc3502be1b48a0e3faf0cde9edbb89db for beagleboard
Using the new env import command it is possible to use plain text files instead
of script-images. Plain text files are much easier to handle.
E.g. If your boot.scr contains the following:
---
setenv dvimode 1024x768-16@60
run loaduimage
run mmcboot
---
you could create a file named uEnv.txt and use that instead of boot.scr:
---
dvimode=1024x768-16@60
uenvcmd=run loaduimage; run mmcboot
---
The variable uenvcmd (if existent) will be executed (using run) after uEnv.txt
was loaded. If uenvcmd doesn't exist the default boot sequence will be started,
therefore you could just use
---
dvimode=1024x768-16@60
---
as uEnv.txt because loaduimage and mmcboot is part of the default boot sequence
Signed-off-by: Javier Martinez Canillas
---
include/configs/omap4_common.h | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index a32369a..a821c01 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -156,9 +156,9 @@
"vram=${vram} " \
"root=${mmcroot} " \
"rootfstype=${mmcrootfstype}\0" \
- "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
- "bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
- "source ${loadaddr}\0" \
+ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+ "importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
+ "env import -t ${loadaddr} ${filesize}\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
@@ -166,12 +166,16 @@
#define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
- "if run loadbootscript; then " \
- "run bootscript; " \
- "else " \
- "if run loaduimage; then " \
- "run mmcboot; " \
- "fi; " \
+ "echo SD/MMC found on device ${mmcdev};" \
+ "if run loadbootenv; then " \
+ "run importbootenv; " \
+ "fi;" \
+ "if test -n ${uenvcmd}; then " \
+ "echo Running uenvcmd ...;" \
+ "run uenvcmd;" \
+ "fi;" \
+ "if run loaduimage; then " \
+ "run mmcboot; " \
"fi; " \
"fi"
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] OMAP3: add boot status GPIO LED for IGEP boards
On Mon, Dec 24, 2012 at 1:39 AM, Wolfgang Denk wrote: > Dear Javier Martinez Canillas, > Hello Wolfgang, Thanks a lot for your feedback. > In message > <1356265899-18669-1-git-send-email-javier.marti...@collabora.co.uk> you wrote: >> This patch adds an GPIO LED boot status for IGEP boards. >> >> The GPIO LED used is the red LED0 while the Linux kernel >> uses the green LED0 as the boot status. >> >> By using different GPIO LEDs, the user can know in which >> step of the boot process the board currently is. >> >> Signed-off-by: Javier Martinez Canillas > > Do we really need yet another implementation of boot status > signalling? I think no. > > Please implement this a board specific version of the > show_boot_progress() feature (see CONFIG_SHOW_BOOT_PROGRESS). > ok, I wasn't aware of the CONFIG_SHOW_BOOT_PROGRESS infrastructure and thought that CONFIG_STATUS_LED was the way to go. > Thanks - and sorry, but NAK for this implementation. > ok, I'll send a v3 using show_boot_progress(). > Best regards, > > Wolfgang Denk > Thanks a lot and merry christmas! Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/1] OMAP3: add boot status GPIO LED for IGEP boards
This patch adds an GPIO LED boot status for IGEP boards.
The GPIO LED used is the red LED0 while the Linux kernel
uses the green LED0 as the boot status.
By using different GPIO LEDs, the user can know in which
step of the boot process the board currently is.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2:
- Use show_boot_progress() instead implementing yet another boot status
signalling as suggested by Wolfgang Denk.
Changes since v1:
- Don't set gd->bd->bi_arch_number since is done in arch/arm/lib/board.c
- Use CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020 instead of check bi_arch_number
as suggested by Igor Grinberg.
board/isee/igep0020/igep0020.c | 15 +++
board/isee/igep0020/igep0020.h |2 ++
board/isee/igep0030/igep0030.c | 15 +++
board/isee/igep0030/igep0030.h |2 ++
include/configs/igep00x0.h |3 +++
5 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c
index a8257a3..5b6afa9 100644
--- a/board/isee/igep0020/igep0020.c
+++ b/board/isee/igep0020/igep0020.c
@@ -58,6 +58,21 @@ int board_init(void)
return 0;
}
+#if defined(CONFIG_SHOW_BOOT_PROGRESS) && !defined(CONFIG_SPL_BUILD)
+void show_boot_progress(int val)
+{
+ if (val < 0) {
+ /* something went wrong */
+ return;
+ }
+
+ if (!gpio_request(IGEP0020_GPIO_LED, "")) {
+ gpio_direction_output(IGEP0020_GPIO_LED, 0);
+ gpio_set_value(IGEP0020_GPIO_LED, 1);
+ }
+}
+#endif
+
#ifdef CONFIG_SPL_BUILD
/*
* Routine: omap_rev_string
diff --git a/board/isee/igep0020/igep0020.h b/board/isee/igep0020/igep0020.h
index 3335ecc..1958bdd 100644
--- a/board/isee/igep0020/igep0020.h
+++ b/board/isee/igep0020/igep0020.h
@@ -23,6 +23,8 @@
#ifndef _IGEP0020_H_
#define _IGEP0020_H_
+#define IGEP0020_GPIO_LED 27
+
const omap3_sysinfo sysinfo = {
DDR_STACKED,
"IGEP v2 board",
diff --git a/board/isee/igep0030/igep0030.c b/board/isee/igep0030/igep0030.c
index 107cb7f..91aff8c 100644
--- a/board/isee/igep0030/igep0030.c
+++ b/board/isee/igep0030/igep0030.c
@@ -45,6 +45,21 @@ int board_init(void)
return 0;
}
+#if defined(CONFIG_SHOW_BOOT_PROGRESS) && !defined(CONFIG_SPL_BUILD)
+void show_boot_progress(int val)
+{
+ if (val < 0) {
+ /* something went wrong */
+ return;
+ }
+
+ if (!gpio_request(IGEP0030_GPIO_LED, "")) {
+ gpio_direction_output(IGEP0030_GPIO_LED, 0);
+ gpio_set_value(IGEP0030_GPIO_LED, 1);
+ }
+}
+#endif
+
#ifdef CONFIG_SPL_BUILD
/*
* Routine: omap_rev_string
diff --git a/board/isee/igep0030/igep0030.h b/board/isee/igep0030/igep0030.h
index a93339d..42c2d9c 100644
--- a/board/isee/igep0030/igep0030.h
+++ b/board/isee/igep0030/igep0030.h
@@ -23,6 +23,8 @@
#ifndef _IGEP0030_H_
#define _IGEP0030_H_
+#define IGEP0030_GPIO_LED 16
+
const omap3_sysinfo sysinfo = {
DDR_STACKED,
"OMAP3 IGEP module",
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index be7937d..07b1d3a 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -82,6 +82,9 @@
#define CONFIG_OMAP_HSMMC 1
#define CONFIG_DOS_PARTITION 1
+/* define to enable boot progress via leds */
+#define CONFIG_SHOW_BOOT_PROGRESS
+
/* USB */
#define CONFIG_MUSB_UDC1
#define CONFIG_USB_OMAP3 1
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] OMAP3: add boot status GPIO LED for IGEP boards
This patch adds an GPIO LED boot status for IGEP boards.
The GPIO LED used is the red LED0 while the Linux kernel
uses the green LED0 as the boot status.
By using different GPIO LEDs, the user can know in which
step of the boot process the board currently is.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- Don't set gd->bd->bi_arch_number since is done in arch/arm/lib/board.c
- Use CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020 instead of check bi_arch_number
as suggested by Igor Grinberg.
board/isee/igep0020/Makefile |4 ++-
board/isee/igep0020/igep0020.c |7 +
board/isee/igep0030/Makefile |4 ++-
board/isee/igep0030/igep0030.c |7 +
board/isee/led.c | 58
include/configs/igep00x0.h | 11 +++
6 files changed, 89 insertions(+), 2 deletions(-)
create mode 100644 board/isee/led.c
diff --git a/board/isee/igep0020/Makefile b/board/isee/igep0020/Makefile
index 00463e1..5ead151 100644
--- a/board/isee/igep0020/Makefile
+++ b/board/isee/igep0020/Makefile
@@ -25,8 +25,10 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := igep0020.o
+COBJS-y := igep0020.o
+COBJS-$(CONFIG_STATUS_LED) += ../led.o
+COBJS := $(sort $(COBJS-y))
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c
index a8257a3..c4fe138 100644
--- a/board/isee/igep0020/igep0020.c
+++ b/board/isee/igep0020/igep0020.c
@@ -21,6 +21,9 @@
* MA 02111-1307 USA
*/
#include
+#ifdef CONFIG_STATUS_LED
+#include
+#endif
#include
#include
#include
@@ -55,6 +58,10 @@ int board_init(void)
/* boot param addr */
gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+ status_led_set(STATUS_LED_BOOT, STATUS_LED_ON);
+#endif
+
return 0;
}
diff --git a/board/isee/igep0030/Makefile b/board/isee/igep0030/Makefile
index cbc03d4..1ca011d 100644
--- a/board/isee/igep0030/Makefile
+++ b/board/isee/igep0030/Makefile
@@ -25,8 +25,10 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := igep0030.o
+COBJS-y := igep0030.o
+COBJS-$(CONFIG_STATUS_LED) += ../led.o
+COBJS := $(sort $(COBJS-y))
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/isee/igep0030/igep0030.c b/board/isee/igep0030/igep0030.c
index 107cb7f..60dabcd 100644
--- a/board/isee/igep0030/igep0030.c
+++ b/board/isee/igep0030/igep0030.c
@@ -21,6 +21,9 @@
* MA 02111-1307 USA
*/
#include
+#ifdef CONFIG_STATUS_LED
+#include
+#endif
#include
#include
#include
@@ -42,6 +45,10 @@ int board_init(void)
/* boot param addr */
gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+ status_led_set(STATUS_LED_BOOT, STATUS_LED_ON);
+#endif
+
return 0;
}
diff --git a/board/isee/led.c b/board/isee/led.c
new file mode 100644
index 000..023ad67
--- /dev/null
+++ b/board/isee/led.c
@@ -0,0 +1,58 @@
+/*
+ * IGEP boards GPIO LED support
+ *
+ * Author: Javier Martinez Canillas
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* GPIO pin for the LED */
+#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
+#define IGEP_GPIO_LED 27
+#else /* MACH_TYPE_IGEP0030 */
+#define IGEP_GPIO_LED 16
+#endif
+
+void __led_init(led_id_t mask, int state)
+{
+ __led_set(mask, state);
+}
+
+void __led_toggle(led_id_t mask)
+{
+ int state;
+
+ if (!gpio_request(IGEP_GPIO_LED, "")) {
+ gpio_direction_output(IGEP_GPIO_LED, 0);
+ state = gpio_get_value(IGEP_GPIO_LED);
+ gpio_set_value(IGEP_GPIO_LED, !state);
+ }
+}
+
+void __led_set(led_id_t mask, int state)
+{
+ if (!gpio_request(IGEP_GPIO_LED, "")) {
+ gpio_direction_output(IGEP_GPIO_LED, 0);
+ gpio_set_value(IGEP_GPIO_LED, state);
+ }
+}
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index be7937d..a583be2 100644
--- a/include/configs/igep00x0.h
+++ b/include/confi
Re: [U-Boot] [PATCH 1/1] OMAP3: add boot status GPIO LED for IGEP boards
On 12/23/2012 08:59 AM, Igor Grinberg wrote:
> On 12/22/12 03:49, Javier Martinez Canillas wrote:
>> This patch adds an GPIO LED boot status for IGEP boards.
>>
Hi Igor, thanks a lot for your comments
>> @@ -52,9 +55,15 @@ static const u32 gpmc_lan_config[] = {
>> int board_init(void)
>> {
>> gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
>> +/* machine type for kernel */
>> +gd->bd->bi_arch_number = MACH_TYPE_IGEP0020;
>
> Please, use CONFIG_MACH_TYPE instead.
>
> [...]
>
Yes, I was just setting this to have some state that could be used latter on
board/isee/led.c but now I realized that bi_arch_number is set in
arch/arm/lib/board.c
gd->bd->bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */
So, I'm just going to remove this assignment
>> diff --git a/board/isee/igep0030/igep0030.c b/board/isee/igep0030/igep0030.c
>> index 107cb7f..394a6cf 100644
>> --- a/board/isee/igep0030/igep0030.c
>> +++ b/board/isee/igep0030/igep0030.c
>
> [...]
>
>> @@ -39,9 +42,15 @@ DECLARE_GLOBAL_DATA_PTR;
>> int board_init(void)
>> {
>> gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
>> +/* machine type for kernel */
>> +gd->bd->bi_arch_number = MACH_TYPE_IGEP0030;
>
> same here
>
ditto
> [...]
>
>> diff --git a/board/isee/led.c b/board/isee/led.c
>> new file mode 100644
>> index 000..b7a9a02
>> --- /dev/null
>> +++ b/board/isee/led.c
>
> [...]
>
>> +
>> +/* GPIO pins for the LED */
>> +#define IGEP0020_GPIO_LED27
>> +#define IGEP0030_GPIO_LED16
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +static int __get_gpio()
>> +{
>> +if (gd->bd->bi_arch_number == MACH_TYPE_IGEP0020)
>> +return IGEP0020_GPIO_LED;
>> +else
>> +return IGEP0030_GPIO_LED;
>> +}
>
> Once you define the CONFIG_MACH_TYPE in your board config file,
> you can then just do something like:
>
> #if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
> #define IGEP_GPIO_LED 27
> #else /* MACH_TYPE_IGEP0030 */
> #define IGEP_GPIO_LED 16
> #endif
>
> remove the above function completely and just use IGEP_GPIO_LED define.
> This will also probably simplify the below code.
> What do you think?
>
Agreed, your approach is much better and simpler.
Will send a v2 with your suggestions,
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] serial/ns16550: check UART mode for TEMT value
Hi Scott, thank you for your feedback.
On 12/22/2012 03:45 AM, Scott Wood wrote:
> On 12/21/2012 03:21:46 AM, Javier Martinez Canillas wrote:
>> On ns16550, the Transmitter Empty (TEMT) Bit is used to
>> indicate when the Transmitter Holding Register (THR) and
>> the Transmitter Shift Register (TSR) are both empty.
>>
>> But ns16550 UART has two operation modes (16450 and FIFO)
>> and the TEMT bit logic value set is different on each mode.
>>
>> On 16450, the TEMT bit is set to 1 when both THR and TSR are
>> empty and is set to 0 on FIFO mode.
>
> When you say "on 16450", do you mean "in 16450 mode"?
>
Yes, that's what I meant. I'm not a native English speaker so sorry if I have
some grammatic errors in my comments.
>> So, checking the TEMT value without checking the current mode
>> and assuming a logical value of 1, can lead to U-Boot to hang
>> forever if the UART is initialized on FIFO mode by default.
>
> From the 16550 docs:
>
>Bit 6 This bit is the Transmitter Empty (TEMT) indicator Bit 6 is set
>to a logic 1 whenever the Transmitter Holding Regis- ter (THR) and
> the
>Transmitter Shift Register (TSR) are both empty It is reset to a
> logic
>0 whenever either the THR or TSR contains a data character In the
> FIFO
>mode this bit is set to one whenever the transmitter FIFO and shift
>register are both empty
>
> Maybe the 16550 implementation you're using is doing something wrong?
>
Could be, I'm using a board with an TI OMAP3 SoC which has an NS16650 UART.
Now I read again the NS16650 documentation [1] and you are right. I
misunderstood and thought that on FIFO mode the TEMT bit was set to 0 when the
both THR and TSR were empty and that this was causing U-Boot to hang.
BTW I realized that this is only an issue for SPL, if you build that check for
the non-SPL build, it works.
With this patch my board boots:
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index bbd91ca..a3ef8a5 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,8 +36,10 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
+#ifndef CONFIG_SPL_BUILD
while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
;
+#endif
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
#if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \
>> Signed-off-by: Javier Martinez Canillas
>>
>> ---
>> drivers/serial/ns16550.c |4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>> index bbd91ca..d75d814 100644
>> --- a/drivers/serial/ns16550.c
>> +++ b/drivers/serial/ns16550.c
>> @@ -36,7 +36,9 @@
>>
>> void NS16550_init(NS16550_t com_port, int baud_divisor)
>> {
>> -while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
>> +int mode = serial_in(&com_port->fcr) & UART_FCR_FIFO_EN;
>> +
>> +while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT ^ mode))
>> ;
>
> Please don't make the reader know the relative prededence of & and ^,
> and
> don't use ^ in obfuscatory ways. It's not even any different from | as
> used above -- except that | wouldn't break if TEMT and FIFO_EN had the
> same
> value -- so why do you need the exclusive form?
>
Ok, sorry. I didn't think that knowing the precedence of bitwise operator was
obfuscated and the ^ was because I misunderstood the NS16550 docs and thought
that UART_LSR_TEMT would be 0 in FIFO mode.
> BTW, when I saw the problem that necessitated this, FIFO was enabled, so
> this is no better than reverting the patch.
>
> -Scott
>
Either way works for me, I just want to boot my board :-)
But if I'm the only one having this issue maybe is just my hardware behaving
badly. I'll ask other OMAP3 users if they can boot with mainline U-Boot to
confirm this.
Best regards,
Javier
[1]:http://www.ti.com/lit/ds/symlink/pc16550d.pdf
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] OMAP3: add boot status GPIO LED for IGEP boards
This patch adds an GPIO LED boot status for IGEP boards.
The GPIO LED used is the red LED0 while the Linux kernel
uses the green LED0 as the boot status.
By using different GPIO LEDs, the user can know in which
step of the boot process the board currently is.
Signed-off-by: Javier Martinez Canillas
---
board/isee/igep0020/Makefile |4 ++-
board/isee/igep0020/igep0020.c |9 +
board/isee/igep0030/Makefile |4 ++-
board/isee/igep0030/igep0030.c |9 +
board/isee/led.c | 74
include/configs/igep00x0.h | 11 ++
6 files changed, 109 insertions(+), 2 deletions(-)
create mode 100644 board/isee/led.c
diff --git a/board/isee/igep0020/Makefile b/board/isee/igep0020/Makefile
index 00463e1..5ead151 100644
--- a/board/isee/igep0020/Makefile
+++ b/board/isee/igep0020/Makefile
@@ -25,8 +25,10 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := igep0020.o
+COBJS-y := igep0020.o
+COBJS-$(CONFIG_STATUS_LED) += ../led.o
+COBJS := $(sort $(COBJS-y))
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c
index a8257a3..7930f4e 100644
--- a/board/isee/igep0020/igep0020.c
+++ b/board/isee/igep0020/igep0020.c
@@ -21,6 +21,9 @@
* MA 02111-1307 USA
*/
#include
+#ifdef CONFIG_STATUS_LED
+#include
+#endif
#include
#include
#include
@@ -52,9 +55,15 @@ static const u32 gpmc_lan_config[] = {
int board_init(void)
{
gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
+ /* machine type for kernel */
+ gd->bd->bi_arch_number = MACH_TYPE_IGEP0020;
/* boot param addr */
gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+ status_led_set(STATUS_LED_BOOT, STATUS_LED_ON);
+#endif
+
return 0;
}
diff --git a/board/isee/igep0030/Makefile b/board/isee/igep0030/Makefile
index cbc03d4..1ca011d 100644
--- a/board/isee/igep0030/Makefile
+++ b/board/isee/igep0030/Makefile
@@ -25,8 +25,10 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := igep0030.o
+COBJS-y := igep0030.o
+COBJS-$(CONFIG_STATUS_LED) += ../led.o
+COBJS := $(sort $(COBJS-y))
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/isee/igep0030/igep0030.c b/board/isee/igep0030/igep0030.c
index 107cb7f..394a6cf 100644
--- a/board/isee/igep0030/igep0030.c
+++ b/board/isee/igep0030/igep0030.c
@@ -21,6 +21,9 @@
* MA 02111-1307 USA
*/
#include
+#ifdef CONFIG_STATUS_LED
+#include
+#endif
#include
#include
#include
@@ -39,9 +42,15 @@ DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
{
gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
+ /* machine type for kernel */
+ gd->bd->bi_arch_number = MACH_TYPE_IGEP0030;
/* boot param addr */
gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+ status_led_set(STATUS_LED_BOOT, STATUS_LED_ON);
+#endif
+
return 0;
}
diff --git a/board/isee/led.c b/board/isee/led.c
new file mode 100644
index 000..b7a9a02
--- /dev/null
+++ b/board/isee/led.c
@@ -0,0 +1,74 @@
+/*
+ * IGEP boards GPIO LED support
+ *
+ * Author: Javier Martinez Canillas
+ *
+ * Some bits borrowed from board/ti/beagle/led.c
+ *
+ * Copyright (c) 2010 Texas Instruments, Inc.
+ * Jason Kridner
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* GPIO pins for the LED */
+#define IGEP0020_GPIO_LED27
+#define IGEP0030_GPIO_LED16
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int __get_gpio()
+{
+ if (gd->bd->bi_arch_number == MACH_TYPE_IGEP0020)
+ return IGEP0020_GPIO_LED;
+ else
+ return IGEP0030_GPIO_LED;
+}
+
+void __led_init(led_id_t mask, int state)
+{
+ __led_set(mask, state);
+}
+
+void __led_toggle(led_id_t mask)
+{
+ int state, toggle_gpio = 0;
+
+ toggle_gpio = __get_gpio();
+
+ if (!gpio_request(toggle_gpio, "")) {
+ gpio_direction_output(toggle_gpio, 0);
+ state = gpi
[U-Boot] [PATCH 1/1] serial/ns16550: check UART mode for TEMT value
On ns16550, the Transmitter Empty (TEMT) Bit is used to
indicate when the Transmitter Holding Register (THR) and
the Transmitter Shift Register (TSR) are both empty.
But ns16550 UART has two operation modes (16450 and FIFO)
and the TEMT bit logic value set is different on each mode.
On 16450, the TEMT bit is set to 1 when both THR and TSR are
empty and is set to 0 on FIFO mode.
So, checking the TEMT value without checking the current mode
and assuming a logical value of 1, can lead to U-Boot to hang
forever if the UART is initialized on FIFO mode by default.
Signed-off-by: Javier Martinez Canillas
---
drivers/serial/ns16550.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index bbd91ca..d75d814 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,7 +36,9 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
- while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
+ int mode = serial_in(&com_port->fcr) & UART_FCR_FIFO_EN;
+
+ while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT ^ mode))
;
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: fix DRAM size for IGEP-based boards.
On Sun, Aug 5, 2012 at 12:55 PM, Enric Balletbo i Serra
wrote:
> The total RAM size of the IGEP-based boards is 512MiB not 1GiB, the
> LPDDR memory consist on two dies of 256MiB.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> board/isee/igep0020/igep0020.c |6 +++---
> board/isee/igep0030/igep0030.c |6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c
> index a4d099a..a8257a3 100644
> --- a/board/isee/igep0020/igep0020.c
> +++ b/board/isee/igep0020/igep0020.c
> @@ -77,19 +77,19 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla, u32
> *ctrlb, u32 *rfr_ctrl,
> {
> *mr = MICRON_V_MR_165;
> #ifdef CONFIG_BOOT_NAND
> - *mcfg = MICRON_V_MCFG_200(512 << 20);
> + *mcfg = MICRON_V_MCFG_200(256 << 20);
> *ctrla = MICRON_V_ACTIMA_200;
> *ctrlb = MICRON_V_ACTIMB_200;
> *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
> #else
> if (get_cpu_family() == CPU_OMAP34XX) {
> - *mcfg = NUMONYX_V_MCFG_165(512 << 20);
> + *mcfg = NUMONYX_V_MCFG_165(256 << 20);
> *ctrla = NUMONYX_V_ACTIMA_165;
> *ctrlb = NUMONYX_V_ACTIMB_165;
> *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
>
> } else {
> - *mcfg = NUMONYX_V_MCFG_200(512 << 20);
> + *mcfg = NUMONYX_V_MCFG_200(256 << 20);
> *ctrla = NUMONYX_V_ACTIMA_200;
> *ctrlb = NUMONYX_V_ACTIMB_200;
> *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
> diff --git a/board/isee/igep0030/igep0030.c b/board/isee/igep0030/igep0030.c
> index 4f8b645..107cb7f 100644
> --- a/board/isee/igep0030/igep0030.c
> +++ b/board/isee/igep0030/igep0030.c
> @@ -64,19 +64,19 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla, u32
> *ctrlb, u32 *rfr_ctrl,
> {
> *mr = MICRON_V_MR_165;
> #ifdef CONFIG_BOOT_NAND
> - *mcfg = MICRON_V_MCFG_200(512 << 20);
> + *mcfg = MICRON_V_MCFG_200(256 << 20);
> *ctrla = MICRON_V_ACTIMA_200;
> *ctrlb = MICRON_V_ACTIMB_200;
> *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
> #else
> if (get_cpu_family() == CPU_OMAP34XX) {
> - *mcfg = NUMONYX_V_MCFG_165(512 << 20);
> + *mcfg = NUMONYX_V_MCFG_165(256 << 20);
> *ctrla = NUMONYX_V_ACTIMA_165;
> *ctrlb = NUMONYX_V_ACTIMB_165;
> *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
>
> } else {
> - *mcfg = NUMONYX_V_MCFG_200(512 << 20);
> + *mcfg = NUMONYX_V_MCFG_200(256 << 20);
> *ctrla = NUMONYX_V_ACTIMA_200;
> *ctrlb = NUMONYX_V_ACTIMB_200;
> *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
> --
> 1.7.9.5
>
Hi Enric,
I missed that on the original patch, thanks for fixing it.
Tested-by: Javier Martinez Canillas
Best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-arm/next RESEND PATCH 0/3] OMAP3: igep00x0: add nand flash and SPL support
On Mon, Jul 30, 2012 at 7:06 PM, Tom Rini wrote: > On Sat, Jul 28, 2012 at 01:19:31PM +0200, Javier Martinez Canillas wrote: > >> IGEP-based boards can have two different flash memories, a OneNAND or a >> NAND device. >> >> Since u-boot still lacks of a device model to be the able to look at >> run-time which memory type is available on a the board, a built time >> config option is needed to choose which memory to use. >> >> This is a resend of a patch-set that adds both a config option for the >> nand memory type and SPL support to IGEP-based boards. >> >> The patch-set is composed of the following patches: >> >> [u-boot-arm/next RESEND PATCH 1/3] OMAP3: igep00x0: Add config >> [u-boot-arm/next RESEND PATCH 2/3] OMAP3: mem: Add Numonyx OneNAND >> [u-boot-arm/next RESEND PATCH 3/3] OMAP3: igep00x0: add SPL support > > This all looks good, barring comments from someone else, I'll pick this > up Friday or so. > > -- > Tom Perfect, thanks a lot Tom! Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot-arm/next RESEND PATCH 2/3] OMAP3: mem: Add Numonyx OneNAND 200MHz timing information
Signed-off-by: Javier Martinez Canillas
---
arch/arm/include/asm/arch-omap3/mem.h | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap3/mem.h
b/arch/arm/include/asm/arch-omap3/mem.h
index 9f6992a..12dcf4e 100644
--- a/arch/arm/include/asm/arch-omap3/mem.h
+++ b/arch/arm/include/asm/arch-omap3/mem.h
@@ -294,6 +294,35 @@ enum {
#define NUMONYX_RASWIDTH_165 15
#define NUMONYX_V_MCFG_165(size) MCFG((size), NUMONYX_RASWIDTH_165)
+/* NUMONYX part of IGEP v2 (200MHz optimized) 5 ns */
+#define NUMONYX_TDAL_200 6 /* Twr/Tck + Trp/tck*/
+ /* 15/5 + 15/5 = 3 + 3 -> 6 */
+#define NUMONYX_TDPL_200 3 /* 15/5 = 3 -> 3 (Twr) */
+#define NUMONYX_TRRD_200 2 /* 10/5 = 2 */
+#define NUMONYX_TRCD_200 4 /* 16.2/5 = 3.24 -> 4 */
+#define NUMONYX_TRP_2003 /* 15/5 = 3
*/
+#define NUMONYX_TRAS_200 8 /* 40/5 = 8 */
+#define NUMONYX_TRC_20011 /* 55/5 = 11
*/
+#define NUMONYX_TRFC_20028 /* 140/5 = 28 */
+
+#define NUMONYX_V_ACTIMA_200 \
+ ACTIM_CTRLA(NUMONYX_TRFC_200, NUMONYX_TRC_200, \
+ NUMONYX_TRAS_200, NUMONYX_TRP_200, \
+ NUMONYX_TRCD_200, NUMONYX_TRRD_200, \
+ NUMONYX_TDPL_200, NUMONYX_TDAL_200)
+
+#define NUMONYX_TWTR_200 2
+#define NUMONYX_TCKE_200 2
+#define NUMONYX_TXP_2003
+#define NUMONYX_XSR_20040
+
+#define NUMONYX_V_ACTIMB_200 \
+ ACTIM_CTRLB(NUMONYX_TWTR_200, NUMONYX_TCKE_200, \
+ NUMONYX_TXP_200, NUMONYX_XSR_200)
+
+#define NUMONYX_RASWIDTH_200 15
+#define NUMONYX_V_MCFG_200(size) MCFG((size), NUMONYX_RASWIDTH_200)
+
/*
* GPMC settings -
* Definitions is as per the following format
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot-arm/next RESEND PATCH 3/3] OMAP3: igep00x0: add SPL support for IGEP-based boards
This patch adds SPL support for IGEP-based boards.
Tested on an IGEPv2 Rev.C board with Micron NAND Flash memory.
Signed-off-by: Javier Martinez Canillas
---
board/isee/igep0020/config.mk | 33
board/isee/igep0020/igep0020.c | 42 +-
board/isee/igep0030/config.mk | 33
board/isee/igep0030/igep0030.c | 42 +-
include/configs/igep00x0.h | 65
5 files changed, 147 insertions(+), 68 deletions(-)
delete mode 100644 board/isee/igep0020/config.mk
delete mode 100644 board/isee/igep0030/config.mk
diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk
deleted file mode 100644
index 7964621..000
--- a/board/isee/igep0020/config.mk
+++ /dev/null
@@ -1,33 +0,0 @@
-#
-# (C) Copyright 2009
-# ISEE 2007 SL,
-#
-# IGEP0020 uses OMAP3 (ARM-CortexA8) cpu
-# see http://www.ti.com/ for more information on Texas Instruments
-#
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-# MA 02111-1307 USA
-#
-# Physical Address:
-# 8000' (bank0)
-# A000/ (bank1)
-# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
-# (mem base + reserved)
-
-# For use with external or internal boots.
-CONFIG_SYS_TEXT_BASE = 0x80008000
diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c
index 971e31b..a4d099a 100644
--- a/board/isee/igep0020/igep0020.c
+++ b/board/isee/igep0020/igep0020.c
@@ -58,6 +58,46 @@ int board_init(void)
return 0;
}
+#ifdef CONFIG_SPL_BUILD
+/*
+ * Routine: omap_rev_string
+ * Description: For SPL builds output board rev
+ */
+void omap_rev_string(void)
+{
+}
+
+/*
+ * Routine: get_board_mem_timings
+ * Description: If we use SPL then there is no x-loader nor config header
+ * so we have to setup the DDR timings ourself on both banks.
+ */
+void get_board_mem_timings(u32 *mcfg, u32 *ctrla, u32 *ctrlb, u32 *rfr_ctrl,
+ u32 *mr)
+{
+ *mr = MICRON_V_MR_165;
+#ifdef CONFIG_BOOT_NAND
+ *mcfg = MICRON_V_MCFG_200(512 << 20);
+ *ctrla = MICRON_V_ACTIMA_200;
+ *ctrlb = MICRON_V_ACTIMB_200;
+ *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
+#else
+ if (get_cpu_family() == CPU_OMAP34XX) {
+ *mcfg = NUMONYX_V_MCFG_165(512 << 20);
+ *ctrla = NUMONYX_V_ACTIMA_165;
+ *ctrlb = NUMONYX_V_ACTIMB_165;
+ *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
+
+ } else {
+ *mcfg = NUMONYX_V_MCFG_200(512 << 20);
+ *ctrla = NUMONYX_V_ACTIMA_200;
+ *ctrlb = NUMONYX_V_ACTIMB_200;
+ *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
+ }
+#endif
+}
+#endif
+
/*
* Routine: setup_net_chip
* Description: Setting up the configuration GPMC registers specific to the
@@ -91,7 +131,7 @@ static void setup_net_chip(void)
}
#endif
-#ifdef CONFIG_GENERIC_MMC
+#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
int board_mmc_init(bd_t *bis)
{
omap_mmc_init(0, 0, 0);
diff --git a/board/isee/igep0030/config.mk b/board/isee/igep0030/config.mk
deleted file mode 100644
index 059a878..000
--- a/board/isee/igep0030/config.mk
+++ /dev/null
@@ -1,33 +0,0 @@
-#
-# (C) Copyright 2009
-# ISEE 2007 SL,
-#
-# IGEP0030 uses OMAP3 (ARM-CortexA8) cpu
-# see http://www.ti.com/ for more information on Texas Instruments
-#
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-# MA 02111-1307 USA
-#
-# Physical Address:
-# 8000&#
[U-Boot] [u-boot-arm/next RESEND PATCH 1/3] OMAP3: igep00x0: Add config option to choose flash storage memory
IGEP-based boards can have two different flash memories, a OneNAND or a
NAND device. Add a configuration option for to choose which memory to use.
Signed-off-by: Javier Martinez Canillas
Acked-by: Enric Balletbo i Serra
---
board/isee/igep0020/igep0020.h |4
board/isee/igep0030/igep0030.h |4
boards.cfg |6 --
include/configs/igep00x0.h | 19 +++
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/board/isee/igep0020/igep0020.h b/board/isee/igep0020/igep0020.h
index 3d6e15f..3335ecc 100644
--- a/board/isee/igep0020/igep0020.h
+++ b/board/isee/igep0020/igep0020.h
@@ -26,7 +26,11 @@
const omap3_sysinfo sysinfo = {
DDR_STACKED,
"IGEP v2 board",
+#if defined(CONFIG_ENV_IS_IN_ONENAND)
"ONENAND",
+#else
+ "NAND",
+#endif
};
static void setup_net_chip(void);
diff --git a/board/isee/igep0030/igep0030.h b/board/isee/igep0030/igep0030.h
index b7ce5aa..a93339d 100644
--- a/board/isee/igep0030/igep0030.h
+++ b/board/isee/igep0030/igep0030.h
@@ -26,7 +26,11 @@
const omap3_sysinfo sysinfo = {
DDR_STACKED,
"OMAP3 IGEP module",
+#if defined(CONFIG_ENV_IS_IN_ONENAND)
"ONENAND",
+#else
+ "NAND",
+#endif
};
/*
diff --git a/boards.cfg b/boards.cfg
index 9efdc6d..7463896 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -224,8 +224,10 @@ cm_t35 arm armv7
cm_t35 -
omap3_overo arm armv7 overo -
omap3
omap3_pandoraarm armv7 pandora -
omap3
dig297 arm armv7 dig297
comelitomap3
-igep0020 arm armv7 igep0020isee
omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020
-igep0030 arm armv7 igep0030isee
omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030
+igep0020 arm armv7 igep0020isee
omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
+igep0020_nandarm armv7 igep0020isee
omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND
+igep0030 arm armv7 igep0030isee
omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
+igep0030_nandarm armv7 igep0030isee
omap3 igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND
am3517_evm arm armv7 am3517evm
logicpdomap3
mt_ventoux arm armv7 mt_ventoux
teejet omap3
omap3_zoom1 arm armv7 zoom1
logicpdomap3
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index a0a23a7..d8e87c3 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -105,7 +105,12 @@
#define CONFIG_CMD_FAT /* FAT support */
#define CONFIG_CMD_I2C /* I2C serial bus support */
#define CONFIG_CMD_MMC /* MMC support */
+#ifdef CONFIG_BOOT_ONENAND
#define CONFIG_CMD_ONENAND /* ONENAND support */
+#endif
+#ifdef CONFIG_BOOT_NAND
+#define CONFIG_CMD_NAND
+#endif
#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_PING
@@ -244,6 +249,7 @@
* FLASH and environment organization
*/
+#ifdef CONFIG_BOOT_ONENAND
#define PISMO1_ONEN_SIZE GPMC_SIZE_128M /* Configure the PISMO */
#define CONFIG_SYS_ONENAND_BASEONENAND_MAP
@@ -253,6 +259,19 @@
#define CONFIG_ENV_IS_IN_ONENAND 1
#define CONFIG_ENV_SIZE(512 << 10) /* Total Size
Environment */
#define CONFIG_ENV_ADDRONENAND_ENV_OFFSET
+#endif
+
+#ifdef CONFIG_BOOT_NAND
+#define PISMO1_NAND_SIZE GPMC_SIZE_128M /* Configure the PISMO */
+#define CONFIG_NAND_OMAP_GPMC
+#define CONFIG_SYS_NAND_BASE NAND_BASE
+#define GPMC_NAND_ECC_LP_x16_LAYOUT1
+#define CONFIG_ENV_OFFSET 0x26 /* environment starts here */
+#define CONFIG_ENV_IS_IN_NAND 1
+#define CONFIG_ENV_SIZE(512 << 10) /* Total Size
Environment */
+#define CONFIG_ENV_ADDRNAND_ENV_OFFSET
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#endif
/*
* Size of malloc() pool
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
