[U-Boot] add more function in hello_world.c for standalone application
hi, Wolfgang:
I've tried the examples/standalone/hello_world.c, it
works on my platform!
but when i add more functions in
examples/standalone/hello_world.c, for example
it will take the test function as the entry, but ignore
the hello_world ? can i have more than one functions in a standalone
application C source code ? thanks
and what's more, can we use IRQ on arm platform for
standalone application that is already supported by u-boot?
diff --git a/examples/standalone/hello_world.c
b/examples/standalone/hello_world.c
index 067c390..226ddef 100644
--- a/examples/standalone/hello_world.c
+++ b/examples/standalone/hello_world.c
@@ -24,6 +24,11 @@
#include
#include
+void test(int i)
+{
+ printf(" this is a test %d \n", i);
+}
+
int hello_world (int argc, char * const argv[])
{
int i;
here is the log:
U-Boot 2011.12-00889-g7a0eac3-dirty (Aug 02 2012 - 22:36:53)
DRAM: 64 MiB
WARNING: Caches not enabled
NAND: 256 MiB
MMC: SDHCI: 0
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
[test] loadb 0x8100
## Ready for binary (kermit) download to 0x8100 at 115200 bps...
## Total Size = 0x027f = 639 Bytes
## Start Addr = 0x8100
[test] go 0x8100
## Starting application at 0x8100 ...
this is a test 1
## Application terminated, rc = 0x13
--
Best regards
Kassey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
Dear Mike Frysinger, > On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote: > > --- /dev/null > > +++ b/common/cmd_dfu.c > > > > + static char *s = "dfu"; > > no need for this to be static It can be pulled out of the function and be made into const static > -mike Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7 V4] EXYNOS5: Enable SPI support
This patch set adds SPI driver for EXYNOS5 and enables same.
This patch set is based on latest Mainline u-boot.git tree.
Changes in V2:
- Correted the Commit message.
Changes in V3:
- Removed SPI_SLAVE Flag.
- Corrected warning messages.
Changes on V4:
- Rebased on mainline u-boot.git
- Incorporated review comments for SPI driver.
Rajeshwari Shinde (7):
EXYNOS5: Add pinmux support for SPI
SPI: Add W25Q32 to Winbond SPI flash table
EXYNOS: Add clock for SPI.
EXYNOS5: Add base address for SPI.
SPI: Add SPI Driver for EXYNOS.
EXYNOS5: Enable SPI
EXYNOS5: Enable SPI booting.
arch/arm/cpu/armv7/exynos/clock.c | 124 +++
arch/arm/cpu/armv7/exynos/pinmux.c| 51 +++-
arch/arm/include/asm/arch-exynos/clk.h|4 +-
arch/arm/include/asm/arch-exynos/cpu.h|6 +
arch/arm/include/asm/arch-exynos/periph.h |5 +
arch/arm/include/asm/arch-exynos/spi.h| 78 +
board/samsung/smdk5250/Makefile |2 +-
board/samsung/smdk5250/smdk5250.c |4 +
board/samsung/smdk5250/{mmc_boot.c => spl_boot.c} | 31 ++-
drivers/mtd/spi/winbond.c |8 +
drivers/spi/Makefile |1 +
drivers/spi/exynos_spi.c | 364 +
include/configs/smdk5250.h| 28 ++-
13 files changed, 700 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/include/asm/arch-exynos/spi.h
rename board/samsung/smdk5250/{mmc_boot.c => spl_boot.c} (66%)
create mode 100644 drivers/spi/exynos_spi.c
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7 V4] EXYNOS5: Add pinmux support for SPI
This patch adds pinmux support for SPI channels
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None.
Changes in V3:
- Removed the slave flag for SPI.
Changes in V4:
- Rebased on Mainline u-boot.git.
arch/arm/cpu/armv7/exynos/pinmux.c| 51 -
arch/arm/include/asm/arch-exynos/periph.h |5 +++
2 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index d28f055..415d7fa 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -226,6 +226,49 @@ static void exynos5_i2c_config(int peripheral, int flags)
}
}
+void exynos5_spi_config(int peripheral)
+{
+ int cfg = 0, pin = 0, i;
+ struct s5p_gpio_bank *bank = NULL;
+ struct exynos5_gpio_part1 *gpio1 =
+ (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
+ struct exynos5_gpio_part2 *gpio2 =
+ (struct exynos5_gpio_part2 *) samsung_get_base_gpio_part2();
+
+ switch (peripheral) {
+ case PERIPH_ID_SPI0:
+ bank = &gpio1->a2;
+ cfg = GPIO_FUNC(0x2);
+ pin = 0;
+ break;
+ case PERIPH_ID_SPI1:
+ bank = &gpio1->a2;
+ cfg = GPIO_FUNC(0x2);
+ pin = 4;
+ break;
+ case PERIPH_ID_SPI2:
+ bank = &gpio1->b1;
+ cfg = GPIO_FUNC(0x5);
+ pin = 1;
+ break;
+ case PERIPH_ID_SPI3:
+ bank = &gpio2->f1;
+ cfg = GPIO_FUNC(0x2);
+ pin = 0;
+ break;
+ case PERIPH_ID_SPI4:
+ for (i = 2; i < 4; i++)
+ s5p_gpio_cfg_pin(&gpio2->f0, i, GPIO_FUNC(0x4));
+ for (i = 4; i < 6; i++)
+ s5p_gpio_cfg_pin(&gpio2->e0, i, GPIO_FUNC(0x4));
+ break;
+ }
+ if (peripheral != PERIPH_ID_SPI4) {
+ for (i = pin; i < pin + 4; i++)
+ s5p_gpio_cfg_pin(bank, i, cfg);
+ }
+}
+
static int exynos5_pinmux_config(int peripheral, int flags)
{
switch (peripheral) {
@@ -253,11 +296,17 @@ static int exynos5_pinmux_config(int peripheral, int
flags)
case PERIPH_ID_I2C7:
exynos5_i2c_config(peripheral, flags);
break;
+ case PERIPH_ID_SPI0:
+ case PERIPH_ID_SPI1:
+ case PERIPH_ID_SPI2:
+ case PERIPH_ID_SPI3:
+ case PERIPH_ID_SPI4:
+ exynos5_spi_config(peripheral);
+ break;
default:
debug("%s: invalid peripheral %d", __func__, peripheral);
return -1;
}
-
return 0;
}
diff --git a/arch/arm/include/asm/arch-exynos/periph.h
b/arch/arm/include/asm/arch-exynos/periph.h
index b861d7d..dafc3f3 100644
--- a/arch/arm/include/asm/arch-exynos/periph.h
+++ b/arch/arm/include/asm/arch-exynos/periph.h
@@ -43,6 +43,11 @@ enum periph_id {
PERIPH_ID_SDMMC2,
PERIPH_ID_SDMMC3,
PERIPH_ID_SROMC,
+ PERIPH_ID_SPI0,
+ PERIPH_ID_SPI1,
+ PERIPH_ID_SPI2,
+ PERIPH_ID_SPI3,
+ PERIPH_ID_SPI4,
PERIPH_ID_UART0,
PERIPH_ID_UART1,
PERIPH_ID_UART2,
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7 V4] SPI: Add W25Q32 to Winbond SPI flash table
SMDK EVT1 has a different Winbond part, added its part details
to the SPI flash table
Signed-off-by: Abhilash Kesavan
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- Corrected the commit message.
Changes in V3:
- None.
Changes in V4:
- Rebased on Mainline u-boot.git.
drivers/mtd/spi/winbond.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 427b71f..ae4e48a 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -62,6 +62,14 @@ static const struct winbond_spi_flash_params
winbond_spi_flash_table[] = {
.nr_blocks = 256,
.name = "W25Q128",
},
+ {
+ .id = 0x5014,
+ .l2_page_size = 8,
+ .pages_per_sector = 16,
+ .sectors_per_block = 16,
+ .nr_blocks = 128,
+ .name = "W25Q80",
+ },
};
struct spi_flash *spi_flash_probe_winbond(struct spi_slave *spi, u8 *idcode)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7 V4] EXYNOS: Add clock for SPI.
This patch adds api to calculate and set the clock for SPI channels
Signed-off-by: Simon Glass
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None
Changes in V3:
- Corrected Warning messages.
Changes in V4:
- Rebased on Mainline u-boot.git.
arch/arm/cpu/armv7/exynos/clock.c | 124
arch/arm/include/asm/arch-exynos/clk.h |4 +-
2 files changed, 127 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index f7829b2..9b015a6 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -601,6 +601,122 @@ static unsigned long exynos5_get_i2c_clk(void)
return aclk_66;
}
+/**
+ * Linearly searches for the most accurate main and fine stage clock scalars
+ * (divisors) for a specified target frequency and scalar bit sizes by checking
+ * all multiples of main_scalar_bits values. Will always return scalars up to
or
+ * slower than target.
+ *
+ * @param main_scalar_bits Number of main scalar bits, must be > 0 and < 32
+ * @param fine_scalar_bits Number of fine scalar bits, must be > 0 and < 32
+ * @param input_freq Clock frequency to be scaled in Hz
+ * @param target_freq Desired clock frequency in Hz
+ * @param best_fine_scalar Pointer to store the fine stage divisor
+ *
+ * @return best_main_scalarMain scalar for desired frequency or -1 if none
+ * found
+ */
+static int clock_calc_best_scalar(unsigned int main_scaler_bits,
+ unsigned int fine_scalar_bits, unsigned int input_rate,
+ unsigned int target_rate, unsigned int *best_fine_scalar)
+{
+ int i;
+ int best_main_scalar = -1;
+ unsigned int best_error = target_rate;
+ const unsigned int cap = (1 << fine_scalar_bits) - 1;
+ const unsigned int loops = 1 << main_scaler_bits;
+
+ debug("Input Rate is %u, Target is %u, Cap is %u\n", input_rate,
+ target_rate, cap);
+
+ assert(best_fine_scalar != NULL);
+ assert(main_scaler_bits <= fine_scalar_bits);
+
+ *best_fine_scalar = 1;
+
+ if (input_rate == 0 || target_rate == 0)
+ return -1;
+
+ if (target_rate >= input_rate)
+ return 1;
+
+ for (i = 1; i <= loops; i++) {
+ const unsigned int effective_div = max(min(input_rate / i /
+ target_rate, cap), 1);
+ const unsigned int effective_rate = input_rate / i /
+ effective_div;
+ const int error = target_rate - effective_rate;
+
+ debug("%d|effdiv:%u, effrate:%u, error:%d\n", i, effective_div,
+ effective_rate, error);
+
+ if (error >= 0 && error <= best_error) {
+ best_error = error;
+ best_main_scalar = i;
+ *best_fine_scalar = effective_div;
+ }
+ }
+
+ return best_main_scalar;
+}
+
+static int exynos5_spi_set_clock_rate(enum periph_id periph_id,
+ unsigned int rate)
+{
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+ int main;
+ unsigned int fine;
+ unsigned shift, pre_shift;
+ unsigned mask = 0xff;
+ u32 *reg;
+
+ main = clock_calc_best_scalar(4, 8, 4, rate, &fine);
+ if (main < 0) {
+ debug("%s: Cannot set clock rate for periph %d",
+ __func__, periph_id);
+ return -1;
+ }
+ main = main - 1;
+ fine = fine - 1;
+
+ switch (periph_id) {
+ case PERIPH_ID_SPI0:
+ reg = &clk->div_peric1;
+ shift = 0;
+ pre_shift = 8;
+ break;
+ case PERIPH_ID_SPI1:
+ reg = &clk->div_peric1;
+ shift = 16;
+ pre_shift = 24;
+ break;
+ case PERIPH_ID_SPI2:
+ reg = &clk->div_peric2;
+ shift = 0;
+ pre_shift = 8;
+ break;
+ case PERIPH_ID_SPI3:
+ reg = &clk->sclk_div_isp;
+ shift = 0;
+ pre_shift = 4;
+ break;
+ case PERIPH_ID_SPI4:
+ reg = &clk->sclk_div_isp;
+ shift = 12;
+ pre_shift = 16;
+ break;
+ default:
+ debug("%s: Unsupported peripheral ID %d\n", __func__,
+ periph_id);
+ return -1;
+ }
+ clrsetbits_le32(reg, mask << shift, (main & mask) << shift);
+ clrsetbits_le32(reg, mask << pre_shift, (fine & mask) << pre_shift);
+
+ return 0;
+}
+
unsigned long get_pll_clk(int pllreg)
{
if (cpu_is_exynos5())
@@ -670,3 +786,11 @@ void set_mipi_clk(v
[U-Boot] [PATCH 6/7 V4] EXYNOS5: Enable SPI
This patch enables SPI driver for EXYNOS5.
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None.
Changes in V3:
- Corrected the warning message.
Changes in V4:
- Rebased on Mainline u-boot.git.
board/samsung/smdk5250/smdk5250.c |4
include/configs/smdk5250.h| 23 ++-
2 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index fae7d6f..7e20a3c 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -63,6 +64,9 @@ static int smc9115_pre_init(void)
int board_init(void)
{
gd->bd->bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
+#ifdef CONFIG_EXYNOS_SPI
+ spi_init();
+#endif
return 0;
}
diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
index eb1466c..0f85be6 100644
--- a/include/configs/smdk5250.h
+++ b/include/configs/smdk5250.h
@@ -162,7 +162,7 @@
#undef CONFIG_CMD_IMLS
#define CONFIG_IDENT_STRING" for SMDK5250"
-#define CONFIG_ENV_IS_IN_MMC
+/*#define CONFIG_ENV_IS_IN_MMC*/
#define CONFIG_SYS_MMC_ENV_DEV 0
#define CONFIG_SECURE_BL1_ONLY
@@ -211,6 +211,27 @@
#define CONFIG_ENV_SROM_BANK 1
#endif /*CONFIG_CMD_NET*/
+/* SPI */
+#define CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_SPI_FLASH
+
+#ifdef CONFIG_SPI_FLASH
+#define CONFIG_EXYNOS_SPI
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SPI
+#define CONFIG_SPI_FLASH_WINBOND
+#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
+#define CONFIG_SF_DEFAULT_SPEED5000
+#define EXYNOS5_SPI_NUM_CONTROLLERS5
+#endif
+
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_ENV_SPI_MODESPI_MODE_0
+#define CONFIG_ENV_SECT_SIZE CONFIG_ENV_SIZE
+#define CONFIG_ENV_SPI_BUS 1
+#define CONFIG_ENV_SPI_MAX_HZ 5000
+#endif
+
/* Enable devicetree support */
#define CONFIG_OF_LIBFDT
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7 V4] SPI: Add SPI Driver for EXYNOS.
This patch adds SPI driver for EXYNOS.
Signed-off-by: Simon Glass
Signed-off-by: Padmavathi Venna
Signed-off-by: Gabe Black
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None.
Changes in V3:
- Removed SPI_SLAVE flag.
Changes in V4:
- Rebased on Mainline u-boot.git.
- Removed variable bus_count and DECLARE_GLOBAL_DATA_PTR;
- Function spi_flush_fifo made static.
arch/arm/include/asm/arch-exynos/spi.h | 78 +++
drivers/spi/Makefile |1 +
drivers/spi/exynos_spi.c | 364
3 files changed, 443 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-exynos/spi.h
create mode 100644 drivers/spi/exynos_spi.c
diff --git a/arch/arm/include/asm/arch-exynos/spi.h
b/arch/arm/include/asm/arch-exynos/spi.h
new file mode 100644
index 000..7cab1e9
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/spi.h
@@ -0,0 +1,78 @@
+/*
+ * (C) Copyright 2012 SAMSUNG Electronics
+ * Padmavathi Venna
+ *
+ * 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
+ */
+
+#ifndef __ASM_ARCH_EXYNOS_COMMON_SPI_H_
+#define __ASM_ARCH_EXYNOS_COMMON_SPI_H_
+
+#ifndef __ASSEMBLY__
+
+/* SPI peripheral register map; padded to 64KB */
+struct exynos_spi {
+ unsigned intch_cfg; /* 0x00 */
+ unsigned char reserved0[4];
+ unsigned intmode_cfg; /* 0x08 */
+ unsigned intcs_reg; /* 0x0c */
+ unsigned char reserved1[4];
+ unsigned intspi_sts;/* 0x14 */
+ unsigned inttx_data;/* 0x18 */
+ unsigned intrx_data;/* 0x1c */
+ unsigned intpkt_cnt;/* 0x20 */
+ unsigned char reserved2[4];
+ unsigned char reserved3[4];
+ unsigned intfb_clk; /* 0x2c */
+ unsigned char padding[0xffd0];
+};
+
+#define EXYNOS_SPI_MAX_FREQ5000
+
+#define SPI_TIMEOUT_MS 10
+
+/* SPI_CHCFG */
+#define SPI_CH_HS_EN (1 << 6)
+#define SPI_CH_RST (1 << 5)
+#define SPI_SLAVE_MODE (1 << 4)
+#define SPI_CH_CPOL_L (1 << 3)
+#define SPI_CH_CPHA_B (1 << 2)
+#define SPI_RX_CH_ON (1 << 1)
+#define SPI_TX_CH_ON (1 << 0)
+
+/* SPI_MODECFG */
+#define SPI_MODE_CH_WIDTH_WORD (0x2 << 29)
+#define SPI_MODE_BUS_WIDTH_WORD(0x2 << 17)
+
+/* SPI_CSREG */
+#define SPI_SLAVE_SIG_INACT(1 << 0)
+
+/* SPI_STS */
+#define SPI_ST_TX_DONE (1 << 25)
+#define SPI_FIFO_LVL_MASK 0x1ff
+#define SPI_TX_LVL_OFFSET 6
+#define SPI_RX_LVL_OFFSET 15
+
+/* Feedback Delay */
+#define SPI_CLK_BYPASS (0 << 0)
+#define SPI_FB_DELAY_90(1 << 0)
+#define SPI_FB_DELAY_180 (2 << 0)
+#define SPI_FB_DELAY_270 (3 << 0)
+
+/* Packet Count */
+#define SPI_PACKET_CNT_EN (1 << 16)
+
+#endif /* __ASSEMBLY__ */
+#endif
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index cd3f9fa..4d02a18 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_ATMEL_SPI) += atmel_spi.o
COBJS-$(CONFIG_BFIN_SPI) += bfin_spi.o
COBJS-$(CONFIG_CF_SPI) += cf_spi.o
COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
+COBJS-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
COBJS-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
new file mode 100644
index 000..e4d41eb
--- /dev/null
+++ b/drivers/spi/exynos_spi.c
@@ -0,0 +1,364 @@
+/*
+ * (C) Copyright 2012 SAMSUNG Electronics
+ * Padmavathi Venna
+ *
+ * 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
[U-Boot] [PATCH 4/7 V4] EXYNOS5: Add base address for SPI.
Signed-off-by: Rajeshwari Shinde --- Changes in V2: - None Changes in V3: - None. Changes in V4: - Rebased on Mainline u-boot.git. arch/arm/include/asm/arch-exynos/cpu.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-exynos/cpu.h b/arch/arm/include/asm/arch-exynos/cpu.h index 0e6ea87..89c2dd3 100644 --- a/arch/arm/include/asm/arch-exynos/cpu.h +++ b/arch/arm/include/asm/arch-exynos/cpu.h @@ -51,11 +51,13 @@ #define EXYNOS4_UART_BASE 0x1380 #define EXYNOS4_I2C_BASE 0x1386 #define EXYNOS4_ADC_BASE 0x1391 +#define EXYNOS4_SPI_BASE 0x1392 #define EXYNOS4_PWMTIMER_BASE 0x139D #define EXYNOS4_MODEM_BASE 0x13A0 #define EXYNOS4_USBPHY_CONTROL 0x10020704 #define EXYNOS4_GPIO_PART4_BASEDEVICE_NOT_AVAILABLE +#define EXYNOS4_SPI_ISP_BASE DEVICE_NOT_AVAILABLE /* EXYNOS5 */ #define EXYNOS5_I2C_SPACING0x1 @@ -80,7 +82,9 @@ #define EXYNOS5_SROMC_BASE 0x1225 #define EXYNOS5_UART_BASE 0x12C0 #define EXYNOS5_I2C_BASE 0x12C6 +#define EXYNOS5_SPI_BASE 0x12D2 #define EXYNOS5_PWMTIMER_BASE 0x12DD +#define EXYNOS5_SPI_ISP_BASE 0x131A #define EXYNOS5_GPIO_PART2_BASE0x1340 #define EXYNOS5_FIMD_BASE 0x1440 @@ -170,6 +174,8 @@ SAMSUNG_BASE(usb_ehci, USB_HOST_EHCI_BASE) SAMSUNG_BASE(usb_otg, USBOTG_BASE) SAMSUNG_BASE(watchdog, WATCHDOG_BASE) SAMSUNG_BASE(power, POWER_BASE) +SAMSUNG_BASE(spi, SPI_BASE) +SAMSUNG_BASE(spi_isp, SPI_ISP_BASE) #endif #endif /* _EXYNOS4_CPU_H */ -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] EXYNOS5: Enable SPI booting.
This patch enables SPI Booting for EXYNOS5
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None.
Changes in V3:
- None.
Changes in V4:
- Rebased on Mainline u-boot.git.
- Corrected the Commit message.
board/samsung/smdk5250/Makefile |2 +-
board/samsung/smdk5250/{mmc_boot.c => spl_boot.c} | 31 +++-
include/configs/smdk5250.h|5 +++
3 files changed, 35 insertions(+), 3 deletions(-)
rename board/samsung/smdk5250/{mmc_boot.c => spl_boot.c} (66%)
diff --git a/board/samsung/smdk5250/Makefile b/board/samsung/smdk5250/Makefile
index 226db1f..9cfde0f 100644
--- a/board/samsung/smdk5250/Makefile
+++ b/board/samsung/smdk5250/Makefile
@@ -35,7 +35,7 @@ COBJS += smdk5250.o
endif
ifdef CONFIG_SPL_BUILD
-COBJS += mmc_boot.o
+COBJS += spl_boot.o
endif
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/board/samsung/smdk5250/mmc_boot.c
b/board/samsung/smdk5250/spl_boot.c
similarity index 66%
rename from board/samsung/smdk5250/mmc_boot.c
rename to board/samsung/smdk5250/spl_boot.c
index 449a919..d8f3c1e 100644
--- a/board/samsung/smdk5250/mmc_boot.c
+++ b/board/samsung/smdk5250/spl_boot.c
@@ -23,6 +23,16 @@
#include
#include
+enum boot_mode {
+ BOOT_MODE_MMC = 4,
+ BOOT_MODE_SERIAL = 20,
+ /* Boot based on Operating Mode pin settings */
+ BOOT_MODE_OM = 32,
+ BOOT_MODE_USB, /* Boot using USB download */
+};
+
+ typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
+
/*
* Copy U-boot from mmc to RAM:
* COPY_BL2_FNPTR_ADDR: Address in iRAM, which Contains
@@ -30,9 +40,26 @@
*/
void copy_uboot_to_ram(void)
{
- u32 (*copy_bl2)(u32, u32, u32) = (void *) *(u32 *)COPY_BL2_FNPTR_ADDR;
+ spi_copy_func_t spi_copy;
+ enum boot_mode bootmode;
+ u32 (*copy_bl2)(u32, u32, u32);
+
+ bootmode = readl(EXYNOS5_POWER_BASE) & OM_STAT;
- copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT, CONFIG_SYS_TEXT_BASE);
+ switch (bootmode) {
+ case BOOT_MODE_SERIAL:
+ spi_copy = *(spi_copy_func_t *)EXYNOS_COPY_SPI_FNPTR_ADDR;
+ spi_copy(SPI_FLASH_UBOOT_POS, CONFIG_BL2_SIZE,
+ CONFIG_SYS_TEXT_BASE);
+ break;
+ case BOOT_MODE_MMC:
+ copy_bl2 = (void *) *(u32 *)COPY_BL2_FNPTR_ADDR;
+ copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
+ CONFIG_SYS_TEXT_BASE);
+ break;
+ default:
+ break;
+ }
}
void board_init_f(unsigned long bootflag)
diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
index 0f85be6..a926a7e 100644
--- a/include/configs/smdk5250.h
+++ b/include/configs/smdk5250.h
@@ -187,6 +187,11 @@
/* U-boot copy size from boot Media to DRAM.*/
#define BL2_START_OFFSET (CONFIG_BL2_OFFSET/512)
#define BL2_SIZE_BLOC_COUNT(CONFIG_BL2_SIZE/512)
+
+#define OM_STAT(0x1f << 1)
+#define EXYNOS_COPY_SPI_FNPTR_ADDR 0x02020058
+#define SPI_FLASH_UBOOT_POS(CONFIG_SEC_FW_SIZE + CONFIG_BL1_SIZE)
+
#define CONFIG_DOS_PARTITION
#define CONFIG_IRAM_STACK 0x0205
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6q: mx6qsabrelite: add GPIO_0__CCM_CLKO and GPIO_3__CCM_CLKO2 pin mux
On 01.08.2012 13:05, Dirk Behme wrote: A recent Linux kernel (>= 3.5) has support for the SGTL 5000 sound on the SabreLite board. To make this work, U-Boot has to configure the pin mux for PAD_GPIO_0__CCM_CLKO and PAD_GPIO_3__CCM_CLKO2 correctly. Taken from Freescale's ER5 U-Boot for the SabreLite. Signed-off-by: Dirk Behme CC: Troy Kisky CC: Stefano Babic --- board/freescale/mx6qsabrelite/imximage.cfg |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/board/freescale/mx6qsabrelite/imximage.cfg b/board/freescale/mx6qsabrelite/imximage.cfg index 62498ab..2d7825a 100644 --- a/board/freescale/mx6qsabrelite/imximage.cfg +++ b/board/freescale/mx6qsabrelite/imximage.cfg @@ -168,3 +168,6 @@ DATA 4 0x020e0010 0xF0CF # set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 DATA 4 0x020e0018 0x007F007F DATA 4 0x020e001c 0x007F007F +# set PAD_GPIO_0__CCM_CLKO and PAD_GPIO_3__CCM_CLKO2 +DATA 4 0x020e0220 0x +DATA 4 0x020e022c 0x0004 \ No newline at end of file This is replaced with a kernel patch http://www.spinics.net/lists/arm-kernel/msg187222.html and therefore this patch is obsolete now. Thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6q: mx6qsabrelite: add GPIO_0__CCM_CLKO and GPIO_3__CCM_CLKO2 pin mux
On 02/08/2012 09:36, Dirk Behme wrote: > On 01.08.2012 13:05, Dirk Behme wrote: >> A recent Linux kernel (>= 3.5) has support for the SGTL 5000 sound >> on the SabreLite board. To make this work, U-Boot has to configure the >> pin mux for PAD_GPIO_0__CCM_CLKO and PAD_GPIO_3__CCM_CLKO2 correctly. >> >> Taken from Freescale's ER5 U-Boot for the SabreLite. >> >> Signed-off-by: Dirk Behme >> CC: Troy Kisky >> CC: Stefano Babic >> --- >> board/freescale/mx6qsabrelite/imximage.cfg |3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/board/freescale/mx6qsabrelite/imximage.cfg >> b/board/freescale/mx6qsabrelite/imximage.cfg >> index 62498ab..2d7825a 100644 >> --- a/board/freescale/mx6qsabrelite/imximage.cfg >> +++ b/board/freescale/mx6qsabrelite/imximage.cfg >> @@ -168,3 +168,6 @@ DATA 4 0x020e0010 0xF0CF >> # set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 >> DATA 4 0x020e0018 0x007F007F >> DATA 4 0x020e001c 0x007F007F >> +# set PAD_GPIO_0__CCM_CLKO and PAD_GPIO_3__CCM_CLKO2 >> +DATA 4 0x020e0220 0x >> +DATA 4 0x020e022c 0x0004 >> \ No newline at end of file > > This is replaced with a kernel patch > > http://www.spinics.net/lists/arm-kernel/msg187222.html > > and therefore this patch is obsolete now. Ok, thanks. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
On Wed, 01 Aug 2012 11:13:14 -0600 Stephen Warren wrote: > On 08/01/2012 01:16 AM, Lukasz Majewski wrote: > > Hi Stephen Warren, > > > >> On 07/31/2012 12:37 AM, Lukasz Majewski wrote: > >>> Support for u-boot's "dfu [list]" command. > >> > >>> +U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu, > >>> + "Device Firmware Upgrade", > >>> + " [list]\n" > >>> + " - device firmware upgrade on a device \n" > >>> + "attached to interface \n" > >>> + "[list] - list available alt settings" > >>> +); > ... > >> Somewhat related to this, it looks like the eMMC support doesn't > >> allow the HW partition to be specified; it would be nice to expose > >> alt settings for all of: > >> > >> a) Each individual HW partition (boot0/1 if present, > >> general0/1/2/3 if present, the user area, maybe the replay block) > > > > I'm fully aware of this problem. > > In the eMMC case, the access to boot partitions will be served by > > defining special alt settings for DFU. > > > > Those altsettings will be defined as follows: > > -a[N] boot0 > > -a[N+1] boot1 > > > > Prerequisite for this functionality is support of "boot" > > command, which will allow switching of the MMC available address > > spaces (e.g. between boot0/boot1 and user accessible space). > > Is this "boot" command a DFU protocol command, or a U-Boot > command-line command? I note that the U-Boot command-line already > allows HW partition selection using an additional parameter to "mmc" > - "mmc dev $mmc_device_id $partition_id". I'm rather thinking of a U-boot command (as it is easier to integrate). The command would be "mmc boot " Although it is not yet implemented, it is on the top of mine "TO DO" list :-). > > >> b) Perhaps also a linearized view of the raw eMMC (LBAs > >> 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 > >> write to boot1, LBAs 2*boot_size..end_of_device write to user area > >> for example). > > > > Access to partitions will be done differently. I assume that each > > eMMC memory (the user accessible part) will be equipped with MBR or > > GPT definition. > > That's a different kind of partition though. > > In general, there's no need for the eMMC device to contain any kind of > standardized SW-level partition table. On Tegra, the boot ROM can boot > directly from an eMMC device, and that requires raw data in the > partitions, not a standardized SW partition table. > > > For this reason I'm now developing the USB Mass Storage (UMS) > > gadget to export eMMC to host PC. > > This solves the problem with accessing separate partitions. > > OK, if the raw eMMC device is exposed using USB storage, we should be > able to dd directly to it and the presence-or-lack-thereof of any > MBR/GPT wouldn't even be relevant. With the UMS you would see the whole mmc address space as one partition. Then you can use dd with several parameters to "dump" data to a specific LBA address. When correct MBR or GPT is present, then we can specify partitions to be accessed. > > It'd still be useful to have a linearized view of the flash that > concatenated all the HW partitions into a single raw device, but I > guess an alt setting for that probably could be added later. I think that UMS solves this issue. However, correct me if I'm wrong. Let's assume, that UMS causes host to see following partitions: sde: sde1 sde2 sde3 sde4 < sde5 .. sdeN > Is the "mount -t vfat /dev/sde /mnt" not allowing access to the whole eMMC device (despite of the partitions)? > > > Please also be aware, that DFU shall be used only for relatively > > small files (due to small EP0 bandwidth). > > > > Large files shall be copied with UMS. > > Oh, didn't know that. Just out of curiosity, are you thinking of > implementing that too? The USB Mass Storage gadget is now working with the g_dnl composite gadget as a f_ums function. Unfortunately it is not polished enough to be posted to ML. I'd prefer that DFU related patches would be pulled to ML first. Afterwards I would post the UMS function. -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX35PDK: Starting U-Boot from serial NOR-Flash
Hi Fabio,
>>
>> Have you had any progress on this?
>
I had some progress on my issue, here a summary of what I did:
- I configured a SD-Card as described in doc/README.imximage
- I did the following changes to the U-Boot sources:
+++ b/board/freescale/mx35pdk/imximage.cfg
+BOOT_FROM sd
+#WEIM config-CS5 init
+DATA 4 0xB8002050 0xd843
+DATA 4 0xB8002054 0x22252521
+DATA 4 0xB8002058 0x0a00
+
+# DDR2 init
+DATA 4 0xB8001010 0x0304
+DATA 4 0xB8001010 0x030C
+DATA 4 0xB8001004 0x007ffc3f
+DATA 4 0xB8001000 0x9222
+DATA 4 0x8400 0x12345678
+DATA 4 0xB8001000 0xA222
+DATA 4 0x8000 0x87654321
+DATA 4 0x8000 0x87654321
+DATA 4 0xB8001000 0xB222
+DATA 1 0x8233 0xda
+DATA 1 0x82000780 0xda
+DATA 1 0x82000400 0xda
+DATA 4 0xB8001000 0x82226080
+DATA 4 0xB8001004 0x007ffc3f
+DATA 4 0xB800100C 0x007ffc3f
+DATA 4 0xB8001010 0x0304
+DATA 4 0xB8001008 0x2000
+++ b/boards.cfg
-mx35pdk arm arm1136 -
freescale mx35
+mx35pdkarm arm1136 -
freescale mx35
mx35pdk:IMX_CONFIG=board/freescale/mx35pdk/imximage.cfg
+++ b/include/configs/mx35pdk.h
-#define CONFIG_SYS_TEXT_BASE 0xA000
+#define CONFIG_SYS_TEXT_BASE 0x8780
+++ b/config.mk
-DBGFLAGS= -g # -DDEBUG
+DBGFLAGS= -g -DDEBUG
This ended up as described earlier, with an U-Boot promp stoppping
with the following output:
> CPU: Freescale i.MX35 rev 2.1 at 532 MHz.
> Reset cause: POR
> I2C: ready
Then I did the following change:
+++ b/board/freescale/mx35pdk/mx35pdk.c
size1 = get_ram_size((void *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
- size2 = get_ram_size((void *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);
+size2 = 0;
+ /*size2 = get_ram_size((void *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);*/
gd->ram_size = size1 + size2;
And here the result:
U-Boot 2012.07-00024-g181e4a3 (Aug 02 2012 - 09:49:35)
U-Boot code: 8780 -> 8783ACC8 BSS: -> 87841704
CPU: Freescale i.MX35 rev 2.1 at 532 MHz.
Reset cause: POR
I2C: ready
monitor len: 00041704
ramsize: 0800
TLB table at: 87ff
Top of RAM usable for U-Boot at: 87ff
Reserving 261k for U-Boot at: 87fae000
Reserving 1280k for malloc() at: 87e6e000
Reserving 40 Bytes for Board Info at: 87e6dfd8
Reserving 120 Bytes for Global Data at: 87e6df60
New Stack Pointer is: 87e6df50
RAM Configuration:
Bank #0: 8000 128 MiB
Bank #1: 9000 128 MiB
relocation Offset is: 007ae000
dram_bank_mmu_setup: bank: 0
dram_bank_mmu_setup: bank: 1
monitor flash len: 00041508
Now running in RAM - U-Boot at: 87fae000
Flash: flash detect cfi
fwc addr a000 cmd f0 f0 8bit x 8 bit
fwc addr a000 cmd ff ff 8bit x 8 bit
fwc addr a055 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr a010 is= 14 51
fwc addr a555 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr a010 is= 14 51
fwc addr a000 cmd f0 f0f0 16bit x 8 bit
fwc addr a000 cmd ff 16bit x 8 bit
fwc addr a0aa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr a020 is= 0051 5151
fwc addr aaaa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr a020 is= 0051 5151
fwc addr a000 cmd f0 00f0 16bit x 16 bit
fwc addr a000 cmd ff 00ff 16bit x 16 bit
fwc addr a0aa cmd 98 0098 16bit x 16 bit
is= cmd 51(Q) addr a020 is= 0051 0051
is= cmd 52(R) addr a022 is= 0052 0052
is= cmd 59(Y) addr a024 is= 0059 0059
device interface is 2
found port 2 chip 2 port 16 bits chip 16 bits
00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 06 QRY..@.'6...
10 : 06 09 13 03 05 03 02 1a 02 00 06 00 01 ff 01 00
20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 8b fb 87
fwc addr a000 cmd f0 00f0 16bit x 16 bit
fwc addr aaaa cmd aa 00aa 16bit x 16 bit
fwc addr a554 cmd 55 0055 16bit x 16 bit
fwc addr aaaa cmd 90 0090 16bit x 16 bit
fwc addr a000 cmd f0 00f0 16bit x 16 bit
fwc addr a0aa cmd 98 0098 16bit x 16 bit
manufacturer is 2
manufacturer id is 0x1
device id is 0x227e
device id2 is 0x2301
cfi version is 0x3133
size_ratio 1 port 16 bits chip 16 bits
found 1 erase regions
erase region 0: 0x020001ff
erase_region_count = 512 erase_region_size = 131072
fwc addr a000 cmd f0 00f0 16bit x 16 bit
flash_protect ON: from 0xA000 to 0xA0041507
fwc addr a000 cmd 70 0070 16bit x 16 bit
flash_is_busy: 0
protect on 0
fwc addr a002 cmd 70 0070 16bit x 16 bit
flash_is_busy: 0
protect on 1
fwc addr a004 cmd 70 0070 16bit x 16 bit
flash_is_busy: 0
protect on 2
flash_protect ON: from 0xA008 to 0xA009
fwc addr a008 cmd 70 0070 16bit x 16 bit
flash_is_busy: 0
protect on 4
flash_protect ON: from 0xA00A to 0xA00B
fwc addr a00a cmd 70 0070 16bit x 16 bit
flash_is_busy: 0
protect on 5
64 MiB
NAND: 4096 MiB
Destroy Hash Table: 87fe94c4 table = (null)
Create Hash Table: N=512
INSERT: table 87fe94c4, filled 1/521 rv 87e90f44 ==> name="addip"
value="if test -n ${ipdyn};then run addip_dyn;else run addip_sta;fi"
INSERT: table 87fe94c4,
Re: [U-Boot] [PATCH 4/7] powerpc/82xx: move km/km82xx-common.h within km82xx.h
On 07/30/2012 09:12 PM, Wolfgang Denk wrote: Dear Gerlando, In message<5016d241.4030...@keymile.com> you wrote: Please also try with -M -C and see if this changes anything. For this one patch I can't get git to detect renames. Neither can I. Thanks for trying, though. It turns out you also need to use "-B", see an excellent thorough explanation at http://article.gmane.org/gmane.comp.version-control.git/202723 Even though this patch was already applied, I'm posting a "v2" version for whoever is curious to see a smaller patch. It won't make any difference on the repository, anyway. Thanks, Gerlando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] powerpc/82xx: move km/km82xx-common.h within km82xx.h
The only file including km82xx-common.h is km82xx.h.
So there is no need to have it as a separate file.
Signed-off-by: Gerlando Falauto
---
Changes from v1:
switched to git v1.7.10.4, used git format-patch -M -C -B
---
include/configs/{km/km82xx-common.h => km82xx.h} | 128 +-
1 file changed, 124 insertions(+), 4 deletions(-)
rename include/configs/{km/km82xx-common.h => km82xx.h} (75%)
diff --git a/include/configs/km/km82xx-common.h b/include/configs/km82xx.h
similarity index 75%
rename from include/configs/km/km82xx-common.h
rename to include/configs/km82xx.h
index 2c763bb..9bfb8df 100644
--- a/include/configs/km/km82xx-common.h
+++ b/include/configs/km82xx.h
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2007-2010
+ * (C) Copyright 2007-2011
* Heiko Schocher, DENX Software Engineering, h...@denx.de.
*
* See file CREDITS for list of people who contributed to this
@@ -21,10 +21,130 @@
* MA 02111-1307 USA
*/
-#ifndef __KM82XX_COMMON
-#define __KM82XX_COMMON
+#ifndef __CONFIG_H
+#define __CONFIG_H
/*
+ * High Level Configuration Options
+ * (easy to change)
+ */
+
+#define CONFIG_MPC8247
+/* MGCOGE */
+#if defined(CONFIG_MGCOGE)
+#define CONFIG_HOSTNAMEmgcoge
+#define CONFIG_KM_BOARD_EXTRA_ENV ""
+
+/* MGCOGE3NE */
+#elif defined(CONFIG_MGCOGE3NE)
+#define CONFIG_HOSTNAMEmgcoge3ne
+#define CONFIG_KM_82XX
+#define CONFIG_KM_BOARD_EXTRA_ENV "bobcatreset=true\0"
+
+#else
+#error ("Board unsupported")
+#endif
+
+#defineCONFIG_SYS_TEXT_BASE0xFE00
+
+/* include common defines/options for all Keymile boards */
+#include "km/keymile-common.h"
+#include "km/km-powerpc.h"
+
+#define CONFIG_SYS_SDRAM_BASE 0x
+#define CONFIG_SYS_FLASH_BASE 0xFE00
+#define CONFIG_SYS_FLASH_SIZE 32
+#define CONFIG_SYS_FLASH_CFI
+#define CONFIG_FLASH_CFI_DRIVER
+
+/* MGCOGE */
+#if defined(CONFIG_MGCOGE)
+#define CONFIG_SYS_MAX_FLASH_BANKS 3
+/* max num of sects on one chip */
+#define CONFIG_SYS_MAX_FLASH_SECT 512
+
+#define CONFIG_SYS_FLASH_BASE_10x5000
+#define CONFIG_SYS_FLASH_SIZE_132
+#define CONFIG_SYS_FLASH_BASE_20x5200
+#define CONFIG_SYS_FLASH_SIZE_232
+
+#define CONFIG_SYS_FLASH_BANKS_LIST { CONFIG_SYS_FLASH_BASE, \
+ CONFIG_SYS_FLASH_BASE_1, \
+ CONFIG_SYS_FLASH_BASE_2 }
+#define MTDIDS_DEFAULT "nor3=app"
+
+/*
+ * Bank 1 - 60x bus SDRAM
+ */
+#define SDRAM_MAX_SIZE 0x0800 /* max. 128 MB */
+#define CONFIG_SYS_GLOBAL_SDRAM_LIMIT (256 << 20) /* less than 256 MB */
+
+/* SDRAM initialization values
+*/
+
+#define CONFIG_SYS_OR1 ((~(CONFIG_SYS_GLOBAL_SDRAM_LIMIT-1) & \
+ ORxS_SDAM_MSK) |\
+ ORxS_BPD_8 |\
+ ORxS_ROWST_PBI0_A7 |\
+ ORxS_NUMR_13)
+
+#define CONFIG_SYS_PSDMR ( \
+ PSDMR_SDAM_A14_IS_A5|\
+ PSDMR_BSMA_A14_A16 |\
+ PSDMR_SDA10_PBI0_A9 |\
+ PSDMR_RFRC_5_CLK|\
+ PSDMR_PRETOACT_2W |\
+ PSDMR_ACTTORW_2W|\
+ PSDMR_LDOTOPRE_1C |\
+ PSDMR_WRC_1C|\
+ PSDMR_CL_2)
+
+/* MGCOGE3NE */
+#elif defined(CONFIG_MGCOGE3NE)
+#define CONFIG_SYS_MAX_FLASH_BANKS 2 /* max num of flash banks */
+#define CONFIG_SYS_MAX_FLASH_SECT 1024/*
+* max num of sects on one
+* chip
+*/
+
+#define CONFIG_SYS_FLASH_BASE_10x5000
+#define CONFIG_SYS_FLASH_SIZE_1128
+
+#define CONFIG_SYS_FLASH_SIZE_2 0 /* dummy value to calc SYS_OR5 */
+
+#define CONFIG_SYS_FLASH_BANKS_LIST { CONFIG_SYS_FLASH_BASE, \
+ CONFIG_SYS_FLASH_BASE_1 }
+
+#define MTDIDS_DEFAULT "nor2=app"
+
+/*
+ * Bank 1 - 60x bus SDRAM
+ * mgcoge3ne has 256M.
+ */
+#define SDRAM_MAX_SIZE 0x1000 /* max. 256 MB */
+#define CONFIG_SYS_GLOBAL_SDRAM_LIMIT (512 << 20) /* less than 512 MB */
+
+#define CONFIG_SYS_OR1 ((~(CONFIG_SYS_GLOBAL_SDRAM_LIMIT-1) & \
+ ORxS_SDAM_MSK) |\
+ ORxS_BPD_4 |\
+ ORxS_ROWST_PBI1_A4 |\
+ ORxS_NUMR_13)
+
+#define CONFIG_SYS_PSDMR ( \
+ PSDMR_PBI |\
+ PSDMR_SDAM_A17_IS_A5|\
+ PSDMR_BSMA_A13_A15
Re: [U-Boot] [PATCH v3 1/7] dfu:usb: Support for g_dnl composite download gadget.
Hi Mike,
> On Tuesday 31 July 2012 02:36:57 Lukasz Majewski wrote:
> > --- /dev/null
> > +++ b/drivers/usb/gadget/g_dnl.c
> >
> > +static const struct usb_descriptor_header *otg_desc[] = {
> > + (struct usb_descriptor_header *) &(struct
> > usb_otg_descriptor){
>
> since you're just casting away things, you could just use (void*) to
> make it a bit more compact
>
> also, can this be:
> static const struct usb_descriptor_header * const otg_desc[]
> (notice the 2nd const)
>
After looking into the code I can say that otg_support is not needed
(at least for this gadget) in u-boot. Will be removed.
> > +static struct usb_gadget_strings *g_dnl_composite_strings[] = {
>
> here too:
> static struct usb_gadget_strings * const g_dnl_composite_strings[] = {
This const is anyway discarded by compiler (GCC 4.6.1) when .string
field of struct usb_composite_driver is initialized.
>
> > +static int g_dnl_do_config(struct usb_configuration *c)
> > +{
> > + int ret = -1;
> > + char *s = (char *) c->cdev->driver->name;
>
> pretty sure this should be:
> const char *s = c->cdev->driver->name;
Yes, you are right. Corrected.
>
> > +static int g_dnl_bind(struct usb_composite_dev *cdev)
> > +{
> > + int gcnum;
> > + int id, ret;
> > + struct usb_gadget *gadget = cdev->gadget;
>
> can we stick to a single space for indentation between the type and
> the variable name please ?
Corrected.
>
> > +int g_dnl_register(const char *type)
> > +{
> > + int ret;
> > + /* We only allow "dfu" atm, so 3 should be enough */
> > + static char name[sizeof(shortname) + 3];
> > +
> > + if (!strcmp(type, "dfu")) {
> > + strcpy(name, shortname);
> > + strcat(name, type);
>
> if u-boot had stpcpy(), we could do:
> strcpy(stpcpy(name, shortname), type);
>
> > --- /dev/null
> > +++ b/include/g_dnl.h
> >
> > +/* USB initialization declaration - board specific*/
>
> needs a space before that "*/"
Corrected.
> -mike
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] GPIO: Extend the cmd_gpio API by gpio_{from, to}_string()
Dear Mike Frysinger, > On Monday 14 May 2012 07:31:35 Marek Vasut wrote: > > Dear Mike Frysinger, > > > > > On Tuesday 01 May 2012 16:50:14 Marek Vasut wrote: > > > > The gpio_from_string() call shall parse the incoming GPIO name taken > > > > from the command line and return the GPIO number used within U-Boot > > > > or return -1 on error. > > > > > > i.e. the already existing name_to_gpio() func > > > > You mean blackfin specific macro crap? Let's actually drop that and > > switch over to this one. That was my intention from start. > > don't spout this crap. try reading the actual history on the lists for the > background on the naming, and then try actually grepping the tree to see > that multiple targets implement it. So ... it was chosen to be compatible with linux gpio api, that's what I understood ... so I grepped the kernel source: linux-2.6# git grep name_to_gpio drivers/gpio/ linux-2.6# git grep name_to_gpio include/ linux-2.6# git grep gpio_to_name include/ linux-2.6# git grep gpio_to_name drivers/gpio/ Nothing. [...] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] at91: Add support for taskit AT91SAM9G20 boards.
On Wed, Aug 01, 2012 at 10:59:10PM +0200, Andreas Bießmann wrote:
> On 01.08.12 21:57, Markus Hubig wrote:
> > +Markus Hubig
> > +
> > + STAMP9G20 ARM926EJS
> > +
> > Ilko Iliev
>
> unfortunately Ilko Iliev is wrong here ... this is the PPC section (all
> these MPCxx). About line 566 begins the ARM section.
Moved both of us ...
> > + * RAM Memory address where to put the
> > + * Linux Kernel bevor starting.
> ^
> before?
Ups ...
> > + "mtdparts=mtdparts=atmel_nand:128k(bootstrap)ro," \
> > + "256k(uboot)ro,128k(env1)ro," \
> > + "128k(env2)ro,12M(linux),-(root)rw\0" \
>
> your table in comment tells 6MiB for kernel, here you have 12MiB ;)
Grrr fixed! ;)
> > + "nfsboot=dhcp; setenv bootargs ${basicargs} ${mtdparts} " \
> > + "root=/dev/nfs ip=dhcp; bootm\0"
>
> dhcp command can use some env (I think bootfile) to directely boot. So
> setting this env, setting bootargs and then run dhcp would maybe better.
> Alternatively the nfsboot could imply a correctly set bootfile, this
> could be another env in your EXTRA_ENV_SETTINGS (another side note;).
Ahh it's autoboot=yes! ;)
Btw: I think it would be easier to handle if all the options in
env_common.h would be prefixed with CONFIG_ENV_* ...
> > +#endif /* __CONFIG_H */
> >
>
> We should think about the MACB ifdef stuff again. I learned that the
> stamp9g20 is a small device sitting on different base boards. In case of
> portux9g20 we will have ethernet. Therefore we should always enable MACB
> when we are configured as portux9g20. But if one uses the stamp on
> another base board he maybe want to disable ethernet support easily ...
> with this information I think it is good to have these ifdef blocks
> around all the ethernet stuff. Sorry, I understood this in your last
> mail and you sent this patch to fast to comment ...
Hmm ok good idea ... will include this in the next patch.
Cheers, Markus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/7] dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
Dear Mike,
> On Tuesday 31 July 2012 02:36:58 Lukasz Majewski wrote:
> > --- /dev/null
> > +++ b/drivers/usb/gadget/f_dfu.c
> >
> > +static struct usb_interface_descriptor dfu_intf_runtime = {
>
> can this be made const ?
Unfortunately those structs cannot be const, since some of their fields
are filled during running DFU code(when switching between "normal" and
"dfu" mode).
>
> > +static struct usb_descriptor_header *dfu_runtime_descs[] = {
> > + (struct usb_descriptor_header *) &dfu_intf_runtime,
>
> can you change the descs array to be const ?
> static const struct usb_descriptor_header * const dfu_runtime_descs[]
> = {
>
The same as above. Moreover the DFU implementation passes the
information about available alt settings as descriptors filled at
runtime.
> then i think you can drop the cast there ...
>
> > +static struct usb_qualifier_descriptor dev_qualifier = {
Struct above can only be defined as const.
> > +static struct usb_gadget_strings stringtab_dfu_generic = {
> > +static struct usb_gadget_strings *dfu_generic_strings[] = {
> > +static struct usb_gadget_strings stringtab_dfu = {
> > +static struct usb_gadget_strings *dfu_strings[] = {
>
> can these be made const ?
>
> > +static void handle_getstate(struct usb_request *req)
> > +{
> > + struct f_dfu *f_dfu = req->context;
> > +
> > + ((u8 *)req->buf)[0] = f_dfu->dfu_state & 0xff;
>
> pretty sure you don't need that "& 0xff"
OK.
>
> > +static int state_app_idle(struct f_dfu *f_dfu,
> > + const struct usb_ctrlrequest *ctrl,
> > + struct usb_gadget *gadget,
> > + struct usb_request *req)
> > +{
> > + int value = 0;
>
> might be good to push this down into the 1 case statement
> (USB_REQ_DFU_GETSTATE) that uses it rather than init it up top
>
I haven't understood this comment.
Do you suggest to combine all those functions (like state_app_* or
state_dfu_*) in one big switch - case clause?
The state machine was initially implemented in this way, but for sake
of clearness Marek Vasut asked to split it down do separate functions
as defined at dfu_state[]. I also think that this approach is better
than one bit switch - case.
> same goes for all the other funcs below that follow this style
> -mike
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5] Corrupted NAND Flash access on KARO TX25 modules.
The mxc_nand driver uses the symmetric mode to access the NAND Flash, but the devices populated on the KARO TX25 only support ann asymmetic mode (MX25: bit 8 within NAND_FLAHS_CONFIG1 register cleared). This patch enables to selected the NAND Flash access mode with the configuration flag CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES. Signed-off-by: Daniel Gachet --- drivers/mtd/nand/mxc_nand.c | 13 + include/configs/tx25.h |1 + 2 files changed, 14 insertions(+) diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c index 936186f..08fbb12 100644 --- a/drivers/mtd/nand/mxc_nand.c +++ b/drivers/mtd/nand/mxc_nand.c @@ -48,6 +48,17 @@ * Reading or writing a 2K or 4K page requires only 1 FDI/FDO cycle. * Also some of registers are moved and/or changed meaning as seen below. */ +/* + * NAND Flash access mode on MX25 + * + * The MX25 NAND Flash Controller supports two modes to access the Flash: + * a) symmetric mode (one Flash clock cycle per access) or + * b) asymmetric mode (two Flash clock cycles per access) + * + * By default the NAND Flash Controller is configured in the symmetric mode. + * To select the asymmetric mode, the configuration option + * CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES has to be selected. + */ #if defined(CONFIG_MX31) || defined(CONFIG_MX27) #define MXC_NFC_V1 #elif defined(CONFIG_MX25) || defined(CONFIG_MX35) @@ -1290,7 +1301,9 @@ static void mxc_setup_config1(void) uint16_t tmp; tmp = readw(&host->regs->nfc_config1); +#ifndef CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES tmp |= NFC_ONE_CYCLE; +#endif tmp |= NFC_4_8N_ECC; writew(tmp, &host->regs->nfc_config1); if (host->pagesize_2k) diff --git a/include/configs/tx25.h b/include/configs/tx25.h index 6821528..8fa51cb 100644 --- a/include/configs/tx25.h +++ b/include/configs/tx25.h @@ -109,6 +109,7 @@ /* NAND */ #define CONFIG_NAND_MXC #define CONFIG_NAND_MXC_V1_1 +#define CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES /* 2 cycles to access NAND Flash */ #define CONFIG_MXC_NAND_REGS_BASE (0xBB00) #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_SYS_NAND_BASE (0xBB00) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Corrupted NAND Flash access on KARO TX25 modules.
Dear Daniel, On Thu, Aug 2, 2012 at 01:17:07 PM, Daniel Gachet wrote: > The mxc_nand driver uses the symmetric mode to access the NAND Flash, > but the > devices populated on the KARO TX25 only support ann asymmetic mode > (MX25: bit 8 within NAND_FLAHS_CONFIG1 register cleared). > > This patch enables to selected the NAND Flash access mode with the > configuration flag CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES. > > Signed-off-by: Daniel Gachet > --- > drivers/mtd/nand/mxc_nand.c | 13 + > include/configs/tx25.h |1 + > 2 files changed, 14 insertions(+) > > diff --git a/drivers/mtd/nand/mxc_nand.c > b/drivers/mtd/nand/mxc_nand.c > index 936186f..08fbb12 100644 > --- a/drivers/mtd/nand/mxc_nand.c > +++ b/drivers/mtd/nand/mxc_nand.c > @@ -48,6 +48,17 @@ > * Reading or writing a 2K or 4K page requires only 1 FDI/FDO > cycle. > * Also some of registers are moved and/or changed meaning as > seen below. > */ > +/* > + * NAND Flash access mode on MX25 > + * > + * The MX25 NAND Flash Controller supports two modes to access the > Flash: > + * a) symmetric mode (one Flash clock cycle per access) or > + * b) asymmetric mode (two Flash clock cycles per access) > + * > + * By default the NAND Flash Controller is configured in the > symmetric mode. > + * To select the asymmetric mode, the configuration option > + * CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES has to be selected. > + */ > #if defined(CONFIG_MX31) || defined(CONFIG_MX27) > #define MXC_NFC_V1 > #elif defined(CONFIG_MX25) || defined(CONFIG_MX35) > @@ -1290,7 +1301,9 @@ static void mxc_setup_config1(void) > uint16_t tmp; > > tmp = readw(&host->regs->nfc_config1); > +#ifndef CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES > tmp |= NFC_ONE_CYCLE; > +#endif > tmp |= NFC_4_8N_ECC; > writew(tmp, &host->regs->nfc_config1); > if (host->pagesize_2k) > diff --git a/include/configs/tx25.h b/include/configs/tx25.h > index 6821528..8fa51cb 100644 > --- a/include/configs/tx25.h > +++ b/include/configs/tx25.h > @@ -109,6 +109,7 @@ > /* NAND */ > #define CONFIG_NAND_MXC > #define CONFIG_NAND_MXC_V1_1 > +#define CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES /* 2 cycles to access > NAND Flash */ > #define CONFIG_MXC_NAND_REGS_BASE(0xBB00) > #define CONFIG_SYS_MAX_NAND_DEVICE 1 > #define CONFIG_SYS_NAND_BASE (0xBB00) > -- > 1.7.9.5 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > Why don't you simply add a factor of two to the CCM NFC divider in lowlevel_init.S? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX35PDK: Starting U-Boot from serial NOR-Flash
On 8/2/12, Michael Hornung wrote: > Hi Fabio, > >>> >>> Have you had any progress on this? >> > > I had some progress on my issue, here a summary of what I did: > > - I configured a SD-Card as described in doc/README.imximage > - I did the following changes to the U-Boot sources: > > +++ b/board/freescale/mx35pdk/imximage.cfg > > +BOOT_FROM sd > > +#WEIM config-CS5 init > +DATA 4 0xB8002050 0xd843 > +DATA 4 0xB8002054 0x22252521 > +DATA 4 0xB8002058 0x0a00 > + > +# DDR2 init > +DATA 4 0xB8001010 0x0304 > +DATA 4 0xB8001010 0x030C > +DATA 4 0xB8001004 0x007ffc3f > +DATA 4 0xB8001000 0x9222 > +DATA 4 0x8400 0x12345678 > +DATA 4 0xB8001000 0xA222 > +DATA 4 0x8000 0x87654321 > +DATA 4 0x8000 0x87654321 > +DATA 4 0xB8001000 0xB222 > +DATA 1 0x8233 0xda > +DATA 1 0x82000780 0xda > +DATA 1 0x82000400 0xda > +DATA 4 0xB8001000 0x82226080 > +DATA 4 0xB8001004 0x007ffc3f > +DATA 4 0xB800100C 0x007ffc3f > +DATA 4 0xB8001010 0x0304 > +DATA 4 0xB8001008 0x2000 > > +++ b/boards.cfg > > -mx35pdk arm arm1136 - > freescale mx35 > +mx35pdkarm arm1136 - > freescale mx35 > mx35pdk:IMX_CONFIG=board/freescale/mx35pdk/imximage.cfg > > +++ b/include/configs/mx35pdk.h > > -#define CONFIG_SYS_TEXT_BASE 0xA000 > +#define CONFIG_SYS_TEXT_BASE 0x8780 > > +++ b/config.mk > > -DBGFLAGS= -g # -DDEBUG > +DBGFLAGS= -g -DDEBUG > Didn't you also had to remove the init_sdram call in lowlevel_init.S ? > This ended up as described earlier, with an U-Boot promp stoppping > with the following output: > >> CPU: Freescale i.MX35 rev 2.1 at 532 MHz. >> Reset cause: POR >> I2C: ready > > > Then I did the following change: > > +++ b/board/freescale/mx35pdk/mx35pdk.c > > size1 = get_ram_size((void *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE); > - size2 = get_ram_size((void *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE); > +size2 = 0; > + /*size2 = get_ram_size((void *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);*/ I think we should not touch this. > > gd->ram_size = size1 + size2; > > > And here the result: > > U-Boot 2012.07-00024-g181e4a3 (Aug 02 2012 - 09:49:35) > > U-Boot code: 8780 -> 8783ACC8 BSS: -> 87841704 > CPU: Freescale i.MX35 rev 2.1 at 532 MHz. > Reset cause: POR > I2C: ready > monitor len: 00041704 > ramsize: 0800 > TLB table at: 87ff > Top of RAM usable for U-Boot at: 87ff > Reserving 261k for U-Boot at: 87fae000 > Reserving 1280k for malloc() at: 87e6e000 > Reserving 40 Bytes for Board Info at: 87e6dfd8 > Reserving 120 Bytes for Global Data at: 87e6df60 > New Stack Pointer is: 87e6df50 > RAM Configuration: > Bank #0: 8000 128 MiB > Bank #1: 9000 128 MiB > relocation Offset is: 007ae000 > dram_bank_mmu_setup: bank: 0 > dram_bank_mmu_setup: bank: 1 > monitor flash len: 00041508 > Now running in RAM - U-Boot at: 87fae000 > Flash: flash detect cfi > fwc addr a000 cmd f0 f0 8bit x 8 bit > fwc addr a000 cmd ff ff 8bit x 8 bit > fwc addr a055 cmd 98 98 8bit x 8 bit > is= cmd 51(Q) addr a010 is= 14 51 > fwc addr a555 cmd 98 98 8bit x 8 bit > is= cmd 51(Q) addr a010 is= 14 51 > fwc addr a000 cmd f0 f0f0 16bit x 8 bit > fwc addr a000 cmd ff 16bit x 8 bit > fwc addr a0aa cmd 98 9898 16bit x 8 bit > is= cmd 51(Q) addr a020 is= 0051 5151 > fwc addr aaaa cmd 98 9898 16bit x 8 bit > is= cmd 51(Q) addr a020 is= 0051 5151 > fwc addr a000 cmd f0 00f0 16bit x 16 bit > fwc addr a000 cmd ff 00ff 16bit x 16 bit > fwc addr a0aa cmd 98 0098 16bit x 16 bit > is= cmd 51(Q) addr a020 is= 0051 0051 > is= cmd 52(R) addr a022 is= 0052 0052 > is= cmd 59(Y) addr a024 is= 0059 0059 > device interface is 2 > found port 2 chip 2 port 16 bits chip 16 bits > 00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 06 QRY..@.'6... > 10 : 06 09 13 03 05 03 02 1a 02 00 06 00 01 ff 01 00 > 20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 8b fb 87 > fwc addr a000 cmd f0 00f0 16bit x 16 bit > fwc addr aaaa cmd aa 00aa 16bit x 16 bit > fwc addr a554 cmd 55 0055 16bit x 16 bit > fwc addr aaaa cmd 90 0090 16bit x 16 bit > fwc addr a000 cmd f0 00f0 16bit x 16 bit > fwc addr a0aa cmd 98 0098 16bit x 16 bit > manufacturer is 2 > manufacturer id is 0x1 > device id is 0x227e > device id2 is 0x2301 > cfi version is 0x3133 > size_ratio 1 port 16 bits chip 16 bits > found 1 erase regions > erase region 0: 0x020001ff > erase_region_count = 512 erase_region_size = 131072 > fwc addr a000 cmd f0 00f0 16bit x 16 bit > flash_protect ON: from 0xA000 to 0xA0041507 > fwc addr a000 cmd 70 0070 16bit x 16 bit > flash_is_busy: 0 > protect on 0 > fwc addr a002 cmd 70 0070 16bit x 16 bit > flash_is_busy: 0 > protect on 1 > fwc addr a004 cmd 70 0070 16bit x 16 bit > flash_is_busy: 0 > protect on 2 > flash_protect ON: from 0xA008 to 0xA009 > fwc addr a008 cmd 70 0
Re: [U-Boot] i.MX35PDK: Starting U-Boot from serial NOR-Flash
On 02/08/2012 14:55, Fabio Estevam wrote:
> On 8/2/12, Michael Hornung wrote:
>> Hi Fabio,
>>
Hi Michael,
>> Starting kernel ...
>>
>> Uncompressing
>> Linux..
>> done, booting the kernel.
>>
>> And that's it, no more kernel output.
At this point, there is no difference for u-boot starting the kernel if
it has booted in external or internal mode. It seems an unrelated issue.
On mx35pdk you can reset the board without powerd off. You should check
the address in kernel for the log buffer (__log_buf in System.map) and
then check it after a reset in u-boot with the "md" command. If we are
lucky, the RAM does not lose its values. Better will be if you have a
JTAG debugger and can you check inside memory directly when the kernel
hangs without rebooting.
>>
>> Here my environment
>>
>> addip=if test -n ${ipdyn};then run addip_dyn;else run addip_sta;fi
>> addip_dyn=setenv bootargs ${bootargs} ip=dhcp
>> addip_sta=setenv bootargs ${bootargs}
>> ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off
>> panic=1
>> addmisc=setenv bootargs ${bootargs} ${misc}
>> addmtd=setenv bootargs ${bootargs} ${mtdparts}
>> addtty=setenv bootargs ${bootargs} console=ttymxc0,${baudrate}
>> baudrate=115200
>> bootargs_nfs=setenv bootargs console=ttymxc0,${baudrate} root=/dev/nfs
Depending on the kernel version, ttymxc0 could be wrong. Have you
checked it ?
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91: Add support for taskit AT91SAM9G20 boards.
On Wed, Aug 01, 2012 at 10:21:04PM +0200, Andreas Bießmann wrote:
> On 01.08.12 21:28, Markus Hubig wrote:
> > On Wed, Aug 01, 2012 at 11:58:22AM +0200, Andreas Bießmann wrote:
> >>> + /* Need to reset PHY -> 500ms reset */
> >>> + writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) |
> >>> + AT91_RSTC_MR_URSTEN, &rstc->mr);
> >>
> >> Hmm ... is it OK to generate the user reset here? I know this is the
> >> same in at least at91sam9263ek, can you please check if we should
> >> instead delete that bit in MR?
> >
> > MR? Sorry I don't get this one. Please explain a bit ...
>
> I talked about URSTEN bit in RSTC_MR (Reset Controller Mode Register;
> p99 in at91sam9g20 datasheet). The URSTEN bit set to 1 means disable low
> level detection on NRST pin. Which in fact disables external reset with
> the reset key. One have to check if this is true or maybe I'm wrong here.
Hmm ok I'll investigate this a bit further ...
> > | /* avoid shutdown by watchdog */
> > | hw_watchdog_reset();
>
> WATCHDOG_RESET();
Fixed!
> > | if (timeout <= 0) {
> > | debug("ERROR: Timeout waiting for PHY reset!\n");
>
> Error messages should not use debug macro.
Fixed!
> For timeout stuff you could also use get_timer(0) to get current
> timestamp and compare against another timestamp.
Fixed!
Cheers, Markus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Corrupted NAND Flash access on KARO TX25 modules.
Dear Daniel, Scott, On Thu, Aug 2, 2012 at 01:28:08 PM, Benoît Thébaudeau wrote: > On Thu, Aug 2, 2012 at 01:17:07 PM, Daniel Gachet wrote: > > The mxc_nand driver uses the symmetric mode to access the NAND > > Flash, > > but the > > devices populated on the KARO TX25 only support ann asymmetic mode > > (MX25: bit 8 within NAND_FLAHS_CONFIG1 register cleared). > > > > This patch enables to selected the NAND Flash access mode with the > > configuration flag CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES. [snip] > Why don't you simply add a factor of two to the CCM NFC divider in > lowlevel_init.S? To be more specific, I also have hardware based on the i.MX25 that does not use the NAND Flash from the reference design. It works fine with the symmetric mode as long as the NFC prescaler is set up appropriately in the MMC. I don't think that it is possible that a NAND Flash device does not support symmetric mode. So there should not be any need for a CONFIG_SYS_NAND_MXC_NFC_TWO_CYCLES config option. All you have to do is to set the appropriate value in PER8 DIV in PCDR2 (address 0x53f80020). This can easily be added as a single line to the init_clocks macro in board/karo/tx25/lowlevel_init.S. Since the TX25 board does not set this register, it is left at its reset value, which is 0x01010101, so the line to add would be (dividing the NFC clock twice more): write32 0x53f80020, 0x01010103 This patch is interfering with a patch series that I'd like to post today or tomorrow, so please make a quick decision about this, so that I can know if I should take this patch into account for my series or if I should ignore it. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] dfu: DFU backend implementation
Dear Mike Frysinger,
> On Tuesday 31 July 2012 02:36:59 Lukasz Majewski wrote:
> > --- /dev/null
> > +++ b/drivers/dfu/dfu.c
> >
> > +static int dfu_find_alt_num(char *s)
>
> const char *s
Good point.
>
> > +{
> > + int i = 0;
> > +
> > + for (; *s; s++)
> > + if (*s == ';')
> > + i++;
> > +
> > + return ++i;
> > +}
In this function I count how many times the ';' separator appears.
I didn't found proper function at ./lib/string.c.
>
> looks kind of like:
> return (strrchr(s, ';') - s) + 1;
The above code returns position of the last occurrence of the ';'
separator.
>
> > +int dfu_write(struct dfu_entity *dfu, void *buf, int size, int
> > blk_seq_num) +{
> > + static unsigned char *i_buf;
> > + static int i_blk_seq_num;
> > + long w_size = 0;
> > + int ret = 0;
> > +
> > + if (blk_seq_num == 0) {
> > + memset(dfu_buf, '\0', sizeof(dfu_buf));
> > ...
> > + memcpy(i_buf, buf, size);
> > + i_buf += size;
>
> why bother clearing it ? since right below we memcpy() in the data
> we care about from buf, i'd skip the memset() completely.
You are right, removed.
>
> > +int dfu_read(struct dfu_entity *dfu, void *buf, int size, int
> > blk_seq_num) +{
> > + static unsigned char *i_buf;
> > + static int i_blk_seq_num;
> > + static long r_size;
> > + static u32 crc;
> > + int ret = 0;
> > +
> > + if (blk_seq_num == 0) {
> > + i_buf = dfu_buf;
> > + memset(dfu_buf, '\0', sizeof(dfu_buf));
> > + ret = dfu->read_medium(dfu, i_buf, &r_size);
> > + debug("%s: %s %ld [B]\n", __func__, dfu->name,
> > r_size);
> > + i_blk_seq_num = 0;
> > + /* Integrity check (if needed) */
> > + crc = crc32(0, dfu_buf, r_size);
> > + }
>
> same here -- punt the memset()
OK,
>
> > +static int dfu_fill_entity(struct dfu_entity *dfu, char* s, int
> > alt,
>
> "char *s", not "char* s"
OK,
>
> > +int dfu_config_entities(char *env, char *interface, int num)
> > +{
> > + struct dfu_entity *dfu;
> > + int i, ret;
> > + char *s;
> > +
> > + dfu_alt_num = dfu_find_alt_num(env);
> > + debug("%s: dfu_alt_num=%d\n", __func__, dfu_alt_num);
> > +
> > + for (i = 0; i < dfu_alt_num; i++) {
> > + dfu = calloc(sizeof(struct dfu_entity), 1);
>
> seems like you can do this in a single call outside of the for loop:
> dfu = calloc(sizeof(*dfu), dfu_alt_num);
> if (!dfu)
> return -1;
> for (i = 0; i < dfu_alt_num; i++) {
> s = strsep(&env, ";");
> ret = dfu_fill_entity(&dfu[i], s, i, interface, num);
> if (ret)
> return -1;
> list_add_tail(&dfu[i].list, &dfu_list);
> }
>
I'd prefer to leave it as it is (since IMHO is more readable) with the
addition of following code:
for (i = 0; i < dfu_alt_num; i++) {
dfu = calloc(sizeof(struct dfu_entity), 1);
if (!dfu) {
dfu_free_entities();
return -1;
}
}
> > --- /dev/null
> > +++ b/include/dfu.h
> >
> > +char *dfu_extract_token(char** e, int *n);
> > +extern int dfu_fill_entity_mmc(struct dfu_entity *dfu, char* s);
> > +static inline int dfu_fill_entity_mmc(struct dfu_entity *dfu,
> > char* s)
>
> "char *s", not "char* s"
OK
> -mike
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3] at91: Add support for taskit AT91SAM9G20 boards.
This adds support for the AT91SAM9G20 boards by taskit GmbH.
Both boards, Stamp9G20 and PortuxG20, are integrated in one
file. PortuxG20 is basically a SBC built around the Stamp9G20.
Signed-off-by: Markus Hubig
Cc: Andreas Bießmann
---
MAINTAINERS| 16 ++-
board/taskit/stamp9g20/Makefile| 52
board/taskit/stamp9g20/stamp9g20.c | 196 ++
boards.cfg |2 +
include/configs/stamp9g20.h| 235
5 files changed, 495 insertions(+), 6 deletions(-)
create mode 100644 board/taskit/stamp9g20/Makefile
create mode 100644 board/taskit/stamp9g20/stamp9g20.c
create mode 100644 include/configs/stamp9g20.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 84413de..7eb55db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -243,12 +243,6 @@ Klaus Heydeck
KUP4K MPC855
KUP4X MPC859
-Ilko Iliev
-
- PM9261 AT91SAM9261
- PM9263 AT91SAM9263
- PM9G45 ARM926EJS (AT91SAM9G45 SoC)
-
Gary Jennejohn
quad100hd PPC405EP
@@ -681,10 +675,20 @@ Vaibhav Hiremath
am3517_evm ARM ARMV7 (AM35x SoC)
+Markus Hubig
+
+ STAMP9G20 ARM926EJS
+
Grazvydas Ignotas
omap3_pandora ARM ARMV7 (OMAP3xx SoC)
+Ilko Iliev
+
+ PM9261 AT91SAM9261
+ PM9263 AT91SAM9263
+ PM9G45 ARM926EJS (AT91SAM9G45 SoC)
+
Michael Jones
omap3_mvblx ARM ARMV7 (OMAP3xx SoC)
diff --git a/board/taskit/stamp9g20/Makefile b/board/taskit/stamp9g20/Makefile
new file mode 100644
index 000..e99bfaa
--- /dev/null
+++ b/board/taskit/stamp9g20/Makefile
@@ -0,0 +1,52 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop
+# Lead Tech Design
+#
+# (C) Copyright 2012
+# Markus Hubig
+# IMKO GmbH
+#
+# 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-y+= stamp9g20.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/taskit/stamp9g20/stamp9g20.c
b/board/taskit/stamp9g20/stamp9g20.c
new file mode 100644
index 000..80359a7
--- /dev/null
+++ b/board/taskit/stamp9g20/stamp9g20.c
@@ -0,0 +1,196 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop
+ * Lead Tech Design
+ *
+ * Achim Ehrlich
+ * taskit GmbH
+ *
+ * (C) Copyright 2012-
+ * Markus Hubig
+ * IMKO GmbH
+ *
+ * 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
+
+#ifdef CONFIG_MACB
+# include
+# include
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void stamp9G20_nand_hw_init(void)
+{
+ struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
+ struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
+ unsigned long csa;
+
+ /* Assign CS3 to NAND/SmartMedia Interface */
+ csa = readl(&
Re: [U-Boot] [PATCH] at91: Add support for taskit AT91SAM9G20 boards.
On Wed, Aug 01, 2012 at 11:58:22AM +0200, Andreas Bießmann wrote:
> On 30.07.12 20:01, Markus Hubig wrote:
> >
> > +int board_early_init_f(void)
> > +{
> > + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> > +
> > + /* Enable clocks for all PIOs */
> > + writel((1 << ATMEL_ID_PIOA) | (1 << ATMEL_ID_PIOB) |
> > + (1 << ATMEL_ID_PIOC), &pmc->pcer);
>
> you should initialize seriald_hw here to avoid strange characters on
> serial line when switching from at91bootstrap to u-boot.
> > + /* adress of boot parameters */
> > + gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
> > +
> > + at91_set_gpio_output(AT91_PIN_PC9, 1);
> > + at91_set_gpio_output(AT91_PIN_PC5, 1);
>
> Can you please add some comment why switching these pins?
OK now I now that PC5 switches the red LED on and there since is a
LED framework in u-boot I will use that in a later patch.
PC9 is somewhat strange. If I set it to 0 I don't have a console!
So I tried to put both
| at91_set_gpio_output(AT91_PIN_PC9, 1);
| at91_seriald_hw_init();
into board_early_init_f() to avoid the strange characters at boot time,
but again no console output ...
Further tests showed that It seems that I can't use at91_set_gpio_output()
inside board_early_init_f(). Switching on the red LED with PC5 also do not
work in board_early_init_f() ...
Any ideas?
Cheers, Markus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/7] dfu: MMC specific routines for DFU operation
Dear Mike Frysinger,
> On Tuesday 31 July 2012 02:37:00 Lukasz Majewski wrote:
> > --- /dev/null
> > +++ b/drivers/dfu/dfu_mmc.c
> >
> > +static int mmc_block_op(enum dfu_mmc_op op, struct dfu_entity *dfu,
> > + void *buf, long *len)
> > +{
> > + ALLOC_CACHE_ALIGN_BUFFER(char, cmd_buf, DFU_CMD_BUF_SIZE);
>
> ugh, what ? you're passing this string to run_command so there is no
> point in aligning it
Ok, I will change this.
> (not to mention the topic of u-boot code
> internally calling run_command() is seriously wrong.
We are all aware that this approach is a compromise. And this code
will be rewritten when new DM appears.
>
> > + memset(cmd_buf, '\0', sizeof(cmd_buf));
> > +
> > + sprintf(cmd_buf, "mmc %s 0x%x %x %x",
>
> that memset is pointless. delete it.
Done.
>
> > +static int mmc_file_op(enum dfu_mmc_op op, struct dfu_entity *dfu,
> > + void *buf, long *len)
> > +{
>
> came comments for this func as above
>
> > +int dfu_fill_entity_mmc(struct dfu_entity *dfu, char* s)
>
> "char *s", not "char* s". please search all your patches for this
> mistake as it seems to have come up a lot.
Hmm, ./tools/checkpatch wasn't complaining about this...
> -mike
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7 V4] SPI: Add W25Q32 to Winbond SPI flash table
On Thursday 02 August 2012 03:25:05 Rajeshwari Shinde wrote: > SMDK EVT1 has a different Winbond part, added its part details > to the SPI flash table thanks, merged in my sf branch -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7 V4] SPI: Add SPI Driver for EXYNOS.
Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
Dear Marek Vasut, > Dear Mike Frysinger, > > > On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote: > > > --- /dev/null > > > +++ b/common/cmd_dfu.c > > > > > > + static char *s = "dfu"; > > > > no need for this to be static > > It can be pulled out of the function and be made into const static Ok. > > > -mike > > Best regards, > Marek Vasut -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problem booting linux kernel due to garbled available machine support
Hello All, I'm having a problem booting a linux kernel built with Marvell buildroot-sdk-6.0 for an Armada XP development board (DB-78460-BP). The kernel messages indicate that the machine id is not recognized or not supported, but I believe this is because the available machine support is all junk. Marvell>> bootm 0x200 ## Booting kernel from Legacy Image at 0200 ... Image Name: linux-3.0 Created: 2012-08-02 14:04:49 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3303200 Bytes = 3.2 MB Load Address: 02008000 Entry Point: 02008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Using machid 0xbdc from environment Starting kernel ... Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported machine ID (r1 = 0x0bdc). Available machine support: ID (hex)NAME (null) c000e150(null) À á0Ø-é°LââßMâMëP1å ã c000e234¬õÀ À á0Ø-é°Lâ Please check your kernel config and/or bootloader. These are the machine types in my kernel config which should be showing up in the available machine support, but for some reason is garbled. [dallasc /development/dallasc/TS-3400/buildroot-2011.05-sdk6.0/output/build/linux-3.0.6] grep '^CONFIG_MACH' .config CONFIG_MACH_ARMADA_XP_DB=y CONFIG_MACH_ARMADA_XP_RDSRV=y CONFIG_MACH_ARMADA_XP_RD_NAS=y [dallasc /development/dallasc/TS-3400/buildroot-2011.05-sdk6.0/output/build/linux-3.0.6] grep MACH_ARMADA arch/arm/tools/mach-types armada_xp_fpga MACH_ARMADA_XP_FPGA ARMADA_XP_FPGA 528 armada_xp_db MACH_ARMADA_XP_DB ARMADA_XP_DB 3036 armada_xp_rd_nasMACH_ARMADA_XP_RD_NAS ARMADA_XP_RD_NAS 3500 armada_xp_rdsrvMACH_ARMADA_XP_RDSRV ARMADA_XP_RDSRV 3037 It looks like the DB-78460-BP board is identifying itself as 0x0bdc = 3036, which corresponds to the armada_xp_db. Does anyone have any suggestions on how to debug the cause of the garbling? Thanks, Dallas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
On 08/02/2012 02:31 AM, Lukasz Majewski wrote: > On Wed, 01 Aug 2012 11:13:14 -0600 > Stephen Warren wrote: > >> On 08/01/2012 01:16 AM, Lukasz Majewski wrote: >>> Hi Stephen Warren, >>> On 07/31/2012 12:37 AM, Lukasz Majewski wrote: > Support for u-boot's "dfu [list]" command. > +U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu, > + "Device Firmware Upgrade", > + " [list]\n" > + " - device firmware upgrade on a device \n" > + "attached to interface \n" > + "[list] - list available alt settings" > +); >> ... Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of: a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block) >>> >>> I'm fully aware of this problem. >>> In the eMMC case, the access to boot partitions will be served by >>> defining special alt settings for DFU. >>> >>> Those altsettings will be defined as follows: >>> -a[N] boot0 >>> -a[N+1] boot1 >>> >>> Prerequisite for this functionality is support of "boot" >>> command, which will allow switching of the MMC available address >>> spaces (e.g. between boot0/boot1 and user accessible space). >> >> Is this "boot" command a DFU protocol command, or a U-Boot >> command-line command? I note that the U-Boot command-line already >> allows HW partition selection using an additional parameter to "mmc" >> - "mmc dev $mmc_device_id $partition_id". > > I'm rather thinking of a U-boot command (as it is easier to integrate). > The command would be "mmc boot " > > Although it is not yet implemented, it is on the top of mine "TO DO" > list :-). I guess I'm confused what that "boot" command would actually do then... The only thing I can think that it might do is already covered by the "mmc" command's partition parameter. b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example). >>> >>> Access to partitions will be done differently. I assume that each >>> eMMC memory (the user accessible part) will be equipped with MBR or >>> GPT definition. >> >> That's a different kind of partition though. >> >> In general, there's no need for the eMMC device to contain any kind of >> standardized SW-level partition table. On Tegra, the boot ROM can boot >> directly from an eMMC device, and that requires raw data in the >> partitions, not a standardized SW partition table. >> >>> For this reason I'm now developing the USB Mass Storage (UMS) >>> gadget to export eMMC to host PC. >>> This solves the problem with accessing separate partitions. >> >> OK, if the raw eMMC device is exposed using USB storage, we should be >> able to dd directly to it and the presence-or-lack-thereof of any >> MBR/GPT wouldn't even be relevant. > > With the UMS you would see the whole mmc address space as one > partition. Then you can use dd with several parameters to "dump" data > to a specific LBA address. > > When correct MBR or GPT is present, then we can specify partitions to > be accessed. > >> It'd still be useful to have a linearized view of the flash that >> concatenated all the HW partitions into a single raw device, but I >> guess an alt setting for that probably could be added later. > > I think that UMS solves this issue. However, correct me if I'm wrong. > > Let's assume, that UMS causes host to see following partitions: > sde: sde1 sde2 sde3 sde4 < sde5 .. sdeN > > > Is the "mount -t vfat /dev/sde /mnt" not allowing access to the whole > eMMC device (despite of the partitions)? Again, this is confusing two different kinds of partitions. There are HW-level partitions/regions/areas within the eMMC HW itself. You need to send commands to the eMMC device to select whether read/write commands act on the boot0/boot1/general*/user HW partition. There are (or can be) SW-level partitions within any/all of those HW partitions. This is the level at which an MBR/GPT partition would exist. With DFU, I'd expect an alt setting for each of the HW partitions at least. With UMS, I'd expect a device to appear for each of the HW partitions. (these may show up as say /dev/sdb for boot0, /dev/sdc for boot1, /dev/sdd for the user area). If an MBR/GPT is present within any of those, Linux may then create a device for each SW partition, so e.g. /dev/sdd1, /dev/sdd2, etc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] config: Always use GNU ld
From: Khem Raj This patch makes sure that we always use the GNU ld. U-Boot uses certain construct e.g. OVERLAY which are not implemented in gold therefore it always needs GNU ld for linking. It works well if default linker in toolchain is GNU ld but in some cases we can have gold to be the default linker and also ship GNU ld but not as default in such cases its called $(PREFIX)ld.bfd, with this patch we make sure that if $(PREFIX)ld.bfd exists than we use that for our ld. This way it does not matter what the default ld is. Signed-off-by: Otavio Salvador Signed-off-by: Khem Raj --- config.mk |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/config.mk b/config.mk index 3dcea6a..c3822a2 100644 --- a/config.mk +++ b/config.mk @@ -133,7 +133,11 @@ cc-version = $(shell $(SHELL) $(SRCTREE)/tools/gcc-version.sh $(CC)) # Include the make variables (CC, etc...) # AS = $(CROSS_COMPILE)as -LD = $(CROSS_COMPILE)ld + +# Always use GNU ld +LD = $(shell if $(CROSS_COMPILE)ld.bfd -v > /dev/null 2>&1; \ + then echo "$(CROSS_COMPILE)ld.bfd"; else echo "$(CROSS_COMPILE)ld"; fi;) + CC = $(CROSS_COMPILE)gcc CPP= $(CC) -E AR = $(CROSS_COMPILE)ar -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging the pogo_e02 and sheevaplug code
> -Original Message- > From: Karl O. Pinc [mailto:k...@meme.com] > Sent: 01 August 2012 21:13 > To: u-boot@lists.denx.de; david.c.pu...@gmail.com; Prafulla Wadaskar > Subject: Merging the pogo_e02 and sheevaplug code > > Hi, > > I'm looking at possibly merging the pogo_e02 and sheevaplug code > and have some general questions before doing anything. > > The pogoplug POGO-E02 (pogo_e02 target) and the sheevaplug (sheevaplug > development kit) (sheevaplug target) board are very similar. > They are arm (Marvell) kirkwood boards. > The sheevaplug has 1G of ram the pogo_e02 has 256M. > Code-wise, the two boards have slightly different > kwbimage.cfg files. There is something going on in the > kwmpp_config[] array, the current pogo_e02 code omits a lot > of elements of this array that are present in the sheevaplug > but are otherwise identical. I can look into this myself > unless someone wants to hand me a clue. Finally, there's > the board initialization: board_init(void). The > sheevaplug has > gd->bd->bi_arch_number = MACH_TYPE_SHEEVAPLUG; > wheras the pogo_e02 does something different > gd->bd->bi_boot_params = kw_sdram_bar(0) + 0x100; There are several other custom boards which are clone of sheevaplug and u-boot image works as it is for them. Does sheevaplug u-boot image boots as it is on pogo-plug_e02? Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] tools, config.mk: add binutils-version
On Wed, Aug 01, 2012 at 04:01:41PM -0700, Mike Frysinger wrote:
> On Wednesday 01 August 2012 18:46:18 Allen Martin wrote:
> > But maybe I'll rewrite it in prolog just to mess with you guys
>
> i'd ack it if it were written in bf
> -mike
>
Challenge accepted
#!/bin/sh
#
# binutils-version [-p] gas-command
#
# Prints the binutils version of `gas-command' in a canonical 4-digit
#form
# such as `0222' for binutils 2.22
#
gas="$*"
if [ ${#gas} -eq 0 ]; then
echo "Error: No assembler specified."
printf "Usage:\n\t$0 \n"
exit 1
fi
tmp=$(mktemp)
echo '>>[<>-]>>+[>+<-]>+>,[>>[<>-]>>+[>\
+<-]>+>,]<<[<<]>>[<[<+>-]>[<<-<+>>>-]<<<[>>>+<<<-]>[>+<[-]]\
]<<[<<]>[>>]>[-]<[-]++[><-]>.>>\
..>>.' > $tmp
$gas --version | bf -n $tmp
rm $tmp
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] image/FIT: Add ramdisk load, entry address and OS tag inclusion
Any point to consider this..or we have any solution that may not require
this change?
Regards,
Jagan.
On Sat, Jul 28, 2012 at 1:32 PM, Jagan <402ja...@gmail.com> wrote:
> From: Jagannadha Sutradharudu Teki <402ja...@gmail.com>
>
> This patch adds support to include Load, Entry address and OS tag
> of ramdisk on to FIT image through mkimage tool.
>
> Signed-off-by: Jagannadha Sutradharudu Teki <402ja...@gmail.com>
> ---
> common/image.c |7 ---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/common/image.c b/common/image.c
> index 91954ac..70a112d 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -2042,13 +2042,13 @@ void fit_image_print(const void *fit, int
> image_noffset, const char *p)
> printf("%s Architecture: %s\n", p,
> genimg_get_arch_name(arch));
> }
>
> - if (type == IH_TYPE_KERNEL) {
> + if ((type == IH_TYPE_KERNEL) || (type == IH_TYPE_RAMDISK)) {
> fit_image_get_os(fit, image_noffset, &os);
> printf("%s OS: %s\n", p,
> genimg_get_os_name(os));
> }
>
> if ((type == IH_TYPE_KERNEL) || (type == IH_TYPE_STANDALONE) ||
> - (type == IH_TYPE_FIRMWARE)) {
> + (type == IH_TYPE_FIRMWARE) || (type == IH_TYPE_RAMDISK)) {
> ret = fit_image_get_load(fit, image_noffset, &load);
> printf("%s Load Address: ", p);
> if (ret)
> @@ -2057,7 +2057,8 @@ void fit_image_print(const void *fit, int
> image_noffset, const char *p)
> printf("0x%08lx\n", load);
> }
>
> - if ((type == IH_TYPE_KERNEL) || (type == IH_TYPE_STANDALONE)) {
> + if ((type == IH_TYPE_KERNEL) || (type == IH_TYPE_STANDALONE) ||
> + (type == IH_TYPE_RAMDISK)) {
> fit_image_get_entry(fit, image_noffset, &entry);
> printf("%s Entry Point: ", p);
> if (ret)
> --
> 1.7.0.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging the pogo_e02 and sheevaplug code
On 08/02/2012 12:10:28 PM, Prafulla Wadaskar wrote: > > > > -Original Message- > > From: Karl O. Pinc [mailto:k...@meme.com] > > Sent: 01 August 2012 21:13 > > To: u-boot@lists.denx.de; david.c.pu...@gmail.com; Prafulla > Wadaskar > > Subject: Merging the pogo_e02 and sheevaplug code > > > > Hi, > > > > I'm looking at possibly merging the pogo_e02 and sheevaplug code > > and have some general questions before doing anything. > > > > The pogoplug POGO-E02 (pogo_e02 target) and the sheevaplug > (sheevaplug > > development kit) (sheevaplug target) board are very similar. > > They are arm (Marvell) kirkwood boards. > > The sheevaplug has 1G of ram the pogo_e02 has 256M. > > Code-wise, the two boards have slightly different > > kwbimage.cfg files. There is something going on in the > > kwmpp_config[] array, the current pogo_e02 code omits a lot > > of elements of this array that are present in the sheevaplug > > but are otherwise identical. I can look into this myself > > unless someone wants to hand me a clue. Finally, there's > > the board initialization: board_init(void). The > > sheevaplug has > > gd->bd->bi_arch_number = MACH_TYPE_SHEEVAPLUG; > > wheras the pogo_e02 does something different > > gd->bd->bi_boot_params = kw_sdram_bar(0) + 0x100; > > There are several other custom boards which are clone of sheevaplug > and u-boot image works as it is for them. > > Does sheevaplug u-boot image boots as it is on pogo-plug_e02? I'm afraid to try it. I don't have any jtag hardware. (If you know of any that will work on Linux for a 10-pin jtag (probably for OpenOCD -- something on Debian would be helpful, that will support the cpu). One reason I'm afraid is that the kwbimage.cfg file from the factory is different from the stock sheevaplug kwbimage.cfg. (It also seems to be different from the kwbimage.cfg in the current pogo_e02 target.) FYI, the "example" patch I sent here: http://lists.denx.de/pipermail/u-boot/2012-July/129182.html includes the kwbimage.cfg file I've verified against the factory pogo_e02 values -- except that my file includes DATA 0xFFD01500 0x# CS[0]n Base address to 0x0 which was not in the original but is in the sheevaplug's kwbimage.cfg file. It seemed a good idea to add this. The main point of the "example patch" was to use a different kwbimage.cfg file while retaining the rest of the sheevaplug code. Thanks for the help. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
On Thursday 02 August 2012 03:16:18 Marek Vasut wrote: > Dear Mike Frysinger, > > > On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote: > > > --- /dev/null > > > +++ b/common/cmd_dfu.c > > > > > > + static char *s = "dfu"; > > > > no need for this to be static > > It can be pulled out of the function and be made into const static err, there's no point. the static markings here are for the pointer "s", not the stuff it's pointing to "dfu". use: char s[] = "dfu"; and it'll probably all optimize away correctly -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: Always use GNU ld
On Thursday 02 August 2012 12:19:34 Otavio Salvador wrote: > This patch makes sure that we always use the GNU ld. U-Boot uses certain > construct e.g. OVERLAY which are not implemented in gold therefore it > always needs GNU ld for linking. > > It works well if default linker in toolchain is GNU ld but in some > cases we can have gold to be the default linker and also ship GNU ld > but not as default in such cases its called $(PREFIX)ld.bfd, with this > patch we make sure that if $(PREFIX)ld.bfd exists than we use that for > our ld. > > This way it does not matter what the default ld is. Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Testing report for i.MX51 using Linaro/Ubuntu gcc 4.6.3 (from Precise repositories), libgcc, etc.
Marek Vasut insists I report this to the list, so here goes; Compiling a U-Boot for i.MX51 here (for the Efika MX) basically doesn't operate well. Among other things, we got data aborts in several places, most annoyingly sometime after boot_relocate_fdt. This was using a 64-bit Ubuntu Precise Pangolin (12.04) installation, the standard "arm-linux-gnueabi-gcc-4.6" (4.6.3-1ubuntu5) compiler and other toolchain components (no modifications made). Using USE_PRIVATE_LIBGCC=yes solved the issues, as did changing to the gcc 4.4.7 (4.4.7-1ubuntu2) and using either private libgcc or the one provided by the toolchain. This is not the first problem we've ever had with the Linaro gcc toolchain, especially not with 4.6. So far, reverting to building using gcc 4.4.7 has solved all the problems, and we're using USE_PRIVATE_LIBGCC by default now anyway because I don't see the point in using the one provided with the toolchain if it is such a huge unknown and U-Boot provides a compatible feature anyway. I'm not sure what anyone on the list is going to make of this or if it influences some design decisions anywhere else in U-Boot, just that I was nagged incessantly to "report my findings" - we all knew the Linaro compiler generally sucks already, though, right? -- Matt Sealey Product Development Analyst, Genesi USA, Inc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] GPIO: Extend the cmd_gpio API by gpio_{from, to}_string()
On Thursday 02 August 2012 06:05:14 Marek Vasut wrote: > Dear Mike Frysinger, > > > On Monday 14 May 2012 07:31:35 Marek Vasut wrote: > > > Dear Mike Frysinger, > > > > > > > On Tuesday 01 May 2012 16:50:14 Marek Vasut wrote: > > > > > The gpio_from_string() call shall parse the incoming GPIO name > > > > > taken from the command line and return the GPIO number used within > > > > > U-Boot or return -1 on error. > > > > > > > > i.e. the already existing name_to_gpio() func > > > > > > You mean blackfin specific macro crap? Let's actually drop that and > > > switch over to this one. That was my intention from start. > > > > don't spout this crap. try reading the actual history on the lists for > > the background on the naming, and then try actually grepping the tree to > > see that multiple targets implement it. > > So ... it was chosen to be compatible with linux gpio api, that's what I > understood ... so I grepped the kernel source: > > linux-2.6# git grep name_to_gpio drivers/gpio/ > linux-2.6# git grep name_to_gpio include/ > linux-2.6# git grep gpio_to_name include/ > linux-2.6# git grep gpio_to_name drivers/gpio/ > > Nothing. the naming convention is inline with the linux naming convention. there is no concept in linux of stringifying a GPIO number. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] PPC temac phy probe unsigned int underflow fix.
Signed-off-by: hpey...@beer.org (Herb Peyerl)
Apologies for the non-git formatted drive-by patch.
If, during phy detection, your phy does not respond, then
ll_temac_phy_addr() will underflow due to the declaration of local
variable 'phy' as an unsigned int.
--- drivers/net/xilinx_ll_temac_mdio.c 11 Jul 2012 00:52:14 -
1.1.1.1
+++ drivers/net/xilinx_ll_temac_mdio.c 2 Aug 2012 16:23:48 -
@@ -137,7 +137,7 @@
{
struct temac_reg *regs = (struct temac_reg *)bus->priv;
unsigned short val;
- unsigned int phy;
+ int phy;
for (phy = PHY_MAX_ADDR; phy >= 0; phy--) {
val = ll_temac_local_mdio_read(regs, phy, 0,
PHY_DETECT_REG);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/17] am335x_evm: Update config for common usage
On Mon, Jul 30, 2012 at 09:48:48AM -0700, Tom Rini wrote: > - Add default commands > - Add HUSH parser > - Make environment, malloc areas larger > - Add ATAGS and OF_LIBFDT > - Add defaults to boot ramdisk and MMC, use uEnv.txt > > Signed-off-by: Tom Rini I plan to commit this with the following minor addition: diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index e915f56..36f9152 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -48,6 +48,7 @@ #define CONFIG_BOOTDELAY 3 #define CONFIG_EXTRA_ENV_SETTINGS \ "loadaddr=0x8020\0" \ + "dtbaddr=0x80F8\0" \ "rdaddr=0x8100\0" \ "bootfile=/boot/uImage\0" \ "console=ttyO0,115200n8\0" \ This still leaves a ton of room between the kernel load and ramdisk/device tree, and sets aside as much room as the PowerPC boards have been. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] sf: stmicro: support JEDEC standard two-byte signature
There are more than the M25Pxx serial flashs that can be
used with the stmicro driver, for example: the M25PXxx or
N25Qxx serie. All these chips have burned in the original
stmicro manufacture id 0x20 together with a standard
two-byte signature.
In preperation to support all these chips the stmicro driver
have to decode the full two-byte signature.
Signed-off-by: Stephan Linz
---
v2: rebase to master sha1:56249fe
add local u16 variable to store idcode[1..2] for
computation and debug print out
---
drivers/mtd/spi/stmicro.c | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index dbd1fc1..706bb8e 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -37,7 +37,7 @@
#define CMD_M25PXX_RES 0xab/* Release from DP, and Read Signature
*/
struct stmicro_spi_flash_params {
- u8 idcode1;
+ u16 id;
u16 pages_per_sector;
u16 nr_sectors;
const char *name;
@@ -45,55 +45,55 @@ struct stmicro_spi_flash_params {
static const struct stmicro_spi_flash_params stmicro_spi_flash_table[] = {
{
- .idcode1 = 0x11,
+ .id = 0x2011,
.pages_per_sector = 128,
.nr_sectors = 4,
.name = "M25P10",
},
{
- .idcode1 = 0x15,
+ .id = 0x2015,
.pages_per_sector = 256,
.nr_sectors = 32,
.name = "M25P16",
},
{
- .idcode1 = 0x12,
+ .id = 0x2012,
.pages_per_sector = 256,
.nr_sectors = 4,
.name = "M25P20",
},
{
- .idcode1 = 0x16,
+ .id = 0x2016,
.pages_per_sector = 256,
.nr_sectors = 64,
.name = "M25P32",
},
{
- .idcode1 = 0x13,
+ .id = 0x2013,
.pages_per_sector = 256,
.nr_sectors = 8,
.name = "M25P40",
},
{
- .idcode1 = 0x17,
+ .id = 0x2017,
.pages_per_sector = 256,
.nr_sectors = 128,
.name = "M25P64",
},
{
- .idcode1 = 0x14,
+ .id = 0x2014,
.pages_per_sector = 256,
.nr_sectors = 16,
.name = "M25P80",
},
{
- .idcode1 = 0x18,
+ .id = 0x2018,
.pages_per_sector = 1024,
.nr_sectors = 64,
.name = "M25P128",
},
{
- .idcode1 = 0x19,
+ .id = 0xba19,
.pages_per_sector = 256,
.nr_sectors = 512,
.name = "N25Q256",
@@ -105,6 +105,7 @@ struct spi_flash *spi_flash_probe_stmicro(struct spi_slave
*spi, u8 * idcode)
const struct stmicro_spi_flash_params *params;
struct spi_flash *flash;
unsigned int i;
+ u16 id;
if (idcode[0] == 0xff) {
i = spi_flash_cmd(spi, CMD_M25PXX_RES,
@@ -119,15 +120,17 @@ struct spi_flash *spi_flash_probe_stmicro(struct
spi_slave *spi, u8 * idcode)
return NULL;
}
+ id = ((idcode[1] << 8) | idcode[2]);
+
for (i = 0; i < ARRAY_SIZE(stmicro_spi_flash_table); i++) {
params = &stmicro_spi_flash_table[i];
- if (params->idcode1 == idcode[2]) {
+ if (params->id == id) {
break;
}
}
if (i == ARRAY_SIZE(stmicro_spi_flash_table)) {
- debug("SF: Unsupported STMicro ID %02x\n", idcode[1]);
+ debug("SF: Unsupported STMicro ID %04x\n", id);
return NULL;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] sf: stmicro: add support N25Q128 parts
Adds support for Numonyx's N25Q128 SPI flash. These devices
are used on (among others) Avnet Spartan-6 LX9 micro-evaluation
boards. Tested with "sf" commands and CONFIG_ENV_IS_IN_SPI_FLASH.
Signed-off-by: Stephan Linz
---
v2: rebase to master sha1:56249fe
---
drivers/mtd/spi/stmicro.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 706bb8e..600e531 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -93,6 +93,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.name = "M25P128",
},
{
+ .id = 0xba18,
+ .pages_per_sector = 256,
+ .nr_sectors = 256,
+ .name = "N25Q128",
+ },
+ {
.id = 0xba19,
.pages_per_sector = 256,
.nr_sectors = 512,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] add more function in hello_world.c for standalone application
Dear Kassey Lee, In message you wrote: > > I've tried the examples/standalone/hello_world.c, it > works on my platform! Good. > but when i add more functions in > examples/standalone/hello_world.c, for example > it will take the test function as the entry, but ignore > the hello_world ? can i have more than one functions in a standalone > application C source code ? thanks You can have as many functions as you like, but there is usually only one entry point. Also, please pay attention on the documented, mandatory entry sequence (including using app_startup() ). > and what's more, can we use IRQ on arm platform for > standalone application that is already supported by u-boot? The infrastructure is in place, so it should be possible, but I think not all ARM systems actually implement interrupt support, so please checn the architecture specific code for your CPU. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de No journaling file system can recover your data if the disk dies. - Steve Rago in ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] tools, config.mk: add binutils-version
Dear Allen Martin, In message <20120802171230.gc7...@nvidia.com> you wrote: > > Challenge accepted ... > tmp=$(mktemp) > echo > '>>[<>-]>>+[>+<-]>+>,[>>[<>-]>>+[>\ > +<-]>+>,]<<[<<]>>[<[<+>-]>[<<-<+>>>-]<<<[>>>+<<<-]>[>+<[-]]\ > ]<<[<<]>[>>]>[-]<[-]++[><-]>.>>\ > ..>>.' > $tmp Thanks. Registered as entry # 1 for the IOUCC. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de On my planet, to rest is to rest -- to cease using energy. To me, it is quite illogical to run up and down on green grass, using energy, instead of saving it. -- Spock, "Shore Leave", stardate 3025.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Testing report for i.MX51 using Linaro/Ubuntu gcc 4.6.3 (from Precise repositories), libgcc, etc.
Dear Matt, In message you wrote: > Marek Vasut insists I report this to the list, so here goes; Indeed such problem reports are valuable information, so thanks for the message. > This is not the first problem we've ever had with the Linaro gcc > toolchain, especially not with 4.6. So far, reverting to building > using gcc 4.4.7 has solved all the problems, and we're using Did you report this to Linaro as well? Because this is where the people sit that should fix such issues. We can do nothing here - except to avoid such broken tool chains. > USE_PRIVATE_LIBGCC by default now anyway because I don't see the point > in using the one provided with the toolchain if it is such a huge > unknown and U-Boot provides a compatible feature anyway. Please do NOT do this by default. USE_PRIVATE_LIBGCC is meant as a workaround for known-to-be-broken tool chains for which no alternative exists. In your case you hcan chose a working tool chain, so please rather do this. By always using USE_PRIVATE_LIBGCC you just close your eyes for potential tool chain problems - why exactly would you trust in a tool chain where such a simple and fundamental piece of code asl ibgcc is broken? > I'm not sure what anyone on the list is going to make of this or if it > influences some design decisions anywhere else in U-Boot, just that I > was nagged incessantly to "report my findings" - we all knew the > Linaro compiler generally sucks already, though, right? Thanks for the report and the clear words; maybe you could send a similar report or a link to this posting to Linux, for example to Ramana Radhakrishnan ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "I'm not a god, I was misquoted." - Lister, Red Dwarf ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] input: key_matrix: fix header inclusion
On Microblaze with device tree support enabled we run into the error below. I'm not sure, but I think that all source code should include at least the common.h and just this fix the problem on Microblaz architecture. The error is: In file included from key_matrix.c:29: include/malloc.h:364: error: conflicting types for 'memset' include/linux/string.h:71: error: previous declaration of 'memset' was here include/malloc.h:365: error: conflicting types for 'memcpy' include/linux/string.h:74: error: previous declaration of 'memcpy' was here Signed-off-by: Stephan Linz CC: Bernie Thompson CC: Simon Glass CC: Tom Warren CC: Michal Simek --- drivers/input/key_matrix.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/input/key_matrix.c b/drivers/input/key_matrix.c index 84b898f..715e57a 100644 --- a/drivers/input/key_matrix.c +++ b/drivers/input/key_matrix.c @@ -23,6 +23,7 @@ * MA 02111-1307 USA */ +#include #include #include #include -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7 V4] SPI: Add W25Q32 to Winbond SPI flash table
On Thursday 02 August 2012 11:19:16 Mike Frysinger wrote: > On Thursday 02 August 2012 03:25:05 Rajeshwari Shinde wrote: > > SMDK EVT1 has a different Winbond part, added its part details > > to the SPI flash table > > thanks, merged in my sf branch actually, you didn't rebase it. half the fields in there no longer exist in master which is why i asked you to rebase it in the first place. at any rate, i fixed it for you now. please at least *compile* test your patches in the future. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] sf: stmicro: support JEDEC standard two-byte signature
On Thursday 02 August 2012 14:47:29 Stephan Linz wrote: > There are more than the M25Pxx serial flashs that can be > used with the stmicro driver, for example: the M25PXxx or > N25Qxx serie. All these chips have burned in the original > stmicro manufacture id 0x20 together with a standard > two-byte signature. > > In preperation to support all these chips the stmicro driver > have to decode the full two-byte signature. thanks, added both to my sf branch -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
Hi all, Apologies for the delay in response, I've been working on a high priority issue. On Thu, Jul 26, 2012 at 4:02 PM, Christian Riesch wrote: > Hi, > > > On Thursday, July 26, 2012, Aneesh V wrote: >> >> Hi Tyler, >> >> On 07/26/2012 11:54 AM, Tyler Olmstead wrote: >>> >>> Hi Christian, >>> >>> On Thu, Jul 26, 2012 at 10:03 AM, Christian Riesch >>> wrote: [cc'd Prabhakar Lad, Tom Rini, and Scott Wood] Tyler, On Thu, Jul 26, 2012 at 5:37 PM, Tyler Olmstead wrote: > > Hi all, > > I have encountered some issues adding a board-specific command to the > board file of a project I have been working on. Specifically, after > adding a U-Boot shell command to my board file, I have been seeing > link-stage failures when attempting to build SPL. It's hard to tell without having your code, but I think this problem was already discussed in [1]. However I do not remember how Prabhakar solved it in the end. >>> >>> >>> Yes, I ran into this thread while debugging the problem, which >>> ultimately lead me to my solution. From that same thread [1], Wolfgang >>> Denk writes: >>> >>> *I want to add a command using U_BOOT_CMD in uboot, where SPL_BUILD is enabled for example for da850evm in spl frame work how can i do that * >>> >>> >>> This makes no sense. Commands can only be executed when we have full >>> U-Boot running (actually even only after relocation). You cannot run >>> commands in the SPL. >>> >>> >>> I understand of course why it makes no sense to have command support >>> in the SPL. However, the crux of this problem is that U-Boot and SPL >>> both link in the same board object file, so in that sense compile-time >>> switches wont work. From later in [1], Scott Wood writes: >> >> >> No that's not correct. For SPL we build the object files into a >> different directory "spl/". Please see the below in spl/Makefile Yes, thank you for correcting me. Also, I had confused CONFIG_SPL and CONFIG_SPL_BUILD. >> >> # We want the final binaries in this directory >> obj := $(OBJTREE)/spl/ >> >> Object files used for U-Boot and SPL are not the same. You can use >> compile-time switches and it should work just fine. > > > Thanks for pointing that out, Aneesh. > > Therefore an #ifndef CONFIG_SPL_BUILD would work for Tyler's problem and I > think that it's also easier to read than some build magic that removes > u-boot commands. > > Christian > Yes, the #ifndef works perfectly for me. However, I also agree with your sentiment regarding build magic, which is why I wonder if removing the $GEN_UBOOT linker magic from the SPL makefile wouldn't be the best approach. If this was done, then my U-Boot command wouldn't have been linked into SPL in the first place, it wouldn't require any cluttering of #ifdef's, and would eliminate the potential of others encountering this same problem. This seems reasonable given that SPL shouldn't contain any command support. Thoughts? >> >> >> -Aneesh >> >> ___ >> 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 v2] Cosmetic doc typo fixes to the kwbimage feature docs
This is a resend of the first email I tried sending to the list. I don't believe the original email went through, probably due to my weak git skills. This fixes a few obvious typos in the kirkwood docs. Karl O. Pinc (1): Cosmetic doc typo fixes to the kwbimage feature docs board/Marvell/sheevaplug/kwbimage.cfg |4 ++-- doc/README.kwbimage |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- 1.7.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Cosmetic doc typo fixes to the kwbimage feature docs
Signed-off-by: Karl O. Pinc --- board/Marvell/sheevaplug/kwbimage.cfg |4 ++-- doc/README.kwbimage |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/board/Marvell/sheevaplug/kwbimage.cfg b/board/Marvell/sheevaplug/kwbimage.cfg index 3b9c53f..55be3a3 100644 --- a/board/Marvell/sheevaplug/kwbimage.cfg +++ b/board/Marvell/sheevaplug/kwbimage.cfg @@ -21,8 +21,8 @@ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, # MA 02110-1301 USA # -# Refer docs/README.kwimage for more details about how-to configure -# and create kirkwood boot image +# Refer to doc/README.kwbimage for more details about how-to +# configure and create kirkwood boot images. # # Boot Media configurations diff --git a/doc/README.kwbimage b/doc/README.kwbimage index 6dd942f..7f15e6d 100644 --- a/doc/README.kwbimage +++ b/doc/README.kwbimage @@ -25,7 +25,7 @@ for ex. -T kwbimage -a 0x0060 -e 0x0060 \ -d u-boot.bin u-boot.kwb -kwimage support available with mkimage utility will generate kirkwood boot +kwbimage support available with mkimage utility will generate kirkwood boot image that can be flashed on the board NAND/SPI flash Board specific configuration file specifications: -- 1.7.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cosmetic: Better explain how to use the kirkwood kwbimage.cfg file.
Hi, This adds to the documenation to explain how to use the kwbimage.cfg file necessary to generate an image with prefixed board setup values necessary for the kirkwood boards. Signed-off-by: Karl O. Pinc --- doc/README.kwbimage | 17 ++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/doc/README.kwbimage b/doc/README.kwbimage index 7f15e6d..e91c387 100644 --- a/doc/README.kwbimage +++ b/doc/README.kwbimage @@ -25,13 +25,24 @@ for ex. -T kwbimage -a 0x0060 -e 0x0060 \ -d u-boot.bin u-boot.kwb + kwbimage support available with mkimage utility will generate kirkwood boot -image that can be flashed on the board NAND/SPI flash +image that can be flashed on the board NAND/SPI flash. The make target +which uses mkimage to produce such an image is "u-boot.kwb". For example: + + export BUILD_DIR=/tmp/build + make distclean + make yourboard_config + make $BUILD_DIR/u-boot.kwb + Board specific configuration file specifications: -1. This file must present in the $(BOARDDIR) and the name should be - kwbimage.cfg (since this is used in Makefile) +1. This file must present in the $(BOARDDIR). The default name is + kwbimage.cfg. The name can be set as part of the full path +to the file using CONFIG_SYS_KWD_CONFIG (probably in +include/configs/.h). The path should look like: +$(SRCTREE)/$(CONFIG_BOARDDIR)/.cfg 2. This file can have empty lines and lines starting with "#" as first character to put comments 3. This file can have configuration command lines as mentioned below, -- 1.7.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cosmetic: Reference nand monitor commands in U-Boot README
Signed-off-by: Karl O. Pinc --- README |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/README b/README index fb9d904..6bb5992 100644 --- a/README +++ b/README @@ -3725,6 +3725,7 @@ saveenv - save environment variables to persistent storage protect - enable or disable FLASH write protection erase - erase FLASH memory flinfo - print FLASH memory information +nand - NAND memory operations (see doc/README.nand) bdinfo - print Board Info structure iminfo - print header information for application image coninfo - print console devices and informations -- 1.7.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] mmc: dw-mmc: add dw-mmc's confiuration at Makefile
Jaehoon, On 3 July 2012 16:58, Jaehoon Chung wrote: > Signed-off-by: Jaehoon Chung > Signed-off-by: Kyungmin Park > --- > drivers/mmc/Makefile |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) Need rebase this patch. > > diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile > index a8e681c..eccbf55 100644 > --- a/drivers/mmc/Makefile > +++ b/drivers/mmc/Makefile > @@ -43,6 +43,9 @@ COBJS-$(CONFIG_SDHCI) += sdhci.o > COBJS-$(CONFIG_S5P_SDHCI) += s5p_sdhci.o > COBJS-$(CONFIG_SH_MMCIF) += sh_mmcif.o > COBJS-$(CONFIG_TEGRA2_MMC) += tegra2_mmc.o > +COBJS-$(CONFIG_DWMMC) += dw_mmc.o > +COBJS-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o > + Please remove this space Thanks. Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] EXYNOS: mmc: support DesignWare Controller for Samsung-SoC
On 3 July 2012 16:58, Jaehoon Chung wrote:
> Support DesignWare MMC Controller for Samsung Specific.
>
> Signed-off-by: Jaehoon Chung
> Signed-off-by: Kyungmin Park
> Signed-off-by: Rajeshawari Shinde
> ---
> arch/arm/include/asm/arch-exynos/dwmmc.h | 36 ++
> drivers/mmc/exynos_dw_mmc.c | 58
> ++
> 2 files changed, 94 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/include/asm/arch-exynos/dwmmc.h
> create mode 100644 drivers/mmc/exynos_dw_mmc.c
>
> diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
> b/arch/arm/include/asm/arch-exynos/dwmmc.h
> new file mode 100644
> index 000..8acdf9b
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
> @@ -0,0 +1,36 @@
> +/*
> + * (C) Copyright 2012 SAMSUNG Electronics
> + * Jaehoon Chung
> + *
> + * 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
> + *
> + */
> +
> +#define DWMCI_CLKSEL 0x09C
> +#define DWMCI_SHIFT_0 0x0
> +#define DWMCI_SHIFT_1 0x1
> +#define DWMCI_SHIFT_2 0x2
> +#define DWMCI_SHIFT_3 0x3
> +#define DWMCI_SET_SAMPLE_CLK(x)(x)
> +#define DWMCI_SET_DRV_CLK(x) ((x) << 16)
> +#define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
> +
> +int exynos_dwmci_init(u32 regbase, int bus_width, int index);
> +
> +static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
> +{
> + unsigned int base = samsung_get_base_mmc() + (0x1 * index);
> + return exynos_dwmci_init(base, bus_width, index);
> +}
> diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
> new file mode 100644
> index 000..286a7df
> --- /dev/null
> +++ b/drivers/mmc/exynos_dw_mmc.c
> @@ -0,0 +1,58 @@
> +/*
> + * (C) Copyright 2012 SAMSUNG Electronics
> + * Jaehoon Chung
> + *
> + * 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
> +
> +static char *EXYNOS_NAME = "EXYNOS DWMMC";
> +
> +static void exynos_dwmci_clksel(struct dwmci_host *host)
> +{
> + u32 val;
> + val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
> + DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(0);
> +
> + dwmci_writel(host, DWMCI_CLKSEL, val);
> +}
> +
> +int exynos_dwmci_init(u32 regbase, int bus_width, int index)
> +{
> + struct dwmci_host *host = NULL;
> + host = (struct dwmci_host *)malloc(sizeof(struct dwmci_host));
> + if (!host) {
> + printf("dwmci_host malloc fail!\n");
> + return 1;
> + }
> +
> + host->name = EXYNOS_NAME;
> + host->ioaddr = (void *)regbase;
> + host->buswidth = bus_width;
> + host->clksel = exynos_dwmci_clksel;
> + host->dev_index = index;
> + host->mmc_clk = get_mmc_clk;
> +
> + add_dwmci(host, 5200, 40, index);
> +
> + return 0;
> +}
> +
remove this space.
Thanks.
Minkyu Kang.
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cosmetic doc typo fixes to the kwbimage feature docs
On 07/30/2012 01:36:07 AM, Prafulla Wadaskar wrote: > > > > -Original Message- > > From: u-boot-boun...@lists.denx.de [mailto:u-boot- > > boun...@lists.denx.de] On Behalf Of Karl O. Pinc > > Sent: 27 July 2012 20:23 > > To: u-boot@lists.denx.de > > Subject: Re: [U-Boot] Cosmetic doc typo fixes to the kwbimage > feature > > docs > > > > On 07/26/2012 11:15:32 PM, Karl O. Pinc wrote: > > > Hi, > > > > > > I'm looking into the kirkwood docs and found some typos. > > > > > > I'm not proficent in git. If there's a problem with my > > > git-age, or anything else, please let me know. > > > > I used git send-mail to send the above and it sent 2 > > emails (?), of which this was the first. The actual > > patch was the second email and it did not show up > > on this list, perhaps because this was my first > > post and needed moderation. > > > > Should I send the patch again? (Trivial stuff, > > but I've another doc fix waiting and wanted to > > get this right first.) > > You may send your v2 with this fix. Ok. Sent again. (FYI, the original patch never did make it to the mailing list but is sitting in patchwork.) Original version of the patch: http://patchwork.ozlabs.org/patch/173553/ (Still sitting there with a "New" status.) The only difference is that now there's a Signed-Off: line. FYI: I suspect I didn't thread it. And I've probably put my comments in the wrong place in all 3 of the patches I've sent so far. I think I see how it all works now, where to put the commit line, the longer commit description, and the comments. (I thought the commit line came out of the subject. Git put my commit line there, but apparently not in the right place in the message body.) Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/4] README: fix references to config_cmd_default.h
All usage of config_cmd_default.h uses <> for the include statement. Update the README to do the same, rather than using "". Signed-off-by: Stephen Warren --- v3: No change v2: New patch --- README |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README b/README index dac46f3..a7deaf4 100644 --- a/README +++ b/README @@ -744,8 +744,8 @@ The following options need to be configured: - Monitor Functions: Monitor commands can be included or excluded from the build by using the #include files - "config_cmd_all.h" and #undef'ing unwanted - commands, or using "config_cmd_default.h" +and #undef'ing unwanted + commands, or using and augmenting with additional #define's for wanted commands. -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/4] ARM: add basic support for the Broadcom BCM2835 SoC
This SoC is used in the Raspberry Pi, for example. For more details, see: http://www.broadcom.com/products/BCM2835 http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf. Initial support is enough to boot to a serial console, execute a minimal set of U-Boot commands, download data over a serial port, and boot a Linux kernel. No storage or network drivers are implemented. GPIO driver originally by Vikram Narayanan with many fixes from myself. Signed-off-by: Stephen Warren --- v3: Squash base SoC, watchdog, and GPIO driver patches into one. --- arch/arm/cpu/arm1176/bcm2835/Makefile| 37 +++ arch/arm/cpu/arm1176/bcm2835/config.mk | 19 ++ arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S | 19 ++ arch/arm/cpu/arm1176/bcm2835/reset.c | 35 ++ arch/arm/cpu/arm1176/bcm2835/timer.c | 55 arch/arm/include/asm/arch-bcm2835/gpio.h | 66 +++ arch/arm/include/asm/arch-bcm2835/timer.h| 37 +++ arch/arm/include/asm/arch-bcm2835/wdog.h | 37 +++ drivers/gpio/Makefile|1 + drivers/gpio/bcm2835_gpio.c | 90 ++ 10 files changed, 396 insertions(+) create mode 100644 arch/arm/cpu/arm1176/bcm2835/Makefile create mode 100644 arch/arm/cpu/arm1176/bcm2835/config.mk create mode 100644 arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S create mode 100644 arch/arm/cpu/arm1176/bcm2835/reset.c create mode 100644 arch/arm/cpu/arm1176/bcm2835/timer.c create mode 100644 arch/arm/include/asm/arch-bcm2835/gpio.h create mode 100644 arch/arm/include/asm/arch-bcm2835/timer.h create mode 100644 arch/arm/include/asm/arch-bcm2835/wdog.h create mode 100644 drivers/gpio/bcm2835_gpio.c diff --git a/arch/arm/cpu/arm1176/bcm2835/Makefile b/arch/arm/cpu/arm1176/bcm2835/Makefile new file mode 100644 index 000..4ea6d6b --- /dev/null +++ b/arch/arm/cpu/arm1176/bcm2835/Makefile @@ -0,0 +1,37 @@ +# +# 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 +# version 2 as published by the Free Software Foundation. +# +# 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. +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(SOC).o + +SOBJS := lowlevel_init.o +COBJS := reset.o timer.o + +SRCS := $(SOBJS:.o=.c) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) + +all: $(obj).depend $(LIB) + +$(LIB):$(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/arm/cpu/arm1176/bcm2835/config.mk b/arch/arm/cpu/arm1176/bcm2835/config.mk new file mode 100644 index 000..b87ce24 --- /dev/null +++ b/arch/arm/cpu/arm1176/bcm2835/config.mk @@ -0,0 +1,19 @@ +# +# (C) Copyright 2012 Stephen Warren +# +# 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 +# version 2 as published by the Free Software Foundation. +# +# 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. + +# Don't attempt to override the target CPU/ABI options; +# the Raspberry Pi toolchain does the right thing by default. +PLATFORM_RELFLAGS := $(filter-out -msoft-float,$(PLATFORM_RELFLAGS)) +PLATFORM_CPPFLAGS := $(filter-out -march=armv5t,$(PLATFORM_CPPFLAGS)) diff --git a/arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S b/arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S new file mode 100644 index 000..c7b0843 --- /dev/null +++ b/arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S @@ -0,0 +1,19 @@ +/* + * (C) Copyright 2012 Stephen Warren + * + * 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 + * version 2 as published by the Free Software Foundation. + * + * 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. + */ + +.globl lowlevel_init +lowlevel_init: + mov pc, lr diff -
[U-Boot] [PATCH V3 2/4] ARM: arm1176: enable instruction cache in arch_cpu_init()
Note that this affects all users of the ARM1176 CPU that enable
CONFIG_ARCH_CPU_INIT, not just the BCM2835 SoC, potentially such as
tnetv107x.
Cc: Cyril Chemparathy
Signed-off-by: Stephen Warren
---
v3: No change, re-ordered patch
v2: No change
---
arch/arm/cpu/arm1176/cpu.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/cpu/arm1176/cpu.c b/arch/arm/cpu/arm1176/cpu.c
index c0fd114..532a90b 100644
--- a/arch/arm/cpu/arm1176/cpu.c
+++ b/arch/arm/cpu/arm1176/cpu.c
@@ -65,3 +65,10 @@ static void cache_flush (void)
/* mem barrier to sync things */
asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (0));
}
+
+int arch_cpu_init(void)
+{
+ icache_enable();
+
+ return 0;
+}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 4/4] ARM: add Raspberry Pi model B board, using BCM2835 SoC
The Raspberry Pi model B uses the BCM2835 SoC, has 256MB of RAM,
contains an SMSC 9512 USB LAN/Hub chip, and various IO connectors.
For more details, see http://www.raspberrypi.org/.
Various portions (cache enable, MACH_TYPE setup, RAM size limit, stack
relocation to top of RAM) extracted from work by:
Oleksandr Tymoshenko .
GPIO driver enablement by Vikram Narayanan .
Signed-off-by: Stephen Warren
---
v3: Squash a number of patches into this single patch.
---
MAINTAINERS |4 ++
board/raspberrypi/rpi_b/Makefile | 34
board/raspberrypi/rpi_b/rpi_b.c | 34
boards.cfg |1 +
include/configs/rpi_b.h | 106 ++
5 files changed, 179 insertions(+)
create mode 100644 board/raspberrypi/rpi_b/Makefile
create mode 100644 board/raspberrypi/rpi_b/rpi_b.c
create mode 100644 include/configs/rpi_b.h
diff --git a/MAINTAINERS b/MAINTAINERS
index fd0c65c..abe621e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -928,6 +928,10 @@ Stephen Warren
trimslice Tegra2 (ARM7 & A9 Dual Core)
whistlerTegra2 (ARM7 & A9 Dual Core)
+Stephen Warren
+
+ rpi_b BCM2835 (ARM1176)
+
Thomas Weber
devkit8000 ARM ARMV7 (OMAP3530 SoC)
diff --git a/board/raspberrypi/rpi_b/Makefile b/board/raspberrypi/rpi_b/Makefile
new file mode 100644
index 000..9d0c377
--- /dev/null
+++ b/board/raspberrypi/rpi_b/Makefile
@@ -0,0 +1,34 @@
+#
+# 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
+# version 2 as published by the Free Software Foundation.
+#
+# 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.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := $(BOARD).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/raspberrypi/rpi_b/rpi_b.c b/board/raspberrypi/rpi_b/rpi_b.c
new file mode 100644
index 000..688b0aa
--- /dev/null
+++ b/board/raspberrypi/rpi_b/rpi_b.c
@@ -0,0 +1,34 @@
+/*
+ * (C) Copyright 2012 Stephen Warren
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int dram_init(void)
+{
+ gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
+
+ return 0;
+}
+
+int board_init(void)
+{
+ gd->bd->bi_boot_params = 0x100;
+
+ return 0;
+}
diff --git a/boards.cfg b/boards.cfg
index 2d36d83..7a88eb9 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -48,6 +48,7 @@ mx35pdk arm arm1136 -
freesca
apollon arm arm1136 apollon
- omap24xx
omap2420h4 arm arm1136 - ti
omap24xx
tnetv107x_evmarm arm1176 tnetv107xevmti
tnetv107x
+rpi_barm arm1176 rpi_b
raspberrypibcm2835
integratorap_cm720t arm arm720t integrator
armltd - integratorap:CM720T
integratorap_cm920t arm arm920t integrator
armltd - integratorap:CM920T
integratorcp_cm920t arm arm920t integrator
armltd - integratorcp:CM920T
diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h
new file mode 100644
index 000..5c91e7d
--- /dev/null
+++ b/include/configs/rpi_b.h
@@ -0,0 +1,106 @@
+/*
+ * (C) Copyright 2012 Stephen Warren
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distribut
Re: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
Dear Stephen Warren, > Again, this is confusing two different kinds of partitions. > > There are HW-level partitions/regions/areas within the eMMC HW itself. > You need to send commands to the eMMC device to select whether > read/write commands act on the boot0/boot1/general*/user HW partition. This will be done via "mmc boot [dev] [HW partition (boot0/1/user]" command (from u-boot prompt). This command is not yet implemented at u-boot (at least for Trats development board). After its implementation it will be used as a helper function for dfu. As a result the access to those partition will be done via proper DFU's alt settings: mmc-boot0 mmc-boot1 etc. > > There are (or can be) SW-level partitions within any/all of those HW > partitions. This is the level at which an MBR/GPT partition would > exist. > > With DFU, I'd expect an alt setting for each of the HW partitions at > least. And this is my goal. Now only the "user" HW partition is supported. After "mmc boot ..." command implementation support for other partitions will be added for DFU as well. > > With UMS, I'd expect a device to appear for each of the HW partitions. > (these may show up as say /dev/sdb for boot0, /dev/sdc for boot1, > /dev/sdd for the user area). Frankly speaking I've thought of providing access only to user HW partition for initial UMS implementation (the UMS v1 implementation). However access to all HW partitions from UMS is worth consideration. > If an MBR/GPT is present within any of > those, Linux may then create a device for each SW partition, so e.g. > /dev/sdd1, /dev/sdd2, etc. This is the functionality which now UMS (v1) provides. -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cosmetic: Better explain how to use the kirkwood kwbimage.cfg file.
> -Original Message- > From: Karl O. Pinc [mailto:k...@meme.com] > Sent: 03 August 2012 08:22 > To: Prafulla Wadaskar; u-boot@lists.denx.de > Cc: Karl O. Pinc > Subject: [PATCH] cosmetic: Better explain how to use the kirkwood > kwbimage.cfg file. > > Hi, > > This adds to the documenation to explain how to use the > kwbimage.cfg file necessary to generate an image with > prefixed board setup values necessary for the kirkwood > boards. > > Signed-off-by: Karl O. Pinc > --- > doc/README.kwbimage | 17 ++--- > 1 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/doc/README.kwbimage b/doc/README.kwbimage > index 7f15e6d..e91c387 100644 > --- a/doc/README.kwbimage > +++ b/doc/README.kwbimage > @@ -25,13 +25,24 @@ for ex. > -T kwbimage -a 0x0060 -e 0x0060 \ > -d u-boot.bin u-boot.kwb > > + > kwbimage support available with mkimage utility will generate > kirkwood boot > -image that can be flashed on the board NAND/SPI flash > +image that can be flashed on the board NAND/SPI flash. The make > target > +which uses mkimage to produce such an image is "u-boot.kwb". For > example: > + > + export BUILD_DIR=/tmp/build > + make distclean > + make yourboard_config > + make $BUILD_DIR/u-boot.kwb > + > > Board specific configuration file specifications: > > -1. This file must present in the $(BOARDDIR) and the name should be > - kwbimage.cfg (since this is used in Makefile) > +1. This file must present in the $(BOARDDIR). The default name is > + kwbimage.cfg. The name can be set as part of the full path > +to the file using CONFIG_SYS_KWD_CONFIG (probably in > +include/configs/.h). The path should look like: > +$(SRCTREE)/$(CONFIG_BOARDDIR)/.cfg > 2. This file can have empty lines and lines starting with "#" as > first > character to put comments > 3. This file can have configuration command lines as mentioned below, > -- Acked by: Prafulla Wadaskar I will pull this patch latter. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Cosmetic doc typo fixes to the kwbimage feature docs
> -Original Message- > From: Karl O. Pinc [mailto:k...@meme.com] > Sent: 03 August 2012 07:40 > To: Prafulla Wadaskar; u-boot@lists.denx.de > Cc: Karl O. Pinc > Subject: [PATCH v2] Cosmetic doc typo fixes to the kwbimage feature > docs > > > Signed-off-by: Karl O. Pinc > --- > board/Marvell/sheevaplug/kwbimage.cfg |4 ++-- > doc/README.kwbimage |2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/board/Marvell/sheevaplug/kwbimage.cfg > b/board/Marvell/sheevaplug/kwbimage.cfg > index 3b9c53f..55be3a3 100644 > --- a/board/Marvell/sheevaplug/kwbimage.cfg > +++ b/board/Marvell/sheevaplug/kwbimage.cfg > @@ -21,8 +21,8 @@ > # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > # MA 02110-1301 USA > # > -# Refer docs/README.kwimage for more details about how-to configure > -# and create kirkwood boot image > +# Refer to doc/README.kwbimage for more details about how-to > +# configure and create kirkwood boot images. > # > > # Boot Media configurations > diff --git a/doc/README.kwbimage b/doc/README.kwbimage > index 6dd942f..7f15e6d 100644 > --- a/doc/README.kwbimage > +++ b/doc/README.kwbimage > @@ -25,7 +25,7 @@ for ex. > -T kwbimage -a 0x0060 -e 0x0060 \ > -d u-boot.bin u-boot.kwb > > -kwimage support available with mkimage utility will generate kirkwood > boot > +kwbimage support available with mkimage utility will generate > kirkwood boot > image that can be flashed on the board NAND/SPI flash > > Board specific configuration file specifications: Acked by: Prafulla Wadaskar Will pull this patch latter. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging the pogo_e02 and sheevaplug code
> -Original Message- > From: Karl O. Pinc [mailto:k...@meme.com] > Sent: 02 August 2012 23:07 > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; david.c.pu...@gmail.com > Subject: Re: Merging the pogo_e02 and sheevaplug code > > On 08/02/2012 12:10:28 PM, Prafulla Wadaskar wrote: > > > > > > > -Original Message- > > > From: Karl O. Pinc [mailto:k...@meme.com] > > > Sent: 01 August 2012 21:13 > > > To: u-boot@lists.denx.de; david.c.pu...@gmail.com; Prafulla > > Wadaskar > > > Subject: Merging the pogo_e02 and sheevaplug code > > > > > > Hi, > > > > > > I'm looking at possibly merging the pogo_e02 and sheevaplug code > > > and have some general questions before doing anything. > > > > > > The pogoplug POGO-E02 (pogo_e02 target) and the sheevaplug > > (sheevaplug > > > development kit) (sheevaplug target) board are very similar. > > > They are arm (Marvell) kirkwood boards. > > > The sheevaplug has 1G of ram the pogo_e02 has 256M. > > > Code-wise, the two boards have slightly different > > > kwbimage.cfg files. There is something going on in the > > > kwmpp_config[] array, the current pogo_e02 code omits a lot > > > of elements of this array that are present in the sheevaplug > > > but are otherwise identical. I can look into this myself > > > unless someone wants to hand me a clue. Finally, there's > > > the board initialization: board_init(void). The > > > sheevaplug has > > > gd->bd->bi_arch_number = MACH_TYPE_SHEEVAPLUG; > > > wheras the pogo_e02 does something different > > > gd->bd->bi_boot_params = kw_sdram_bar(0) + 0x100; > > > > There are several other custom boards which are clone of sheevaplug > > and u-boot image works as it is for them. > > > > Does sheevaplug u-boot image boots as it is on pogo-plug_e02? > > I'm afraid to try it. I don't have any jtag hardware. > (If you know of any that will work on Linux for a 10-pin > jtag (probably for OpenOCD -- something on Debian would > be helpful, that will support the cpu). > > One reason I'm afraid is that the kwbimage.cfg file from > the factory is different from the stock sheevaplug > kwbimage.cfg. (It also seems to be different from the > kwbimage.cfg in the current pogo_e02 target.) > > FYI, the "example" patch I sent here: > http://lists.denx.de/pipermail/u-boot/2012-July/129182.html > includes the kwbimage.cfg file I've verified against > the factory pogo_e02 values -- except that my file > includes > DATA 0xFFD01500 0x # CS[0]n Base address to 0x0 > which was not in the original but is in the > sheevaplug's kwbimage.cfg file. It seemed > a good idea to add this. > > The main point of the "example patch" > was to use a different kwbimage.cfg file > while retaining the rest of the sheevaplug > code. Hi Karl I think it is exactly opposite, you can reuse the sheevaplug kwbimage and if have your own code, or you can you sheevaplug source files as it is. This is the reason we introduced macro CONFIG_SYS_KWD_CONFIG Secondly your board is custom board and not sheevaplug, so modifying sheevaplug code for the same does not sound good. Still if it is one or two lines #ifdef change we can manage that instead of adding complete new board specific folder. To me it looks that you can u-boot with sheevaplug u-boot image, where as it may report wrong DRAM size, that can be fixed. Regards... Prafulla . . . > > Thanks for the help. > > Karl > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
