Re: [U-Boot] [PATCH 1/1] am33xx: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width
On 25/09/13 06:23, Pekon Gupta wrote: NAND driver needs to know bus-width of the connected NAND device, in order to perform proper I/O and initialize itself. Currently there is no CONFIG option to provide this information to NAND driver. - SPL NAND driver does not have framework to parse ONFI parameter page. - NAND drivers which cannot self initialize !defined(CONFIG_SYS_NAND_SELF_INIT) do not have any information about device bus-width during board_nand_init(), So, any device-width specific configurations are not possible there. - There should be some mechanism to pass device bus-width information for non-ONFI compliant devices. This patch (1) adds CONFIG_SYS_NAND_DEVICE_WIDTH which can take following value 16: NAND device with x16 bus-width 8: NAND device with x8 bus-width (2) removes GPMC_NAND_ECC_LP_x16_LAYOUT, as NAND layout is determined based on ecc-scheme and oobsize during initialization in board_nand_init(). Thus this config is redundant. Signed-off-by: Pekon Gupta pe...@ti.com snip diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 978bca7..c92cb2f 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -216,6 +216,7 @@ #ifdef CONFIG_NAND #define CONFIG_SYS_NAND_5_ADDR_CYCLE +#define CONFIG_SYS_NAND_DEVICE_WIDTH 8 This new setting ... #define CONFIG_SYS_NAND_BLOCK_SIZE 131072 #define CONFIG_SYS_NAND_PAGE_SIZE2048 #define CONFIG_SYS_NAND_OOBSIZE 64 @@ -366,7 +367,6 @@ /* NAND support */ #ifdef CONFIG_NAND #define CONFIG_CMD_NAND -#define GPMC_NAND_ECC_LP_x16_LAYOUT 1 ... does *not* match with what you're taking out here !! #if !defined(CONFIG_SPI_BOOT) !defined(CONFIG_NOR_BOOT) #define MTDIDS_DEFAULT nand0=omap2-nand.0 #define MTDPARTS_DEFAULT mtdparts=omap2-nand.0:128k(SPL), \ diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h index 1fd2508..0985221 100644 --- a/include/configs/am3517_crane.h +++ b/include/configs/am3517_crane.h @@ -269,7 +269,6 @@ #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE #define CONFIG_NAND_OMAP_GPMC -#define GPMC_NAND_ECC_LP_x16_LAYOUT 1 Same here ... #define CONFIG_ENV_IS_IN_NAND1 #define SMNAND_ENV_OFFSET0x26 /* environment starts here */ @@ -332,6 +331,7 @@ /* NAND boot config */ #define CONFIG_SYS_NAND_5_ADDR_CYCLE +#define CONFIG_SYS_NAND_DEVICE_WIDTH 8 ... !! #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE2048 #define CONFIG_SYS_NAND_OOBSIZE 64 diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 6500878..8593d44 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -263,7 +263,6 @@ #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE #define CONFIG_NAND_OMAP_GPMC -#define GPMC_NAND_ECC_LP_x16_LAYOUT 1 Again ... #define CONFIG_ENV_IS_IN_NAND1 #define SMNAND_ENV_OFFSET0x26 /* environment starts here */ @@ -326,6 +325,7 @@ /* NAND boot config */ #define CONFIG_SYS_NAND_5_ADDR_CYCLE +#define CONFIG_SYS_NAND_DEVICE_WIDTH 8 ... !! #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE2048 #define CONFIG_SYS_NAND_OOBSIZE 64 diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index bc5b66c..1e3dd0d 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -164,8 +164,6 @@ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ /* to access nand at */ /* CS0 */ -#define GPMC_NAND_ECC_LP_x8_LAYOUT - And here you don't specify the new setting at all. #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ /* devices */ /* Environment information */ snip There's several other instances of the same issue through the whole patch. Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/4] ARM: AM33xx: Move s_init to a common place
On 23/08/13 11:55, Mark Jackson wrote:
On 23/08/13 11:25, Lokesh Vutla wrote:
Hi Mark,
On Friday 23 August 2013 02:58 PM, Mark Jackson wrote:
On 30/07/13 06:18, Lokesh Vutla wrote:
From: Heiko Schocher h...@denx.de
s_init has the same outline for all the AM33xx based
board. So making it generic.
This also helps in addition of new Soc with minimal changes.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Heiko Schocher h...@denx.de
Signed-off-by: Tom Rini tr...@ti.com
snip
But this fails to boot. However, if I use the old ASM code:-
void enable_norboot_pin_mux(void)
{
asm(stmfd sp!, {r2 - r4});
asm(movw r4, #0x8A4);
asm(movw r3, #0x44E1);
asm(orrr4, r4, r3, lsl #16);
asm(movr2, #9);
asm(movr3, #8);
asm(gpmc_mux: str r2, [r4], #4);
asm(subs r3, r3, #1);
asm(bnegpmc_mux);
asm(ldmfd sp!, {r2 - r4});
}
This code writes 0x9 into 8 continuous registers starting from
0x44e108a4, this is what done in module_pin_mux norboot_pin_mux
except that it has 9 registers(i guess 9th register was added by mistake..:(
)
Correct me if I am wrong.
Not sure about the code, but it was introduced here:-
http://git.denx.de/?p=u-boot/u-boot-ti.git;a=commit;h=c5c7a7c32d552592ac49749e5c184c89bd50c098
So you are telling this is wrong but boots properly ?
Basically ... yes !!
Is there any update on this issue ?
I'm keen to get our board support files pushed through.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/4] ARM: AM33xx: Move s_init to a common place
On 30/07/13 06:18, Lokesh Vutla wrote:
From: Heiko Schocher h...@denx.de
s_init has the same outline for all the AM33xx based
board. So making it generic.
This also helps in addition of new Soc with minimal changes.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Heiko Schocher h...@denx.de
Signed-off-by: Tom Rini tr...@ti.com
snip
This patch introduces the following new function call ...
+void s_init(void)
+{
+ /*
+ * The ROM will only have set up sufficient pinmux to allow for the
+ * first 4KiB NOR to be read, we must finish doing what we know of
+ * the NOR mux in this space in order to continue.
+ */
+#ifdef CONFIG_NOR_BOOT
+ enable_norboot_pin_mux();
+#endif
... which replaces the old code ...
- /*
- * The ROM will only have set up sufficient pinmux to allow for the
- * first 4KiB NOR to be read, we must finish doing what we know of
- * the NOR mux in this space in order to continue.
- */
-#ifdef CONFIG_NOR_BOOT
- asm(stmfd sp!, {r2 - r4});
- asm(movw r4, #0x8A4);
- asm(movw r3, #0x44E1);
- asm(orrr4, r4, r3, lsl #16);
- asm(movr2, #9);
- asm(movr3, #8);
- asm(gpmc_mux: str r2, [r4], #4);
- asm(subs r3, r3, #1);
- asm(bnegpmc_mux);
- asm(ldmfd sp!, {r2 - r4});
-#endif
Now (for the TI boards) enable_norboot_pin_mux() is defined as:-
+#if defined(CONFIG_NOR_BOOT)
+static struct module_pin_mux norboot_pin_mux[] = {
+ {OFFSET(lcd_data1), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data2), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data3), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data4), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data5), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data6), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data7), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data8), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data9), MODE(1) | PULLUDDIS},
+ {-1},
+};
+
+void enable_norboot_pin_mux(void)
+{
+ configure_module_pin_mux(norboot_pin_mux);
+}
+#endif
Firstly, this pinmux code seems wrong, since lcd_data pin map:-
lcd_data1 (mode 1) = gpmc_a1_mux1
lcd_data2 (mode 1) = gpmc_a2_mux1
lcd_data3 (mode 1) = gpmc_a3_mux1
lcd_data4 (mode 1) = gpmc_a4_mux1
lcd_data5 (mode 1) = gpmc_a5_mux1
lcd_data6 (mode 1) = gpmc_a6_mux1
lcd_data7 (mode 1) = gpmc_a7_mux1
lcd_data8 (mode 1) = gpmc_a12_mux1
lcd_data9 (mode 1) = gpmc_a13_mux1
Doesn't this leave gpmc_a[8..11] unconfigured ?
Shouldn't we configure lcd_vsync, lcd_hsync and lcd_pclk ?
Secondly, I've modded our Nanobone code to match this new setup, as follows:-
static struct module_pin_mux norboot_pin_mux[] = {
{OFFSET(lcd_data1), (MODE(1) | PULLUDDIS)}, /* GPMC A17 */
{OFFSET(lcd_data2), (MODE(1) | PULLUDDIS)}, /* GPMC A18 */
{OFFSET(lcd_data3), (MODE(1) | PULLUDDIS)}, /* GPMC A19 */
{OFFSET(lcd_data4), (MODE(1) | PULLUDDIS)}, /* GPMC A20 */
{OFFSET(lcd_data5), (MODE(1) | PULLUDDIS)}, /* GPMC A21 */
{OFFSET(lcd_data6), (MODE(1) | PULLUDDIS)}, /* GPMC A22 */
{OFFSET(lcd_data7), (MODE(1) | PULLUDDIS)}, /* GPMC A23 */
{OFFSET(lcd_vsync), (MODE(1) | PULLUDDIS)}, /* GPMC A24 */
{OFFSET(lcd_hsync), (MODE(1) | PULLUDDIS)}, /* GPMC A25 */
{OFFSET(lcd_pclk), (MODE(1) | PULLUDDIS)}, /* GPMC A26 */
{-1},
};
void enable_norboot_pin_mux(void)
{
configure_module_pin_mux(norboot_pin_mux);
}
But this fails to boot. However, if I use the old ASM code:-
void enable_norboot_pin_mux(void)
{
asm(stmfd sp!, {r2 - r4});
asm(movw r4, #0x8A4);
asm(movw r3, #0x44E1);
asm(orrr4, r4, r3, lsl #16);
asm(movr2, #9);
asm(movr3, #8);
asm(gpmc_mux: str r2, [r4], #4);
asm(subs r3, r3, #1);
asm(bnegpmc_mux);
asm(ldmfd sp!, {r2 - r4});
}
... this now boots correctly !!
Anyone care to comment ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/4] ARM: AM33xx: Move s_init to a common place
On 23/08/13 11:25, Lokesh Vutla wrote:
Hi Mark,
On Friday 23 August 2013 02:58 PM, Mark Jackson wrote:
On 30/07/13 06:18, Lokesh Vutla wrote:
From: Heiko Schocher h...@denx.de
s_init has the same outline for all the AM33xx based
board. So making it generic.
This also helps in addition of new Soc with minimal changes.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Heiko Schocher h...@denx.de
Signed-off-by: Tom Rini tr...@ti.com
snip
But this fails to boot. However, if I use the old ASM code:-
void enable_norboot_pin_mux(void)
{
asm(stmfd sp!, {r2 - r4});
asm(movw r4, #0x8A4);
asm(movw r3, #0x44E1);
asm(orrr4, r4, r3, lsl #16);
asm(movr2, #9);
asm(movr3, #8);
asm(gpmc_mux: str r2, [r4], #4);
asm(subs r3, r3, #1);
asm(bnegpmc_mux);
asm(ldmfd sp!, {r2 - r4});
}
This code writes 0x9 into 8 continuous registers starting from
0x44e108a4, this is what done in module_pin_mux norboot_pin_mux
except that it has 9 registers(i guess 9th register was added by mistake..:( )
Correct me if I am wrong.
Not sure about the code, but it was introduced here:-
http://git.denx.de/?p=u-boot/u-boot-ti.git;a=commit;h=c5c7a7c32d552592ac49749e5c184c89bd50c098
So you are telling this is wrong but boots properly ?
Basically ... yes !!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Add Nanobone board support
On 14/08/13 10:24, Mark Jackson wrote: NanoBone Specification: --- CPU: TI AM335x Memory: 256MB DDR3 64MB NOR flash 256MB NAND flash 128KB FRAM Ethernet: 2 x 10/100 connected to SMSC LAN8710 PHY USB: 1 x USB2.0 Type A I2C: 2Kbit EEPROM (Microchip 24AA02) RTC (Maxim DS1338) GPIO Expander (Microchip MCP23017) Expansion connector: 6 x UART 1 x MMC/SD 1 x USB2.0 Signed-off-by: Mark Jackson m...@newflow.co.uk Any comments on this board support patch ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/4] ARM: AM33xx: Move s_init to a common place
On 30/07/13 08:34, Heiko Schocher wrote: Hello Lokesh, Am 30.07.2013 07:18, schrieb Lokesh Vutla: From: Heiko Schocherh...@denx.de s_init has the same outline for all the AM33xx based board. So making it generic. This also helps in addition of new Soc with minimal changes. There's a new function now defined ... void enable_norboot_pin_mux(void) ... but our board *always* boots via NOR. All the required pinmux config is handled by enable_board_pin_mux(). Should I just define this an empty function ? Or should it be a maybe unused function ? Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] Add Nanobone board support
NanoBone Specification:
---
CPU:
TI AM335x
Memory:
256MB DDR3
64MB NOR flash
256MB NAND flash
128KB FRAM
Ethernet:
2 x 10/100 connected to SMSC LAN8710 PHY
USB:
1 x USB2.0 Type A
I2C:
2Kbit EEPROM (Microchip 24AA02)
RTC (Maxim DS1338)
GPIO Expander (Microchip MCP23017)
Expansion connector:
6 x UART
1 x MMC/SD
1 x USB2.0
Signed-off-by: Mark Jackson m...@newflow.co.uk
---
Changes in v4:
- Tweaked after comments from Tom Rini
- LEDs now initialised
Changes in v3:
- Rebased on TI U-Boot
Changes in v2:
- Tweaked after comments from Tom Rini
MAINTAINERS |4 +
board/newflow/nanobone/Makefile | 38 +
board/newflow/nanobone/board.c| 298 +
board/newflow/nanobone/mux.c | 195
board/newflow/nanobone/u-boot.lds | 98
boards.cfg|2 +
include/configs/nanobone.h| 295
7 files changed, 930 insertions(+)
create mode 100644 board/newflow/nanobone/Makefile
create mode 100644 board/newflow/nanobone/board.c
create mode 100644 board/newflow/nanobone/mux.c
create mode 100644 board/newflow/nanobone/u-boot.lds
create mode 100644 include/configs/nanobone.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 081cf96..4f44e8f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -717,6 +717,10 @@ Ilko Iliev il...@ronetix.at
PM9263 AT91SAM9263
PM9G45 ARM926EJS (AT91SAM9G45 SoC)
+Mark Jackson m...@newflow.co.uk
+
+ NANOBONEARM ARMV7 (AM33xx Soc)
+
Michael Jones michael.jo...@matrix-vision.de
omap3_mvblx ARM ARMV7 (OMAP3xx SoC)
diff --git a/board/newflow/nanobone/Makefile b/board/newflow/nanobone/Makefile
new file mode 100644
index 000..3dbeeda
--- /dev/null
+++ b/board/newflow/nanobone/Makefile
@@ -0,0 +1,38 @@
+#
+# Makefile
+#
+# Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_NOR_BOOT),y)
+COBJS := mux.o
+endif
+
+COBJS += board.o
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/newflow/nanobone/board.c b/board/newflow/nanobone/board.c
new file mode 100644
index 000..743454b
--- /dev/null
+++ b/board/newflow/nanobone/board.c
@@ -0,0 +1,298 @@
+/*
+ * board.c
+ *
+ * Board functions for Newflow NanoBone board
+ *
+ * Copyright (C) 2013, Newflow Ltd - http://www.newflow.co.uk/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include errno.h
+#include spl.h
+#include asm/arch/cpu.h
+#include asm/arch/hardware.h
+#include asm/arch/omap.h
+#include asm/arch/ddr_defs.h
+#include asm/arch/clock.h
+#include asm/arch/gpio.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mem.h
+#include asm/io.h
+#include asm/emif.h
+#include asm/gpio.h
+#include i2c.h
+#include miiphy.h
+#include cpsw.h
+#include board.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* NOR Flash config */
+#define NOR_CS 0
+#define NOR_BASE 0x0800
+#define NOR_SIZE GPMC_SIZE_128M
+static u32 gpmc_nor_config[GPMC_MAX_REG] = {
+ 0x1200,
+ 0x00101000,
+ 0x00030301,
+ 0x10041004,
+ 0x010f1010,
+ 0x08070280,
+ 0
+};
+
+/* FRAM config */
+#define FRAM_CS1
+#define FRAM_BASE 0x1c00
+#define FRAM_SIZE GPMC_SIZE_16M
+static u32 gpmc_fram_config[GPMC_MAX_REG] = {
+ 0x1200,
+ 0x00101000,
+ 0x00020201,
+ 0x0f030f03,
+ 0x010d1010,
+ 0x000301c0,
+ 0
+};
+
+static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
+
+/* MII mode defines */
+#define PORT1_MII_MODE_ENABLE 0x0
+#define PORT2_MII_MODE_ENABLE 0x0
+
+static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
+
+#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
+static const struct ddr_data ddr3_data = {
+ .datardsratio0 = MT41J128MJT125_RD_DQS,
+ .datawdsratio0 = MT41J128MJT125_WR_DQS,
+ .datafwsratio0 = MT41J128MJT125_PHY_FIFO_WE,
+ .datawrsratio0 = MT41J128MJT125_PHY_WR_DATA,
+ .datadldiff0 = PHY_DLL_LOCK_DIFF,
+};
+
+static const struct cmd_control ddr3_cmd_ctrl_data = {
+ .cmd0csratio = MT41J128MJT125_RATIO,
+ .cmd0dldiff = MT41J128MJT125_DLL_LOCK_DIFF
Re: [U-Boot] [PATCH v4 0/8] am335x: NOR support
On 30/07/13 14:28, Tom Rini wrote:
On Thu, Jul 18, 2013 at 03:12:57PM -0400, Tom Rini wrote:
Hey all,
This series adds NOR support to am335x_evm, along with a few generic
changes to make gpmc clearer (for per-board things like different NOR
chips, etc). This series depends on the last go-round of the am335x
falcon mode docs as that adds the README that I add more content to.
And while I say this in 3/8, to be clear, I expect to drop 3/8 in favor
of Justin Waters' way of doing this instead, I just include this here for
completeness and will get it all happy together when I assemble things
in u-boot-ti.
The big changes in v4 are:
- Apply again to master which includes a few non-trivial updates, so the
linker script got re-synced.
- After checking what's going on, and testing with NAND again, we can be
common with gpmc_cfg-irqstatus/enable, and only set documented bits
in gpmc_cfg-config
Applied to u-boot-ti/master, thanks!
I'm now rebasing our NanoBone code onto the TI uboot code, but
I'm coming up with the original issue [1] of having to not check for
the R_ARM_RELATIVE relocations again.
If I patch config.mk again, the code all compiles.
I've tested make am335x_evm_norboot and that works.
I've attached my custom patchset ... can you tell me what I'm doing wrong ?
[1] http://lists.denx.de/pipermail/u-boot/2013-July/158592.html
Cheers
Mark J.
---
board/newflow/nanobone/Makefile | 38 +
board/newflow/nanobone/board.c| 295 +++
board/newflow/nanobone/mux.c | 195 +++
board/newflow/nanobone/u-boot.lds | 110 +
boards.cfg|2 +
include/configs/nanobone.h| 308 +
6 files changed, 948 insertions(+)
create mode 100644 board/newflow/nanobone/Makefile
create mode 100644 board/newflow/nanobone/board.c
create mode 100644 board/newflow/nanobone/mux.c
create mode 100644 board/newflow/nanobone/u-boot.lds
create mode 100644 include/configs/nanobone.h
diff --git a/board/newflow/nanobone/Makefile b/board/newflow/nanobone/Makefile
new file mode 100644
index 000..3dbeeda
--- /dev/null
+++ b/board/newflow/nanobone/Makefile
@@ -0,0 +1,38 @@
+#
+# Makefile
+#
+# Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_NOR_BOOT),y)
+COBJS := mux.o
+endif
+
+COBJS += board.o
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/newflow/nanobone/board.c b/board/newflow/nanobone/board.c
new file mode 100644
index 000..6ccda1b
--- /dev/null
+++ b/board/newflow/nanobone/board.c
@@ -0,0 +1,295 @@
+/*
+ * board.c
+ *
+ * Board functions for Newflow NanoBone board
+ *
+ * Copyright (C) 2013, Newflow Ltd - http://www.newflow.co.uk/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include errno.h
+#include spl.h
+#include asm/arch/cpu.h
+#include asm/arch/hardware.h
+#include asm/arch/omap.h
+#include asm/arch/ddr_defs.h
+#include asm/arch/clock.h
+#include asm/arch/gpio.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mem.h
+#include asm/io.h
+#include asm/emif.h
+#include asm/gpio.h
+#include i2c.h
+#include miiphy.h
+#include cpsw.h
+#include board.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* NOR Flash config */
+#define NOR_CS 0
+#define NOR_BASE 0x0800
+#define NOR_SIZE GPMC_SIZE_128M
+static u32 gpmc_nor_config[GPMC_MAX_REG] = {
+ 0x1200,
+ 0x00101000,
+ 0x00030301,
+ 0x10041004,
+ 0x010f1010,
+ 0x08070280,
+ 0
+};
+
+/* FRAM config */
+#define FRAM_CS1
+#define FRAM_BASE 0x1c00
+#define FRAM_SIZE GPMC_SIZE_16M
+static u32 gpmc_fram_config[GPMC_MAX_REG] = {
+ 0x1200,
+ 0x00101000,
+ 0x00020201,
+ 0x0f030f03,
+ 0x010d1010,
+ 0x000301c0,
+ 0
+};
+
+static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
+#if defined(CONFIG_SPL_BUILD) || (CONFIG_NOR_BOOT)
+//static struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
+#endif
+
+/* MII mode defines */
+#define PORT1_MII_MODE_ENABLE 0x0
+#define PORT2_MII_MODE_ENABLE 0x0
+
+static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
+
+#if defined(CONFIG_SPL_BUILD) ||
Re: [U-Boot] [PATCH v4 0/8] am335x: NOR support
On 13/08/13 16:00, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/13/2013 10:57 AM, Mark Jackson wrote: On 30/07/13 14:28, Tom Rini wrote: On Thu, Jul 18, 2013 at 03:12:57PM -0400, Tom Rini wrote: Hey all, This series adds NOR support to am335x_evm, along with a few generic changes to make gpmc clearer (for per-board things like different NOR chips, etc). This series depends on the last go-round of the am335x falcon mode docs as that adds the README that I add more content to. And while I say this in 3/8, to be clear, I expect to drop 3/8 in favor of Justin Waters' way of doing this instead, I just include this here for completeness and will get it all happy together when I assemble things in u-boot-ti. The big changes in v4 are: - Apply again to master which includes a few non-trivial updates, so the linker script got re-synced. - After checking what's going on, and testing with NAND again, we can be common with gpmc_cfg-irqstatus/enable, and only set documented bits in gpmc_cfg-config Applied to u-boot-ti/master, thanks! I'm now rebasing our NanoBone code onto the TI uboot code, but I'm coming up with the original issue [1] of having to not check for the R_ARM_RELATIVE relocations again. Your linker script is out of sync with arch/arm/cpu/u-boot.lds Strange ... since the am335x nor_boot compile appeared to work fine, I just copied the script from board/ti/am335x, and assumed it would work fine for me (with a library path change). So does this TI file also need updating ? Either way, my code now compiles. Cheers. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] am335x: NOR support
On 13/08/13 16:11, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/13/2013 11:06 AM, Mark Jackson wrote: On 13/08/13 16:00, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/13/2013 10:57 AM, Mark Jackson wrote: On 30/07/13 14:28, Tom Rini wrote: On Thu, Jul 18, 2013 at 03:12:57PM -0400, Tom Rini wrote: Hey all, This series adds NOR support to am335x_evm, along with a few generic changes to make gpmc clearer (for per-board things like different NOR chips, etc). This series depends on the last go-round of the am335x falcon mode docs as that adds the README that I add more content to. And while I say this in 3/8, to be clear, I expect to drop 3/8 in favor of Justin Waters' way of doing this instead, I just include this here for completeness and will get it all happy together when I assemble things in u-boot-ti. The big changes in v4 are: - Apply again to master which includes a few non-trivial updates, so the linker script got re-synced. - After checking what's going on, and testing with NAND again, we can be common with gpmc_cfg-irqstatus/enable, and only set documented bits in gpmc_cfg-config Applied to u-boot-ti/master, thanks! I'm now rebasing our NanoBone code onto the TI uboot code, but I'm coming up with the original issue [1] of having to not check for the R_ARM_RELATIVE relocations again. Your linker script is out of sync with arch/arm/cpu/u-boot.lds Strange ... since the am335x nor_boot compile appeared to work fine, I just copied the script from board/ti/am335x, and assumed it would work fine for me (with a library path change). So does this TI file also need updating ? Either way, my code now compiles. I had to re-sync the TI one in this series as well. Double check between what you have working now vs before, there's a few small changes there... Doh ... I was copying the script from the non-TI branch of uboot !! :-( ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] am335x: NOR support
On 13/08/13 16:20, Mark Jackson wrote: On 13/08/13 16:11, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/13/2013 11:06 AM, Mark Jackson wrote: On 13/08/13 16:00, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/13/2013 10:57 AM, Mark Jackson wrote: On 30/07/13 14:28, Tom Rini wrote: On Thu, Jul 18, 2013 at 03:12:57PM -0400, Tom Rini wrote: Hey all, This series adds NOR support to am335x_evm, along with a few generic changes to make gpmc clearer (for per-board things like different NOR chips, etc). This series depends on the last go-round of the am335x falcon mode docs as that adds the README that I add more content to. And while I say this in 3/8, to be clear, I expect to drop 3/8 in favor of Justin Waters' way of doing this instead, I just include this here for completeness and will get it all happy together when I assemble things in u-boot-ti. The big changes in v4 are: - Apply again to master which includes a few non-trivial updates, so the linker script got re-synced. - After checking what's going on, and testing with NAND again, we can be common with gpmc_cfg-irqstatus/enable, and only set documented bits in gpmc_cfg-config Applied to u-boot-ti/master, thanks! I'm now rebasing our NanoBone code onto the TI uboot code, but I'm coming up with the original issue [1] of having to not check for the R_ARM_RELATIVE relocations again. Your linker script is out of sync with arch/arm/cpu/u-boot.lds Strange ... since the am335x nor_boot compile appeared to work fine, I just copied the script from board/ti/am335x, and assumed it would work fine for me (with a library path change). So does this TI file also need updating ? Either way, my code now compiles. I had to re-sync the TI one in this series as well. Double check between what you have working now vs before, there's a few small changes there... Doh ... I was copying the script from the non-TI branch of uboot !! :-( Well the code seems to work apart from I get no networking. We have dual ethernet, so I'll have to do some digging. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Add Nanobone board support
NanoBone Specification:
---
CPU:
TI AM335x
Memory:
256MB DDR3
64MB NOR flash
256MB NAND flash
128KB FRAM
Ethernet:
2 x 10/100 connected to SMSC LAN8710 PHY
USB:
1 x USB2.0 Type A
I2C:
2Kbit EEPROM (Microchip 24AA02)
RTC (Maxim DS1338)
GPIO Expander (Microchip MCP23017)
Expansion connector:
6 x UART
1 x MMC/SD
1 x USB2.0
Signed-off-by: Mark Jackson m...@newflow.co.uk
---
Changes in v3:
- Rebased on TI U-Boot
Changes in v2:
- Tweaked after comments from Tom Rini
MAINTAINERS |4 +
board/newflow/nanobone/Makefile | 38 +
board/newflow/nanobone/board.c| 296 +++
board/newflow/nanobone/mux.c | 195 +++
board/newflow/nanobone/u-boot.lds | 98
boards.cfg|2 +
include/configs/nanobone.h| 307 +
7 files changed, 940 insertions(+)
create mode 100644 board/newflow/nanobone/Makefile
create mode 100644 board/newflow/nanobone/board.c
create mode 100644 board/newflow/nanobone/mux.c
create mode 100644 board/newflow/nanobone/u-boot.lds
create mode 100644 include/configs/nanobone.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 081cf96..4f44e8f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -717,6 +717,10 @@ Ilko Iliev il...@ronetix.at
PM9263 AT91SAM9263
PM9G45 ARM926EJS (AT91SAM9G45 SoC)
+Mark Jackson m...@newflow.co.uk
+
+ NANOBONEARM ARMV7 (AM33xx Soc)
+
Michael Jones michael.jo...@matrix-vision.de
omap3_mvblx ARM ARMV7 (OMAP3xx SoC)
diff --git a/board/newflow/nanobone/Makefile b/board/newflow/nanobone/Makefile
new file mode 100644
index 000..3dbeeda
--- /dev/null
+++ b/board/newflow/nanobone/Makefile
@@ -0,0 +1,38 @@
+#
+# Makefile
+#
+# Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_NOR_BOOT),y)
+COBJS := mux.o
+endif
+
+COBJS += board.o
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/newflow/nanobone/board.c b/board/newflow/nanobone/board.c
new file mode 100644
index 000..2534516
--- /dev/null
+++ b/board/newflow/nanobone/board.c
@@ -0,0 +1,296 @@
+/*
+ * board.c
+ *
+ * Board functions for Newflow NanoBone board
+ *
+ * Copyright (C) 2013, Newflow Ltd - http://www.newflow.co.uk/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include errno.h
+#include spl.h
+#include asm/arch/cpu.h
+#include asm/arch/hardware.h
+#include asm/arch/omap.h
+#include asm/arch/ddr_defs.h
+#include asm/arch/clock.h
+#include asm/arch/gpio.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mem.h
+#include asm/io.h
+#include asm/emif.h
+#include asm/gpio.h
+#include i2c.h
+#include miiphy.h
+#include cpsw.h
+#include board.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* NOR Flash config */
+#define NOR_CS 0
+#define NOR_BASE 0x0800
+#define NOR_SIZE GPMC_SIZE_128M
+static u32 gpmc_nor_config[GPMC_MAX_REG] = {
+ 0x1200,
+ 0x00101000,
+ 0x00030301,
+ 0x10041004,
+ 0x010f1010,
+ 0x08070280,
+ 0
+};
+
+/* FRAM config */
+#define FRAM_CS1
+#define FRAM_BASE 0x1c00
+#define FRAM_SIZE GPMC_SIZE_16M
+static u32 gpmc_fram_config[GPMC_MAX_REG] = {
+ 0x1200,
+ 0x00101000,
+ 0x00020201,
+ 0x0f030f03,
+ 0x010d1010,
+ 0x000301c0,
+ 0
+};
+
+static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
+#if defined(CONFIG_SPL_BUILD) || (CONFIG_NOR_BOOT)
+//static struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
+#endif
+
+/* MII mode defines */
+#define PORT1_MII_MODE_ENABLE 0x0
+#define PORT2_MII_MODE_ENABLE 0x0
+
+static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
+
+#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
+static const struct ddr_data ddr3_data = {
+ .datardsratio0 = MT41J128MJT125_RD_DQS,
+ .datawdsratio0 = MT41J128MJT125_WR_DQS,
+ .datafwsratio0 = MT41J128MJT125_PHY_FIFO_WE,
+ .datawrsratio0 = MT41J128MJT125_PHY_WR_DATA,
+ .datadldiff0 = PHY_DLL_LOCK_DIFF,
+};
+
+static const struct cmd_control ddr3_cmd_ctrl_data = {
+ .cmd0csratio = MT41J128MJT125_RATIO
Re: [U-Boot] [PATCH v2] Add NanoBone board support
On 11/08/13 19:34, Tom Rini wrote: On Sun, Aug 11, 2013 at 09:31:00AM +0100, Mark Jackson wrote: On 22/04/13 13:46, Mark Jackson wrote: NanoBone Specification: --- CPU: TI AM335x Memory: 256MB DDR3 64MB NOR flash 256MB NAND flash 128KB FRAM Ethernet: 2 x 10/100 connected to SMSC LAN8710 PHY USB: 1 x USB2.0 Type A I2C: 2Kbit EEPROM (Microchip 24AA02) RTC (Maxim DS1338) GPIO Expander (Microchip MCP23017) Expansion connector: 6 x UART 1 x MMC/SD 1 x USB2.0 Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v2: - Tweaked after comments from Tom Rini MAINTAINERS |4 + board/newflow/nanobone/Makefile | 46 ++ board/newflow/nanobone/board.c | 304 +++ board/newflow/nanobone/board.h | 24 board/newflow/nanobone/mux.c| 203 ++ boards.cfg |1 + include/configs/nanobone.h | 285 7 files changed, 867 insertions(+) create mode 100644 board/newflow/nanobone/Makefile create mode 100644 board/newflow/nanobone/board.c create mode 100644 board/newflow/nanobone/board.h create mode 100644 board/newflow/nanobone/mux.c create mode 100644 include/configs/nanobone.h Any chance this board can be added ? I guess the email asking for you to re-send got lost, the copy in patchwork appears to be whitespace corrupted. Since you need to re-send anyhow (sorry) please update to use the SPDX tags now, thanks. Hmmm ... nope, never got that one !! I'll repost an updated patch. Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add NanoBone board support
On 22/04/13 13:46, Mark Jackson wrote: NanoBone Specification: --- CPU: TI AM335x Memory: 256MB DDR3 64MB NOR flash 256MB NAND flash 128KB FRAM Ethernet: 2 x 10/100 connected to SMSC LAN8710 PHY USB: 1 x USB2.0 Type A I2C: 2Kbit EEPROM (Microchip 24AA02) RTC (Maxim DS1338) GPIO Expander (Microchip MCP23017) Expansion connector: 6 x UART 1 x MMC/SD 1 x USB2.0 Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v2: - Tweaked after comments from Tom Rini MAINTAINERS |4 + board/newflow/nanobone/Makefile | 46 ++ board/newflow/nanobone/board.c | 304 +++ board/newflow/nanobone/board.h | 24 board/newflow/nanobone/mux.c| 203 ++ boards.cfg |1 + include/configs/nanobone.h | 285 7 files changed, 867 insertions(+) create mode 100644 board/newflow/nanobone/Makefile create mode 100644 board/newflow/nanobone/board.c create mode 100644 board/newflow/nanobone/board.h create mode 100644 board/newflow/nanobone/mux.c create mode 100644 include/configs/nanobone.h Any chance this board can be added ? Regards Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 11/07/13 14:06, Mark Jackson wrote: On 18/06/13 13:11, Mark Jackson wrote: On 17/06/13 15:43, Mark Jackson wrote: On 13/05/13 19:28, Tom Rini wrote: From: Steve Kipisz s-kipi...@ti.com NOR requires that s_init be within the first 4KiB of the image so that we can perform the rest of the required pinmuxing to talk with the rest of NOR that we are found on. When NOR_BOOT is set we save our environment in NOR at 512KiB and a redundant copy at 768KiB. We avoid using SPL for this case and u-boot.bin is written directly to the start of NOR. I'm trying to get this up and running our NanoBone platform, but I'm having no success. Just an update ... I now have it working ... yay !! The main (and possibly the *only*) culprit was that SYSBOOT[8] (which selects 8/16bit mode) was being incorrectly influenced by a hardware fault. I have pulled quite a few patches from various places, some of which might not be required. Now I have a working base, I'll work out what is needed on top of Tom's original patch set. Okay ... I've now got NOR booting rebased to master using the patch set below. This doesn't include my board code as that's of no interest until NOR booting is added to the mainline code. Sorry, Tom, I'm no git expert, so I'm not sure how to compare this to your previous patches ... I hope this is useful in some way ?? Tom ... any idea when NOR booting will be merged into the mainline code ? I'm keen to get our NanoBone board support added. Cheers Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 18/06/13 13:11, Mark Jackson wrote:
On 17/06/13 15:43, Mark Jackson wrote:
On 13/05/13 19:28, Tom Rini wrote:
From: Steve Kipisz s-kipi...@ti.com
NOR requires that s_init be within the first 4KiB of the image so that
we can perform the rest of the required pinmuxing to talk with the rest
of NOR that we are found on. When NOR_BOOT is set we save our
environment in NOR at 512KiB and a redundant copy at 768KiB. We avoid
using SPL for this case and u-boot.bin is written directly to the start
of NOR.
I'm trying to get this up and running our NanoBone platform, but I'm having
no success.
Just an update ... I now have it working ... yay !!
The main (and possibly the *only*) culprit was that SYSBOOT[8] (which selects
8/16bit mode) was being incorrectly influenced by a hardware fault.
I have pulled quite a few patches from various places, some of which might
not be required. Now I have a working base, I'll work out what is needed
on top of Tom's original patch set.
Okay ... I've now got NOR booting rebased to master using the patch set below.
This doesn't include my board code as that's of no interest until NOR booting
is added to the mainline code.
Sorry, Tom, I'm no git expert, so I'm not sure how to compare this to your
previous patches ... I hope this is useful in some way ??
Cheers
Mark J.
---
arch/arm/config.mk |2 +-
arch/arm/cpu/armv7/am33xx/board.c |2 +-
arch/arm/cpu/armv7/am33xx/emif4.c |6 +-
arch/arm/cpu/armv7/am33xx/mem.c| 18 --
arch/arm/cpu/armv7/lowlevel_init.S |2 +-
arch/arm/cpu/armv7/omap3/mem.c | 18 --
arch/arm/cpu/armv7/start.S |2 +-
7 files changed, 21 insertions(+), 29 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index e80e1ed..ba310cb 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -111,6 +111,6 @@ endif
endif
# check that only R_ARM_RELATIVE relocations are generated
-ifneq ($(CONFIG_SPL_BUILD),y)
+ifneq ($(CONFIG_SPL_BUILD)$(CONFIG_NOR_BOOT),y)
ALL-y += checkarmreloc
endif
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index b935a29..3085292 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -150,7 +150,7 @@ int arch_misc_init(void)
return 0;
}
-#ifdef CONFIG_SPL_BUILD
+#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
void rtc32k_enable(void)
{
struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
diff --git a/arch/arm/cpu/armv7/am33xx/emif4.c
b/arch/arm/cpu/armv7/am33xx/emif4.c
index aa84e96..370230b 100644
--- a/arch/arm/cpu/armv7/am33xx/emif4.c
+++ b/arch/arm/cpu/armv7/am33xx/emif4.c
@@ -43,9 +43,11 @@ void dram_init_banksize(void)
}
-#ifdef CONFIG_SPL_BUILD
+#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
+#ifdef CONFIG_TI81XX
static struct dmm_lisa_map_regs *hw_lisa_map_regs =
(struct dmm_lisa_map_regs *)DMM_BASE;
+#endif
static struct vtp_reg *vtpreg[2] = {
(struct vtp_reg *)VTP0_CTRL_ADDR,
(struct vtp_reg *)VTP1_CTRL_ADDR};
@@ -53,6 +55,7 @@ static struct vtp_reg *vtpreg[2] = {
static struct ddr_ctrl *ddrctrl = (struct ddr_ctrl *)DDR_CTRL_ADDR;
#endif
+#ifdef CONFIG_TI81XX
void config_dmm(const struct dmm_lisa_map_regs *regs)
{
enable_dmm_clocks();
@@ -67,6 +70,7 @@ void config_dmm(const struct dmm_lisa_map_regs *regs)
writel(regs-dmm_lisa_map_1, hw_lisa_map_regs-dmm_lisa_map_1);
writel(regs-dmm_lisa_map_0, hw_lisa_map_regs-dmm_lisa_map_0);
}
+#endif
static void config_vtp(int nr)
{
diff --git a/arch/arm/cpu/armv7/am33xx/mem.c b/arch/arm/cpu/armv7/am33xx/mem.c
index b86b0de..923ea83 100644
--- a/arch/arm/cpu/armv7/am33xx/mem.c
+++ b/arch/arm/cpu/armv7/am33xx/mem.c
@@ -75,16 +75,17 @@ void gpmc_init(void)
/* putting a blanket check on GPMC based on ZeBu for now */
gpmc_cfg = (struct gpmc *)GPMC_BASE;
-#ifdef CONFIG_CMD_NAND
- const u32 *gpmc_config = NULL;
- u32 base = 0;
- u32 size = 0;
-#endif
/* global settings */
writel(0x0008, gpmc_cfg-sysconfig);
+#ifdef CONFIG_NOR
+ writel(0x, gpmc_cfg-irqstatus);
+ writel(0x, gpmc_cfg-irqenable);
+ writel(0x0A00, gpmc_cfg-config);
+#else
writel(0x0100, gpmc_cfg-irqstatus);
writel(0x0100, gpmc_cfg-irqenable);
writel(0x0012, gpmc_cfg-config);
+#endif
/*
* Disable the GPMC0 config set by ROM code
*/
@@ -92,10 +93,7 @@ void gpmc_init(void)
sdelay(1000);
#ifdef CONFIG_CMD_NAND
- gpmc_config = gpmc_m_nand;
-
- base = PISMO1_NAND_BASE;
- size = PISMO1_NAND_SIZE;
- enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[0], base, size);
+ enable_gpmc_cs_config(gpmc_m_nand, gpmc_cfg-cs[0],
+ CONFIG_SYS_NAND_BASE
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 11/07/13 14:28, Tom Rini wrote: On Thu, Jul 11, 2013 at 02:06:26PM +0100, Mark Jackson wrote: On 18/06/13 13:11, Mark Jackson wrote: On 17/06/13 15:43, Mark Jackson wrote: Okay ... I've now got NOR booting rebased to master using the patch set below. This doesn't include my board code as that's of no interest until NOR booting is added to the mainline code. Sorry, Tom, I'm no git expert, so I'm not sure how to compare this to your previous patches ... I hope this is useful in some way ?? I'm just starting to cycle back to the NOR patches again myself and fixup the few remaining comments. But in your series: diff --git a/arch/arm/config.mk b/arch/arm/config.mk index e80e1ed..ba310cb 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -111,6 +111,6 @@ endif endif # check that only R_ARM_RELATIVE relocations are generated -ifneq ($(CONFIG_SPL_BUILD),y) +ifneq ($(CONFIG_SPL_BUILD)$(CONFIG_NOR_BOOT),y) ALL-y += checkarmreloc endif What toolchain are you using? This seems worrying at best. Generated via Buildroot ... here's the (rather copious) version info ... mpfj@mpfj-nanobone:~/uboot/u-boot$ arm-linux-gcc --version -v Using built-in specs. COLLECT_GCC=arm-linux-gcc COLLECT_LTO_WRAPPER=/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper arm-linux-gcc (Buildroot 2013.02-dirty) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: arm-buildroot-linux-uclibcgnueabi Configured with: /home/mpfj/buildroot/output/toolchain/gcc-4.6.3/configure --prefix=/home/mpfj/buildroot/output/host/usr --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c,c++ --with-sysroot=/home/mpfj/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/mpfj/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/mpfj/buildroot/output/host/usr --with-mpfr=/home/mpfj/buildroot/output/host/usr --with-mpc=/home/mpfj/buildroot/output/host/usr --disable-nls --enable-threads --disable-decimal-float --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02-dirty' --with-bugurl=http://bugs.buildroot.net/ --with -fpu=vfpv 3 --with-float=hard Thread model: posix gcc version 4.6.3 (Buildroot 2013.02-dirty) COLLECT_GCC_OPTIONS='--version' '-v' '-march=armv7-a' '-mtune=cortex-a8' '-mfloat-abi=hard' '-mfpu=vfpv3' '-mabi=aapcs-linux' /home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/cc1 -quiet -v help-dummy -quiet -dumpbase help-dummy -march=armv7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=vfpv3 -mabi=aapcs-linux -auxbase help-dummy -version --version -o /tmp/cczFlXPw.s GNU C (Buildroot 2013.02-dirty) version 4.6.3 (arm-buildroot-linux-uclibcgnueabi) compiled by GNU C version 4.6.3, GMP version 5.1.0, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='--version' '-v' '-march=armv7-a' '-mtune=cortex-a8' '-mfloat-abi=hard' '-mfpu=vfpv3' '-mabi=aapcs-linux' /home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/as -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3 -meabi=5 --version -o /tmp/ccgLl9x8.o /tmp/cczFlXPw.s GNU assembler (GNU Binutils) 2.21.1 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `arm-buildroot-linux-uclibcgnueabi'. COMPILER_PATH=/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/:/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/:/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/:/home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/:/home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/:/home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ LIBRARY_PATH=/home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/:/home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/../../../../arm-buildroot-linux-uclibcgnueabi/lib/:/home/mpfj/buildroot/output/host/usr/arm-buildroot-linux
[U-Boot] AM335x: env_{flash,nowhere} compile conflict
I'm struggling to work out why I get the following compile error:-
arm-linux-ld.bfd -r -o /home/mpfj/uboot/u-boot/spl/common/libcommon.o
/home/mpfj/uboot/u-boot/spl/common/cmd_nvedit.o
/home/mpfj/uboot/u-boot/spl/common/console.o
/home/mpfj/uboot/u-boot/spl/common/dlmalloc.o
/home/mpfj/uboot/u-boot/spl/common/env_common.o
/home/mpfj/uboot/u-boot/spl/common/env_flash.o
/home/mpfj/uboot/u-boot/spl/common/env_nowhere.o
/home/mpfj/uboot/u-boot/spl/common/image-fdt.o
/home/mpfj/uboot/u-boot/spl/common/image.o
/home/mpfj/uboot/u-boot/spl/common/memsize.o
/home/mpfj/uboot/u-boot/spl/common/miiphyutil.o
/home/mpfj/uboot/u-boot/spl/common/stdio.o
/home/mpfj/uboot/u-boot/spl/common/xyzModem.o
/home/mpfj/uboot/u-boot/spl/common/env_nowhere.o: In function
`env_relocate_spec':
/home/mpfj/uboot/u-boot/common/env_nowhere.c:38: multiple definition of
`env_relocate_spec'
/home/mpfj/uboot/u-boot/spl/common/env_flash.o:/home/mpfj/uboot/u-boot/common/env_flash.c:321:
first defined here
/home/mpfj/uboot/u-boot/spl/common/env_nowhere.o: In function `env_init':
/home/mpfj/uboot/u-boot/common/env_nowhere.c:47: multiple definition of
`env_init'
/home/mpfj/uboot/u-boot/spl/common/env_flash.o:/home/mpfj/uboot/u-boot/common/env_flash.c:78:
first defined here
/home/mpfj/uboot/u-boot/spl/common/env_nowhere.o: In function
`env_relocate_spec':
/home/mpfj/uboot/u-boot/common/env_nowhere.c:38: multiple definition of
`env_ptr'
/home/mpfj/uboot/u-boot/spl/common/env_flash.o:(.data.env_ptr+0x0): first
defined here
make[3]: *** [/home/mpfj/uboot/u-boot/spl/common/libcommon.o] Error 1
make[3]: Leaving directory `/home/mpfj/uboot/u-boot/common'
make[2]: *** [/home/mpfj/uboot/u-boot/spl/common/libcommon.o] Error 2
make[2]: Leaving directory `/home/mpfj/uboot/u-boot/spl'
make[1]: *** [spl/u-boot-spl.bin] Error 2
make[1]: Leaving directory `/home/mpfj/uboot/u-boot'
make: *** [nanobone_sdboot] Error 2
I have 2 custom entries in the boards.cfg file:-
nanobone arm armv7 nanobone
newflowam33xx nanobone:NOR_BOOT
nanobone_sdboot arm armv7 nanobone
newflowam33xx nanobone:SD_BOOT
My nanobone.h file is attached.
I'd appreciate it is someone could tell me why env_nowhere.o is being compiled
in even though
CONFIG_ENV_IS_NOWHERE is not defined.
Cheers
Mark J.
/*
* nanobone.h
*
* Copyright (C) 2013 Newflow Ltd - http://www.newflow.co.uk/
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation version 2.
*
* This program is distributed as is WITHOUT ANY WARRANTY of any
* kind, whether express or implied; without even the implied warranty
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#ifndef __CONFIG_NANOBONE_H
#define __CONFIG_NANOBONE_H
#define CONFIG_AM33XX
#define CONFIG_OMAP
#include asm/arch/omap.h
#define CONFIG_DMA_COHERENT
#define CONFIG_DMA_COHERENT_SIZE (1 20)
#define CONFIG_ENV_SIZE (128 10) /* 128 KiB */
#define CONFIG_SYS_MALLOC_LEN (1024 10)
#define CONFIG_SYS_LONGHELP /* undef to save memory */
#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */
#define CONFIG_SYS_PROMPT U-Boot#
#define CONFIG_BOARD_LATE_INIT
#define MACH_TYPE_NANOBONE 4483
#define CONFIG_MACH_TYPE MACH_TYPE_NANOBONE
#define CONFIG_OF_LIBFDT
#define CONFIG_CMD_BOOTZ
#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_INITRD_TAG
/* Custom script for NOR */
#define CONFIG_SYS_LDSCRIPT board/newflow/nanobone/u-boot.lds
#define CONFIG_SYS_CACHELINE_SIZE 64
/* commands to include */
#include config_cmd_default.h
#define CONFIG_CMD_ASKENV
#define CONFIG_VERSION_VARIABLE
/* set to negative value for no autoboot */
#define CONFIG_BOOTDELAY 0
#define CONFIG_ZERO_BOOTDELAY_CHECK
#define CONFIG_ENV_VARS_UBOOT_CONFIG
#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
#ifndef CONFIG_SPL_BUILD
#ifdef CONFIG_SD_BOOT
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
mmcdev=0\0 \
bootenv=uEnv.txt\0 \
loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
env import -t ${loadaddr} ${filesize}\0 \
#define CONFIG_BOOTCOMMAND \
mtdparts default; \
if run loadbootenv; then \
echo Loaded environment from ${bootenv}; \
run importbootenv; \
if test -n $uenvcmd; then \
echo Running uenvcmd ...; \
run uenvcmd; \
fi; \
fi; \
#endif /* CONFIG_SD_BOOT */
#ifdef CONFIG_NOR_BOOT
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
fdtaddr=0x80f8\0 \
fdt_high=0x\0 \
kerneladdr=0x0810\0
#define CONFIG_BOOTARGS \
console=ttyO0,115200n8 noinitrd ip=off \
mem=256M rootwait=1 ubi.mtd=7,2048 \
rootfstype=jffs2 root=/dev/mtdblock5
#define CONFIG_BOOTCOMMAND \
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 17/06/13 15:43, Mark Jackson wrote: On 13/05/13 19:28, Tom Rini wrote: From: Steve Kipisz s-kipi...@ti.com NOR requires that s_init be within the first 4KiB of the image so that we can perform the rest of the required pinmuxing to talk with the rest of NOR that we are found on. When NOR_BOOT is set we save our environment in NOR at 512KiB and a redundant copy at 768KiB. We avoid using SPL for this case and u-boot.bin is written directly to the start of NOR. I'm trying to get this up and running our NanoBone platform, but I'm having no success. Just an update ... I now have it working ... yay !! The main (and possibly the *only*) culprit was that SYSBOOT[8] (which selects 8/16bit mode) was being incorrectly influenced by a hardware fault. I have pulled quite a few patches from various places, some of which might not be required. Now I have a working base, I'll work out what is needed on top of Tom's original patch set. Thanks for everyone's support. Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 13/05/13 19:28, Tom Rini wrote: From: Steve Kipisz s-kipi...@ti.com NOR requires that s_init be within the first 4KiB of the image so that we can perform the rest of the required pinmuxing to talk with the rest of NOR that we are found on. When NOR_BOOT is set we save our environment in NOR at 512KiB and a redundant copy at 768KiB. We avoid using SPL for this case and u-boot.bin is written directly to the start of NOR. I'm trying to get this up and running our NanoBone platform, but I'm having no success. Using a non NOR_BOOT version, I can boot u-boot and read / write to the NOR device (located at 0x0800). So I've compiled my NOR_BOOT version and stored it at the start of the flash device. But when I switch to booting from NOR (rather than SD) I get no output on the serial console. Using an oscilloscope, I can see the NOR chip select is active for a while (approx 350us), so *something* is trying to boot. How can I debug such an early part of the boot process ? Thanks for any help you can give me. Regards Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 17/06/13 15:49, Tom Rini wrote:
snip
Did you copy the parts that setup the pinmuxing in s_init for NOR?
This bit ?
#ifdef CONFIG_NOR_BOOT
asm(stmfd sp!, {r2 - r4});
asm(movw r4, #0x8A4);
asm(movw r3, #0x44E1);
asm(orrr4, r4, r3, lsl #16);
asm(movr2, #9);
asm(movr3, #8);
asm(gpmc_mux: str r2, [r4], #4);
asm(subs r3, r3, #1);
asm(bnegpmc_mux);
asm(ldmfd sp!, {r2 - r4});
#endif
Yes ... :-)
Mark J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 17/06/13 16:01, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2013 10:59 AM, Mark Jackson wrote:
On 17/06/13 15:49, Tom Rini wrote:
snip
Did you copy the parts that setup the pinmuxing in s_init for
NOR?
This bit ?
#ifdef CONFIG_NOR_BOOT asm(stmfd sp!, {r2 - r4}); asm(movw
r4, #0x8A4); asm(movw r3, #0x44E1); asm(orrr4,
r4, r3, lsl #16); asm(movr2, #9); asm(movr3,
#8); asm(gpmc_mux: str r2, [r4], #4); asm(subs r3,
r3, #1); asm(bnegpmc_mux); asm(ldmfd sp!, {r2 -
r4}); #endif
Yes ... :-)
Right. Well, baring hints from Steve, time to hook up the JTAG and
see where it's stuck.
Urm ... unfortunately, we have no JTAG on this board ... :-(
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 17/06/13 15:59, Mark Jackson wrote:
On 17/06/13 15:49, Tom Rini wrote:
snip
Did you copy the parts that setup the pinmuxing in s_init for NOR?
This bit ?
#ifdef CONFIG_NOR_BOOT
asm(stmfd sp!, {r2 - r4});
asm(movw r4, #0x8A4);
asm(movw r3, #0x44E1);
asm(orrr4, r4, r3, lsl #16);
asm(movr2, #9);
asm(movr3, #8);
asm(gpmc_mux: str r2, [r4], #4);
asm(subs r3, r3, #1);
asm(bnegpmc_mux);
asm(ldmfd sp!, {r2 - r4});
#endif
Yes ... :-)
Below is my entire s_init() routine.
One question ... the SPL code has:-
...
gd = gdata;
...
But there seems to be no similar assignment when in NOR boot mode.
I'm no expert in the internal workings of u-boot, so I thought I'd
check, just in case !?!
Cheers
Mark J.
---
void s_init(void)
{
/*
* The ROM will only have set up sufficient pinmux to allow for the
* first 4KiB NOR to be read, we must finish doing what we know of
* the NOR mux in this space in order to continue.
*/
#ifdef CONFIG_NOR_BOOT
asm(stmfd sp!, {r2 - r4});
asm(movw r4, #0x8A4);
asm(movw r3, #0x44E1);
asm(orrr4, r4, r3, lsl #16);
asm(movr2, #9);
asm(movr3, #8);
asm(gpmc_mux: str r2, [r4], #4);
asm(subs r3, r3, #1);
asm(bnegpmc_mux);
asm(ldmfd sp!, {r2 - r4});
#endif
/*
* Save the boot parameters passed from romcode.
* We cannot delay the saving further than this,
* to prevent overwrites.
*/
#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
save_omap_boot_params();
#endif
/* WDT1 is already running when the bootloader gets control
* Disable it to avoid random resets
*/
writel(0x, wdtimer-wdtwspr);
while (readl(wdtimer-wdtwwps) != 0x0)
;
writel(0x, wdtimer-wdtwspr);
while (readl(wdtimer-wdtwwps) != 0x0)
;
#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
/* Setup the PLLs and the clocks for the peripherals */
pll_init();
/* Enable RTC32K clock */
rtc32k_enable();
enable_board_pin_mux();
/* UART softreset */
u32 regVal;
regVal = readl(uart_base-uartsyscfg);
regVal |= UART_RESET;
writel(regVal, uart_base-uartsyscfg);
while ((readl(uart_base-uartsyssts)
UART_CLK_RUNNING_MASK) != UART_CLK_RUNNING_MASK)
;
/* Disable smart idle */
regVal = readl(uart_base-uartsyscfg);
regVal |= UART_SMART_IDLE_EN;
writel(regVal, uart_base-uartsyscfg);
#if defined(CONFIG_NOR_BOOT)
/* We want our console now. */
gd-baudrate = CONFIG_BAUDRATE;
serial_init();
gd-have_console = 1;
puts(\nU-Boot NOR Boot\n);
#else
gd = gdata;
preloader_console_init();
#endif
config_ddr(303, MT41J128MJT125_IOCTRL_VALUE, ddr3_data,
ddr3_cmd_ctrl_data, ddr3_emif_reg_data, 0);
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
#endif /* CONFIG_SPL_BUILD */
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 17/06/13 17:01, Stefan Roese wrote:
Hi Mark,
On 17.06.2013 17:23, Mark Jackson wrote:
snip
One question ... the SPL code has:-
...
gd = gdata;
...
But there seems to be no similar assignment when in NOR boot mode.
I'm no expert in the internal workings of u-boot, so I thought I'd
check, just in case !?!
I just noticed you mentioning gd here and wanted to point you to a
patch that fixed a gd-related boot issue for me on OMAP3:
[U-Boot] [PATCH 1/3] arm: spl: Fix SPL booting for OMAP3
(sorry, I can't find a link to this patch right now and I'm in a hurry)
Not sure if this has something to do with your problem (I don't have the
time to dig into this mail thread today as I'm leaving right now).
I'll look at that thanks.
But I've taken a slightly different approach, and added the following
to the start of s_init() ...
void s_init(void)
{
unsigned short *p = (unsigned short*)0x0800;
while (1)
{
int i;
for (i = 0; i (1 * 1024); i++)
{
unsigned short d = p[i];
d++;
*p = d;
}
}
...
AFAICT, that should just spin on reading/writing the NOR device,
but I still get only an initial 350us burst on the CS0 line, and
then nothing.
So I can only assume that the boot code isn't getting as far as
s_init() at all !!
In start.S and low_levelinit.c, there are various uses of:-
#ifdef CONFIG_SPL_BUILD
Do any of these also need referencing with a CONFIG_NOR_BOOT ?
Mark J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 17/06/13 18:04, Kipisz, Steven wrote:
snip
I'll look at that thanks.
But I've taken a slightly different approach, and added the following to the
start of s_init() ...
void s_init(void)
{
unsigned short *p = (unsigned short*)0x0800;
while (1)
{
int i;
for (i = 0; i (1 * 1024); i++)
{
unsigned short d = p[i];
d++;
*p = d;
}
}
...
AFAICT, that should just spin on reading/writing the NOR device, but I still
get
only an initial 350us burst on the CS0 line, and then nothing.
So I can only assume that the boot code isn't getting as far as
s_init() at all !!
In start.S and low_levelinit.c, there are various uses of:-
#ifdef CONFIG_SPL_BUILD
Do any of these also need referencing with a CONFIG_NOR_BOOT ?
Mark J.
Do you have a u-boot.lds in board/ti/am335x? That should put s_init()
earlier in the boot. Also, include/configs/am335x_evm.h should have
/* Custom script for NOR */
#define CONFIG_SYS_LDSCRIPT board/ti/am335x/u-boot.lds
Yes ... I have both u-boot.lds in my board directory, and the reference
to it in the config.
#define CONFIG_SYS_LDSCRIPT board/newflow/nanobone/u-boot.lds
Before using JTAG, take a look in System.map where s_init is located. For a
multiplex NOR it should be in the first 64K of address space.
That all seems in order ...
0800 T __image_copy_start
0800 T _start
0820 t _undefined_instruction
0824 t _software_interrupt
0828 t _prefetch_abort
082c t _data_abort
0830 t _not_used
0834 t _irq
0838 t _fiq
083c t _pad
0840 T _TEXT_BASE
0840 T _end_vect
0844 T _bss_start_ofs
0848 T _bss_end_ofs
084c T _end_ofs
0850 T IRQ_STACK_START_IN
0854 t reset
0894 T c_runtime_cpu_setup
08b0 T cpu_init_cp15
08e8 T cpu_init_crit
08000100 t undefined_instruction
08000160 t software_interrupt
080001c0 t prefetch_abort
08000220 t data_abort
08000280 t not_used
080002e0 t irq
08000340 t fiq
080003a0 T enable_board_pin_mux
08000444 t cpsw_control
08000448 T s_init
08000464 t gpmc_mux
08000568 T board_init
080005d8 T board_late_init
0800060c T board_eth_init
0800076c T enable_gpmc_cs_config
080007e0 T gpmc_init
...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored
On 21/05/13 18:34, Michael Heimpold wrote: Hi Wolfgang Denx, Closing a file descriptor does not guarantee that the data has been successfully saved to disk, as the kernel might defer the write. What is the exact problem you are trying to fix? I mean, when exactly does adding the sync play a role? I'm using fw_setenv during system update process. The sequence of such a shell script is something like (much simplified): ... fw_setenv state=2 dd if=... of=/dev/mmcblk0... fw_setenv state=1 ... reboot Not sure what final OS environment you're running, but I would think that reboot would sync for you ? For instance, under BusyBox, we have:- # reboot --help BusyBox v1.14.0 (2012-02-15 10:28:26 GMT) multi-call binary Usage: reboot [-d delay] [-n] [-f] Reboot the system Options: -d Delay interval for rebooting -n No call to sync() -f Force reboot (don't go through init) ... and under Ubuntu, we have ... $ reboot --help Usage: reboot [OPTION]... Reboot the system. Options: -n, --no-sync don't sync before reboot or halt ... So by default, reboot would (should ?) call sync automatically. This might point to some other issue ? Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add NanoBone board support
On 16/04/13 20:22, Tom Rini wrote:
On Tue, Apr 16, 2013 at 08:14:13PM +0100, Mark Jackson wrote:
On 16/04/13 16:48, Tom Rini wrote:
On Tue, Apr 16, 2013 at 04:02:34PM +0100, Mark Jackson wrote:
snip
+static struct cpsw_platform_data cpsw_data = {
+ .mdio_base = CPSW_MDIO_BASE,
+ .cpsw_base = CPSW_BASE,
+ .mdio_div = 0xff,
+ .channels = 8,
+ .cpdma_reg_ofs = 0x800,
+ .slaves = 2,
Is this all that was needed for both interfaces to work in U-Boot, along
with a config change or two? If so, I should take a stab at getting
both working on the EVM-SK.
Yes ... the config change is just to set CONFIG_PHY_ADDR to the
correct value.
Unfortunately, since the CONFIG_PHY_ADDR value is hard-coded into
quite a bit of the uboot code, to change ports, you need to
re-compile !! Not ideal, and I don't suppose it's too much work to
get both
working together, but I don't see much demand for it.
Ah, so it's not quite right :( Other platforms support multiple
interfaces, but I don't know how they're setup.
Tom
I can see in drivers/net/cpsw.c:-
static int cpsw_phy_init(struct eth_device *dev, struct cpsw_slave *slave)
{
...
phydev = phy_connect(priv-bus,
CONFIG_PHY_ADDR,
dev,
slave-data-phy_if);
...
}
As you can see the hardcoded CONFIG_PHY_ADDR is being used, despite the
fact that it might be different for each slave.
Could you just replace that with slave-data-phy_id ?
I'll give it a try and see what happens.
Cheers
Mark J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add NanoBone board support
On 22/04/13 11:04, Mark Jackson wrote:
On 16/04/13 20:22, Tom Rini wrote:
On Tue, Apr 16, 2013 at 08:14:13PM +0100, Mark Jackson wrote:
On 16/04/13 16:48, Tom Rini wrote:
On Tue, Apr 16, 2013 at 04:02:34PM +0100, Mark Jackson wrote:
snip
+static struct cpsw_platform_data cpsw_data = {
+ .mdio_base = CPSW_MDIO_BASE,
+ .cpsw_base = CPSW_BASE,
+ .mdio_div = 0xff,
+ .channels = 8,
+ .cpdma_reg_ofs = 0x800,
+ .slaves = 2,
Is this all that was needed for both interfaces to work in U-Boot, along
with a config change or two? If so, I should take a stab at getting
both working on the EVM-SK.
Yes ... the config change is just to set CONFIG_PHY_ADDR to the
correct value.
Unfortunately, since the CONFIG_PHY_ADDR value is hard-coded into
quite a bit of the uboot code, to change ports, you need to
re-compile !! Not ideal, and I don't suppose it's too much work to
get both
working together, but I don't see much demand for it.
Ah, so it's not quite right :( Other platforms support multiple
interfaces, but I don't know how they're setup.
Tom
I can see in drivers/net/cpsw.c:-
static int cpsw_phy_init(struct eth_device *dev, struct cpsw_slave *slave)
{
...
phydev = phy_connect(priv-bus,
CONFIG_PHY_ADDR,
dev,
slave-data-phy_if);
...
}
As you can see the hardcoded CONFIG_PHY_ADDR is being used, despite the
fact that it might be different for each slave.
Could you just replace that with slave-data-phy_id ?
I'll give it a try and see what happens.
No, that doesn't fix things.
It looks like the PHY device is stored in the cpsw struct (rather than
in the slave struct) ... from cpsw.c:-
struct cpsw_priv {
struct eth_device *dev;
struct cpsw_platform_data data;
int host_port;
struct cpsw_regs*regs;
void*dma_regs;
struct cpsw_host_regs *host_port_regs;
void*ale_regs;
struct cpdma_desc *descs;
struct cpdma_desc *desc_free;
struct cpdma_chan rx_chan, tx_chan;
struct cpsw_slave *slaves;
struct phy_device *phydev;
struct mii_dev *bus;
u32 mdio_link;
u32 phy_mask;
};
So there's an assumption that you can only have a single PHY (even
though you can have 2 slaves).
I've gone as far as I dare with my limited knowledge.
Regards
Mark J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Add NanoBone board support
NanoBone Specification:
---
CPU:
TI AM335x
Memory:
256MB DDR3
64MB NOR flash
256MB NAND flash
128KB FRAM
Ethernet:
2 x 10/100 connected to SMSC LAN8710 PHY
USB:
1 x USB2.0 Type A
I2C:
2Kbit EEPROM (Microchip 24AA02)
RTC (Maxim DS1338)
GPIO Expander (Microchip MCP23017)
Expansion connector:
6 x UART
1 x MMC/SD
1 x USB2.0
Signed-off-by: Mark Jackson m...@newflow.co.uk
---
Changes in v2:
- Tweaked after comments from Tom Rini
MAINTAINERS |4 +
board/newflow/nanobone/Makefile | 46 ++
board/newflow/nanobone/board.c | 304
+++
board/newflow/nanobone/board.h | 24
board/newflow/nanobone/mux.c| 203 ++
boards.cfg |1 +
include/configs/nanobone.h | 285
7 files changed, 867 insertions(+)
create mode 100644 board/newflow/nanobone/Makefile
create mode 100644 board/newflow/nanobone/board.c
create mode 100644 board/newflow/nanobone/board.h
create mode 100644 board/newflow/nanobone/mux.c
create mode 100644 include/configs/nanobone.h
diff --git a/MAINTAINERS b/MAINTAINERS
index bbab5fe..3724e21 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -711,6 +711,10 @@ Ilko Iliev il...@ronetix.at
PM9263 AT91SAM9263
PM9G45 ARM926EJS (AT91SAM9G45 SoC)
+Mark Jackson m...@newflow.co.uk
+
+ NANOBONEARM ARMV7 (AM33xx Soc)
+
Michael Jones michael.jo...@matrix-vision.de
omap3_mvblx ARM ARMV7 (OMAP3xx SoC)
diff --git a/board/newflow/nanobone/Makefile
b/board/newflow/nanobone/Makefile
new file mode 100644
index 000..67a87a1
--- /dev/null
+++ b/board/newflow/nanobone/Makefile
@@ -0,0 +1,46 @@
+#
+# Makefile
+#
+# Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+#
+# 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 as is WITHOUT ANY WARRANTY of any
+# kind, whether express or implied; without even the implied warranty
+# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifdef CONFIG_SPL_BUILD
+COBJS := mux.o
+endif
+
+COBJS += board.o
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/newflow/nanobone/board.c b/board/newflow/nanobone/board.c
new file mode 100644
index 000..d0af256
--- /dev/null
+++ b/board/newflow/nanobone/board.c
@@ -0,0 +1,304 @@
+/*
+ * board.c
+ *
+ * Board functions for Newflow NanoBone board
+ *
+ * Copyright (C) 2013, Newflow Ltd - http://www.newflow.co.uk/
+ *
+ * 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.
+ */
+
+#include common.h
+#include errno.h
+#include asm/arch/clock.h
+#include asm/arch/cpu.h
+#include asm/arch/ddr_defs.h
+#include asm/arch/gpio.h
+#include asm/arch/hardware.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mem.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/omap.h
+#include asm/emif.h
+#include asm/gpio.h
+#include asm/io.h
+#include cpsw.h
+#include i2c.h
+#include miiphy.h
+#include spl.h
+#include board.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* FRAM config */
+#define FRAM_CS1
+#define FRAM_BASE 0x1c00
+#define FRAM_SIZE GPMC_SIZE_16M
+static u32 gpmc_fram_config[GPMC_MAX_REG] = {
+ 0x1200,
+ 0x00101000,
+ 0x00020201,
+ 0x0f030f03,
+ 0x010d1010,
+ 0x000301c0,
+ 0
+};
+
+/* NOR Flash config */
+#define NOR_CS 3
+#define NOR_BASE 0x1800
+#define NOR_SIZE GPMC_SIZE_64M
+static u32 gpmc_nor_config[GPMC_MAX_REG] = {
+ 0x1200,
+ 0x00101004,
+ 0x00020201,
+ 0x10041004,
+ 0x010f1010
Re: [U-Boot] [PATCH] Add NanoBone board support
On 16/04/13 16:48, Tom Rini wrote: On Tue, Apr 16, 2013 at 04:02:34PM +0100, Mark Jackson wrote: snip +config_ddr(303, MT41J128MJT125_IOCTRL_VALUE, ddr3_data, + ddr3_cmd_ctrl_data, ddr3_emif_reg_data, 0); And are you unable to run at 400MHz here? Or just weren't aware / having tried updating the timing parameters, etc? Forgive my ignorance, but where does the 400MHz come from ? I thought that 303MHz was the max clock speed on the AM335x (TRM 7.3.2.2), or am I missing something ? Cheers Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add NanoBone board support
On 18/04/13 07:05, Hebbar, Gururaja wrote: On Wed, Apr 17, 2013 at 23:12:51, Mark Jackson wrote: On 17/04/13 06:27, Hebbar, Gururaja wrote: Mark, On Tue, Apr 16, 2013 at 20:32:34, Mark Jackson wrote: snip diff --git a/MAINTAINERS b/MAINTAINERS index 1614b91..7778883 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -710,6 +710,10 @@ Ilko Iliev il...@ronetix.at PM9263 AT91SAM9263 PM9G45 ARM926EJS (AT91SAM9G45 SoC) +Mark Jackson m...@newflow.co.uk A small nit-pick, you sent the commit using email id as mpfj-l...@mimc.co.uk But in the maintainer file, it shows as m...@newflow.co.uk. Is this valid/correct? Yes ... the newflow address is my official work one. But I have a separate email address for all my mailing lists which makes sorting out my mailboxes *so* much easier. AFAIK Email id in Maintainer file will be used for all communications. So I believe, you have enabled mail fwd from m...@newflow.co.uk to mpfj-l...@mimc.co.uk I don't mind direct contact on my standard email address ... I just have all my mailing list traffic sent to another email address. I've actually now change to mpfj-list at newflow.co.uk, so does that make things a bit clearer ? Regards Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add NanoBone board support
On 17/04/13 06:27, Hebbar, Gururaja wrote: Mark, On Tue, Apr 16, 2013 at 20:32:34, Mark Jackson wrote: snip diff --git a/MAINTAINERS b/MAINTAINERS index 1614b91..7778883 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -710,6 +710,10 @@ Ilko Iliev il...@ronetix.at PM9263 AT91SAM9263 PM9G45 ARM926EJS (AT91SAM9G45 SoC) +Mark Jackson m...@newflow.co.uk A small nit-pick, you sent the commit using email id as mpfj-l...@mimc.co.uk But in the maintainer file, it shows as m...@newflow.co.uk. Is this valid/correct? Yes ... the newflow address is my official work one. But I have a separate email address for all my mailing lists which makes sorting out my mailboxes *so* much easier. I trust this isn't an issue. Cheers Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove duplicate / unused #defines on AM335x boards
As part of a review of a recent patch to add a new AM335x board, Tom found several duplicate and/or unused #defines. This patch simply removes them. The two affected configs have been recompiled to check nothing was broken (from a compilation point of view !!) Reported-by: Tom Rini tr...@ti.com Signed-off-by: Mark Jackson mpfj-l...@mimc.co.uk --- include/configs/am335x_evm.h | 10 ++ include/configs/pcm051.h |4 +--- 2 files changed, 3 insertions(+), 11 deletions(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index ef00306..5739422 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -196,7 +196,6 @@ + (8 * 1024 * 1024)) #define CONFIG_SYS_LOAD_ADDR 0x8100 /* Default load address */ -#define CONFIG_SYS_HZ 1000 /* 1ms clock */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC @@ -260,12 +259,11 @@ /* Platform/Board specific defs */ #define CONFIG_SYS_TIMERBASE 0x4804 /* Use Timer2 */ #define CONFIG_SYS_PTV 2 /* Divisor: 2^(PTV+1) = 8 */ -#define CONFIG_SYS_HZ 1000 +#define CONFIG_SYS_HZ 1000/* 1ms clock */ /* NS16550 Configuration */ #define CONFIG_SYS_NS16550 #define CONFIG_SYS_NS16550_SERIAL -#define CONFIG_SERIAL_MULTI #define CONFIG_SYS_NS16550_REG_SIZE(-4) #define CONFIG_SYS_NS16550_CLK (4800) #define CONFIG_SYS_NS16550_COM10x44e09000 /* Base EVM has UART0 */ @@ -360,11 +358,7 @@ #define CONFIG_SYS_NAND_ECCSIZE512 #define CONFIG_SYS_NAND_ECCBYTES 14 -#define CONFIG_SYS_NAND_ECCSTEPS 4 -#defineCONFIG_SYS_NAND_ECCTOTAL(CONFIG_SYS_NAND_ECCBYTES * \ - CONFIG_SYS_NAND_ECCSTEPS) - -#defineCONFIG_SYS_NAND_U_BOOT_STARTCONFIG_SYS_TEXT_BASE +#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_NAND_U_BOOT_OFFS0x8 diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h index d0ea74e..2e3f08b 100644 --- a/include/configs/pcm051.h +++ b/include/configs/pcm051.h @@ -129,7 +129,6 @@ + (8 * 1024 * 1024)) #define CONFIG_SYS_LOAD_ADDR 0x80007fc0 /* Default load address */ -#define CONFIG_SYS_HZ 1000 /* 1ms clock */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC @@ -158,13 +157,12 @@ /* Platform/Board specific defs */ #define CONFIG_SYS_TIMERBASE 0x4804 /* Use Timer2 */ #define CONFIG_SYS_PTV 2 /* Divisor: 2^(PTV+1) = 8 */ -#define CONFIG_SYS_HZ 1000 +#define CONFIG_SYS_HZ 1000/* 1ms clock */ #define CONFIG_CONS_INDEX 1 /* NS16550 Configuration */ #define CONFIG_SYS_NS16550 #define CONFIG_SYS_NS16550_SERIAL -#define CONFIG_SERIAL_MULTI #define CONFIG_SYS_NS16550_REG_SIZE(-4) #define CONFIG_SYS_NS16550_CLK (4800) #define CONFIG_SYS_NS16550_COM10x44e09000 /* Base EVM has UART0 */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add NanoBone board support
NanoBone Specification:
---
Memory:
256MB DDR3
64MB NOR flash
256MB NAND flash
128KB FRAM
Ethernet:
2 x 10/100 connected to SMSC LAN8710 PHY
USB:
1 x USB2.0 Type A
I2C:
2Kbit EEPROM (Microchip 24AA02)
RTC (Maxim DS1338)
GPIO Expander (Microchip MCP23017)
Expansion connector:
6 x UART
1 x MMC/SD
1 x USB2.0
Signed-off-by: Mark Jackson m...@newflow.co.uk
---
MAINTAINERS |4 +
board/newflow/nanobone/Makefile | 46 ++
board/newflow/nanobone/board.c | 337 +++
board/newflow/nanobone/board.h | 24 +++
board/newflow/nanobone/mux.c| 203 +++
boards.cfg |1 +
include/configs/nanobone.h | 291 +
7 files changed, 906 insertions(+)
create mode 100644 board/newflow/nanobone/Makefile
create mode 100644 board/newflow/nanobone/board.c
create mode 100644 board/newflow/nanobone/board.h
create mode 100644 board/newflow/nanobone/mux.c
create mode 100644 include/configs/nanobone.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 1614b91..7778883 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -710,6 +710,10 @@ Ilko Iliev il...@ronetix.at
PM9263 AT91SAM9263
PM9G45 ARM926EJS (AT91SAM9G45 SoC)
+Mark Jackson m...@newflow.co.uk
+
+ NANOBONEARM ARMV7 (AM33xx Soc)
+
Michael Jones michael.jo...@matrix-vision.de
omap3_mvblx ARM ARMV7 (OMAP3xx SoC)
diff --git a/board/newflow/nanobone/Makefile b/board/newflow/nanobone/Makefile
new file mode 100644
index 000..67a87a1
--- /dev/null
+++ b/board/newflow/nanobone/Makefile
@@ -0,0 +1,46 @@
+#
+# Makefile
+#
+# Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+#
+# 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 as is WITHOUT ANY WARRANTY of any
+# kind, whether express or implied; without even the implied warranty
+# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifdef CONFIG_SPL_BUILD
+COBJS := mux.o
+endif
+
+COBJS += board.o
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/newflow/nanobone/board.c b/board/newflow/nanobone/board.c
new file mode 100644
index 000..e8f7e00
--- /dev/null
+++ b/board/newflow/nanobone/board.c
@@ -0,0 +1,337 @@
+/*
+ * board.c
+ *
+ * Board functions for Newflow NanoBone board
+ *
+ * Copyright (C) 2013, Newflow Ltd - http://www.newflow.co.uk/
+ *
+ * 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.
+ */
+
+#include common.h
+#include errno.h
+#include asm/arch/clock.h
+#include asm/arch/cpu.h
+#include asm/arch/ddr_defs.h
+#include asm/arch/gpio.h
+#include asm/arch/hardware.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mem.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/omap.h
+#include asm/emif.h
+#include asm/gpio.h
+#include asm/io.h
+#include cpsw.h
+#include i2c.h
+#include miiphy.h
+#include spl.h
+#include board.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* FRAM config */
+#define FRAM_CS1
+#define FRAM_BASE 0x1c00
+#define FRAM_SIZE GPMC_SIZE_16M
+static u32 gpmc_fram_config[GPMC_MAX_REG] = {
+ 0x1200,
+ 0x00101000,
+ 0x00020201,
+ 0x0f030f03,
+ 0x010d1010,
+ 0x000301c0,
+ 0
+};
+
+/* NOR Flash config */
+#define NOR_CS 3
+#define NOR_BASE 0x1800
+#define NOR_SIZE GPMC_SIZE_64M
+static u32 gpmc_nor_config[GPMC_MAX_REG] = {
+ 0x1200,
+ 0x00101004,
+ 0x00020201,
+ 0x10041004,
+ 0x010f1010,
+ 0x000601c0,
+ 0
+};
+
+static struct wd_timer *wdtimer = (struct
Re: [U-Boot] [PATCH] Add NanoBone board support
On 16/04/13 16:48, Tom Rini wrote:
On Tue, Apr 16, 2013 at 04:02:34PM +0100, Mark Jackson wrote:
[snip]
+static struct emif_regs ddr3_emif_reg_data = {
+ .sdram_config = MT41J128MJT125_EMIF_SDCFG,
+ .ref_ctrl = MT41J128MJT125_EMIF_SDREF,
+ .sdram_tim1 = MT41J128MJT125_EMIF_TIM1,
+ .sdram_tim2 = MT41J128MJT125_EMIF_TIM2,
+ .sdram_tim3 = MT41J128MJT125_EMIF_TIM3,
+ .zq_config = MT41J128MJT125_ZQ_CFG,
+ .emif_ddr_phy_ctlr_1 = MT41J128MJT125_EMIF_READ_LATENCY,
On the READ_LATENCY, you probably want | PHY_EN_DYN_PWRDN for that
(since it's not part of MT41J128MJT125_EMIF_READ_LATENCY) bit of
savings.
Okay, I'd not looked at the DDR setup in great detail, simply copying
what the EVM-SK did.
+static int do_switch_ecc(cmd_tbl_t * cmdtp, int flag, int argc, char * const
argv[])
Why are we bringing this in?
There's currently no way to enable BCH8 ECC mode. I need this so that
all writes to the on-board NAND have the correct ECC values.
There's a similar bunch of code in the OMAP3 board.c file, so I just
copied that principal.
Ah ... I've just seen this changed recently (don't know why my code even
compiles now as the headers are different !!). I'll just back this out
and use the existing version.
+ config_ddr(303, MT41J128MJT125_IOCTRL_VALUE, ddr3_data,
+ ddr3_cmd_ctrl_data, ddr3_emif_reg_data, 0);
And are you unable to run at 400MHz here? Or just weren't aware /
having tried updating the timing parameters, etc?
Again, I just copied the EVM-SK code.
DDR3 is a new technology for us, but now the board essentially works I
should (when I have time !!) be able do some further timing tweaks.
+static struct cpsw_platform_data cpsw_data = {
+ .mdio_base = CPSW_MDIO_BASE,
+ .cpsw_base = CPSW_BASE,
+ .mdio_div = 0xff,
+ .channels = 8,
+ .cpdma_reg_ofs = 0x800,
+ .slaves = 2,
Is this all that was needed for both interfaces to work in U-Boot, along
with a config change or two? If so, I should take a stab at getting
both working on the EVM-SK.
Yes ... the config change is just to set CONFIG_PHY_ADDR to the correct
value.
Unfortunately, since the CONFIG_PHY_ADDR value is hard-coded into
quite a bit of the uboot code, to change ports, you need to re-compile
!! Not ideal, and I don't suppose it's too much work to get both
working together, but I don't see much demand for it.
+ writel(PORT1_MII_MODE_ENABLE | PORT2_MII_MODE_ENABLE, cdev-miisel);
+ cpsw_slaves[0].phy_if = cpsw_slaves[1].phy_if = PHY_INTERFACE_MODE_MII;
Can't you just do that in the struct? And avoid the checkpatch warning
too.
Sure, will do.
+#define CONFIG_SYS_NO_FLASH
But you have NOR. Is it not working yet?
We do have NOR and it's working, but it doesn't contain any user
accessible data. We use it as long-term storage using a custom layout,
so there's no point in exposing it to uboot.
+/*
+ * memtest works on 8 MB in DRAM after skipping 32MB from
+ * start addr of ram disk
+ */
+#define CONFIG_SYS_MEMTEST_START (PHYS_DRAM_1 + (64 * 1024 * 1024))
+#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START \
+ + (8 * 1024 * 1024))
Please see doc/README.memory-test and then eiter update the range to be
most of memory or drop these and add #undef CONFIG_CMD_MEMTEST.
I'll just drop memtest.
+#define CONFIG_SYS_HZ 1000 /* 1ms clock */
[snip]
+#define CONFIG_SYS_HZ 1000
I see this is a copy/paste problem too from am335x_evm.h, can you fix
there and pcm051.h?
Sure, I'll post a remove duplicate #defines patch.
+#define CONFIG_SERIAL_MULTI
Same (not needed anymore, not sure how it didn't get removed before).
Ok.
+#define CONFIG_CMD_EEPROM
+#define CONFIG_SYS_I2C_EEPROM_ADDR 0x50/* Main EEPROM */
+#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 2
+#define CONFIG_SYS_I2C_MULTI_EEPROMS
Do you really have the EEPROM at 0x50 like the TI boards do (and then at
other offets for capes/daughter cards) ?
Yes, but it doesn't contain the same TI EEPROM data structure. In fact,
at the moment, it doesn't contain anything (!!).
It's just there for future expansion in which case, should I remove
the #defines for the time being ?
+#defineCONFIG_SYS_NAND_ECCTOTAL(CONFIG_SYS_NAND_ECCBYTES * \
+ CONFIG_SYS_NAND_ECCSTEPS)
+
+#defineCONFIG_SYS_NAND_U_BOOT_STARTCONFIG_SYS_TEXT_BASE
Another problem duplicated from am335x_evm.h :(
I'll add it to the remove duplicates patch.
+#define MTDPARTS_DEFAULT mtdparts=nand: \
+ 128k(spl), \
+ 1792k(boot), \
This isn't quite right. Your first 128k chunks are ROM-checked
redundant locations for SPL to live (hence
Re: [U-Boot] [PATCH] Add NanoBone board support
On 16/04/13 20:14, Mark Jackson wrote: On 16/04/13 16:48, Tom Rini wrote: On Tue, Apr 16, 2013 at 04:02:34PM +0100, Mark Jackson wrote: snip +#defineCONFIG_SYS_NAND_ECCTOTAL(CONFIG_SYS_NAND_ECCBYTES * \ +CONFIG_SYS_NAND_ECCSTEPS) + +#defineCONFIG_SYS_NAND_U_BOOT_STARTCONFIG_SYS_TEXT_BASE Another problem duplicated from am335x_evm.h :( I'll add it to the remove duplicates patch. Replied a bit too soon on this one ... I thought they were duplicated, but they're not. what's the problem with these lines ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add NanoBone board support
On 16/04/13 20:27, Tom Rini wrote: On Tue, Apr 16, 2013 at 08:25:17PM +0100, Mark Jackson wrote: On 16/04/13 20:14, Mark Jackson wrote: On 16/04/13 16:48, Tom Rini wrote: On Tue, Apr 16, 2013 at 04:02:34PM +0100, Mark Jackson wrote: snip +#defineCONFIG_SYS_NAND_ECCTOTAL(CONFIG_SYS_NAND_ECCBYTES * \ +CONFIG_SYS_NAND_ECCSTEPS) + +#defineCONFIG_SYS_NAND_U_BOOT_STARTCONFIG_SYS_TEXT_BASE Another problem duplicated from am335x_evm.h :( I'll add it to the remove duplicates patch. Replied a bit too soon on this one ... I thought they were duplicated, but they're not. what's the problem with these lines ? '#definetab' not '#definespace'. A general fixup patch is fine. Actually, neither CONFIG_SYS_NAND_ECCTOTAL nor CONFIG_SYS_NAND_ECCSTEPS are used anywhere in the code !! I'll just remove them. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do I use AM335x eth1 rather than eth0 ? [SOLVED]
On 12/04/13 11:56, Mark Jackson wrote:
We have a dual Ethernet board (based on the BeagelBone) but with both Ethernet
ports connected.
I'm wanting to use eth1 (rather than eth0), so in my board.c file, I changed:-
static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs = 0x208,
.sliver_reg_ofs = 0xd80,
.phy_id = 0,
},
{
.slave_reg_ofs = 0x308,
.sliver_reg_ofs = 0xdc0,
.phy_id = 1,
},
};
... to ...
static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs = 0x308,
.sliver_reg_ofs = 0xdc0,
.phy_id = 1,
},
{
.slave_reg_ofs = 0x208,
.sliver_reg_ofs = 0xd80,
.phy_id = 0,
},
};
... assuming that eth0 would now be ignored (as only 1 slave is configured).
But (eg) dhcp still only responds on eth0 !?!
What else do I have to change ?
After much experimenting, I've managed to get it to work.
Based on the original board.c file copied from the TI starter kit, I
simply changed the slaves count to 2, and set CONFIG_PHY_ADDR to 1 in my
board config file.
Simple.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do I use AM335x eth1 rather than eth0 ? [SOLVED]
On 12/04/13 11:56, Mark Jackson wrote:
We have a dual Ethernet board (based on the BeagelBone) but with both Ethernet
ports connected.
I'm wanting to use eth1 (rather than eth0), so in my board.c file, I changed:-
static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs = 0x208,
.sliver_reg_ofs = 0xd80,
.phy_id = 0,
},
{
.slave_reg_ofs = 0x308,
.sliver_reg_ofs = 0xdc0,
.phy_id = 1,
},
};
... to ...
static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs = 0x308,
.sliver_reg_ofs = 0xdc0,
.phy_id = 1,
},
{
.slave_reg_ofs = 0x208,
.sliver_reg_ofs = 0xd80,
.phy_id = 0,
},
};
... assuming that eth0 would now be ignored (as only 1 slave is configured).
But (eg) dhcp still only responds on eth0 !?!
What else do I have to change ?
After much experimenting, I've managed to get it to work.
Based on the original board.c file copied from the TI starter kit, I
simply changed the slaves count to 2, and set CONFIG_PHY_ADDR to 1 in my
board config file.
Simple.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How do I use AM335x eth1 rather than eth0 ?
We have a dual Ethernet board (based on the BeagelBone) but with both Ethernet
ports connected.
I'm wanting to use eth1 (rather than eth0), so in my board.c file, I changed:-
static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs = 0x208,
.sliver_reg_ofs = 0xd80,
.phy_id = 0,
},
{
.slave_reg_ofs = 0x308,
.sliver_reg_ofs = 0xdc0,
.phy_id = 1,
},
};
... to ...
static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs = 0x308,
.sliver_reg_ofs = 0xdc0,
.phy_id = 1,
},
{
.slave_reg_ofs = 0x208,
.sliver_reg_ofs = 0xd80,
.phy_id = 0,
},
};
... assuming that eth0 would now be ignored (as only 1 slave is configured).
But (eg) dhcp still only responds on eth0 !?!
What else do I have to change ?
Cheers
Mark J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How do I use AM335x eth1 rather than eth0 ?
We have a dual Ethernet board (based on the BeagelBone) but with both Ethernet
ports connected.
I'm wanting to use eth1 (rather than eth0), so in my board.c file, I changed:-
static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs = 0x208,
.sliver_reg_ofs = 0xd80,
.phy_id = 0,
},
{
.slave_reg_ofs = 0x308,
.sliver_reg_ofs = 0xdc0,
.phy_id = 1,
},
};
... to ...
static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs = 0x308,
.sliver_reg_ofs = 0xdc0,
.phy_id = 1,
},
{
.slave_reg_ofs = 0x208,
.sliver_reg_ofs = 0xd80,
.phy_id = 0,
},
};
... assuming that eth0 would now be ignored (as only 1 slave is configured).
But (eg) dhcp still only responds on eth0 !?!
What else do I have to change ?
Cheers
Mark J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do I use AM335x eth1 rather than eth0 ?
On 12/04/13 17:05, Tom Rini wrote: On Fri, Apr 12, 2013 at 11:56:57AM +0100, Mark Jackson wrote: We have a dual Ethernet board (based on the BeagelBone) but with both Ethernet ports connected. I'm wanting to use eth1 (rather than eth0), so in my board.c file, I changed:- snip ... assuming that eth0 would now be ignored (as only 1 slave is configured). But (eg) dhcp still only responds on eth0 !?! What else do I have to change ? Good question, do you have both ports working in Linux yet? The EVM-SK design supports two interfaces and I know the cpsw driver in the kernel required some changes to support two. I strongly suspect similar changes would be required in the U-Boot driver (I don't have any specific links other than look at the vendor kernel tree). Well, I've realised I needed to change CONFIG_PHY_ADDR in my board config file. So the link up/down portion now works to PHY#2, but I'm still unable to ping anything from our board. I'm guessing there's some hard-coded assumptions in the cpsw.c driver. I've taken quick look at the Ethernet section of the TRM, but that's *wy* over my head !?! I've so far been unable to get Linux to see the 2nd port, and there is no vendor kernel tree ... I'm the vendor :-) Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Build failure on am335x_evm
On the current git master, I get the following build failure:- $ make am335x_evm common/libcommon.o: In function `do_fat_fsinfo': /home/mpfj/u-boot/u-boot/common/cmd_fat.c:87: undefined reference to `fat_set_blk_dev' /home/mpfj/u-boot/u-boot/common/cmd_fat.c:92: undefined reference to `file_fat_detectfs' drivers/mtd/nand/libnand.o: In function `nand_register': /home/mpfj/u-boot/u-boot/drivers/mtd/nand/nand.c:66: undefined reference to `add_mtd_device' fs/libfs.o:(.data+0x4): undefined reference to `fat_set_blk_dev' fs/libfs.o:(.data+0x8): undefined reference to `file_fat_ls' fs/libfs.o:(.data+0xc): undefined reference to `fat_read_file' fs/libfs.o:(.data+0x10): undefined reference to `fat_close' fs/libfs.o:(.data+0x18): undefined reference to `ext4fs_probe' fs/libfs.o:(.data+0x1c): undefined reference to `ext4fs_ls' fs/libfs.o:(.data+0x20): undefined reference to `ext4_read_file' fs/libfs.o:(.data+0x24): undefined reference to `ext4fs_close' arm-linux-ld.bfd: BFD (GNU Binutils) 2.23.1 assertion fail elf32-arm.c:7677 arm-linux-ld.bfd: BFD (GNU Binutils) 2.23.1 assertion fail elf32-arm.c:7677 arm-linux-ld.bfd: BFD (GNU Binutils) 2.23.1 assertion fail elf32-arm.c:7677 arm-linux-ld.bfd: error: required section '.rel.plt' not found in the linker script arm-linux-ld.bfd: final link failed: Invalid operation make[1]: *** [u-boot] Error 1 make[1]: Leaving directory `/home/mpfj/u-boot/u-boot' make: *** [am335x_evm] Error 2 Any ideas ? Cheers Mark JACKSON ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failure on am335x_evm
On 11/04/13 14:13, Tom Rini wrote: On Thu, Apr 11, 2013 at 10:58:19AM +0100, Mark Jackson wrote: On the current git master, I get the following build failure:- snip What rev are you on? 98f9200 should have fixed this issue. Fixed ... I needed to do a make distclean when I switched compiling from one board to another. Cheers Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding Kernel not starting
On 08/03/13 09:56, Ramesh K Khokhani wrote: Hi Friends, I have successfully run u-boot our my custom board but I can't run kernel. Problem is that I have saved uImage.bin at NOR location 0x80 and load into DRAM:0x4100. Here u-boot can get kernel info and print into UART consol but after loading uncompressed image from 0x4100 to 0x4002 u-boot transfer its control to linux kernel and here my hardware goes reset means can't run kernel at 0x4002. Following is the log of consol: U-Boot 2011.09 (Jan 23 2013 - 17:16:07) CPU: BTAM MCF5329 (Mask:54 Version:2) CPU CLK 240 MHz BUS CLK 80 MHz Board: BTAM 5329 I2C: ready DRAM: 32 MiB Flash: 16 MiB In:serial Out: serial Err: serial Net: Link UP timeout FEC0 Hit any key to stop autoboot: 5 4 3 2 1 0 ## Booting kernel from Legacy Image at 4100 ... Image Name: Created: 2013-03-04 12:03:52 UTC Image Type: M68K Linux Kernel Image (gzip compressed) Data Size:1549021 Bytes = 1.5 MiB Load Address: 4002 Entry Point: 4002 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Once you've got this point, you're no longer in the U-Boot environment. I suggest you repost over on one of the Linux mailing lists. Regards Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Allow AM335x MPU core clock speed to be specified in the board config file
On 04/03/13 00:27, Wolfgang Denk wrote: Dear Mark Jackson, In message 5130c537.8000...@mimc.co.uk you wrote: Allow AM335x MPU core clock speed to be specified in the board config file. To use, add the following to the board's config file:- #define V_MPUCLK desired clock freq in Hz If this is a configurable option, it should be CONFIG_SYS_V_MPUCLK instead. arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) Also, this new config option must be documented in the README. No problem ... I'll post a v3. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Allow AM335x MPU core clock speed to be specified in the board config file
Allow AM335x MPU core clock speed to be specified in the board config file. To use, add the following to the board's config file:- #define CONFIG_SYS_MPUCLK desired clock freq in Hz Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v3: - Changed from V_MPUCLK to CONFIG_SYS_MPUCLK - Added entry in README Changes in v2: - Tweaked after comments from Peter Korsgaard README |4 arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |7 +-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/README b/README index d8cb394..ddf6df2 100644 --- a/README +++ b/README @@ -3820,6 +3820,10 @@ Low Level (hardware related) configuration options: If defined, the x86 reset vector code is included. This is not needed when U-Boot is running from Coreboot. +- CONFIG_SYS_MPUCLK + Defines the MPU clock speed (in Hz). + + NOTE : currently only supported on AM335x platforms. Freescale QE/FMAN Firmware Support: --- diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h index d748dd2..5f2939b 100644 --- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h +++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h @@ -21,8 +21,11 @@ #define OSC(V_OSCK/100) -/* MAIN PLL Fdll = 550 MHZ, */ -#define MPUPLL_M 550 +/* MAIN PLL Fdll = 550 MHz, by default */ +#ifndef CONFIG_SYS_MPUCLK +#define CONFIG_SYS_MPUCLK 55000 +#endif +#define MPUPLL_M (CONFIG_SYS_MPUCLK/100) #define MPUPLL_N (OSC-1) #define MPUPLL_M2 1 -- 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 v3] Allow AM335x MPU core clock speed to be specified in the board config file
On 04/03/13 11:14, Wolfgang Denk wrote: Dear Mark Jackson, In message 51346856.8020...@mimc.co.uk you wrote: Allow AM335x MPU core clock speed to be specified in the board config file. To use, add the following to the board's config file:- #define CONFIG_SYS_MPUCLKdesired clock freq in Hz Why do you claim an accuracy of Hz here, when in the code you silently throw away any sub-MHz parts anyway? Why not leaving it at MHz as it was before, and as used in the code? I was simply copying the format of the existing V_OSCK defines, but I'm happy to change it. Regards Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] Allow AM335x MPU core clock speed to be specified in the board config file
Allow AM335x MPU core clock speed to be specified in the board config file. To use, add the following to the board's config file:- #define CONFIG_SYS_MPUCLK desired clock freq in MHz Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v4: - Now defined as MHz (not Hz) Changes in v3: - Changed from V_MPUCLK to CONFIG_SYS_MPUCLK - Added entry in README Changes in v2: - Tweaked after comments from Peter Korsgaard README |4 arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |7 +-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/README b/README index d8cb394..ddf6df2 100644 --- a/README +++ b/README @@ -3820,6 +3820,10 @@ Low Level (hardware related) configuration options: If defined, the x86 reset vector code is included. This is not needed when U-Boot is running from Coreboot. +- CONFIG_SYS_MPUCLK + Defines the MPU clock speed (in MHz). + + NOTE : currently only supported on AM335x platforms. Freescale QE/FMAN Firmware Support: --- diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h index d748dd2..2d96007 100644 --- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h +++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h @@ -21,8 +21,11 @@ #define OSC(V_OSCK/100) -/* MAIN PLL Fdll = 550 MHZ, */ -#define MPUPLL_M 550 +/* MAIN PLL Fdll = 550 MHz, by default */ +#ifndef CONFIG_SYS_MPUCLK +#define CONFIG_SYS_MPUCLK 550 +#endif +#define MPUPLL_M CONFIG_SYS_MPUCLK #define MPUPLL_N (OSC-1) #define MPUPLL_M2 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Remounting UBI image leads to ECC errors
On 26/02/13 15:11, Mark Jackson wrote: We have a custom made AM335x board I'm working on and I have encountered a problem when mounting an ubifs image from nand. If I ... (1) Write an ubifs image to nand (2) Mount the ubifs image (3) Repeat step (2) ... this then corrupts the ubifs image. Below is a full log. Can anyone help ? Does anyone have any thoughts on this issue ? Can someone confirm that they can repeat my test and it works / fails for them ? Regards Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Allow AM335x MPU core clock speed to be specified in the board config file
Allow AM335x MPU core clock speed to be specified in the board config file. To use, add the following to the board's config file:- #define V_MPUCLKdesired clock freq in Hz Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h index d748dd2..acfa355 100644 --- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h +++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h @@ -22,7 +22,11 @@ #define OSC(V_OSCK/100) /* MAIN PLL Fdll = 550 MHZ, */ +#ifdef V_MPUCLK +#define MPUPLL_M (V_MPUCLK/100) +#else #define MPUPLL_M 550 +#endif #define MPUPLL_N (OSC-1) #define MPUPLL_M2 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Allow AM335x MPU core clock speed to be specified in the board config file
Allow AM335x MPU core clock speed to be specified in the board config file. To use, add the following to the board's config file:- #define V_MPUCLKdesired clock freq in Hz Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v2: - Tweaked after comments from Peter Korsgaard arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h index d748dd2..f1a8aa7 100644 --- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h +++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h @@ -21,8 +21,11 @@ #define OSC(V_OSCK/100) -/* MAIN PLL Fdll = 550 MHZ, */ -#define MPUPLL_M 550 +/* MAIN PLL Fdll = 550 MHZ, by default */ +#ifndef V_MPUCLK +#define V_MPUCLK 55000 +#endif +#define MPUPLL_M (V_MPUCLK/100) #define MPUPLL_N (OSC-1) #define MPUPLL_M2 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Remounting UBI image leads to ECC errors
We have a custom made AM335x board I'm working on and I have encountered a problem when mounting an ubifs image from nand. If I ... (1) Write an ubifs image to nand (2) Mount the ubifs image (3) Repeat step (2) ... this then corrupts the ubifs image. Below is a full log. Can anyone help ? Regards Mark J. --- U-Boot SPL 2013.01-00336-g044fbc4-dirty (Feb 26 2013 - 14:07:36) U-Boot 2013.01-00336-g044fbc4-dirty (Feb 26 2013 - 14:07:36) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: 256 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401000 using PIO, IRQ 0 Net: cpsw U-Boot# nandecc hw 2 HW BCH8 selected U-Boot# mw.b 8200 ff 81f000 U-Boot# dhcp 8200 10.0.0.100:/nanobone/rootfs.ubifs link up on port 0, speed 100, full duplex BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 46 *** Unhandled DHCP Option in OFFER/ACK: 46 DHCP client bound to address 10.0.0.104 Using cpsw device TFTP from server 10.0.0.100; our IP address is 10.0.0.104 Filename '/nanobone/rootfs.ubifs'. Load address: 0x8200 Loading: # # # # # # # 657.2 KiB/s done Bytes transferred = 6029312 (5c hex) U-Boot# nand erase 20 400 NAND erase: device 0 offset 0x20, size 0x400 Erasing at 0x41e -- 100% complete. OK U-Boot# nand write 8200 20 81f000 NAND write: device 0 offset 0x20, size 0x81f000 8515584 bytes written: OK U-Boot# nandecc hw 2 HW BCH8 selected U-Boot# mtdparts default U-Boot# ubi part rootfs Creating 1 MTD partitions on nand0: 0x0020-0x0420 : mtd=6 UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:129024 bytes UBI: smallest flash I/O unit:2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset:2048 UBI: volume 0 (root) re-sized from 44 to 503 LEBs UBI: attached mtd1 to ubi0 UBI: MTD device name:mtd=6 UBI: MTD device size:64 MiB UBI: number of good PEBs:512 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold:4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 0 UBI: total number of reserved PEBs: 512 UBI: number of PEBs reserved for bad PEB handling: 5 UBI: max/mean erase counter: 1/0 U-Boot# nandecc hw 2 HW BCH8 selected U-Boot# mtdparts default U-Boot# ubi part rootfs UBI: mtd1 is detached from ubi0 Creating 1 MTD partitions on nand0: 0x0020-0x0420 : mtd=6 UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:129024 bytes UBI: smallest flash I/O unit:2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset:2048 ECC: uncorrectable. ECC: uncorrectable. UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 510:0, read 64 bytes ECC: uncorrectable. ECC: uncorrectable. UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 510:512, read 512 bytes ECC: uncorrectable. ECC: uncorrectable. UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 511:0, read 64 bytes ECC: uncorrectable. ECC: uncorrectable. UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 511:512, read 512 bytes ECC: uncorrectable. ECC: uncorrectable. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AM335x PLL configuration
All the current TI AM335x boards currently appear to start with an MPU clock of 550MHx and a core clock of 1GHz, based on #defines in include/asm/arch-am33xx/clocks_am33xx.h I assume most people then pass control over to (eg) cpufreq once Linux boots. However I would like to just boot up at the max clock speed (i.e. 720MHz). Is there any merit in reworking this to allow the clock speeds to be specified in the config heaeder file ? Or would it be better to allow the board init code to adjust the clock settings on-the-fly ? I could just add some extra code to my own board.c file, but that doesn't seem like a very elegant solution !! Maybe someone else already has a solution for this ? Cheers Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AM335x : failure to boot SPL from NAND
On 19/02/13 14:55, Mark Jackson wrote: On 18/02/13 14:54, Tom Rini wrote: On Mon, Feb 18, 2013 at 02:43:47PM +, Mark Jackson wrote: On 15/02/13 21:13, Tom Rini wrote: On Thu, Feb 14, 2013 at 03:54:23PM +, Mark Jackson wrote: I'm trying to diagnose why our AM335x based CPU board (based on the AM335x Starter Kit) can boot SPL and U-Boot from an MMC card, but is unable to boot from NAND (connected to CS0). Just a quick update (in case anyone else is in the same boat) ... Looks like the upper data bus (AD[15:8]) needs to have pullups on it, even though you're booting from an 8bit device. Just to update this ... *pulldowns* (not pullups) were needed to get it to boot reliably. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Initialise correct GPMC WAITx irq for AM33xx
Currently WAIT0 irq is reset and then WAIT1 irq is enabled. Fix it such that WAIT0 irq is enabled instead. Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/cpu/armv7/am33xx/mem.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/am33xx/mem.c b/arch/arm/cpu/armv7/am33xx/mem.c index b8f54ab..b86b0de 100644 --- a/arch/arm/cpu/armv7/am33xx/mem.c +++ b/arch/arm/cpu/armv7/am33xx/mem.c @@ -83,7 +83,7 @@ void gpmc_init(void) /* global settings */ writel(0x0008, gpmc_cfg-sysconfig); writel(0x0100, gpmc_cfg-irqstatus); - writel(0x0200, gpmc_cfg-irqenable); + writel(0x0100, gpmc_cfg-irqenable); writel(0x0012, gpmc_cfg-config); /* * Disable the GPMC0 config set by ROM code -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AM335x : failure to boot SPL from NAND
On 18/02/13 14:54, Tom Rini wrote: On Mon, Feb 18, 2013 at 02:43:47PM +, Mark Jackson wrote: On 15/02/13 21:13, Tom Rini wrote: On Thu, Feb 14, 2013 at 03:54:23PM +, Mark Jackson wrote: I'm trying to diagnose why our AM335x based CPU board (based on the AM335x Starter Kit) can boot SPL and U-Boot from an MMC card, but is unable to boot from NAND (connected to CS0). Just a quick update (in case anyone else is in the same boat) ... Looks like the upper data bus (AD[15:8]) needs to have pullups on it, even though you're booting from an 8bit device. I guess the AM335x internal boot code assumes everything is 16bit (even though SYSBOOT[8] is used to configure 8/16bit device). Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Allow AM33xx boards to setup GPMC chipselects.
Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects. Changes in V3: - Fix line wrapping Changes in V2: - Indicate this is for AM33xx (not OMAP2) Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, +u32 size); void omap_nand_switch_ecc(int); #endif -- 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 v2] Allow AM33xx boards to setup GPMC chipselects.
On 17/02/13 20:11, Peter Korsgaard wrote: Mark == Mark Jackson mpfj-l...@mimc.co.uk writes: Mark Expose the enable_gpmc_cs_config() function so AM33xx based boards can Mark register GPMC chip selects. Mark Changes in V2: Mark - Indicate this is for AM33xx (not OMAP2) Mark Signed-off-by: Mark Jackson m...@newflow.co.uk Mark --- Mark arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ Mark 1 file changed, 2 insertions(+) Mark diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark b/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark index 588d8de..97ab60d 100644 Mark --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); Mark void sdelay(unsigned long); Mark void gpmc_init(void); Mark +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs Mark *cs, u32 base, Mark + u32 size); Seems like your mailer line wrapped the patch. Oops ... resent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] Allow AM33xx boards to setup GPMC chipselects.
Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects. Changes in V4: - Fix checkpatch errors (TAB - space mangling) Changes in V3: - Fix line wrapping Changes in V2: - Indicate this is for AM33xx (not OMAP2) Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, + u32 size); void omap_nand_switch_ecc(int); #endif -- 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 v3] Allow AM33xx boards to setup GPMC chipselects.
On 18/02/13 11:01, Peter Korsgaard wrote: Mark == Mark Jackson mpfj-l...@mimc.co.uk writes: Mark Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects. Mark Changes in V3: Mark - Fix line wrapping Mark Changes in V2: Mark - Indicate this is for AM33xx (not OMAP2) Mark Signed-off-by: Mark Jackson m...@newflow.co.uk Mark --- Mark arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ Mark 1 file changed, 2 insertions(+) Mark diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark index 588d8de..97ab60d 100644 Mark --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h Mark @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); Mark void sdelay(unsigned long); Mark void gpmc_init(void); Mark +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, Mark +u32 size); Checkpatch still complains. How about wrapping after *cs, and properly aligning the next line? G ... stupid mailer programs !! Hopefully v4 is now correct ... Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AM335x : failure to boot SPL from NAND
On 15/02/13 21:13, Tom Rini wrote: On Thu, Feb 14, 2013 at 03:54:23PM +, Mark Jackson wrote: I'm trying to diagnose why our AM335x based CPU board (based on the AM335x Starter Kit) can boot SPL and U-Boot from an MMC card, but is unable to boot from NAND (connected to CS0). Following the TI wiki (http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Flashing_images_to_NAND_in_SD_boot) I:- (1) boot from MMC (2) erase the nand (3) copy MLO from MMC into NAND (4) verified it copied correctly (using crc32) When I reboot the board in NAND mode, I get nothing on UART0. If I reboot in MMC mode, SPL and U-Boot load correctly. Can anyone give me some pointers on the boot sequence, and where I might look to help debug the problem ? Assuming you're using mainline U-Boot and can rule out vendor problems, if you can access the SYSBOOT pins, set it up for a mode that does NAND and UART. If you never see the 'CCC' on console (or only see it the first time if you do UART then NAND), then you are starting SPL and dying in there. If you just see a stream of C then your file is not written to NAND correctly. Interesting ... I don't get any 'CCC' on the console. However, I then tested this by booting via MMC, erasing the NAND chip and then trying to reboot via NAND again. I still get no 'CCC' on the console !?! This is using boot mode 10011 (NAND, NANDI2C, MMC0, UART0), so I would expect to either boot via MMC (if I left it in) or get some 'CCC' output on the console. I can see that the NAND signals always have a burst of activity every 10ms. That must be a timeout of some sort ... do you know if that's a hardware or software timeout ? Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AM335x : failure to boot SPL from NAND
I'm trying to diagnose why our AM335x based CPU board (based on the AM335x Starter Kit) can boot SPL and U-Boot from an MMC card, but is unable to boot from NAND (connected to CS0). Following the TI wiki (http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Flashing_images_to_NAND_in_SD_boot) I:- (1) boot from MMC (2) erase the nand (3) copy MLO from MMC into NAND (4) verified it copied correctly (using crc32) When I reboot the board in NAND mode, I get nothing on UART0. If I reboot in MMC mode, SPL and U-Boot load correctly. Can anyone give me some pointers on the boot sequence, and where I might look to help debug the problem ? Regards Mark JACKSON ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Allow OMAP2 boards to setup GPMC chipselects.
On 12/02/13 17:01, Tom Rini wrote: On Mon, Feb 11, 2013 at 04:29:03PM +, Mark Jackson wrote: Expose the enable_gpmc_cs_config() function so OMAP2 boards can register GPMC chipselects. Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, + u32 size); void omap_nand_switch_ecc(int); #endif Can you please correct the description? You're exposing the function for am33xx not omap2. Otherwise fine with me, and I assume you need this on a custom board (aside: the function already exists/is used in arch/arm/cpu/armv7/am33xx/mem.c). Are you planning to submit that support as well? Thanks! Sure ... I'll repost with the comment changed. Yes ... I've not written my own version, I'm using the existing code. And, yes, I've a new CPU board I'm working on, which I'll submit later (once we've done a hardware re-spin). Cheers Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Allow AM33xx boards to setup GPMC chipselects.
Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects. Changes in V2: - Indicate this is for AM33xx (not OMAP2) Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, + u32 size); void omap_nand_switch_ecc(int); #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Allow OMAP2 boards to setup GPMC chipselects.
Expose the enable_gpmc_cs_config() function so OMAP2 boards can register GPMC chipselects. Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, + u32 size); void omap_nand_switch_ecc(int); #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Latest u-boot-atmel git hangs on AVR32 board
Hi
Our MIMC200 board has been using 2009.08 for some time, so I thought I would
take a look at the
latest git version to keep our boards more up-to-date.
I have checked out the u-boot-atmel branch, and done:-
$ make mimc200_config
$ make
Everything compiles, but when I try the image, I only get:-
U-Boot 2011.06-rc2-02816-g5f2e176 (Jun 13 2011 - 12:50:29)
U-Boot code: - 00012668 data: 0001ae38 - 00050840
LCD: Frame buffer allocated at preset 0x1060
VMR table @ 0x11fca7f4
I have traced through the code to see where things stop, and it seems to be in:-
arch/avr32/cpu/at32ap700x/mmu.c
void mmu_init_r(unsigned long dest_addr)
{
...
printf(VMR table @ 0x%08x\n, vmr_table_addr);
/* Enable paging */
puts(a);
sysreg_write(MMUCR, SYSREG_BF(DRP, 1) | SYSREG_BF(DLA, 1)
| SYSREG_BIT(MMUCR_S) | SYSREG_BIT(M) | SYSREG_BIT(E));
puts(b);
}
I get the VMR table ... string, as well as a, but I never get b.
Can anyone help ?
Regards
Mark
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] avr32 portmux : fix incorrect port mask
The portmux peripheral pin selection code used when setting up the MACB1 ethernet port has a small (but critical !!) typo. Signed-off-by: Mark Jackson m...@mimc.co.uk --- cpu/at32ap/at32ap700x/portmux.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/at32ap/at32ap700x/portmux.c b/cpu/at32ap/at32ap700x/portmux.c index b1f2c6f..a60288f 100644 --- a/cpu/at32ap/at32ap700x/portmux.c +++ b/cpu/at32ap/at32ap700x/portmux.c @@ -122,7 +122,7 @@ void portmux_enable_macb1(unsigned long flags, unsigned long drive_strength) portd_mask |= (1 15);/* SPD */ /* REVISIT: Some pins are probably pure outputs */ - portmux_select_peripheral(PORTMUX_PORT_D, portc_mask, + portmux_select_peripheral(PORTMUX_PORT_D, portd_mask, PORTMUX_FUNC_B, PORTMUX_BUSKEEPER); portmux_select_peripheral(PORTMUX_PORT_C, portc_mask, PORTMUX_FUNC_B, PORTMUX_BUSKEEPER); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32 portmux : fix incorrect port mask
Hans-Christian Egtvedt wrote: On Mon, 19 Oct 2009 10:49:00 +0100 Mark Jackson mpfj-l...@mimc.co.uk wrote: The portmux peripheral pin selection code used when setting up the MACB1 ethernet port has a small (but critical !!) typo. It does? Where is this fixed in the patch? Not sure what you mean ... Signed-off-by: Mark Jackson m...@mimc.co.uk --- cpu/at32ap/at32ap700x/portmux.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/at32ap/at32ap700x/portmux.c b/cpu/at32ap/at32ap700x/portmux.c index b1f2c6f..a60288f 100644 --- a/cpu/at32ap/at32ap700x/portmux.c +++ b/cpu/at32ap/at32ap700x/portmux.c @@ -122,7 +122,7 @@ void portmux_enable_macb1(unsigned long flags, unsigned long drive_strength) portd_mask |= (1 15);/* SPD */ /* REVISIT: Some pins are probably pure outputs */ -portmux_select_peripheral(PORTMUX_PORT_D, portc_mask, +portmux_select_peripheral(PORTMUX_PORT_D, portd_mask, This replaces portc_mask with portd_mask, which looks indeed correcter. ... and this looks like a simple typo to me !?! Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32 portmux : fix incorrect port mask
Hans-Christian Egtvedt wrote: On Mon, 19 Oct 2009 11:35:40 +0100 Mark Jackson mpfj-l...@mimc.co.uk wrote: Hans-Christian Egtvedt wrote: On Mon, 19 Oct 2009 10:49:00 +0100 Mark Jackson mpfj-l...@mimc.co.uk wrote: The portmux peripheral pin selection code used when setting up the MACB1 ethernet port has a small (but critical !!) typo. It does? Where is this fixed in the patch? Not sure what you mean ... Aha, rereading I get it, I thought you were fixing an actual !! typo somewhere in the code. Ho, ho ... I guess my comment is a bit misleading :-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
Chris Moore wrote:
I agree wholeheartedly with the idea but shouldn't it be more like this
(untested) code :
void * memcpy(void *dest, const void *src, size_t count)
{
char *d8, *s8;
unsigned long *dl = dest, *sl = src;
In here, would it be overkill to add byte copying until data is aligned, and
then fall into the aligned copy code.
In that case, you'd still gain a speed increase if you're starting at an
unaligned
address ?
/* while all data is aligned (common case), copy multiple bytes at a
time */
if ( (((int)(long)dest | (int)(long)src) (sizeof(*dl) - 1)) == 0) {
while (count = sizeof(*dl)) {
*dl++ = *sl++;
count -= sizeof(*dl);
}
}
d8 = (char *)dl;
s8 = (char *)sl;
/* copy any remaining data byte by byte */
while (count--)
*d8++ = *s8++;
return dest;
}
Regards
Mark
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] unable to configure eth0 on DM6446 using filesystem
rohan tabish wrote: Hye guys i am trying to put linux on my custom board DM6446.I am done with the UBL,U-BOOT ,uImage(kernel) and the filesystem. Have refrred the busybox as my file system.I am using the open source code from git.Here is what i get snip The ethernet works well in the u-boot but it is not working in the kernel ... By your own admission, you have no problem with U-Boot, so I'd suggest trying a Linux mailing (eg LKML) ??? Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Virtual addresses, u-boot, and the MMU
Becky Bruce wrote:
snip
This is where Detlev's comment about using the chance to define a
cache API comes into play.
Yes, we probably should create a set of functions like
enable_data_cache(address, size);
and
disable_data_cache(address, size);
which would turn on resp. off the caching attributes on the given
memory range.
snip
Using a completely different address range instead is a different
thing, and not what I have in mind. I really dislike the idea of
supporting alternate addresses in this context - even if this is
what would be easiest to implement on some architectures.
I agree, but, then, I'm coming from an architecture where doing this is
bad joo-joo. Again, it looks like AVR may actually need this -
hopefully someone who knows more about AVR will speak up here.
Although I wouldn't consider myself an AVR32 expert, I am following
this thread closely. It seems to me that the above 2 functions could be
used to support Detlev's idea as well as Haavard's map_physmem() idea.
The functions could also return (architecture dependant) a remapped
address to be used, then we could support:-
(1) AVR32-type cache which is based on different address ranges
Here the xxx_data_cache() functions would flush the cache, and return
a new address that points to the relevant cached / uncached section of
memory.
(2) Platforms with single address ranges but finer cache control
These would flush the cache, adjust the caching for the memory range as
required, and then just return the *same* address (since no address
re-mapping is required).
The functions using xxx_data_cache() would then code up as follows:-
void foo(address, size) {
uncached_address = disable_data_cache(address, size);
/*
* ... do some code using only uncached_address ...
*/
cached_address = enable_data_cache(address, size);
}
Regards
Mark
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR
Haavard Skinnemoen wrote: snip Right...I'm beginning to doubt that anyone is familiar enough with the u-boot code, since everyone seems to have their own opinion about how things are supposed to work. To summarize, here are the possible ways to fix the problem as I see it: - Use virtual address in CONFIG_ENV_ADDR to conform with the way the CFI driver currently works. Rejected by Wolfgang because virtual addresses don't exist. - Fix the API and user interface breakage by reverting commit 09ce9921. Rejected because virtual addresses are used everywhere. - Fix it by using map_physmem() in a way that works for all architectures. Rejected because all other architectures than PPC are evil and need to be punished for doing things differently. Your triple revert patch doesn't look overly complex, and seems to only add a few map_physmem() calls (I'm summarising *quite* a bit there !!). Is there not some way using weak functions (or similar) to add some AVR32 specific workarounds. Or ... there's *plenty* of arch specific #ifdefs in most of the rest of u-boot, so could we not just #ifdef AVR32 the existing code for the time being until this sticking point gets unstuck ? - Introduce a custom flash driver for ATNGW100. Rejected because stupid principles are more important than making things work. So I don't really know where to proceed from here. I guess two additional options are forking the damn thing or creating a proprietary bootloader, but I don't really want to do either. Me neither !! Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR
Haavard Skinnemoen wrote: Ever since the CFI driver was rewritten to use virtual addresses, thus eliminating the whole point of the map_physmem() macro, ATNGW100 has been broken like this: How about other boards (like the MIMC200) ? Aren't *all* AVR32 boards affected in this way ? Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR
Haavard Skinnemoen wrote: Mark Jackson mpfj-l...@mimc.co.uk wrote: Haavard Skinnemoen wrote: Possibly, but NGW100 is the only one which I've seen reports about. STK1000 is safe since it doesn't use the CFI driver. I did kinda report this in the thread JFFS2 scanning bug, and the triple-revert patch you posted on 26/05/09 16:58 appeared to fix it. Ah...so it breaks JFFS2 as well? I doubt that changing the environment address fixes that... Since this didn't change any board files (only the core CFI files) I guess I assumed this revert would work its way upstream and I wouldn't have to change anything. Hmm, yeah, maybe I should post the revert again. I have to admit I'm completely confused about how u-boot deals with virtual and physical addresses these days. It used to expose only physical addresses through external interfaces, but now it looks like it's a bit of both, and it's impossible to tell which goes where. Shall I just submit a patch to fix the mimc200 board in the same way as your NGW100 patch ? Yes, that will probably be a good idea if it has the same problem with saveenv. Okay ... looks like there are 2 problems revolving round CFI. (1) saveenv (2) jffs2 The CONFIG_ENV_ADDR patch fixes (1) but *not* (2). The triple-revert patch fixes both (1) and (2). Not quite sure how to proceed from here. For the time being, I'll go down the triple-revert patch route until something better pops up !! Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MIMC200: set default fbmem value
This patch adds a default bootargs fbmem value to the CONFIG_BOOTARGS string for the MIMC200 board. Signed-off-by: Mark Jackson m...@mimc.co.uk --- include/configs/mimc200.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/mimc200.h b/include/configs/mimc200.h index 8f71664..36488b3 100644 --- a/include/configs/mimc200.h +++ b/include/configs/mimc200.h @@ -74,7 +74,7 @@ #define CONFIG_BAUDRATE115200 #define CONFIG_BOOTARGS \ - root=/dev/mtdblock1 rootfstype=jffs2 console=ttyS1 + root=/dev/mtdblock1 rootfstype=jffs2 fbmem=512k console=ttyS1 #define CONFIG_BOOTCOMMAND \ fsload boot/uImage; bootm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MIMC200: reduce LCD pixclock
[Resent to add CC u-b...@lists.denx.de]
The initial pixclock for the MIMC200 board is wrong (and causes
screen corruption due to DMA underruns).
This patch simply reduces the pixel clock to fix the problem.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
board/mimc/mimc200/mimc200.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/mimc/mimc200/mimc200.c b/board/mimc/mimc200/mimc200.c
index b773c1a..0dcacb9 100644
--- a/board/mimc/mimc200/mimc200.c
+++ b/board/mimc/mimc200/mimc200.c
@@ -38,7 +38,7 @@
vidinfo_t panel_info = {
.vl_col = 480, /* Number of columns */
.vl_row = 272, /* Number of rows */
- .vl_clk = 1000, /* pixel clock in ps */
+ .vl_clk = 500, /* pixel clock in ps */
.vl_sync= ATMEL_LCDC_INVCLK_INVERTED |
ATMEL_LCDC_INVLINE_INVERTED |
ATMEL_LCDC_INVFRAME_INVERTED,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Add AVR32 LCD support
This patch adds support for the AVR32 LCD controller. This patch is
based off the latest u-boot-video.
A quick summary of what's going on:-
Enable LCDC pixel clock
Enable LCDC port pins
Add framebuffer pointer to global_data struct
Allocate framebuffer
To use the new code, update your board config to include something like
this:-
#define CONFIG_LCD 1
#if defined(CONFIG_LCD)
#define CONFIG_CMD_BMP
#define CONFIG_ATMEL_LCD1
#define LCD_BPP LCD_COLOR16
#define CONFIG_BMP_16BPP1
#define CONFIG_FB_ADDR 0x1060
#define CONFIG_WHITE_ON_BLACK 1
#define CONFIG_VIDEO_BMP_GZIP 1
#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE 262144
#define CONFIG_ATMEL_LCD_BGR555 1
#define CONFIG_SYS_CONSOLE_IS_IN_ENV1
#define CONFIG_SPLASH_SCREEN1
#endif
The standard U-Boot BMP and Splash-screen features should just work.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
cpu/at32ap/at32ap700x/clk.c |5 +
cpu/at32ap/at32ap700x/portmux.c | 90 +
include/asm-avr32/arch-at32ap700x/chip-features.h |5 +
include/asm-avr32/arch-at32ap700x/clk.h |6 ++
include/asm-avr32/arch-at32ap700x/portmux.h |5 +-
include/asm-avr32/global_data.h |3 +
lib_avr32/board.c | 11 +++
7 files changed, 124 insertions(+), 1 deletions(-)
diff --git a/cpu/at32ap/at32ap700x/clk.c b/cpu/at32ap/at32ap700x/clk.c
index 2c2e19c..742bc6b 100644
--- a/cpu/at32ap/at32ap700x/clk.c
+++ b/cpu/at32ap/at32ap700x/clk.c
@@ -65,6 +65,11 @@ void clk_init(void)
#ifdef CONFIG_PLL
/* Use PLL0 as main clock */
sm_writel(PM_MCCTRL, SM_BIT(PLLSEL));
+
+#ifdef CONFIG_LCD
+ /* Set up pixel clock for the LCDC */
+ sm_writel(PM_GCCTRL(7), SM_BIT(PLLSEL) | SM_BIT(CEN));
+#endif
#endif
}
diff --git a/cpu/at32ap/at32ap700x/portmux.c b/cpu/at32ap/at32ap700x/portmux.c
index 2a3b004..e71b2bf 100644
--- a/cpu/at32ap/at32ap700x/portmux.c
+++ b/cpu/at32ap/at32ap700x/portmux.c
@@ -202,3 +202,93 @@ void portmux_enable_spi1(unsigned long cs_mask, unsigned
long drive_strength)
PORTMUX_DIR_OUTPUT | PORTMUX_INIT_HIGH);
}
#endif
+
+#ifdef AT32AP700x_CHIP_HAS_LCDC
+void portmux_enable_lcdc(int pin_config)
+{
+ unsigned long portc_mask = 0;
+ unsigned long portd_mask = 0;
+ unsigned long porte_mask = 0;
+
+ switch(pin_config) {
+ case 0:
+ portc_mask = (1 19) /* CC */
+ | (1 20) /* HSYNC */
+ | (1 21) /* PCLK */
+ | (1 22) /* VSYNC */
+ | (1 23) /* DVAL */
+ | (1 24) /* MODE */
+ | (1 25) /* PWR*/
+ | (1 26) /* DATA0 */
+ | (1 27) /* DATA1 */
+ | (1 28) /* DATA2 */
+ | (1 29) /* DATA3 */
+ | (1 30) /* DATA4 */
+ | (1 31);/* DATA5 */
+
+ portd_mask = (1 0) /* DATA6 */
+ | (1 1) /* DATA7 */
+ | (1 2) /* DATA8 */
+ | (1 3) /* DATA9 */
+ | (1 4) /* DATA10 */
+ | (1 5) /* DATA11 */
+ | (1 6) /* DATA12 */
+ | (1 7) /* DATA13 */
+ | (1 8) /* DATA14 */
+ | (1 9) /* DATA15 */
+ | (1 10) /* DATA16 */
+ | (1 11) /* DATA17 */
+ | (1 12) /* DATA18 */
+ | (1 13) /* DATA19 */
+ | (1 14) /* DATA20 */
+ | (1 15) /* DATA21 */
+ | (1 16) /* DATA22 */
+ | (1 17);/* DATA23 */
+ break;
+
+ case 1:
+ portc_mask = (1 20) /* HSYNC */
+ | (1 21) /* PCLK */
+ | (1 22) /* VSYNC */
+ | (1 25) /* PWR*/
+ | (1 31);/* DATA5 */
+
+ portd_mask = (1 0) /* DATA6 */
+ | (1 1) /* DATA7 */
+ | (1 7) /* DATA13 */
+ | (1 8) /* DATA14 */
+ | (1 9) /* DATA15 */
+ | (1 16) /* DATA22 */
+ | (1 17);/* DATA23 */
+
+ porte_mask = (1 0) /* CC */
+ | (1 1) /* DVAL */
+ | (1 2) /* MODE */
+ | (1 3
[U-Boot] [PATCH] Add 16bit colour support in lcd.h
This patch adds support for LCD_COLOR16 in include/lcd.h. Signed-off-by: Mark Jackson m...@mimc.co.uk --- include/lcd.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/lcd.h b/include/lcd.h index f054cac..0d6549c 100644 --- a/include/lcd.h +++ b/include/lcd.h @@ -314,7 +314,7 @@ void lcd_show_board_info(void); #if LCD_BPP == LCD_MONOCHROME # define COLOR_MASK(c) ((c) | (c) 1 | (c) 2 | (c) 3 | \ (c) 4 | (c) 5 | (c) 6 | (c) 7) -#elif LCD_BPP == LCD_COLOR8 +#elif (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16) # define COLOR_MASK(c) (c) #else # error Unsupported LCD BPP. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove static declaration from gunzip_bmp()
This patch removes the static declaration from gunzip_bmp()
Without it, the gunzip_bmp() function is not visible to
common/lcd.c and fails to compile with an error.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
common/cmd_bmp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index fc8462e..27d5896 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -46,7 +46,7 @@ int gunzip(void *, int, unsigned char *, unsigned long *);
* didn't contain a valid BMP signature.
*/
#ifdef CONFIG_VIDEO_BMP_GZIP
-static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
{
void *dst;
unsigned long len;
@@ -85,7 +85,7 @@ static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned
long *lenp)
return bmp;
}
#else
-static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
{
return NULL;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add LCD support to MIMC200 board
This patch updates the MIMC200 files to enable the LCD.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
board/mimc/mimc200/mimc200.c | 34 ++
include/configs/mimc200.h| 16
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/board/mimc/mimc200/mimc200.c b/board/mimc/mimc200/mimc200.c
index 6df741e..78441c3 100644
--- a/board/mimc/mimc200/mimc200.c
+++ b/board/mimc/mimc200/mimc200.c
@@ -28,10 +28,40 @@
#include asm/arch/gpio.h
#include asm/arch/hmatrix.h
#include asm/arch/portmux.h
+#include atmel_lcdc.h
#include lcd.h
#include ../../../cpu/at32ap/hsmc3.h
+#if defined(CONFIG_LCD)
+/* 480x272x16 @ 72 Hz */
+vidinfo_t panel_info = {
+ .vl_col = 480, /* Number of columns */
+ .vl_row = 272, /* Number of rows */
+ .vl_clk = 1000, /* pixel clock in ps */
+ .vl_sync= ATMEL_LCDC_INVCLK_INVERTED |
+ ATMEL_LCDC_INVLINE_INVERTED |
+ ATMEL_LCDC_INVFRAME_INVERTED,
+ .vl_bpix= LCD_COLOR16, /* Bits per pixel, 0 =
1, 1 = 2, 2 = 4, 3 = 8, 4 = 16 */
+ .vl_tft = 1,/* 0 = passive, 1 = TFT
*/
+ .vl_hsync_len = 42, /* Length of horizontal
sync */
+ .vl_left_margin = 1,/* Time from sync to
picture */
+ .vl_right_margin= 1,/* Time from picture to
sync */
+ .vl_vsync_len = 1,/* Length of vertical
sync */
+ .vl_upper_margin= 12, /* Time from sync to
picture */
+ .vl_lower_margin= 1,/* Time from picture to
sync */
+ .mmio = LCDC_BASE,/* Memory mapped
registers */
+};
+
+void lcd_enable(void)
+{
+}
+
+void lcd_disable(void)
+{
+}
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
static const struct sdram_config sdram_config = {
@@ -110,6 +140,10 @@ int board_early_init_f(void)
portmux_enable_mmci(0, PORTMUX_MMCI_4BIT, PORTMUX_DRIVE_LOW);
#endif
+#if defined(CONFIG_LCD)
+ portmux_enable_lcdc(1);
+#endif
+
return 0;
}
diff --git a/include/configs/mimc200.h b/include/configs/mimc200.h
index 8ff2f8a..8f71664 100644
--- a/include/configs/mimc200.h
+++ b/include/configs/mimc200.h
@@ -82,6 +82,8 @@
#define CONFIG_DISABLE_CONSOLE 1 /* disable console */
#define CONFIG_SYS_DEVICE_NULLDEV 1 /* include nulldev
device */
+#define CONFIG_LCD 1
+
/*
* Only interrupt autoboot if space is pressed. Otherwise, garbage
* data on the serial line may interrupt the boot sequence.
@@ -127,6 +129,20 @@
#define CONFIG_MMC 1
#define CONFIG_ATMEL_MCI 1
+#if defined(CONFIG_LCD)
+#define CONFIG_CMD_BMP
+#define CONFIG_ATMEL_LCD 1
+#define LCD_BPPLCD_COLOR16
+#define CONFIG_BMP_16BPP 1
+#define CONFIG_FB_ADDR 0x1060
+#define CONFIG_WHITE_ON_BLACK 1
+#define CONFIG_VIDEO_BMP_GZIP 1
+#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE 262144
+#define CONFIG_ATMEL_LCD_BGR5551
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV 1
+#define CONFIG_SPLASH_SCREEN 1
+#endif
+
#define CONFIG_SYS_DCACHE_LINESZ 32
#define CONFIG_SYS_ICACHE_LINESZ 32
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Atmel LCD driver GUARDTIME fix
This patch allows the guard time parameter to be set in the Atmel LCDC driver. By default, the previous value of 1 is used, unless the setting is defined elsewhere. Signed-off-by: Mark Jackson m...@mimc.co.uk --- drivers/video/atmel_lcdfb.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c index 3a51cc7..db86763 100644 --- a/drivers/video/atmel_lcdfb.c +++ b/drivers/video/atmel_lcdfb.c @@ -42,6 +42,9 @@ short console_row; /* configurable parameters */ #define ATMEL_LCDC_CVAL_DEFAULT0xc8 #define ATMEL_LCDC_DMA_BURST_LEN 8 +#ifndef ATMEL_LCDC_GUARD_TIME +#define ATMEL_LCDC_GUARD_TIME 1 +#endif #if defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91CAP9) #define ATMEL_LCDC_FIFO_SIZE 2048 @@ -69,7 +72,7 @@ void lcd_ctrl_init(void *lcdbase) /* Turn off the LCD controller and the DMA controller */ lcdc_writel(panel_info.mmio, ATMEL_LCDC_PWRCON, - 1 ATMEL_LCDC_GUARDT_OFFSET); + ATMEL_LCDC_GUARD_TIME ATMEL_LCDC_GUARDT_OFFSET); /* Wait for the LCDC core to become idle */ while (lcdc_readl(panel_info.mmio, ATMEL_LCDC_PWRCON) ATMEL_LCDC_BUSY) @@ -150,7 +153,7 @@ void lcd_ctrl_init(void *lcdbase) lcdc_writel(panel_info.mmio, ATMEL_LCDC_DMACON, ATMEL_LCDC_DMAEN); lcdc_writel(panel_info.mmio, ATMEL_LCDC_PWRCON, - (1 ATMEL_LCDC_GUARDT_OFFSET) | ATMEL_LCDC_PWR); + (ATMEL_LCDC_GUARD_TIME ATMEL_LCDC_GUARDT_OFFSET) | ATMEL_LCDC_PWR); } ulong calc_fbsize(void) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH ... resent] Atmel LCD driver GUARDTIME fix
This patch correctly sets up the guard time parameter in the Atmel LCDC driver. This works on the AVR32 platform, but needs to be tested under the AT91 platform which shares the same code base. Signed-off-by: Mark Jackson m...@mimc.co.uk --- drivers/video/atmel_lcdfb.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c index 3a51cc7..14f578e 100644 --- a/drivers/video/atmel_lcdfb.c +++ b/drivers/video/atmel_lcdfb.c @@ -42,6 +42,7 @@ short console_row; /* configurable parameters */ #define ATMEL_LCDC_CVAL_DEFAULT 0xc8 #define ATMEL_LCDC_DMA_BURST_LEN 8 +#define ATMEL_LCDC_GUARD_TIME 2 #if defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91CAP9) #define ATMEL_LCDC_FIFO_SIZE 2048 @@ -69,7 +70,7 @@ void lcd_ctrl_init(void *lcdbase) /* Turn off the LCD controller and the DMA controller */ lcdc_writel(panel_info.mmio, ATMEL_LCDC_PWRCON, - 1 ATMEL_LCDC_GUARDT_OFFSET); + ATMEL_LCDC_GUARD_TIME ATMEL_LCDC_GUARDT_OFFSET); /* Wait for the LCDC core to become idle */ while (lcdc_readl(panel_info.mmio, ATMEL_LCDC_PWRCON) ATMEL_LCDC_BUSY) @@ -150,7 +151,7 @@ void lcd_ctrl_init(void *lcdbase) lcdc_writel(panel_info.mmio, ATMEL_LCDC_DMACON, ATMEL_LCDC_DMAEN); lcdc_writel(panel_info.mmio, ATMEL_LCDC_PWRCON, - (1 ATMEL_LCDC_GUARDT_OFFSET) | ATMEL_LCDC_PWR); + (ATMEL_LCDC_GUARD_TIME ATMEL_LCDC_GUARDT_OFFSET) | ATMEL_LCDC_PWR); } ulong calc_fbsize(void) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ... resent] Atmel LCD driver GUARDTIME fix
Mark Jackson wrote: This patch correctly sets up the guard time parameter in the Atmel LCDC driver. This works on the AVR32 platform, but needs to be tested under the AT91 platform which shares the same code base. Signed-off-by: Mark Jackson m...@mimc.co.uk --- drivers/video/atmel_lcdfb.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c index 3a51cc7..14f578e 100644 --- a/drivers/video/atmel_lcdfb.c +++ b/drivers/video/atmel_lcdfb.c @@ -42,6 +42,7 @@ short console_row; /* configurable parameters */ #define ATMEL_LCDC_CVAL_DEFAULT 0xc8 #define ATMEL_LCDC_DMA_BURST_LEN8 +#define ATMEL_LCDC_GUARD_TIME2 This should be ... #define ATMEL_LCDC_CVAL_DEFAULT 0xc8 #define ATMEL_LCDC_DMA_BURST_LEN8 +#define ATMEL_LCDC_GUARD_TIME 2 ... without the extra space at the start. #if defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91CAP9) #define ATMEL_LCDC_FIFO_SIZE2048 @@ -69,7 +70,7 @@ void lcd_ctrl_init(void *lcdbase) /* Turn off the LCD controller and the DMA controller */ lcdc_writel(panel_info.mmio, ATMEL_LCDC_PWRCON, - 1 ATMEL_LCDC_GUARDT_OFFSET); + ATMEL_LCDC_GUARD_TIME ATMEL_LCDC_GUARDT_OFFSET); /* Wait for the LCDC core to become idle */ while (lcdc_readl(panel_info.mmio, ATMEL_LCDC_PWRCON) ATMEL_LCDC_BUSY) @@ -150,7 +151,7 @@ void lcd_ctrl_init(void *lcdbase) lcdc_writel(panel_info.mmio, ATMEL_LCDC_DMACON, ATMEL_LCDC_DMAEN); lcdc_writel(panel_info.mmio, ATMEL_LCDC_PWRCON, - (1 ATMEL_LCDC_GUARDT_OFFSET) | ATMEL_LCDC_PWR); + (ATMEL_LCDC_GUARD_TIME ATMEL_LCDC_GUARDT_OFFSET) | ATMEL_LCDC_PWR); } ulong calc_fbsize(void) My patch has been mangled ... there's an extra space at the start of each unchanged patch line. Any ideas ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Atmel LCD driver GUARDTIME fix
Anatolij Gustschin wrote: Mark Jackson wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: ... does not apply Sorry ... does that mean the patch fails in some way, or that this patch is not relevant ? a...@wker:~/git/u-boot$ patch -p1 --dry-run ~/devel/u-boot-video/\[U-Boot\]\ \[PATCH\]\ Atmel\ LCD\ driver\ GUARDTIME\ fix.eml patching file drivers/video/atmel_lcdfb.c Hunk #1 FAILED at 42. Hunk #2 FAILED at 70. Hunk #3 FAILED at 151. 3 out of 3 hunks FAILED -- saving rejects to file drivers/video/atmel_lcdfb.c.rej please rebase on top of u-boot/master branch. TIA. Hmmm ... this is strange. The patch *is* based on the latest gut master !! I mailed the patch to both u-boot@lists.denx.de and u-b...@avr32linux.org mailing lists (the same email, I just added both ml address in the To: box) Looking at mail that came in on the u-boot ML, I can see that an space at the start of most of the patch lines ... argh !! The patch itself works fine ... it looks like one of the mail servers has mangled my patch. I'll try it again ... and CC you all in. Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Atmel LCD driver GUARDTIME fix
This patch correctly sets up the guard time parameter in the Atmel LCDC driver. This works on the AVR32 platform, but needs to be tested under the AT91 platform which shares the same code base. Signed-off-by: Mark Jackson m...@mimc.co.uk --- drivers/video/atmel_lcdfb.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c index 3a51cc7..14f578e 100644 --- a/drivers/video/atmel_lcdfb.c +++ b/drivers/video/atmel_lcdfb.c @@ -42,6 +42,7 @@ short console_row; /* configurable parameters */ #define ATMEL_LCDC_CVAL_DEFAULT 0xc8 #define ATMEL_LCDC_DMA_BURST_LEN 8 +#define ATMEL_LCDC_GUARD_TIME 2 #if defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91CAP9) #define ATMEL_LCDC_FIFO_SIZE 2048 @@ -69,7 +70,7 @@ void lcd_ctrl_init(void *lcdbase) /* Turn off the LCD controller and the DMA controller */ lcdc_writel(panel_info.mmio, ATMEL_LCDC_PWRCON, - 1 ATMEL_LCDC_GUARDT_OFFSET); + ATMEL_LCDC_GUARD_TIME ATMEL_LCDC_GUARDT_OFFSET); /* Wait for the LCDC core to become idle */ while (lcdc_readl(panel_info.mmio, ATMEL_LCDC_PWRCON) ATMEL_LCDC_BUSY) @@ -150,7 +151,7 @@ void lcd_ctrl_init(void *lcdbase) lcdc_writel(panel_info.mmio, ATMEL_LCDC_DMACON, ATMEL_LCDC_DMAEN); lcdc_writel(panel_info.mmio, ATMEL_LCDC_PWRCON, - (1 ATMEL_LCDC_GUARDT_OFFSET) | ATMEL_LCDC_PWR); + (ATMEL_LCDC_GUARD_TIME ATMEL_LCDC_GUARDT_OFFSET) | ATMEL_LCDC_PWR); } ulong calc_fbsize(void) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Best way to submit this patch
I'm planning to submit a patch to add LCD support to the current main Denx (non-AVR32) git. It consists of the following changes:- cpu/at32ap/at32ap700x/clk.c |5 + cpu/at32ap/at32ap700x/portmux.c | 90 + drivers/video/atmel_lcdfb.c |5 +- include/asm-avr32/arch-at32ap700x/chip-features.h |5 + include/asm-avr32/arch-at32ap700x/clk.h |6 ++ include/asm-avr32/arch-at32ap700x/portmux.h |5 +- include/asm-avr32/global_data.h |3 + include/lcd.h |2 +- lib_avr32/board.c | 11 +++ 9 files changed, 128 insertions(+), 4 deletions(-) Can I submit this as a single patch (since it is *all* related to LCD support), or should I split it up into lots of little patches ? Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Best way to submit this patch
On Thu, 2009-06-04 at 08:29 -0400, Jerry Van Baren wrote: Mark Jackson wrote: I'm planning to submit a patch to add LCD support to the current main Denx (non-AVR32) git. snip Hi Mark, Don't agonize over it, just post the patch. The number of electrons you kill by asking for direction/permission is roughly the same as the number you kill by just submitting the patch. Just hit send already. (Based on the above stats, that is a small patch. Hypothetically, it is cohesive as well. We have insufficient information to throw any hypothetical stones at it.) Okay ... thanks Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add AVR32 LCD support
This patch adds support for the AVR32 LCD controller. This patch is
based off the latest Denx master (not the current AVR32 git).
A quick summary of what's going on:-
Enable LCDC pixel clock
Enable LCDC port pins
Correctly specify LCDC guard time
Add framebuffer pointer to global_data struct
Allocate framebuffer
To use the new code, update your board config to include something like
this:-
#define CONFIG_LCD 1
#if defined(CONFIG_LCD)
#define CONFIG_CMD_BMP
#define CONFIG_ATMEL_LCD1
#define LCD_BPP LCD_COLOR16
#define CONFIG_BMP_16BPP1
#define CONFIG_FB_ADDR 0x1060
#define CONFIG_WHITE_ON_BLACK 1
#define CONFIG_VIDEO_BMP_GZIP 1
#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE 262144
#define CONFIG_ATMEL_LCD_BGR555 1
#define CONFIG_SYS_CONSOLE_IS_IN_ENV1
#define CONFIG_SPLASH_SCREEN1
#endif
The standard U-Boot BMP and Splash-screen features should just work.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
cpu/at32ap/at32ap700x/clk.c |5 +
cpu/at32ap/at32ap700x/portmux.c | 90
+
drivers/video/atmel_lcdfb.c |5 +-
include/asm-avr32/arch-at32ap700x/chip-features.h |5 +
include/asm-avr32/arch-at32ap700x/clk.h |6 ++
include/asm-avr32/arch-at32ap700x/portmux.h |5 +-
include/asm-avr32/global_data.h |3 +
include/lcd.h |2 +-
lib_avr32/board.c | 11 +++
9 files changed, 128 insertions(+), 4 deletions(-)
diff --git a/cpu/at32ap/at32ap700x/clk.c b/cpu/at32ap/at32ap700x/clk.c
index 2c2e19c..742bc6b 100644
--- a/cpu/at32ap/at32ap700x/clk.c
+++ b/cpu/at32ap/at32ap700x/clk.c
@@ -65,6 +65,11 @@ void clk_init(void)
#ifdef CONFIG_PLL
/* Use PLL0 as main clock */
sm_writel(PM_MCCTRL, SM_BIT(PLLSEL));
+
+#ifdef CONFIG_LCD
+ /* Set up pixel clock for the LCDC */
+ sm_writel(PM_GCCTRL(7), SM_BIT(PLLSEL) | SM_BIT(CEN));
+#endif
#endif
}
diff --git a/cpu/at32ap/at32ap700x/portmux.c
b/cpu/at32ap/at32ap700x/portmux.c
index 2a3b004..e71b2bf 100644
--- a/cpu/at32ap/at32ap700x/portmux.c
+++ b/cpu/at32ap/at32ap700x/portmux.c
@@ -202,3 +202,93 @@ void portmux_enable_spi1(unsigned long cs_mask,
unsigned long drive_strength)
PORTMUX_DIR_OUTPUT | PORTMUX_INIT_HIGH);
}
#endif
+
+#ifdef AT32AP700x_CHIP_HAS_LCDC
+void portmux_enable_lcdc(int pin_config)
+{
+ unsigned long portc_mask = 0;
+ unsigned long portd_mask = 0;
+ unsigned long porte_mask = 0;
+
+ switch(pin_config) {
+ case 0:
+ portc_mask = (1 19) /* CC */
+ | (1 20) /* HSYNC */
+ | (1 21) /* PCLK */
+ | (1 22) /* VSYNC */
+ | (1 23) /* DVAL */
+ | (1 24) /* MODE */
+ | (1 25) /* PWR*/
+ | (1 26) /* DATA0 */
+ | (1 27) /* DATA1 */
+ | (1 28) /* DATA2 */
+ | (1 29) /* DATA3 */
+ | (1 30) /* DATA4 */
+ | (1 31);/* DATA5 */
+
+ portd_mask = (1 0) /* DATA6 */
+ | (1 1) /* DATA7 */
+ | (1 2) /* DATA8 */
+ | (1 3) /* DATA9 */
+ | (1 4) /* DATA10 */
+ | (1 5) /* DATA11 */
+ | (1 6) /* DATA12 */
+ | (1 7) /* DATA13 */
+ | (1 8) /* DATA14 */
+ | (1 9) /* DATA15 */
+ | (1 10) /* DATA16 */
+ | (1 11) /* DATA17 */
+ | (1 12) /* DATA18 */
+ | (1 13) /* DATA19 */
+ | (1 14) /* DATA20 */
+ | (1 15) /* DATA21 */
+ | (1 16) /* DATA22 */
+ | (1 17);/* DATA23 */
+ break;
+
+ case 1:
+ portc_mask = (1 20) /* HSYNC */
+ | (1 21) /* PCLK */
+ | (1 22) /* VSYNC */
+ | (1 25) /* PWR*/
+ | (1 31);/* DATA5 */
+
+ portd_mask = (1 0) /* DATA6 */
+ | (1 1) /* DATA7 */
+ | (1 7) /* DATA13 */
+ | (1 8) /* DATA14 */
+ | (1 9) /* DATA15 */
+ | (1 16) /* DATA22 */
+ | (1 17);/* DATA23
Re: [U-Boot] JFFS2 scanning bug
On 14/03/09 00:59, Ilya Yanok wrote: Hi Mark, snip I'll prepare the patch and will post it in some days. (We can just drop the above two lines and it should work but the most clean way would be to calculate sector_size after flash_init() and then just use that value but that means a lot of patching... Maybe someone has any ideas?) Has any progress been made with this ? The v2009 code still seems to suffer from this. Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Fix JFFS2 NOR sector size routine
On 11/03/09 18:29, Scott Wood wrote:
On Wed, Mar 11, 2009 at 09:54:20AM +, Mark Jackson wrote:
diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c
index d0a7cea..2f3b3a9 100644
--- a/common/cmd_jffs2.c
+++ b/common/cmd_jffs2.c
@@ -1814,7 +1814,12 @@ static inline u32 get_part_sector_size_nor(struct
mtdids *id, struct part_info *
flash =flash_info[id-num];
start_phys = flash-start[0] + part-offset;
-end_phys = start_phys + part-size;
+
+if (part-size == SIZE_REMAINING) {
+end_phys = start_phys + flash-size;
+} else {
+end_phys = start_phys + part-size;
+}
That looks wrong if part-offset != 0; shouldn't it be:
if (part-size == SIZE_REMAINING)
end_phys = flash-start[0] + flash-size;
else
end_phys = start_phys + part-size;
?
-Scott
Yes ... that seems perfectly reasonable !!
I'll update my patch, retest and resubmit.
Thanks
Mark
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] Fix JFFS2 NOR sector size routine
This patch fixes the JFFS2 scanning code when not using
CONFIG_JFFS2_CMDLINE.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
common/cmd_jffs2.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c
index d0a7cea..2f3b3a9 100644
--- a/common/cmd_jffs2.c
+++ b/common/cmd_jffs2.c
@@ -1814,7 +1814,12 @@ static inline u32 get_part_sector_size_nor(struct
mtdids *id, struct part_info *
flash = flash_info[id-num];
start_phys = flash-start[0] + part-offset;
- end_phys = start_phys + part-size;
+
+ if (part-size == SIZE_REMAINING) {
+ end_phys = start_phys + flash-size;
+ } else {
+ end_phys = start_phys + part-size;
+ }
for (i = 0; i flash-sector_count; i++) {
if (flash-start[i] = end_phys)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 scanning bug
On 26/02/09 14:48, Ilya Yanok wrote:
Hi Mark,
Mark Jackson wrote:
I've just updated from v2008.10 to v2009.01 on my AVR32 board (MIMC200).
JFFS2 no longer works (it hangs at Scanning JFFS2 FS:, so I've done a git
bisect, and here's the result:-
[snip]
Is this a known problem ?
No, I've never heard of it. Could you please be more specific? What type
of flash do you using? What is the size of your JFFS2 partition? How did
you create your filesystem?
The JFFS image was made using Buildroot, and I think it's just over 5MBytes
(size = 0x4d bytes).
The image itself is fine, since if I install v2008.10, the target boots (into
Linux) as expected.
The flash is an 8MByte device (Spansion P/N S29GL064N90TFI04).
I have taken an existing, working board, and simply installed v2009.01 (rather
than v2008.10). The target boots into U-Boot fine, and I can read / write the
env variables, and, obviously, I'm able to write U-Boot itself !!
flinfo returns the following:-
U-Boot flinfo
Bank # 1: CFI conformant FLASH (16 x 16) Size: 8 MB in 135 Sectors
AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E
Erase timeout: 16384 ms, write timeout: 2 ms
Buffer write timeout: 5 ms, buffer size: 32 bytes
Sector Start Addresses:
RO 2000 RO 4000 RO 6000 RO 8000 RO
A000 RO C000 RO E000 RO 0001 RO 0002
00030004000500060007
00080009000A000B000C
000D000E000F00100011
00120013001400150016
001700180019001A001B
001C001D001E001F0020
00210022002300240025
0026002700280029002A
002B002C002D002E002F
00300031003200330034
00350036003700380039
003A003B003C003D003E
003F0040004100420043
00440045004600470048
0049004A004B004C004D
004E004F005000510052
00530054005500560057
00580059005A005B005C
005D005E005F00600061
00620063006400650066
006700680069006A006B
006C006D006E006F0070
00710072007300740075
0076007700780079007A
007B007C007D007E007F RO
Under v2008.10, when I do an 'ls', the line Scanning JFFS2 FS: is shown,
along with a spinning - \ | / - character sequence.
Under v2009.01, the Scanning JFFS2 FS: text is shown and the target appears
to hang (i.e. no spinning cursor, just a solid cursor).
I have also tried a new board (with blanked flash). Under v2008.10 'ls' comes
up with a filesystem not found type of error. Under v2009.01, again the
target just appears to hang.
I guessed that no-one else has this problem (since the bad commit was back in
November), but it's definitely broken for me !!
I'm happy to help diagnose / fault find.
Regards
Mark
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 scanning bug
On 26/02/09 15:46, Ilya Yanok wrote: Hi Mark, Don't you have JTAG debugger so you could find where exactly it hangs? Or you can try adding debugging printf's to the source... I can't reproduce your problem myself so that info would be useful. Regards, Ilya. I do have a JTAG unit, but it'll be quicker for me to just use some debug printf's. I'll report back when I've found the problem. Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1 v2] Setup extra MIMC200 chip selects
Added code to setup the extra Flash and FRAM chip selects as used on the MIMC200 board. V2 moves the init code from the common cpu.c file into the board specific setup file. Signed-off-by: Mark Jackson m...@mimc.co.uk --- board/mimc/mimc200/mimc200.c | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/board/mimc/mimc200/mimc200.c b/board/mimc/mimc200/mimc200.c index 8516dcb..423238b 100644 --- a/board/mimc/mimc200/mimc200.c +++ b/board/mimc/mimc200/mimc200.c @@ -29,6 +29,8 @@ #include asm/arch/hmatrix.h #include lcd.h +#include ../../../cpu/at32ap/hsmc3.h + #define SM_PM_GCCTRL 0x0060 DECLARE_GLOBAL_DATA_PTR; @@ -98,6 +100,18 @@ int board_early_init_f(void) /* release phys reset */ gpio_set_value(GPIO_PIN_PC18, 0); /* PHY RESET (Release) */ + /* setup Data Flash chip select (NCS2) */ + hsmc3_writel(MODE2, 0x20121003); + hsmc3_writel(CYCLE2, 0x000a0009); + hsmc3_writel(PULSE2, 0x0a060806); + hsmc3_writel(SETUP2, 0x00030102); + + /* setup FRAM chip select (NCS3) */ + hsmc3_writel(MODE3, 0x10120001); + hsmc3_writel(CYCLE3, 0x001e001d); + hsmc3_writel(PULSE3, 0x08040704); + hsmc3_writel(SETUP3, 0x02050204); + #if defined(CONFIG_MACB) /* init macb0 pins */ gpio_select_periph_A(GPIO_PIN_PC3, 0); /* TXD0 */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Setup extra MIMC200 chip selects
Wolfgang Denk wrote: Dear Mark Jackson, In message 492a8d60.3090...@mimc.co.uk you wrote: Added code to setup the extra Flash and FRAM chip selects as used on the MIMC200 board. Signed-off-by: Mark Jackson m...@mimc.co.uk --- cpu/at32ap/cpu.c | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) snip I feel it is conceptually wrong to add board specific code to a common CPU specific file. I do agree !! Is there something in place (like the gclk setup) to allow me to do this ? Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add 16bpp BMP support
Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message pine.lnx.4.64.0901302206180.4...@axis700.grange you wrote: platform-specific types and code. So, looking at this your patch - do we really need the one more CONFIG_ define for CONFIG_BMP_16BPP? What are the drawbacks of adding your code unconditionally? extra 100 bytes for all configurations using LCD? Yes. In fact, there's almost a case for adding *even more* #defines to remove the 1bpp and 8bpp code when you've #defined your board to use 16bpp. Another question - do you really need 16bpp bmp? I saw a discussion on this list, that other picture formats should not be added to U-Boot - you can easily convert any format to bmp. Are 256 colours really not enough for you? I used a real photo today as a test image, converted to an 8-bit bmp. It looked well enough on my qvga. And normally you use this lcd code to display a splashscreen, which is usually a computer-generated image, so 256 colours should suffice? Although, I am not an expert in graphical desing. I can understand that 8 bpp doe snot satisfy anoybode with more than just basic graphics needs. Exactly ... in my case, I boot up linux which is also using 16bpp. My aim was to have the bootsplash image displayed by u-boot, and remain *intact* throughtout the linux boot sequence. Switching from 8bpp (in u-boot) to 16bpp (in linux) would cause some nasty screen corruption, and require the image to be re-displayed, which kind of spoils the whole concept of a boot logo. If we really add more bmp formats, we also get more combinations like of bmp / lcd: Not necessarily. We can always request that bitmap images match the natural color depth of the display. It makes no sense to send a 16 bpp image to a 1 bpp display, nor does it vice versa. As far as I understand, U-boot was not written be some fully-fledged OS ... rather to just allow a smooth transition from power-on to real OS. Thus we only need to support some fairly simple combinations of options, but enough to keep the majority happy. I guess up till now, 1bpp and 8bpp have been sufficient. BMP LCD 1-bit1-bit 8-bit1-bit 16-bit 1-bit 1-bit8-bit ... if we really want to go that way, maybe better break this code into several functions for different format conversions? We do NOT want to do everything that is possible, but only what is reasonable. Exactly ... otherwise where do you stop ? JPG, GIF, TIFF, PNG, etc ? We're *only* meant to be showing a simply boot up image (not view lots of different sized photos or movies !!), in a very controlled environment (i.e. no user options ... just what the designers want / require). Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add 16bpp BMP support
Wolfgang Denk wrote: Dear Mark Jackson, In message 49817e75.7060...@mimc.co.uk you wrote: snip Or have I misunderstood the bmp format and the existing code ? I don't know - I'm just asking because the 16 bpp case is different from the 1 and 8 bpp cases where the operands are swapped. It works for me ... is that enough ? Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add 16bpp BMP support
Wolfgang Denk wrote: Dear Mark Jackson, In message 497f1732.6050...@mimc.co.uk you wrote: This patch adds 16bpp BMP support to the common lcd code. Use CONFIG_BMP_16BPP and set LCD_BPP to LCD_COLOR16 to enable the code. At the moment it's only been tested on the MIMC200 AVR32 board, but extending this to other platforms should be a simple task !! Signed-off-by: Mark Jackson m...@mimc.co.uk --- common/lcd.c | 49 +++-- 1 files changed, 39 insertions(+), 10 deletions(-) diff --git a/common/lcd.c b/common/lcd.c index ae79051..16d6f2a 100644 --- a/common/lcd.c +++ b/common/lcd.c snip +bmap += (padded_line - width) * 2; +fb -= (width * 2 + lcd_line_length); Is it intentional that you reverse padded_line and width here, i.e. you are sure it's not bmap += (width - padded_line) * 2; ? The bmap += ... line is to step forward to the start of the next line of bmp data, taking into account any padding bytes. If I read the code correct, padded_line is defined as ... padded_line = (width0x3) ? ((width~0x3)+4) : (width); ... so it will always be = width. Correct ? If so, then ... bmap += (width - padded_line) * 2; ... will be = 0, and so will actually step bmap back into the data you've just used, whereas ... bmap += (padded_line - width) * 2; ... will be = 0, and will step forward to the start of the next line as required. Or have I misunderstood the bmp format and the existing code ? Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
