[U-Boot] [PATCH V2 0/3] ARM: DRA74x: Provide support for ARM erratum 801819
Provide support ARM erratum 801819 with capability to disable write streaming. Obvioulsy on SMP systems such as DRA74x/OMAP5, this will benefit only CPU0. CPU1 when made online in HLOS such as linux kernel will need similar workaround as well. Ignoring v1 of the patch completely here. Nishanth Menon (3): ARM: Introduce erratum workaround for 801819 ARM: DRA7/ OMAP5: implement Auxiliary Control Register configuration ARM: DRA72: disable workaround for 801819 README | 1 + arch/arm/cpu/armv7/omap5/hwinit.c | 17 + arch/arm/cpu/armv7/start.S | 21 + arch/arm/include/asm/arch-omap5/sys_proto.h | 1 + 4 files changed, 40 insertions(+) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/3] ARM: Introduce erratum workaround for 801819
Add workaround for Cortex-A15 ARM erratum 801819 which says in summary
that "A livelock can occur in the L2 cache arbitration that might
prevent a snoop from completing. Under certain conditions this can
cause the system to deadlock. "
Recommended workaround is as follows:
Do both of the following:
1) Do not use the write-back no-allocate memory type.
2) Do not issue write-back cacheable stores at any time when the cache
is disabled (SCTLR.C=0) and the MMU is enabled (SCTLR.M=1). Because it
is implementation defined whether cacheable stores update the cache when
the cache is disabled it is not expected that any portable code will
execute cacheable stores when the cache is disabled.
For implementations of Cortex-A15 configured without the “L2 arbitration
register slice” option (typically one or two core systems), you must
also do the following:
3) Disable write-streaming in each CPU by setting ACTLR[28:25] = 0b
So, we provide an option to disable write streaming on OMAP5 and DRA7.
It is a rare condition to occur and may be enabled selectively based
on platform acceptance of risk.
Applies to: A15 revisions r2p0, r2p1, r2p2, r2p3 or r2p4 and REVIDR[3]
is set to 0.
Note: certain unicore SoCs *might* not have REVIDR[3] not set, but
might not meet the condition for the erratum to occur when they donot
have ACP (Accelerator Coherency Port) hooked to ACE (AXI Coherency
Extensions). Such SoCs will need the work around handled in the SoC
specific manner, since there is no ARM generic manner to detect such
configurations.
Based on ARM errata Document revision 18.0 (22 Nov 2013)
Suggested-by: Richard Woodruff
Suggested-by: Brad Griffis
Reviewed-by: Brad Griffis
Signed-off-by: Nishanth Menon
---
README | 1 +
arch/arm/cpu/armv7/start.S | 21 +
2 files changed, 22 insertions(+)
diff --git a/README b/README
index 4e0ff9f74e59..55834ee3c465 100644
--- a/README
+++ b/README
@@ -705,6 +705,7 @@ The following options need to be configured:
CONFIG_ARM_ERRATA_454179
CONFIG_ARM_ERRATA_621766
CONFIG_ARM_ERRATA_798870
+ CONFIG_ARM_ERRATA_801819
- Tegra SoC options:
CONFIG_TEGRA_SUPPORT_NON_SECURE
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 1c7e6f01f941..b18094447b06 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -187,6 +187,27 @@ ENTRY(cpu_init_cp15)
skip_errata_798870:
#endif
+#ifdef CONFIG_ARM_ERRATA_801819
+ cmp r2, #0x24 @ Applies to lt including R2p4
+ bgt skip_errata_801819 @ skip if not affected rev
+ cmp r2, #0x20 @ Applies to including and above R2p0
+ blt skip_errata_801819 @ skip if not affected rev
+ mrc p15, 0, r0, c0, c0, 6 @ pick up REVIDR reg
+ and r0, r0, #1 << 3 @ check REVIDR[3]
+ cmp r0, #1 << 3
+ beq skip_errata_801819 @ skip erratum if REVIDR[3] is set
+
+ mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
+ orr r0, r0, #3 << 27@ Disables streaming. All write-allocate
+ @ lines allocate in the L1 or L2 cache.
+ orr r0, r0, #3 << 25@ Disables streaming. All write-allocate
+ @ lines allocate in the L1 cache.
+ push{r1-r5} @ Save the cpu info registers
+ bl v7_arch_cp15_set_acr
+ pop {r1-r5} @ Restore the cpu info - fall through
+skip_errata_801819:
+#endif
+
#ifdef CONFIG_ARM_ERRATA_454179
cmp r2, #0x21 @ Only on < r2p1
bge skip_errata_454179
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/3] ARM: DRA72: disable workaround for 801819
DRA72x processor variants are single core and it does not export ACP[1].
Hence, we have no source for generating an external snoop requests which
appear to be key to the deadlock in DRA72x design.
Since we build the same image for DRA74x and DRA72x platforms, lets
runtime detect and disable the workaround (in favor of performance) on
DRA72x platforms.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438i/BABIAJAG.html
Suggested-by: Richard Woodruff
Suggested-by: Brad Griffis
Reviewed-by: Brad Griffis
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap5/hwinit.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index bc19aebc6db7..22e0829a6a0c 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -422,5 +422,16 @@ void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32
cpu_midr,
void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
u32 cpu_variant, u32 cpu_rev)
{
+
+#ifdef CONFIG_ARM_ERRATA_801819
+ /*
+* DRA72x processors are uniprocessors and DONOT have
+* ACP (Accelerator Coherency Port) hooked to ACE (AXI Coherency
+* Extensions) Hence the erratum workaround is not applicable for
+* DRA72x processors.
+*/
+ if (is_dra72x())
+ acr &= ~((0x3 << 23) | (0x3 << 25));
+#endif
omap_smc1(OMAP5_SERVICE_ACR_SET, acr);
}
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/3] ARM: DRA7/ OMAP5: implement Auxiliary Control Register configuration
Implement logic for ACR(Auxiliary Control Register) configuration using
ROM Code smc service.
Suggested-by: Richard Woodruff
Suggested-by: Brad Griffis
Reviewed-by: Brad Griffis
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap5/hwinit.c | 6 ++
arch/arm/include/asm/arch-omap5/sys_proto.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 39f8d0d5e200..bc19aebc6db7 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -418,3 +418,9 @@ void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32
cpu_midr,
{
omap_smc1(OMAP5_SERVICE_L2ACTLR_SET, l2auxctrl);
}
+
+void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
+ u32 cpu_variant, u32 cpu_rev)
+{
+ omap_smc1(OMAP5_SERVICE_ACR_SET, acr);
+}
diff --git a/arch/arm/include/asm/arch-omap5/sys_proto.h
b/arch/arm/include/asm/arch-omap5/sys_proto.h
index 6da8297c7292..7fcb78389403 100644
--- a/arch/arm/include/asm/arch-omap5/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap5/sys_proto.h
@@ -81,5 +81,6 @@ static inline u32 usec_to_32k(u32 usec)
}
#define OMAP5_SERVICE_L2ACTLR_SET0x104
+#define OMAP5_SERVICE_ACR_SET0x107
#endif
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] drivers: Introduce a simplified remoteproc framework
On Thu, Aug 27, 2015 at 10:49 AM, Simon Glass wrote: > +U-Boot Aaah.. i missed a reply-all, did'nt I?.. Sorry about that. > > On 26 August 2015 at 16:51, Nishanth Menon wrote: >> On Tue, Aug 25, 2015 at 9:26 PM, Simon Glass wrote: >>> >>>>>> +#include/* For platform data support - non dt >>>>>> world */ >>>>> >>>>> Does this need to be supported for a new uclass? >>>> >>>> we do have platforms that are not using DT yet... they will need to pass >>>> platform data. >>> >>> Is this a good opportunity to convert them? >> >> It might be better not to hold the platforms hostage yet -> at least >> the TI ones(which depend on this series) are already in the pipe for >> conversion - the journey will take some time to complete though. > > That seems OK, but please add a comment that new platforms should not > use the platform data. > That is fair enough. will definitely do that. thanks for the suggestion. -- --- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/4] remoteproc: Introduce a sandbox dummy driver
Introduce a dummy driver for sandbox that allows us to verify basic
functionality. This is not meant to do anything functional - but is
more or less meant as a framework plumbing debug helper.
The sandbox remoteproc driver maintains absolutey no states and is a
simple driver which just is filled with empty hooks. Idea being to give
an approximate idea to implement own remoteproc driver using this as a
template.
Signed-off-by: Nishanth Menon
---
Changes in V2:
- review comments incorporated from v1
V1: https://patchwork.ozlabs.org/patch/510197/
drivers/remoteproc/Kconfig| 9 +
drivers/remoteproc/Makefile | 3 +
drivers/remoteproc/sandbox_testproc.c | 336 ++
3 files changed, 348 insertions(+)
create mode 100644 drivers/remoteproc/sandbox_testproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 444682624ace..437224b5491f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -12,4 +12,13 @@ config REMOTEPROC
bool
depends on DM
+# Please keep the configuration alphabetically sorted.
+config REMOTEPROC_SANDBOX
+ bool "Support for Test processor for Sandbox"
+ select REMOTEPROC
+ depends on DM
+ depends on SANDBOX
+ help
+ Say 'y' here to add support for test processor which does dummy
+ operations for sandbox platform.
endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 14c27929b63e..720aa6e64701 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -5,3 +5,6 @@
#
obj-$(CONFIG_REMOTEPROC) += rproc-uclass.o
+
+# Remote proc drivers - Please keep this list alphabetically sorted.
+obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
diff --git a/drivers/remoteproc/sandbox_testproc.c
b/drivers/remoteproc/sandbox_testproc.c
new file mode 100644
index ..cb56f7e46ed1
--- /dev/null
+++ b/drivers/remoteproc/sandbox_testproc.c
@@ -0,0 +1,336 @@
+/*
+ * (C) Copyright 2015
+ * Texas Instruments Incorporated - http://www.ti.com/
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#define pr_fmt(fmt) "%s: " fmt, __func__
+#include
+#include
+#include
+#include
+
+/**
+ * enum sandbox_state - different device states
+ * @sb_booted: Entry condition, just booted
+ * @sb_init: Initialized (basic environment is ready)
+ * @sb_reset: Held in reset (accessible, but not running)
+ * @sb_loaded: Loaded with image (but not running)
+ * @sb_running:Processor is running
+ */
+enum sandbox_state {
+ sb_booted,
+ sb_init,
+ sb_reset,
+ sb_loaded,
+ sb_running
+};
+
+/**
+ * struct sandbox_test_devdata - private data per device
+ * @current_state: device current state
+ */
+struct sandbox_test_devdata {
+ enum sandbox_state current_state;
+};
+
+/**
+ * sandbox_dev_move_to_state() - statemachine for our dummy device
+ * @dev: device to switch state
+ * @next_state:next proposed state
+ *
+ * This tries to follow the following statemachine:
+ * Entry
+ *|
+ *v
+ * +---+
+ * +---+ init |
+ * | | | <-+
+ * | +---+ |
+ * | |
+ * | |
+ * | ++ |
+ * Load| | reset | |
+ * | || <--+ |
+ * | ++| |
+ * ||Load| |
+ * ||| |
+ * | +v+ reset | |
+ * +-> | |(opt) | |
+ * | Loaded +---+ |
+ * | | |
+ * +++ |
+ * | Start|
+ * +---v-+(opt) |
+ * +->| Running |Stop|
+ * Ping +- | ++
+ * (opt)+-+
+ *
+ * (is_running does not change state)
+ *
+ * Return: 0 when valid state transition is seen, else returns -EINVAL
+ */
+static int sandbox_dev_move_to_state(struct udevice *dev,
+enum sandbox_state next_state)
+{
+ struct sandbox_test_devdata *ddata = dev_get_priv(dev);
+
+ /* No state transition is OK */
+ if (ddata->current_state == next_state)
+ return 0;
+
+ debug("current_state=%d, next_state=%d\n", ddata->current_state,
+ next_state);
+ switch (ddata->current_state) {
+ case sb_booted:
+ if (next_state == sb_init)
+ goto ok_state;
+ break;
+
+ case sb_init:
+ if (next_state == sb_reset || next_state == sb_loaded)
+ goto ok_state;
+
[U-Boot] [PATCH V2 4/4] test: Add basic tests for remoteproc
Use the sandbox environment for the basic tests.
Signed-off-by: Nishanth Menon
---
New patch.
test/dm/Makefile | 1 +
test/dm/remoteproc.c | 67
2 files changed, 68 insertions(+)
create mode 100644 test/dm/remoteproc.c
diff --git a/test/dm/Makefile b/test/dm/Makefile
index eda964318593..7b3626cb3294 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_DM_MMC) += mmc.o
obj-$(CONFIG_DM_PCI) += pci.o
obj-$(CONFIG_RAM) += ram.o
obj-y += regmap.o
+obj-$(CONFIG_REMOTEPROC) += remoteproc.o
obj-$(CONFIG_RESET) += reset.o
obj-$(CONFIG_DM_RTC) += rtc.o
obj-$(CONFIG_DM_SPI_FLASH) += sf.o
diff --git a/test/dm/remoteproc.c b/test/dm/remoteproc.c
new file mode 100644
index ..924eae854078
--- /dev/null
+++ b/test/dm/remoteproc.c
@@ -0,0 +1,67 @@
+/*
+ * (C) Copyright 2015
+ * Texas Instruments Incorporated - http://www.ti.com/
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+/**
+ * dm_test_remoteproc_base() - test the operations after initializations
+ * @uts: unit test state
+ *
+ * Return: 0 if test passed, else error
+ */
+static int dm_test_remoteproc_base(struct unit_test_state *uts)
+{
+ if (!rproc_is_initialized())
+ ut_assertok(rproc_init());
+
+ /* Ensure we are initialized */
+ ut_asserteq(true, rproc_is_initialized());
+
+
+ /* platform data device 1 */
+ ut_assertok(rproc_stop(0));
+ ut_assertok(rproc_reset(0));
+ /* -> invalid attempt tests.. */
+ ut_asserteq(-EINVAL, rproc_start(0));
+ ut_asserteq(-EINVAL, rproc_ping(0));
+ /* Valid tests.. */
+ ut_assertok(rproc_load(0, 1, 0));
+ ut_assertok(rproc_start(0));
+ ut_assertok(rproc_is_running(0));
+ ut_assertok(rproc_ping(0));
+ ut_assertok(rproc_reset(0));
+ ut_assertok(rproc_stop(0));
+
+ /* dt device device 1 */
+ ut_assertok(rproc_stop(1));
+ ut_assertok(rproc_reset(1));
+ ut_assertok(rproc_load(1, 1, 0));
+ ut_assertok(rproc_start(1));
+ ut_assertok(rproc_is_running(1));
+ ut_assertok(rproc_ping(1));
+ ut_assertok(rproc_reset(1));
+ ut_assertok(rproc_stop(1));
+
+ /* dt device device 2 */
+ ut_assertok(rproc_stop(0));
+ ut_assertok(rproc_reset(0));
+ /* -> invalid attempt tests.. */
+ ut_asserteq(-EINVAL, rproc_start(0));
+ ut_asserteq(-EINVAL, rproc_ping(0));
+ /* Valid tests.. */
+ ut_assertok(rproc_load(2, 1, 0));
+ ut_assertok(rproc_start(2));
+ ut_assertok(rproc_is_running(2));
+ ut_assertok(rproc_ping(2));
+ ut_assertok(rproc_reset(2));
+ ut_assertok(rproc_stop(2));
+
+ return 0;
+}
+DM_TEST(dm_test_remoteproc_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/4] drivers: Introduce a simplified remoteproc framework
Many System on Chip(SoC) solutions are complex with multiple processors
on the same die dedicated to either general purpose of specialized
functions. Many examples do exist in today's SoCs from various vendors.
Typical examples are micro controllers such as an ARM M3/M0 doing a
offload of specific function such as event integration or power
management or controlling camera etc.
Traditionally, the responsibility of loading up such a processor with a
firmware and communication has been with a High Level Operating
System(HLOS) such as Linux. However, there exists classes of products
where Linux would need to expect services from such a processor or the
delay of Linux and operating system being able to load up such a
firmware is unacceptable.
To address these needs, we need some minimal capability to load such a
system and ensure it is started prior to an Operating System(Linux or
any other) is started up.
NOTE: This is NOT meant to be a solve-all solution, instead, it tries to
address certain class of SoCs and products that need such a solution.
A very simple model is introduced here as part of the initial support
that supports microcontrollers with internal memory (no MMU, no
execution from external memory, or specific image format needs). This
basic framework can then (hopefully) be extensible to other complex SoC
processor support as need be.
Signed-off-by: Nishanth Menon
---
Changes in V2:
- review comments incorporated from v1
V1: https://patchwork.ozlabs.org/patch/510198/
common/Kconfig | 5 +
common/Makefile| 1 +
common/cmd_remoteproc.c| 281
doc/device-tree-bindings/remoteproc/remoteproc.txt | 14 +
doc/driver-model/remoteproc-framework.txt | 168
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/remoteproc/Kconfig | 15 +
drivers/remoteproc/Makefile| 7 +
drivers/remoteproc/rproc-uclass.c | 472 +
include/dm/uclass-id.h | 1 +
include/remoteproc.h | 102 +
12 files changed, 1069 insertions(+)
create mode 100644 common/cmd_remoteproc.c
create mode 100644 doc/device-tree-bindings/remoteproc/remoteproc.txt
create mode 100644 doc/driver-model/remoteproc-framework.txt
create mode 100644 drivers/remoteproc/Kconfig
create mode 100644 drivers/remoteproc/Makefile
create mode 100644 drivers/remoteproc/rproc-uclass.c
create mode 100644 include/remoteproc.h
diff --git a/common/Kconfig b/common/Kconfig
index 88dc0160796e..9bf0559ce2f3 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -344,6 +344,11 @@ config CMD_FPGA
help
FPGA support.
+config CMD_REMOTEPROC
+ bool "remoteproc"
+ depends on REMOTEPROC
+ help
+ Support for Remote Processor control
endmenu
diff --git a/common/Makefile b/common/Makefile
index dc82433e90de..c3a62a2e1379 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -154,6 +154,7 @@ obj-$(CONFIG_CMD_PXE) += cmd_pxe.o
obj-$(CONFIG_CMD_READ) += cmd_read.o
obj-$(CONFIG_CMD_REGINFO) += cmd_reginfo.o
obj-$(CONFIG_CMD_REISER) += cmd_reiser.o
+obj-$(CONFIG_CMD_REMOTEPROC) += cmd_remoteproc.o
obj-$(CONFIG_SANDBOX) += cmd_host.o
obj-$(CONFIG_CMD_SATA) += cmd_sata.o
obj-$(CONFIG_CMD_SF) += cmd_sf.o
diff --git a/common/cmd_remoteproc.c b/common/cmd_remoteproc.c
new file mode 100644
index ..794a406b7828
--- /dev/null
+++ b/common/cmd_remoteproc.c
@@ -0,0 +1,281 @@
+/*
+ * (C) Copyright 2015
+ * Texas Instruments Incorporated - http://www.ti.com/
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * print_remoteproc_list() - print all the remote processor devices
+ *
+ * Return: 0 if no error, else returns appropriate error value.
+ */
+static int print_remoteproc_list(void)
+{
+ struct udevice *dev;
+ struct uclass *uc;
+ int ret;
+ char *type;
+
+ ret = uclass_get(UCLASS_REMOTEPROC, &uc);
+ if (ret) {
+ printf("Cannot find Remote processor class\n");
+ return ret;
+ }
+
+ uclass_foreach_dev(dev, uc) {
+ struct dm_rproc_uclass_pdata *uc_pdata;
+ const struct dm_rproc_ops *ops = rproc_get_ops(dev);
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+
+ switch (uc_pdata->mem_type) {
+ case RPROC_INTERNAL_MEMORY_MAPPED:
+ type = "internal memory mapped";
+ break;
+ default:
+ type = "unknown";
+ break;
+ }
+ printf("%d - Name:'%s' t
[U-Boot] [PATCH V2 0/4] drivers/sandbox: Introduce a simplified remoteproc framework
Many System on Chip(SoC) solutions are complex with multiple processors on the same die dedicated to either general purpose of specialized functions. Many examples do exist in today's SoCs from various vendors. Typical examples are micro controllers such as an ARM M3/M0 doing a offload of specific function such as event integration or power management or controlling camera etc. Traditionally, the responsibility of loading up such a processor with a firmware and communication has been with a High Level Operating System(HLOS) such as Linux. However, there exists classes of products where Linux would need to expect services from such a processor or the delay of Linux and operating system being able to load up such a firmware is unacceptable. The intent here is to introduce a simplified remoteproc framework which can then be used to provide basic services to these remote processors. Series is based on: master 79c884d7e449 Merge git://git.denx.de/u-boot-x86 Changes in V2: - review comments from v1 incorporated - dm test included (patch #4 is new) V1: http://lists.denx.de/pipermail/u-boot/2015-August/225085.html Quick test log: http://pastebin.ubuntu.com/12212006/ Nishanth Menon (4): drivers: Introduce a simplified remoteproc framework remoteproc: Introduce a sandbox dummy driver sandbox: Introduce dummy remoteproc nodes test: Add basic tests for remoteproc arch/sandbox/dts/test.dts | 13 + common/Kconfig | 5 + common/Makefile| 1 + common/cmd_remoteproc.c| 281 configs/sandbox_defconfig | 2 + doc/device-tree-bindings/remoteproc/remoteproc.txt | 14 + doc/driver-model/remoteproc-framework.txt | 168 drivers/Kconfig| 2 + drivers/Makefile | 1 + drivers/remoteproc/Kconfig | 24 ++ drivers/remoteproc/Makefile| 10 + drivers/remoteproc/rproc-uclass.c | 472 + drivers/remoteproc/sandbox_testproc.c | 336 +++ include/dm/uclass-id.h | 1 + include/remoteproc.h | 102 + test/dm/Makefile | 1 + test/dm/remoteproc.c | 67 +++ 17 files changed, 1500 insertions(+) create mode 100644 common/cmd_remoteproc.c create mode 100644 doc/device-tree-bindings/remoteproc/remoteproc.txt create mode 100644 doc/driver-model/remoteproc-framework.txt create mode 100644 drivers/remoteproc/Kconfig create mode 100644 drivers/remoteproc/Makefile create mode 100644 drivers/remoteproc/rproc-uclass.c create mode 100644 drivers/remoteproc/sandbox_testproc.c create mode 100644 include/remoteproc.h create mode 100644 test/dm/remoteproc.c -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/4] sandbox: Introduce dummy remoteproc nodes
Introduce dummy devices for sandbox remoteproc device and enable it by
default
Signed-off-by: Nishanth Menon
---
Changes in V2:
- review comments incorporated from V1.
V1: https://patchwork.ozlabs.org/patch/510196/
arch/sandbox/dts/test.dts | 13 +
configs/sandbox_defconfig | 2 ++
2 files changed, 15 insertions(+)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index c948df8c864b..9e85c2868444 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -12,6 +12,8 @@
eth5 = ð_5;
i2c0 = "/i2c@0";
pci0 = &pci;
+ remoteproc1 = &rproc_1;
+ remoteproc2 = &rproc_2;
rtc0 = &rtc_0;
rtc1 = &rtc_1;
spi0 = "/spi@0";
@@ -226,6 +228,17 @@
compatible = "sandbox,reset";
};
+ rproc_1: rproc@1 {
+ compatible = "sandbox,test-processor";
+ remoteproc-name = "remoteproc-test-dev1";
+ };
+
+ rproc_2: rproc@2 {
+ compatible = "sandbox,test-processor";
+ internal-memory-mapped;
+ remoteproc-name = "remoteproc-test-dev2";
+ };
+
spi@0 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 85ff95df7962..a33a05d08c90 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -54,3 +54,5 @@ CONFIG_UNIT_TEST=y
CONFIG_UT_TIME=y
CONFIG_UT_DM=y
CONFIG_UT_ENV=y
+CONFIG_REMOTEPROC_SANDBOX=y
+CONFIG_CMD_REMOTEPROC=y
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] drivers: Introduce a simplified remoteproc framework
On 21:46-20150901, Simon Glass wrote: Hi Simon, Apologies on a delayed response. [...] > > Changes in V2: > > - review comments incorporated from v1 > > Ah yes, but which ones?! Hopefully all of them - I'd normally list up the details, but the changes were a little too many in the case of v2.. [...] > > > [snip] > > Reviewed-by: Simon Glass Thanks. Will post next rev fixing the nits and picking up your reviewed-by tag. > > A few nits below. Thanks once again for your patience and review. > > + > > +/* > > + * XXX XXX XXX > > + * *IMPORTANT* NOTE: THE PLATFORM DATA SUPPORT IS NOT MEANT FOR USE WITH > > NEWER > > + * PLATFORMS. THIS IS MEANT ONLY FOR LEGACY DEVICES. THIS MODE OF > > + * INITIALIZATION *WILL* BE EVENTUALLY REMOVED ONCE ALL NECESSARY > > + * PLATFORMS HAVE MOVED TO DM/FDT. > > + * XXX XXX XXX > > + */ > > This can be lower case and you should remove the stuff. Will do so in the next rev. > > +/* Accessor */ > > +#define rproc_get_ops(dev) ((struct dm_rproc_ops *)(dev)->driver->ops) > > + > > +#ifdef CONFIG_REMOTEPROC > > +int rproc_init(void); > > +bool rproc_is_initialized(void); > > +int rproc_load(int id, ulong addr, ulong size); > > +int rproc_start(int id); > > +int rproc_stop(int id); > > +int rproc_reset(int id); > > +int rproc_ping(int id); > > +int rproc_is_running(int id); > > Can you move your function comments to here? This where you define > your API, and it is the file that people will read. Will do so as well. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/4] remoteproc: Introduce a sandbox dummy driver
On 21:46-20150901, Simon Glass wrote: > On 27 August 2015 at 22:07, Nishanth Menon wrote: > [...] > Reviewed-by: Simon Glass Thanks. will update and post the next rev with the mentioned changes incorporated. > > Nit below. [...] > > + > > +/* XXX: THIS MUST GO AWAY ALONG WITH NON-DT support.. */ > > /* TODO(y...@email.com): Remove this along with... */ OK. Will add the details. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 4/4] test: Add basic tests for remoteproc
On 21:46-20150901, Simon Glass wrote: > On 27 August 2015 at 22:07, Nishanth Menon wrote: > > Use the sandbox environment for the basic tests. > > > > Signed-off-by: Nishanth Menon > > --- > > New patch. > > > > test/dm/Makefile | 1 + > > test/dm/remoteproc.c | 67 > > > > 2 files changed, 68 insertions(+) > > create mode 100644 test/dm/remoteproc.c > > Reviewed-by: Simon Glass > Tested-by: Simon Glass > > Nit below. Thanks. Will fix the same in the next rev. [...] > > + > > + /* dt device device 2 */ > > + ut_assertok(rproc_stop(0)); > > + ut_assertok(rproc_reset(0)); > > + /* -> invalid attempt tests.. */ > > + ut_asserteq(-EINVAL, rproc_start(0)); > > + ut_asserteq(-EINVAL, rproc_ping(0)); > > + /* Valid tests.. */ > > You don't need a period at the end of these comments\ Yep. Will fix. > > > + ut_assertok(rproc_load(2, 1, 0)); > > + ut_assertok(rproc_start(2)); > > + ut_assertok(rproc_is_running(2)); > > + ut_assertok(rproc_ping(2)); > > + ut_assertok(rproc_reset(2)); > > + ut_assertok(rproc_stop(2)); > > Would it be worth having a test that goes through things in the wrong > sequence? It's up to you. The current tests does attempt to perform basic sanity tests - there are invalid sequence attempts as well. > > BTW you don't have to put all your tests in one function, e.g. if some > have a different purpose you can put them in a separate function. I agree and had started it that way, then as I started putting things together, considering the tests were simple sequence based, they were good enough to put them in the test sequence in one shot. We can definitely evolve as folks find specific needs of improvement in the future. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/4] sandbox: Introduce dummy remoteproc nodes
Introduce dummy devices for sandbox remoteproc device and enable it by
default
Reviewed-by: Simon Glass
Signed-off-by: Nishanth Menon
---
Changes since V2:
- Picked up Simon's reviewed-by from V2.
V2: https://patchwork.ozlabs.org/patch/511750/
V1: https://patchwork.ozlabs.org/patch/510196/
arch/sandbox/dts/test.dts | 13 +
configs/sandbox_defconfig | 2 ++
2 files changed, 15 insertions(+)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index f5217fb87778..730de8a57ffc 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -13,6 +13,8 @@
eth5 = ð_5;
i2c0 = "/i2c@0";
pci0 = &pci;
+ remoteproc1 = &rproc_1;
+ remoteproc2 = &rproc_2;
rtc0 = &rtc_0;
rtc1 = &rtc_1;
spi0 = "/spi@0";
@@ -233,6 +235,17 @@
compatible = "sandbox,reset";
};
+ rproc_1: rproc@1 {
+ compatible = "sandbox,test-processor";
+ remoteproc-name = "remoteproc-test-dev1";
+ };
+
+ rproc_2: rproc@2 {
+ compatible = "sandbox,test-processor";
+ internal-memory-mapped;
+ remoteproc-name = "remoteproc-test-dev2";
+ };
+
spi@0 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index e9e1597f9acf..b9ba04acebe5 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -61,3 +61,5 @@ CONFIG_UNIT_TEST=y
CONFIG_UT_TIME=y
CONFIG_UT_DM=y
CONFIG_UT_ENV=y
+CONFIG_REMOTEPROC_SANDBOX=y
+CONFIG_CMD_REMOTEPROC=y
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/4] drivers: Introduce a simplified remoteproc framework
Many System on Chip(SoC) solutions are complex with multiple processors
on the same die dedicated to either general purpose of specialized
functions. Many examples do exist in today's SoCs from various vendors.
Typical examples are micro controllers such as an ARM M3/M0 doing a
offload of specific function such as event integration or power
management or controlling camera etc.
Traditionally, the responsibility of loading up such a processor with a
firmware and communication has been with a High Level Operating
System(HLOS) such as Linux. However, there exists classes of products
where Linux would need to expect services from such a processor or the
delay of Linux and operating system being able to load up such a
firmware is unacceptable.
To address these needs, we need some minimal capability to load such a
system and ensure it is started prior to an Operating System(Linux or
any other) is started up.
NOTE: This is NOT meant to be a solve-all solution, instead, it tries to
address certain class of SoCs and products that need such a solution.
A very simple model is introduced here as part of the initial support
that supports microcontrollers with internal memory (no MMU, no
execution from external memory, or specific image format needs). This
basic framework can then (hopefully) be extensible to other complex SoC
processor support as need be.
Reviewed-by: Simon Glass
Signed-off-by: Nishanth Menon
---
Changes since V2:(review comment updates)
- Changes to warning for "non-dt" users - lowercase, remove XXX
- Move function documentation to header for exported functions
- Picked up Simon's reviewed tag from V2
V2: https://patchwork.ozlabs.org/patch/511748/
V1: https://patchwork.ozlabs.org/patch/510198/
common/Kconfig | 5 +
common/Makefile| 1 +
common/cmd_remoteproc.c| 281 ++
doc/device-tree-bindings/remoteproc/remoteproc.txt | 14 +
doc/driver-model/remoteproc-framework.txt | 168 +
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/remoteproc/Kconfig | 15 +
drivers/remoteproc/Makefile| 7 +
drivers/remoteproc/rproc-uclass.c | 417 +
include/dm/uclass-id.h | 1 +
include/remoteproc.h | 162
12 files changed, 1074 insertions(+)
create mode 100644 common/cmd_remoteproc.c
create mode 100644 doc/device-tree-bindings/remoteproc/remoteproc.txt
create mode 100644 doc/driver-model/remoteproc-framework.txt
create mode 100644 drivers/remoteproc/Kconfig
create mode 100644 drivers/remoteproc/Makefile
create mode 100644 drivers/remoteproc/rproc-uclass.c
create mode 100644 include/remoteproc.h
diff --git a/common/Kconfig b/common/Kconfig
index 2c42b8e4d034..da68f494b626 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -344,6 +344,11 @@ config CMD_FPGA
help
FPGA support.
+config CMD_REMOTEPROC
+ bool "remoteproc"
+ depends on REMOTEPROC
+ help
+ Support for Remote Processor control
endmenu
diff --git a/common/Makefile b/common/Makefile
index 556fb0759292..6a5d33a90bd0 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -154,6 +154,7 @@ obj-$(CONFIG_CMD_PXE) += cmd_pxe.o
obj-$(CONFIG_CMD_READ) += cmd_read.o
obj-$(CONFIG_CMD_REGINFO) += cmd_reginfo.o
obj-$(CONFIG_CMD_REISER) += cmd_reiser.o
+obj-$(CONFIG_CMD_REMOTEPROC) += cmd_remoteproc.o
obj-$(CONFIG_SANDBOX) += cmd_host.o
obj-$(CONFIG_CMD_SATA) += cmd_sata.o
obj-$(CONFIG_CMD_SF) += cmd_sf.o
diff --git a/common/cmd_remoteproc.c b/common/cmd_remoteproc.c
new file mode 100644
index ..794a406b7828
--- /dev/null
+++ b/common/cmd_remoteproc.c
@@ -0,0 +1,281 @@
+/*
+ * (C) Copyright 2015
+ * Texas Instruments Incorporated - http://www.ti.com/
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * print_remoteproc_list() - print all the remote processor devices
+ *
+ * Return: 0 if no error, else returns appropriate error value.
+ */
+static int print_remoteproc_list(void)
+{
+ struct udevice *dev;
+ struct uclass *uc;
+ int ret;
+ char *type;
+
+ ret = uclass_get(UCLASS_REMOTEPROC, &uc);
+ if (ret) {
+ printf("Cannot find Remote processor class\n");
+ return ret;
+ }
+
+ uclass_foreach_dev(dev, uc) {
+ struct dm_rproc_uclass_pdata *uc_pdata;
+ const struct dm_rproc_ops *ops = rproc_get_ops(dev);
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+
+ switch (uc_pdata->mem_type) {
+ case RPROC_INTERNAL_MEMORY_MAPPED:
+
[U-Boot] [PATCH V3 2/4] remoteproc: Introduce a sandbox dummy driver
Introduce a dummy driver for sandbox that allows us to verify basic
functionality. This is not meant to do anything functional - but is
more or less meant as a framework plumbing debug helper.
The sandbox remoteproc driver maintains absolutey no states and is a
simple driver which just is filled with empty hooks. Idea being to give
an approximate idea to implement own remoteproc driver using this as a
template.
Reviewed-by: Simon Glass
Signed-off-by: Nishanth Menon
---
Changes Since V2:
- Fixed TODO message for removal of non-DT pdata entry
- Picked up Simon's reviewed-by from V2
V2: https://patchwork.ozlabs.org/patch/511747/
V1: https://patchwork.ozlabs.org/patch/510197/
drivers/remoteproc/Kconfig| 9 +
drivers/remoteproc/Makefile | 3 +
drivers/remoteproc/sandbox_testproc.c | 336 ++
3 files changed, 348 insertions(+)
create mode 100644 drivers/remoteproc/sandbox_testproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 444682624ace..437224b5491f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -12,4 +12,13 @@ config REMOTEPROC
bool
depends on DM
+# Please keep the configuration alphabetically sorted.
+config REMOTEPROC_SANDBOX
+ bool "Support for Test processor for Sandbox"
+ select REMOTEPROC
+ depends on DM
+ depends on SANDBOX
+ help
+ Say 'y' here to add support for test processor which does dummy
+ operations for sandbox platform.
endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 14c27929b63e..720aa6e64701 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -5,3 +5,6 @@
#
obj-$(CONFIG_REMOTEPROC) += rproc-uclass.o
+
+# Remote proc drivers - Please keep this list alphabetically sorted.
+obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
diff --git a/drivers/remoteproc/sandbox_testproc.c
b/drivers/remoteproc/sandbox_testproc.c
new file mode 100644
index ..004c7792d186
--- /dev/null
+++ b/drivers/remoteproc/sandbox_testproc.c
@@ -0,0 +1,336 @@
+/*
+ * (C) Copyright 2015
+ * Texas Instruments Incorporated - http://www.ti.com/
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#define pr_fmt(fmt) "%s: " fmt, __func__
+#include
+#include
+#include
+#include
+
+/**
+ * enum sandbox_state - different device states
+ * @sb_booted: Entry condition, just booted
+ * @sb_init: Initialized (basic environment is ready)
+ * @sb_reset: Held in reset (accessible, but not running)
+ * @sb_loaded: Loaded with image (but not running)
+ * @sb_running:Processor is running
+ */
+enum sandbox_state {
+ sb_booted,
+ sb_init,
+ sb_reset,
+ sb_loaded,
+ sb_running
+};
+
+/**
+ * struct sandbox_test_devdata - private data per device
+ * @current_state: device current state
+ */
+struct sandbox_test_devdata {
+ enum sandbox_state current_state;
+};
+
+/**
+ * sandbox_dev_move_to_state() - statemachine for our dummy device
+ * @dev: device to switch state
+ * @next_state:next proposed state
+ *
+ * This tries to follow the following statemachine:
+ * Entry
+ *|
+ *v
+ * +---+
+ * +---+ init |
+ * | | | <-+
+ * | +---+ |
+ * | |
+ * | |
+ * | ++ |
+ * Load| | reset | |
+ * | || <--+ |
+ * | ++| |
+ * ||Load| |
+ * ||| |
+ * | +v+ reset | |
+ * +-> | |(opt) | |
+ * | Loaded +---+ |
+ * | | |
+ * +++ |
+ * | Start|
+ * +---v-+(opt) |
+ * +->| Running |Stop|
+ * Ping +- | ++
+ * (opt)+-+
+ *
+ * (is_running does not change state)
+ *
+ * Return: 0 when valid state transition is seen, else returns -EINVAL
+ */
+static int sandbox_dev_move_to_state(struct udevice *dev,
+enum sandbox_state next_state)
+{
+ struct sandbox_test_devdata *ddata = dev_get_priv(dev);
+
+ /* No state transition is OK */
+ if (ddata->current_state == next_state)
+ return 0;
+
+ debug("current_state=%d, next_state=%d\n", ddata->current_state,
+ next_state);
+ switch (ddata->current_state) {
+ case sb_booted:
+ if (next_state == sb_init)
+ goto ok_state;
+ break;
[U-Boot] [PATCH V3 0/4] drivers/sandbox: Introduce a simplified remoteproc framework
Many System on Chip(SoC) solutions are complex with multiple processors on the same die dedicated to either general purpose of specialized functions. Many examples do exist in today's SoCs from various vendors. Typical examples are micro controllers such as an ARM M3/M0 doing a offload of specific function such as event integration or power management or controlling camera etc. Traditionally, the responsibility of loading up such a processor with a firmware and communication has been with a High Level Operating System(HLOS) such as Linux. However, there exists classes of products where Linux would need to expect services from such a processor or the delay of Linux and operating system being able to load up such a firmware is unacceptable. The intent here is to introduce a simplified remoteproc framework which can then be used to provide basic services to these remote processors. Special thanks to Simon in helping cleaning up the series to a much more better implementation. The series is based on: master fa43ce842c30 Merge git://git.denx.de/u-boot-fdt Changes since V2: - Minor comment updates from V2 - Review and tested tag picked up from V2 V2: http://marc.info/?l=u-boot&m=144073487701030&w=2 V1: http://lists.denx.de/pipermail/u-boot/2015-August/225085.html Test Log: http://pastebin.ubuntu.com/12432507/ Nishanth Menon (4): drivers: Introduce a simplified remoteproc framework remoteproc: Introduce a sandbox dummy driver sandbox: Introduce dummy remoteproc nodes test: Add basic tests for remoteproc arch/sandbox/dts/test.dts | 13 + common/Kconfig | 5 + common/Makefile| 1 + common/cmd_remoteproc.c| 281 ++ configs/sandbox_defconfig | 2 + doc/device-tree-bindings/remoteproc/remoteproc.txt | 14 + doc/driver-model/remoteproc-framework.txt | 168 + drivers/Kconfig| 2 + drivers/Makefile | 1 + drivers/remoteproc/Kconfig | 24 ++ drivers/remoteproc/Makefile| 10 + drivers/remoteproc/rproc-uclass.c | 417 + drivers/remoteproc/sandbox_testproc.c | 336 + include/dm/uclass-id.h | 1 + include/remoteproc.h | 162 test/dm/Makefile | 1 + test/dm/remoteproc.c | 67 17 files changed, 1505 insertions(+) create mode 100644 common/cmd_remoteproc.c create mode 100644 doc/device-tree-bindings/remoteproc/remoteproc.txt create mode 100644 doc/driver-model/remoteproc-framework.txt create mode 100644 drivers/remoteproc/Kconfig create mode 100644 drivers/remoteproc/Makefile create mode 100644 drivers/remoteproc/rproc-uclass.c create mode 100644 drivers/remoteproc/sandbox_testproc.c create mode 100644 include/remoteproc.h create mode 100644 test/dm/remoteproc.c -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 4/4] test: Add basic tests for remoteproc
Use the sandbox environment for the basic tests.
Reviewed-by: Simon Glass
Tested-by: Simon Glass
Signed-off-by: Nishanth Menon
---
Changes since V1:
- Comment cleanup (dropped '..')
- Picked up Simon's Tested and Reviewed tags from V2
V2: https://patchwork.ozlabs.org/patch/511749/
V1: did not exist
test/dm/Makefile | 1 +
test/dm/remoteproc.c | 67
2 files changed, 68 insertions(+)
create mode 100644 test/dm/remoteproc.c
diff --git a/test/dm/Makefile b/test/dm/Makefile
index eda964318593..7b3626cb3294 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_DM_MMC) += mmc.o
obj-$(CONFIG_DM_PCI) += pci.o
obj-$(CONFIG_RAM) += ram.o
obj-y += regmap.o
+obj-$(CONFIG_REMOTEPROC) += remoteproc.o
obj-$(CONFIG_RESET) += reset.o
obj-$(CONFIG_DM_RTC) += rtc.o
obj-$(CONFIG_DM_SPI_FLASH) += sf.o
diff --git a/test/dm/remoteproc.c b/test/dm/remoteproc.c
new file mode 100644
index ..0e5f3305a252
--- /dev/null
+++ b/test/dm/remoteproc.c
@@ -0,0 +1,67 @@
+/*
+ * (C) Copyright 2015
+ * Texas Instruments Incorporated - http://www.ti.com/
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+/**
+ * dm_test_remoteproc_base() - test the operations after initializations
+ * @uts: unit test state
+ *
+ * Return: 0 if test passed, else error
+ */
+static int dm_test_remoteproc_base(struct unit_test_state *uts)
+{
+ if (!rproc_is_initialized())
+ ut_assertok(rproc_init());
+
+ /* Ensure we are initialized */
+ ut_asserteq(true, rproc_is_initialized());
+
+
+ /* platform data device 1 */
+ ut_assertok(rproc_stop(0));
+ ut_assertok(rproc_reset(0));
+ /* -> invalid attempt tests */
+ ut_asserteq(-EINVAL, rproc_start(0));
+ ut_asserteq(-EINVAL, rproc_ping(0));
+ /* Valid tests */
+ ut_assertok(rproc_load(0, 1, 0));
+ ut_assertok(rproc_start(0));
+ ut_assertok(rproc_is_running(0));
+ ut_assertok(rproc_ping(0));
+ ut_assertok(rproc_reset(0));
+ ut_assertok(rproc_stop(0));
+
+ /* dt device device 1 */
+ ut_assertok(rproc_stop(1));
+ ut_assertok(rproc_reset(1));
+ ut_assertok(rproc_load(1, 1, 0));
+ ut_assertok(rproc_start(1));
+ ut_assertok(rproc_is_running(1));
+ ut_assertok(rproc_ping(1));
+ ut_assertok(rproc_reset(1));
+ ut_assertok(rproc_stop(1));
+
+ /* dt device device 2 */
+ ut_assertok(rproc_stop(0));
+ ut_assertok(rproc_reset(0));
+ /* -> invalid attempt tests */
+ ut_asserteq(-EINVAL, rproc_start(0));
+ ut_asserteq(-EINVAL, rproc_ping(0));
+ /* Valid tests */
+ ut_assertok(rproc_load(2, 1, 0));
+ ut_assertok(rproc_start(2));
+ ut_assertok(rproc_is_running(2));
+ ut_assertok(rproc_ping(2));
+ ut_assertok(rproc_reset(2));
+ ut_assertok(rproc_stop(2));
+
+ return 0;
+}
+DM_TEST(dm_test_remoteproc_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot for Arm cortexA8
Alwin, [EMAIL PROTECTED] said the following on 08/20/2008 11:04 PM: > Hi, > > I would like to know if u-boot source code is there for ARM Cortex A8. > TI's OMAP3 processors have Cortex-A8. You can find versions of u-boot for these processors in many places(they are not in mainline u-boot tree yet): For some of the boards, you'd see here: http://linux.omap.com/pub/bootloader/3530evm/ <https://webmail.ti.com/owa/redir.aspx?C=e49298289ff24e8a8c24893ec2dc9e85&URL=http%3a%2f%2flinux.omap.com%2fpub%2fbootloader%2f3530evm%2f> (for 3530EVM) http://linux.omap.com/pub/bootloader/3430zoom/ <https://webmail.ti.com/owa/redir.aspx?C=e49298289ff24e8a8c24893ec2dc9e85&URL=http%3a%2f%2flinux.omap.com%2fpub%2fbootloader%2f3430zoom%2f> (for 3430 Zoom MDK) http://linux.omap.com/pub/bootloader/3430sdp/ <https://webmail.ti.com/owa/redir.aspx?C=e49298289ff24e8a8c24893ec2dc9e85&URL=http%3a%2f%2flinux.omap.com%2fpub%2fbootloader%2f3430sdp%2f> (3430 sdp) http://code.google.com/p/beagleboard/downloads/list <https://webmail.ti.com/owa/redir.aspx?C=e49298289ff24e8a8c24893ec2dc9e85&URL=http%3a%2f%2fcode.google.com%2fp%2fbeagleboard%2fdownloads%2flist> This is beagle board development site. Also uboot-v2 has a limited amount of cortex support (in the mainline tree itself). Steve sakoman maintains a git tree for u-boot v1 which he and Dirk Behme may be planning on pushing in the coming days -> even that has cortex support. Git: http://sakoman.net/git/u-boot-omap3.git/ (there is a branch with omap patches called common, test etc..) <https://webmail.ti.com/owa/redir.aspx?C=e49298289ff24e8a8c24893ec2dc9e85&URL=http%3a%2f%2fsakoman.net%2fgit%2fu-boot-omap3.git%2f> gitweb: http://www.sakoman.net/cgi-bin/gitweb.cgi <https://webmail.ti.com/owa/redir.aspx?C=e49298289ff24e8a8c24893ec2dc9e85&URL=http%3a%2f%2fwww.sakoman.net%2fcgi-bin%2fgitweb.cgi> > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient should > check this email and any attachments for the presence of viruses. The company > accepts no liability for any damage caused by any virus transmitted by this > email. > > www.wipro.com > > By the way, disclaimers such as those above are pretty dis-concerting to an open community I guess looking at previous discussions on the same.. for e.g. see http://www.nabble.com/Help-needed-for-porting-linux-on-mpc8260-based-custom-board-to2182946.html#a2182946 You could probably speak to your IT folks about this.. They might have email list configuration which are white listed and disclaimers would not appear when send to those lists. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] working with loadb & bootm on u-boot-v2 for imx27ads Board
Lejin K Joy said the following on 09/25/2008 05:06 AM: > I want to load the Linux Kernel Zimage on to RAM. As per the documentation > we have used the following command to load zImage using Kermit protocol. > > " U-boot-v2> loadb -c zImage " > > (Also tried " U-boot-v2> loadb -f zImage ") > > Which successfully downloads zimage to the file with default offset set as > 0x. > U-Boot V2 uses a filesystem. when you did loadb -c -f zImage, it downloaded the image to the file called zImage. zImage is stored within the ramfs filesystem. (the concepts are very similar to an OS with restrictions). This is slightly different from what you want to achieve I think. > a) But I am not able to understand to which location in RAM this image is > written to? b) Please let me know how exactly to load kernel image to > specific location on RAM? > Look for the device node which shows the RAM/NOR/NAND you need. this might be /dev/mem or (in my OMAP3430 case) /dev/ram0 - also see "help loadb". Loadb takes the following options: -f file - where to download to -o offset - what offset to download - defaults to 0 -b baud - baudrate at which to download - defaults to console baudrate -c - Create file if it is not present - default disabled In your case, lets say: your ram starts at 0x8000 and is denoted by /dev/ram0. If you want to download to offset 0x3000 in ram, you can do loadb -f /dev/ram0 -o 0x3000. this will essentially download to 0x80003000. + you now have the flexibility of downloading straight to NOR, NAND or to even a file within u-boot v2's ramfs!! - so you can store and share commonly used scripts modules etc.. tons of similar flexibility exists. > c) Also how we can change the default location since the user is not given > an option to mention the address. > as explained above. > d) How to load the file " zImage" to RAM? > if you want to copy a file from ramfs to a "specific location" just do the cp command! > I was intending to do the following steps : > > >> loadb 0x10 zimage > >> loadb 0x100 ramdisk.gz > >> bootm 0x10 0x100 > > Please help me out as I am using U-boot-V2 for the first time. > Does the above explanation help? in u-boot-v2, you can infact run "help " or do a make docs And if you have graphviz latex etc installed, you will get a html documentation in Documentation/html. Note: I created a few useful platform independent tools for U-boot (should work for both U-boot v2 and V1). they are available in [1]. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Lejin K Joy > Sent: Tuesday, September 23, 2008 9:49 PM > To: 'Robert Schwebel'; 'Sascha Hauer' > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] u-boot-v2 for imx27 Board > Try not to top post. see [2] and mailing list ettiquette. Regards, Nishanth Menon [1] http://code.google.com/p/omap-u-boot-utils/ [2] http://en.wikipedia.org/wiki/Posting_style ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] working with loadb & bootm on u-boot-v2 for imx27ads Board
On Thu, Sep 25, 2008 at 8:04 AM, Lejin K Joy <[EMAIL PROTECTED]> wrote: > > --- > uboot:/ loadb -f /dev/ram0 -o 0x10 Do you have /dev/ram0? is it mapped to 0xa000? there could be issues with mach-types.. I am not sure though.. I am not entirely sure about imx boot procedure(I am an OMAP guy ;) )..but it could be uImage you need there? I am not too sure.. does the piggy relocate the kernel? I am not too sure.. probably the kernel details would help.. > ## Ready for binary (kermit) download to 0x0010 offset on /dev/ram0 > device a > t 115200 bps... > ## Total Size = 0x0014deb9 = 1367737 Bytes > > uboot:/ go 0xa010 Should'nt this be bootm 0xa010? Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
Dirk Behme said the following on 10/07/2008 04:42 AM:
>
> Scott Wood wrote:
>> On Fri, Oct 03, 2008 at 12:40:25PM +0200, [EMAIL PROTECTED]
>> wrote:
>>
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#if defined(CONFIG_CMD_NAND)
>>> +
>>> +#include
>>
>>
>> Move the #ifdef to the Makefile.
>
> Did this. Additionally, I moved OMAP3 NAND driver to
> drivers/mtd/nand/omap3.c.
I would recommend having a nand_omap_gpmc.c if the driver can be made
generic enough.
>
>>> +/*
>>> + * nand_read_buf16 - [DEFAULT] read chip data into buffer
>>> + * @mtd:MTD device structure
>>> + * @buf:buffer to store date
>>> + * @len:number of bytes to read
>>> + *
>>> + * Default read function for 16bit buswith
>>> + */
>>> +static void omap_nand_read_buf(struct mtd_info *mtd, u_char *buf,
>>> int len)
>>> +{
>>> +int i;
>>> +struct nand_chip *this = mtd->priv;
>>> +u16 *p = (u16 *) buf;
>>> +len >>= 1;
>>> +
>>> +for (i = 0; i < len; i++)
>>> +p[i] = readw(this->IO_ADDR_R);
>>> +}
>>
>>
>> How does this differ from the default implementation?
>
> It doesn't differ ;)
>
> So I removed this and tried to use default nand_read_buf16() instead:
>
> nand->read_buf = nand_read_buf16;
>
> in board_nand_init(). But this doesn't compile as nand_read_buf16() is
> static in nand_base.c. How do I use it in OMAP3 NAND driver? Marked it
> as FIXME in patch.
Probably does not need an explicit initialization, mtd nand_scan should
populate that. in fact IMHO, the read/write buf ops might be duplicating
mtd's implementation.. :(
>
>
>>> +/*
>>> + * omap_calculate_ecc - Generate non-inverted ECC bytes.
>>> + *
>>> + * Using noninverted ECC can be considered ugly since writing a blank
>>> + * page ie. padding will clear the ECC bytes. This is no problem as
>>> + * long nobody is trying to write data on the seemingly unused page.
>>> + * Reading an erased page will produce an ECC mismatch between
>>> + * generated and read ECC bytes that has to be dealt with separately.
>>
>>
>> Is this a hardware limitation? If so, say so in the comment. If not,
>> why do it this way?
>
> Don't know.
>
> All: Any help?
The issue is simple: assume we read a page of 0xFF's(fresh erased), IF
using H/w ECC engine within GPMC, the result of read will be 0x0 while
the ECC offsets of the spare area will be 0xFF which will result in an
ECC mismatch.
>>> +.eccbytes = 12,
>>> +.eccpos = {
>>> + 2, 3, 4, 5,
>>> + 6, 7, 8, 9,
>>> + 10, 11, 12, 13},
>>> +.oobfree = { {20, 50} }/* don't care */
>>
>>
>> Bytes 64-69 of a 64-byte OOB are free?
>> What don't we care about?
> +static struct nand_ecclayout hw_nand_oob_64 = {
>
> Don't know (or understand?).
>
> All: Any help?
I do not get it either.. ECCPOS is in offset bytes, and oobfree should
be {.offset=20,.length=44} /*I always hated struct initialization done
as above..*/, but then,
>
>>> ===
>>> --- u-boot-arm.orig/drivers/mtd/nand/nand_base.c
>>> +++ u-boot-arm/drivers/mtd/nand/nand_base.c
>>> @@ -2730,6 +2730,151 @@ int nand_scan_tail(struct mtd_info *mtd)
>>> return 0;
>>> }
>>>
>>> +#if defined(CONFIG_OMAP) && (defined(CONFIG_OMAP3_BEAGLE) \
>>> +|| defined(CONFIG_OMAP3_EVM) || defined(CONFIG_OVERO))
>>> +void nand_switch_ecc(struct mtd_info *mtd)
>>
>>
>> NACK. First, explain why you need to be able to dynamically switch ECC
>> modes.
>
> Two topics here, changes in cmd_nand.c and nand_base.c.
>
> cmd_nand.c:
>
> We need to be able to switch ECC at runtime cause some images have to
> be written to NAND with HW ECC and some with SW ECC. This depends on
> what user (reader) of these parts expect.
>
> OMAP3 has a boot ROM which is able to read a second level loader
> (called x-loader) from NAND and start/execute it. This 2nd level
> loader has to be written by U-Boot using HW ECC as ROM code does HW
> ECC to read the image. All other parts, e.g. Linux kernel, use SW ECC
> as default. For this we have to use SW ECC to write images, then.
>
> Therefore we add an additional user command in cmd_nand.c to switch
> ECC depending on what user wants to write.
why not use h/w ecc which rom code understands in kernel and u-boot. H/w
ecc will be faster in comparison to doing s/w ecc and there is good
support in MTD to do it, then there would be no reason for s/w ecc IMHO..
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot-Users] Compilation problem for TI3430 board.
Radha Krishna said the following on 10/17/2008 07:53 PM: > I am doing U-boot for TI3430 boad. > > Step 0: make distclean //worked fine > Step 1: make CROSS_COMPILE=arm-none-linux-gnueabi- omap3430sdp_config > //worked fine > Step 2: make CROSS_COMPILE=arm-none-linux-gnueabi- //Error > > [SNIP] > $ make CROSS_COMPILE=arm-none-linux-gnueabi- > make: arm-none-linux-gnueabi-gcc: Command not found > make[1]: arm-none-linux-gnueabi-gcc: Command not found > make[1]: Entering directory `/cygdrive/c/u-boot/tools' > make[1]: Entering directory `/cygdrive/c/u-boot/tools' Step using windows and try using a *real* Linux environment such as a vmware[4] or an Linux PC to build. I suspect you are taking code from [1]. in which case code sourcery gcc [2] will be good. Further, you need to say ARCH=ARM as part of your compilation command. By the way, there are many "TI3430" boards. from your defconfig I understand it is for SDP3430[3]. I had written a small quick start doc for 2430 - many of whose comments are still valid for 2430. Regards, Nishanth Menon [1] http://linux.omap.com/pub/bootloader/3430sdp/ or https://omapzoom.org/gf/ [2] http://www.codesourcery.com/gnu_toolchains/arm/portal/[EMAIL PROTECTED] [3] http://www.ti.com/omap3430_devplatform [4] http://www.vmware.com/download/player/ and as an example: http://search-www.vmware.com/socialsearch/query?cn=vmware&cc=www&ie=UTF-8&oe=UTF-8&q=ubuntu+8.04&x=0&y=0 choose the appliance you like, download the image and run it.. [5] http://www.geocities.com/crecmca98/Linux/omap2430_From_almost_scratch.pdf ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3, RFBI, splash screen
Try2: to list.. On Fri, Sep 18, 2009 at 11:08 AM, Dirk Behme wrote: > > Sergey Lapin wrote: > > Hi, all! > > > > I'm trying to implement splash screen on OMAP35xx-based device > > with 128x128 1bpp display connected using RFBI, plain parallel interface. > > Display has controller and own memory, and is controlled with parallel > > interface, 8-bit wide data bus and signals. > > > > This display works under Linux, but I can't implement > > that using u-boot, display just doesn't power on, while I see > > that data is on bus with oscilloscope. Linux version works > > using interrupts, so I can't do this with u-boot, and that'd be simply > > overkill using this in u-boot. I think I miss something simple. > > > > Have anybody implemented such a thing, I just need to make > > it into dumb parallel mode, just to display simple image. > > Any examples, ideas? > > Most probably it won't help you, as it seems you have some HW > configuration issues. But for OMAP3 splash screen example see > > http://groups.google.com/group/beagleboard/browse_thread/thread/3ad9b803a3418624 Just FYI -> RFBI is pretty easy to configure up.. I dont recollect seeing (Display Sub System) DSS support in mainline u-boot though.. Usually for RFBI display, there is a few configuration sequences you need to do using RFBI CMD reg and is very display specific, followed by filling up the screen with the data you need -> also note for backlight, based on the board, you may need to look at the schematics for required gpio line to toggle to the right position.. you can usually reverse engineer it from the corresponding linux driver for the same.. if you have it.. also ensure you have the pin mux done correctly.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] OMAP3: fix warnings when NAND/ONENAND is not used
Fix build warnings by putting specific used variables
under required #ifdefs for removing:
mem.c:227: warning: unused variable 'f_sec'
mem.c:226: warning: unused variable 'f_off'
mem.c:225: warning: unused variable 'size'
mem.c:224: warning: unused variable 'base'
mem.c:222: warning: unused variable 'gpmc_config'
Signed-off-by: Nishanth Menon
---
cpu/arm_cortexa8/omap3/mem.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 8d64478..e93343c 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -219,12 +219,16 @@ void enable_gpmc_cs_config(const u32 *gpmc_config, struct
gpmc_cs *cs, u32 base,
void gpmc_init(void)
{
/* putting a blanket check on GPMC based on ZeBu for now */
- u32 *gpmc_config = NULL;
gpmc_cfg = (struct gpmc *)GPMC_BASE;
+#if defined(CONFIG_CMD_NAND) || defined(CONFIG_CMD_ONENAND)
+ u32 *gpmc_config = NULL;
u32 base = 0;
u32 size = 0;
+#if defined(CONFIG_ENV_IS_IN_NAND) || defined(CONFIG_ENV_IS_IN_ONENAND)
u32 f_off = CONFIG_SYS_MONITOR_LEN;
u32 f_sec = 0;
+#endif
+#endif
u32 config = 0;
/* global settings */
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] OMAP3: export enable_gpmc_cs_config to board files
Export enable_gpmc_cs_config into common header to prevent warning: warning: implicit declaration of function 'enable_gpmc_cs_config' Signed-off-by: Nishanth Menon --- include/asm-arm/arch-omap3/sys_proto.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-omap3/sys_proto.h b/include/asm-arm/arch-omap3/sys_proto.h index 2246f80..e59021e 100644 --- a/include/asm-arm/arch-omap3/sys_proto.h +++ b/include/asm-arm/arch-omap3/sys_proto.h @@ -34,6 +34,8 @@ void memif_init(void); void sdrc_init(void); void do_sdrc_init(u32, u32); void gpmc_init(void); +void enable_gpmc_cs_config(u32 *gpmc_config, struct gpmc_cs *cs, u32 base, + u32 size); void watchdog_init(void); void set_muxconf_regs(void); -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] OMAP3: Fix SDRC init
Defaults are for infenion DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Signed-off-by: Nishanth Menon
---
cpu/arm_cortexa8/omap3/mem.c |3 ++-
include/asm-arm/arch-omap3/cpu.h |1 +
include/asm-arm/arch-omap3/mem.h |8
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 079c848..8731c9d 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -164,7 +164,8 @@ void do_sdrc_init(u32 cs, u32 early)
writel(SDP_SDRC_SHARING, &sdrc_base->sharing);
/* Disable Power Down of CKE cuz of 1 CKE on combo part */
- writel(SRFRONRESET | PAGEPOLICY_HIGH, &sdrc_base->power);
+ writel(WAKEUPPROC | PWDNEN | SRFRONRESET | PAGEPOLICY_HIGH,
+ &sdrc_base->power);
writel(ENADLL | DLLPHASE_90, &sdrc_base->dlla_ctrl);
sdelay(0x2);
diff --git a/include/asm-arm/arch-omap3/cpu.h b/include/asm-arm/arch-omap3/cpu.h
index 8ab2e39..e51c4f3 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -222,6 +222,7 @@ struct sdrc {
#define PAGEPOLICY_HIGH(0x1 << 0)
#define SRFRONRESET(0x1 << 7)
+#define PWDNEN (0x1 << 2)
#define WAKEUPPROC (0x1 << 26)
#define DDR_SDRAM (0x1 << 0)
diff --git a/include/asm-arm/arch-omap3/mem.h b/include/asm-arm/arch-omap3/mem.h
index 5b9ac75..31cbdef 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -78,16 +78,16 @@ enum {
#define TRP_1653
#define TRAS_165 7
#define TRC_16510
-#define TRFC_165 21
+#define TRFC_165 12
#define V_ACTIMA_165 ((TRFC_165 << 27) | (TRC_165 << 22) | \
(TRAS_165 << 18) | (TRP_165 << 15) | \
(TRCD_165 << 12) | (TRRD_165 << 9) | \
(TDPL_165 << 6) | (TDAL_165))
#define TWTR_165 1
-#define TCKE_165 1
-#define TXP_1655
-#define XSR_16523
+#define TCKE_165 2
+#define TXP_1652
+#define XSR_16520
#define V_ACTIMB_165 (((TCKE_165 << 12) | (XSR_165 << 0)) | \
(TXP_165 << 8) | (TWTR_165 << 16))
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] ARM:OMAP3:SDP3430: initial support
From: David Brownell Start of SDP3430 support in "mainline" u-boot mainline code Original Patch written by David Brownell Support default jumpering and: - UART1/ttyS0 console(legacy sdp3430 u-boot) - UART3/ttyS2 console (matching other boards, and SDP HW docs) - Ethernet - mmc0 - NOR boot TODO: - mmc1 - NAND (boot or 128M storage) - OneNAND (boot or 256M storage) - Fix NOR env variable load - Review SDRC timing configuration/DPLL configuration - Dynamically read FPGA dip switch settings and map NOR/NAND/ONENAND devices to right chipselects Currently the UART1 is enabled by default. for compatibility with other OMAP3 u-boot platforms, enable the #define of CONSOLE_J9. Ref: SDP3430: http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=28741 Signed-off-by: David Brownell Signed-off-by: Nishanth Menon --- MAINTAINERS |1 + MAKEALL |1 + Makefile|3 + board/ti/sdp3430/Makefile | 49 ++ board/ti/sdp3430/config.mk | 33 board/ti/sdp3430/sdp.c | 194 ++ board/ti/sdp3430/sdp.h | 376 +++ board/ti/sdp3430/u-boot.lds | 63 +++ include/configs/omap3_sdp.h | 367 + 9 files changed, 1087 insertions(+), 0 deletions(-) create mode 100644 board/ti/sdp3430/Makefile create mode 100644 board/ti/sdp3430/config.mk create mode 100644 board/ti/sdp3430/sdp.c create mode 100644 board/ti/sdp3430/sdp.h create mode 100644 board/ti/sdp3430/u-boot.lds create mode 100644 include/configs/omap3_sdp.h diff --git a/MAINTAINERS b/MAINTAINERS index e9db278..adc8a63 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -619,6 +619,7 @@ Guennadi Liakhovetski Nishanth Menon omap3_zoom1 ARM CORTEX-A8 (OMAP3xx SoC) + omap3_sdp ARM CORTEX-A8 (OMAP3xx SoC) David Müller diff --git a/MAKEALL b/MAKEALL index f0ed8ea..53620eb 100755 --- a/MAKEALL +++ b/MAKEALL @@ -588,6 +588,7 @@ LIST_ARM_CORTEX_A8="\ omap3_pandora \ omap3_zoom1 \ omap3_zoom2 \ + omap3_sdp \ " # diff --git a/Makefile b/Makefile index 5a4a109..2626147 100644 --- a/Makefile +++ b/Makefile @@ -3172,6 +3172,9 @@ omap3_zoom1_config : unconfig omap3_zoom2_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 logicpd omap3 +omap3_sdp_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 sdp3430 ti omap3 + # ## XScale Systems # diff --git a/board/ti/sdp3430/Makefile b/board/ti/sdp3430/Makefile new file mode 100644 index 000..2554c7b --- /dev/null +++ b/board/ti/sdp3430/Makefile @@ -0,0 +1,49 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := sdp.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(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/ti/sdp3430/config.mk b/board/ti/sdp3430/config.mk new file mode 100644 index 000..3726634 --- /dev/null +++ b/board/ti/sdp3430/config.mk @@ -0,0 +1,33 @@ +# +# (C) Copyright 2006-2009 +# Texas Instruments, +# +# OMAP 3430 SDP uses OMAP3 (ARM-CortexA8) cpu +# see http://www.ti.com/ for more information on Texas Instruments +# +# See file CREDITS for list of people who contributed to this +# project. +# +# T
[U-Boot] [PATCH 5/6] DLMALLOC:!X86: add av_ initialization
This is questionable if this is really required
as the av_ static initalized values should have
been loaded to sdram as part of the boot process
and initialization should have been done.
Signed-off-by: Nishanth Menon
---
common/dlmalloc.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 241db8c..bd509db 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1527,6 +1527,11 @@ void *sbrk(ptrdiff_t increment)
*/
void mem_malloc_init(ulong start, ulong size)
{
+ u8 i;
+ av_[0] = av_[1] = 0;
+ for (i = 0; i < 128; i++)
+ av_[2 + i * 2] = av_[2 + i * 2 + 1] = bin_at(i);
+
mem_malloc_start = start;
mem_malloc_end = start + size;
mem_malloc_brk = start;
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] ARM:OMAP3:SDP3430 initial support
Hi, This series of patch provides minimal support for OMAP3430 based OMAP3 platform Ref: http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=28741 David Brownell (1): ARM:OMAP3:SDP3430: initial support Nishanth Menon (5): OMAP3: Fix SDRC init OMAP3: export enable_gpmc_cs_config to board files OMAP3: make gpmc_config as const OMAP3: fix warnings when NAND/ONENAND is not used DLMALLOC:!X86: add av_ initialization MAINTAINERS|1 + MAKEALL|1 + Makefile |3 + board/ti/sdp3430/Makefile | 49 board/ti/sdp3430/config.mk | 33 +++ board/ti/sdp3430/sdp.c | 194 board/ti/sdp3430/sdp.h | 376 board/ti/sdp3430/u-boot.lds| 63 ++ common/dlmalloc.c |5 + cpu/arm_cortexa8/omap3/mem.c | 15 +- include/asm-arm/arch-omap3/cpu.h |1 + include/asm-arm/arch-omap3/mem.h |8 +- include/asm-arm/arch-omap3/sys_proto.h |2 + include/configs/omap3_sdp.h| 367 +++ 14 files changed, 1109 insertions(+), 9 deletions(-) create mode 100644 board/ti/sdp3430/Makefile create mode 100644 board/ti/sdp3430/config.mk create mode 100644 board/ti/sdp3430/sdp.c create mode 100644 board/ti/sdp3430/sdp.h create mode 100644 board/ti/sdp3430/u-boot.lds create mode 100644 include/configs/omap3_sdp.h Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] OMAP3: make gpmc_config as const
gpmc_config should not be a variant as it is board specific
hence make it a const parameter
Signed-off-by: Nishanth Menon
---
cpu/arm_cortexa8/omap3/mem.c |6 +++---
include/asm-arm/arch-omap3/sys_proto.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 8731c9d..8d64478 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -44,7 +44,7 @@ volatile unsigned int boot_flash_env_addr;
struct gpmc *gpmc_cfg;
#if defined(CONFIG_CMD_NAND)
-static u32 gpmc_m_nand[GPMC_MAX_REG] = {
+static const u32 gpmc_m_nand[GPMC_MAX_REG] = {
M_NAND_GPMC_CONFIG1,
M_NAND_GPMC_CONFIG2,
M_NAND_GPMC_CONFIG3,
@@ -62,7 +62,7 @@ static u32 gpmc_m_nand[GPMC_MAX_REG] = {
#endif
#if defined(CONFIG_CMD_ONENAND)
-static u32 gpmc_onenand[GPMC_MAX_REG] = {
+static const u32 gpmc_onenand[GPMC_MAX_REG] = {
ONENAND_GPMC_CONFIG1,
ONENAND_GPMC_CONFIG2,
ONENAND_GPMC_CONFIG3,
@@ -193,7 +193,7 @@ void do_sdrc_init(u32 cs, u32 early)
writel(0, &sdrc_base->cs[cs].mcfg);
}
-void enable_gpmc_cs_config(u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32
base,
u32 size)
{
writel(0, &cs->config7);
diff --git a/include/asm-arm/arch-omap3/sys_proto.h
b/include/asm-arm/arch-omap3/sys_proto.h
index e59021e..34bd515 100644
--- a/include/asm-arm/arch-omap3/sys_proto.h
+++ b/include/asm-arm/arch-omap3/sys_proto.h
@@ -34,7 +34,7 @@ void memif_init(void);
void sdrc_init(void);
void do_sdrc_init(u32, u32);
void gpmc_init(void);
-void enable_gpmc_cs_config(u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32
base,
u32 size);
void watchdog_init(void);
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM:OMAP3:SDP3430: initial support
Peter Tyser said the following on 09/19/2009 09:34 AM:
thanks for your review
> Hi Nishanth,
>
> On Fri, 2009-09-18 at 21:21 -0500, Nishanth Menon wrote:
>
>> From: David Brownell
>>
>> Start of SDP3430 support in "mainline"
>> u-boot mainline code
>>
>> Original Patch written by David Brownell
>>
>
> I don't think the above comments are necessary. David will be credited
> with authorship already, and the subject line and text below make it
> clear what this patch does.
>
>
Ack..
>> create mode 100644 board/ti/sdp3430/sdp.h
>> create mode 100644 board/ti/sdp3430/u-boot.lds
>> create mode 100644 include/configs/omap3_sdp.h
>>
>
> The board config header file should be renamed to sdp.h from
> omap3_sdp.h. There was a recent thread discussing this convention "ARM
> Pull Request" around Sept 6.
>
sdp3430 - there are many software development platforms ->
omap2420 based, omap2430 based etc..
Thanks for pointing this chain out.. a specific link describing
the thought will help and prevent me misunderstanding the
intention here.
>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e9db278..adc8a63 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -619,6 +619,7 @@ Guennadi Liakhovetski
>> Nishanth Menon
>>
>> omap3_zoom1 ARM CORTEX-A8 (OMAP3xx SoC)
>> +omap3_sdp ARM CORTEX-A8 (OMAP3xx SoC)
>>
>
> You may as well keep the boards ordered alphabetically (and remove the
> omap_ prefix from sdp).
>
ack to alphabetical sort.
>> +/**
>> + * Routine: board_init
>> + * Description: Early hardware init.
>> +
>> */
>> +int board_init(void)
>> +{
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>>
>
>
> I'd use the preferred multi-line comment style:
> /*
> *
> */
>
> There are lots of other non-preferred multi-line comments throughout the
> patch as well.
>
ack.
> I personally don't think its necessary to put "Routine: " stuff
> for each function either. It doesn't add any benefit, adds cruft to
> grep output, and might get out of sync with the real function name at
> some point. If it were me, I would get rid of "Description: " text too.
> Its pretty obvious that the text "Early hardware init" is a description
> of the function.
>
not to all.. I dont like it either, I would rather go doxygen style..
will convert.
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] DLMALLOC:!X86: add av_ initialization
Peter Tyser said the following on 09/19/2009 09:03 AM:
> On Fri, 2009-09-18 at 21:21 -0500, Nishanth Menon wrote:
>
>> This is questionable if this is really required
>> as the av_ static initalized values should have
>> been loaded to sdram as part of the boot process
>> and initialization should have been done.
>>
>
> Is there a reason you need to do this fixup? Based on your commit
> message its unclear if this patch is really needed...
>
>
Essentially, the loaded memory from the NOR looks all corrupted.
I am unable to convince myself why the SDRAM is not updated
with the static default inits - SDRAM corruption would have
cracked everything else and scope measurement looks good too.
>> Signed-off-by: Nishanth Menon > void mem_malloc_init(ulong start, ulong size)
>> {
>> +u8 i;
>> +av_[0] = av_[1] = 0;
>> +for (i = 0; i < 128; i++)
>> +av_[2 + i * 2] = av_[2 + i * 2 + 1] = bin_at(i);
>> +
>> mem_malloc_start = start;
>> mem_malloc_end = start + size;
>> mem_malloc_brk = start;
>>
>
> If you are going to do this fixup, av_ should not be initialized with
> values (you're currently doing the same initialization 2 times). In
> general, we could probably shave a bit off of U-Boot's size by leaving
> av_ uninitialized and implementing your manual calculation of av_ above,
>
yep.. missed finishing that out.. :(
> but I'm not sure why this change should be included in this patch
> series.
>
This patch is need for booting SDP3430 from NOR flash.
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] TI: OMAP3: Overo Tobi ethernet support
Olof Johansson said the following on 09/23/2009 09:43 PM: > On Sep 23, 2009, at 1:39 PM, Tom wrote: > > >> Olof Johansson wrote: >> >>> diff --git a/board/overo/overo.c b/board/overo/overo.c >>> index dd6d286..7d87e52 100644 >>> --- a/board/overo/overo.c >>> +++ b/board/overo/overo.c >>> >>> + writel(GPIO0, &gpio3_base->cleardataout); >>> + udelay(1); >>> + writel(GPIO0, &gpio3_base->setdataout); >>> >> Use the omap gpio interface described in README.omap3 >> >> > > Seriously, this code is a 1:1 replica from the evm code. Obviously > that code was good enough to merge. > should'nt we be fixing evm code instead of moving similar code in for another platform? Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] DLMALLOC:!X86: add av_ initialization
Wolfgang Denk said the following on 09/23/2009 11:04 PM: > Dear Nishanth Menon, > > In message <4ab4fad6.20...@gmail.com> you wrote: > >> This patch is need for booting SDP3430 from NOR flash. >> > > There must be some problem elsewhere. It's extremely unlikely that > just a single board has this problem; it's much more likely that > there is a bug in the board port, and/or it's linker script. > Yes, I tend to agree on this. but that said, as pointed out earlier in this thread by Peter Tyser, it might actually save a few bytes of code.. but I need to really root cause this out before sending out patchset v2. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM:OMAP3:SDP3430: initial support
Wolfgang Denk said the following on 09/23/2009 10:51 PM:
> Dear Nishanth Menon,
>
> In message <1253326918-1670-7-git-send-email...@ti.com> you wrote:
>
>> --===1247028818==
>>
>> From: David Brownell
>>
>> Start of SDP3430 support in "mainline"
>> u-boot mainline code
>>
>> Original Patch written by David Brownell
>>
>
> Um... this seems redundant information to me (the "From:" line and
> the Signed-off-by: line already say that David Brownell is the
> author.
>
Acked as previously discussed.
> On the other hand, I'm missing explanations what SDP3430 might be?
>
hmm.. my bad. will fix. I should really be adding a few more lines to
README.omap3. I will do that along with this change.
>
>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e9db278..adc8a63 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -619,6 +619,7 @@ Guennadi Liakhovetski
>> Nishanth Menon
>>
>> omap3_zoom1 ARM CORTEX-A8 (OMAP3xx SoC)
>> +omap3_sdp ARM CORTEX-A8 (OMAP3xx SoC)
>>
>
> Please keep lists sorted.
>
Ack
> General remark:
>
> The board name is "SDP3430", right? The board directory name is
> board/ti/sdp3430/, which is ok. But then the configuration name should
> be "sdp3430", too.
>
Thanks.
>> +
>> +static const u32 gpmc_sdp_nand[] = {
>> +0x0800, /*CONF1 */
>> +0x00141400, /*CONF2 */
>> +0x00141400, /*CONF3 */
>> +0x0F010F01, /*CONF4 */
>> +0x010C1414, /*CONF5 */
>> +0x1F040A80, /*CONF6 */
>> +/*CONF7- computed as params */
>> +};
>>
>
> Please comment what all these magic numbers mean.
>
>
these are configuration register values for GPMC (General Purpose Memory
Controller)
I should be indeed adding proper comments here. will do.
>> +/**
>> + * Routine: board_init
>> + * Description: Early hardware init.
>> +
>> */
>>
>
> Incorrect multiline comment style. Please fix globally.
>
Ack
> ...
>
>> diff --git a/board/ti/sdp3430/sdp.h b/board/ti/sdp3430/sdp.h
>> new file mode 100644
>> index 000..5ad2920
>> --- /dev/null
>> +++ b/board/ti/sdp3430/sdp.h
>>
> ...
>
>> +#define MUX_SDP3430()\
>> + /*SDRC*/\
>> + MUX_VAL(CP(SDRC_D0), (IEN | PTD | DIS | M0)) /*SDRC_D0*/\
>> + MUX_VAL(CP(SDRC_D1), (IEN | PTD | DIS | M0)) /*SDRC_D1*/\
>>
> ...
>
> Incorrect indentation.
>
(having spend almost an hr cleaning that piece of mux header up)
groan.. any recommendations? is it because of the " "?
> What exacty is the purpose of the comment? It does not carry any
> information. Seems just a waste of line length to me?
>
you mean /* SDRC_D0 */? hmmm.. might actually make sense if
I am not using default mux mode 0 to note why I am using a new
value.
>
>> diff --git a/board/ti/sdp3430/u-boot.lds b/board/ti/sdp3430/u-boot.lds
>> new file mode 100644
>> index 000..4ecc6dd
>> --- /dev/null
>> +++ b/board/ti/sdp3430/u-boot.lds
>>
>
> Is it really necessary that this board uses a custom linke rscript?
> Cannot we use a generic one for several boards?
>
Ack.
>
>> diff --git a/include/configs/omap3_sdp.h b/include/configs/omap3_sdp.h
>> new file mode 100644
>> index 000..176617a
>> --- /dev/null
>> +++ b/include/configs/omap3_sdp.h
>>
>
> This should be include/configs/sdp3430.h, accorsing to the board name.
>
Ack. I guess this is a hangover from the days where we wanted all omap3
boards to look similar.
> ...
>
>> +/*
>> + * Size of malloc() pool
>> + */
>> +#define CONFIG_ENV_SIZE SZ_256K /* Total Size
>> Environment */
>>
>
> Please do not use any of these SZ_ defines; they will be removed soon.
>
Ack..
>
>> +#if 0
>> +#define CONSOLE_J9 /* else J8/UART1 (innermost) */
>> +#endif
>>
>
> Please delete - don't add dead code.
>
CONSOLE_J9 is really an option, but I get your point here I should be using
#undef even if i wanted to allow folks to tweak around.. #if 0s are *evil*
>
>> +/* timeout values are in ticks */
>> +#define CONFIG_SYS_FLASH_ERASE_TOUT (100 * CONFIG_SYS_HZ)
>> +#define CONFIG_SYS_FLASH_WRITE_TOUT (100 * CONFIG_SYS_HZ)
>>
>
> Strictly speaking the co
Re: [U-Boot] [PATCH v2] TI: OMAP3: Overo Tobi ethernet support
Olof Johansson said the following on 09/24/2009 03:38 AM:
> On Sep 23, 2009, at 7:34 PM, Nishanth Menon wrote:
>
>> Olof Johansson said the following on 09/23/2009 09:43 PM:
>>> On Sep 23, 2009, at 1:39 PM, Tom wrote:
>>>
>>>
>>>> Olof Johansson wrote:
>>>>
>>>>> diff --git a/board/overo/overo.c b/board/overo/overo.c
>>>>> index dd6d286..7d87e52 100644
>>>>> --- a/board/overo/overo.c
>>>>> +++ b/board/overo/overo.c
>>>>>
>>>>> +writel(GPIO0, &gpio3_base->cleardataout);
>>>>> +udelay(1);
>>>>> +writel(GPIO0, &gpio3_base->setdataout);
>>>>>
>>>> Use the omap gpio interface described in README.omap3
>>>>
>>>>
>>>
>>> Seriously, this code is a 1:1 replica from the evm code. Obviously
>>> that code was good enough to merge.
>>>
>>
>> should'nt we be fixing evm code instead of moving similar code in for
>> another platform?
>
> Sure, but you forgot to attach the patch.
>
Silly me.. sorry about that.. as you pointed out, I did indeed forget..
need to catch my flight now, and as i dont own an evm, here is the patch
in attachment if someone would care to try it out..
Regards,
Nishanth Menon
>From 05a504c3f0bf9eb7cf06db5712abe70c907c8240 Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Thu, 24 Sep 2009 04:02:45 +0300
Subject: [PATCH] [RFC] OMAP3:EVM: remove direct gpio hits
ONLY COMPILE TESTED
replace gpio direct access with gpio api calls
Signed-off-by: Nishanth Menon
---
board/ti/evm/evm.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 0718a08..f0ebaad 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "evm.h"
/*
@@ -92,7 +93,6 @@ void set_muxconf_regs(void)
*/
static void setup_net_chip(void)
{
- struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
/* Configure GPMC registers */
@@ -112,15 +112,15 @@ static void setup_net_chip(void)
writew(readw(&ctrl_base->gpmc_nadv_ale) | 0x0E00,
&ctrl_base->gpmc_nadv_ale);
- /* Make GPIO 64 as output pin */
- writel(readl(&gpio3_base->oe) & ~(GPIO0), &gpio3_base->oe);
-
- /* Now send a pulse on the GPIO pin */
- writel(GPIO0, &gpio3_base->setdataout);
- udelay(1);
- writel(GPIO0, &gpio3_base->cleardataout);
- udelay(1);
- writel(GPIO0, &gpio3_base->setdataout);
+ /* Make GPIO 64 as output pin and send a magic pulse through it */
+ if (!omap_request_gpio(64)) {
+ omap_set_gpio_direction(64, 0);
+ omap_set_gpio_dataout(64, 1);
+ udelay(1);
+ omap_set_gpio_dataout(64, 0);
+ udelay(1);
+ omap_set_gpio_dataout(64, 1);
+ }
}
int board_eth_init(bd_t *bis)
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] DLMALLOC:!X86: add av_ initialization
Remove the predefined static initialization
and generate the map dynamically to reduce
code size.
This patch benefits were pointed out by Peter:
http://www.nabble.com/forum/Permalink.jtp?root=25518020&post=25523748&page=y
Signed-off-by: Nishanth Menon
Cc: Peter Tyser
Cc: Sandeep Paulraj
Cc: Tom Rix
---
common/dlmalloc.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 241db8c..25e5314 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1474,6 +1474,7 @@ typedef struct malloc_chunk* mbinptr;
#define IAV(i) bin_at(i), bin_at(i)
+#ifdef CONFIG_X86
static mbinptr av_[NAV * 2 + 2] = {
0, 0,
IAV(0), IAV(1), IAV(2), IAV(3), IAV(4), IAV(5), IAV(6), IAV(7),
@@ -1493,6 +1494,9 @@ static mbinptr av_[NAV * 2 + 2] = {
IAV(112), IAV(113), IAV(114), IAV(115), IAV(116), IAV(117), IAV(118),
IAV(119),
IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125), IAV(126), IAV(127)
};
+#else
+static mbinptr av_[NAV * 2 + 2];
+#endif
void malloc_bin_reloc (void)
{
@@ -1527,6 +1531,11 @@ void *sbrk(ptrdiff_t increment)
*/
void mem_malloc_init(ulong start, ulong size)
{
+ u8 i;
+ av_[0] = av_[1] = 0;
+ for (i = 0; i < 128; i++)
+ av_[2 + i * 2] = av_[2 + i * 2 + 1] = bin_at(i);
+
mem_malloc_start = start;
mem_malloc_end = start + size;
mem_malloc_brk = start;
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP3: remove SZ definition in config definitions
SZ definitions are deprecated as indicated by wd here:
http://www.nabble.com/forum/Permalink.jtp?root=25518020&post=25584065&page=y
Fix by running the following script
I=`cat include/asm-arm/sizes.h |grep SZ_|cut -d ' ' -f2`
I=`cat include/asm-arm/sizes.h |grep SZ_|cut -d ' ' -f4-`
sz_array=( $I )
val_array=( $J )
for file in include/configs/omap3_*;
do
x=0
for i in $I
do
o=${sz_array[$x]}
n=${val_array[$x]}
cat $file |sed -e "s/$o/$n/g">b
mv b $file
x=$(( x + 1 ))
done
done
Signed-off-by: Nishanth Menon
Cc: Vikram Pandita
Cc: Sandeep Paulraj
Cc: Tom Rix
Cc: Dirk Behme
---
include/configs/omap3_beagle.h | 16
include/configs/omap3_evm.h | 16
include/configs/omap3_overo.h | 16
include/configs/omap3_pandora.h | 16
include/configs/omap3_zoom1.h | 16
include/configs/omap3_zoom2.h | 16
6 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 55eeb94..14754c3 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -61,10 +61,10 @@
/*
* Size of malloc() pool
+ * Total env = 128K, malloc = 128K
*/
-#define CONFIG_ENV_SIZESZ_128K /* Total Size
Environment */
- /* Sector */
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + SZ_128K)
+#define CONFIG_ENV_SIZE0x0002
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 0x0002)
#define CONFIG_SYS_GBL_DATA_SIZE 128 /* bytes reserved for */
/* initial data */
@@ -239,10 +239,10 @@
*
* The stack sizes are set up in start.S using the settings below
*/
-#define CONFIG_STACKSIZE SZ_128K /* regular stack */
+#define CONFIG_STACKSIZE 0x0002 /* regular stack */
#ifdef CONFIG_USE_IRQ
-#define CONFIG_STACKSIZE_IRQ SZ_4K /* IRQ stack */
-#define CONFIG_STACKSIZE_FIQ SZ_4K /* FIQ stack */
+#define CONFIG_STACKSIZE_IRQ 0x1000 /* IRQ stack */
+#define CONFIG_STACKSIZE_FIQ 0x1000 /* FIQ stack */
#endif
/*---
@@ -250,7 +250,7 @@
*/
#define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be populated */
#define PHYS_SDRAM_1 OMAP34XX_SDRC_CS0
-#define PHYS_SDRAM_1_SIZE SZ_32M /* at least 32 meg */
+#define PHYS_SDRAM_1_SIZE 0x0200 /* at least 32 meg */
#define PHYS_SDRAM_2 OMAP34XX_SDRC_CS1
/* SDRAM Bank Allocation method */
@@ -269,7 +269,7 @@
#define CONFIG_SYS_MAX_FLASH_SECT 520 /* max number of sectors on */
/* one chip */
#define CONFIG_SYS_MAX_FLASH_BANKS 2 /* max number of flash banks */
-#define CONFIG_SYS_MONITOR_LEN SZ_256K /* Reserve 2 sectors */
+#define CONFIG_SYS_MONITOR_LEN 0x0004 /* Reserve 2 sectors */
#define CONFIG_SYS_FLASH_BASE boot_flash_base
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 72e9626..f615a4e 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -66,10 +66,10 @@
/*
* Size of malloc() pool
+ * Total Environment = 128K + malloc = 128K
*/
-#define CONFIG_ENV_SIZESZ_128K /* Total Size
Environment */
- /* Sector */
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + SZ_128K)
+#define CONFIG_ENV_SIZE0x0002
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 0x0002)
#define CONFIG_SYS_GBL_DATA_SIZE 128 /* bytes reserved for */
/* initial data */
/*
@@ -231,10 +231,10 @@
*
* The stack sizes are set up in start.S using the settings below
*/
-#define CONFIG_STACKSIZE SZ_128K /* regular stack */
+#define CONFIG_STACKSIZE 0x0002 /* regular stack */
#ifdef CONFIG_USE_IRQ
-#define CONFIG_STACKSIZE_IRQ SZ_4K /* IRQ stack */
-#define CONFIG_STACKSIZE_FIQ SZ_4K /* FIQ stack */
+#define CONFIG_STACKSIZE_IRQ 0x1000 /* IRQ stack */
+#define CONFIG_STACKSIZE_FIQ 0x1000 /* FIQ stack */
#endif
/*---
@@ -242,7 +242,7 @@
*/
#define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be populated */
#define PHYS_SDRAM_1 OMAP34XX_SDRC_CS0
-#define PHYS_SDRAM_1_SIZE SZ_32M /* at least 32 meg */
+#define PHYS_SDRAM_1_SIZE 0x0200 /* at least 32 meg */
#define PHYS_SDRAM_2 OMAP34XX_SDRC_CS1
/* SDRAM Bank Allocati
[U-Boot] [PATCH 2/5] OMAP3: export enable_gpmc_cs_config to board files
Export enable_gpmc_cs_config into common header to prevent warning: warning: implicit declaration of function 'enable_gpmc_cs_config' Signed-off-by: Nishanth Menon Cc: David B Cc: Vikram Pandita Cc: Richard Woodruff Cc: Sandeep Paulraj Cc: Tom Rix Cc: Dirk Behme --- include/asm-arm/arch-omap3/sys_proto.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-omap3/sys_proto.h b/include/asm-arm/arch-omap3/sys_proto.h index 2246f80..e59021e 100644 --- a/include/asm-arm/arch-omap3/sys_proto.h +++ b/include/asm-arm/arch-omap3/sys_proto.h @@ -34,6 +34,8 @@ void memif_init(void); void sdrc_init(void); void do_sdrc_init(u32, u32); void gpmc_init(void); +void enable_gpmc_cs_config(u32 *gpmc_config, struct gpmc_cs *cs, u32 base, + u32 size); void watchdog_init(void); void set_muxconf_regs(void); -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] OMAP3: make gpmc_config as const
gpmc_config should not be a variant as it is board specific
hence make it a const parameter
Signed-off-by: Nishanth Menon
Cc: David B
Cc: Vikram Pandita
Cc: Richard Woodruff
Cc: Sandeep Paulraj
Cc: Tom Rix
Cc: Dirk Behme
---
cpu/arm_cortexa8/omap3/mem.c |6 +++---
include/asm-arm/arch-omap3/sys_proto.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 8731c9d..8d64478 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -44,7 +44,7 @@ volatile unsigned int boot_flash_env_addr;
struct gpmc *gpmc_cfg;
#if defined(CONFIG_CMD_NAND)
-static u32 gpmc_m_nand[GPMC_MAX_REG] = {
+static const u32 gpmc_m_nand[GPMC_MAX_REG] = {
M_NAND_GPMC_CONFIG1,
M_NAND_GPMC_CONFIG2,
M_NAND_GPMC_CONFIG3,
@@ -62,7 +62,7 @@ static u32 gpmc_m_nand[GPMC_MAX_REG] = {
#endif
#if defined(CONFIG_CMD_ONENAND)
-static u32 gpmc_onenand[GPMC_MAX_REG] = {
+static const u32 gpmc_onenand[GPMC_MAX_REG] = {
ONENAND_GPMC_CONFIG1,
ONENAND_GPMC_CONFIG2,
ONENAND_GPMC_CONFIG3,
@@ -193,7 +193,7 @@ void do_sdrc_init(u32 cs, u32 early)
writel(0, &sdrc_base->cs[cs].mcfg);
}
-void enable_gpmc_cs_config(u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32
base,
u32 size)
{
writel(0, &cs->config7);
diff --git a/include/asm-arm/arch-omap3/sys_proto.h
b/include/asm-arm/arch-omap3/sys_proto.h
index e59021e..34bd515 100644
--- a/include/asm-arm/arch-omap3/sys_proto.h
+++ b/include/asm-arm/arch-omap3/sys_proto.h
@@ -34,7 +34,7 @@ void memif_init(void);
void sdrc_init(void);
void do_sdrc_init(u32, u32);
void gpmc_init(void);
-void enable_gpmc_cs_config(u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32
base,
u32 size);
void watchdog_init(void);
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] OMAP3: fix warnings when NAND/ONENAND is not used
Fix build warnings by putting specific used variables
under required #ifdefs for removing:
mem.c:227: warning: unused variable 'f_sec'
mem.c:226: warning: unused variable 'f_off'
mem.c:225: warning: unused variable 'size'
mem.c:224: warning: unused variable 'base'
mem.c:222: warning: unused variable 'gpmc_config'
Signed-off-by: Nishanth Menon
Cc: David B
Cc: Vikram Pandita
Cc: Richard Woodruff
Cc: Sandeep Paulraj
Cc: Tom Rix
Cc: Dirk Behme
---
cpu/arm_cortexa8/omap3/mem.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 8d64478..e93343c 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -219,12 +219,16 @@ void enable_gpmc_cs_config(const u32 *gpmc_config, struct
gpmc_cs *cs, u32 base,
void gpmc_init(void)
{
/* putting a blanket check on GPMC based on ZeBu for now */
- u32 *gpmc_config = NULL;
gpmc_cfg = (struct gpmc *)GPMC_BASE;
+#if defined(CONFIG_CMD_NAND) || defined(CONFIG_CMD_ONENAND)
+ u32 *gpmc_config = NULL;
u32 base = 0;
u32 size = 0;
+#if defined(CONFIG_ENV_IS_IN_NAND) || defined(CONFIG_ENV_IS_IN_ONENAND)
u32 f_off = CONFIG_SYS_MONITOR_LEN;
u32 f_sec = 0;
+#endif
+#endif
u32 config = 0;
/* global settings */
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5 v2] OMAP3: Fix SDRC init
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Signed-off-by: Nishanth Menon
Cc: David B
Cc: Vikram Pandita
Cc: Richard Woodruff
Cc: Sandeep Paulraj
Cc: Tom Rix
Cc: Dirk Behme
---
cpu/arm_cortexa8/omap3/mem.c |3 ++-
include/asm-arm/arch-omap3/cpu.h |1 +
include/asm-arm/arch-omap3/mem.h |8
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 079c848..8731c9d 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -164,7 +164,8 @@ void do_sdrc_init(u32 cs, u32 early)
writel(SDP_SDRC_SHARING, &sdrc_base->sharing);
/* Disable Power Down of CKE cuz of 1 CKE on combo part */
- writel(SRFRONRESET | PAGEPOLICY_HIGH, &sdrc_base->power);
+ writel(WAKEUPPROC | PWDNEN | SRFRONRESET | PAGEPOLICY_HIGH,
+ &sdrc_base->power);
writel(ENADLL | DLLPHASE_90, &sdrc_base->dlla_ctrl);
sdelay(0x2);
diff --git a/include/asm-arm/arch-omap3/cpu.h b/include/asm-arm/arch-omap3/cpu.h
index 8ab2e39..e51c4f3 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -222,6 +222,7 @@ struct sdrc {
#define PAGEPOLICY_HIGH(0x1 << 0)
#define SRFRONRESET(0x1 << 7)
+#define PWDNEN (0x1 << 2)
#define WAKEUPPROC (0x1 << 26)
#define DDR_SDRAM (0x1 << 0)
diff --git a/include/asm-arm/arch-omap3/mem.h b/include/asm-arm/arch-omap3/mem.h
index 5b9ac75..31cbdef 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -78,16 +78,16 @@ enum {
#define TRP_1653
#define TRAS_165 7
#define TRC_16510
-#define TRFC_165 21
+#define TRFC_165 12
#define V_ACTIMA_165 ((TRFC_165 << 27) | (TRC_165 << 22) | \
(TRAS_165 << 18) | (TRP_165 << 15) | \
(TRCD_165 << 12) | (TRRD_165 << 9) | \
(TDPL_165 << 6) | (TDAL_165))
#define TWTR_165 1
-#define TCKE_165 1
-#define TXP_1655
-#define XSR_16523
+#define TCKE_165 2
+#define TXP_1652
+#define XSR_16520
#define V_ACTIMB_165 (((TCKE_165 << 12) | (XSR_165 << 0)) | \
(TXP_165 << 8) | (TWTR_165 << 16))
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5 v2] ARM:OMAP3:SDP3430: initial support
From: David Brownell Start of support of Texas Instruments Software Development Platform(SDP) for OMAP3430 - SDP3430 Highlights of this platform are: Flash Memory devices: Sibley NOR, Micron 8bit NAND and OneNAND Connectivity: 3 UARTs and expanded 4 UART ports + IrDA Ethernet, USB Other peripherals: TWL5030 PMIC+Audio+Keypad VGA display Expansion ports: Memory devices plugin boards (PISMO) Connectivity board for GPS,WLAN etc.. Completely configurable boot sequence and device mapping etc.. For more details, please refer: http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=28741 U-boot support introduced for: Support default jumpering and: - UART1/ttyS0 console(legacy sdp3430 u-boot) - UART3/ttyS2 console (matching other boards, and SDP HW docs) - Ethernet - mmc0 - NOR boot TODO: - mmc1 - NAND (boot or 128M storage) - OneNAND (boot or 256M storage) - Fix NOR env variable load - Review SDRC timing configuration/DPLL configuration - Dynamically read FPGA dip switch settings and map NOR/NAND/ONENAND devices to right chipselects Currently the UART1 is enabled by default. for compatibility with other OMAP3 u-boot platforms, enable the #define of CONSOLE_J9. Signed-off-by: David Brownell Signed-off-by: Nishanth Menon Cc: Vikram Pandita Cc: Richard Woodruff Cc: Sandeep Paulraj Cc: Tom Rix Cc: Dirk Behme --- MAINTAINERS |1 + MAKEALL |1 + Makefile|3 + board/ti/sdp3430/Makefile | 49 + board/ti/sdp3430/config.mk | 33 +++ board/ti/sdp3430/sdp.c | 204 +++ board/ti/sdp3430/sdp.h | 417 +++ include/configs/omap3_sdp3430.h | 366 ++ 8 files changed, 1074 insertions(+), 0 deletions(-) create mode 100644 board/ti/sdp3430/Makefile create mode 100644 board/ti/sdp3430/config.mk create mode 100644 board/ti/sdp3430/sdp.c create mode 100644 board/ti/sdp3430/sdp.h create mode 100644 include/configs/omap3_sdp3430.h diff --git a/MAINTAINERS b/MAINTAINERS index 2297651..5742782 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -628,6 +628,7 @@ Guennadi Liakhovetski Nishanth Menon + omap3_sdp3430 ARM CORTEX-A8 (OMAP3xx SoC) omap3_zoom1 ARM CORTEX-A8 (OMAP3xx SoC) David Müller diff --git a/MAKEALL b/MAKEALL index 38cd076..9bf75e8 100755 --- a/MAKEALL +++ b/MAKEALL @@ -603,6 +603,7 @@ LIST_ARM_CORTEX_A8="\ omap3_overo \ omap3_evm \ omap3_pandora \ + omap3_sdp3430 \ omap3_zoom1 \ omap3_zoom2 \ " diff --git a/Makefile b/Makefile index 9637643..8dbe552 100644 --- a/Makefile +++ b/Makefile @@ -3144,6 +3144,9 @@ omap3_zoom1_config : unconfig omap3_zoom2_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 logicpd omap3 +omap3_sdp3430_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 sdp3430 ti omap3 + # ## XScale Systems # diff --git a/board/ti/sdp3430/Makefile b/board/ti/sdp3430/Makefile new file mode 100644 index 000..2554c7b --- /dev/null +++ b/board/ti/sdp3430/Makefile @@ -0,0 +1,49 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := sdp.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinc
[U-Boot] [PATCH 0/5 v2] ARM:OMAP3:SDP3430 initial support
This series of patch provides minimal support for OMAP3430 based SDP3430 platform Ref: http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=28741 Rev 1 of this patch series was discussed in: http://www.nabble.com/forum/Permalink.jtp?root=25518020&post=25518020&page=y 1 patch was removed from the series and 2 patches were reworked but the entire series is being send out after being rebased to: http://git.denx.de/?p=u-boot/u-boot-ti.git;a=summary This is to ensure continuity of discussion. David Brownell (1): ARM:OMAP3:SDP3430: initial support (v2) Nishanth Menon (4): OMAP3: Fix SDRC init (v2) OMAP3: export enable_gpmc_cs_config to board files OMAP3: make gpmc_config as const OMAP3: fix warnings when NAND/ONENAND is not used MAINTAINERS|1 + MAKEALL|1 + Makefile |3 + board/ti/sdp3430/Makefile | 49 board/ti/sdp3430/config.mk | 33 +++ board/ti/sdp3430/sdp.c | 204 board/ti/sdp3430/sdp.h | 417 cpu/arm_cortexa8/omap3/mem.c | 15 +- include/asm-arm/arch-omap3/cpu.h |1 + include/asm-arm/arch-omap3/mem.h |8 +- include/asm-arm/arch-omap3/sys_proto.h |2 + include/configs/omap3_sdp3430.h| 366 12 files changed, 1091 insertions(+), 9 deletions(-) create mode 100644 board/ti/sdp3430/Makefile create mode 100644 board/ti/sdp3430/config.mk create mode 100644 board/ti/sdp3430/sdp.c create mode 100644 board/ti/sdp3430/sdp.h create mode 100644 include/configs/omap3_sdp3430.h Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] DLMALLOC:!X86: add av_ initialization
Graeme Russ had written, on 10/06/2009 09:52 PM, the following:
> On Wed, Oct 7, 2009 at 1:13 PM, Nishanth Menon wrote:
>> Remove the predefined static initialization
>> and generate the map dynamically to reduce
>> code size.
>>
>> This patch benefits were pointed out by Peter:
>> http://www.nabble.com/forum/Permalink.jtp?root=25518020&post=25523748&page=y
>>
>> Signed-off-by: Nishanth Menon
>> Cc: Peter Tyser
>> Cc: Sandeep Paulraj
>> Cc: Tom Rix
>> ---
>> common/dlmalloc.c |9 +
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/common/dlmalloc.c b/common/dlmalloc.c
>> index 241db8c..25e5314 100644
>> --- a/common/dlmalloc.c
>> +++ b/common/dlmalloc.c
>> @@ -1474,6 +1474,7 @@ typedef struct malloc_chunk* mbinptr;
>>
>> #define IAV(i) bin_at(i), bin_at(i)
>>
>> +#ifdef CONFIG_X86
>> static mbinptr av_[NAV * 2 + 2] = {
>> 0, 0,
>> IAV(0), IAV(1), IAV(2), IAV(3), IAV(4), IAV(5), IAV(6),
>> IAV(7),
>> @@ -1493,6 +1494,9 @@ static mbinptr av_[NAV * 2 + 2] = {
>> IAV(112), IAV(113), IAV(114), IAV(115), IAV(116), IAV(117), IAV(118),
>> IAV(119),
>> IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125), IAV(126),
>> IAV(127)
>> };
>> +#else
>> +static mbinptr av_[NAV * 2 + 2];
>> +#endif
>
> Is there any reason why X86 is treated differently? I know the previous
> patch to dlmalloc.c did, but in the end it really didn't need to and ended
> up breaking the x86 build anyway (my fault for not getting time to test it
> before it went mainline)
>
> Feel free to remove this #ifdef unless you are 100% sure it IS needed.
> Mainline x86 is broken anyway - if this change introduces another break, I
> will submit a consolidated fix soon
I dont have any rationale to retain the #ifdef.. it is ugly.. will kick
it out and send out a v3 of this patch in a short while.
>
>> void malloc_bin_reloc (void)
>> {
>> @@ -1527,6 +1531,11 @@ void *sbrk(ptrdiff_t increment)
>> */
>> void mem_malloc_init(ulong start, ulong size)
>> {
>> + u8 i;
>> + av_[0] = av_[1] = 0;
>> + for (i = 0; i < 128; i++)
>> + av_[2 + i * 2] = av_[2 + i * 2 + 1] = bin_at(i);
>> +
>>mem_malloc_start = start;
>>mem_malloc_end = start + size;
>>mem_malloc_brk = start;
>> --
>> 1.6.0.4
>
> Regards,
>
> Graeme
>
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5 v3] ARM:OMAP3:SDP3430: initial support
From: David Brownell Sandeep pointed me to: http://lists.denx.de/pipermail/u-boot/2009-October/062086.html so the v3 of patch with size fixes Start of support of Texas Instruments Software Development Platform(SDP) for OMAP3430 - SDP3430 Highlights of this platform are: Flash Memory devices: Sibley NOR, Micron 8bit NAND and OneNAND Connectivity: 3 UARTs and expanded 4 UART ports + IrDA Ethernet, USB Other peripherals: TWL5030 PMIC+Audio+Keypad VGA display Expansion ports: Memory devices plugin boards (PISMO) Connectivity board for GPS,WLAN etc.. Completely configurable boot sequence and device mapping etc.. For more details, please refer: http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=28741 Support default jumpering and: - UART1/ttyS0 console(legacy sdp3430 u-boot) - UART3/ttyS2 console (matching other boards, and SDP HW docs) - Ethernet - mmc0 - NOR boot TODO: - mmc1 - NAND (boot or 128M storage) - OneNAND (boot or 256M storage) - Fix NOR env variable load - Review SDRC timing configuration/DPLL configuration - Dynamically read FPGA dip switch settings and map NOR/NAND/ONENAND devices to right chipselects Currently the UART1 is enabled by default. for compatibility with other OMAP3 u-boot platforms, enable the #define of CONSOLE_J9. Signed-off-by: David Brownell Signed-off-by: Nishanth Menon Cc: Vikram Pandita Cc: Richard Woodruff Cc: Sandeep Paulraj Cc: Tom Rix Cc: Dirk Behme --- MAINTAINERS |1 + MAKEALL |1 + Makefile|3 + board/ti/sdp3430/Makefile | 49 + board/ti/sdp3430/config.mk | 33 +++ board/ti/sdp3430/sdp.c | 204 +++ board/ti/sdp3430/sdp.h | 417 +++ include/configs/omap3_sdp3430.h | 369 ++ 8 files changed, 1077 insertions(+), 0 deletions(-) create mode 100644 board/ti/sdp3430/Makefile create mode 100644 board/ti/sdp3430/config.mk create mode 100644 board/ti/sdp3430/sdp.c create mode 100644 board/ti/sdp3430/sdp.h create mode 100644 include/configs/omap3_sdp3430.h diff --git a/MAINTAINERS b/MAINTAINERS index 2297651..5742782 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -628,6 +628,7 @@ Guennadi Liakhovetski Nishanth Menon + omap3_sdp3430 ARM CORTEX-A8 (OMAP3xx SoC) omap3_zoom1 ARM CORTEX-A8 (OMAP3xx SoC) David Müller diff --git a/MAKEALL b/MAKEALL index 38cd076..9bf75e8 100755 --- a/MAKEALL +++ b/MAKEALL @@ -603,6 +603,7 @@ LIST_ARM_CORTEX_A8="\ omap3_overo \ omap3_evm \ omap3_pandora \ + omap3_sdp3430 \ omap3_zoom1 \ omap3_zoom2 \ " diff --git a/Makefile b/Makefile index 9637643..8dbe552 100644 --- a/Makefile +++ b/Makefile @@ -3144,6 +3144,9 @@ omap3_zoom1_config : unconfig omap3_zoom2_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 logicpd omap3 +omap3_sdp3430_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 sdp3430 ti omap3 + # ## XScale Systems # diff --git a/board/ti/sdp3430/Makefile b/board/ti/sdp3430/Makefile new file mode 100644 index 000..2554c7b --- /dev/null +++ b/board/ti/sdp3430/Makefile @@ -0,0 +1,49 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := sdp.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depe
[U-Boot] [PATCH v3] DLMALLOC: make av_ initialization dynamic
Remove the predefined static initialization
and generate the map dynamically to reduce
code size.
This patch benefits were pointed out by Peter:
http://www.nabble.com/forum/Permalink.jtp?root=25518020&post=25523748&page=y
Additional comments from Graeme Russ on x86
support to be removed:
http://www.nabble.com/Re%3A--U-Boot---PATCH-v2--DLMALLOC%3A%21X86%3A-add-av_-initialization-p25779706.html
Tested on SDP3430 ONLY. Following code seem to
explicitly call this:
lib_avr32/board.c
lib_blackfin/board.c
lib_m68k/board.c
lib_mips/board.c
lib_nios2/board.c
lib_nios/board.c
lib_ppc/board.c
lib_sh/board.c
lib_sparc/board.c
These unfortunately could not be tested
Signed-off-by: Nishanth Menon
Cc: Peter Tyser
Cc: Graeme Russ
Cc: Sandeep Paulraj
Cc: Tom Rix
---
common/dlmalloc.c | 27 ++-
1 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 241db8c..9039b3e 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1474,25 +1474,7 @@ typedef struct malloc_chunk* mbinptr;
#define IAV(i) bin_at(i), bin_at(i)
-static mbinptr av_[NAV * 2 + 2] = {
- 0, 0,
- IAV(0), IAV(1), IAV(2), IAV(3), IAV(4), IAV(5), IAV(6), IAV(7),
- IAV(8), IAV(9), IAV(10), IAV(11), IAV(12), IAV(13), IAV(14), IAV(15),
- IAV(16), IAV(17), IAV(18), IAV(19), IAV(20), IAV(21), IAV(22), IAV(23),
- IAV(24), IAV(25), IAV(26), IAV(27), IAV(28), IAV(29), IAV(30), IAV(31),
- IAV(32), IAV(33), IAV(34), IAV(35), IAV(36), IAV(37), IAV(38), IAV(39),
- IAV(40), IAV(41), IAV(42), IAV(43), IAV(44), IAV(45), IAV(46), IAV(47),
- IAV(48), IAV(49), IAV(50), IAV(51), IAV(52), IAV(53), IAV(54), IAV(55),
- IAV(56), IAV(57), IAV(58), IAV(59), IAV(60), IAV(61), IAV(62), IAV(63),
- IAV(64), IAV(65), IAV(66), IAV(67), IAV(68), IAV(69), IAV(70), IAV(71),
- IAV(72), IAV(73), IAV(74), IAV(75), IAV(76), IAV(77), IAV(78), IAV(79),
- IAV(80), IAV(81), IAV(82), IAV(83), IAV(84), IAV(85), IAV(86), IAV(87),
- IAV(88), IAV(89), IAV(90), IAV(91), IAV(92), IAV(93), IAV(94), IAV(95),
- IAV(96), IAV(97), IAV(98), IAV(99), IAV(100), IAV(101), IAV(102),
IAV(103),
- IAV(104), IAV(105), IAV(106), IAV(107), IAV(108), IAV(109), IAV(110),
IAV(111),
- IAV(112), IAV(113), IAV(114), IAV(115), IAV(116), IAV(117), IAV(118),
IAV(119),
- IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125), IAV(126), IAV(127)
-};
+static mbinptr av_[NAV * 2 + 2];
void malloc_bin_reloc (void)
{
@@ -1520,20 +1502,23 @@ void *sbrk(ptrdiff_t increment)
return (void *)old;
}
-#ifndef CONFIG_X86
/*
* x86 boards use a slightly different init sequence thus they implement
* their own version of mem_malloc_init()
*/
void mem_malloc_init(ulong start, ulong size)
{
+ u8 i;
+ av_[0] = av_[1] = 0;
+ for (i = 0; i < 128; i++)
+ av_[2 + i * 2] = av_[2 + i * 2 + 1] = bin_at(i);
+
mem_malloc_start = start;
mem_malloc_end = start + size;
mem_malloc_brk = start;
memset((void *)mem_malloc_start, 0, size);
}
-#endif
/* field-extraction macros */
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Watchdog of omap 3530 in U-Boot
Ratheesh said the following on 10/07/2009 12:45 AM: > Hi >I need to use watchdog timer of OMAP-3530 in U-Boot. > Has anybody used watchdog timer of OMAP3530 successfully? > yes on 3430 (similar to 3530) > Kindly provide me links to source. > please read the public TRM - chapter Timers -> see watchdog there are only few registers and should be easy to use. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] OMAP3: make gpmc_config as const
Dirk Behme said the following on 10/11/2009 02:54 AM:
> Nishanth Menon wrote:
>
>> gpmc_config should not be a variant as it is board specific
>> hence make it a const parameter
>>
>
> Having this in u-boot-ti/next results in
>
> - All non-SDP3430 boards have
>
> mem.c: In function 'gpmc_init':
> mem.c:250: warning: assignment discards qualifiers from pointer target
> type
>
> - Zoom2 fails to build with
>
> zoom2.c:54: error: conflicting types for 'enable_gpmc_cs_config'
> /include/asm/arch/sys_proto.h:38: error: previous declaration of
> 'enable_gpmc_cs_config' was here
>
> Reverting this patch makes both go away
Redone patch attached - MAKEALL tested ONLY. apologies on the noise.
ethernet still pending..
Regards,
Nishanth Menon
>From 2199f2aa8d59d81140c34388da5bdc7338bd6c27 Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Sat, 10 Oct 2009 19:28:03 -0400
Subject: [PATCH] OMAP3: make gpmc_config as const
gpmc_config should not be a variant as it is board specific
hence make it a const parameter
Fixes issues identified by Dirk: build issue for zoom2 +
warnings for all OMAP3 other platforms using nand/onenand etc..
Signed-off-by: Nishanth Menon
Cc: David B
Cc: Vikram Pandita
Cc: Richard Woodruff
Cc: Sandeep Paulraj
Cc: Tom Rix
Cc: Dirk Behme
---
board/logicpd/zoom2/zoom2.c|3 ---
cpu/arm_cortexa8/omap3/mem.c |8
include/asm-arm/arch-omap3/sys_proto.h |2 +-
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/board/logicpd/zoom2/zoom2.c b/board/logicpd/zoom2/zoom2.c
index d9e2ae5..2dbab28 100644
--- a/board/logicpd/zoom2/zoom2.c
+++ b/board/logicpd/zoom2/zoom2.c
@@ -50,9 +50,6 @@
* The details of the setting of the serial gpmc setup are not available.
* The values were provided by another party.
*/
-void enable_gpmc_cs_config(u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
- u32 size);
-
static u32 gpmc_serial_TL16CP754C[GPMC_MAX_REG] = {
0x00011000,
0x001F1F01,
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index fc65f11..5e6d542 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -44,7 +44,7 @@ volatile unsigned int boot_flash_env_addr;
struct gpmc *gpmc_cfg;
#if defined(CONFIG_CMD_NAND)
-static u32 gpmc_m_nand[GPMC_MAX_REG] = {
+static const u32 gpmc_m_nand[GPMC_MAX_REG] = {
M_NAND_GPMC_CONFIG1,
M_NAND_GPMC_CONFIG2,
M_NAND_GPMC_CONFIG3,
@@ -62,7 +62,7 @@ static u32 gpmc_m_nand[GPMC_MAX_REG] = {
#endif
#if defined(CONFIG_CMD_ONENAND)
-static u32 gpmc_onenand[GPMC_MAX_REG] = {
+static const u32 gpmc_onenand[GPMC_MAX_REG] = {
ONENAND_GPMC_CONFIG1,
ONENAND_GPMC_CONFIG2,
ONENAND_GPMC_CONFIG3,
@@ -193,7 +193,7 @@ void do_sdrc_init(u32 cs, u32 early)
writel(0, &sdrc_base->cs[cs].mcfg);
}
-void enable_gpmc_cs_config(u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
u32 size)
{
writel(0, &cs->config7);
@@ -221,7 +221,7 @@ void gpmc_init(void)
/* putting a blanket check on GPMC based on ZeBu for now */
gpmc_cfg = (struct gpmc *)GPMC_BASE;
#if defined(CONFIG_CMD_NAND) || defined(CONFIG_CMD_ONENAND)
- u32 *gpmc_config = NULL;
+ const u32 *gpmc_config = NULL;
u32 base = 0;
u32 size = 0;
#if defined(CONFIG_ENV_IS_IN_NAND) || defined(CONFIG_ENV_IS_IN_ONENAND)
diff --git a/include/asm-arm/arch-omap3/sys_proto.h b/include/asm-arm/arch-omap3/sys_proto.h
index e59021e..34bd515 100644
--- a/include/asm-arm/arch-omap3/sys_proto.h
+++ b/include/asm-arm/arch-omap3/sys_proto.h
@@ -34,7 +34,7 @@ void memif_init(void);
void sdrc_init(void);
void do_sdrc_init(u32, u32);
void gpmc_init(void);
-void enable_gpmc_cs_config(u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
u32 size);
void watchdog_init(void);
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] OMAP3: make gpmc_config as const
Paulraj, Sandeep said the following on 10/11/2009 09:48 AM: > >> Dirk Behme said the following on 10/11/2009 02:54 AM: >> >>> Nishanth Menon wrote: >>> >>> >>>> gpmc_config should not be a variant as it is board specific >>>> hence make it a const parameter >>>> >>>> >>> Having this in u-boot-ti/next results in >>> >>> - All non-SDP3430 boards have >>> >>> mem.c: In function 'gpmc_init': >>> mem.c:250: warning: assignment discards qualifiers from pointer target >>> type >>> >>> - Zoom2 fails to build with >>> >>> zoom2.c:54: error: conflicting types for 'enable_gpmc_cs_config' >>> /include/asm/arch/sys_proto.h:38: error: previous declaration of >>> 'enable_gpmc_cs_config' was here >>> >>> Reverting this patch makes both go away >>> >> Redone patch attached - MAKEALL tested ONLY. apologies on the noise. >> > > Pushed to u-boot-ti next > > http://git.denx.de/?p=u-boot/u-boot-ti.git;a=commit;h=78c38ce87f7423eedba844e8594cfc5a4fa6051b > > thanks. i have an ethernet patch.. but i need to reach office later today to test it.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-ti next updated
On Mon, Oct 12, 2009 at 9:41 AM, Dirk Behme wrote: > Steve Sakoman wrote: >> >> On Sun, Oct 11, 2009 at 7:16 AM, Steve Sakoman wrote: >> >>> Compile and run test of the Overo build was fine with Tobi card. >>> Later today I will try some of the other daughter cards to make sure >>> it works with all of them. >> >> Heh, I spoke too soon! >> >> U-boot appeared to run fine, but it fails in it's main mission in life >> -- to load & execute the linux kernel. >> >> Overo hangs after the uncompressing kernel message. > > Hmm, on beagle it seems to be fine, though. SDP3430 also seems to boot fine. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP3: proposal: dont piggy back on ROMCode interrupt vectors
Hi, Current interrupt vectors[1] are piggy backing on OMAP3 ROM Code vectors This has the disadvantage that "external boot" option of OMAP GP devices for booting off NOR devices would probably not function as the interrupt vectors are not setup. I had faced this during the port of u-boot-v2 and had done an implementation[2] for this. would we be interested in pulling this back in for u-boot-v1? I suppose all OMAP3 devices could benefit from it. Regards, Nishanth Menon Ref: [1] http://git.denx.de/?p=u-boot/u-boot-ti.git;a=blob;f=cpu/arm_cortexa8/start.S;h=14a9bd3b039143f92aed2133493aa9ee6a175738;hb=HEAD#l112 [2] http://git.denx.de/?p=u-boot/u-boot-v2.git;a=blob;f=arch/arm/mach-omap/omap3_core.S;h=dece199faefb3354189347d17cb0709d0ce2ad6c;hb=HEAD#l71 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: proposal: dont piggy back on ROMCode interrupt vectors
On Tue, Oct 13, 2009 at 7:27 AM, Tom Rix wrote: > Nishanth Menon wrote: >> >> Hi, >> Current interrupt vectors[1] are piggy backing on OMAP3 ROM Code vectors >> This has the disadvantage that "external boot" option of OMAP GP devices >> for booting off NOR devices would probably not function as the interrupt >> vectors are not setup. >> > In general we want to limit dependencies of ROM code. > And it should be moved to omap3 so other cortexa8 users don't have to > code around it. Like we did for the cache flushing. > >> I had faced this during the port of u-boot-v2 and had done an >> implementation[2] for this. would we be interested in pulling this back >> in for u-boot-v1? I suppose all OMAP3 devices could benefit from it. >> > > Poking around it does not look like any of the omap boards define > CONFIG_USE_IRQ so it seems like you really will be creating the > interrupt handlers. I think this is a good idea as long as the existing > non-interrupts still works. I would be happy to test whatever you want to > do. Should we set up a special ti-omap-irq topic branch ? it is going to be just a silly little patch.. and given it is a cp15 feature, I think it might be cortex_a8 specific and not OMAP3 specific.. it would be good to have the irqs to be enabled for data abort reports etc.. but then, that is just my 2 cents.. > > Tom > > >> Regards, >> Nishanth Menon >> >> Ref: >> [1] >> >> http://git.denx.de/?p=u-boot/u-boot-ti.git;a=blob;f=cpu/arm_cortexa8/start.S;h=14a9bd3b039143f92aed2133493aa9ee6a175738;hb=HEAD#l112 >> [2] >> >> http://git.denx.de/?p=u-boot/u-boot-v2.git;a=blob;f=arch/arm/mach-omap/omap3_core.S;h=dece199faefb3354189347d17cb0709d0ce2ad6c;hb=HEAD#l71 >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> >> > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NET: SDP3430: trouble with shifting from LAN9C916 to SMC91XX driver
Hi Folks,
While attempting to address the warning for SDP3430 as pointed out by
dirk in [1], I did a patch corresponding to what was done for EVM(353x)
as in [2]. unfortunately, this wont work for me, I get:
U-Boot 2009.08-00515-gfea6a55-dirty (Oct 12 2009 - 14:03:23)
OMAP3530-GP ES3.0, CPU-OPP2 L3-165MHz
OMAP3 SDP3430 board + LPDDR/NOR
I2C: ready
DRAM: 128 MB
Flash: 128 MB
In:serial
Out: serial
Err: serial
smc911x: Invalid chip endian 0xdee0013d
Net: No ethernet found.
OMAP34XX SDP #
and no network, using LEGACY driver seems to be working just great for me.
Note: in my patch [2], I did try both CONFIG_SMC911X_32_BIT and
CONFIG_SMC911X_16_BIT with no luck either way. I even tried to hack the
driver by skipping the supported chip detection code, but the driver
still did not work for me.
scanning a little more in the git repo, I see all the ancient boards of
OMAP family - 5912,2420 etc.. still have LEGACY driver being used..
I am pretty sure I must be missing something here and appreciate any
guidance folks can give me on this..
--
Regards,
Nishanth Menon
Ref:
[1]
http://www.nabble.com/forum/Permalink.jtp?root=25837696&post=25841367&page=y
[2]
From fea6a55cb67b3fda1d93da74b2fe68fb25376e7e Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Mon, 12 Oct 2009 13:54:17 -0500
Subject: [BAD][PATCH] TI OMAP3: SDP3430: dont use legacy ethernet driver
Stop using the LEGACY driver and use NET_MULTI
this also removes the build warning for SDP3430
---
board/ti/sdp3430/sdp.c |8 +---
include/configs/omap3_sdp3430.h |7 ---
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/board/ti/sdp3430/sdp.c b/board/ti/sdp3430/sdp.c
index 40cf26f..85181c8 100644
--- a/board/ti/sdp3430/sdp.c
+++ b/board/ti/sdp3430/sdp.c
@@ -22,6 +22,7 @@
* MA 02111-1307 USA
*/
#include
+#include
#include
#include
#include
@@ -121,8 +122,8 @@ int board_init(void)
return 0;
}
-#define LAN_RESET_REGISTER (CONFIG_LAN91C96_BASE + 0x01c)
-#define ETH_CONTROL_REG(CONFIG_LAN91C96_BASE + 0x30b)
+#define LAN_RESET_REGISTER (CONFIG_SMC911X_BASE + 0x01c)
+#define ETH_CONTROL_REG(CONFIG_SMC911X_BASE + 0x30b)
/**
* @brief ether_init Take the Ethernet controller out of reset and wait
@@ -130,7 +131,7 @@ int board_init(void)
*/
static void ether_init(void)
{
-#ifdef CONFIG_DRIVER_LAN91C96
+#ifdef CONFIG_SMC911X
int cnt = 20;
writew(0x0, LAN_RESET_REGISTER);
@@ -155,6 +156,7 @@ static void ether_init(void)
writeb(readb(ETH_CONTROL_REG) & ~0x1, ETH_CONTROL_REG);
udelay(1000);
+ smc911x_initialize(0, CONFIG_SMC911X_BASE);
reset_err_out:
return;
diff --git a/include/configs/omap3_sdp3430.h
b/include/configs/omap3_sdp3430.h
index 229dc5e..7b0a248 100644
--- a/include/configs/omap3_sdp3430.h
+++ b/include/configs/omap3_sdp3430.h
@@ -200,9 +200,10 @@
*/
#if defined(CONFIG_CMD_NET)
-#define CONFIG_DRIVER_LAN91C96
-#define CONFIG_LAN91C96_BASE DEBUG_BASE
-#define CONFIG_LAN91C96_EXT_PHY
+#define CONFIG_NET_MULTI
+#define CONFIG_SMC911X
+#define CONFIG_SMC911X_32_BIT
+#define CONFIG_SMC911X_BASEDEBUG_BASE
#define CONFIG_BOOTP_SEND_HOSTNAME
/*
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NET: SDP3430: trouble with shifting from LAN9C916 to SMC91XX driver
Ben Warren had written, on 10/13/2009 11:36 PM, the following:
Nishanth,
On Tue, Oct 13, 2009 at 8:13 PM, Nishanth Menon <mailto:n...@ti.com>> wrote:
Hi Folks,
While attempting to address the warning for SDP3430 as pointed out by
dirk in [1], I did a patch corresponding to what was done for EVM(353x)
as in [2]. unfortunately, this wont work for me, I get:
U-Boot 2009.08-00515-gfea6a55-dirty (Oct 12 2009 - 14:03:23)
OMAP3530-GP ES3.0, CPU-OPP2 L3-165MHz
OMAP3 SDP3430 board + LPDDR/NOR
I2C: ready
DRAM: 128 MB
Flash: 128 MB
In:serial
Out: serial
Err: serial
smc911x: Invalid chip endian 0xdee0013d
Net: No ethernet found.
OMAP34XX SDP #
and no network, using LEGACY driver seems to be working just great
for me.
Note: in my patch [2], I did try both CONFIG_SMC911X_32_BIT and
CONFIG_SMC911X_16_BIT with no luck either way. I even tried to hack the
driver by skipping the supported chip detection code, but the driver
still did not work for me.
When using CONFIG_NET_MULTI you need to have a board_eth_init() function
done
in your board code which in turn must call smc911x_initialize(). Make
done
sure that eth_initialize() gets called somewhere in your cpu/board.c
why eth_initalize? rest of the OMAP3 boards dont seem to be doing that
call sequence. I suspect that while the SMC911x driver is being
initialized, it isn't being registered properly with the networking
library. There are many examples in the source tree of how to do this.
I would expect that and did check too, but why:
smc911x: Invalid chip endian 0xdee0013d
when I had a base address and device which was supported by LAN91C96
legacy driver?
My lack of network chip knowledge is kicking me at the moment.. trying
to find the device data sheet internally @ TI..
--
Regards,
Nishanth Menon
>From db2fd6d0ee801696a7e1d9568f4c526ae3d16c4b Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Mon, 12 Oct 2009 13:54:17 -0500
Subject: [BAD] [PATCH] TI OMAP3: SDP3430: dont use legacy ethernet driver
Stop using the LEGACY driver and use NET_MULTI
this also removes the build warning for SDP3430
Signed-off-by: Nishanth Menon
---
board/ti/sdp3430/sdp.c | 16 ++--
include/configs/omap3_sdp3430.h |7 ---
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/board/ti/sdp3430/sdp.c b/board/ti/sdp3430/sdp.c
index 40cf26f..529956f 100644
--- a/board/ti/sdp3430/sdp.c
+++ b/board/ti/sdp3430/sdp.c
@@ -22,6 +22,7 @@
* MA 02111-1307 USA
*/
#include
+#include
#include
#include
#include
@@ -121,16 +122,18 @@ int board_init(void)
return 0;
}
-#define LAN_RESET_REGISTER (CONFIG_LAN91C96_BASE + 0x01c)
-#define ETH_CONTROL_REG (CONFIG_LAN91C96_BASE + 0x30b)
+#define LAN_RESET_REGISTER (CONFIG_SMC911X_BASE + 0x01c)
+#define ETH_CONTROL_REG (CONFIG_SMC911X_BASE + 0x30b)
/**
* @brief ether_init Take the Ethernet controller out of reset and wait
* for the EEPROM load to complete.
*/
-static void ether_init(void)
+int board_eth_init(bd_t *bis)
{
-#ifdef CONFIG_DRIVER_LAN91C96
+ int rc = 0;
+#ifdef CONFIG_SMC911X
+#if 0
int cnt = 20;
writew(0x0, LAN_RESET_REGISTER);
@@ -157,8 +160,11 @@ static void ether_init(void)
udelay(1000);
reset_err_out:
return;
+#endif
+ rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
#endif
+ return rc;
}
/**
@@ -187,8 +193,6 @@ int misc_init_r(void)
* VSIM - off (init, variable) for MMC1.DAT[3..7], SIM
* VPLL2 - 1.8V
*/
- ether_init();
-
return 0;
}
diff --git a/include/configs/omap3_sdp3430.h b/include/configs/omap3_sdp3430.h
index 229dc5e..7b0a248 100644
--- a/include/configs/omap3_sdp3430.h
+++ b/include/configs/omap3_sdp3430.h
@@ -200,9 +200,10 @@
*/
#if defined(CONFIG_CMD_NET)
-#define CONFIG_DRIVER_LAN91C96
-#define CONFIG_LAN91C96_BASE DEBUG_BASE
-#define CONFIG_LAN91C96_EXT_PHY
+#define CONFIG_NET_MULTI
+#define CONFIG_SMC911X
+#define CONFIG_SMC911X_32_BIT
+#define CONFIG_SMC911X_BASE DEBUG_BASE
#define CONFIG_BOOTP_SEND_HOSTNAME
/*
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NET: SDP3430: trouble with shifting from LAN9C916 to SMC91XX driver
On Wed, Oct 14, 2009 at 2:00 PM, Ben Warren wrote: [...] > The SMC911x chips all contain the magic value 0x87654321 @ offset 0x64. > Your board has something else there (it's obviously not an endianness > issue, so ignore the error message text). I think you need to learn > more about your board, in particular which SMCS chip you're using, which > data width and where it's located in memory. This is a simple > memory-mapped device, and once you find out where it's located, it > should 'just work' > > Here's a datasheet for reference. See page 68 for the memory map. > > http://www.smsc.com/media/Downloads_Public/Data_Sheets/9116.pdf 9116 seems to use memory mapped regs, while 91c96 [1] page 39 shows it to use banked register access. So unfortunately, SMC911X would not support this chip as I cannot even see the banked registers in smc911x.[ch]. so unfortuantely, I cant switch to SMC911X driver and will have to wait till lan91c96.c becomes NET_MULTI to be able to remove the warning in sdp3430 build. In fact, I think the following boards use the legacy LAN91C96 driver: include/configs/apollon.h include/configs/assabet.h include/configs/B2.h include/configs/gcplus.h include/configs/lubbock.h include/configs/omap1510inn.h include/configs/omap1610h2.h include/configs/omap1610inn.h include/configs/omap2420h4.h include/configs/omap5912osk.h include/configs/omap730p2.h to confirm a non ti board which uses this legacy chip, I tried building B2, and yep, I see the same warning which was plaguing me :(.. Do let me know if there are alternatives available. Regards, Nishanth Menon Ref: [1] http://www.embeddedsys.com/subpages/resources/images/documents/LAN91C96_datasheet.pdf ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] enable CONFIG_NET_MULTI for LAN91C96
Based on the discussion[1] here is the patchset Patchset is based on [2], and tested on SDP3430. Other platforms would be prefered to be build/tested/fixed as required Nishanth Menon (3): NET: LAN91C96 CONFIG_NET_MULTIify TI OMAP3: SDP3430 FIX NET_MULTI Warning LAN91C96: Enable NET_MULTI LAN driver board/apollon/apollon.c | 12 +- board/ti/sdp3430/sdp.c | 12 +- drivers/net/Makefile|2 +- drivers/net/lan91c96.c | 452 --- drivers/net/lan91c96.h | 110 +- include/configs/B2.h|2 +- include/configs/apollon.h |3 +- include/configs/assabet.h |3 +- include/configs/gcplus.h|3 +- include/configs/lubbock.h |3 +- include/configs/omap1510inn.h |3 +- include/configs/omap1610h2.h|3 +- include/configs/omap1610inn.h |3 +- include/configs/omap2420h4.h|3 +- include/configs/omap3_sdp3430.h |3 +- include/configs/omap5912osk.h |3 +- include/configs/omap730p2.h |3 +- include/configs/pleb2.h |6 +- include/netdev.h|1 + 19 files changed, 277 insertions(+), 353 deletions(-) Regards, Nishanth Menon Ref: [1] http://www.nabble.com/-U-Boot--NET%3A-SDP3430%3A-trouble-with-shifting-from-LAN9C916-to-SMC91XX-driver-td25884700.html [2] http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-ti.git ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] TI OMAP3: SDP3430 FIX NET_MULTI Warning
Enable the NET MULTI option and remove build warning
Tested: SDP3430
Signed-off-by: Nishanth Menon
Cc: Ben Warren
Cc: Sandeep Paulraj
---
board/ti/sdp3430/sdp.c | 12 +++-
include/configs/omap3_sdp3430.h |3 ++-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/board/ti/sdp3430/sdp.c b/board/ti/sdp3430/sdp.c
index 40cf26f..0d8e20d 100644
--- a/board/ti/sdp3430/sdp.c
+++ b/board/ti/sdp3430/sdp.c
@@ -22,6 +22,7 @@
* MA 02111-1307 USA
*/
#include
+#include
#include
#include
#include
@@ -125,12 +126,13 @@ int board_init(void)
#define ETH_CONTROL_REG(CONFIG_LAN91C96_BASE + 0x30b)
/**
- * @brief ether_init Take the Ethernet controller out of reset and wait
+ * @brief board_eth_init Take the Ethernet controller out of reset and wait
* for the EEPROM load to complete.
*/
-static void ether_init(void)
+int board_eth_init(bd_t *bis)
{
-#ifdef CONFIG_DRIVER_LAN91C96
+ int rc = 0;
+#ifdef CONFIG_LAN91C96
int cnt = 20;
writew(0x0, LAN_RESET_REGISTER);
@@ -155,10 +157,11 @@ static void ether_init(void)
writeb(readb(ETH_CONTROL_REG) & ~0x1, ETH_CONTROL_REG);
udelay(1000);
+ rc = lan91c96_initialize(0, CONFIG_LAN91C96_BASE);
reset_err_out:
- return;
#endif
+ return rc;
}
/**
@@ -187,7 +190,6 @@ int misc_init_r(void)
* VSIM - off (init, variable) for MMC1.DAT[3..7], SIM
* VPLL2 - 1.8V
*/
- ether_init();
return 0;
}
diff --git a/include/configs/omap3_sdp3430.h b/include/configs/omap3_sdp3430.h
index 229dc5e..7401671 100644
--- a/include/configs/omap3_sdp3430.h
+++ b/include/configs/omap3_sdp3430.h
@@ -200,7 +200,8 @@
*/
#if defined(CONFIG_CMD_NET)
-#define CONFIG_DRIVER_LAN91C96
+#define CONFIG_NET_MULTI
+#define CONFIG_LAN91C96
#define CONFIG_LAN91C96_BASE DEBUG_BASE
#define CONFIG_LAN91C96_EXT_PHY
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] LAN91C96: Enable NET_MULTI LAN driver
This modification is NOT tested on any of the
platforms modified as I dont have them. please
help by testing+building+fixing
Signed-off-by: Nishanth Menon
Cc: Andrea Scian
Cc: Ben Warren
Cc: Dave Peverley
Cc: George G. Davis
Cc: Kyungmin Park
Cc: Nishant Kamat
Cc: Richard Woodruff
Cc: Rishi Bhattacharya
Cc: Sandeep Paulraj
---
board/apollon/apollon.c | 12 +++-
include/configs/B2.h |2 +-
include/configs/apollon.h |3 ++-
include/configs/assabet.h |3 ++-
include/configs/gcplus.h |3 ++-
include/configs/lubbock.h |3 ++-
include/configs/omap1510inn.h |3 ++-
include/configs/omap1610h2.h |3 ++-
include/configs/omap1610inn.h |3 ++-
include/configs/omap2420h4.h |3 ++-
include/configs/omap5912osk.h |3 ++-
include/configs/omap730p2.h |3 ++-
include/configs/pleb2.h |6 --
13 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/board/apollon/apollon.c b/board/apollon/apollon.c
index 8964eba..b93e880 100644
--- a/board/apollon/apollon.c
+++ b/board/apollon/apollon.c
@@ -24,6 +24,7 @@
* MA 02111-1307 USA
*/
#include
+#include
#include
#include
#include
@@ -138,13 +139,14 @@ void wait_for_command_complete(unsigned int wd_base)
}
/***
- * Routine:ether_init
+ * Routine:board_eth_init
* Description: take the Ethernet controller out of reset and wait
*for the EEPROM load to complete.
**/
-void ether_init(void)
+int board_eth_init(bd_t *bis)
{
-#ifdef CONFIG_DRIVER_LAN91C96
+ int rc = 0;
+#ifdef CONFIG_LAN91C96
int cnt = 20;
__raw_writeb(0x03, OMAP2420_CTRL_BASE + 0x0f2); /*protect->gpio74 */
@@ -171,10 +173,10 @@ void ether_init(void)
mask_config_reg(ETH_CONTROL_REG, 0x01);
udelay(1000);
-
+ rc = lan91c96_initialize(0, CONFIG_LAN91C96_BASE);
eth_reset_err_out:
- return;
#endif
+ return rc;
}
/**
diff --git a/include/configs/B2.h b/include/configs/B2.h
index e5439f3..d7806e9 100644
--- a/include/configs/B2.h
+++ b/include/configs/B2.h
@@ -58,7 +58,7 @@
/*
* Hardware drivers
*/
-#define CONFIG_DRIVER_LAN91C96
+#define CONFIG_LAN91C96
#define CONFIG_LAN91C96_BASE 0x04000300 /* base address */
#define CONFIG_SMC_USE_32_BIT
#undef CONFIG_SHOW_ACTIVITY
diff --git a/include/configs/apollon.h b/include/configs/apollon.h
index 575f60e..be0dc04 100644
--- a/include/configs/apollon.h
+++ b/include/configs/apollon.h
@@ -87,7 +87,8 @@
/*
* SMC91c96 Etherent
*/
-#defineCONFIG_DRIVER_LAN91C96
+#define CONFIG_NET_MULTI
+#defineCONFIG_LAN91C96
#defineCONFIG_LAN91C96_BASE(APOLLON_CS1_BASE+0x300)
#defineCONFIG_LAN91C96_EXT_PHY
diff --git a/include/configs/assabet.h b/include/configs/assabet.h
index 8c5b84c..d17d4bd 100644
--- a/include/configs/assabet.h
+++ b/include/configs/assabet.h
@@ -53,7 +53,8 @@
/*
* Hardware drivers
*/
-#define CONFIG_DRIVER_LAN91C96 /* we have an SMC9194 on-board */
+#define CONFIG_NET_MULTI
+#define CONFIG_LAN91C96/* we have an SMC9194 on-board */
#define CONFIG_LAN91C96_BASE 0x1800
/*
diff --git a/include/configs/gcplus.h b/include/configs/gcplus.h
index 85db4f5..41294b9 100644
--- a/include/configs/gcplus.h
+++ b/include/configs/gcplus.h
@@ -66,7 +66,8 @@
/*
* Hardware drivers
*/
-#define CONFIG_DRIVER_LAN91C96 /* we have an SMC9194 on-board */
+#define CONFIG_NET_MULTI
+#define CONFIG_LAN91C96/* we have an SMC9194 on-board */
#define CONFIG_LAN91C96_BASE 0x100e
/*
diff --git a/include/configs/lubbock.h b/include/configs/lubbock.h
index 43913ca..0a69210 100644
--- a/include/configs/lubbock.h
+++ b/include/configs/lubbock.h
@@ -58,7 +58,8 @@
/*
* Hardware drivers
*/
-#define CONFIG_DRIVER_LAN91C96
+#define CONFIG_NET_MULTI
+#define CONFIG_LAN91C96
#define CONFIG_LAN91C96_BASE 0x0C00
/*
diff --git a/include/configs/omap1510inn.h b/include/configs/omap1510inn.h
index 8408209..b0ebafd 100644
--- a/include/configs/omap1510inn.h
+++ b/include/configs/omap1510inn.h
@@ -60,7 +60,8 @@
#define CONFIG_SMC9196_BASE 0x08000300
#define CONFIG_SMC9196_EXT_PHY
*/
-#define CONFIG_DRIVER_LAN91C96
+#define CONFIG_NET_MULTI
+#define CONFIG_LAN91C96
#define CONFIG_LAN91C96_BASE 0x08000300
#define CONFIG_LAN91C96_EXT_PHY
diff --git a/include/configs/omap1610h2.h b/include/configs/omap1610h2.h
index 42e0198..0bbb5b3 100644
--- a/include/configs/omap1610h2.h
+++ b/include/configs/omap1610h2.h
@@ -57,7 +57,8 @@
/*
* Hardware drivers
*/
-#define CONFIG_DRIVER_LAN91C96
+#define CONFIG_NET_MULTI
+#define CONFIG_LAN91C96
#define CONFIG_LAN91C96_BASE 0x04000300
#define CONFIG_LAN91C96_EXT_PHY
diff --git a/include/configs/omap1610inn.h b/include/configs/omap1610inn.h
index 22c873e..832d
[U-Boot] [PATCH 1/3] NET: LAN91C96 CONFIG_NET_MULTIify
Make the lan91c96 driver capable of CONFIG_NET_MULTI
to be clean for the new arch, add a a lil detect function
Most of the formatting change was done to keep checkpatch
silent, but a few functions and #if 0ed code which
does not make sense for NET_MULTI have been removed
Now, use the lan91c96_initialize() function to init the driver
Signed-off-by: Nishanth Menon
Cc: Andrea Scian
Cc: Ben Warren
Cc: Dave Peverley
Cc: George G. Davis
Cc: Kyungmin Park
Cc: Nishant Kamat
Cc: Richard Woodruff
Cc: Rishi Bhattacharya
Cc: Sandeep Paulraj
---
drivers/net/Makefile |2 +-
drivers/net/lan91c96.c | 452 +++
drivers/net/lan91c96.h | 110 ++---
include/netdev.h |1 +
4 files changed, 236 insertions(+), 329 deletions(-)
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index be5c484..a4ab447 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -44,7 +44,7 @@ COBJS-$(CONFIG_GRETH) += greth.o
COBJS-$(CONFIG_INCA_IP_SWITCH) += inca-ip_sw.o
COBJS-$(CONFIG_KIRKWOOD_EGIGA) += kirkwood_egiga.o
COBJS-$(CONFIG_DRIVER_KS8695ETH) += ks8695eth.o
-COBJS-$(CONFIG_DRIVER_LAN91C96) += lan91c96.o
+COBJS-$(CONFIG_LAN91C96) += lan91c96.o
COBJS-$(CONFIG_MACB) += macb.o
COBJS-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
COBJS-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o
diff --git a/drivers/net/lan91c96.c b/drivers/net/lan91c96.c
index 65565bc..90e4002 100644
--- a/drivers/net/lan91c96.c
+++ b/drivers/net/lan91c96.c
@@ -60,6 +60,7 @@
#include
#include
+#include
#include "lan91c96.h"
#include
@@ -108,11 +109,7 @@
*
*
*/
-#define CARDNAME "LAN91C96"
-
-#define SMC_BASE_ADDRESS CONFIG_LAN91C96_BASE
-
-#define SMC_DEV_NAME "LAN91C96"
+#define DRIVER_NAME "LAN91C96"
#define SMC_ALLOC_MAX_TRY 5
#define SMC_TX_TIMEOUT 30
@@ -124,64 +121,12 @@
#undef USE_32_BIT
#endif
-/*-
- *
- * The driver can be entered at any of the following entry points.
- *
- *-
- */
-
-extern int eth_init (bd_t * bd);
-extern void eth_halt (void);
-extern int eth_rx (void);
-extern int eth_send (volatile void *packet, int length);
-#if 0
-static int smc_hw_init (void);
-#endif
-
-/*
- * This is called by register_netdev(). It is responsible for
- * checking the portlist for the SMC9000 series chipset. If it finds
- * one, then it will initialize the device, find the hardware information,
- * and sets up the appropriate device parameters.
- * NOTE: Interrupts are *OFF* when this procedure is called.
- *
- * NB:This shouldn't be static since it is referred to externally.
- */
-int smc_init (void);
-
-/*
- * This is called by unregister_netdev(). It is responsible for
- * cleaning up before the driver is finally unregistered and discarded.
- */
-void smc_destructor (void);
-
-/*
- * The kernel calls this function when someone wants to use the device,
- * typically 'ifconfig ethX up'.
- */
-static int smc_open (bd_t *bd);
-
-
-/*
- * This is called by the kernel in response to 'ifconfig ethX down'. It
- * is responsible for cleaning up everything that the open routine
- * does, and maybe putting the card into a powerdown state.
- */
-static int smc_close (void);
-
-/*
- * This is a separate procedure to handle the receipt of a packet, to
- * leave the interrupt code looking slightly cleaner
- */
-static int smc_rcv (void);
-
/* See if a MAC address is defined in the current environment. If so use it.
If not
. print a warning and set the environment and other globals with the default.
. If an EEPROM is present it really should be consulted.
*/
-int smc_get_ethaddr(bd_t *bd);
-int get_rom_mac(unsigned char *v_rom_mac);
+static int smc_get_ethaddr(bd_t *bd, struct eth_device *dev);
+static int get_rom_mac(struct eth_device *dev, unsigned char *v_rom_mac);
/*
* Internal routines
@@ -195,7 +140,7 @@ static unsigned char smc_mac_addr[] = { 0xc0, 0x00, 0x00,
0x1b, 0x62, 0x9c };
* the default mac address.
*/
-void smc_set_mac_addr (const unsigned char *addr)
+static void smc_set_mac_addr(const unsigned char *addr)
{
int i;
@@ -204,45 +149,21 @@ void smc_set_mac_addr (const unsigned char *addr)
}
}
-/*
- * smc_get_macaddr is no longer used. If you want to override the default
- * mac address, call smc_get_mac_addr as a part of the board initialisation.
- */
-
-#if 0
-void smc_get_macaddr (byte * addr)
-{
- /* MAC ADDRESS AT FLASHBLOCK 1 / OFFSET 0x10 */
- unsigned char *dnp1110_mac = (unsigned char *) (0xE800 + 0x20010);
- int i;
-
-
- for (i = 0; i < 6; i++) {
- addr[0] = *(dnp1110_mac + 0);
- addr[1] = *(dnp1110_mac + 1);
- addr[
[U-Boot] OMAP3 DDR Fix patches (was Re: [PATCH 1/5 v2] OMAP3: Fix SDRC init)
Steve Sakoman had written, on 10/19/2009 10:06 AM, the following:
On Mon, Oct 19, 2009 at 7:55 AM, Dirk Behme wrote:
Steve Sakoman wrote:
On Tue, Oct 6, 2009 at 7:17 PM, Nishanth Menon wrote:
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Signed-off-by: Nishanth Menon
Cc: David B
Cc: Vikram Pandita
Cc: Richard Woodruff
Cc: Sandeep Paulraj
Cc: Tom Rix
Cc: Dirk Behme
---
cpu/arm_cortexa8/omap3/mem.c |3 ++-
include/asm-arm/arch-omap3/cpu.h |1 +
include/asm-arm/arch-omap3/mem.h |8
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 079c848..8731c9d 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -164,7 +164,8 @@ void do_sdrc_init(u32 cs, u32 early)
writel(SDP_SDRC_SHARING, &sdrc_base->sharing);
/* Disable Power Down of CKE cuz of 1 CKE on combo part */
- writel(SRFRONRESET | PAGEPOLICY_HIGH, &sdrc_base->power);
+ writel(WAKEUPPROC | PWDNEN | SRFRONRESET |
PAGEPOLICY_HIGH,
+ &sdrc_base->power);
writel(ENADLL | DLLPHASE_90, &sdrc_base->dlla_ctrl);
sdelay(0x2);
diff --git a/include/asm-arm/arch-omap3/cpu.h
b/include/asm-arm/arch-omap3/cpu.h
index 8ab2e39..e51c4f3 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -222,6 +222,7 @@ struct sdrc {
#define PAGEPOLICY_HIGH(0x1 << 0)
#define SRFRONRESET(0x1 << 7)
+#define PWDNEN (0x1 << 2)
#define WAKEUPPROC (0x1 << 26)
#define DDR_SDRAM (0x1 << 0)
diff --git a/include/asm-arm/arch-omap3/mem.h
b/include/asm-arm/arch-omap3/mem.h
index 5b9ac75..31cbdef 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -78,16 +78,16 @@ enum {
#define TRP_1653
#define TRAS_165 7
#define TRC_16510
-#define TRFC_165 21
+#define TRFC_165 12
#define V_ACTIMA_165 ((TRFC_165 << 27) | (TRC_165 << 22) | \
(TRAS_165 << 18) | (TRP_165 << 15) | \
(TRCD_165 << 12) | (TRRD_165 << 9) | \
(TDPL_165 << 6) | (TDAL_165))
#define TWTR_165 1
-#define TCKE_165 1
-#define TXP_1655
-#define XSR_16523
+#define TCKE_165 2
+#define TXP_1652
+#define XSR_16520
#define V_ACTIMB_165 (((TCKE_165 << 12) | (XSR_165 << 0)) | \
(TXP_165 << 8) | (TWTR_165 << 16))
--
1.6.0.4
I see issues after applying this patch (Overo/Beagle).
In about half of my boot attempts I get a hang after Uncompressing
Linux
In the other half I get many many errors of this type:
SLAB: cache with size 192 has lost its name
Reverting the patch restores normal operation.
What's about removing it from recent ARM pull request than and do some
further testing?
That sounds like a good plan to me.
Original patch was send on 6th Oct. sad that we will need to break
complete SDP3430 boot support.. How about fixing it properly once for
all-> looks like a previous commit hacked the timings meant for INFINEON
DDR with MICRON values for few of them causing this mess. attached is a
patchset to fix it.
Tested on SDP3430, buildtested for others - Steve do try it on your
platform to confirm. more testing invited..
--
Regards,
Nishanth Menon
>From 3b8f52c22ae81deab45c0a6ea18dda834daefc95 Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Mon, 19 Oct 2009 20:31:36 -0500
Subject: [PATCH 1/2] OMAP3:SDRC: Cleanup references to SDP
Remove SDP referenced unused defines
Signed-off-by: Nishanth Menon
---
cpu/arm_cortexa8/omap3/mem.c |2 +-
cpu/arm_cortexa8/omap3/sys_info.c |2 +-
include/asm-arm/arch-omap3/mem.h | 11 ++-
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 5e6d542..dfb7e4c 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -161,7 +161,7 @@ void do_sdrc_init(u32 cs, u32 early)
writel(0, &sdrc_base->sysconfig);
/* setup sdrc to ball mux */
- writel(SDP_SDRC_SHARING, &sdrc_base->sharing);
+ writel(SDRC_SHARING, &sdrc_base->sharing);
/* Disable Power Down of CKE cuz of 1 CKE on combo part */
writel(WAKEUPPROC | PWDNEN | SRFRONRESET | PAGEPOLICY_HIGH,
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c b/cpu/arm_cortexa8/omap3/sys_info.c
index 31b2003..08fb32e 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/a
[U-Boot] [PATCH 0/2] OMAP3:DDR timing cleanup series
Hi, in continuation of the discussion on: http://www.nabble.com/forum/Permalink.jtp?root=25779518&post=25959734&page=y the following patch set should introduce DDR timing changes for MICRON and INFINEON DDRs and allow both classes of boards to live happily together Tested ON: SDP3430 - type INFENINION BeagleBoard - type MICRON tested with mtest 0x8200 0x8300 1 from u-boot prompt Nishanth Menon (2): OMAP3:SDRC: Cleanup references to SDP OMAP3:SDRC: introduce DDR types cpu/arm_cortexa8/omap3/mem.c |2 +- cpu/arm_cortexa8/omap3/sys_info.c |2 +- include/asm-arm/arch-omap3/mem.h | 97 +++-- include/configs/devkit8000.h |3 + include/configs/omap3_beagle.h|3 + include/configs/omap3_evm.h |3 + include/configs/omap3_overo.h |3 + include/configs/omap3_pandora.h |3 + include/configs/omap3_sdp3430.h |3 + include/configs/omap3_zoom1.h |3 + include/configs/omap3_zoom2.h |3 + 11 files changed, 97 insertions(+), 28 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] OMAP3:SDRC: introduce DDR types
Micron DDR timings based on:
http://www.sakoman.net/cgi-bin/gitweb.cgi?p=x-load-omap3.git;a=blob;f=include/asm/arch-omap3/mem.h;h=e6fbfe3947f5d0d85fea776e30821d4017316d86;hb=HEAD
Introduce Micron DDR timings and provide
CONFIG_OMAP3_INFINEON_DDR and CONFIG_OMAP3_MICRON_DDR config
options to allow for platform files to setup their timings as
per the type of DDR selected
Reported-by: Steve Sakoman in
http://www.nabble.com/forum/Permalink.jtp?root=25779518&post=25959734&page=y
Signed-off-by: Nishanth Menon
---
include/asm-arm/arch-omap3/mem.h | 88 ++
include/configs/devkit8000.h |3 +
include/configs/omap3_beagle.h |3 +
include/configs/omap3_evm.h |3 +
include/configs/omap3_overo.h|3 +
include/configs/omap3_pandora.h |3 +
include/configs/omap3_sdp3430.h |3 +
include/configs/omap3_zoom1.h|3 +
include/configs/omap3_zoom2.h|3 +
9 files changed, 94 insertions(+), 18 deletions(-)
diff --git a/include/asm-arm/arch-omap3/mem.h b/include/asm-arm/arch-omap3/mem.h
index 3ef8478..ae06a14 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -68,26 +68,78 @@ enum {
* TCKE = 2
* XSR = 120/6 = 20
*/
-#define TDAL_165 6
-#define TDPL_165 3
-#define TRRD_165 2
-#define TRCD_165 3
-#define TRP_1653
-#define TRAS_165 7
-#define TRC_16510
-#define TRFC_165 12
-#define V_ACTIMA_165 ((TRFC_165 << 27) | (TRC_165 << 22) | \
- (TRAS_165 << 18) | (TRP_165 << 15) | \
- (TRCD_165 << 12) | (TRRD_165 << 9) | \
- (TDPL_165 << 6) | (TDAL_165))
-
-#define TWTR_165 1
-#define TCKE_165 2
-#define TXP_1652
-#define XSR_16520
-#define V_ACTIMB_165 (((TCKE_165 << 12) | (XSR_165 << 0)) | \
- (TXP_165 << 8) | (TWTR_165 << 16))
+#define INFINEON_TDAL_165 6
+#define INFINEON_TDPL_165 3
+#define INFINEON_TRRD_165 2
+#define INFINEON_TRCD_165 3
+#define INFINEON_TRP_165 3
+#define INFINEON_TRAS_165 7
+#define INFINEON_TRC_165 10
+#define INFINEON_TRFC_165 12
+#define INFINEON_V_ACTIMA_165 ((INFINEON_TRFC_165 << 27) |\
+ (INFINEON_TRC_165 << 22) | (INFINEON_TRAS_165 << 18) | \
+ (INFINEON_TRP_165 << 15) | (INFINEON_TRCD_165 << 12) | \
+ (INFINEON_TRRD_165 << 9) | (INFINEON_TDPL_165 << 6) | \
+ (INFINEON_TDAL_165))
+#define INFINEON_TWTR_165 1
+#define INFINEON_TCKE_165 2
+#define INFINEON_TXP_165 2
+#define INFINEON_XSR_165 20
+#define INFINEON_V_ACTIMB_165 ((INFINEON_TCKE_165 << 12) |\
+ (INFINEON_XSR_165 << 0) | (INFINEON_TXP_165 << 8) | \
+ (INFINEON_TWTR_165 << 16))
+
+/* Micron part of 3430 EVM (165MHz optimized) 6.06ns
+ * ACTIMA
+ * TDAL = Twr/Tck + Trp/tck= 15/6 + 18 /6 = 2.5 + 3 = 5.5 -> 6
+ * TDPL (Twr) = 15/6 = 2.5 -> 3
+ * TRRD= 12/6 = 2
+ * TRCD= 18/6 = 3
+ * TRP = 18/6 = 3
+ * TRAS= 42/6 = 7
+ * TRC = 60/6 = 10
+ * TRFC= 125/6 = 21
+ * ACTIMB
+ * TWTR= 1
+ * TCKE= 1
+ * TXSR= 138/6 = 23
+ * TXP = 25/6 = 4.1 ~5
+ */
+#define MICRON_TDAL_1656
+#define MICRON_TDPL_1653
+#define MICRON_TRRD_1652
+#define MICRON_TRCD_1653
+#define MICRON_TRP_165 3
+#define MICRON_TRAS_1657
+#define MICRON_TRC_165 10
+#define MICRON_TRFC_16521
+#define MICRON_V_ACTIMA_165 ((MICRON_TRFC_165 << 27) | \
+ (MICRON_TRC_165 << 22) | (MICRON_TRAS_165 << 18) | \
+ (MICRON_TRP_165 << 15) | (MICRON_TRCD_165 << 12) | \
+ (MICRON_TRRD_165 << 9) | (MICRON_TDPL_165 << 6) | \
+ (MICRON_TDAL_165))
+
+#define MICRON_TWTR_1651
+#define MICRON_TCKE_1651
+#define MICRON_XSR_165 23
+#define MICRON_TXP_165 5
+#define MICRON_V_ACTIMB_165 ((MICRON_TCKE_165 << 12) | \
+ (MICRON_XSR_165 << 0) | (MICRON_TXP_165 << 8) | \
+ (MICRON_TWTR_165 << 16))
+
+#ifdef CONFIG_OMAP3_INFINEON_DDR
+#define V_ACTIMA_165 INFINEON_V_ACTIMA_165
+#define V_ACTIMB_165 INFINEON_V_ACTIMB_165
+#endif
+#ifdef CONFIG_OMAP3_MICRON_DDR
+#define V_ACTIMA_165 MICRON_V_ACTIMA_165
+#define V_ACTIMB_165 MICRON_V_ACTIMB_165
+#endif
+
+#if !defined(V_ACTIMA_165) || !defined(V_ACTIMB_165)
+#error "Please c
[U-Boot] [PATCH 1/2] OMAP3:SDRC: Cleanup references to SDP
Remove SDP referenced unused defines
Signed-off-by: Nishanth Menon
---
cpu/arm_cortexa8/omap3/mem.c |2 +-
cpu/arm_cortexa8/omap3/sys_info.c |2 +-
include/asm-arm/arch-omap3/mem.h | 11 ++-
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 5e6d542..dfb7e4c 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -161,7 +161,7 @@ void do_sdrc_init(u32 cs, u32 early)
writel(0, &sdrc_base->sysconfig);
/* setup sdrc to ball mux */
- writel(SDP_SDRC_SHARING, &sdrc_base->sharing);
+ writel(SDRC_SHARING, &sdrc_base->sharing);
/* Disable Power Down of CKE cuz of 1 CKE on combo part */
writel(WAKEUPPROC | PWDNEN | SRFRONRESET | PAGEPOLICY_HIGH,
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index 31b2003..08fb32e 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -109,7 +109,7 @@ u32 get_cpu_rev(void)
/
u32 is_mem_sdr(void)
{
- if (readl(&sdrc_base->cs[CS0].mr) == SDP_SDRC_MR_0_SDR)
+ if (readl(&sdrc_base->cs[CS0].mr) == SDRC_MR_0_SDR)
return 1;
return 0;
}
diff --git a/include/asm-arm/arch-omap3/mem.h b/include/asm-arm/arch-omap3/mem.h
index 31cbdef..3ef8478 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -40,11 +40,8 @@ enum {
#define EARLY_INIT 1
/* Slower full frequency range default timings for x32 operation*/
-#define SDP_SDRC_SHARING 0x0100
-#define SDP_SDRC_MR_0_SDR 0x0031
-
-/* optimized timings good for current shipping parts */
-#define SDP_3430_SDRC_RFR_CTRL_165MHz 0x0004e201 /* 7.8us/6ns - 50=0x4e2 */
+#define SDRC_SHARING 0x0100
+#define SDRC_MR_0_SDR 0x0031
#define DLL_OFFSET 0
#define DLL_WRITEDDRCLKX2DIS 1
@@ -91,10 +88,6 @@ enum {
#define V_ACTIMB_165 (((TCKE_165 << 12) | (XSR_165 << 0)) | \
(TXP_165 << 8) | (TWTR_165 << 16))
-#define SDP_SDRC_ACTIM_CTRLA_0 V_ACTIMA_165
-#define SDP_SDRC_ACTIM_CTRLB_0 V_ACTIMB_165
-#define SDP_SDRC_RFR_CTRL SDP_3430_SDRC_RFR_CTRL_165MHz
-
/*
* GPMC settings -
* Definitions is as per the following format
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Requesting an update to ARM mach types
On Thu, Oct 22, 2009 at 4:42 PM, Paulraj, Sandeep wrote: > >> >> Paulraj, Sandeep wrote: >> > Tom, >> > >> > The ARM mach-types.h in /include/asm-arm needs to be updated with what >> is present at >> > >> > http://www.arm.linux.org.uk/developer/machines/ >> > >> > >> > Thanks, >> > Sandeep >> > ___ >> > U-Boot mailing list >> > U-Boot@lists.denx.de >> > http://lists.denx.de/mailman/listinfo/u-boot >> > >> > >> Can you point me to a kernel git commit? > No at this very moment. >> see http://marc.info/?t=12561738451&r=1&w=2 >> Can you verify that it has MACH_TYPE_OMAP_ZOOM3 ? > Yes. And it had OMAP 3630 >> I will be submitting this soon :) >> >> I will do this over the weekend >> Thanks, >> Tom >> > I'll look > Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] OMAP3 I2C Fix the sampling clock.
Tom said the following on 06/20/2009 01:22 PM:
> Menon, Nishanth wrote:
>
>>> -Original Message-
>>> From: Tom Rix [mailto:tom@windriver.com]
>>> Sent: Thursday, June 18, 2009 11:14 PM
>>> To: u-boot@lists.denx.de; Menon, Nishanth; dirk.be...@googlemail.com
>>> Cc: Tom Rix
>>> Subject: [PATCH 1/3] OMAP3 I2C Fix the sampling clock.
>>>
>>>
>> Acked-by: Nishanth Menon
>>
>> There is one comment below though..
>>
>>
>>> Signed-off-by: Tom Rix
>>> ---
>>> drivers/i2c/omap24xx_i2c.c | 34 +++-
>>> include/asm-arm/arch-omap3/i2c.h | 54
>>> +-
>>> 2 files changed, 74 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
>>> index 6784603..ecdf1f2 100644
>>> --- a/drivers/i2c/omap24xx_i2c.c
>>> +++ b/drivers/i2c/omap24xx_i2c.c
>>> @@ -31,7 +31,29 @@ static void flush_fifo(void);
>>>
>>> void i2c_init (int speed, int slaveadd)
>>> {
>>> - u16 scl;
>>> + int psc, scll, sclh;
>>> +
>>> + /* Only handle standard and fast speeds */
>>> + if ((speed != OMAP_I2C_STANDARD) &&
>>> + (speed != OMAP_I2C_FAST_MODE)) {
>>> + printf("Error : I2C unsupported speed %d\n", speed);
>>> + return;
>>> + }
>>> +
>>>
>>>
>> We may want to bring the HSI2C support back in though
>>
>>
>>
> How about I do this in a later patch?
> The configs I looked at only used the much slower standard speed.
>
Sounds good as long as it is in TODO somewhere.. kinda sad if we talk
400khz to TWL5030 which could go upto 2.4mhz or so..
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot and ARM SMP support
Sudeep K N said the following on 06/25/2009 12:11 PM: > Sorry, may be I confused you. > I indent to use only one core for u-boot. > I wanted to ask whether we need to update the cache > management to boot for ARM Cortex A9 SMP if we take > ARM Cortex A8 code as base. > I have tried and did not require any change on top of A8 code > to run u-boot on A9 SMP. > Is that right approach? > > you may want to see [1] how this was done for OMAP4 (which has a SMP cortex A9)-> we can discuss how to setup cortex_a9 in mainline u-boot. My thought would be: cpu/arm_cortexa9 - considering that a9 cores could be from 1 to 4 or so if my memory serves right -> btw, I wonder how SMP handling is done in u-boot today.. Regards, Nishanth Menon Ref: [1] http://git.omapzoom.org/?p=repo/u-boot.git;a=tree;h=refs/heads/omap4_dev;hb=refs/heads/omap4_dev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot and ARM SMP support
Shilimkar, Santosh said the following on 06/25/2009 04:51 PM: >> -Original Message- >> From: Pandita, Vikram >> Sent: Thursday, June 25, 2009 6:32 PM >> To: Jean-Christophe PLAGNIOL-VILLARD; Nishanth Menon; >> Shilimkar, Santosh >> Cc: Sudeep K N; u-boot@lists.denx.de; Tom >> Subject: RE: [U-Boot] Uboot and ARM SMP support >> >> Adding Santosh to loop who has pushed the OMAP4 SMP support >> into Kernel.org >> >> >> >>> -Original Message- >>> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] >>> Sent: Thursday, June 25, 2009 7:44 AM >>> To: Nishanth Menon >>> Cc: Sudeep K N; u-boot@lists.denx.de; Pandita, Vikram; Tom >>> Subject: Re: [U-Boot] Uboot and ARM SMP support >>> >>> On 12:47 Thu 25 Jun , Nishanth Menon wrote: >>> >>>> Sudeep K N said the following on 06/25/2009 12:11 PM: >>>> >>>>> Sorry, may be I confused you. >>>>> I indent to use only one core for u-boot. >>>>> I wanted to ask whether we need to update the cache >>>>> management to boot for ARM Cortex A9 SMP if we take >>>>> ARM Cortex A8 code as base. >>>>> I have tried and did not require any change on top of A8 code >>>>> to run u-boot on A9 SMP. >>>>> Is that right approach? >>>>> >>>>> >>>>> >>>> you may want to see [1] how this was done for OMAP4 (which >>>> >> has a SMP >> >>>> cortex A9)-> we can discuss how to setup cortex_a9 in >>>> >> mainline u-boot. >> >>>> My thought would be: cpu/arm_cortexa9 - considering that >>>> >> a9 cores could >> >>>> be from 1 to 4 or so if my memory serves right -> btw, I >>>> >> wonder how SMP >> >>>> handling is done in u-boot today.. >>>> >>> for arm I've only a theorical design as I've no SMP board for now >>> but I want to see SMP boot & AMP boot supported in Mainline >>> >>> > > The approach is perfect and that's what is most of the SMP systems are doing.. > If one look at the linux framework, U-boot need not know about the secondary > cores. > > As far as caches goes, the SCU is not enabled at u-boot level so there is no > coherency > between L1 caches.L2 is external and not enabled at u-boot level for time > being. > At the point when u-boot transfer control to kernel, the caches are flushed > in the > clean-up path so you need not do any explicit stuff. > > In case you want to enable L2 cache ( if preset ), then you need to add > support for > that in the u-boot. > > So essentially u-boot would be almost same as Cortex-A8 except you should > avoid programming AuxControl > register because the bit definitions are different. > > Hope this helps > so how would the new arch look like? do we do: cpu/arm_cortexa8_9 and common code there? Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot and ARM SMP support
Peter Pearse said the following on 06/25/2009 06:55 PM: > Those interested in SMP booting on ARM may be interested in > > http://www.linux-arm.org/LinuxBootLoader/SMPBoot > > > On ARM supplied development boards we rely on the pre-installed > > ARM Boot Monitor to provide the necessary setup to allow U-Boot to run > uni-core. > > > I am about to look at a patch for the ARM Fast Model A9 multicore > > in order to boot it without an ARM Boot Monitor. I'll cc this list > > once it is added to git://linux-arm.org/u-boot-armdev > > > Apologies for the disclaimer - our sys admins seemd to have decided to close > my open-source account... > > It might be exciting to look at boot and peripheral support planned: a) unicore Vs multicore support at u-boot level? b) single thread scheduling? c) interrrupt handling? d) peripheral and flash handling could be concurrent? e) anything else which could affect common systems? f) any kernel/"other OS" specific features? Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
Krishna, Mahith said the following on 06/29/2009 10:18 AM: > I am trying to boot OMAP3430SDP with MMC2 but cant get it to boot. I > think there is some problem with x-load or u-boot. Can someone help me out > and tell me what to do? > > Neither is supported for mmc2 - specifically x-loader - you may want to check that. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mmc2 on OMAP sdp3430
Krishna, Mahith said the following on 06/29/2009 10:18 AM: > I am trying to boot OMAP3430SDP with MMC2 but cant get it to boot. I > think there is some problem with x-load or u-boot. Can someone help me out > and tell me what to do? > > Neither is supported for mmc2 - specifically x-loader - you may want to check that. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mmc2 on OMAP sdp3430
Krishna, Mahith said the following on 06/29/2009 10:54 AM: > If neither is supported then how can I get the sdp to boot with mmc2 You can see mmc2 support patches in u-boot mailing list -> it could be available once those are merged in. x-loader I do not know. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
On Thu, Jul 9, 2009 at 6:03 PM, wrote: > Subject: [PATCH] Add support for the KwikByte KBOC OMAP35xx board Do you have some link that you can point us to what is KwikByte KBOC board? give us some explanation.. > > Signed-off-by: Christian Owens > --- > MAINTAINERS | 4 + > MAKEALL | 1 + > Makefile | 3 + > board/omap3/common/Makefile | 1 + > board/omap3/kboc/Makefile | 49 ++ > board/omap3/kboc/config.mk | 33 > board/omap3/kboc/kboc.c | 106 > board/omap3/kboc/kboc.h | 382 > ++ > include/configs/omap3_kboc.h | 317 +++ > 9 files changed, 896 insertions(+), 0 deletions(-) > create mode 100644 board/omap3/kboc/Makefile > create mode 100644 board/omap3/kboc/config.mk > create mode 100644 board/omap3/kboc/kboc.c > create mode 100644 board/omap3/kboc/kboc.h > create mode 100644 include/configs/omap3_kboc.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 0041112..cc55df9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -686,6 +686,10 @@ Alex Z > lart SA1100 > dnp1110 SA1110 > > +Christian Owens > + > + omap3_kboc ARM CORTEX-A8 (OMAP35xx SoC) > + > - > > Unknown / orphaned boards: > diff --git a/MAKEALL b/MAKEALL > index 41f1445..ac0c5d9 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -572,6 +572,7 @@ LIST_ARM_CORTEX_A8=" \ > omap3_pandora \ > omap3_zoom1 \ > omap3_zoom2 \ > + omap3_kboc \ > " > > # > diff --git a/Makefile b/Makefile > index 2a06440..b204917 100644 > --- a/Makefile > +++ b/Makefile > @@ -3040,6 +3040,9 @@ omap3_zoom1_config : unconfig > omap3_zoom2_config : unconfig > �...@$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 omap3 omap3 > > +omap3_kboc_config : unconfig > + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 kboc omap3 omap3 > + > # > ## XScale Systems > # > diff --git a/board/omap3/common/Makefile b/board/omap3/common/Makefile > index b8a0b14..4f7a20b 100644 > --- a/board/omap3/common/Makefile > +++ b/board/omap3/common/Makefile > @@ -34,6 +34,7 @@ COBJS-$(CONFIG_OMAP3_OVERO) += power.o > COBJS-$(CONFIG_OMAP3_PANDORA) += power.o > COBJS-$(CONFIG_OMAP3_ZOOM1) += power.o > COBJS-$(CONFIG_OMAP3_ZOOM2) += power.o > +COBJS-$(CONFIG_OMAP3_KBOC) += power.o > > COBJS := $(COBJS-y) > SRCS := $(COBJS:.o=.c) > diff --git a/board/omap3/kboc/Makefile b/board/omap3/kboc/Makefile > new file mode 100644 > index 000..2c77444 > --- /dev/null > +++ b/board/omap3/kboc/Makefile > @@ -0,0 +1,49 @@ > +# > +# (C) Copyright 2000, 2001, 2002 > +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. > +# > +# See file CREDITS for list of people who contributed to this > +# project. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation; either version 2 of > +# the License, or (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > +# > + > +include $(TOPDIR)/config.mk > + > +LIB = $(obj)lib$(BOARD).a > + > +COBJS := kboc.o > + > +SRCS := $(COBJS:.o=.c) > +OBJS := $(addprefix $(obj),$(COBJS)) > + > +$(LIB): $(obj).depend $(OBJS) > + $(AR) $(ARFLAGS) $@ $(OBJS) > + > +clean: > + rm -f $(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/omap3/kboc/config.mk b/board/omap3/kboc/config.mk > new file mode 100644 > index 000..879b2e2 > --- /dev/null > +++ b/board/omap3/kboc/config.mk > @@ -0,0 +1,33 @@ > +# > +# (C) Copyright 2006 > +# Texas Instruments, > +# > +# Beagle Board uses OMAP3 (ARM-CortexA8) cpu > +# see http://www.ti.com/ for more information on Texas Instruments is this board beagleboard? should this be here? mebbe you could take stat
Re: [U-Boot] [PATCH] Add support for the KwikByte KBOC OMAP35xx board
Jean-Christophe PLAGNIOL-VILLARD said the following on 07/12/2009 08:13 AM: >>> _sread*/\ >>> + MUX_VAL(CP(D2D_MBUSFLAG), (IEN | PTD | DIS | M0)) /*d2d_mbusflag*/\ >>> + MUX_VAL(CP(D2D_SBUSFLAG), (IEN | PTD | DIS | M0)) /*d2d_sbusflag*/\ >>> + MUX_VAL(CP(SDRC_CKE0),(IDIS | PTU | EN | M0)) >>> /*sdrc_cke0*/\ >>> + MUX_VAL(CP(SDRC_CKE1),(IDIS | PTU | EN | M0)) >>> /*sdrc_cke1*/ >>> >> one more reason why the mux needs a big change in mux handling :( I >> think we will end up with 1/2 a dozen crazy and code repetition for >> each board... Arrggghhh... >> > NM: yes, it's really not easy to follow here > do you plan to do it soon? > Been a little tied up recent days with "work load" hoping things to ease down.. will try to send out a mux cleanup rev next weekend.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP MUX handling improvement (was: Add support for the KwikByte KBOC OMAP35xx board)
Dirk Behme said the following on 07/12/2009 09:31 AM: > Nishanth Menon wrote: >> Jean-Christophe PLAGNIOL-VILLARD said the following on 07/12/2009 >> 08:13 AM: >>>>> _sread*/\ >>>>> + MUX_VAL(CP(D2D_MBUSFLAG), (IEN | PTD | DIS | M0)) >>>>> /*d2d_mbusflag*/\ >>>>> + MUX_VAL(CP(D2D_SBUSFLAG), (IEN | PTD | DIS | M0)) >>>>> /*d2d_sbusflag*/\ >>>>> + MUX_VAL(CP(SDRC_CKE0),(IDIS | PTU | EN | M0)) >>>>> /*sdrc_cke0*/\ >>>>> + MUX_VAL(CP(SDRC_CKE1),(IDIS | PTU | EN | M0)) >>>>> /*sdrc_cke1*/ >>>>> >>>> one more reason why the mux needs a big change in mux handling :( I >>>> think we will end up with 1/2 a dozen crazy and code repetition for >>>> each board... Arrggghhh... >>>> >>> NM: yes, it's really not easy to follow here >>> do you plan to do it soon? >>> >> Been a little tied up recent days with "work load" hoping things to ease >> down.. will try to send out a mux cleanup rev next weekend.. > > Btw, I like the way we do pin mux in U-Boot at the moment (*). Or > better: I can't imagine a way how to do it even better without > introducing other disadvantages. But I will enjoy to have a look to > your changes ;) Maybe you can give us already an idea of how you like > to change it? > > (*) What I like: > > Having everything in one file for each board. With this, you can get a > complete overview of board's pin mux with looking only in one file. > And you can see immediately for each pin what is configured and how. Here are few quick things i like and dont like about the mux handling Pros: * Simple interface - just a #define Cons: * Repetition for every single board for common stuff such as Sdrc dat regs etc.. * Boards tend to enable *every* mux even if u-boot uses or not. Proposal stage 1: * move common mux out to a mux.h, where board files can use the defaults if they like -> i recollect having send such a patch out some time back.. but I never got the time to follow up on it. Proposal stage 2: * kick out mux settings from each board, which does not belong there -> e.g. if the board does not do camera at u-boot level ->move that out to kernel. This is just my 2 cents.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot booting RTOS
rahan...@tataelxsi.co.in said the following on 04/07/2009 01:01 AM: > Hi, > > For the time being can I load RTOS using any elf loader through serial port. > Does U boot have any elf loader. > > How can I load a RTOS image(elf format) to memory through Serial cable from > uboot terminal? > Could you please try running the command "help" at uboot prompt and read through what it says? here is one way: you would need a elf to binary convertion then once you get a binary image use "loadb" command to download that image to sdram, then use the "go" command to give control to that image.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] OMAP3:NAND: rename SMNAND_ENV_OFFSET
SMNAND_ENV_OFFSET is more specific to Samsung NAND, rename it to NAND_ENV_OFFSET Signed-off-by: Nishanth Menon --- cpu/arm_cortexa8/omap3/mem.c|2 +- include/configs/omap3_beagle.h |4 ++-- include/configs/omap3_evm.h |2 +- include/configs/omap3_overo.h |4 ++-- include/configs/omap3_pandora.h |4 ++-- include/configs/omap3_zoom1.h |4 ++-- 6 files changed, 10 insertions(+), 10 deletions(-) diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c index 9c90f32..ac126fd 100644 --- a/cpu/arm_cortexa8/omap3/mem.c +++ b/cpu/arm_cortexa8/omap3/mem.c @@ -248,7 +248,7 @@ void gpmc_init(void) size = PISMO1_NAND_SIZE; enable_gpmc_config(gpmc_config, nand_cs_base, base, size); #if defined(CONFIG_ENV_IS_IN_NAND) - f_off = SMNAND_ENV_OFFSET; + f_off = NAND_ENV_OFFSET; f_sec = SZ_128K; /* env setup */ boot_flash_base = base; diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 3f47b7a..30b2cfd 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -276,11 +276,11 @@ #define CONFIG_ENV_IS_IN_NAND 1 #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */ -#define SMNAND_ENV_OFFSET 0x26 /* environment starts here */ +#define NAND_ENV_OFFSET0x26 /* environment starts here */ #define CONFIG_SYS_ENV_SECT_SIZE boot_flash_sec #define CONFIG_ENV_OFFSET boot_flash_off -#define CONFIG_ENV_ADDRSMNAND_ENV_OFFSET +#define CONFIG_ENV_ADDRNAND_ENV_OFFSET /*--- * CFI FLASH driver setup diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 8cd8a1b..c33d981 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -268,7 +268,7 @@ #define CONFIG_ENV_IS_IN_ONENAND 1 #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */ -#define SMNAND_ENV_OFFSET 0x26 /* environment starts here */ +#define NAND_ENV_OFFSET0x26 /* environment starts here */ #define CONFIG_SYS_ENV_SECT_SIZE boot_flash_sec #define CONFIG_ENV_OFFSET boot_flash_off diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index 093f922..259b864 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -263,11 +263,11 @@ #define CONFIG_ENV_IS_IN_NAND 1 #define ONENAND_ENV_OFFSET 0x24 /* environment starts here */ -#define SMNAND_ENV_OFFSET 0x24 /* environment starts here */ +#define NAND_ENV_OFFSET0x24 /* environment starts here */ #define CONFIG_SYS_ENV_SECT_SIZE boot_flash_sec #define CONFIG_ENV_OFFSET boot_flash_off -#define CONFIG_ENV_ADDRSMNAND_ENV_OFFSET +#define CONFIG_ENV_ADDRNAND_ENV_OFFSET /*--- * CFI FLASH driver setup diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h index 7c3d2f0..7deecb7 100644 --- a/include/configs/omap3_pandora.h +++ b/include/configs/omap3_pandora.h @@ -265,11 +265,11 @@ #define CONFIG_ENV_IS_IN_NAND 1 #define ONENAND_ENV_OFFSET 0x24 /* environment starts here */ -#define SMNAND_ENV_OFFSET 0x24 /* environment starts here */ +#define NAND_ENV_OFFSET0x24 /* environment starts here */ #define CONFIG_SYS_ENV_SECT_SIZE boot_flash_sec #define CONFIG_ENV_OFFSET boot_flash_off -#define CONFIG_ENV_ADDRSMNAND_ENV_OFFSET +#define CONFIG_ENV_ADDRNAND_ENV_OFFSET /*--- * CFI FLASH driver setup diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h index 794ad96..34e6868 100644 --- a/include/configs/omap3_zoom1.h +++ b/include/configs/omap3_zoom1.h @@ -273,11 +273,11 @@ #define CONFIG_ENV_IS_IN_NAND 1 #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */ -#define SMNAND_ENV_OFFSET 0x26 /* environment starts here */ +#define NAND_ENV_OFFSET0x26 /* environment starts here */ #define CONFIG_SYS_ENV_SECT_SIZE boot_flash_sec #define CONFIG_ENV_OFFSET boot_flash_off -#define CONFIG_ENV_ADDRSMNAND_ENV_OFFSET +#define CONFIG_ENV_ADDRNAND_ENV_OFFSET /*--- * CFI FLASH driver setup -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http
[U-Boot] [PATCH 0/3] OMAP3:NAND: Cleanup patchset
Hi, The following patch series provides cleanup for making OMAP3 NAND support more generic. This consists of: a) OMAP3:NAND: Change the NAND timing assignment b) OMAP3:NAND: Change the NAND CS handling c) OMAP3:NAND: rename SMNAND_ENV_OFFSET Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] OMAP3:NAND: Change the NAND CS handling
NAND CS is assumed to be CS0 while we could have
choice b/w 0 to 7. This patch enables board files
to handle varied CS on a need basis.
Signed-off-by: Nishanth Menon
---
cpu/arm_cortexa8/omap3/mem.c |8 +---
include/asm-arm/arch-omap3/mem.h |8
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 14cd87d..9c90f32 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -54,12 +54,6 @@ static u32 gpmc_m_nand[GPMC_MAX_REG] = {
gpmc_csx_t *nand_cs_base;
gpmc_t *gpmc_cfg_base;
-#if defined(CONFIG_ENV_IS_IN_NAND)
-#define GPMC_CS 0
-#else
-#define GPMC_CS 1
-#endif
-
#endif
#if defined(CONFIG_CMD_ONENAND)
@@ -249,7 +243,7 @@ void gpmc_init(void)
gpmc_config = gpmc_m_nand;
gpmc_cfg_base = gpmc_base;
nand_cs_base = (gpmc_csx_t *)(GPMC_CONFIG_CS0_BASE +
- (GPMC_CS * GPMC_CONFIG_WIDTH));
+ (NAND_GPMC_CS * GPMC_CONFIG_WIDTH));
base = PISMO1_NAND_BASE;
size = PISMO1_NAND_SIZE;
enable_gpmc_config(gpmc_config, nand_cs_base, base, size);
diff --git a/include/asm-arm/arch-omap3/mem.h b/include/asm-arm/arch-omap3/mem.h
index 622578e..1c4abe7 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -216,6 +216,14 @@ typedef enum {
/* max number of GPMC regs */
#define GPMC_MAX_REG 7
+#if defined(CONFIG_ENV_IS_IN_NAND)
+#define NAND_GPMC_CS 0
+#else
+#ifndef NAND_GPMC_CS
+#define NAND_GPMC_CS 1
+#endif /* NAND_GPMC_CS */
+#endif /* CONFIG_ENV_IS_IN_NAND */
+
#define PISMO1_NOR 1
#define PISMO1_NAND2
#define PISMO2_CS0 3
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] OMAP3:NAND: Change the NAND timing assignment
NAND timing is defaulted to Micron NAND. To support
varied boards, this is not scalable.
This patch introduces compile time option to select
the timing to select at the same time allows
platforms to build with custom timing params
Signed-off-by: Nishanth Menon
---
cpu/arm_cortexa8/omap3/mem.c | 12 ++--
include/asm-arm/arch-omap3/mem.h | 38 +++---
include/configs/omap3_beagle.h |1 +
include/configs/omap3_overo.h|1 +
include/configs/omap3_pandora.h |1 +
include/configs/omap3_zoom1.h|1 +
6 files changed, 33 insertions(+), 21 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 3cc22c4..14cd87d 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -43,12 +43,12 @@ volatile unsigned int boot_flash_env_addr;
#if defined(CONFIG_CMD_NAND)
static u32 gpmc_m_nand[GPMC_MAX_REG] = {
- M_NAND_GPMC_CONFIG1,
- M_NAND_GPMC_CONFIG2,
- M_NAND_GPMC_CONFIG3,
- M_NAND_GPMC_CONFIG4,
- M_NAND_GPMC_CONFIG5,
- M_NAND_GPMC_CONFIG6, 0
+ NAND_GPMC_CONFIG1,
+ NAND_GPMC_CONFIG2,
+ NAND_GPMC_CONFIG3,
+ NAND_GPMC_CONFIG4,
+ NAND_GPMC_CONFIG5,
+ NAND_GPMC_CONFIG6, 0
};
gpmc_csx_t *nand_cs_base;
diff --git a/include/asm-arm/arch-omap3/mem.h b/include/asm-arm/arch-omap3/mem.h
index 6f0f90b..622578e 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -137,21 +137,29 @@ typedef enum {
#define GPMC_SIZE_32M 0xE
#define GPMC_SIZE_16M 0xF
-#define SMNAND_GPMC_CONFIG10x0800
-#define SMNAND_GPMC_CONFIG20x00141400
-#define SMNAND_GPMC_CONFIG30x00141400
-#define SMNAND_GPMC_CONFIG40x0F010F01
-#define SMNAND_GPMC_CONFIG50x010C1414
-#define SMNAND_GPMC_CONFIG60x1F0F0A80
-#define SMNAND_GPMC_CONFIG70x0C44
-
-#define M_NAND_GPMC_CONFIG10x1800
-#define M_NAND_GPMC_CONFIG20x00141400
-#define M_NAND_GPMC_CONFIG30x00141400
-#define M_NAND_GPMC_CONFIG40x0F010F01
-#define M_NAND_GPMC_CONFIG50x010C1414
-#define M_NAND_GPMC_CONFIG60x1f0f0A80
-#define M_NAND_GPMC_CONFIG70x0C44
+/*
+ * Standard OMAP3 NAND device definitions
+ * Define SMNAND_GPMC or M_NAND_GPMC to use the defaults
+ * if your board has a specific timing (such as optimized timing),
+ * define NAND_GPMC_CONFIG1 to 7
+ */
+#ifdef SMNAND_GPMC
+#define NAND_GPMC_CONFIG1 0x0800
+#define NAND_GPMC_CONFIG2 0x00141400
+#define NAND_GPMC_CONFIG3 0x00141400
+#define NAND_GPMC_CONFIG4 0x0F010F01
+#define NAND_GPMC_CONFIG5 0x010C1414
+#define NAND_GPMC_CONFIG6 0x1F0F0A80
+#define NAND_GPMC_CONFIG7 0x0C44
+#elif defined(M_NAND_GPMC)
+#define NAND_GPMC_CONFIG1 0x1800
+#define NAND_GPMC_CONFIG2 0x00141400
+#define NAND_GPMC_CONFIG3 0x00141400
+#define NAND_GPMC_CONFIG4 0x0F010F01
+#define NAND_GPMC_CONFIG5 0x010C1414
+#define NAND_GPMC_CONFIG6 0x1f0f0A80
+#define NAND_GPMC_CONFIG7 0x0C44
+#endif
#define STNOR_GPMC_CONFIG1 0x3
#define STNOR_GPMC_CONFIG2 0x00151501
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 5a948e4..3f47b7a 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -126,6 +126,7 @@
* Board NAND Info.
*/
#define CONFIG_NAND_OMAP_GPMC
+#define M_NAND_GPMC
#define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */
/* to access nand */
#define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 51b04b6..093f922 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -113,6 +113,7 @@
* Board NAND Info.
*/
#define CONFIG_NAND_OMAP_GPMC
+#define M_NAND_GPMC
#define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */
/* to access nand */
#define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */
diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h
index 40107a6..7c3d2f0 100644
--- a/include/configs/omap3_pandora.h
+++ b/include/configs/omap3_pandora.h
@@ -116,6 +116,7 @@
* Board NAND Info.
*/
#define CONFIG_NAND_OMAP_GPMC
+#define M_NAND_GPMC
#define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */
/* to access nand */
#define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */
diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h
index 8e984b4..794ad96 100644
--- a/include/configs/omap3_zoom1.h
+++ b/include/configs/omap3_zoom1.h
@@ -123,6 +123,7 @@
* Board NAND Info.
*/
#define CONFIG_NAND_OMAP_GPMC
+#define M_NAND_GPMC
#define CONFIG_SYS_NAND_ADDR
Re: [U-Boot] Unable to debug UBOOT
Vivek DALAL said the following on 05/08/2009 01:12 AM: > I am newbie in bootloader. > I am trying to port latest uboot on omap2430(poseidon board). Currently > support for omap2430 is not present in uboot; so I made changes accordingly. > > would be nice to see your patches when you are ready :).. it might even pave way to get sdp2430 support in place.. > I am putting it in RAM using Trace 32 debugger. But unable to get prompt. > Code hangs but giving message *"DRAM: 64MB" ...* > Please suggest me different ways of debugging uboot. > I tried using Trace 32(LAUTERBACH JTAG debugger). Loaded uboot elf > file(u-boot) into RAM. I am getting symbols and function names. But unable > to put breakpoints. Also C code is not visible even after changing mode. > > Please suggest me ways to debug uboot I would recommend you start with reading Lauterbach user manual(hitting F1 key when trace32 runs will help). IMHO, Lauterbach will be the best tool to go ahead and use esp for OMAP2-3 processors. When you read the user manual, pay close attention to 'd.load.elf ... /strippart /lowerpath' option also s.path.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] omap3: clean up gpmc config strut
Matthias Ludwig said the following on 05/11/2009 01:09 PM: > following patchset cleans up gpmc config for omap3. > > - which tree is the baseline for these? i think arm/next has few changes also which is yet to be merged to mainline.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ZOOM1 Add power reset button
looping in beagleboard for comments.
Tom said the following on 06/13/2009 09:16 AM:
> Tom wrote:
>
>> Menon, Nishanth wrote:
>>
-Original Message-
From: Tom [mailto:tom@windriver.com]
Sent: Friday, June 12, 2009 4:57 PM
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: u-boot@lists.denx.de; Menon, Nishanth
Subject: Re: [U-Boot] [PATCH 4/4] ZOOM1 Add power reset button
>> */
>> void twl4030_power_reset_init(void)
>> {
>> -#ifdef CONFIG_OMAP3_ZOOM2
>> +#if defined(CONFIG_OMAP3_ZOOM2) || defined(CONFIG_OMAP3_ZOOM1)
>>
>>
> I think it will be better to avoid board specifc code in the driver
> unless it's the only solution
>
>
>
I think this is zoom1 and zoom2 specific.
I could add this function to each of their board files.
I was trying to avoid that.
>> + if (twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, &val,
>> + TWL4030_PM_MASTER_P1_SW_EVENTS)) {
>> + printf("Error:TWL4030: failed to read the power register\n");
>> + printf("Could not initialize hardware reset\n");
>> + } else {
>> + val |= TWL4030_PM_MASTER_SW_EVENTS_STOPON_PWRON;
>> + if (twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, val,
>> + TWL4030_PM_MASTER_P1_SW_EVENTS)) {
>>
>>> Why is this zoom1 and zoom2 specific? You are playing with PM Master
>>> registers causing a board reset right? It should in theory work for
>>> beagleboard also.. am I wrong?
>>>
>> Half right I think.
>> The beagle, from the schematics, has a 'Reset' - 'S2' switch. This is
>> tied to them omap's sys_nRespwon and to the t2_nRespwon. I think when
>> the switch is pressed only the omap gets reset. I could try verifing
>> this but it would take a while. Looking at
>> theTWL4030_PM_MASTER_P1_SW_EVENTS using 'i2c md 4b 46' it is clear in
>> both the factory and the current versions of u-boot.
>>
>> I think that setting this bit in beagle will reset just the twl4030.
>> Which I think is the right thing to do.
>>
>> I will try removing the #if-defs and see what happens :|
>>
>
> I have taken a closer look.
> I think the 'Cold Reset' label for switch 2 should be relabeled 'Warm
> Reset'
> twl4030 registers are persistent on beagle and zoom1 when both the sw
> reset cmd is given and when the beagle reset or the zoom1 reset (pin
> hole in back + handy paperclip) is used. The easiest way to test this is
> to set the sw_events manually using
> inm 4b 46
> then set to
> 40
> Verify with imd 4b 46.
>
> When the hw reset button is used on the zoom1, front face red button,
> the board resets and this is clear. On beagle you need to cycle power by
> unplugging / replugging power. Otherwise it does not get reset.
>
> Looking at beagle schematics, the ic SN74LVC2G07 has nRESPWRON as an
> input. So the resetting of the omap is an or-ing of nRESPWRON and the
> switch. The switch has no effect on nRESPWRON. If the input & output of
> ic were reversed, you _may_ get the behaviour of resetting omap with a
> touch and resetting omap+twl4030 when held for 8+ seconds.
>
> The moral of the story is do not depend on twl4030 to be reset.
>
> For this patch for resetting, the reset logic is generic and should be
> in the driver layer and not in the board layer.
>
> Tom
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM:OMAP3:Zoom1: Add nand unlock option
>From d391faf8ca68fcddc8569b03cf24d151d4d3b937 Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Mon, 2 Feb 2009 18:20:12 -0600 Subject: [PATCH] ARM:OMAP3:Zoom1: Add nand unlock option Enable NAND_UNLOCK option for unlocking nand for erase/write operations Signed-off-by: Nishanth Menon --- include/configs/omap3_zoom1.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h index 54d2416..f8ae163 100644 --- a/include/configs/omap3_zoom1.h +++ b/include/configs/omap3_zoom1.h @@ -103,6 +103,7 @@ #define CONFIG_CMD_I2C /* I2C serial bus support */ #define CONFIG_CMD_MMC /* MMC support */ #define CONFIG_CMD_NAND/* NAND support */ +#define CONFIG_CMD_NAND_LOCK_UNLOCK /* Enable lock/unlock support */ #undef CONFIG_CMD_FLASH/* flinfo, erase, protect */ #undef CONFIG_CMD_FPGA /* FPGA configuration Support */ -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] lcd
Anusha, Anusha Bhat said the following on 02/06/2009 11:44 PM: > How to add LCD SUPPORT (CONFIG_LCD) to opma3evm bootcode(u-boot).if i add > CONFIG_LCD in the omap3evm.h it gives error. > Because the display variables and funtions are not defined for omap. > I wanted to display a bmp logo on u-boot up > yep, it is probably not supported in omap3 port in latest u-boot at the moment. for OMAP3 DSS configuration code, look at [1] - you need to port this code from the old u-boot to the latest u-boot. This is a community development, so, we welcome any new features folks can provide.. Regards, Nishanth Menon Ref: [1] http://beagleboard.googlecode.com/files/u-boot-beagle-rev2-trial2.tar.gz.gz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
md ks said the following on 02/19/2009 03:30 PM: > Hi, > I am omap-3530, u-boot 1.3 version , while switching from u-boot > level to kernel level , i am getting flicker on LCD(display)., How to > remove that flicker. What platform is this? did you mention u-boot 1.3? the current u-boots are numbered 2009-01 etc.. Where is the source code from? Further, could you see if u-boot from the mainline [1] resolves the issue? Regards, Nishanth Menon Ref: [1] http://git.denx.de/?p=u-boot.git;a=summary ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] flow of u-boot
ABIRAMA SUNDARI said the following on 02/19/2009 03:56 PM: > thanks for your answer. but i am getting you properly.pls tell me the > things in detail.(what you meant by _start ). > Step 1) Download u-boot code (you can download using git - try google.com to get more help on git) by git clone git://git.denx.de/u-boot.git Step 2) try 'grep -Rw _start .' (help of grep is available in 'man grep') Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PATCH Beagleboard add OTG host support
Connie, yanfeng qin said the following on 02/19/2009 06:58 PM: > This patch is added OTG host support for beagleboard. My team modifiedand > tested this patch.We hope it would help. > > Thanks. What is the baseline for the patch? could you send us the link of the git? Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7 v2] OMAP3: Add OMAP3 core changes for MUSB
Grazvydas Ignotas said the following on 02/23/2009 02:13 PM: >>>> +#ifdef CONFIG_MUSB >>>> +/* Enable the MUSB interface clock */ >>>> +sr32(&prcm_base->iclken1_core, 4, 1, 0x1); >>>> +#endif >>>> >>> the design of u-boot is to enagle the IP only when he use it >>> so please do not enable the clock every time just when you want to use >>> (in the USB driver init) >>> >> This is already answered in >> >> http://lists.denx.de/pipermail/u-boot/2009-February/047452.html >> > > He probably wants to say that clocks should be enabled only when "usb > start" is issued, as you might have u-boot compiled with USB defines > set, but never actually use USB. > Comparing having all clock initialization at a central point (clock.c) - which seems simple vs having get-put kind of clock apis in U-boot : I might go for the simple solution of all clocks in a single place.. u-boot is supposed to "keep it simple", enable/disable clocks on a need basis is elegant, though could end up getting extended to i2c and other peripherals too(if I were to stretch is pretty hard ;) ).. makes more sense in kernel(which is already there) than here - my 2 cents.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Clock handling (wasRe: [PATCH 6/7 v2] OMAP3: Add OMAP3 core changes for MUSB)
Wolfgang Denk said the following on 02/23/2009 11:36 PM: > >> Comparing having all clock initialization at a central point (clock.c) - >> which seems simple vs having get-put kind of clock apis in U-boot : I >> > > But the explicit rule is only to enable interfaces (and this includes > clocks) when they are actually being used. Enabling all clocks even if > not needed may for example add significantly to the power consumption > and to EMC problems. > I agree power consumption in u-boot is higher due to lack of power management support -> but just having clocks is just one factor of it.. if power management is our concern, we probably need a unified strategy for it. But inherently is'nt it an overkill at u-boot level (normal boot time is less than few seconds).. if we look at clock handling -> there are multiple levels of clock handling: a) enable all required clocks at a go -> current omap3 code does that b) proposed change -> clock enable/disable on need basis. c) clock tree architecture -> OMAP3 as an example has a complex clock tree, cascading clock dependencies etc. as an example: sys_clk OR clk32 could be functional clock source of gptimer module. to access gptimer you need interface clock -> but once you program it, unless you need to access the regs, you can essentially shut the interface clock off.. till lets say interrupt occurs.. we could even think of cascading clock divisors here.. just to make things a little more complex.. How about voltage handling etc.. are we thinking of a complete power architecture here? what kind of gains do we expect by having just (b)? My feel is that it would make things a lot more complex than the need is.. For the modules one needs (they are not too many at u-boot level), enable the clocks at one place. if we go to (b) we might as well go to (c).. mebbe even pull in clocksource like u-boot-v2 has, while we are it.. But in anycase, do we have a generic clock architecture(clock register, unregister, get, put apis) we are to adhere to? or are we holding off each patch and rejecting unless they call thier own omap3_musb_clk_get, omap3_musb_clk_put? that does not sound to be a good idea :(.. maybe I am missing the conversation here.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Changes for single binary image for u-boot for NAND/OneNAND flash.
> @@ -243,12 +243,20 @@ extern ulong load_addr; /* Default Load Address
> */
> void doc_probe(unsigned long physadr);
>
> /* common/cmd_nvedit.c */
> +#if defined(CONFIG_ENV_IS_RUNTIME_SEL)
> +typedef uchar (*env_get_char_spec_p)(int index);
> +typedef int (*env_init_p)(void);
> +typedef int (*saveenv_p)(void);
> +typedef void (*env_relocate_spec_p)(void);
> +#else
> int env_init (void);
> +int saveenv(void);
> +#endif
> void env_relocate (void);
> int envmatch (uchar *, int);
> char *getenv (char *);
> int getenv_r (char *name, char *buf, unsigned len);
> -int saveenv (void);
> +
> #ifdef CONFIG_PPC/* ARM version to be fixed! */
> int inline setenv (char *, char *);
> #else
> diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> index f4498a9..bf5614e 100644
> --- a/include/configs/omap3_evm.h
> +++ b/include/configs/omap3_evm.h
> @@ -107,6 +107,7 @@
> #define CONFIG_CMD_I2C /* I2C serial bus support */
> #define CONFIG_CMD_MMC /* MMC support */
> #define CONFIG_CMD_ONENAND /* ONENAND support */
> +#define CONFIG_CMD_NAND /* NAND support */
>
please move this to some other patch.. not relevant here..
> #define CONFIG_CMD_DHCP
> #define CONFIG_CMD_PING
>
> @@ -125,12 +126,15 @@
> /*
> * Board NAND Info.
> */
> +#define CONFIG_NAND_OMAP_GPMC
> #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */
> /* to access nand */
> #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */
> /* to access */
> /* nand at CS0 */
>
> +#define GPMC_NAND_ECC_LP_x16_LAYOUT 1
> +
> #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of */
> /* NAND devices */
> #define SECTORSIZE 512
> @@ -271,7 +275,7 @@
> #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE
> #define CONFIG_SYS_ONENAND_BASE ONENAND_MAP
>
> -#define CONFIG_ENV_IS_IN_ONENAND 1
> +#define CONFIG_ENV_IS_RUNTIME_SEL1
> #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */
> #define SMNAND_ENV_OFFSET0x26 /* environment starts here */
>
> diff --git a/lib_arm/board.c b/lib_arm/board.c
> index 09eaaf2..9a0c285 100644
> --- a/lib_arm/board.c
> +++ b/lib_arm/board.c
> @@ -60,6 +60,11 @@ DECLARE_GLOBAL_DATA_PTR;
>
> ulong monitor_flash_len;
>
> +#if defined(CONFIG_ENV_IS_RUNTIME_SEL)
> +extern void gpmc_init(void);
> +extern void print_board_info(void);
> +#endif
> +
> #ifdef CONFIG_HAS_DATAFLASH
> extern int AT91F_DataflashInit(void);
> extern void dataflash_print_info(void);
> @@ -259,12 +264,17 @@ static int arm_pci_init(void)
> typedef int (init_fnc_t) (void);
>
> int print_cpuinfo (void); /* test-only */
> +extern env_init_p env_init;
>
> init_fnc_t *init_sequence[] = {
> cpu_init, /* basic cpu dependent setup */
> board_init, /* basic board dependent setup */
> interrupt_init, /* set up exceptions */
> +#if defined(CONFIG_ENV_IS_RUNTIME_SEL)
> + NULL, /* initialize environment */
> +#else
> env_init, /* initialize environment */
> +#endif
> init_baudrate, /* initialze baudrate settings */
> serial_init,/* serial communications setup */
> console_init_f, /* stage 1 init of console */
> @@ -350,13 +360,14 @@ void start_armboot (void)
> /* armboot_start is defined in the board-specific linker script */
> mem_malloc_init (_armboot_start - CONFIG_SYS_MALLOC_LEN);
>
> -#if defined(CONFIG_CMD_NAND)
> - puts ("NAND: ");
> - nand_init();/* go init the NAND */
> -#endif
> -
> -#if defined(CONFIG_CMD_ONENAND)
> - onenand_init();
>
well.. my nand and onenand init dissapeared... :( not the way to di it I
guess..
> +#if defined(CONFIG_ENV_IS_RUNTIME_SEL)
> + gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
>
Waaah.. gpmc is TI OMAP2 or OMAP3 only NOT in other ARM or PPC
or other platforms.. NAK on this.
> + env_init();
> + init_baudrate();/* initialze baudrate settings */
> + serial_init(); /* serial communications setup */
> + console_init_f(); /* stage 1 init of console */
> + display_banner();
> + print_board_info();
> #endif
>
> #ifdef CONFIG_HAS_DATAFLASH
>
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Fix for running examples on OMAP3 EVM board
Manikandan Pillai said the following on 03/03/2009 05:40 AM: > Example binaries to be downloaded to 0x8030 for OMAP3 EVMs. > > Signed-off-by: Manikandan Pillai > --- > examples/Makefile |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/examples/Makefile b/examples/Makefile > index dbcfa92..75e6c87 100644 > --- a/examples/Makefile > +++ b/examples/Makefile > @@ -36,10 +36,14 @@ else > ifeq ($(CPU),omap3) > LOAD_ADDR = 0x8030 > else > +ifeq ($(CPU),arm_cortexa8) > +LOAD_ADDR = 0x8030 > +else > I am bit confused here.. first we say $(CPU) omap3...EVM is based on omap3 rt? the second change is not valid -> cortex_a8 -> we might have future platforms which have cortex. they need not use the same memory map as OMAP does. this is not valid change. NAK from me. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Fix for running examples on OMAP3 EVM board
Pillai, Manikandan said the following on 03/04/2009 06:57 AM: > Hi all, > please dont top post. > For the EVM board, > > $BOARD = evm $CPU = arm_cortexa8 and $ARCH = arm. > $VENDOR = omap3 and $SOC = omap3 > > I can change the check to check BOARD so that it is applicable only > To OMAP3 EVMs. > > ifeq ($(BOARD),evm) > LOAD_ADDR = 0x8030 > else > what is so special about evm? ;) if we have an exception from the current boards supported, lets go ahead and do it.. mebbe the right fix would be replace $CPU, omap3 with $SOC,omap3? Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Changes for single binary image for u-boot for NAND/OneNAND flash.
Pillai, Manikandan said the following on 03/04/2009 08:35 AM:
>>> #if defined(CONFIG_ENV_IS_IN_NAND) /* Environment is in Nand
>>>
>> Flash */ \
>>
>>> - || defined(CONFIG_ENV_IS_IN_SPI_FLASH)
>>> + || defined(CONFIG_ENV_IS_IN_SPI_FLASH) \
>>> + || (defined(CONFIG_CMD_NAND) && defined(CONFIG_ENV_IS_RUNTIME_SEL))
>>>
>>>
>> Errr ENV_IS_IN_NAND Vs ENV_IS_RUNTIME_SEL is not clear.
>>
> [Pillai, Manikandan] I am not clear with the query
>
>
CONFIG_ENV_IS_RUNTIME_SEL is dependent only on CMD_NAND? if I had onenand and
NOR, then what?
>>> +void print_board_info(void)
>>> +{
>>> + u32 btype;
>>> +
>>> + btype = get_board_type();
>>> +
>>> + display_board_info(btype);
>>> +}
>>> +
>>>
>>>
>> I dont think this is related to this...
>>
> [Pillai, Manikandan] The default EVM support does not have NAND. To build only
> For NAND, you need to enable this. I can put this in a separate patch in a
> series.
>
>
my comment -> move this as a seperate patch.. this patch seems to mix up
things doing different things and confusing for a review.
>>> -#if defined(CONFIG_CMD_ONENAND)
>>> +#if defined(CONFIG_CMD_NAND) && defined(CONFIG_ENV_IS_RUNTIME_SEL)
>>> + gpmc_config = gpmc_m_nand;
>>> + nand_cs_base = (gpmc_csx_t *)(GPMC_CONFIG_CS0_BASE +
>>> + (gpmc_index * GPMC_CONFIG_WIDTH));
>>> + base = PISMO1_NAND_BASE;
>>> + size = PISMO1_NAND_SIZE;
>>> + enable_gpmc_config(gpmc_config, nand_cs_base, base, size);
>>> + /* NAND and/or ONENAND is to be scanned */
>>> + is_nand = 0;
>>> + nand_init();
>>> + if (nand_info[0].size) {
>>> + is_nand = 1;
>>> + f_off = SMNAND_ENV_OFFSET;
>>> + f_sec = SZ_128K;
>>> + /* env setup */
>>> + boot_flash_base = base;
>>> + boot_flash_off = f_off;
>>> + boot_flash_sec = f_sec;
>>> + boot_flash_env_addr = f_off;
>>> +
>>> + env_name_spec = nand_env_name_spec;
>>> + env_ptr = nand_env_ptr;
>>> + env_get_char_spec = nand_env_get_char_spec;
>>> + env_init = nand_env_init;
>>> + saveenv = nand_saveenv;
>>> + env_relocate_spec = nand_env_relocate_spec;
>>> + gpmc_index++;
>>> + }
>>>
>>>
>> with a change like above in a common omap3 file, you are essentially
>> bottlenecking scalability to other OMAP3 platforms which use different
>> NAND. Eg. we assume SZ_128K ;) kinda wrong rt? sector size is dependent
>> on the nand device we plug in..
>>
> [Pillai, Manikandan] I can plug out the initialization stuff and put it in
> a board dependent file and invoke the same from the common omap3 locations
> for the type of board.
>
>
that might be a nice idea.. will look for your changes.. :)
>>> printf("OMAP%s-%s rev %d, CPU-OPP2 L3-165MHz\n", cpu_s,
>>> - sec_s, get_cpu_rev());
>>> - printf("%s + %s/%s\n", sysinfo.board_string,
>>> - mem_s, sysinfo.nand_string);
>>> + sec_s, get_cpu_rev());
>>> +#if defined(CONFIG_ENV_IS_RUNTIME_SEL)
>>> + printf("%s + %s/", sysinfo.board_string,
>>> + mem_s);
>>> +#if defined(CONFIG_CMD_NAND)
>>> + if (is_nand)
>>> + printf("%s\n", "NAND");
>>> +#endif
>>> +#if defined(CONFIG_CMD_ONENAND)
>>> + if (is_onenand)
>>> + printf("%s\n", "ONENAND");
>>> +#endif
>>> +#else
>>> + printf("%s + %s/%s\n", sysinfo.board_string,
>>> + mem_s, sysinfo.nand_string);
>>> +#endif
>>>
>>>
>> I have this feel that we could improve this #ifdef mess.. using
>> variables maybe?
>>
> [Pillai, Manikandan] other suggestions welcome Personally, I felt
> here the #ifdef is not so dirty.
>
;) not after a time of adding multiple #ifdefs :D... as I said, how
about using variables to do it?
>>> +#if defined(CONFIG_ENV_IS_RUNTIME_SEL)
>>> + gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
>>>
>>>
>> Waaah.. gpmc is TI OMAP2 or OMAP3 only NOT in other ARM or PPC
>> or other platforms.. NAK on this.
>>
> [Pillai, Manikandan] Got your point. But I don't have a solution to this
> Since I EVM is doing a scan, it requires the gpmc_init to be called late.
> An option is to have another function board_init_late() which can be used to
> called gpmc_init_late().
>
that could be an option.. but please keep other platforms in mind when
we send this patch.
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Vector set up in u-boot for OMAP3530.
Rahanesh said the following on 03/04/2009 01:23 PM: > I am trying to set up vector table for a my custom RTOS. > > ARM provides 0x: and 0x: as the Vector base address. > > I planned to use 0x: for my development. > > I have decided to hard-code the opcode for the corresponding branches to > the loactions respectively.(0x to 0x001C) > > When i write to 0x location , i get a prefetch abort exception. Why > am i not able to write to 0x? > Some basics on interrupt vector handling on cortex_a8: CP15 coprocessor forallows: * legacy high and low interrupt vectors * also allows you to program interrupt vector of your choosing. please read the ARM architecture Manual and the ARM technical reference manual for further information. if you look at the OMAP3 TRM, you will find 0x0 belonging to GPMC address space, unless you mapped something there, ARM will not find an vector to execute. > > How did U boot handle this? How did U boot set up Vector table? > in OMAP3, we have rom code which setups a trampoline vector in SRAM. this is piggybacked to handle the interrupts. the omap3 code probably does not use interrupts extensively at this stage, but yeah, that is one way to do it.. but you would need ROM Code executing prior to your code to get this. one way to go about this is to enable MMU and map 0x0 to which ever address space you want (if you want to use the "old style" of doing arm interrupts.. > > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments contained in it. > > Please... we have this long aversion to this form of copyright information tailer.. please do not claim that it is always present for mails from you company.. if so, use a different mail id such as gmail etc.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Fix for running examples on OMAP3 EVM board
Manikandan Pillai said the following on 03/05/2009 07:55 AM: > Example binaries to be downloaded to 0x8030 for OMAP3 EVMs. > > Signed-off-by: Manikandan Pillai > --- > examples/Makefile |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/examples/Makefile b/examples/Makefile > index dbcfa92..d2e811a 100644 > --- a/examples/Makefile > +++ b/examples/Makefile > @@ -33,7 +33,7 @@ ifeq ($(ARCH),arm) > ifeq ($(BOARD),omap2420h4) > LOAD_ADDR = 0x8030 > else > -ifeq ($(CPU),omap3) > +ifeq ($(SOC),omap3) > LOAD_ADDR = 0x8030 > else > LOAD_ADDR = 0xc10 > Acked-by: Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DeAsserting UART Interrupt line on OMAP3530 for uboot
Rahanesh said the following on 03/05/2009 04:21 PM: > Can anyone help me to de-assert the uart interrupt line. > Please read the OMAP3530 TRM. it explains how to handle the UART registers. > I have enabled the UART interrupt only for reception of data. > > Processor get the interrupt and data is read to a local buffer. Since the > Interrupt line is not deasserted , i keep on getting the same interrupt. > > How can i deassert the UART interrupt in OMAP 3530? Is it in the UART side > or Interrupt Controller Side? > > How does Ubot handle this? How is the Interrupt line cleared in Uboot? > > I would recommend doing the following: git clone git://git.denx.de/u-boot.git vim drivers/serial/ns16550.c You'd see that it is not using interrupts, it does a poll on interrupt status register.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH]OMAP3:Beagle: Enable mtdparts
http://www.denx.de/wiki/DULG/UBootCmdGroupFlash#UBootCmdFlMtdparts provides a flexible way to create and maintain u-boot mtd partitions. This allows commands such as "nand erase fs" to work and the user no longer needs to decode the absolute nand offsets. This patch enables this function for beagleboard Signed-off-by: Nishanth Menon --- include/configs/omap3_beagle.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 9057606..c64999f 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -98,6 +98,11 @@ #define CONFIG_CMD_EXT2/* EXT2 Support */ #define CONFIG_CMD_FAT /* FAT support */ #define CONFIG_CMD_JFFS2 /* JFFS2 Support*/ +#define CONFIG_JFFS2_CMDLINE /* Enable MTD parts commands */ +#define MTDIDS_DEFAULT "nand0=nand" +#define MTDPARTS_DEFAULT "mtdparts=nand:512k(x-loader),"\ + "1920k(u-boot),128k(u-boot-env),"\ + "4m(kernel),-(fs)" #define CONFIG_CMD_I2C /* I2C serial bus support */ #define CONFIG_CMD_MMC /* MMC support */ -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Display Sub SYstem Controller Initialization
Rahanesh, Wolfgang Denk said the following on 03/09/2009 01:57 PM: > Dear Rahanesh, > > In message you > wrote: > >> As per your advice i have used Xloader and then i loaded MY RTOS image . >> My RTOS works fine. Thanks. >> >> I Need your advice on Display Subsystem Controller available on OMAP3530. >> After sucessfully porting RTOS , now i am trying to use the LCD available on >> the board. >> This is my requirement: >> > > Questions about "your RTOS" are off topic on this mailing list. > Please stop posting these here. > > Could you take the generic OMAP3530 related questions to [1] mailing list? Regards, Nishanth Menon Ref: [1] http://groups.google.com/group/beagleboard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
