[U-Boot] [PATCH v9 0/5] usb: add Faraday EHCI & Gadget support
From: Kuo-Jung Su This patch adds support to both Faraday FUSBH200 and FOTG210, the differences between Faraday EHCI and standard EHCI are listed bellow: 1. The PORTSC starts at 0x30 instead of 0x44. 2. The CONFIGFLAG(0x40) is not only un-implemented, and also has its address removed. 3. Faraday EHCI is a TDI design, but it doesn't compatible with the general TDI implementation found at both U-Boot and Linux. 4. The ISOC descriptors differs from standard EHCI in several ways. But since U-boot doesn't support ISOC, we don't have to worry about that. The Faraday FOTG210 is an OTG chip which could operate as either an EHCI Host or a USB Device at a time. Changes for v9: - ehci-hcd: prevent bad PORTSC register access in ehci_submit_root() - ehci-hcd: drop the quick fix to 'port=-1' from ehci_get_portsc_register(). - ehci-faraday: drop the quick fix to 'port=-1' Changes for v8: - ehci-faraday: ehci_get_portsc_register(): Bug fixed, only port=0 is accepted. Changes for v7: - Rebase to u-boot-bbd0f7e3ba66d288a2f146f1c7797801e04598ae, and also make sure it's compatible to u-boot-usb-dc69e46302a36e60e2417bba8c6ea78761a37ebf. - Update TDI aliased functions, since there is another similar patch had been committed and acceptted. - ehci-hcd: ehci_get_portsc_register(): make sure port is always >= 0 Changes for v6: - usb_hub: Simplify CONFIG_USB_HUB_MIN_POWER_ON_DELAY default value setup. - ehci-hcd: Simplify weak aliased function declaration - ehci-hcd: Drop redundant line feed Changes for v5: - Split up EHCI changeset - usb_hub: replace the Faraday EHCI ifdef for the long delay in usb_hub_configure() with the new configuration option: USB_HUB_MIN_POWER_ON_DELAY, which is used in usb_hub_power_on() to control the minimum usb hub power-on delay. - ehci-faraday: fix the invalid multi-line comment style. - gadget-fotg210: coding style cleanup. - gadget-fotg210: drop postfix '__iomem' from struct fotg210_regs - gadget-fotg210: use permanent delay for hardware reset - gadget-fotg210: drop '#ifndef CONFIG_SYS_DCACHE_OFF' - gadget-fotg210: drop magic numbers Changes for v4: - Use only macro constants and named bit/mask - Use weak-aliased functions for tdi implementation and also portsc registers to avoid poluting ehci.h with ifdefs Changes for v3: - Coding Style cleanup. - Drop bit fields from c struct. - Drop macros for wirtel()/readl(), call them directly. - Always insert a blank line between declarations and code. - Replace all the infinite wait loop with a timeout. - Add '__iomem' to all the declaration of HW register pointers. Changes for v2: - Coding Style cleanup. - Use readl(), writel(), clrsetbits_le32() to replace REG() macros. - Use structure based hardware registers to replace the macro constants. - Replace BIT() with BIT_MASK(). - echi-faraday: Remove debug codes. Kuo-Jung Su (5): usb: ehci: prevent bad PORTSC register access usb: ehci: add weak-aliased function for PORTSC usb: hub: make minimum power-on delay configurable usb: ehci: add Faraday USB 2.0 EHCI support usb: gadget: add Faraday FOTG210 USB gadget support README|3 + common/usb_hub.c | 15 +- drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/fotg210.c | 948 + drivers/usb/gadget/gadget_chips.h |8 + drivers/usb/host/Makefile |1 + drivers/usb/host/ehci-faraday.c | 148 ++ drivers/usb/host/ehci-hcd.c | 34 +- include/usb/fotg210.h | 364 ++ include/usb/fusbh200.h| 61 +++ 10 files changed, 1575 insertions(+), 8 deletions(-) create mode 100644 drivers/usb/gadget/fotg210.c create mode 100644 drivers/usb/host/ehci-faraday.c create mode 100644 include/usb/fotg210.h create mode 100644 include/usb/fusbh200.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v9 1/5] usb: ehci: prevent bad PORTSC register access
From: Kuo-Jung Su
1. The 'index' of ehci_submit_root() is not always > 0.
e.g.
While it gets invoked from usb_get_descriptor(),
the 'index' is always a '0'. (See ch.9 of USB2.0)
2. The PORTSC register is not always required, and thus it
should only report a port error when necessary.
It would cause a port scan failure if the ehci_submit_root()
always gets terminated by a port error.
Signed-off-by: Kuo-Jung Su
CC: Marek Vasut
---
Changes for v9:
- 1st edition
drivers/usb/host/ehci-hcd.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index e0f3e4b..6022049 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -616,11 +616,6 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
int port = le16_to_cpu(req->index) & 0xff;
struct ehci_ctrl *ctrl = dev->controller;
- if (port > CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) {
- printf("The request port(%d) is not configured\n", port - 1);
- return -1;
- }
- status_reg = (uint32_t *)&ctrl->hcor->or_portsc[port - 1];
srclen = 0;
debug("req=%u (%#x), type=%u (%#x), value=%u, index=%u\n",
@@ -631,6 +626,21 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
typeReq = req->request | req->requesttype << 8;
switch (typeReq) {
+ case USB_REQ_GET_STATUS | ((USB_RT_PORT | USB_DIR_IN) << 8):
+ case USB_REQ_SET_FEATURE | ((USB_DIR_OUT | USB_RT_PORT) << 8):
+ case USB_REQ_CLEAR_FEATURE | ((USB_DIR_OUT | USB_RT_PORT) << 8):
+ if (!port || port > CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) {
+ printf("The request port(%d) is not configured\n", port
- 1);
+ return -1;
+ }
+ status_reg = (uint32_t *)&ctrl->hcor->or_portsc[port - 1];
+ break;
+ default:
+ status_reg = NULL;
+ break;
+ }
+
+ switch (typeReq) {
case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
switch (le16_to_cpu(req->value) >> 8) {
case USB_DT_DEVICE:
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v9 2/5] usb: ehci: add weak-aliased function for PORTSC
From: Kuo-Jung Su
There is at least one non-EHCI compliant controller (i.e. Faraday EHCI)
not only leave RESERVED and CONFIGFLAG registers un-implemented
but also has their address spaces removed.
As an result, the PORTSC register of Faraday EHCI always
starts from 0x30 instead of 0x44 in standard EHCI.
So that we'll need a weak-aliased function for abstraction.
Signed-off-by: Kuo-Jung Su
CC: Marek Vasut
---
Changes for v9:
- Drop the quick fix to 'port=-1' from ehci_get_portsc_register().
Changes for v8:
- Nothing updates
Changes for v7:
- Rebase to u-boot-bbd0f7e3ba66d288a2f146f1c7797801e04598ae
- Drop TDI weak-aliased functions, since there is another similar
patch had been committed and acceptted.
- ehci_get_portsc_register(): make sure port is always >= 0
Changes for v6:
- Simplify weak aliased function declaration
- Drop redundant line feed
Changes for v5:
- Split up from Faraday EHCI patch
Changes for v2 - v4:
- See 'usb: ehci: add Faraday USB 2.0 EHCI support'
drivers/usb/host/ehci-hcd.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 6022049..cfb2097 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -603,6 +603,17 @@ fail:
return -1;
}
+__weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port)
+{
+ if (port < 0 || port >= CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) {
+ /* Printing the message would cause a scan failure! */
+ debug("The request port(%u) is not configured\n", port);
+ return NULL;
+ }
+
+ return (uint32_t *)&hcor->or_portsc[port];
+}
+
int
ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer,
int length, struct devrequest *req)
@@ -629,11 +640,9 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
case USB_REQ_GET_STATUS | ((USB_RT_PORT | USB_DIR_IN) << 8):
case USB_REQ_SET_FEATURE | ((USB_DIR_OUT | USB_RT_PORT) << 8):
case USB_REQ_CLEAR_FEATURE | ((USB_DIR_OUT | USB_RT_PORT) << 8):
- if (!port || port > CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) {
- printf("The request port(%d) is not configured\n", port
- 1);
+ status_reg = ehci_get_portsc_register(ctrl->hcor, port - 1);
+ if (!status_reg)
return -1;
- }
- status_reg = (uint32_t *)&ctrl->hcor->or_portsc[port - 1];
break;
default:
status_reg = NULL;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v9 4/5] usb: ehci: add Faraday USB 2.0 EHCI support
From: Kuo-Jung Su
This patch adds support to both Faraday FUSBH200 and FOTG210,
the differences between Faraday EHCI and standard EHCI are
listed bellow:
1. The PORTSC starts at 0x30 instead of 0x44.
2. The CONFIGFLAG(0x40) is not only un-implemented, and
also has its address space removed.
3. Faraday EHCI is a TDI design, but it doesn't
compatible with the general TDI implementation
found at both U-Boot and Linux.
4. The ISOC descriptors differ from standard EHCI in
several ways. But since U-boot doesn't support ISOC,
we don't have to worry about that.
Signed-off-by: Kuo-Jung Su
CC: Marek Vasut
---
Changes for v9:
- Drop the quick fix to 'port=-1' from ehci_get_portsc_register().
Changes for v8:
- ehci-faraday: ehci_get_portsc_register():
Bug fixed, only port=0 is accepted.
Changes for v7:
- Nothing updates
Changes for v6:
- Nothing updates
Changes for v5:
- Break down EHCI changes as seperate changesets.
- Fix the invalid multi-line comment style.
Changes for v4:
- Use only macro constants and named bit/mask
- Use weak-aliased functions for tdi implementation and
also portsc registers to avoid poluting ehci.h with ifdefs
Changes for v3:
- Coding Style cleanup.
- Drop bit fields from c struct.
- Drop macros for wirtel()/readl(), call them directly.
- Always insert a blank line between declarations and code.
- Replace all the infinite wait loop with a timeout.
- Add '__iomem' to all the declaration of HW register pointers.
Changes for v2:
- Coding Style cleanup.
- Use readl(), writel(), clrsetbits_le32() to replace REG() macros.
- Use structure based hardware registers to replace the macro constants.
- Replace BIT() with BIT_MASK().
- echi-faraday: Remove debug codes.
common/usb_hub.c|7 +-
drivers/usb/host/Makefile |1 +
drivers/usb/host/ehci-faraday.c | 148
drivers/usb/host/ehci-hcd.c |5 +
include/usb/fotg210.h | 364 +++
include/usb/fusbh200.h | 61 +++
6 files changed, 585 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/host/ehci-faraday.c
create mode 100644 include/usb/fotg210.h
create mode 100644 include/usb/fusbh200.h
diff --git a/common/usb_hub.c b/common/usb_hub.c
index fc3a8c1..774ba63 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -489,7 +489,11 @@ static int usb_hub_configure(struct usb_device *dev)
i + 1, portstatus);
usb_clear_port_feature(dev, i + 1,
USB_PORT_FEAT_C_ENABLE);
-
+ /*
+* The following hack causes a ghost device problem
+* to Faraday EHCI
+*/
+#ifndef CONFIG_USB_EHCI_FARADAY
/* EM interference sometimes causes bad shielded USB
* devices to be shutdown by the hub, this hack enables
* them again. Works at least with mouse driver */
@@ -501,6 +505,7 @@ static int usb_hub_configure(struct usb_device *dev)
"re-enabling...\n", i + 1);
usb_hub_port_connect_change(dev, i);
}
+#endif
}
if (portstatus & USB_PORT_STAT_SUSPEND) {
debug("port %d suspend change\n", i + 1);
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 87a5970..98f2a10 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -43,6 +43,7 @@ COBJS-$(CONFIG_USB_EHCI_FSL) += ehci-mpc512x.o
else
COBJS-$(CONFIG_USB_EHCI_FSL) += ehci-fsl.o
endif
+COBJS-$(CONFIG_USB_EHCI_FARADAY) += ehci-faraday.o
COBJS-$(CONFIG_USB_EHCI_EXYNOS) += ehci-exynos.o
COBJS-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
COBJS-$(CONFIG_USB_EHCI_MXS) += ehci-mxs.o
diff --git a/drivers/usb/host/ehci-faraday.c b/drivers/usb/host/ehci-faraday.c
new file mode 100644
index 000..86add36
--- /dev/null
+++ b/drivers/usb/host/ehci-faraday.c
@@ -0,0 +1,148 @@
+/*
+ * Faraday USB 2.0 EHCI Controller
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ehci.h"
+
+#ifndef CONFIG_USB_EHCI_BASE_LIST
+#define CONFIG_USB_EHCI_BASE_LIST { CONFIG_USB_EHCI_BASE }
+#endif
+
+union ehci_faraday_regs {
+ struct fusbh200_regs usb;
+ struct fotg210_regs otg;
+};
+
+static inline int ehci_is_fotg2xx(union ehci_faraday_regs *regs)
+{
+ return !readl(®s->usb.easstr);
+}
+
+/*
+ * Create the appropriate control structures to manage
+ * a new EHCI host controller.
+ */
+int ehci_hcd_init(int index, struct ehci_hccr **ret_hccr,
+
[U-Boot] [PATCH v9 3/5] usb: hub: make minimum power-on delay configurable
From: Kuo-Jung Su
This patch makes the minimum power-on delay for USB HUB
become configurable. The original design waits at least
100 msec here, but some EHCI controlers(e.g. Faraday EHCI)
are known to require much longer delay interval.
Signed-off-by: Kuo-Jung Su
CC: Marek Vasut
---
Changes for v9:
- Nothing updates
Changes for v8:
- Nothing updates
Changes for v7:
- Rebase to u-boot-bbd0f7e3ba66d288a2f146f1c7797801e04598ae
Changes for v6:
- Simplify CONFIG_USB_HUB_MIN_POWER_ON_DELAY default value setup.
Changes for v5:
- Split up from Faraday EHCI patch
- Replace the Faraday EHCI ifdef for the long delay
in usb_hub_configure() with the new configuration option:
USB_HUB_MIN_POWER_ON_DELAY, which is used in usb_hub_power_on()
to control the minimum usb hub power-on delay.
Changes for v2 - v4:
- See 'usb: ehci: add Faraday USB 2.0 EHCI support'
README |3 +++
common/usb_hub.c |8 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/README b/README
index defdedb..5bf4791 100644
--- a/README
+++ b/README
@@ -1245,6 +1245,9 @@ The following options need to be configured:
CONFIG_USB_EHCI_TXFIFO_THRESH enables setting of the
txfilltuning field in the EHCI controller on reset.
+ CONFIG_USB_HUB_MIN_POWER_ON_DELAY defines the minimum
+ interval for usb hub power-on delay.(minimum 100msec)
+
- USB Device:
Define the below if you wish to use the USB console.
Once firmware is rebuilt from a serial console issue the
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 0d79ec3..fc3a8c1 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -53,6 +53,10 @@
#include
#endif
+#ifndef CONFIG_USB_HUB_MIN_POWER_ON_DELAY
+#define CONFIG_USB_HUB_MIN_POWER_ON_DELAY 100
+#endif
+
#define USB_BUFSIZ 512
static struct usb_hub_device hub_dev[USB_MAX_HUB];
@@ -148,8 +152,8 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
debug("port %d returns %lX\n", i + 1, dev->status);
}
- /* Wait at least 100 msec for power to become stable */
- mdelay(max(pgood_delay, (unsigned)100));
+ /* Wait for power to become stable */
+ mdelay(max(pgood_delay, CONFIG_USB_HUB_MIN_POWER_ON_DELAY));
}
void usb_hub_reset(void)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v9 5/5] usb: gadget: add Faraday FOTG210 USB gadget support
From: Kuo-Jung Su
The Faraday FOTG210 is an OTG chip which could operate
as either an EHCI Host or a USB Device at a time.
Signed-off-by: Kuo-Jung Su
CC: Marek Vasut
---
Changes for v9:
- Nothing updates
Changes for v8:
- Nothing updates
Changes for v7:
- Nothing updates
Changes for v6:
- Nothing updates
Changes for v5:
- Coding Style cleanup.
- Drop postfix '__iomem' from struct fotg210_regs
- Use permanent delay for hardware reset
- Drop '#ifndef CONFIG_SYS_DCACHE_OFF'
- Drop magic numbers
Changes for v4:
- Use only macro constants and named bit/mask
- Remove dcache_enable() from usb_gadget_register_driver()
Changes for v3:
- Coding Style cleanup.
- Drop bit fields from c struct.
- Drop macros for wirtel()/readl(), call them directly.
- Always insert a blank line between declarations and code.
- Replace all the infinite wait loop with a timeout.
- Add '__iomem' to all the declaration of HW register pointers.
Changes for v2:
- Coding Style cleanup.
- Use readl(), writel(), clrsetbits_le32() to replace REG() macros.
- Use structure based hardware registers to replace the macro constants.
- Replace BIT() with BIT_MASK().
- echi-faraday: Remove debug codes.
drivers/usb/gadget/Makefile |1 +
drivers/usb/gadget/fotg210.c | 948 +
drivers/usb/gadget/gadget_chips.h |8 +
3 files changed, 957 insertions(+)
create mode 100644 drivers/usb/gadget/fotg210.c
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index e545b6b..432cf17 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -35,6 +35,7 @@ endif
# new USB gadget layer dependencies
ifdef CONFIG_USB_GADGET
COBJS-$(CONFIG_USB_GADGET_S3C_UDC_OTG) += s3c_udc_otg.o
+COBJS-$(CONFIG_USB_GADGET_FOTG210) += fotg210.o
COBJS-$(CONFIG_USBDOWNLOAD_GADGET) += g_dnl.o
COBJS-$(CONFIG_DFU_FUNCTION) += f_dfu.o
endif
diff --git a/drivers/usb/gadget/fotg210.c b/drivers/usb/gadget/fotg210.c
new file mode 100644
index 000..d003331
--- /dev/null
+++ b/drivers/usb/gadget/fotg210.c
@@ -0,0 +1,948 @@
+/*
+ * Faraday USB 2.0 OTG Controller
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define CFG_NUM_ENDPOINTS 4
+#define CFG_EP0_MAX_PACKET_SIZE64
+#define CFG_EPX_MAX_PACKET_SIZE512
+
+#define CFG_CMD_TIMEOUT (CONFIG_SYS_HZ >> 2) /* 250 ms */
+
+struct fotg210_chip;
+
+struct fotg210_ep {
+ struct usb_ep ep;
+
+ uint maxpacket;
+ uint id;
+ uint stopped;
+
+ struct list_head queue;
+ struct fotg210_chip *chip;
+ const struct usb_endpoint_descriptor *desc;
+};
+
+struct fotg210_request {
+ struct usb_request req;
+ struct list_head queue;
+ struct fotg210_ep *ep;
+};
+
+struct fotg210_chip {
+ struct usb_gadget gadget;
+ struct usb_gadget_driver *driver;
+ struct fotg210_regs *regs;
+ uint8_t irq;
+ uint16_t addr;
+ int pullup;
+ enum usb_device_state state;
+ struct fotg210_ep ep[1 + CFG_NUM_ENDPOINTS];
+};
+
+static struct usb_endpoint_descriptor ep0_desc = {
+ .bLength = sizeof(struct usb_endpoint_descriptor),
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bEndpointAddress = USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_CONTROL,
+};
+
+static inline int fifo_to_ep(struct fotg210_chip *chip, int id, int in)
+{
+ return (id < 0) ? 0 : ((id & 0x03) + 1);
+}
+
+static inline int ep_to_fifo(struct fotg210_chip *chip, int id)
+{
+ return (id <= 0) ? -1 : ((id - 1) & 0x03);
+}
+
+static inline int ep_reset(struct fotg210_chip *chip, uint8_t ep_addr)
+{
+ int ep = ep_addr & USB_ENDPOINT_NUMBER_MASK;
+ struct fotg210_regs *regs = chip->regs;
+
+ if (ep_addr & USB_DIR_IN) {
+ /* reset endpoint */
+ setbits_le32(®s->iep[ep - 1], IEP_RESET);
+ mdelay(1);
+ clrbits_le32(®s->iep[ep - 1], IEP_RESET);
+ /* clear endpoint stall */
+ clrbits_le32(®s->iep[ep - 1], IEP_STALL);
+ } else {
+ /* reset endpoint */
+ setbits_le32(®s->oep[ep - 1], OEP_RESET);
+ mdelay(1);
+ clrbits_le32(®s->oep[ep - 1], OEP_RESET);
+ /* clear endpoint stall */
+ clrbits_le32(®s->oep[ep - 1], OEP_STALL);
+ }
+
+ return 0;
+}
+
+static int fotg210_reset(struct fotg210_chip *chip)
+{
+ struct fotg210_regs *regs = chip->regs;
+ uint32_t i;
+
+
Re: [U-Boot] [PATCH v2 4/4] arm: factorize relocate_code routine
Hi Benoît, (I had indeed missed remarks in your reply; apologies for this) On Tue, 14 May 2013 18:01:50 +0200 (CEST), Benoît Thébaudeau wrote: > Hi Albert, > > +/* > > + * These are defined in the board-specific linker script. > > + * Subtracting _start from them lets the linker put their > > + * relative position in the executable instead of leaving > > + * them null. > > + */ > > This comment is obsolete. It should either be removed or updated. Correct. > > + > > +/* > > + * void relocate_code(addr_moni) > > + * > > + * This function relocates the monitor code. > > + */ > > +ENTRY(relocate_code) > > + mov r6, r0 /* save addr of destination */ > > + > > + ldr r0, =_start > > If you are avoiding the "ldr =" construct below, why do you use it > here? You could "ldr r0, _TEXT_BASE". _start is defined in a compilation unit, not in the linker file. References to _start such as the one above are therefore correct before as well as after relocation. > > + subsr9, r6, r0 /* r9 <- relocation offset */ > > + beq relocate_done /* skip relocation */ > > + mov r1, r6 /* r1 <- scratch for copy loop */ > > + ldr r3, _image_copy_end_ofs > > + add r2, r0, r3 /* r2 <- source end address */ > > Adding _start to a relocate_code-relative _image_copy_end_ofs?! You're correct. For some reason I did not complete the rewrite here. :( I'd made the offsets relative to relocate_code in order to avoid the linker issues with subtracting symbols not defined in the current compilation unit. Then I should add =relocate_code to r3, not =_start, and also -- as r9 is not the right offset here -- compute r7 as the delta between the link-time =_start and the run-time relocate_code (r7 becomes useless once R10, r2 and r3 are fixed). I'd run-tested tested each commit but apparently this bug did not cause any immediately visible issue. This time I'll step-test it. > > + /* > > +* fix .rel.dyn relocations > > +*/ > > + ldr r10, _dynsym_start_ofs /* r10 <- sym table ofs */ > > + add r10, r10, r9/* r10 <- sym table in FLASH */ > > + ldr r2, _rel_dyn_start_ofs /* r2 <- rel dyn start ofs */ > > + add r2, r2, r9 /* r2 <- rel dyn start in FLASH */ > > + ldr r3, _rel_dyn_end_ofs/* r3 <- rel dyn end ofs */ > > + add r3, r3, r9 /* r3 <- rel dyn end in FLASH */ > > This is mixing relocate_code-relative offsets with the relocation offset! Correct, that's where r7 kicks in to replace r9. Again, apologies for missing this. > Best regards, > Benoît Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] arm: optimize relocate_code routine
Hi Benoît,
On Wed, 15 May 2013 01:54:11 +0200 (CEST), Benoît Thébaudeau
wrote:
> Hi Albert,
>
> On Tuesday, May 14, 2013 10:03:00 PM, Albert ARIBAUD wrote:
> > Use section symbols directly
> > Drop support for R_ARM_ABS32 record types
> > Eliminate unneeded intermediate registers
> > Optimize relocation table iteration
> >
> > Signed-off-by: Albert ARIBAUD
> > ---
> > arch/arm/lib/relocate.S | 45
> > +++--
> > 1 file changed, 15 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> > index 818735c..75ee3b4 100644
> > --- a/arch/arm/lib/relocate.S
> > +++ b/arch/arm/lib/relocate.S
> > @@ -37,51 +37,36 @@
> > * This function relocates the monitor code.
> > */
> > ENTRY(relocate_code)
> > - mov r6, r0 /* save addr of destination */
> >
> > - ldr r0, =__image_copy_start /* r0 <- source start address */
> > - subsr9, r6, r0 /* r9 <- relocation offset */
> > + ldr r1, =__image_copy_start /* r1 <- source start address */
> > + subsr9, r0, r1 /* r9 <- relocation offset */
> > beq relocate_done /* skip relocation */
> > - mov r1, r6 /* r1 <- scratch for copy loop */
> > ldr r2, =__image_copy_end /* r2 <- source end address */
> >
> > copy_loop:
> > - ldmia r0!, {r10-r11} /* copy from source address [r0]*/
> > - stmia r1!, {r10-r11} /* copy to target address [r1]*/
> > - cmp r0, r2 /* until source end address [r2]*/
> > + ldmia r1!, {r10-r11} /* copy from source address [r1]*/
> > + stmia r0!, {r10-r11} /* copy to target address [r0]*/
> > + cmp r1, r2 /* until source end address [r2]*/
> > blo copy_loop
> >
> > /*
> > * fix .rel.dyn relocations
> > */
> > - ldr r10, =__dynsym_start/* r10 <- sym table ofs */
> > ldr r2, =__rel_dyn_start/* r2 <- rel dyn start ofs */
> > ldr r3, =__rel_dyn_end /* r3 <- rel dyn end ofs */
> > fixloop:
> > - ldr r0, [r2]/* r0 <- SRC location to fix up */
> > - add r0, r0, r9 /* r0 <- DST location to fix up */
> > - ldr r1, [r2, #4]
> > - and r7, r1, #0xff
> > - cmp r7, #23 /* relative fixup? */
> > - beq fixrel
> > - cmp r7, #2 /* absolute fixup? */
> > - beq fixabs
> > - /* ignore unknown type of fixup */
> > - b fixnext
> > -fixabs:
> > - /* absolute fix: set location to (offset) symbol value */
> > - mov r1, r1, LSR #4 /* r1 <- symbol index in .dynsym */
> > - add r1, r10, r1 /* r1 <- address of symbol in table */
> > - ldr r1, [r1, #4]/* r1 <- symbol value */
> > - add r1, r1, r9 /* r1 <- relocated sym addr */
> > - b fixnext
> > -fixrel:
> > + ldmia r2!, {r0-r1}/* (r0,r1) <- (SRC location,fixup) */
> > + and r1, r1, #0xff /* r1 <- fixup type */
> > + cmp r1, #23 /* relative fixup? */
> > + bne fixnext
> > +
> > /* relative fix: increase location by offset */
> > - ldr r1, [r0]
> > - add r1, r1, r9
> > + add r0, r0, r9 /* r0 <- DST location to fix up */
> > + ldr r1, [r0]/* r1 <- content to fix up */
> > + add r1, r1, r9 /* fix up */
> > + str r1, [r0]/* write back fixed-up content */
> > +
> > fixnext:
> > - str r1, [r0]
> > - add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
> > cmp r2, r3
> > blo fixloop
>
> The final state of relocate.S is correct in this series, but it is not correct
> at the end of "[PATCH v2 4/4] arm: factorize relocate_code routine" as I
> pointed
> out in the part of my review that you cut in your first reply.
Error is relocate patch series to be fixed in V2; I'll rebase V2 of
this series accordingly.
Thanks again.
> Best regards,
> Benoît
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Wrong RAM Size on Devkit8000
Dear Maxime Ripard, (CCing Board Maintainer) On 05/14/2013 04:25 PM, Maxime Ripard wrote: > Hi, > > I'm currently testing u-boot 2013.04 with SPL on a Devkit8000 with 256MB > of RAM. > > Trouble is, it only detects 128MB of RAM. The x-loader found on the NAND > detects 256MB and works perfectly with it. > > I obviously tried to change the mcfg field of the timings structure to > be at MICRON_V_MCFG_165(256 << 20), however, while it obviously detects > 256MB of RAM, it then crashes quite badly when booting to a userspace > (and actually using that much RAM I guess). It works perfectly fine > though with only 128MB of RAM, so I think the timings are ok. I guess this is linux related. We have the same problem with tricorder board here. Please have a look at linux kernel a/a/mach-omap2/board-devkit8000.c and check the following line: ---8<--- omap_sdrc_init(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params); --->8--- The mt64h32m32 is a 1Gb device which is 128MiB. I think is an leftover from the very beginning of these bords in linux. Maybe in former days the boot-loader did not initialize SDRAM correctly so it was required to re-write the timing registers in linux. Nowadays this should be removed. > -- Boot from the NAND, with stock uboot/x-loader from TimLL --- > X-Loader 1.41 > Starting OS Bootloader... > > > U-Boot 1.3.3-svn (Mar 16 2012 - 17:38:47) > > OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz > OMAP3 DevKit8000 Board + LPDDR/NAND > DRAM: 256 MB > NAND: 512 MiB > Using default environment > > In:serial > Out: serial > Err: serial > Hit space key to stop autoboot: 0 > > > -- Boot from the MMC, using vanilla u-boot 2013.04 - > U-Boot SPL 2013.04 (May 14 2013 - 16:12:21) > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.img > > > U-Boot 2013.04 (May 14 2013 - 16:12:21) > > OMAP3530-GP ES3.1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz > OMAP3 DevKit8000 + LPDDR/NAND > I2C: ready > DRAM: 128 MiB > NAND: 512 MiB > MMC: OMAP SD/MMC: 0 > *** Warning - bad CRC, using default environment > > In:serial > Out: serial > Err: serial > ethaddr not set, using Die ID > Die ID #5917015470c40101a01e > Net: dm9000 > Hit any key to stop autoboot: 0 > > Any ideas on how to solve this? Patch u-boot to detect whether it needs to initialize 256MiB or 128MiB. Initialize timings correctly and remove the mentioned kernel re-timing. Patches are welcome (I havn't fixed the tricorder issue til now ... ;). Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add the symbol for the minimal SPL used to eliminate unused code
From: Ying Zhang
Add the symbol CONFIG_SPL_BUILD_MINIMAL for the minimal SPL. It used to
eliminate code unused in the minimal SPL but used in the SPL.
This patch is on top of the following patch:
1. common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for
environment in SPL.
2. powerpc/mpc85xx: support application without resetvec segment in the
linker script.
Signed-off-by: Ying Zhang
---
README |4
arch/powerpc/cpu/mpc85xx/tlb.c |2 +-
arch/powerpc/cpu/mpc8xxx/law.c |4 ++--
common/env_common.c|2 +-
include/configs/MPC8313ERDB.h |1 +
include/configs/P1022DS.h |3 +++
include/configs/p1_p2_rdb_pc.h |3 +++
7 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/README b/README
index daf1fa1..79ccfc9 100644
--- a/README
+++ b/README
@@ -3976,6 +3976,10 @@ Low Level (hardware related) configuration options:
that is executed before the actual U-Boot. E.g. when
compiling a NAND SPL.
+- CONFIG_SPL_BUILD_MINIMAL
+ Add for the minimal SPL, used to eliminate unused code to
+ save the code space.
+
- CONFIG_SYS_MPC85XX_NO_RESETVEC
Only for 85xx systems. If this variable is specified, the
section
.resetvec is not kept and the section .bootpg is placed in the
diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c b/arch/powerpc/cpu/mpc85xx/tlb.c
index 0dff37f..d21b324 100644
--- a/arch/powerpc/cpu/mpc85xx/tlb.c
+++ b/arch/powerpc/cpu/mpc85xx/tlb.c
@@ -55,7 +55,7 @@ void init_tlbs(void)
return ;
}
-#if !defined(CONFIG_NAND_SPL) && !defined(CONFIG_SPL_BUILD)
+#if !defined(CONFIG_NAND_SPL) && !defined(CONFIG_SPL_BUILD_MINIMAL)
void read_tlbcam_entry(int idx, u32 *valid, u32 *tsize, unsigned long *epn,
phys_addr_t *rpn)
{
diff --git a/arch/powerpc/cpu/mpc8xxx/law.c b/arch/powerpc/cpu/mpc8xxx/law.c
index 6f9d568..979c3c2 100644
--- a/arch/powerpc/cpu/mpc8xxx/law.c
+++ b/arch/powerpc/cpu/mpc8xxx/law.c
@@ -92,7 +92,7 @@ void disable_law(u8 idx)
return;
}
-#if !defined(CONFIG_NAND_SPL) && !defined(CONFIG_SPL_BUILD)
+#if !defined(CONFIG_NAND_SPL) && !defined(CONFIG_SPL_BUILD_MINIMAL)
static int get_law_entry(u8 i, struct law_entry *e)
{
u32 lawar;
@@ -122,7 +122,7 @@ int set_next_law(phys_addr_t addr, enum law_size sz, enum
law_trgt_if id)
return idx;
}
-#if !defined(CONFIG_NAND_SPL) && !defined(CONFIG_SPL_BUILD)
+#if !defined(CONFIG_NAND_SPL) && !defined(CONFIG_SPL_BUILD_MINIMAL)
int set_last_law(phys_addr_t addr, enum law_size sz, enum law_trgt_if id)
{
u32 idx;
diff --git a/common/env_common.c b/common/env_common.c
index 906b41f..5d82ea0 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -156,7 +156,7 @@ int set_default_vars(int nvars, char * const vars[])
H_NOCLEAR | H_INTERACTIVE, nvars, vars);
}
-#ifndef CONFIG_SPL_BUILD
+#ifndef CONFIG_SPL_BUILD_MINIMAL
/*
* Check if CRC is valid and (if yes) import the environment.
* Note that "buf" may or may not be aligned.
diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h
index c28dfe0..9b917a3 100644
--- a/include/configs/MPC8313ERDB.h
+++ b/include/configs/MPC8313ERDB.h
@@ -47,6 +47,7 @@
#ifdef CONFIG_SPL_BUILD
#define CONFIG_NS16550_MIN_FUNCTIONS
+#define CONFIG_SPL_BUILD_MINIMAL
#endif
#define CONFIG_SYS_TEXT_BASE 0x0010 /* CONFIG_SYS_NAND_U_BOOT_DST */
diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h
index 8b13b10..1cefed9 100644
--- a/include/configs/P1022DS.h
+++ b/include/configs/P1022DS.h
@@ -55,6 +55,9 @@
#define CONFIG_SYS_NAND_U_BOOT_START 0x0020
#define CONFIG_SYS_NAND_U_BOOT_OFFS0
#define CONFIG_SYS_LDSCRIPT
"arch/powerpc/cpu/mpc85xx/u-boot-nand.lds"
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_SPL_BUILD_MINIMAL
+#endif
#endif
/* High Level Configuration Options */
diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index 7ed634b..d3d3bad 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -187,6 +187,9 @@
#define CONFIG_SYS_NAND_U_BOOT_SIZE((512 << 10) - 0x2000)
#define CONFIG_SYS_NAND_U_BOOT_OFFS0
#define CONFIG_SYS_LDSCRIPT
"arch/powerpc/cpu/mpc85xx/u-boot-nand.lds"
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_SPL_BUILD_MINIMAL
+#endif
#endif
#ifndef CONFIG_SYS_TEXT_BASE
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] arm: ensure u-boot only uses relative relocations
Hi Benoît, On Wed, 15 May 2013 00:12:24 +0200 (CEST), Benoît Thébaudeau wrote: > Hi Albert, > > --- a/Makefile > > +++ b/Makefile > > @@ -746,6 +746,13 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE) > > $(MAKE) -C $@ all > > endif # config.mk > > > > +# ARM relocations should all be R_ARM_RELATIVE. > > +checkarmreloc: $(obj)u-boot > > + @if test "R_ARM_RELATIVE" != \ > > + "`readelf -r $(obj)u-boot | cut -d ' ' -f 4 | grep R_ARM | sort > > -u`"; \ > ^ > or $$< to avoid a duplicate? Will fix as suggested. > > + then echo "$(obj)u-boot contains relocations other than \ >^ >or $$< too, or no $(obj) prefix at all for this > message? I prefer leaving the prefix so that failures during out-of-tree builds or during MAKEALL builds with BUILD_NBUILDS>1 log the correct path. > Best regards, > Benoît Thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Optimize ARM relocation
Hi Benoît, On Wed, 15 May 2013 01:58:23 +0200 (CEST), Benoît Thébaudeau wrote: > Hi Albert, > > On Tuesday, May 14, 2013 10:16:01 PM, Albert ARIBAUD wrote: > > On Tue, 14 May 2013 22:02:55 +0200, Albert ARIBAUD > > wrote: > > > > > *** NOTE: this series applies over the 'Factorize > > > ARM relocate_code instances' series. > > > > > > This series optimizes relocation by ensuring ARM > > > binaries only use one type of relocation record, > > > R_ARM_RELATIVE., then optimizing relocation code > > > accordingly. > > > > > > The only known case where relocation records other > > > than R_ARM_RELATIVE are generated is when a reference > > > is made to a symbol defined in the linker script, e.g. > > > __image_copy_start, __image_copy_end, __rel_dyn_start, > > > __rel_dyn_end, and __dynsym_start. > > > > > > Moving the definition of these symbols from the linker > > > scripts into a C module causes their references' types > > > to become R_ARM_RELATIVE. > > > > > > First, arch/arm/lib/bss.c is replaced by a more generic > > > arch/arm/lib/sections.c where all section symbols will > > > be defined. > > > > > > Second, __image_copy_start and __image_copy_end symbols > > > are moved from linker scripts to arch/arm/lib/sections.c > > > > > > Third, __rel_dyn_start, __rel_dyn_end and __synsym_start > > > are moved from linker scripts into arch/arm/lib/sections.c > > > > > > Fourth, a check is added to the build system to ensure > > > that ELF U-Boot binaries only use R_ARM_RELATIVE records. > > > > > > Last, relocate_code is optimized > > > > Hmm, it seems I need to see my work posted on the list to discover how > > I could have done it better... I just noticed that if ARM binaries only > > have R_ARM_RELATIVE record types, then all the .dynsym sections can > > actually be dropped from the binaries. So, if I reorder the series and > > put patch 5/5 first, then I can eliminate patch 3/5, or more to the > > point, replace it with one which eliminates all dynsym stuff from linker > > scripts, further reducing code size. That'll go in V2... > > Indeed. Correction: if I out patch 4/5, not 5/5 -- 4/5 is the patch that ensures only relative relocations are present, and 5/5 depends on previous patches in the series (at least 1/5 and 2/5). So the new order will be 4/5, 1/5, 2/5, amended 3/5, 5/5. > Best regards, > Benoît Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Sricharan, On 15/05/13 08:11, Sricharan R wrote: > Hi, > On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: >> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >>> Hi Tom, >>> >>> On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: > Hi Tom, > > I'm currently busy with other work; on the other hand, careful > rebasing shall require some time, especially the Palmas stuff. > What would be the deadline for a V2 submission? > > Meanwhile could you please have a look at the (already old) > http://patchwork.ozlabs.org/patch/232743/? A simple patch, > shall be needed if we enable USB (for the uEVM along with > our board). In general, what are your plans regarding USB > (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? >>> Not yet (didn't have the opportunity to test, although some uEVMs should >>> be around at MMS). As you know, a patch shall be needed in the uEVM board >>> file along with the common USB stuff. >> Yeah, I can test it as well if you write it up, and may find the time if >> you point me in the right direction. >> > And again on I2C (.../patch/233823/): what is you final > opinion? I'm confident that this patch is a major improvement > for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. >>> Just applied 233823 to current u-boot-ti master. Works fine. >> OK, thanks. >> [snip] > + * TODO: Replace this ugly hardcoding with proper defines + > */ + writel(0x0100, 0x4ae0a310); Again, do please. >>> This should be (*scrm)->auxclk0. The problem is that the >>> omap5_scrm_regs struct (holding the auxclk0 member) has to be >>> defined somewhere in the common OMAP5 headers. Sricharan? Or should >>> I hack around? >> Add it to the most likely struct in the headers. > The entire struct (I call it omap5_scrm_regs in theory, similar to the > corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of > course I could define only the member that I need, but I guess it is > a (responsible) TI job to define hardware descriptors. Or I'm wrong? > Please advise. If I have time, I could do it myself - it's some 27 > registers, almost identical to the OMAP4, and should go into > arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to . Thanks! >>> I would argue that this is not very appropriate. Those regs that are >>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; >>> on the other hand the OMAP5 has some modem clock regs that are reserved >>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 >>> and below? >> We don't need to use ifdefs since there's no conflicts, things are >> either reserved in one case and used in the other. And we can make sure >> we don't try and use the omap5 bits on omap4 and vice versa. I don't >> see scrm in the first omap3 TRM I pulled up, so we don't need to worry >> there. >> >>> Currently the scrm struct is defined for OMAP4 in the >>> asm/arch-omap4/clocks.h >>> file and I have already done the same for OMAP5 by analogy. I must admit >>> however that this approach does not correspond to the latest way by which >>> groups of OMAP hardware regs are defined, prcm in particular - a struct in >>> omap_common.h, holding only the required regs, no padding and such garbage, >>> and an init with the physical addresses in a .c file for the particular SoC >>> (prcm-regs.c). But still the Panda board, for example, uses the old way for >>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and >>> lazy ;) ). >> Yes, I'm OK starting off with moving things into omap_common.h as-is and >> then updating them a bit later ala pcrm-regs.c. >> >> > I am sorry for the very late response on this. > Now then, why not add this register in to omap5_es2_prcm > ??. That is how the TRM sees it as well.. Of course, this is cleanup > stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)->x, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap
[U-Boot] [PATCH] ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for cpu_init_crit
cpu_init_crit() can be skipped, but the code is still enabled requiring a platform to supply lowlevel_init(). Signed-off-by: Axel Lin --- arch/arm/cpu/arm720t/start.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/arm720t/start.S b/arch/arm/cpu/arm720t/start.S index 9facc7e..9f0e3f9 100644 --- a/arch/arm/cpu/arm720t/start.S +++ b/arch/arm/cpu/arm720t/start.S @@ -244,6 +244,7 @@ c_runtime_cpu_setup: * */ +#ifndef CONFIG_SKIP_LOWLEVEL_INIT cpu_init_crit: #if !defined(CONFIG_TEGRA) @@ -258,6 +259,7 @@ cpu_init_crit: #endif mov pc, lr +#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ #ifndef CONFIG_SPL_BUILD -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
> -Original Message- > From: Shawn Guo [mailto:shawn@linaro.org] > Sent: Wednesday, May 15, 2013 12:15 PM > To: Wang Huan-B18965 > Cc: sba...@denx.de; u-boot@lists.denx.de; TsiChung Liew; Jin Zhengxiong- > R64188; Estevam Fabio-R49496 > Subject: Re: [U-Boot] [PATCH v2 6/6] arm: mvf600: Add basic support for > Vybrid MVF600TWR board > > On Tue, May 14, 2013 at 05:51:48PM +0800, Alison Wang wrote: > > diff --git a/include/configs/mvf600twr.h b/include/configs/mvf600twr.h > > new file mode 100644 index 000..bb1f3ef > > --- /dev/null > > +++ b/include/configs/mvf600twr.h > > To make it friendly to the mainline kernel, I would suggest we enable > the following two options. > > CONFIG_OF_LIBFDT > CONFIG_CMD_BOOTZ > [Alison Wang] Yes, I will enable them. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
On 14/05/2013 11:51, Alison Wang wrote:
> This patch adds generic codes to support Freescale's Vybrid MVF600 CPU.
>
> It aligns Vybrid MVF600 platform with i.MX platform. As there are
> some differences between MVF600 and i.MX platforms, the specific
> codes are in the arch/arm/cpu/armv7/mvf600 directory.
>
> Signed-off-by: Alison Wang
> ---
Hi Alison,
> Changes in v2:
> - Remove vybrid-common directory
> - Rename directory name 'vybrid' to 'mvf600'
> - Add generic.c file
> - Rewrite get_reset_cause() to make it readable
> - Remove reset_cpu(), and use the function in imx_watchdog.c
> - Rewrite timer.c file
> - Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk()
> - Remove lowlevel_init.S, and add clock_init() in board_early_init_f()
> - Remove useless CONFIG_SYS_ defines
> - Move CONFIG_MACH_TYPE to board configuration file
> - Define C structures and access C structures to set/read registers
> - Remove useless errata
> - Remove useless macros
> - Rename directory 'arch-vybrid' to 'arch-mvf600'
>
> Makefile| 2 +-
> arch/arm/cpu/armv7/mvf600/Makefile | 42
> arch/arm/cpu/armv7/mvf600/generic.c | 309
>
Just a minor concern here. The SOC is a ARMv5, but files go into the
armv7 directory. Maybe the bigger issue can be with the increasing
number of work-around (CONFIG_ERRATA) that flow into start.S for armv7,
that are specific only for armv7. I know that for ARMv5 we split
differently instead of ARM architecture (ARM926,...).
Albert, what do you think about ? Should these files be moved away from
armv7 ?
> +unsigned int mvf_get_clock(enum mvf_clock clk)
> +{
> + switch (clk) {
> + case MVF_ARM_CLK:
> + return get_mcu_main_clk();
> + case MVF_BUS_CLK:
> + return get_bus_clk();
> + case MVF_IPG_CLK:
> + return get_ipg_clk();
> + case MVF_UART_CLK:
> + return get_uart_clk();
> + case MVF_ESDHC_CLK:
> + return get_sdhc_clk();
> + case MVF_FEC_CLK:
> + return get_fec_clk();
> + default:
> + break;
> + }
> + return -1;
> +}
Ok - we have the same structure as for i.MX. I agree with you that the
name of the function mxc_get_clock() is not anymore correct, after some
other Freescale's SOC families were introduced. However, it is still
important to have a common API to expone a SOC to a board maintainer.
If you see, the mxs family (MX23 / MX28) has a mxc_get_clock(), even if
most internal functions are marked as mxs_. I think we can later change
the name for this function (maybe this is not the only one) to make the
name clearer and not specific to i.MX, but then it is will be easier if
all SOCs use the same names. For this reason, it is better to rename
this function to mxc_get_clock() and please take the same enums that are
already set for the other Freescale's SOCs.
> +
> +#ifdef CONFIG_FEC_MXC
> +void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
> +{
> + struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
> + struct fuse_bank *bank = &ocotp->bank[4];
> + struct fuse_bank4_regs *fuse =
> + (struct fuse_bank4_regs *)bank->fuse_regs;
> +
> + u32 value = readl(&fuse->mac_addr0);
> + mac[0] = (value >> 8);
> + mac[1] = value;
To my knowledge : is the whole MAC stored in the ocotp ? No need to add
the first bytes (vendor-id) as we had for MX28 ?
> diff --git a/arch/arm/cpu/armv7/mvf600/timer.c
> b/arch/arm/cpu/armv7/mvf600/timer.c
> new file mode 100644
> index 000..99ca57d
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/mvf600/timer.c
> @@ -0,0 +1,144 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Periodic interrupt timer registers */
> +struct pit_reg {
> + u32 mcr;
> + u32 recv0[55];
> + u32 ltmr64h;
> + u32 ltmr64l;
> + u32 recv1[6];
> + u32 ldval0;
> + u32 cval0;
> + u32 tctrl0;
> + u32 tflg0;
> + u32 ldval1;
> + u32 cval1;
> + u32 tctrl1;
> + u32 tflg1;
> + u32 ldval2;
> + u32 cval2;
> + u32 tctrl2;
> +
Re: [U-Boot] [PATCH v2 3/6] arm: mvf600: Add FEC support for Vybrid MVF600
On 14/05/2013 11:51, Alison Wang wrote: > This patch adds FEC support for Vybrid MVF600 platform. > Add code to use RMII for MVF600. > > Signed-off-by: Alison Wang > --- > Changes in v2: > - Use common FEC driver fec_mxc.c > > drivers/net/fec_mxc.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c > index 4dbcdca..21e58f4 100644 > --- a/drivers/net/fec_mxc.c > +++ b/drivers/net/fec_mxc.c > @@ -518,7 +518,11 @@ static int fec_open(struct eth_device *edev) > u32 ecr = readl(&fec->eth->ecntrl) & ~FEC_ECNTRL_SPEED; > u32 rcr = (readl(&fec->eth->r_cntrl) & > ~(FEC_RCNTRL_RMII | FEC_RCNTRL_RMII_10T)) | > - FEC_RCNTRL_RGMII | FEC_RCNTRL_MII_MODE; > + FEC_RCNTRL_MII_MODE; > + if (fec->xcv_type == RGMII) > + rcr |= FEC_RCNTRL_RGMII; > + else if (fec->xcv_type == RMII) > + rcr |= FEC_RCNTRL_RMII; > if (speed == _1000BASET) > ecr |= FEC_ECNTRL_SPEED; > else if (speed != _100BASET) > This can generally be applied, it is not only related to the new SOC. Acked-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] arm: mvf600: Add IOMUX support for Vybrid MVF600
On 14/05/2013 11:51, Alison Wang wrote: > This patch adds the IOMUX support for Vybrid MVF600 platform. > > There is a little difference for IOMUXC module between MVF600 and i.MX > platform, the muxmode and pad configuration share one 32bit register on > MVF600, but they are two independent registers on I.MX platform. A > CONFIG_IOMUX_SHARE_CONFIG_REG was introduced to fit this difference. > > Signed-off-by: Alison Wang > --- > Changes in v2: > - Use common iomux-v3 code > > arch/arm/imx-common/Makefile | 2 +- > arch/arm/imx-common/iomux-v3.c | 6 ++ > arch/arm/include/asm/imx-common/iomux-v3.h | 18 ++ > 3 files changed, 25 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile > index 8bba8a5..3378931 100644 > --- a/arch/arm/imx-common/Makefile > +++ b/arch/arm/imx-common/Makefile > @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk > > LIB = $(obj)libimx-common.o > > -ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6)) > +ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6 mvf600)) > COBJS-y = iomux-v3.o > endif > ifeq ($(SOC),$(filter $(SOC),mx5 mx6)) > diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c > index 7fe5ce7..35880c7 100644 > --- a/arch/arm/imx-common/iomux-v3.c > +++ b/arch/arm/imx-common/iomux-v3.c > @@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad) > if (sel_input_ofs) > __raw_writel(sel_input, base + sel_input_ofs); > > +#ifdef CONFIG_IOMUX_SHARE_CONF_REG > + if (!(pad_ctrl & NO_PAD_CTRL)) > + __raw_writel((mux_mode << PAD_MUX_MODE_SHIFT) | pad_ctrl, > + base + pad_ctrl_ofs); > +#else > if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) > __raw_writel(pad_ctrl, base + pad_ctrl_ofs); > +#endif > } > > void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list, > diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h > b/arch/arm/include/asm/imx-common/iomux-v3.h > index 0b4e763..7005fde 100644 > --- a/arch/arm/include/asm/imx-common/iomux-v3.h > +++ b/arch/arm/include/asm/imx-common/iomux-v3.h > @@ -121,6 +121,24 @@ typedef u64 iomux_v3_cfg_t; > #define PAD_CTL_DSE_40ohm(6 << 3) > #define PAD_CTL_DSE_34ohm(7 << 3) > > +#elif defined(CONFIG_MVF600) > + > +#define PAD_MUX_MODE_SHIFT 20 > + > +#define PAD_CTL_PUS_47K_UP (1 << 4) > +#define PAD_CTL_PUS_100K_UP (2 << 4) > +#define PAD_CTL_PUE (1 << 2) > +#define PAD_CTL_PKE (1 << 3) > + > +#define PAD_CTL_SPEED_HIGH (3 << 12) > +#define PAD_CTL_SPEED_MED(1 << 12) > + > +#define PAD_CTL_DSE_20ohm(7 << 6) > +#define PAD_CTL_DSE_25ohm(6 << 6) > +#define PAD_CTL_DSE_50ohm(3 << 6) > + > +#define PAD_CTL_OBE_IBE_ENABLE (3 << 0) > + > #else > > #define PAD_CTL_DVS (1 << 13) > Acked-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] arm: factorize relocate_code routine
On Wed, 15 May 2013 09:31:37 +0200, Albert ARIBAUD wrote: > Then I should add =relocate_code to r3, not =_start, and also -- as r9 > is not the right offset here -- compute r7 as the delta between the > link-time =_start and the run-time relocate_code (r7 becomes useless > once R10, r2 and r3 are fixed). I badly need a coffee break... Make this "r7 equal to =relocate_code", simply. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] cosmetic: arm: fix comments in arch/arm/lib/crt0.S
Signed-off-by: Masahiro Yamada --- Changes for v2: - Fix one more comment Changes for v3: - Fix the commit log to indicate * this patch is entirely cosmetic * which part was changed at a glance arch/arm/lib/crt0.S |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index a9657d1..a5bffb8 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -97,13 +97,13 @@ ENTRY(_main) * 'here' but relocated. */ - ldr sp, [r8, #GD_START_ADDR_SP] /* r8 = gd->start_addr_sp */ + ldr sp, [r8, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */ bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r8, [r8, #GD_BD]/* r8 = gd->bd */ sub r8, r8, #GD_SIZE/* new GD is below bd */ adr lr, here - ldr r0, [r8, #GD_RELOC_OFF] /* lr = gd->start_addr_sp */ + ldr r0, [r8, #GD_RELOC_OFF] /* r0 = gd->reloc_off */ add lr, lr, r0 ldr r0, [r8, #GD_RELOCADDR] /* r0 = gd->relocaddr */ b relocate_code -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: fix a comment
Hello Albert, Thanks for your advice. > So... how about a V3 with a commit summary of "cosmetic: arm: fix > comments in arch/arm/lib/crt0.S" ? People reading the summary for no I posted a v3 patch as suggested. Best Regard, Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
On 14/05/2013 11:51, Alison Wang wrote:
> MVF600TWR is a board based on Vybrid MVF600 SoC.
>
> This patch adds basic support for Vybrid MVF600TWR board.
>
> Signed-off-by: Alison Wang
> Signed-off-by: Jason Jin
> Signed-off-by: TsiChung Liew
> ---
Hi Alison,
> diff --git a/board/freescale/mvf600twr/imximage.cfg
> b/board/freescale/mvf600twr/imximage.cfg
> new file mode 100644
> index 000..33ead0f
> --- /dev/null
> +++ b/board/freescale/mvf600twr/imximage.cfg
> @@ -0,0 +1,35 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * 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. 51 Franklin Street Fifth Floor Boston,
> + * MA 02110-1301 USA
> + *
> + * Refer docs/README.imxmage for more details about how-to configure
> + * and create imximage boot image
> + *
> + * The syntax is taken as close as possible with the kwbimage
> + */
> +
> +/* image version */
> +IMAGE_VERSION 2
> +
> +/*
> + * Boot Device : one of
> + * spi, sd (the board has no nand neither onenand)
> + */
> +BOOT_FROMsd
Ok, verstanden (I hope). This SOC has plenty of internal IRAM. It still
uses the imximage mechanism, but you decided to start from internal RAM
instead of DDR and to set up the RAM controller in the board
initialization function.
We recently discussed about the wrongness of BOOT_FROM command. It makes
no sense, and it was replaced by BOOT_OFFSET. If the SOC uses the main
common offset (0x400), you can put
BOOT_OFFSET FLASH_OFFSET_STANDARD
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define UART_PAD_CTRL(PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
> + PAD_CTL_DSE_25ohm | PAD_CTL_OBE_IBE_ENABLE)
> +
> +#define ESDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |
> PAD_CTL_PUS_100K_UP | \
> + PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_20ohm | \
> + PAD_CTL_OBE_IBE_ENABLE)
Please see commit 7e2173cf82d0bc235b695460c56d46927febdf36 and adjust
this SOC consequently. PUE requires that PKE is enabled, that means that
setting PKE alone does nothing. Then it is better to define PAD_CTL_PUE
so that PKE is enabled, so in your 2/6 (that I have too fast acked):
PAD_CTL_PUE (1 << 2 | PAD_CTL_PKE)
and drop PAD_CTL_PKE here. This must fixed globally.
> +#define ENET_PAD_CTRL(PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \
> + PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
> +
> +#define DDR_PAD_CTRL PAD_CTL_DSE_25ohm
> +
> +#define PHY_DQ_TIMING0x2613
> +#define PHY_DQS_TIMING 0x2615
> +#define PHY_CTRL 0x01210080
> +#define PHY_MASTER_CTRL 0x0001012a
> +#define PHY_SLAVE_CTRL 0x00012020
> +
> +iomux_v3_cfg_t const ddr_pads[] = {
> + MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A14__DDR_A_14 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A13__DDR_A_13 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A12__DDR_A_12 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A11__DDR_A_11 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A10__DDR_A_10 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A9__DDR_A_9 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A8__DDR_A_8 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A7__DDR_A_7 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A6__DDR_A_6 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A5__DDR_A_5 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A4__DDR_A_4 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A3__DDR_A_3 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A2__DDR_A_2 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A1__DDR_A_1 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_BA2__DDR_BA_2 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_BA1__DDR_BA_1 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_BA0__DDR_BA_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_CAS__DDR_CAS_B | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_CKE__DDR_CKE_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_CLK__DDR_CLK_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_CS__DDR_CS_B_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_D15__DDR_D_15 | MUX_PAD_CTR
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi, On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: > Hi Sricharan, > > On 15/05/13 08:11, Sricharan R wrote: >> Hi, >> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: >>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >> Hi Tom, >> >> I'm currently busy with other work; on the other hand, careful >> rebasing shall require some time, especially the Palmas stuff. >> What would be the deadline for a V2 submission? >> >> Meanwhile could you please have a look at the (already old) >> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >> shall be needed if we enable USB (for the uEVM along with >> our board). In general, what are your plans regarding USB >> (.../patch/232742/)? > Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do > you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. >>> Yeah, I can test it as well if you write it up, and may find the time if >>> you point me in the right direction. >>> >> And again on I2C (.../patch/233823/): what is you final >> opinion? I'm confident that this patch is a major improvement >> for OMAP4/5 at least. > I'm inclined to go with it, just need to mentally unswap the i2c notes > in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. >>> OK, thanks. >>> > [snip] >> + * TODO: Replace this ugly hardcoding with proper defines + >> */ + writel(0x0100, 0x4ae0a310); > Again, do please. This should be (*scrm)->auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? >>> Add it to the most likely struct in the headers. >> The entire struct (I call it omap5_scrm_regs in theory, similar to the >> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of >> course I could define only the member that I need, but I guess it is >> a (responsible) TI job to define hardware descriptors. Or I'm wrong? >> Please advise. If I have time, I could do it myself - it's some 27 >> registers, almost identical to the OMAP4, and should go into >> arch/arm/include/asm/arch-omap5/clocks.h. > Whomever uses / needs it should do it. I gave the TRM a quick read and > I don't see any conflicts per-se just some reserved areas being named > and vice versa. So rename it to omap_scrm_regs and move to > . Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? >>> We don't need to use ifdefs since there's no conflicts, things are >>> either reserved in one case and used in the other. And we can make sure >>> we don't try and use the omap5 bits on omap4 and vice versa. I don't >>> see scrm in the first omap3 TRM I pulled up, so we don't need to worry >>> there. >>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). >>> Yes, I'm OK starting off with moving things into omap_common.h as-is and >>> then updating them a bit later ala pcrm-regs.c. >>> >>> >> I am sorry for the very late response on this. >> Now then, why not add this register in to omap5_es2_prcm >> ??. That is how the TRM sees it as well.. Of course, this is cleanup >> stuff for OMAP4 panda as you pointed out.. > Yes, you are right in respect to fluent software integration and consistency > with current implementation. My only concern is that from architectural point > of view the SCRM, although related to the PRCM, is a separate module > (described > correspondingly as such in the TRM). If we go this way, the SCRM regs shall > have to be referenced via the prcm pointer: (*prcm)->x, and this might be > confusing. > > I'm OK t
Re: [U-Boot] [PATCH v2 06/10] powerpc/ppc4xx: Use generic FPGA accessors on all gdsys 405ep/ex boards
Hello Wolfgang,
sorry for the delay, I had to clean some other things on my ToDoList.
I cleaned up my patchseries and wanted to start implementing your
proposal. And ran into a problem. Remember, the basic reason for the the
generic FPGA accessors was, that we have a certain amount of basically
identical FPGAs which are only connected to the CPU in different ways.
The drivers accessing those FPGAs should be agnostic of that and simply
be able to access those FPGAs by index.
It appears you need both the element address and the offset in your
fpga_set_reg() code, so you should pass this information, like that
[note that we no longer need an array of addresses]:
struct ihs_fpga fpga_ptr = (struct ihs_fpga *)CONFIG_SYS_FPGA_BASE;
...
void fpga_set_reg(u32 fpga, u16 *reg, off_t regoff, u16 data)
{
if (fpga)
return mclink_send(fpga - 1, regoff, data);
return out_le16(reg, data);
}
where mclink_send() is the routine to access the non memory mapped
FPGAs through the memory mapped FPGA:
int mclink_send(u8 slave, u16 addr, u16 data)
{
...
fpga_set_reg(0, &system_fpgas[0].mc_tx_address, addr);
fpga_set_reg(0, &system_fpgas[0].mc_tx_data, data);
fpga_set_reg(0, &system_fpgas[0].mc_tx_cmd, (slave & 0x03) << 14);
}
And this becomes:
fpga_set_reg(0,
&fpga_ptr->mc_tx_address,
offsetof(struct ihs_fpga, mc_tx_address),
addr);
etc. Yes, this is long and ugly to write, so you may want to define a
helper macro like:
#define FPGA_SET_REG(ix,fld,val)\
fpga_set_reg((ix), \
&fpga_ptr->fld, \
offsetof(struct ihs_fpga, fld), \
val)
so this turns into a plain and simple
FPGA_SET_REG(0, mc_tx_address, addr);
FPGA_SET_REG(0, mc_tx_data, data);
FPGA_SET_REG(0, mc_tx_cmd, (slave & 0x03) << 14);
This works nicely for our memory mapped FPGA. But how about the other
FPGAs? I don't have a fpga_ptr for them. Setting it NULL would make
FPGA_SET_REG dereference a NULL pointer.
Certainly I might call
fpga_set_reg(1,
NULL,
offsetof(struct ihs_fpga, mc_tx_address),
addr);
but that would not be generic any more.
Do you have any idea how to solve this?
Cheers
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] arm: ensure u-boot only uses relative relocations
Hi again Benoît, On Wed, 15 May 2013 09:46:17 +0200, Albert ARIBAUD wrote: > Hi Benoît, > > On Wed, 15 May 2013 00:12:24 +0200 (CEST), Benoît Thébaudeau > wrote: > > > Hi Albert, > > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -746,6 +746,13 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE) > > > $(MAKE) -C $@ all > > > endif# config.mk > > > > > > +# ARM relocations should all be R_ARM_RELATIVE. > > > +checkarmreloc: $(obj)u-boot > > > + @if test "R_ARM_RELATIVE" != \ > > > + "`readelf -r $(obj)u-boot | cut -d ' ' -f 4 | grep R_ARM | sort > > > -u`"; \ > > ^ > > or $$< to avoid a duplicate? > > Will fix as suggested. > > > + then echo "$(obj)u-boot contains relocations other than \ > >^ > >or $$< too, or no $(obj) prefix at all for this > > message? > > I prefer leaving the prefix so that failures during out-of-tree builds > or during MAKEALL builds with BUILD_NBUILDS>1 log the correct path. Actually $$< does not work within backquotes unless escaped as a less legible \$\$<, and does not work properly at all within double quotes, whether escaped or not. Do you prefer that I change only the first $(obj)u-boot into \$\$< and leave the second one untouched, or that I leave both $(obj)u-boot instances as-is for the sake of homogeneity? > > Best regards, > > Benoît Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mx23-olinuxino: occasional memory errors
Hi all, I was told I should report this. The tests are performed on two imx233-olinuxino boards: maxi and mini. I've removed R17 (120 ohms between CLK and CLKN) from the mini board as advised in #olimex and the Olimex forum board, but kept it on the maxi board. I am testing U-Boot 2013-04 with a patchset for mx23, build recipe is at [1] with a 3.7.2 kernel [2]. I ran `memtester 24M 100` 3 times on each board, the memtester program is built using [3] on a computer running ArchlinuxARM with armv5 architecture. The maxi board shows no signs of errors -- somewhat strange, given the popular opinion that R17 introduces instability and should be removed. The mini board, despite having R17 removed, shows occasional memory errors, here are some: Loop 3/100: Stuck Address : testing 6FAILURE: possible bad address line at offset 0x000392a0. Skipping to next test... ... Loop 15/100: Stuck Address : testing 8FAILURE: possible bad address line at offset 0x010321b0. Skipping to next test... ... FAILURE: 0x7e0ba0a0 != 0x7e4ba0a0 at offset 0x0082f8e0. Compare OR : FAILURE: 0x4e032000 != 0x4e432000 at offset 0x0088bf50. ... 8-bit Writes: /FAILURE: 0xfe0f01b0 != 0xfe4f01b0 at offset 0x007de9a4. As advised by Marek, I've repeated the test with disabled pullup on MX23_PAD_EMI_CLKN__EMI_CLKN, changing the line in board/olimex/mx23_olinuxino/spl_boot.c to: MX23_PAD_EMI_CLKN__EMI_CLKN | (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL), , but this doesn't fix the errors on the mini board. I've prepared a rootfs tarball which can be used to replicate the tests. Please see [4]. Thanks, -- Kiril [1] https://github.com/kzyapkov/PKGBUILDs/blob/master/alarm/uboot-olinuxino/PKGBUILD [2] https://github.com/kzyapkov/PKGBUILDs/blob/master/core/linux-olinuxino/PKGBUILD [3] https://aur.archlinux.org/packages/memtester/ [4] http://promptly.undo.it/alarm-memtester/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/p1022ds: boot from SD Card with SPL
From: Ying Zhang
This patch introduces SPL to enable a loader stub that runs in the L2 SRAM,
after being loaded by the code from the internal on-chip ROM. It loads the
final uboot image into DDR, then jump to it to begin execution.
The SPL's size is sizeable, the maximum size must not exceed the size of L2
SRAM. It initializes the DDR through SPD code, and copys final uboot image
to DDR. So there are two stage uboot images:
* spl_boot, 96KB size. The env variables are copied to L2 SRAM, so
that ddr spd code can get the interleaving mode setting in env. It
loads final uboot image from offset 96KB.
* final uboot image, size is variable depends on the functions
enabled.
This patch is on top of the following patch:
1. common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment
in SPL.
2. powerpc/mpc85xx: support application without resetvec segment in the
linker script.
3. Add the symbol for the minimal SPL used to eliminate unused code
4. drivers/mmc: move spl_mmc.c to common/spl
5. Makefile: move the common makefile line to public area
6. powerpc/mpc85xx: modify the function clear_bss and the end address of
the BSS
Signed-off-by: Ying Zhang
---
Compared with the previous version, this patch stripped out the independent
part with SD boot.
README |8 ++
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds |5 +
board/freescale/common/Makefile |2 -
board/freescale/p1022ds/Makefile|3 +
board/freescale/p1022ds/spl.c | 112 ++
board/freescale/p1022ds/tlb.c |9 ++-
doc/README.mpc85xx-sd-spi-boot | 82 +++
drivers/mmc/Makefile|1 +
drivers/mmc/fsl_esdhc_spl.c | 132 +++
include/configs/P1022DS.h | 56 +++--
include/fsl_esdhc.h |1 +
spl/Makefile|3 +
12 files changed, 403 insertions(+), 11 deletions(-)
create mode 100644 board/freescale/p1022ds/spl.c
create mode 100644 doc/README.mpc85xx-sd-spi-boot
create mode 100644 drivers/mmc/fsl_esdhc_spl.c
diff --git a/README b/README
index 79ccfc9..676bb99 100644
--- a/README
+++ b/README
@@ -2942,6 +2942,14 @@ FIT uImage format:
Support for NAND boot using simple NAND drivers that
expose the cmd_ctrl() interface.
+ CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT
+ Set for the SPL on PPC mpc8xxx targets, support for
+ arch/powerpc/cpu/mpc8xxx/ddr/libddr.o in SPL binary.
+
+ CONFIG_SPL_COMMON_INIT_DDR
+ Set for common ddr init with serial presence detect in
+ SPL binary.
+
CONFIG_SYS_NAND_5_ADDR_CYCLE, CONFIG_SYS_NAND_PAGE_COUNT,
CONFIG_SYS_NAND_PAGE_SIZE, CONFIG_SYS_NAND_OOBSIZE,
CONFIG_SYS_NAND_BLOCK_SIZE, CONFIG_SYS_NAND_BAD_BLOCK_POS,
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index 847818a..ba28656 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -57,6 +57,11 @@ SECTIONS
}
_edata = .;
+ . = .;
+ __start___ex_table = .;
+ __ex_table : { *(__ex_table) }
+ __stop___ex_table = .;
+
. = ALIGN(8);
__init_begin = .;
__init_end = .;
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 72bb56c..c334797 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -52,9 +52,7 @@ COBJS-$(CONFIG_MPC8555CDS)+= cds_pci_ft.o
COBJS-$(CONFIG_MPC8536DS) += ics307_clk.o
COBJS-$(CONFIG_MPC8572DS) += ics307_clk.o
-ifndef CONFIG_SPL_BUILD
COBJS-$(CONFIG_P1022DS)+= ics307_clk.o
-endif
COBJS-$(CONFIG_P2020DS)+= ics307_clk.o
COBJS-$(CONFIG_P3041DS)+= ics307_clk.o
COBJS-$(CONFIG_P4080DS)+= ics307_clk.o
diff --git a/board/freescale/p1022ds/Makefile b/board/freescale/p1022ds/Makefile
index 0eeef05..9746063 100644
--- a/board/freescale/p1022ds/Makefile
+++ b/board/freescale/p1022ds/Makefile
@@ -24,6 +24,9 @@ ifdef MINIMAL
COBJS-y+= spl_minimal.o tlb.o law.o
else
+ifdef CONFIG_SPL_BUILD
+COBJS-y += spl.o
+endif
COBJS-y+= $(BOARD).o
COBJS-y+= ddr.o
COBJS-y+= law.o
diff --git a/board/freescale/p1022ds/spl.c b/board/freescale/p1022ds/spl.c
new file mode 100644
index 000..a6c6828
--- /dev/null
+++ b/board/freescale/p1022ds/spl.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ *
+ *
Re: [U-Boot] [PATCH 1/2] mx6qsabreauto: Add i2c to mx6qsabreauto board
On 14/05/2013 06:01, Renato Frias wrote:
> Add i2c2 and 3 to mx6qsabreauto board, i2c3 is multiplexed
> use gpio to set steering.
>
> Signed-off-by: Renato Frias
> ---
> board/freescale/mx6qsabreauto/mx6qsabreauto.c | 50
> +
> include/configs/mx6qsabreauto.h |6 +++
> 2 files changed, 56 insertions(+)
>
> diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> index bfe4868..d6df750 100644
> --- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> +++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> @@ -26,12 +26,14 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -46,6 +48,12 @@ DECLARE_GLOBAL_DATA_PTR;
> #define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP |\
> PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
>
> +#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
> + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
> + PAD_CTL_ODE | PAD_CTL_SRE_FAST)
> +
> +#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
> +
> int dram_init(void)
> {
> gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
> @@ -76,6 +84,41 @@ iomux_v3_cfg_t const enet_pads[] = {
> MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
> };
>
> +/* I2C2 PMIC, iPod, Tuner, Codec, Touch, HDMI EDID, MIPI CSI2 card */
> +struct i2c_pads_info i2c_pad_info1 = {
> + .scl = {
> + .i2c_mode = MX6_PAD_EIM_EB2__I2C2_SCL | PC,
> + .gpio_mode = MX6_PAD_EIM_EB2__GPIO_2_30 | PC,
> + .gp = IMX_GPIO_NR(2, 30)
> + },
> + .sda = {
> + .i2c_mode = MX6_PAD_KEY_ROW3__I2C2_SDA | PC,
> + .gpio_mode = MX6_PAD_KEY_ROW3__GPIO_4_13 | PC,
> + .gp = IMX_GPIO_NR(4, 13)
> + }
> +};
> +
> +/*
> + * I2C3 MLB, Port Expanders (A, B, C), Video ADC, Light Sensor,
> + * Compass Sensor, Accelerometer, Res Touch
> + */
> +struct i2c_pads_info i2c_pad_info2 = {
> + .scl = {
> + .i2c_mode = MX6_PAD_GPIO_3__I2C3_SCL | PC,
> + .gpio_mode = MX6_PAD_GPIO_3__GPIO_1_3 | PC,
> + .gp = IMX_GPIO_NR(1, 3)
> + },
> + .sda = {
> + .i2c_mode = MX6_PAD_EIM_D18__I2C3_SDA | PC,
> + .gpio_mode = MX6_PAD_EIM_D18__GPIO_3_18 | PC,
> + .gp = IMX_GPIO_NR(3, 18)
> + }
> +};
> +
> +iomux_v3_cfg_t const i2c3_pads[] = {
> + MX6_PAD_EIM_A24__GPIO_5_4 | MUX_PAD_CTRL(NO_PAD_CTRL),
> +};
> +
> static void setup_iomux_enet(void)
> {
> imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads));
> @@ -216,6 +259,13 @@ int board_init(void)
> /* address of boot parameters */
> gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
>
> + /* I2C 2 and 3 setup - I2C 3 hw mux with EIM */
> + setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info1);
> + /* I2C 3 Steer */
> + gpio_direction_output(IMX_GPIO_NR(5, 4), 1);
> + imx_iomux_v3_setup_multiple_pads(i2c3_pads, ARRAY_SIZE(i2c3_pads));
> + setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info2);
> +
> return 0;
> }
>
> diff --git a/include/configs/mx6qsabreauto.h b/include/configs/mx6qsabreauto.h
> index 1583c11..947ea60 100644
> --- a/include/configs/mx6qsabreauto.h
> +++ b/include/configs/mx6qsabreauto.h
> @@ -38,4 +38,10 @@
> #define CONFIG_SYS_MMC_ENV_PART 1 /* Boot partition 1 */
> #endif
>
> +/* I2C Configs */
> +#define CONFIG_CMD_I2C
> +#define CONFIG_I2C_MULTI_BUS
> +#define CONFIG_I2C_MXC
> +#define CONFIG_SYS_I2C_SPEED 10
> +
> #endif /* __MX6QSABREAUTO_CONFIG_H */
>
Acked-by: Stefano Babic
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx6qsabreauto: Add Port Expander reset
On 14/05/2013 06:01, Renato Frias wrote:
> There are 3 IO expanders on the mx6qsabreauto all reset by the
> same GPIO, just set it to high to use the IO.
>
> Signed-off-by: Renato Frias
> ---
> board/freescale/mx6qsabreauto/mx6qsabreauto.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> index d6df750..eb2561e 100644
> --- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> +++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> @@ -119,6 +119,10 @@ iomux_v3_cfg_t const i2c3_pads[] = {
> MX6_PAD_EIM_A24__GPIO_5_4 | MUX_PAD_CTRL(NO_PAD_CTRL),
> };
>
> +iomux_v3_cfg_t const port_exp[] = {
> + MX6_PAD_SD2_DAT0__GPIO_1_15 | MUX_PAD_CTRL(NO_PAD_CTRL),
> +};
> +
> static void setup_iomux_enet(void)
> {
> imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads));
> @@ -266,6 +270,9 @@ int board_init(void)
> imx_iomux_v3_setup_multiple_pads(i2c3_pads, ARRAY_SIZE(i2c3_pads));
> setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info2);
>
> + gpio_direction_output(IMX_GPIO_NR(1, 15), 1);
> + imx_iomux_v3_setup_multiple_pads(port_exp, ARRAY_SIZE(port_exp));
> +
> return 0;
> }
>
>
Acked-by: Stefano Babic
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] env-variable setting in u-boot-function
Hi,
i want tos et an env. variable in a u-boot-function like this
fs/fs.c:
int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int fstype, int cmdline_base)
{
..
..
setenv("filesize", buf);
..
..
}
I tried it like following
Arch/x86/lib/board.c:
-
void board_init_f(ulong boot_flags)
{
..
..
gd->flags = boot_flags;
1) /*setenv("starttype", boot_flags);*/
2) setenv((const char *) "starttype", (const char *) boot_flags);
..
..
}
I will find out the starttype. But the version
1) can not be compiled
board.c: In function 'board_init_f':
board.c:223:2: error: passing argument 2 of 'setenv' makes pointer from integer
without a cast [-Werror]
In file included from board.c:34:0:
.../u-boot-2013.01/include/common.h:358:5: note: expected 'const char *' but
argument is of type 'ulong'
cc1: all warnings being treated as errors
make[1]: *** [board.o] Error 1
make[1]: Leaving directory .../u-boot-2013.01/arch/x86/lib'
make: *** [arch/x86/lib/libx86.o] Error 2
the version
2) doesn't work. This means. Starttype is not set
Thank you for hints
Mit freundlichen Grüßen / Best regards
Sabri Altunbas (DC-IA/EAH2)
Tel. +49 (0) 6062/78-526
Fax +49 (0) 6062/78-771
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Limitations/Considerations when programming U-Boot
Hi all, I'm currently investigating the possibility of using a cryptographic library in U-Boot to verify signatures during a fatload (or similar). So my question is, what has to be considered when choosing a crypto library? As far as I understood so far, U-Boot only implements a part of the C Standard Library. So this has to be considered, right? The README mentions that the stack space is very limited. Is this still the case when the "shell" is loaded or is this just the case during initialization? If so, this means for a crypto library that it should not do a lot in the stack, but prefer heap space? Then again, are there any boundaries in using heap? Maybe increase CONFIG_SYS_MALLOC_LEN? Is there anything else I have to consider? Thanks, Oliver ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 2013 Plumber's CFP: Fastboot
On Tue, May 14, 2013 at 1:51 AM, Mehaffey, John wrote: > Hello All, > Hey John! > I am proposing a microconference on fastboot at the Linux Plumber's > conference 2013 in New Orleans. The goal is to get to sub 1S boot times for > a large (IVI) system using NAND flash. This pushes the state of the art, > and will require innovative solutions in may areas of Linux plumbing, > including bootloader, kernel init, UBI, and systemd. > > Note that fastboot improvements will (generally) help all architectures so > I am not limiting this to automotive systems. > > Please visit http://wiki.linuxplumbersconf.org/2013:fastboot for more > information or if you want to submit a topic. > I've linked to your micrconference from the automotive microconference: http://wiki.linuxplumbersconf.org/2013:automotive I'm a bit confused about the LPC format though. John, is it planned to have the non-Android fastboot discussion as part of the automotive microconference or is this separate (despite its automotive relevance.) I ask because it might be nice to have the participants in both microconferences and it would be a shame to lose attendees to one or the other if they're competing tracks. Can someone clue me in to the microconference format as regards LPC? Thanks, Jeremiah ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Unable to understand flow of U-Boot Code.
Hello, I am trying to understand the flow of U-boot code, but unable to get the complete link. I can not understand how the flow goes. In which sequence the code executes. So, please give me some reference, which can explain the complete flow of execution of U-Boot code. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/7] cros: add I2C support for cros_ec
This patch adds I2C support for carrying out the cros_ec protocol.
Signed-off-by: Randall Spangler
Signed-off-by: Simon Glass
Signed-off-by: Hung-ying Tyan
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fixed warnings of exceeding 80 chars in a line.
- Added Commit message.
- Dropped the period from commit subject.
drivers/misc/Makefile | 1 +
drivers/misc/cros_ec_i2c.c | 199 +
2 files changed, 200 insertions(+)
create mode 100644 drivers/misc/cros_ec_i2c.c
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 33fe822..9363ef9 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -31,6 +31,7 @@ COBJS-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
COBJS-$(CONFIG_GPIO_LED) += gpio_led.o
COBJS-$(CONFIG_FSL_MC9SDZ60) += mc9sdz60.o
COBJS-$(CONFIG_CROS_EC) += cros_ec.o
+COBJS-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
COBJS-$(CONFIG_NS87308) += ns87308.o
COBJS-$(CONFIG_PDSP188x) += pdsp188x.o
COBJS-$(CONFIG_STATUS_LED) += status_led.o
diff --git a/drivers/misc/cros_ec_i2c.c b/drivers/misc/cros_ec_i2c.c
new file mode 100644
index 000..b0060ac
--- /dev/null
+++ b/drivers/misc/cros_ec_i2c.c
@@ -0,0 +1,199 @@
+/*
+ * Chromium OS cros_ec driver - I2C interface
+ *
+ * Copyright (c) 2012 The Chromium OS Authors.
+ * 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
+ */
+
+/*
+ * The Matrix Keyboard Protocol driver handles talking to the keyboard
+ * controller chip. Mostly this is for keyboard functions, but some other
+ * things have slipped in, so we provide generic services to talk to the
+ * KBC.
+ */
+
+#include
+#include
+#include
+
+#ifdef DEBUG_TRACE
+#define debug_trace(fmt, b...) debug(fmt, #b)
+#else
+#define debug_trace(fmt, b...)
+#endif
+
+int cros_ec_i2c_command(struct cros_ec_dev *dev, uint8_t cmd, int cmd_version,
+const uint8_t *dout, int dout_len,
+uint8_t **dinp, int din_len)
+{
+ int old_bus = 0;
+ /* version8, cmd8, arglen8, out8[dout_len], csum8 */
+ int out_bytes = dout_len + 4;
+ /* response8, arglen8, in8[din_len], checksum8 */
+ int in_bytes = din_len + 3;
+ uint8_t *ptr;
+ /* Receive input data, so that args will be dword aligned */
+ uint8_t *in_ptr;
+ int ret;
+
+ old_bus = i2c_get_bus_num();
+
+ /*
+* Sanity-check I/O sizes given transaction overhead in internal
+* buffers.
+*/
+ if (out_bytes > sizeof(dev->dout)) {
+ debug("%s: Cannot send %d bytes\n", __func__, dout_len);
+ return -1;
+ }
+ if (in_bytes > sizeof(dev->din)) {
+ debug("%s: Cannot receive %d bytes\n", __func__, din_len);
+ return -1;
+ }
+ assert(dout_len >= 0);
+ assert(dinp);
+
+ /*
+* Copy command and data into output buffer so we can do a single I2C
+* burst transaction.
+*/
+ ptr = dev->dout;
+
+ /*
+* in_ptr starts of pointing to a dword-aligned input data buffer.
+* We decrement it back by the number of header bytes we expect to
+* receive, so that the first parameter of the resulting input data
+* will be dword aligned.
+*/
+ in_ptr = dev->din + sizeof(int64_t);
+ if (!dev->cmd_version_is_supported) {
+ /* Send an old-style command */
+ *ptr++ = cmd;
+ out_bytes = dout_len + 1;
+ in_bytes = din_len + 2;
+ in_ptr--; /* Expect just a status byte */
+ } else {
+ *ptr++ = EC_CMD_VERSION0 + cmd_version;
+ *ptr++ = cmd;
+ *ptr++ = dout_len;
+ in_ptr -= 2;/* Expect status, length bytes */
+ }
+ memcpy(ptr, dout, dout_len);
+ ptr += dout_len;
+
+ if (dev->cmd_version_is_supported)
+ *ptr++ = (uint8_t)
+cros_ec_calc_checksum(dev->dout, dout_len + 3);
+
+ /* Set to the proper i2c bus */
+ if (i2c_set_bus_num(dev->bus_num)) {
+ debug("%s: Cannot change to I2C bus %d\n", __func__,
+ dev->bus_num);
+
[U-Boot] [PATCH v5 0/7] Add cros-ec protocol driver and enable it in smdk5250
This patch series adds the drivers for the cros-ec protocol that is used to communicate with the Chrome OS Embedded Controller (EC). The series also enables its use in Google Snow which is based on smdk5250. The last patch in this series depends on the patch in the MMC series that brings in exynos5-dt.c: http://patchwork.ozlabs.org/patch/240084. - Changes in v5: - Change ec-interrupt gpio pin from 174 to 782. This has to be changed again after the GPIO pin numbering patches (http://patchwork.ozlabs.org/patch/233417) are in. - Add exynos: tag wherever applicable. - Add/change dependency description. Changes in v4: - Removed unrelated exynos-spi.txt. - Moved cros-ec-keyb.txt to the cros-ec-keyb patch. - Removed old code and comment. Changes in v3: - Rearranged #include directives in alphabetical order. - Removed outdated TODO and irrelevant bug reference in comments. Changes in v2: - Moved code from smdk5250.c (non-FDT) to exynos5-dt.c (FDT). - Moved code from smdk5250.h to exynos5250-dt.h. - Added gpio node to exynos5250.dtsi. - Fixed warnings of exceeding 80 chars in a line. - Added commit message. - Dropped the period from commit subject. Hung-ying Tyan (7): cros: add cros_ec driver cros: add I2C support for cros_ec cros: exynos: add SPI support for cros_ec cros: add LPC support for cros_ec cros: adds cros_ec keyboard driver cros: exynos: add cros-ec device nodes to exynos5250-snow.dts cros: exynos: enable cros-ec for smdk5250 README |5 + arch/arm/dts/exynos5250.dtsi|3 + board/samsung/dts/exynos5250-snow.dts | 81 ++ board/samsung/smdk5250/exynos5-dt.c | 45 + doc/device-tree-bindings/input/cros-ec-keyb.txt | 79 ++ doc/device-tree-bindings/misc/cros-ec.txt | 38 + drivers/input/Makefile |1 + drivers/input/cros_ec_keyb.c| 261 drivers/misc/Makefile |4 + drivers/misc/cros_ec.c | 1304 drivers/misc/cros_ec_i2c.c | 199 drivers/misc/cros_ec_lpc.c | 283 + drivers/misc/cros_ec_spi.c | 161 +++ drivers/spi/exynos_spi.c| 22 + include/configs/exynos5250-dt.h | 10 +- include/cros_ec.h | 449 +++ include/cros_ec_message.h | 44 + include/ec_commands.h | 1440 +++ include/fdtdec.h|2 + include/spi.h | 16 + lib/fdtdec.c|2 + 21 files changed, 4448 insertions(+), 1 deletion(-) create mode 100644 doc/device-tree-bindings/input/cros-ec-keyb.txt create mode 100644 doc/device-tree-bindings/misc/cros-ec.txt create mode 100644 drivers/input/cros_ec_keyb.c create mode 100644 drivers/misc/cros_ec.c create mode 100644 drivers/misc/cros_ec_i2c.c create mode 100644 drivers/misc/cros_ec_lpc.c create mode 100644 drivers/misc/cros_ec_spi.c create mode 100644 include/cros_ec.h create mode 100644 include/cros_ec_message.h create mode 100644 include/ec_commands.h -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 5/7] cros: adds cros_ec keyboard driver
This patch adds the driver for keyboard that's controlled by ChromeOS EC.
Signed-off-by: Randall Spangler
Signed-off-by: Simon Glass
Signed-off-by: Vincent Palatin
Signed-off-by: Hung-ying Tyan
---
Changes in v5: None
Changes in v4:
- Added cros-ec-keyb.txt.
Changes in v3:
- Rearranged #include directives in alphabetical order.
- Removed outdated TODO and irrelevant bug reference in comments.
Changes in v2:
- Fixed warnings of exceeding 80 chars in a line.
- Added commit message.
- Dropped the period from commit subject.
README | 5 +
doc/device-tree-bindings/input/cros-ec-keyb.txt | 79 +++
drivers/input/Makefile | 1 +
drivers/input/cros_ec_keyb.c| 261
include/fdtdec.h| 1 +
lib/fdtdec.c| 1 +
6 files changed, 348 insertions(+)
create mode 100644 doc/device-tree-bindings/input/cros-ec-keyb.txt
create mode 100644 drivers/input/cros_ec_keyb.c
diff --git a/README b/README
index 0d37d56..55a9e35 100644
--- a/README
+++ b/README
@@ -1412,6 +1412,11 @@ CBFS (Coreboot Filesystem) support
Export function i8042_kbd_init, i8042_tstc and i8042_getc
for cfb_console. Supports cursor blinking.
+ CONFIG_CROS_EC_KEYB
+ Enables a Chrome OS keyboard using the CROS_EC interface.
+ This uses CROS_EC to communicate with a second microcontroller
+ which provides key scans on request.
+
- Video support:
CONFIG_VIDEO
diff --git a/doc/device-tree-bindings/input/cros-ec-keyb.txt
b/doc/device-tree-bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000..3118276
--- /dev/null
+++ b/doc/device-tree-bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,79 @@
+CROS_EC Keyboard
+
+The CROS_EC (Matrix Keyboard Protocol) allows communcation with a secondary
+micro used for keyboard, and possible other features.
+
+The CROS_EC keyboard uses this protocol to receive key scans and produce input
+in U-Boot.
+
+Required properties :
+- compatible : "google,cros-ec-keyb"
+- google,key-rows : Number of key rows
+- google,key-columns : Number of key columns
+
+Optional properties, in addition to those specified by the shared
+matrix-keyboard bindings:
+
+- linux,fn-keymap: a second keymap, same specification as the
+ matrix-keyboard-controller spec but to be used when the KEY_FN modifier
+ key is pressed.
+- google,repeat-delay-ms : delay in milliseconds before repeat starts
+- google,repeat-rate-ms : delay between each subsequent key press
+- google,ghost-filter : enable ghost filtering for this device
+
+Example, taken from daisy:
+
+cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ google,key-rows = <8>;
+ google,key-columns = <13>;
+ google,ghost-filter;
+ google,repeat-delay-ms = <240>;
+ google,repeat-rate-ms = <30>;
+ /*
+ * Keymap entries take the form of 0xRRCC where
+ * RR=Row CC=Column =Key Code
+ * The values below are for a US keyboard layout and
+ * are taken from the Linux driver. Note that the
+ * 102ND key is not used for US keyboards.
+ */
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003c 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACEL_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x021d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x0461 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002
[U-Boot] [PATCH v5 4/7] cros: add LPC support for cros_ec
This patch adds LPC support for carrying out the cros_ec protocol.
Signed-off-by: Randall Spangler
Signed-off-by: Simon Glass
Signed-off-by: Hung-ying Tyan
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fixed warnings of exceeding 80 chars in a line.
- Added commit message.
- Dropped the period from commit subject.
drivers/misc/Makefile | 1 +
drivers/misc/cros_ec_lpc.c | 283 +
2 files changed, 284 insertions(+)
create mode 100644 drivers/misc/cros_ec_lpc.c
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 18209ec..3553ff6 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -31,6 +31,7 @@ COBJS-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
COBJS-$(CONFIG_GPIO_LED) += gpio_led.o
COBJS-$(CONFIG_FSL_MC9SDZ60) += mc9sdz60.o
COBJS-$(CONFIG_CROS_EC) += cros_ec.o
+COBJS-$(CONFIG_CROS_EC_LPC) += cros_ec_lpc.o
COBJS-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
COBJS-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
COBJS-$(CONFIG_NS87308) += ns87308.o
diff --git a/drivers/misc/cros_ec_lpc.c b/drivers/misc/cros_ec_lpc.c
new file mode 100644
index 000..cf0435b
--- /dev/null
+++ b/drivers/misc/cros_ec_lpc.c
@@ -0,0 +1,283 @@
+/*
+ * Chromium OS cros_ec driver - LPC interface
+ *
+ * Copyright (c) 2012 The Chromium OS Authors.
+ * 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
+ */
+
+/*
+ * The Matrix Keyboard Protocol driver handles talking to the keyboard
+ * controller chip. Mostly this is for keyboard functions, but some other
+ * things have slipped in, so we provide generic services to talk to the
+ * KBC.
+ */
+
+#include
+#include
+#include
+#include
+
+#ifdef DEBUG_TRACE
+#define debug_trace(fmt, b...) debug(fmt, ##b)
+#else
+#define debug_trace(fmt, b...)
+#endif
+
+static int wait_for_sync(struct cros_ec_dev *dev)
+{
+ unsigned long start;
+
+ start = get_timer(0);
+ while (inb(EC_LPC_ADDR_HOST_CMD) & EC_LPC_STATUS_BUSY_MASK) {
+ if (get_timer(start) > 1000) {
+ debug("%s: Timeout waiting for CROS_EC sync\n",
+ __func__);
+ return -1;
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * Send a command to a LPC CROS_EC device and return the reply.
+ *
+ * The device's internal input/output buffers are used.
+ *
+ * @param dev CROS_EC device
+ * @param cmd Command to send (EC_CMD_...)
+ * @param cmd_version Version of command to send (EC_VER_...)
+ * @param dout Output data (may be NULL If dout_len=0)
+ * @param dout_len Size of output data in bytes
+ * @param dinp Place to put pointer to response data
+ * @param din_len Maximum size of response in bytes
+ * @return number of bytes in response, or -1 on error
+ */
+static int old_lpc_command(struct cros_ec_dev *dev, uint8_t cmd,
+const uint8_t *dout, int dout_len,
+uint8_t **dinp, int din_len)
+{
+ int ret, i;
+
+ if (dout_len > EC_OLD_PARAM_SIZE) {
+ debug("%s: Cannot send %d bytes\n", __func__, dout_len);
+ return -1;
+ }
+
+ if (din_len > EC_OLD_PARAM_SIZE) {
+ debug("%s: Cannot receive %d bytes\n", __func__, din_len);
+ return -1;
+ }
+
+ if (wait_for_sync(dev)) {
+ debug("%s: Timeout waiting ready\n", __func__);
+ return -1;
+ }
+
+ debug_trace("cmd: %02x, ", cmd);
+ for (i = 0; i < dout_len; i++) {
+ debug_trace("%02x ", dout[i]);
+ outb(dout[i], EC_LPC_ADDR_OLD_PARAM + i);
+ }
+ outb(cmd, EC_LPC_ADDR_HOST_CMD);
+ debug_trace("\n");
+
+ if (wait_for_sync(dev)) {
+ debug("%s: Timeout waiting ready\n", __func__);
+ return -1;
+ }
+
+ ret = inb(EC_LPC_ADDR_HOST_DATA);
+ if (ret) {
+ debug("%s: CROS_EC result code %d\n", __func__, ret);
+ return -ret;
+ }
+
+ debug_trace("resp: %02x, ", ret);
+ for (i = 0; i < din_len; i++) {
+ dev->din[i] = inb(EC_LPC_ADDR_OLD_PARAM + i);
+ debug_trace("%02x ", de
[U-Boot] [PATCH v5 3/7] cros: exynos: add SPI support for cros_ec
This patch adds SPI support for carrying out the cros_ec protocol.
Signed-off-by: Hung-ying Tyan
Signed-off-by: Randall Spangler
Signed-off-by: Simon Glass
---
Changes in v5:
- Add exynos: tag as the patch includes changes in exynos_spi.c.
Changes in v4:
- Removed old code and comment.
Changes in v3: None
Changes in v2:
- Fixed warnings of exceeding 80 chars in a line.
- Added commit message.
- Dropped the period from commit subject.
drivers/misc/Makefile | 1 +
drivers/misc/cros_ec_spi.c | 161 +
drivers/spi/exynos_spi.c | 22 +++
include/spi.h | 16 +
4 files changed, 200 insertions(+)
create mode 100644 drivers/misc/cros_ec_spi.c
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 9363ef9..18209ec 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -32,6 +32,7 @@ COBJS-$(CONFIG_GPIO_LED) += gpio_led.o
COBJS-$(CONFIG_FSL_MC9SDZ60) += mc9sdz60.o
COBJS-$(CONFIG_CROS_EC) += cros_ec.o
COBJS-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
+COBJS-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
COBJS-$(CONFIG_NS87308) += ns87308.o
COBJS-$(CONFIG_PDSP188x) += pdsp188x.o
COBJS-$(CONFIG_STATUS_LED) += status_led.o
diff --git a/drivers/misc/cros_ec_spi.c b/drivers/misc/cros_ec_spi.c
new file mode 100644
index 000..e15c833
--- /dev/null
+++ b/drivers/misc/cros_ec_spi.c
@@ -0,0 +1,161 @@
+/*
+ * Chromium OS cros_ec driver - SPI interface
+ *
+ * Copyright (c) 2012 The Chromium OS Authors.
+ * 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
+ */
+
+/*
+ * The Matrix Keyboard Protocol driver handles talking to the keyboard
+ * controller chip. Mostly this is for keyboard functions, but some other
+ * things have slipped in, so we provide generic services to talk to the
+ * KBC.
+ */
+
+#include
+#include
+#include
+
+/**
+ * Send a command to a LPC CROS_EC device and return the reply.
+ *
+ * The device's internal input/output buffers are used.
+ *
+ * @param dev CROS_EC device
+ * @param cmd Command to send (EC_CMD_...)
+ * @param cmd_version Version of command to send (EC_VER_...)
+ * @param dout Output data (may be NULL If dout_len=0)
+ * @param dout_len Size of output data in bytes
+ * @param dinp Returns pointer to response data. This will be
+ * untouched unless we return a value > 0.
+ * @param din_len Maximum size of response in bytes
+ * @return number of bytes in response, or -1 on error
+ */
+int cros_ec_spi_command(struct cros_ec_dev *dev, uint8_t cmd, int cmd_version,
+const uint8_t *dout, int dout_len,
+uint8_t **dinp, int din_len)
+{
+ int in_bytes = din_len + 4; /* status, length, checksum, trailer */
+ uint8_t *out;
+ uint8_t *p;
+ int csum, len;
+ int rv;
+
+ /*
+* Sanity-check input size to make sure it plus transaction overhead
+* fits in the internal device buffer.
+*/
+ if (in_bytes > sizeof(dev->din)) {
+ debug("%s: Cannot receive %d bytes\n", __func__, din_len);
+ return -1;
+ }
+
+ /* We represent message length as a byte */
+ if (dout_len > 0xff) {
+ debug("%s: Cannot send %d bytes\n", __func__, dout_len);
+ return -1;
+ }
+
+ /*
+* Clear input buffer so we don't get false hits for MSG_HEADER
+*/
+ memset(dev->din, '\0', in_bytes);
+
+ if (spi_claim_bus(dev->spi)) {
+ debug("%s: Cannot claim SPI bus\n", __func__);
+ return -1;
+ }
+
+ out = dev->dout;
+ out[0] = cmd_version;
+ out[1] = cmd;
+ out[2] = (uint8_t)dout_len;
+ memcpy(out + 3, dout, dout_len);
+ csum = cros_ec_calc_checksum(out, 3)
+ + cros_ec_calc_checksum(dout, dout_len);
+ out[3 + dout_len] = (uint8_t)csum;
+
+ /*
+* Send output data and receive input data starting such that the
+* message body will be dword aligned.
+*/
+ p = dev->din + sizeof(int64_t) - 2;
+ len = dout_len + 4;
+ cros_ec_dump_data("out", cmd, out, len);
+ rv = spi_xfer(dev->spi, max(len, i
[U-Boot] [PATCH v5 6/7] cros: exynos: add cros-ec device nodes to exynos5250-snow.dts
This patch adds cros-ec related device nodes to exynos5250-snow.dts.
It also adds a gpio node to exynos5250.dtsi.
Signed-off-by: Hung-ying Tyan
---
Changes in v5:
- Change ec-interrupt gpio pin from 174 to 782. This has to be changed again
after the GPIO pin numbering patches
(http://patchwork.ozlabs.org/patch/233417) are in.
Changes in v4:
- Added commit message.
Changes in v3: None
Changes in v2:
- Added gpio node to exynos5250.dtsi.
- Dropped the period from commit subject.
arch/arm/dts/exynos5250.dtsi | 3 ++
board/samsung/dts/exynos5250-snow.dts | 81 +++
2 files changed, 84 insertions(+)
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index 9c4e686..2d6dfff 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -201,4 +201,7 @@
reg = <0x1223 0x1000>;
interrupts = <0 78 0>;
};
+
+ gpio: gpio {
+ };
};
diff --git a/board/samsung/dts/exynos5250-snow.dts
b/board/samsung/dts/exynos5250-snow.dts
index 24658c1..d2ccc66 100644
--- a/board/samsung/dts/exynos5250-snow.dts
+++ b/board/samsung/dts/exynos5250-snow.dts
@@ -32,6 +32,33 @@
spi4 = "/spi@131b";
};
+ i2c4: i2c@12ca {
+ cros-ec@1e {
+ reg = <0x1e>;
+ compatible = "google,cros-ec";
+ i2c-max-frequency = <10>;
+ ec-interrupt = <&gpio 782 1>;
+ };
+
+ power-regulator@48 {
+ compatible = "ti,tps65090";
+ reg = <0x48>;
+ };
+ };
+
+ spi@131b {
+ spi-max-frequency = <100>;
+ spi-deactivate-delay = <100>;
+ cros-ec@0 {
+ reg = <0>;
+ compatible = "google,cros-ec";
+ spi-max-frequency = <500>;
+ ec-interrupt = <&gpio 782 1>;
+ optimise-flash-write;
+ status = "disabled";
+ };
+ };
+
sound@12d6 {
samsung,i2s-epll-clock-frequency = <19200>;
samsung,i2s-sampling-rate = <48000>;
@@ -69,4 +96,58 @@
samsung,dc-value= <25>;
};
+ cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ google,key-rows = <8>;
+ google,key-columns = <13>;
+ google,repeat-delay-ms = <240>;
+ google,repeat-rate-ms = <30>;
+ google,ghost-filter;
+ /*
+* Keymap entries take the form of 0xRRCC where
+* RR=Row CC=Column =Key Code
+* The values below are for a US keyboard layout and
+* are taken from the Linux driver. Note that the
+* 102ND key is not used for US keyboards.
+*/
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003b 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACEL_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x021d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x0461 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002 0x06020004 0x06030005 0x06040003
+ /* 8
[U-Boot] [PATCH v5 7/7] cros: exynos: enable cros-ec for smdk5250
This patch initiates cros-ec in board_init() to enable it for smdk5250.
This patch depends on the patch in the MMC series that brings in exynos5-dt.c.
Refer to http://patchwork.ozlabs.org/patch/240084.
Signed-off-by: Simon Glass
Signed-off-by: Vincent Palatin
Signed-off-by: Hung-ying Tyan
---
Changes in v5:
- Add exynos: tag.
- Add dependency description.
Changes in v4: None
Changes in v3: None
Changes in v2:
- Moved code from smdk5250.c (non-FDT) to exynos5-dt.c (FDT).
- Moved code from smdk5250.h to exynos5250-dt.h.
- Added commit message.
- Dropped the period from commit subject.
board/samsung/smdk5250/exynos5-dt.c | 45 +
include/configs/exynos5250-dt.h | 10 -
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/board/samsung/smdk5250/exynos5-dt.c
b/board/samsung/smdk5250/exynos5-dt.c
index b01fe72..8be3192 100644
--- a/board/samsung/smdk5250/exynos5-dt.c
+++ b/board/samsung/smdk5250/exynos5-dt.c
@@ -21,6 +21,7 @@
*/
#include
+#include
#include
#include
#include
@@ -39,6 +40,13 @@
DECLARE_GLOBAL_DATA_PTR;
+struct local_info {
+ struct cros_ec_dev *cros_ec_dev;/* Pointer to cros_ec device */
+ int cros_ec_err;/* Error for cros_ec, 0 if ok */
+};
+
+static struct local_info local;
+
#ifdef CONFIG_USB_EHCI_EXYNOS
int board_usb_vbus_init(void)
{
@@ -55,12 +63,30 @@ int board_usb_vbus_init(void)
}
#endif
+struct cros_ec_dev *board_get_cros_ec_dev(void)
+{
+ return local.cros_ec_dev;
+}
+
+static int board_init_cros_ec_devices(const void *blob)
+{
+ local.cros_ec_err = cros_ec_init(blob, &local.cros_ec_dev);
+ if (local.cros_ec_err)
+ return -1; /* Will report in board_late_init() */
+
+ return 0;
+}
+
int board_init(void)
{
gd->bd->bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
#ifdef CONFIG_EXYNOS_SPI
spi_init();
#endif
+
+ if (board_init_cros_ec_devices(gd->fdt_blob))
+ return -1;
+
#ifdef CONFIG_USB_EHCI_EXYNOS
board_usb_vbus_init();
#endif
@@ -337,3 +363,22 @@ int board_early_init_f(void)
return err;
}
#endif
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ stdio_print_current_devices();
+
+ if (local.cros_ec_err) {
+ /* Force console on */
+ gd->flags &= ~GD_FLG_SILENT;
+
+ printf("cros-ec communications failure %d\n",
+ local.cros_ec_err);
+ puts("\nPlease reset with Power+Refresh\n\n");
+ panic("Cannot init cros-ec device");
+ return -1;
+ }
+ return 0;
+}
+#endif
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 97c8825..289db00 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -82,11 +82,19 @@
#define CONFIG_BAUDRATE115200
#define EXYNOS5_DEFAULT_UART_OFFSET0x01
+/* Enable keyboard */
+#define CONFIG_CROS_EC /* CROS_EC protocol */
+#define CONFIG_CROS_EC_SPI /* Support CROS_EC over SPI */
+#define CONFIG_CROS_EC_I2C /* Support CROS_EC over I2C */
+#define CONFIG_CROS_EC_KEYB/* CROS_EC keyboard input */
+#define CONFIG_CMD_CROS_EC
+#define CONFIG_KEYBOARD
+
/* Console configuration */
#define CONFIG_CONSOLE_MUX
#define CONFIG_SYS_CONSOLE_IS_IN_ENV
#define EXYNOS_DEVICE_SETTINGS \
- "stdin=serial\0" \
+ "stdin=serial,cros-ec-keyb\0" \
"stdout=serial,lcd\0" \
"stderr=serial,lcd\0"
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Sricharan, On 15/05/13 12:04, Sricharan R wrote: > Hi, > > On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: >> Hi Sricharan, >> >> On 15/05/13 08:11, Sricharan R wrote: >>> Hi, >>> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: > Hi Tom, > > On 14/05/13 17:52, Tom Rini wrote: >> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >>> Hi Tom, >>> >>> I'm currently busy with other work; on the other hand, careful >>> rebasing shall require some time, especially the Palmas stuff. >>> What would be the deadline for a V2 submission? >>> >>> Meanwhile could you please have a look at the (already old) >>> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >>> shall be needed if we enable USB (for the uEVM along with >>> our board). In general, what are your plans regarding USB >>> (.../patch/232742/)? >> Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do >> you have a patch around for uEVM still? > Not yet (didn't have the opportunity to test, although some uEVMs should > be around at MMS). As you know, a patch shall be needed in the uEVM board > file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. >>> And again on I2C (.../patch/233823/): what is you final >>> opinion? I'm confident that this patch is a major improvement >>> for OMAP4/5 at least. >> I'm inclined to go with it, just need to mentally unswap the i2c notes >> in my brain and think it over one more time. > Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. >> [snip] >>> +* TODO: Replace this ugly hardcoding with proper defines + >>> */ +writel(0x0100, 0x4ae0a310); >> Again, do please. > This should be (*scrm)->auxclk0. The problem is that the > omap5_scrm_regs struct (holding the auxclk0 member) has to be > defined somewhere in the common OMAP5 headers. Sricharan? Or should > I hack around? Add it to the most likely struct in the headers. >>> The entire struct (I call it omap5_scrm_regs in theory, similar to the >>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of >>> course I could define only the member that I need, but I guess it is >>> a (responsible) TI job to define hardware descriptors. Or I'm wrong? >>> Please advise. If I have time, I could do it myself - it's some 27 >>> registers, almost identical to the OMAP4, and should go into >>> arch/arm/include/asm/arch-omap5/clocks.h. >> Whomever uses / needs it should do it. I gave the TRM a quick read and >> I don't see any conflicts per-se just some reserved areas being named >> and vice versa. So rename it to omap_scrm_regs and move to >> . Thanks! > I would argue that this is not very appropriate. Those regs that are > reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; > on the other hand the OMAP5 has some modem clock regs that are reserved > on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 > and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. > Currently the scrm struct is defined for OMAP4 in the > asm/arch-omap4/clocks.h > file and I have already done the same for OMAP5 by analogy. I must admit > however that this approach does not correspond to the latest way by which > groups of OMAP hardware regs are defined, prcm in particular - a struct in > omap_common.h, holding only the required regs, no padding and such > garbage, > and an init with the physical addresses in a .c file for the particular > SoC > (prcm-regs.c). But still the Panda board, for example, uses the old way > for > scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and > lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. >>> I am sorry for the very late response on this. >>> Now then, why not add this register in to omap5_es2_prcm >>> ??. That is how the TRM sees it as well.. Of course, this is cleanup >>> stuff for OMAP4 panda as you pointed out.. >> Yes, you are right in respect to fluent software integration and consistency >> with current implementation. My only concern is that from architectural point >> of view the SCRM, although related to the PRCM, is a separate module >> (described >> corr
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote: > Hi Sricharan, > > On 15/05/13 12:04, Sricharan R wrote: >> Hi, >> >> On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: >>> Hi Sricharan, >>> >>> On 15/05/13 08:11, Sricharan R wrote: Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: > On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >> Hi Tom, >> >> On 14/05/13 17:52, Tom Rini wrote: >>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? >>> Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do >>> you have a patch around for uEVM still? >> Not yet (didn't have the opportunity to test, although some uEVMs should >> be around at MMS). As you know, a patch shall be needed in the uEVM board >> file along with the common USB stuff. > Yeah, I can test it as well if you write it up, and may find the time if > you point me in the right direction. > And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. >>> I'm inclined to go with it, just need to mentally unswap the i2c notes >>> in my brain and think it over one more time. >> Just applied 233823 to current u-boot-ti master. Works fine. > OK, thanks. > >>> [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); >>> Again, do please. >> This should be (*scrm)->auxclk0. The problem is that the >> omap5_scrm_regs struct (holding the auxclk0 member) has to be >> defined somewhere in the common OMAP5 headers. Sricharan? Or should >> I hack around? > Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. >>> Whomever uses / needs it should do it. I gave the TRM a quick read and >>> I don't see any conflicts per-se just some reserved areas being named >>> and vice versa. So rename it to omap_scrm_regs and move to >>> . Thanks! >> I would argue that this is not very appropriate. Those regs that are >> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; >> on the other hand the OMAP5 has some modem clock regs that are reserved >> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 >> and below? > We don't need to use ifdefs since there's no conflicts, things are > either reserved in one case and used in the other. And we can make sure > we don't try and use the omap5 bits on omap4 and vice versa. I don't > see scrm in the first omap3 TRM I pulled up, so we don't need to worry > there. > >> Currently the scrm struct is defined for OMAP4 in the >> asm/arch-omap4/clocks.h >> file and I have already done the same for OMAP5 by analogy. I must admit >> however that this approach does not correspond to the latest way by which >> groups of OMAP hardware regs are defined, prcm in particular - a struct >> in >> omap_common.h, holding only the required regs, no padding and such >> garbage, >> and an init with the physical addresses in a .c file for the particular >> SoC >> (prcm-regs.c). But still the Panda board, for example, uses the old way >> for >> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old >> and >> lazy ;) ). > Yes, I'm OK starting off with moving things into omap_common.h as-is and > then updating them a bit later ala pcrm-regs.c. > > I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. >>> Yes, you are right in respect to fluent software integration and consistency >>> with
Re: [U-Boot] [PATCH v2 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
Hi Stefano,
On Wed, 15 May 2013 10:13:36 +0200, Stefano Babic
wrote:
> On 14/05/2013 11:51, Alison Wang wrote:
> > This patch adds generic codes to support Freescale's Vybrid MVF600 CPU.
> >
> > It aligns Vybrid MVF600 platform with i.MX platform. As there are
> > some differences between MVF600 and i.MX platforms, the specific
> > codes are in the arch/arm/cpu/armv7/mvf600 directory.
> >
> > Signed-off-by: Alison Wang
> > ---
>
> Hi Alison,
>
> > Changes in v2:
> > - Remove vybrid-common directory
> > - Rename directory name 'vybrid' to 'mvf600'
> > - Add generic.c file
> > - Rewrite get_reset_cause() to make it readable
> > - Remove reset_cpu(), and use the function in imx_watchdog.c
> > - Rewrite timer.c file
> > - Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk()
> > - Remove lowlevel_init.S, and add clock_init() in board_early_init_f()
> > - Remove useless CONFIG_SYS_ defines
> > - Move CONFIG_MACH_TYPE to board configuration file
> > - Define C structures and access C structures to set/read registers
> > - Remove useless errata
> > - Remove useless macros
> > - Rename directory 'arch-vybrid' to 'arch-mvf600'
> >
> > Makefile| 2 +-
> > arch/arm/cpu/armv7/mvf600/Makefile | 42
> > arch/arm/cpu/armv7/mvf600/generic.c | 309
> >
>
> Just a minor concern here. The SOC is a ARMv5, but files go into the
> armv7 directory. Maybe the bigger issue can be with the increasing
> number of work-around (CONFIG_ERRATA) that flow into start.S for armv7,
> that are specific only for armv7. I know that for ARMv5 we split
> differently instead of ARM architecture (ARM926,...).
>
> Albert, what do you think about ? Should these files be moved away from
> armv7 ?
If the SoC is ARMv5, then yes, its arch/arm/cpu files should not go in
armv7 -- and then, we may have to discuss whether, and how, to factorize
ISA-level code. Maybe we need an arch/arm/isa/armv{4,5,6,7...} beside
arch/cpu, and move wherever is isa-specific there.
Regarding errata, I don't understand your point: if they are specific
to armv7, then arch/arm/cpu/armv7/start.S seems to be the place to put
them (assuming they affect execution before board_init_f() of course).
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
On 15/05/2013 14:09, Albert ARIBAUD wrote:
>>
>> Albert, what do you think about ? Should these files be moved away from
>> armv7 ?
>
> If the SoC is ARMv5, then yes, its arch/arm/cpu files should not go in
> armv7 -- and then, we may have to discuss whether, and how, to factorize
> ISA-level code. Maybe we need an arch/arm/isa/armv{4,5,6,7...} beside
> arch/cpu, and move wherever is isa-specific there.
Agree. I think adding armv{4,5,6,7...} is the most clean solution.
>
> Regarding errata, I don't understand your point: if they are specific
> to armv7, then arch/arm/cpu/armv7/start.S seems to be the place to put
> them (assuming they affect execution before board_init_f() of course).
I was not able to express my point, sorry. Of course, the right place
for them is arch/arm/cpu/armv7/start.S. My concern was related to this
SOC, as it seems it steals armv7 code but it is not armv7. Then changes
in start.S, that fixes real problems for armv7, can break this Vybrid.
But the reason is that Vybrid initialization should not be taken from
arch/arm/cpu/armv7/start.S.
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
Hi Stefano,
On Wed, 15 May 2013 14:24:33 +0200, Stefano Babic
wrote:
> On 15/05/2013 14:09, Albert ARIBAUD wrote:
> >>
> >> Albert, what do you think about ? Should these files be moved away from
> >> armv7 ?
> >
> > If the SoC is ARMv5, then yes, its arch/arm/cpu files should not go in
> > armv7 -- and then, we may have to discuss whether, and how, to factorize
> > ISA-level code. Maybe we need an arch/arm/isa/armv{4,5,6,7...} beside
> > arch/cpu, and move wherever is isa-specific there.
>
> Agree. I think adding armv{4,5,6,7...} is the most clean solution.
This is a clean solution, but do we have the problem? IOW, do we have a
substantial quantity of code that is common to a given ISA but neither
generic to ARM (if it were, it would go to arch/arm or arch/arm/lib) nor
specific to a CPU (if it were, then it should stay under arch/arm/cpu/)?
If we do then moving this code under an isa tree makes sense; if we
don't, then arch/arm/cpu// is enough, and mvf600 just jas to
move under arch/arm/cpu/ and copy the few ARMv5 snippets it needs from
another ARMv5-based cpu.
IMO, the proof is in the pudding: if I see a patch that creates e.g.
arch/arm/isa/armv5 and factorizes isa code there from cpu subdirs, and
if this results in a smaller codebase (apart from doc) and no binary
size increase, then I'll ack it and apply it [albeit on next as the
merge window is now closed].
> > Regarding errata, I don't understand your point: if they are specific
> > to armv7, then arch/arm/cpu/armv7/start.S seems to be the place to put
> > them (assuming they affect execution before board_init_f() of course).
>
> I was not able to express my point, sorry. Of course, the right place
> for them is arch/arm/cpu/armv7/start.S. My concern was related to this
> SOC, as it seems it steals armv7 code but it is not armv7. Then changes
> in start.S, that fixes real problems for armv7, can break this Vybrid.
> But the reason is that Vybrid initialization should not be taken from
> arch/arm/cpu/armv7/start.S.
I understand now, and this is a valid point -- all the more a reason to
move mvf600 under arch/cpu/, with or without factorizing armv5 code.
> Best regards,
> Stefano
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] OMAP3+: introduce generic ABB support
Hi,
Tom, Nishant, could you please review this series ?
Thank you in advance.
Regards,
Andrii
On 05/13/2013 05:15 PM, Andrii Tseglytskyi wrote:
Adaptive Body Biasing (ABB) modulates transistor bias voltages
dynamically in order to optimize switching speed versus leakage.
Adaptive Body-Bias ldos are present for some voltage domains
starting with OMAP3630. There are three modes of operation:
* Bypass - the default, it just follows the vdd voltage
* Foward Body-Bias - applies voltage bias to increase transistor
performance at the cost of power. Used to operate safely at high
OPPs.
* Reverse Body-Bias - applies voltage bias to decrease leakage and
save power. Used to save power at lower OPPs.
Signed-off-by: Andrii Tseglytskyi
---
arch/arm/cpu/armv7/omap-common/Makefile |1 +
arch/arm/cpu/armv7/omap-common/abb.c| 139 +++
arch/arm/cpu/armv7/omap5/Makefile |1 +
arch/arm/cpu/armv7/omap5/abb.c | 65 +++
arch/arm/include/asm/arch-omap3/omap3.h |9 ++
arch/arm/include/asm/arch-omap4/omap.h |7 ++
arch/arm/include/asm/arch-omap5/omap.h | 13 +++
arch/arm/include/asm/omap_common.h | 22 +
8 files changed, 257 insertions(+)
create mode 100644 arch/arm/cpu/armv7/omap-common/abb.c
create mode 100644 arch/arm/cpu/armv7/omap5/abb.c
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index 55e82ba..c4b9809 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -34,6 +34,7 @@ COBJS += hwinit-common.o
COBJS += clocks-common.o
COBJS += emif-common.o
COBJS += vc.o
+COBJS += abb.o
endif
ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),)
diff --git a/arch/arm/cpu/armv7/omap-common/abb.c
b/arch/arm/cpu/armv7/omap-common/abb.c
new file mode 100644
index 000..7ade110
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/abb.c
@@ -0,0 +1,139 @@
+/*
+ *
+ * Adaptive Body Bias programming sequence for OMAP family
+ *
+ * (C) Copyright 2013
+ * Texas Instruments,
+ *
+ * Andrii Tseglytskyi R
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+
+__weak s8 abb_setup_ldovbb(u32 fuse, u32 ldovbb)
+{
+ return -1;
+}
+
+static void abb_setup_timings(u32 setup)
+{
+ u32 sys_rate, sr2_cnt, clk_cycles;
+
+ /*
+* SR2_WTCNT_VALUE is the settling time for the ABB ldo after a
+* transition and must be programmed with the correct time at boot.
+* The value programmed into the register is the number of SYS_CLK
+* clock cycles that match a given wall time profiled for the ldo.
+* This value depends on:
+* settling time of ldo in micro-seconds (varies per OMAP family),
+* of clock cycles per SYS_CLK period (varies per OMAP family),
+* the SYS_CLK frequency in MHz (varies per board)
+* The formula is:
+*
+* ldo settling time (in micro-seconds)
+* SR2_WTCNT_VALUE = --
+* (# system clock cycles) * (sys_clk period)
+*
+* Put another way:
+*
+* SR2_WTCNT_VALUE = settling time / (# SYS_CLK cycles / SYS_CLK rate))
+*
+* To avoid dividing by zero multiply both "# clock cycles" and
+* "settling time" by 10 such that the final result is the one we want.
+*/
+
+ /* calculate SR2_WTCNT_VALUE */
+ sys_rate = DIV_ROUND(V_OSCK, 100);
+ clk_cycles = DIV_ROUND(OMAP_ABB_CLOCK_CYCLES * 10, sys_rate);
+ sr2_cnt = DIV_ROUND(OMAP_ABB_SETTLING_TIME * 10, clk_cycles);
+
+ setbits_le32(setup,
+sr2_cnt << (ffs(OMAP_ABB_SETUP_SR2_WTCNT_VALUE_MASK) - 1));
+}
+
+void abb_setup(u32 fuse, u32 ldovbb, u32 setup, u32 control,
+ u32 txdone, u32 txdone_mask, u32 opp)
+{
+ u32 abb_type_mask, opp_sel_mask;
+
+ /* sanity check */
+ if (!setup || !control || !txdone)
+ return;
+
+ /* setup ABB only in case of Fast or Slow OPP */
+ switch (opp) {
+ case OMAP_ABB_
Re: [U-Boot] [PATCH 0/2] Power: remove support for Freescale MPC8220
On Sat, May 11, 2013 at 03:00:48PM +0200, Wolfgang Denk wrote: > The Freescale MPC8220 Power Architecture processors have long reached > EOL; Freescale does not even list these any more on their web site. > > Remove the code to avoid wasting maitaining efforts on dead stuff. > > Wolfgang Denk (2): > doc/README.scrapyard: add missing commit IDs > Power: remove support for Freescale MPC8220 Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v3] Please pull u-boot-mpc85xx.git
On Tue, May 14, 2013 at 05:26:23PM -0500, Andy Fleming wrote: > The following changes since commit a661b99dbc35e725f229a7b8e189ca21304ba026: > > Merge branch 'master' of git://git.denx.de/u-boot-x86 (2013-05-13 18:17:39 > -0400) > > are available in the git repository at: > > > git://www.denx.de/git/u-boot-mpc85xx.git master > > for you to fetch changes up to f63d638dad5dd13f445d1e87ce824d4a7cd61f79: > > T4240/eth: fix SGMII card PHY address (2013-05-14 16:13:25 -0500) > > Tested on 85xx and 83xx. > > > Andy Fleming (2): > powerpc/mpc85xx: Add definitions for HDBCR registers > e6500: Move L1 enablement after L2 enablement > > Ed Swarthout (1): > powerpc/t4qds: Fix disabling remote I2C connection > > Roy Zang (4): > T4/serdes: fix the serdes clock frequency > T4/SerDes: correct the SATA index > T4/USB: Add USB 2.0 UTMI dual phy support > T4/usb: move usb 2.0 utmi dual phy init code to cpu_init.c > > Sandeep Singh (1): > powerpc/B4860: Corrected FMAN1 operating frequency print at u-boot > > Shaohui Xie (7): > powerpc/t4240qds: Fix SPI flash type > powerpc/t4240qds: fix XAUI card PHY address > Fman/t4240: some fix for 10G XAUI > powerpc/85xx: add missing QMAN frequency calculation > net/phy: add VSC8574 support > T4240/net: use QSGMII card PHY address by default > T4240/eth: fix SGMII card PHY address > > Shengzhou Liu (3): > t4240qds/eth: fixup ethernet for t4240qds > net/fm: fixup ethernet for mEMAC > powerpc/85xx: fix build error introduced by serdes_get_prtcl > > York Sun (14): > powerpc/mpc85xx: Update corenet global utility block registers > powerpc/t4240qds: Update DDR timing table > powerpc/mpc8xxx: Fix DDR 3-way interleaving > powerpc/mpc85xx: Fix portal setup > powerpc/t4240qds: Add voltage ID support > powerpc/corenet2: Print SerDes protocol in decimal > powerpc/mpc85xx: Fix PIR parsing for chassis2 > powerpc/t4240: Fix SerDes protocol arrays with const prefix > powerpc/mpc85xx: Add T4160 SoC > powerpc/t4240qds: Move SoC define into boards.cfg > powerpc: Add T4160QDS > powerpc/mpc85xx: Update workaround for DDR erratum A-004934 > powerpc/mpc8xxx: Allow board file to override DDR address assignment > powerpc/b4860qds: Assign DDR address in board file > > arch/powerpc/cpu/mpc85xx/Makefile |3 + > arch/powerpc/cpu/mpc85xx/cpu_init.c| 22 ++ > arch/powerpc/cpu/mpc85xx/ddr-gen3.c|2 +- > arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c |2 +- > arch/powerpc/cpu/mpc85xx/portals.c | 36 ++- > arch/powerpc/cpu/mpc85xx/release.S | 14 +- > arch/powerpc/cpu/mpc85xx/speed.c | 12 + > arch/powerpc/cpu/mpc85xx/start.S | 102 +++ > arch/powerpc/cpu/mpc85xx/t4240_serdes.c| 150 +- > arch/powerpc/cpu/mpc8xxx/cpu.c |1 + > arch/powerpc/cpu/mpc8xxx/ddr/main.c| 26 +- > arch/powerpc/include/asm/config_mpc85xx.h | 36 ++- > arch/powerpc/include/asm/immap_85xx.h | 66 - > arch/powerpc/include/asm/processor.h | 11 + > board/freescale/b4860qds/ddr.c | 72 + > board/freescale/t4qds/ddr.c| 56 ++-- > board/freescale/t4qds/eth.c| 356 > +++- > board/freescale/t4qds/t4240qds_qixis.h |2 +- > board/freescale/t4qds/t4qds.c | 237 +++- > boards.cfg |9 +- > drivers/net/fm/Makefile|1 + > drivers/net/fm/eth.c |2 + > drivers/net/fm/fm.h|2 + > drivers/net/fm/init.c | 31 +++ > drivers/net/fm/t4240.c | 14 +- > drivers/net/phy/vitesse.c | 67 + > include/configs/T4240QDS.h |1 - > include/configs/t4qds.h| 42 ++- > include/fm_eth.h |4 +- > include/phy.h |2 + > 30 files changed, 1154 insertions(+), 227 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP5: Enable USB Ethernet support with LAN9730
On Mon, Apr 01, 2013 at 04:50:55AM -, Lubomir Popov wrote: > Added the LAN9730 to list of supported devices. This chip is used > in the sEVM, uEVM and som5_evb. Tested on the som5_evb with dhcp > and ping. > > Signed-off-by: Lubomir Popov Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/19] Allow images to work on sandbox
On Tue, May 07, 2013 at 09:11:44AM -0700, Simon Glass wrote: > This series adjusts the image code to work with sandbox and prepares it for > verified boot to come later. > > The primary goal here is to get image loading to work on sandbox, which is > mostly a set of fairly minor changes such as using map_sysmem() instead of > just a cast when converting from a U-Boot address to a pointer. Since > common/image.c runs to over 3000 lines and half of it is FIT-related code > behind an #ifdef, this code is moved into a new image-fit.c file. > > Changes in v4: > - Bring in upstream version of fdt_first/next_subnode() > - Use new upstream fdt_first/next_subnode() Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot UBI support
On Wed, May 08, 2013 at 05:08:10PM -, Paul B. Henson wrote: > On Tue, May 07, 2013 at 11:01:35PM -0400, Tom Rini wrote: > > > All changes do, but you can just reply to this thread. > > Ok, here it is again, with the tag. > > > >From 532cc340712c0542526be601c3f9f886e7054e5c Mon Sep 17 00:00:00 2001 > From: "Paul B. Henson" > Date: Sat, 4 May 2013 17:44:43 -0700 > Subject: [PATCH] Update doc/README.ubi to add description of accessing ubi > filesystems. > > Signed-off-by: "Paul B. Henson" Reworded such that the commit message is: doc/README.ubi: Add description of accessing ubi filesystems and applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 01/12] mkimage: Put FIT loading in function and tidy error handling
On Wed, May 08, 2013 at 08:05:57AM -, Simon Glass wrote: > The fit_handle_file() function is quite long - split out the part that > loads and checks a FIT into its own function. We will use this > function for storing public keys into a destination FDT file. > > The error handling is currently a bit repetitive - tidy it. > > Signed-off-by: Simon Glass Applied to u-boot/master, along with the rest of the series, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smc911x: fix the timeout detection
On Wed, May 08, 2013 at 09:42:44PM -, Masahiro Yamada wrote: > If timeout is occurred at the while loop above, > the value of 'timeout' is -1, not 0. > > Signed-off-by: Masahiro Yamada Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] drivers/mmc: move spl_mmc.c to common/spl
On Thu, May 09, 2013 at 11:00:36PM -, ying.zh...@freescale.com wrote: > From: Ying Zhang > > The mpc85xx repuires a special layout on the memory device that is > connected to the eSDHC controller interface. But the file spl_mmc.c > didn't handle this specfic case, there needs a special treatmen, in > the powerpc drictory. So, there is no longer to keep spl_mmc.c on > mpc85xx, CONFIG_SPL_FRAMEWORK is not set. > > When CONFIG_SPL_MMC_SUPPORT is set and CONFIG_SPL_FRAMEWORK is not > set, there was an error in drivers/mmc/spl_mmc.c: > > drivers/mmc/libmmc.o:(.got2+0x8): undefined reference to `spl_image'. > > Now, the solution is to move the file "spl_mmc.c" to directory "common/spl". > > Signed-off-by: Ying Zhang Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [systemd-devel] 2013 Plumber's CFP: Fastboot
On Wed, 15.05.13 11:43, Jeremiah Foster (jeremiah.fos...@pelagicore.com) wrote: > On Tue, May 14, 2013 at 1:51 AM, Mehaffey, John > wrote: > > > Hello All, > > > > Hey John! > > > > I am proposing a microconference on fastboot at the Linux Plumber's > > conference 2013 in New Orleans. The goal is to get to sub 1S boot times for > > a large (IVI) system using NAND flash. This pushes the state of the art, > > and will require innovative solutions in may areas of Linux plumbing, > > including bootloader, kernel init, UBI, and systemd. > > > > Note that fastboot improvements will (generally) help all architectures so > > I am not limiting this to automotive systems. > > > > Please visit http://wiki.linuxplumbersconf.org/2013:fastboot for more > > information or if you want to submit a topic. > > > > I've linked to your micrconference from the automotive microconference: > http://wiki.linuxplumbersconf.org/2013:automotive > > I'm a bit confused about the LPC format though. John, is it planned to have > the non-Android fastboot discussion as part of the automotive > microconference or is this separate (despite its automotive relevance.) I > ask because it might be nice to have the participants in both > microconferences and it would be a shame to lose attendees to one or the > other if they're competing tracks. > > Can someone clue me in to the microconference format as regards LPC? BTW, there's also this MC we proposed: http://wiki.linuxplumbersconf.org/2013:boot_and_core_os which sounds pretty close to fastboot? Lennart -- Lennart Poettering - Red Hat, Inc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for cpu_init_crit
Hi Marek, On Wed, 15 May 2013 05:36:14 +0200, Marek Vasut wrote: > Dear Axel Lin, > > > cpu_init_crit() can be skipped, but the code is still enabled requiring a > > platform to supply lowlevel_init(). > > > > Signed-off-by: Axel Lin > > Nice CC list, it'd be the best if you CCed the ARM maintainer too though ;-) Thanks Marek. :) > > --- > > arch/arm/cpu/arm720t/start.S | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm/cpu/arm720t/start.S b/arch/arm/cpu/arm720t/start.S > > index 9facc7e..9f0e3f9 100644 > > --- a/arch/arm/cpu/arm720t/start.S > > +++ b/arch/arm/cpu/arm720t/start.S > > @@ -244,6 +244,7 @@ c_runtime_cpu_setup: > > * > > */ > > > > +#ifndef CONFIG_SKIP_LOWLEVEL_INIT > > cpu_init_crit: > > > > #if !defined(CONFIG_TEGRA) > > @@ -258,6 +259,7 @@ cpu_init_crit: > > #endif > > > > mov pc, lr > > +#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ > > > > > > #ifndef CONFIG_SPL_BUILD I am tempted to ask: what actual issue does this guarding aim at solving? Just in case, beware that AFAIR Wolfgang does not consider 'because debugging' a valid answer. > Best regards, > Marek Vasut Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Sricharan, Tom, On 15/05/13 14:25, Sricharan R wrote: > On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote: >> Hi Sricharan, >> >> On 15/05/13 12:04, Sricharan R wrote: >>> Hi, >>> >>> On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: Hi Sricharan, On 15/05/13 08:11, Sricharan R wrote: > Hi, > On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: >> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >>> Hi Tom, >>> >>> On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: > Hi Tom, > > I'm currently busy with other work; on the other hand, careful > rebasing shall require some time, especially the Palmas stuff. > What would be the deadline for a V2 submission? > > Meanwhile could you please have a look at the (already old) > http://patchwork.ozlabs.org/patch/232743/? A simple patch, > shall be needed if we enable USB (for the uEVM along with > our board). In general, what are your plans regarding USB > (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? >>> Not yet (didn't have the opportunity to test, although some uEVMs should >>> be around at MMS). As you know, a patch shall be needed in the uEVM >>> board >>> file along with the common USB stuff. >> Yeah, I can test it as well if you write it up, and may find the time if >> you point me in the right direction. >> > And again on I2C (.../patch/233823/): what is you final > opinion? I'm confident that this patch is a major improvement > for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. >>> Just applied 233823 to current u-boot-ti master. Works fine. >> OK, thanks. >> [snip] > + * TODO: Replace this ugly hardcoding with proper defines + > */ + writel(0x0100, 0x4ae0a310); Again, do please. >>> This should be (*scrm)->auxclk0. The problem is that the >>> omap5_scrm_regs struct (holding the auxclk0 member) has to be >>> defined somewhere in the common OMAP5 headers. Sricharan? Or should >>> I hack around? >> Add it to the most likely struct in the headers. > The entire struct (I call it omap5_scrm_regs in theory, similar to the > corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of > course I could define only the member that I need, but I guess it is > a (responsible) TI job to define hardware descriptors. Or I'm wrong? > Please advise. If I have time, I could do it myself - it's some 27 > registers, almost identical to the OMAP4, and should go into > arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to . Thanks! >>> I would argue that this is not very appropriate. Those regs that are >>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; >>> on the other hand the OMAP5 has some modem clock regs that are reserved >>> on OMAP4. We shall probably have ugly #ifdefs again. And what about >>> OMAP3 >>> and below? >> We don't need to use ifdefs since there's no conflicts, things are >> either reserved in one case and used in the other. And we can make sure >> we don't try and use the omap5 bits on omap4 and vice versa. I don't >> see scrm in the first omap3 TRM I pulled up, so we don't need to worry >> there. >> >>> Currently the scrm struct is defined for OMAP4 in the >>> asm/arch-omap4/clocks.h >>> file and I have already done the same for OMAP5 by analogy. I must admit >>> however that this approach does not correspond to the latest way by >>> which >>> groups of OMAP hardware regs are defined, prcm in particular - a struct >>> in >>> omap_common.h, holding only the required regs, no padding and such >>> garbage, >>> and an init with the physical addresses in a .c file for the particular >>> SoC >>> (prcm-regs.c). But still the Panda board, for example, uses the old way >>> for >>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old >>> and >>> lazy ;) ). >> Yes, I'm OK starting off with moving things into omap_common.h as-is and >> then updating them a bit later ala pcrm-regs.c. >> >> > I am sorry for the very late response on this. > Now then, why not add this register in to omap5_es2_prcm > ??. That is how th
[U-Boot] Samsung patches pending
Hi Minkyu, I have collected a list of patches from the mailing list related to exynos and tested them on snow. This is not a complete list - there is still the GPIO patches to come, plus 'EXYNOS: Move files from board/samsung to arch/arm' but these will need to be rebased. I have pushed the patches I collected and tested to u-boot-x86.git in branch snow. The list (in reverse order) is: d1c106f (HEAD, x86/snow, snow) EXYNOS: Add API for power reset and exit wakeup a79f0a6 Exynos5: cpufreq: Implement frequency scaling for exynos5 aa90070 pmic: max77686: add pmic_set_voltage api for max77686 cacbe6a EXYNOS4210: Configure GPIO for uart 4e37956 EXYNOS: LDS file move to common e751ab2 EXYNOS: Add API for power reset and shutdown 2900538 EXYNOS: Move includes from setup.h to tzpc_init.c fd0ba0c CONFIG: EXYNOS5: Enable silent console 3337750 S5P: Serial: Add fdt support to driver 9319822 EXYNOS5: FDT: Add serial device node values c0ba798 EXYNOS5: FDT: Add compatible strings for Serial 3700619 exynos: dts: Use 50MHz SPI flash speed on snow 8492823 EXYNOS: SPL: Add a custom spi copy function c89dd42 EXYNOS: SPI: Support word transfers f887dfd EXYNOS: SPI: Minimise access to SPI FIFO level 8f49e3c EXYNOS: SPI: Support a delay after deactivate 4aba9b5 EXYNOS: Export timer_get_us() to get microsecond timer 3f60ae8 EXYNOS: SPI: Support SPI_PREAMBLE mode 65cbaed SPI: Add support for preamble bytes e9c45bb exynos: Enable mmc for snow e9f0d09 COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition 5de8a42 SMDK5250: Enable EMMC booting e545b7d MMC: APIs to support resize of EMMC boot partition edcf63d SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT 102ab75 EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted results. 646756e EXYNOS5: DWMMC: Added FDT support for DWMMC 272db65 DWMMC: Initialise dwmci and resolve EMMC read write issues cc32791 EXYNOS5: FDT: Add DWMMC device node data adfd53c FDT: Add compatible string for DWMMC Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] EXYNOS: Move files from board/samsung to arch/arm.
Hi Rajeswari, On Sun, May 12, 2013 at 8:40 PM, Rajeshwari Birje wrote: > Hi Simon, > > Thank you for reviewing the patch set. > You need to apply the following patches for it to compile and work fine. > > EXYNOS: Add API for power reset and exit wakeup > EXYNOS: LDS file move to common > EXYNOS4210: Configure GPIO for uart > EXYNOS: Move files from board/samsung to arch/arm. > > From the error it looks like "EXYNOS: Add API for power reset and exit > wakeup" patch is missing. Yes that fixes it, thank you. I sent an email to the maintainer with the list. > On Sun, May 12, 2013 at 12:09 AM, Simon Glass wrote: >> Hi Rajeshwari, >> >> On Wed, Apr 24, 2013 at 11:57 PM, Rajeshwari Shinde >> wrote: >>> This patch performs the following: >>> >>> 1) Convert the assembly code for memory and clock initialization to C code. >>> 2) Move the memory and clock init codes from board/samsung to arch/arm >>> 3) Creat a common lowlevel_init file across Exynos4 and Exynos5. Converted >>>the common lowlevel_init from assembly to C-code >>> 4) Made spl_boot.c and tzpc_init.c common for both exynos4 and exynos5. >>> 5) Enable CONFIG_SKIP_LOWLEVEL_INIT as stack pointer initialisation is >>> already >>> done in _main. >>> 6) exynos-uboot-spl.lds made common across SMDKV310, Origen and SMDK5250. >>> >>> TEST: Tested SD-MMC boot on SMDK5250 and Origen. >>> Tested USB and SPI boot on SMDK5250 >>> Compile tested for SMDKV310. >>> >>> Signed-off-by: Hatim Ali >>> Signed-off-by: Rajeshwari Shinde >> >> Congratulations on getting this patch together. >> >> It looks correct, but I had some problems getting it to build. >> Probably I am missing some other patch. >> >> Configuring for smdk5250 board... >> lowlevel_init.c: In function ‘do_lowlevel_init’: >> lowlevel_init.c:50:2: warning: implicit declaration of function >> ‘get_reset_status’ [-Wimplicit-function-declaration] >> spl_boot.c: In function ‘board_init_f’: >> spl_boot.c:141:3: warning: implicit declaration of function >> ‘power_exit_wakeup’ [-Wimplicit-function-declaration] >> arch/arm/cpu/armv7/exynos/libexynos.o: In function `board_init_f': >> /mnt/host/source/src/third_party/u-boot/files/arch/arm/cpu/armv7/exynos/spl_boot.c:141: >> undefined reference to `power_exit_wakeup' >> arch/arm/cpu/armv7/exynos/libexynos.o: In function `do_lowlevel_init': >> /mnt/host/source/src/third_party/u-boot/files/arch/arm/cpu/armv7/exynos/lowlevel_init.c:50: >> undefined reference to `get_reset_status' >> make[1]: *** [/mnt/host/source/src/third_party/u-boot/files/spl/u-boot-spl] >> Error 1 >> >> I will send a separate email about the patch situation. Here are the >> patches I applied in reverse order - please let me know if I missed >> any. >> >> d3858f7 (HEAD, snow2) EXYNOS: Move files from board/samsung to arch/arm. >> e666035 hack: Remove TPM definitions from exysno5-dt.h so that next >> patch applies cleanly >> c9ec2d1 EXYNOS4210: Configure GPIO for uart >> cf6e500 EXYNOS: LDS file move to common >> a40665b EXYNOS: Add API for power reset and shutdown [snip] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v2] PMIC: max77686: add pmic_set_voltage api for max77686
On Sun, May 12, 2013 at 10:19 PM, Akshay Saraswat wrote: > This patch adds pmic_set_voltage api in max77686. > As the name suggests, this api is required for switching > voltage from one level to another. Unit for the new > voltage value should be microvolts. > > Signed-off-by: Akshay Saraswat Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
On 15/05/2013 14:39, Albert ARIBAUD wrote:
> Hi Stefano,
>
Hi Albert, hi Alison,
>> Agree. I think adding armv{4,5,6,7...} is the most clean solution.
>
> This is a clean solution, but do we have the problem? IOW, do we have a
> substantial quantity of code that is common to a given ISA but neither
> generic to ARM (if it were, it would go to arch/arm or arch/arm/lib) nor
> specific to a CPU (if it were, then it should stay under arch/arm/cpu/)?
> If we do then moving this code under an isa tree makes sense; if we
> don't, then arch/arm/cpu// is enough, and mvf600 just jas to
> move under arch/arm/cpu/ and copy the few ARMv5 snippets it needs from
> another ARMv5-based cpu.
Roght - this is also a clean solution, because we have already arm926
and so on. Alison, please check how you can move your initialization
code as Alber suggested.
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] lcd: add functions to setup up simplefb device tree
Hi Stephen,
On Fri, May 10, 2013 at 9:35 PM, Stephen Warren wrote:
> On 05/08/2013 09:33 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Tue, May 7, 2013 at 10:21 PM, Stephen Warren
>> wrote:
>>> simple-framebuffer is a new device tree binding that describes a pre-
>>> configured frame-buffer memory region and its format. The Linux kernel
>>> contains a driver that supports this binding. Implement functions to
>>> create a DT node (or fill in an existing node) with parameters that
>>> describe the framebuffer format that U-Boot is using.
>>>
>>> This will be immediately used by the Raspberry Pi board in U-Boot, and
>>> likely will be used by the Samsung ARM ChromeBook support soon too. It
>>> could well be used by many other boards (e.g. Tegra boards with built-in
>>> LCD panels, which aren't yet supported by the Linux kernel).
>
>> This looks OK - is a better place for it than the common lcd code? I
>> presume it is here because it accesses panel_info?
>
> I believe it really is common code; the DT content this code generates
> is defined by a generic binding and isn't SoC-/board-specific. Perhaps a
> common DT-related file would be OK too, although as you mention I'm not
> sure if any other file would have access to the required LCD variables.
>
>> Also is there a binding file we can bring in?
>
> Yes, there's a simple-framebuffer.txt I could copy from the kernel.
Yes, it looks good.
>
>>> +int lcd_dt_simplefb_add_node(void *blob)
>>
>> Can we not automatically find the node and update it?
>
> Some DTs might have the node already exist and want to edit it, whereas
> others might not contain it at all and need it added. This is rather up
> to the author of individual boards' DTs. I wanted to make the code
> explicitly select between those two options so that the U-Boot board
> author always thought about exactly which behaviour they wanted.
OK.
>
>>> +int lcd_dt_simplefb_enable_existing_node(void *blob)
>>> +{
>>> + int off;
>>> +
>>> + off = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
>>
>> Do we ever need to support more than one node, iwc perhaps we want to
>> pass in the offset? If not, then see above question re searching.
>
> I don't think U-Boot supports multiple panels does it? If the DT
> contained multiple nodes to start with, I think they'd have to all be
> initially disabled since some firmware would be required to fill in the
> fields before they were useful.
>
> As such, finding and editing the first node in all cases seems to make
> sense for now. If this ever becomes false, we can add an index parameter
> quite easily without significant impact.
Sounds reasonable. I guess U-Boot will support multiple panels once
driver model is fully installed, but for now it does not.
>
>>> diff --git a/include/lcd.h b/include/lcd.h
>
>>> +#if defined(CONFIG_LCD_DT_SIMPLEFB)
>>
>> Probably don't need this #ifdef? It will complicate things if we use
>> the autoconf series.
>
> What's the autoconf series? I did this in order to get compile errors
> rather than link errors if the functions were used without being
> enabled, but I guess most linkers generate useful error messages so
> perhaps this isn't needed.
>
It was posted 26 Feb - first patch is here:
http://patchwork.ozlabs.org/patch/223278/
Also while you are in review mode, I'd appreciate any comment you have
on U-Boot driver model:
http://patchwork.ozlabs.org/patch/242451/
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 V5] EXYNOS5: Add gpio pin numbering feature
Hi Minkyu, On Sun, May 12, 2013 at 9:07 PM, Rajeshwari Birje wrote: > Hi Simon, > > I applied the V5 patches on the latest u-boot-samsung tree and need > seem to compile fine. > Yes I will need to rebase them once the MMC patches get in, but will > wait for comments from Minkyu Kang as well > so that I can incorporate them and rebase the patch set once the MMC > patches get in. I am looking forward to seeing the outstanding patches applied - will this be soon? Regards, Simon > > Regards, > Rajeshwari Shinde. > > On Sat, May 11, 2013 at 11:48 PM, Simon Glass wrote: >> HI Rajeshwari, >> >> On Wed, Apr 3, 2013 at 5:54 AM, Rajeshwari Shinde >> wrote: >>> This patch adds support for gpio pin numbering support on >>> EXYNOS5250 >>> To have consistent 0..n-1 GPIO numbering the banks are divided >>> into different parts where ever they have holes in them. >>> >>> Signed-off-by: Leela Krishna Amudala >>> Signed-off-by: Rajeshwari Shinde >>> --- >>> Changes in V2: >>> - none. >>> Changes in V3: >>> - none. >>> Changes in V4: >>> - To have consistent 0..n-1 GPIO numbering the banks are divided >>> into different parts where ever they have holes in them. >>> - Combined previous patch 1 and 2 into single patch. >>> Changes in V5: >>> - Removed Exynos5 specific code in gpio driver api to >>> get bank. >>> - Added #define HAVE_GENERIC_GPIO in config file >>> to remove conditinal CPU check in gpio driver. >> >> With this series I am getting errors in exynos5-dt.c: >> >> 25: EXYNOS5: Add gpio pin numbering feature >>arm: + snow >> +exynos5-dt.c: In function 'board_usb_vbus_init': >> +exynos5-dt.c:79: error: 'struct exynos5_gpio_part1' has no member named 'x2' >> +exynos5-dt.c: In function 'board_enable_audio_codec': >> +exynos5-dt.c:95: error: 'struct exynos5_gpio_part1' has no member named 'x1' >> +exynos5-dt.c:96: error: 'struct exynos5_gpio_part1' has no member named 'x1' >> +exynos5-dt.c: In function 'exynos_cfg_lcd_gpio': >> +exynos5-dt.c:412: error: 'struct exynos5_gpio_part1' has no member named >> 'x1' >> +exynos5-dt.c:413: error: 'struct exynos5_gpio_part1' has no member named >> 'x1' >> +exynos5-dt.c:416: error: 'struct exynos5_gpio_part1' has no member named >> 'x0' >> >> >> This is probably due to new support added, so I think you need to >> adjust your patch. >> >> Here is the sequence I am testing with (reverse order of application): >> >> 9529fd4 (HEAD, ws/snow, snow) EXYNOS5: GPIO: Enable GPIO Command for EXYNOS5 >> 0f81b33 S5P: Rename GPIO definitions >> 0c6254b EXYNOS5: Add gpio pin numbering feature >> 5a35ef9 CONFIG: EXYNOS5: Enable silent console >> 6083f4f S5P: Serial: Add fdt support to driver >> 2f78e0f EXYNOS5: FDT: Add serial device node values >> 5b85902 EXYNOS5: FDT: Add compatible strings for Serial >> 6402856 exynos: dts: Use 50MHz SPI flash speed on snow >> 1a6900e EXYNOS: SPL: Add a custom spi copy function >> 27530a7 EXYNOS: SPI: Support word transfers >> 7f8ba96 EXYNOS: SPI: Minimise access to SPI FIFO level >> 149742a EXYNOS: SPI: Support a delay after deactivate >> f3d8caf EXYNOS: Export timer_get_us() to get microsecond timer >> 1aaa266 EXYNOS: SPI: Support SPI_PREAMBLE mode >> 2752d08 SPI: Add support for preamble bytes >> 279a5cb exynos: Enable mmc for snow >> a6280ba COMMON: MMC: Command to support EMMC booting and to resize >> EMMC boot partition >> 19425ea SMDK5250: Enable EMMC booting >> 5253ae0 MMC: APIs to support resize of EMMC boot partition >> 15bb05e SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT >> eeef540 EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted >> results. >> a4d8bf2 EXYNOS5: DWMMC: Added FDT support for DWMMC >> 71b87c4 DWMMC: Initialise dwmci and resolve EMMC read write issues >> 97c6565 EXYNOS5: FDT: Add DWMMC device node data >> ec5fb8b FDT: Add compatible string for DWMMC >> e7c528b EXYNOS5: I2C: Add FDT and non-FDT support for I2C >> >> Regards, >> Simon >> >> >>> arch/arm/cpu/armv7/exynos/pinmux.c | 150 -- >>> arch/arm/include/asm/arch-exynos/cpu.h | 10 +- >>> arch/arm/include/asm/arch-exynos/gpio.h | 452 >>> +++ >>> board/samsung/smdk5250/smdk5250.c | 24 +- >>> drivers/gpio/s5p_gpio.c | 42 +++ >>> include/configs/exynos5250-dt.h |1 + >>> 6 files changed, 522 insertions(+), 157 deletions(-) >>> >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot > > > > -- > Regards, > Rajeshwari Shinde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Add support for Congatec Conga-QEVAl board
Add minimal support (only boot from mmc device) for the Congatec Conga-QEVAl Evaluation Carrier Board with conga-Qmx6q (i.MX6 Quad processor) module. Signed-off-by: Leo Sartre --- Changes in v3: -Files where moved to cgtqmx6eval. -MX6Q macro is passed in config as it is done for the wandboard. Thanks Otavio for these advices. MAINTAINERS |4 + board/congatec/cgtqmx6eval/Makefile | 42 +++ board/congatec/cgtqmx6eval/README| 28 + board/congatec/cgtqmx6eval/cgtqmx6eval.c | 178 +++ boards.cfg |1 + include/configs/cgtqmx6eval.h| 197 ++ 6 files changed, 450 insertions(+) create mode 100644 board/congatec/cgtqmx6eval/Makefile create mode 100644 board/congatec/cgtqmx6eval/README create mode 100644 board/congatec/cgtqmx6eval/cgtqmx6eval.c create mode 100644 include/configs/cgtqmx6eval.h diff --git a/MAINTAINERS b/MAINTAINERS index 643a5ac..b61484b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -889,6 +889,10 @@ Steve Sakoman omap3_overo ARM ARMV7 (OMAP3xx SoC) +Leo Sartre + + cgtqmx6qi.MX6Q + Jens Scharsig eb_cpux9k2 ARM920T (AT91RM9200 SoC) diff --git a/board/congatec/cgtqmx6eval/Makefile b/board/congatec/cgtqmx6eval/Makefile new file mode 100644 index 000..ac16c1f --- /dev/null +++ b/board/congatec/cgtqmx6eval/Makefile @@ -0,0 +1,42 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# (C) Copyright 2013 Adeneo Embedded +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := cgtqmx6eval.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/congatec/cgtqmx6eval/README b/board/congatec/cgtqmx6eval/README new file mode 100644 index 000..31162e2 --- /dev/null +++ b/board/congatec/cgtqmx6eval/README @@ -0,0 +1,28 @@ +U-Boot for the Congatec Conga-QEVAl Evaluation Carrier board + +This file contains information for the port of U-Boot to the Congatec +Conga-QEVAl Evaluation Carrier board. + +1. Boot source, boot from SD card +- + +This version of u-boot works only on the SD card. By default, the +Congatec board can boot only from the SPI-NOR. +But, with the u-boot version provided with the board you can write boot +registers to force the board to reboot and boot from the SD slot. If +"bmode" command is not available from your pre-installed u-boot, these +instruction will produce the same effect: + +conga-QMX6 U-Boot > mw.l 0x20d8040 0x3850 +conga-QMX6 U-Boot > mw.l 0x020d8044 0x1000 +conga-QMX6 U-Boot > reset +resetting ... + +The the board will reboot and, if you have written your SD correctly +the board will use u-boot that live into the SD + +To copy the resulting u-boot.imx to the SD card: + + dd if=u-boot.imx of=/dev/xxx bs=512 seek=2 + +Note: Replace xxx with the device representing the SD card in your system. diff --git a/board/congatec/cgtqmx6eval/cgtqmx6eval.c b/board/congatec/cgtqmx6eval/cgtqmx6eval.c new file mode 100644 index 000..e5d2adb --- /dev/null +++ b/board/congatec/cgtqmx6eval/cgtqmx6eval.c @@ -0,0 +1,178 @@ +/* + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. + * Based on mx6qsabrelite.c file + * Copyright (C) 2013, Adeneo Embedded + * Leo Sartre, + * + * 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 Publi
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
On Wed, May 15, 2013 at 04:10:46PM +0300, Lubomir Popov wrote: > Hi Sricharan, Tom, [snip] > Now on USB in general: u-boot-ti master lags behind mainline master in > respect to > drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old > .../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then > Tom > does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom? The patch still git am's fine on master (just checked), so it's OK as-is. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add support for Congatec Conga-QEVAl board
On Wed, May 15, 2013 at 10:36 AM, SARTRE Leo wrote: > Add minimal support (only boot from mmc device) for the Congatec > Conga-QEVAl Evaluation Carrier Board with conga-Qmx6q (i.MX6 Quad > processor) module. > > Signed-off-by: Leo Sartre > --- > > Changes in v3: > -Files where moved to cgtqmx6eval. > -MX6Q macro is passed in config as it is done for the > wandboard. > Thanks Otavio for these advices. > > MAINTAINERS |4 + > board/congatec/cgtqmx6eval/Makefile | 42 +++ > board/congatec/cgtqmx6eval/README| 28 + > board/congatec/cgtqmx6eval/cgtqmx6eval.c | 178 +++ > boards.cfg |1 + > include/configs/cgtqmx6eval.h| 197 > ++ > 6 files changed, 450 insertions(+) > create mode 100644 board/congatec/cgtqmx6eval/Makefile > create mode 100644 board/congatec/cgtqmx6eval/README > create mode 100644 board/congatec/cgtqmx6eval/cgtqmx6eval.c > create mode 100644 include/configs/cgtqmx6eval.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 643a5ac..b61484b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -889,6 +889,10 @@ Steve Sakoman > > omap3_overo ARM ARMV7 (OMAP3xx SoC) > > +Leo Sartre > + > + cgtqmx6qi.MX6Q > + > Jens Scharsig > > eb_cpux9k2 ARM920T (AT91RM9200 SoC) > diff --git a/board/congatec/cgtqmx6eval/Makefile > b/board/congatec/cgtqmx6eval/Makefile > new file mode 100644 > index 000..ac16c1f > --- /dev/null > +++ b/board/congatec/cgtqmx6eval/Makefile > @@ -0,0 +1,42 @@ > +# > +# Copyright (C) 2007, Guennadi Liakhovetski > +# > +# (C) Copyright 2011 Freescale Semiconductor, Inc. > +# (C) Copyright 2013 Adeneo Embedded > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation; either version 2 of > +# the License, or (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > +# > + > +include $(TOPDIR)/config.mk > + > +LIB= $(obj)lib$(BOARD).o > + > +COBJS := cgtqmx6eval.o > + > +SRCS := $(COBJS:.o=.c) > +OBJS := $(addprefix $(obj),$(COBJS)) > + > +$(LIB):$(obj).depend $(OBJS) > + $(call cmd_link_o_target, $(OBJS)) > + > +# > + > +# defines $(obj).depend target > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +# > diff --git a/board/congatec/cgtqmx6eval/README > b/board/congatec/cgtqmx6eval/README > new file mode 100644 > index 000..31162e2 > --- /dev/null > +++ b/board/congatec/cgtqmx6eval/README > @@ -0,0 +1,28 @@ > +U-Boot for the Congatec Conga-QEVAl Evaluation Carrier board > + > +This file contains information for the port of U-Boot to the Congatec > +Conga-QEVAl Evaluation Carrier board. > + > +1. Boot source, boot from SD card > +- > + > +This version of u-boot works only on the SD card. By default, the > +Congatec board can boot only from the SPI-NOR. > +But, with the u-boot version provided with the board you can write boot > +registers to force the board to reboot and boot from the SD slot. If > +"bmode" command is not available from your pre-installed u-boot, these > +instruction will produce the same effect: > + > +conga-QMX6 U-Boot > mw.l 0x20d8040 0x3850 > +conga-QMX6 U-Boot > mw.l 0x020d8044 0x1000 > +conga-QMX6 U-Boot > reset > +resetting ... > + > +The the board will reboot and, if you have written your SD correctly > +the board will use u-boot that live into the SD > + > +To copy the resulting u-boot.imx to the SD card: > + > + dd if=u-boot.imx of=/dev/xxx bs=512 seek=2 > + > +Note: Replace xxx with the device representing the SD card in your system. > diff --git a/board/congatec/cgtqmx6eval/cgtqmx6eval.c > b/board/congatec/cgtqmx6eval/cgtqmx6eval.c > new file mode 100644 > index 000..e5d2adb > --- /dev/null > +++ b/board/congatec/cgtqmx6eval/cgtqmx6eval.c > @@ -0,0 +1,178 @@ > +/* > + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. > + * Based on mx6qsabrelite.c file > + * Copyright (C) 2013, Adeneo Embedded > + * Leo Sartre, > + * > + * 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 Softw
Re: [U-Boot] [PATCH 4/5] arm: ensure u-boot only uses relative relocations
Hi Albert, On Wednesday, May 15, 2013 11:38:37 AM, Albert ARIBAUD wrote: > Hi again Benoît, > > On Wed, 15 May 2013 09:46:17 +0200, Albert ARIBAUD > wrote: > > > Hi Benoît, > > > > On Wed, 15 May 2013 00:12:24 +0200 (CEST), Benoît Thébaudeau > > wrote: > > > > > Hi Albert, > > > > > > --- a/Makefile > > > > +++ b/Makefile > > > > @@ -746,6 +746,13 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE) > > > > $(MAKE) -C $@ all > > > > endif # config.mk > > > > > > > > +# ARM relocations should all be R_ARM_RELATIVE. > > > > +checkarmreloc: $(obj)u-boot > > > > + @if test "R_ARM_RELATIVE" != \ > > > > + "`readelf -r $(obj)u-boot | cut -d ' ' -f 4 | grep > > > > R_ARM | sort > > > > -u`"; \ > > > ^ > > > or $$< to avoid a duplicate? > > > > Will fix as suggested. > > > > > + then echo "$(obj)u-boot contains relocations other than > > > > \ > > >^ > > >or $$< too, or no $(obj) prefix at all for > > >this message? > > > > I prefer leaving the prefix so that failures during out-of-tree builds > > or during MAKEALL builds with BUILD_NBUILDS>1 log the correct path. > > Actually $$< does not work within backquotes unless escaped as a less > legible \$\$<, and does not work properly at all within double quotes, > whether escaped or not. > > Do you prefer that I change only the first $(obj)u-boot into \$\$< and > leave the second one untouched, or that I leave both $(obj)u-boot > instances as-is for the sake of homogeneity? Actually, a single dollar sign (i.e. "$<") would be needed since it must have been expanded by make before reaching the shell, and no shell backslash escape sequences should be required. If this still does not pass smoothly, then I prefer simplicity and homogeneity. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] arm: mvf600: Add IOMUX support for Vybrid MVF600
Hi Stefano, Alison, On Wednesday, May 15, 2013 10:16:40 AM, Stefano Babic wrote: > On 14/05/2013 11:51, Alison Wang wrote: > > This patch adds the IOMUX support for Vybrid MVF600 platform. > > > > There is a little difference for IOMUXC module between MVF600 and i.MX > > platform, the muxmode and pad configuration share one 32bit register on > > MVF600, but they are two independent registers on I.MX platform. A > > CONFIG_IOMUX_SHARE_CONFIG_REG was introduced to fit this difference. > > > > Signed-off-by: Alison Wang > > --- > > Changes in v2: > > - Use common iomux-v3 code > > > > arch/arm/imx-common/Makefile | 2 +- > > arch/arm/imx-common/iomux-v3.c | 6 ++ > > arch/arm/include/asm/imx-common/iomux-v3.h | 18 ++ > > 3 files changed, 25 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile > > index 8bba8a5..3378931 100644 > > --- a/arch/arm/imx-common/Makefile > > +++ b/arch/arm/imx-common/Makefile > > @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk > > > > LIB = $(obj)libimx-common.o > > > > -ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6)) > > +ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6 mvf600)) > > COBJS-y= iomux-v3.o > > endif > > ifeq ($(SOC),$(filter $(SOC),mx5 mx6)) > > diff --git a/arch/arm/imx-common/iomux-v3.c > > b/arch/arm/imx-common/iomux-v3.c > > index 7fe5ce7..35880c7 100644 > > --- a/arch/arm/imx-common/iomux-v3.c > > +++ b/arch/arm/imx-common/iomux-v3.c > > @@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad) > > if (sel_input_ofs) > > __raw_writel(sel_input, base + sel_input_ofs); > > > > +#ifdef CONFIG_IOMUX_SHARE_CONF_REG > > + if (!(pad_ctrl & NO_PAD_CTRL)) > > + __raw_writel((mux_mode << PAD_MUX_MODE_SHIFT) | pad_ctrl, > > + base + pad_ctrl_ofs); > > +#else > > if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) > > __raw_writel(pad_ctrl, base + pad_ctrl_ofs); > > +#endif > > } > > > > void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list, > > diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h > > b/arch/arm/include/asm/imx-common/iomux-v3.h > > index 0b4e763..7005fde 100644 > > --- a/arch/arm/include/asm/imx-common/iomux-v3.h > > +++ b/arch/arm/include/asm/imx-common/iomux-v3.h > > @@ -121,6 +121,24 @@ typedef u64 iomux_v3_cfg_t; > > #define PAD_CTL_DSE_40ohm (6 << 3) > > #define PAD_CTL_DSE_34ohm (7 << 3) > > > > +#elif defined(CONFIG_MVF600) > > + > > +#define PAD_MUX_MODE_SHIFT 20 > > + > > +#definePAD_CTL_PUS_47K_UP (1 << 4) > > +#definePAD_CTL_PUS_100K_UP (2 << 4) > > +#define PAD_CTL_PUE(1 << 2) > > +#define PAD_CTL_PKE(1 << 3) > > + > > +#define PAD_CTL_SPEED_HIGH (3 << 12) > > +#define PAD_CTL_SPEED_MED (1 << 12) > > + > > +#define PAD_CTL_DSE_20ohm (7 << 6) > > +#define PAD_CTL_DSE_25ohm (6 << 6) > > +#define PAD_CTL_DSE_50ohm (3 << 6) > > + > > +#define PAD_CTL_OBE_IBE_ENABLE (3 << 0) > > + > > #else > > > > #define PAD_CTL_DVS(1 << 13) > > > > Acked-by: Stefano Babic Could you please just fix the spaces/tabs mess in the #define-s? Thanks. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] TPM: STMicroelectronics u-boot driver I2C
From: Mathias Leblanc
* STMicroelectronics version 1.2.0, Copyright (C) 2013
* This is free software, and you are welcome to redistribute it.
This is the u-boot driver for TPM chip from ST Microelectronics.
If you have a TPM security chip from STMicroelectronics working with
an I2C, read the README file and add the correct defines regarding
the tpm in the configuration file of your board.
This file is located in include/configs/your_board.h
The tpm command will be accessible from within uboot terminal.
Signed-off-by: Mathias Leblanc
---
README | 14 +-
common/cmd_tpm.c | 122
drivers/tpm/Makefile |1 +
drivers/tpm/slb9635_i2c/tpm.c | 20 ++
drivers/tpm/slb9635_i2c/tpm.h |1 +
drivers/tpm/tis_i2c.c | 37 +++
drivers/tpm/tpm_i2c_st.c | 599
include/configs/omap3_beagle.h |8 +
include/tpm.h | 18 ++
9 files changed, 819 insertions(+), 1 deletion(-)
create mode 100644 drivers/tpm/tpm_i2c_st.c
diff --git a/README b/README
index 0d37d56..a72b570 100644
--- a/README
+++ b/README
@@ -1208,7 +1208,7 @@ The following options need to be configured:
If this option is set, the driver enables cache flush.
- TPM Support:
- CONFIG_GENERIC_LPC_TPM
+ CONFIG_TPM
Support for generic parallel port TPM devices. Only one device
per system is supported at this time.
@@ -1217,6 +1217,18 @@ The following options need to be configured:
to. Contemporary x86 systems usually map it at
0xfed4.
+ CONFIG_ST_TPM_I2C
+ Define to compile the ST TPM I2C DRIVER.
+
+ CONFIG_TPM_I2C_BUS
+ Define the bus number of the board.
+
+ CONFIG_TPM_I2C_ADDR
+ Define the address of the TPM.
+
+ CONFIG_CMD_TPM
+ Define to use some TPM u-boot commands.
+
- USB Support:
At the moment only the UHCI host controller is
supported (PIP405, MIP405, MPC5200); define
diff --git a/common/cmd_tpm.c b/common/cmd_tpm.c
index 46fae18..fba1fe7 100644
--- a/common/cmd_tpm.c
+++ b/common/cmd_tpm.c
@@ -27,6 +27,14 @@
#include
#include
+#define MAX_TRANSACTION_SIZE 30
+#define CHECK(exp) do {
\
+ int _rv = exp; \
+ if (_rv) { \
+ printf("CHECK: %s %d %x\n", #exp, __LINE__, _rv);\
+ } \
+ } while (0)
+
/**
* Print a byte string in hexdecimal format, 16-bytes per line.
*
@@ -546,6 +554,118 @@ static int do_tpm_nv_write(cmd_tbl_t *cmdtp, int flag,
return convert_return_code(err);
}
+static int do_tpm_hash(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+ u8 tpm_buffer[MAX_TRANSACTION_SIZE];
+ u32 write_size, read_size;
+ char *p;
+ int rv = -1;
+ argc -= 1;
+ argv += 1;
+ uint8_t response[1024];
+ size_t rlength = MAX_TRANSACTION_SIZE;
+
+ u8 startup[] = {
+ 0x00, 0xc1,
+ 0x00, 0x00, 0x00, 0x0c,
+ 0x00, 0x00, 0x00, 0x99,
+ 0x00, 0x01
+ };
+
+ u8 selftestfull[] = {
+ 0x00, 0xc1,
+ 0x00, 0x00, 0x00, 0x0a,
+ 0x00, 0x00, 0x00, 0x50
+ };
+
+ u8 readpcr17[] = {
+ 0x00, 0xc1,
+ 0x00, 0x00, 0x00, 0x0e,
+ 0x00, 0x00, 0x00, 0x15,
+ 0x00, 0x00, 0x00, 0x11
+ };
+
+ for (write_size = 0; write_size < argc; write_size++) {
+ u32 datum = kstrtoul(argv[write_size], &p, 0);
+ if (*p || (datum > 0xff)) {
+ printf("\n%s: bad data value\n\n", argv[write_size]);
+ cmd_usage(cmdtp);
+ return rv;
+ }
+ tpm_buffer[write_size] = (u8)datum;
+ }
+
+ if (tis_init()) {
+ puts("tis_init() failed!\n");
+ return -1;
+ }
+
+ if (tis_open()) {
+ puts("tis_open() failed!\n");
+ return -1;
+ }
+
+ rv = tis_sendrecv(startup, sizeof(startup), response, &rlength);
+ if (rv) {
+ printf("tpm test startup failed\n");
+ CHECK(tis_close());
+ }
+
+ rv = tis_sendrecv(selftestfull, sizeof(selftestfull), response,
+&rlength);
+ if (rv) {
+ printf("tpm test selftestfull failed\n");
+ CHECK(tis_close());
+ }
+
+ if (!
+ tis_sendrecv(readpcr17, sizeof(readpcr17), response, &read_size)) {
+ int i;
+
Re: [U-Boot] [PATCH v3] Add support for Congatec Conga-QEVAl board
Le Wednesday 15 May 2013 15:46:49, Otavio Salvador a écrit : > On Wed, May 15, 2013 at 10:36 AM, SARTRE Leo > > wrote: > > Add minimal support (only boot from mmc device) for the Congatec > > Conga-QEVAl Evaluation Carrier Board with conga-Qmx6q (i.MX6 Quad > > processor) module. > > > > Signed-off-by: Leo Sartre > > --- > > > > Changes in v3: > > -Files where moved to cgtqmx6eval. > > -MX6Q macro is passed in config as it is done for the > > wandboard. > > > > Thanks Otavio for these advices. > > > > MAINTAINERS |4 + > > board/congatec/cgtqmx6eval/Makefile | 42 +++ > > board/congatec/cgtqmx6eval/README| 28 + > > board/congatec/cgtqmx6eval/cgtqmx6eval.c | 178 > > +++ boards.cfg | > >1 + > > include/configs/cgtqmx6eval.h| 197 > > ++ 6 files changed, 450 insertions(+) > > create mode 100644 board/congatec/cgtqmx6eval/Makefile > > create mode 100644 board/congatec/cgtqmx6eval/README > > create mode 100644 board/congatec/cgtqmx6eval/cgtqmx6eval.c > > create mode 100644 include/configs/cgtqmx6eval.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 643a5ac..b61484b 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -889,6 +889,10 @@ Steve Sakoman > > > > omap3_overo ARM ARMV7 (OMAP3xx SoC) > > > > +Leo Sartre > > + > > + cgtqmx6qi.MX6Q > > + > > > > Jens Scharsig > > > > eb_cpux9k2 ARM920T (AT91RM9200 SoC) > > > > diff --git a/board/congatec/cgtqmx6eval/Makefile > > b/board/congatec/cgtqmx6eval/Makefile new file mode 100644 > > index 000..ac16c1f > > --- /dev/null > > +++ b/board/congatec/cgtqmx6eval/Makefile > > @@ -0,0 +1,42 @@ > > +# > > +# Copyright (C) 2007, Guennadi Liakhovetski > > +# > > +# (C) Copyright 2011 Freescale Semiconductor, Inc. > > +# (C) Copyright 2013 Adeneo Embedded > > +# > > +# This program is free software; you can redistribute it and/or > > +# modify it under the terms of the GNU General Public License as > > +# published by the Free Software Foundation; either version 2 of > > +# the License, or (at your option) any later version. > > +# > > +# This program is distributed in the hope that it will be useful, > > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > +# GNU General Public License for more details. > > +# > > +# You should have received a copy of the GNU General Public License > > +# along with this program; if not, write to the Free Software > > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > > +# MA 02111-1307 USA > > +# > > + > > +include $(TOPDIR)/config.mk > > + > > +LIB= $(obj)lib$(BOARD).o > > + > > +COBJS := cgtqmx6eval.o > > + > > +SRCS := $(COBJS:.o=.c) > > +OBJS := $(addprefix $(obj),$(COBJS)) > > + > > +$(LIB):$(obj).depend $(OBJS) > > + $(call cmd_link_o_target, $(OBJS)) > > + > > + > > # + > > +# defines $(obj).depend target > > +include $(SRCTREE)/rules.mk > > + > > +sinclude $(obj).depend > > + > > + > > # diff --git a/board/congatec/cgtqmx6eval/README > > b/board/congatec/cgtqmx6eval/README new file mode 100644 > > index 000..31162e2 > > --- /dev/null > > +++ b/board/congatec/cgtqmx6eval/README > > @@ -0,0 +1,28 @@ > > +U-Boot for the Congatec Conga-QEVAl Evaluation Carrier board > > + > > +This file contains information for the port of U-Boot to the Congatec > > +Conga-QEVAl Evaluation Carrier board. > > + > > +1. Boot source, boot from SD card > > +- > > + > > +This version of u-boot works only on the SD card. By default, the > > +Congatec board can boot only from the SPI-NOR. > > +But, with the u-boot version provided with the board you can write boot > > +registers to force the board to reboot and boot from the SD slot. If > > +"bmode" command is not available from your pre-installed u-boot, these > > +instruction will produce the same effect: > > + > > +conga-QMX6 U-Boot > mw.l 0x20d8040 0x3850 > > +conga-QMX6 U-Boot > mw.l 0x020d8044 0x1000 > > +conga-QMX6 U-Boot > reset > > +resetting ... > > + > > +The the board will reboot and, if you have written your SD correctly > > +the board will use u-boot that live into the SD > > + > > +To copy the resulting u-boot.imx to the SD card: > > + > > + dd if=u-boot.imx of=/dev/xxx bs=512 seek=2 > > + > > +Note: Replace xxx with the device representing the SD card in your > > system. diff --git a/board/congatec/cgtqmx6eval/cgtqmx6eval.c > > b/board/congatec/cgtqmx6eval/cgtqmx6eval.c new file mode 100644 > > index 000..e5d2adb > > --- /dev/null > > +++ b/board/congatec/cgtqmx6eval/cgtqmx6eval.c > > @@ -0,0 +1,178 @
Re: [U-Boot] [PATCH v3] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL
On Wed, May 15, 2013 at 10:15:28AM +0800, ying.zh...@freescale.com wrote: > From: Ying Zhang > > There will need the environment in SPL for reasons other than network > support (in particular, hwconfig contains info for how to set up DDR). > > Add a new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT > for environment in common/Makefile. > > Signed-off-by: Ying Zhang [snip] > # environment > @@ -67,7 +66,6 @@ COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o > COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o > COBJS-$(CONFIG_ENV_IS_IN_REMOTE) += env_remote.o > COBJS-$(CONFIG_ENV_IS_IN_UBI) += env_ubi.o > -COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o You need to move all of these options down so that adding them to SPL later, as needed, doesn't have further deltas, and to keep things organized still. > # command > COBJS-$(CONFIG_CMD_AMBAPP) += cmd_ambapp.o > @@ -215,18 +213,16 @@ COBJS-$(CONFIG_CMD_GPT) += cmd_gpt.o > endif > > ifdef CONFIG_SPL_BUILD > -COBJS-y += cmd_nvedit.o > -COBJS-y += env_common.o > COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o This CONFIG_ENV_IS_IN_FLASH is now duplicated and needs to be removed, when you move all of the other CONFIG_ENV_IS_... down to the always part of the Makefile. [snip] > diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h > index ef00306..f47d3d1 100644 > --- a/include/configs/am335x_evm.h > +++ b/include/configs/am335x_evm.h > @@ -325,6 +325,7 @@ > #define CONFIG_SPL_GPIO_SUPPORT > #define CONFIG_SPL_YMODEM_SUPPORT > #define CONFIG_SPL_NET_SUPPORT > +#define CONFIG_SPL_ENV_SUPPORT > #define CONFIG_SPL_NET_VCI_STRING"AM335x U-Boot SPL" > #define CONFIG_SPL_ETH_SUPPORT > #define CONFIG_SPL_SPI_SUPPORT > diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h > index d0ea74e..926842f 100644 > --- a/include/configs/pcm051.h > +++ b/include/configs/pcm051.h > @@ -224,6 +224,7 @@ > #define CONFIG_SPL_GPIO_SUPPORT > #define CONFIG_SPL_YMODEM_SUPPORT > #define CONFIG_SPL_NET_SUPPORT > +#define CONFIG_SPL_ENV_SUPPORT > #define CONFIG_SPL_NET_VCI_STRING"pcm051 U-Boot SPL" > #define CONFIG_SPL_ETH_SUPPORT > #define CONFIG_SPL_SPI_SUPPORT Have you made sure these two boards still compile? I bet they don't as they aren't setting CONFIG_ENV_IS_NOWHERE for SPL and CONFIG_ENV_IS_...somewhere-else for non-SPL. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] OMAP3+: introduce generic ABB support
On Wed, May 15, 2013 at 03:42:45PM +0300, Andrii Tseglytskyi wrote: > Hi, > > Tom, Nishant, could you please review this series ? Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [systemd-devel] 2013 Plumber's CFP: Fastboot
On Wed, May 15, 2013 at 9:50 AM, Lennart Poettering wrote: > On Wed, 15.05.13 11:43, Jeremiah Foster (jeremiah.fos...@pelagicore.com) > wrote: > >> On Tue, May 14, 2013 at 1:51 AM, Mehaffey, John >> wrote: >> >> > Hello All, >> > >> >> Hey John! >> >> >> > I am proposing a microconference on fastboot at the Linux Plumber's >> > conference 2013 in New Orleans. The goal is to get to sub 1S boot times for >> > a large (IVI) system using NAND flash. This pushes the state of the art, >> > and will require innovative solutions in may areas of Linux plumbing, >> > including bootloader, kernel init, UBI, and systemd. >> > >> > Note that fastboot improvements will (generally) help all architectures so >> > I am not limiting this to automotive systems. >> > >> > Please visit http://wiki.linuxplumbersconf.org/2013:fastboot for more >> > information or if you want to submit a topic. >> > >> >> I've linked to your micrconference from the automotive microconference: >> http://wiki.linuxplumbersconf.org/2013:automotive >> >> I'm a bit confused about the LPC format though. John, is it planned to have >> the non-Android fastboot discussion as part of the automotive >> microconference or is this separate (despite its automotive relevance.) I >> ask because it might be nice to have the participants in both >> microconferences and it would be a shame to lose attendees to one or the >> other if they're competing tracks. >> >> Can someone clue me in to the microconference format as regards LPC? > > > BTW, there's also this MC we proposed: > > http://wiki.linuxplumbersconf.org/2013:boot_and_core_os > > which sounds pretty close to fastboot? > What if we merge the proposals? John, are you ok with proposing (some of) these topics in the "Boot and Core OS" track? I could help with the module-related part, too. Lucas De Marchi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere
Hi Tom, On Tue, May 14, 2013 at 3:28 PM, Tom Rini wrote: > On Tue, May 14, 2013 at 03:22:04PM -0700, Vadim Bendebury wrote: >> On Tue, May 14, 2013 at 3:15 PM, Tom Rini wrote: >> > On Tue, May 14, 2013 at 02:27:32PM -0700, Simon Glass wrote: >> >> Hi Tom, >> >> >> >> On Tue, May 14, 2013 at 2:21 PM, Tom Rini wrote: >> >> > On Mon, May 13, 2013 at 03:12:07PM -0700, Simon Glass wrote: >> >> >> Hi Tom, >> >> >> >> >> >> On Thu, Mar 21, 2013 at 7:38 AM, Tom Rini wrote: >> >> >> > On Tue, Feb 26, 2013 at 08:10:53AM -0800, Simon Glass wrote: >> >> >> > >> >> >> >> Many parts of the U-Boot code base are sprinkled with #ifdefs. This >> >> >> >> makes >> >> >> >> different boards compile different versions of the source code, >> >> >> >> meaning >> >> >> >> that we must build all boards to check for failures. It is easy to >> >> >> >> misspell >> >> >> >> an #ifdef and there is not as much checking of this by the >> >> >> >> compiler. Multiple >> >> >> >> dependent #ifdefs are harder to do than with if..then..else. >> >> >> >> Variable >> >> >> >> declarations must be #idefed as well as the code that uses them, >> >> >> >> often much >> >> >> >> later in the file/function. #ifdef indents don't match code indents >> >> >> >> and >> >> >> >> have their own separate indent feature. Overall, excessive use of >> >> >> >> #idef >> >> >> >> hurts readability and makes the code harder to modify and refactor. >> >> >> >> For >> >> >> >> people coming newly into the code base, #ifdefs can be a big >> >> >> >> barrier. >> >> >> >> >> >> >> >> The use of #ifdef in U-Boot has possibly got a little out of hand. >> >> >> >> In an >> >> >> >> attempt to turn the tide, this series includes a patch which >> >> >> >> provides a way >> >> >> >> to make CONFIG macros available to C code without using the >> >> >> >> preprocessor. >> >> >> >> This makes it possible to use standard C conditional features such >> >> >> >> as >> >> >> >> if/then instead of #ifdef. A README update exhorts compliance. >> >> >> > >> >> >> > OK, this is true. Looking over the series, a number of the patches >> >> >> > are >> >> >> > just general fixes / improvements that don't depend on the >> >> >> > autoconf_... >> >> >> > work. Lets split this out now and take them in now as they seem like >> >> >> > reviewable by inspection code. >> >> >> >> >> >> Well sorry I didn't make time to get this done last time. I can do >> >> >> this now or... >> >> >> >> >> >> > >> >> >> > For the approach itself, I'm not sure which is best here. In a lot >> >> >> > of >> >> >> > cases we're trading an #ifdef for adding a level of indent to already >> >> >> > pretty indented code and that feels like a wash, in terms of >> >> >> > readability >> >> >> > to me. We probably need to re-factor some of the code in question >> >> >> > there >> >> >> > too for readability, then see about using autoconf_... type things, >> >> >> > or >> >> >> > maybe something else. >> >> >> >> >> >> I think you are saying to do the rearrangement and clean-up first, >> >> >> then add autoconf afterwards. I can do that but really I am wondering >> >> >> what you think of the autoconf concept? The Kconfig stuff is related >> >> >> here too, but first I would like to decide on what to do with the >> >> >> #ifdefs. >> >> > >> >> > I think a lot of our #ifdefery is a problem of code that's in need of >> >> > some love and re-org and cleaning and updating. One of the old style >> >> > rules I still try and follow is that after a few levels of indent code >> >> > doesn't read well. Also big nested #ifdefs don't read well. So we're >> >> > trading one in for the other. But your series showed a lot of places >> >> > where we can re-factor things to improve readability. So lets go that >> >> > way. Then we can see if there's still things to improve on, and what >> >> > dead code we still have around. >> >> >> >> So are you saying that you are keen on the autoconf idea? >> > >> > I'm saying lets clean up the code and see if we still need something >> > like autoconf. It seems to provide the most benefit in terms of >> > readability in places that could read a lot better with some clean up >> > and refactoring before we add new tools to the pile. >> > >> >> Yet another great advantage of autoconf is that it ensures a >> consistent combination of the configuration options, with the status >> quo it is so easy to make a mistake and create a deficient >> configuration. > > There are things I like about the concept, but I really want to see the > problem areas in question made more readable as it will both help in > general, and if we do make this conversion later, make the conversion > easier as we'll hopefully kill off some of the nested and tricky ifdefs. I've brought over the patches that I can that don't depend on autoconf: 6c0e6c9 (HEAD, ws/us-config5, us-config5) main: Add debug_bootkeys to avoid #ifdefs 9777b9f main: Add debug_parser() to avoid #ifdefs 2fc85b6 main: Correct
Re: [U-Boot] 答复: [PATCH v2 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
On 15/05/2013 15:55, Wang Huan-B18965 wrote: > > Hi, Stefano, > > Vybrid MVF600 is a dual-core eMPU combining the ARM Cortex A5 and > Cortex M4 cores. > Cortex A5 is a processor core designed by implementing the ARM v7 instruction > set architecture. > So I put the codes in the armv7 directory. Ok, got it. Then it is fine to have in armv7 directory. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc and fat bug fixes
This patch fixes a number of mmc and fat-related bugs:
> Added a check for blkcnt > 0 in mmc_write_blocks (drivers/mmc.c) to prevent a
> hangup for further mmc commands.
> Solved a checksum issue in fs/fat/fat.c. The mkcksum has const char arguments
> with a size specifier, like "const char name[8]". In the function, it is
> assumed that sizeof(name) will have the value 8, but this is not the case (at
> least not for the Sourcery CodeBench compiler and probably not according to
> ANSI C). This causes "long filename checksum errors" for each fat file listed
> or written.
> Made some changes to fs/fat/fat_write.c. Fixed testing fat_val for
> 0x/0xfff8 and 0xfff/0xff8 by adding the corresponding fatsize in
> the test (as read in earlier posts) and some changes in debug output.
Signed-off-by: Ruud Commandeur
Cc: Tom Rini
Cc: Benoît Thébaudeau
Cc: Mats Karrman
Index: drivers/mmc/mmc.c
===
--- drivers/mmc/mmc.c (revision 9)
+++ drivers/mmc/mmc.c (working copy)
@@ -282,8 +282,9 @@
if (blkcnt > 1)
cmd.cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK;
- else
+ else if (blkcnt > 0)
cmd.cmdidx = MMC_CMD_WRITE_SINGLE_BLOCK;
+ else return 0; //Called with blkcnt = 0
if (mmc->high_capacity)
cmd.cmdarg = start;
Index: fs/fat/fat.c
===
--- fs/fat/fat.c(revision 9)
+++ fs/fat/fat.c(working copy)
@@ -569,10 +569,12 @@
__u8 ret = 0;
- for (i = 0; i < sizeof(name); i++)
+ for (i = 0; i < 8; i++) {
ret = (((ret & 1) << 7) | ((ret & 0xfe) >> 1)) + name[i];
- for (i = 0; i < sizeof(ext); i++)
+ }
+ for (i = 0; i < 3; i++) {
ret = (((ret & 1) << 7) | ((ret & 0xfe) >> 1)) + ext[i];
+ }
return ret;
}
Index: fs/fat/fat_write.c
===
--- fs/fat/fat_write.c (revision 9)
+++ fs/fat/fat_write.c (working copy)
@@ -41,6 +41,7 @@
}
static int total_sector;
+
static int disk_write(__u32 block, __u32 nr_blocks, void *buf)
{
if (!cur_dev || !cur_dev->block_write)
@@ -104,8 +105,7 @@
} else
memcpy(dirent->ext, s_name + period_location + 1, 3);
- debug("name : %s\n", dirent->name);
- debug("ext : %s\n", dirent->ext);
+ debug("name.ext : %.8s.%.3s\n", dirent->name, dirent->ext);
}
static __u8 num_of_fats;
@@ -264,6 +264,7 @@
goto name0_4;
}
slotptr->name0_4[j] = name[*idx];
+ slotptr->name0_4[j + 1] = 0x00;
(*idx)++;
end_idx++;
}
@@ -275,6 +276,7 @@
goto name5_10;
}
slotptr->name5_10[j] = name[*idx];
+ slotptr->name5_10[j + 1] = 0x00;
(*idx)++;
end_idx++;
}
@@ -286,6 +288,7 @@
goto name11_12;
}
slotptr->name11_12[j] = name[*idx];
+ slotptr->name11_12[j + 1] = 0x00;
(*idx)++;
end_idx++;
}
@@ -569,7 +572,7 @@
else
startsect = mydata->rootdir_sect;
- debug("clustnum: %d, startsect: %d\n", clustnum, startsect);
+ debug("clustnum: %d, startsect: %d, size %lu\n", clustnum, startsect,
size);
if (disk_write(startsect, size / mydata->sect_size, buffer) < 0) {
debug("Error writing data\n");
@@ -587,10 +590,7 @@
debug("Error writing data\n");
return -1;
}
-
- return 0;
}
-
return 0;
}
@@ -656,7 +656,8 @@
else
break;
- if (fat_val == 0xfff || fat_val == 0x)
+ if (((fat_val == 0xfff) && (mydata->fatsize == 32)) ||
+ ((fat_val == 0x) && (mydata->fatsize == 16)))
break;
entry = fat_val;
@@ -901,7 +902,8 @@
}
curclust = get_fatent_value(mydata, dir_curclust);
- if ((curclust >= 0xff8) || (curclust >= 0xfff8)) {
+ if (((curclust >= 0xff8) && (mydata->fatsize == 32)) ||
+ ((curclust >= 0xfff8) && (mydata->fatsize == 16))) {
empty_dentptr = dentptr;
return NULL;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] arm: mvf600: Add FEC support for Vybrid MVF600
Hi Stefano, Alison,
On Wednesday, May 15, 2013 10:15:35 AM, Stefano Babic wrote:
> On 14/05/2013 11:51, Alison Wang wrote:
> > This patch adds FEC support for Vybrid MVF600 platform.
> > Add code to use RMII for MVF600.
> >
> > Signed-off-by: Alison Wang
> > ---
> > Changes in v2:
> > - Use common FEC driver fec_mxc.c
> >
> > drivers/net/fec_mxc.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> > index 4dbcdca..21e58f4 100644
> > --- a/drivers/net/fec_mxc.c
> > +++ b/drivers/net/fec_mxc.c
> > @@ -518,7 +518,11 @@ static int fec_open(struct eth_device *edev)
> > u32 ecr = readl(&fec->eth->ecntrl) & ~FEC_ECNTRL_SPEED;
> > u32 rcr = (readl(&fec->eth->r_cntrl) &
> > ~(FEC_RCNTRL_RMII | FEC_RCNTRL_RMII_10T)) |
> > - FEC_RCNTRL_RGMII | FEC_RCNTRL_MII_MODE;
> > + FEC_RCNTRL_MII_MODE;
> > + if (fec->xcv_type == RGMII)
> > + rcr |= FEC_RCNTRL_RGMII;
> > + else if (fec->xcv_type == RMII)
> > + rcr |= FEC_RCNTRL_RMII;
> > if (speed == _1000BASET)
> > ecr |= FEC_ECNTRL_SPEED;
> > else if (speed != _100BASET)
> >
>
> This can generally be applied, it is not only related to the new SOC.
>
> Acked-by: Stefano Babic
This is already done in fec_reg_setup(), so the piece of code above could
perhaps just leave untouched the FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII /
FEC_RCNTRL_MII_MODE bits, i.e.:
---
#ifdef FEC_QUIRK_ENET_MAC
{
u32 ecr = readl(&fec->eth->ecntrl) & ~FEC_ECNTRL_SPEED;
- u32 rcr = (readl(&fec->eth->r_cntrl) &
- ~(FEC_RCNTRL_RMII | FEC_RCNTRL_RMII_10T)) |
- FEC_RCNTRL_RGMII | FEC_RCNTRL_MII_MODE;
+ u32 rcr = readl(&fec->eth->r_cntrl) & ~FEC_RCNTRL_RMII_10T;
if (speed == _1000BASET)
ecr |= FEC_ECNTRL_SPEED;
else if (speed != _100BASET)
---
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
OK, thanks. On 15/05/13 16:43, Tom Rini wrote: > On Wed, May 15, 2013 at 04:10:46PM +0300, Lubomir Popov wrote: >> Hi Sricharan, Tom, > [snip] >> Now on USB in general: u-boot-ti master lags behind mainline master in >> respect to >> drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old >> .../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then >> Tom >> does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom? > > The patch still git am's fine on master (just checked), so it's OK > as-is. > Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for cpu_init_crit
On 05/14/2013 09:04 PM, Axel Lin wrote: > cpu_init_crit() can be skipped, but the code is still enabled requiring a > platform to supply lowlevel_init(). > diff --git a/arch/arm/cpu/arm720t/start.S b/arch/arm/cpu/arm720t/start.S > +#ifndef CONFIG_SKIP_LOWLEVEL_INIT > cpu_init_crit: > > #if !defined(CONFIG_TEGRA) > @@ -258,6 +259,7 @@ cpu_init_crit: > #endif > > mov pc, lr > +#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ If you're going to make changes here, you should probably ensure that Tegra is setting CONFIG_SKIP_LOWLEVEL_INIT, and then remove the Tegra-specific ifdef from the body of that function. That's assuming that setting CONFIG_SKIP_LOWLEVEL_INIT doesn't have any other side-effects. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP5: Enable access to auxclk registers
auxclk0 and auxclk1 are utilized on some OMAP5 boards.
Define the infrastructure needed for accessing them
without using magic numbers.
Also remove unrelated TPS62361 defines from clocks.h
Signed-off-by: Lubomir Popov
---
arch/arm/cpu/armv7/omap5/prcm-regs.c |8
arch/arm/include/asm/arch-omap5/clocks.h | 32 ++
arch/arm/include/asm/omap_common.h |4
3 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index e9f6a32..5ba9bc4 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -307,6 +307,10 @@ struct prcm_regs const omap5_es1_prcm = {
.prm_sldo_mpu_ctrl = 0x4ae07bd0,
.prm_sldo_mm_setup = 0x4ae07bd4,
.prm_sldo_mm_ctrl = 0x4ae07bd8,
+
+ /* SCRM stuff, used by some boards */
+ .scrm_auxclk0 = 0x4ae0a310,
+ .scrm_auxclk1 = 0x4ae0a314,
};
struct omap_sys_ctrl_regs const omap5_ctrl = {
@@ -740,6 +744,10 @@ struct prcm_regs const omap5_es2_prcm = {
.prm_sldo_mpu_ctrl = 0x4ae07cd0,
.prm_sldo_mm_setup = 0x4ae07cd4,
.prm_sldo_mm_ctrl = 0x4ae07cd8,
+
+ /* SCRM stuff, used by some boards */
+ .scrm_auxclk0 = 0x4ae0a310,
+ .scrm_auxclk1 = 0x4ae0a314,
};
struct prcm_regs const dra7xx_prcm = {
diff --git a/arch/arm/include/asm/arch-omap5/clocks.h
b/arch/arm/include/asm/arch-omap5/clocks.h
index 68afa76..6e23b1e 100644
--- a/arch/arm/include/asm/arch-omap5/clocks.h
+++ b/arch/arm/include/asm/arch-omap5/clocks.h
@@ -195,9 +195,9 @@
#define RSTTIME1_MASK (0x3ff << 0)
/* Clock frequencies */
-#define OMAP_SYS_CLK_FREQ_38_4_MHZ 3840
+#define OMAP_SYS_CLK_FREQ_38_4_MHZ 3840/* Not used; remove? */
#define OMAP_SYS_CLK_IND_38_4_MHZ 6
-#define OMAP_32K_CLK_FREQ 32768
+#define OMAP_32K_CLK_FREQ 32768 /* Not used; remove? */
/* PRM_VC_VAL_BYPASS */
#define PRM_VC_I2C_CHANNEL_FREQ_KHZ400
@@ -232,21 +232,6 @@
/* Standard offset is 0.5v expressed in uv */
#define PALMAS_SMPS_BASE_VOLT_UV 50
-/* TPS */
-#define TPS62361_I2C_SLAVE_ADDR0x60
-#define TPS62361_REG_ADDR_SET0 0x0
-#define TPS62361_REG_ADDR_SET1 0x1
-#define TPS62361_REG_ADDR_SET2 0x2
-#define TPS62361_REG_ADDR_SET3 0x3
-#define TPS62361_REG_ADDR_CTRL 0x4
-#define TPS62361_REG_ADDR_TEMP 0x5
-#define TPS62361_REG_ADDR_RMP_CTRL 0x6
-#define TPS62361_REG_ADDR_CHIP_ID 0x8
-#define TPS62361_REG_ADDR_CHIP_ID_20x9
-
-#define TPS62361_BASE_VOLT_MV 500
-#define TPS62361_VSEL0_GPIO7
-
/* Defines for DPLL setup */
#define DPLL_LOCKED_FREQ_TOLERANCE_0 0
#define DPLL_LOCKED_FREQ_TOLERANCE_500_KHZ 500
@@ -261,4 +246,17 @@
* into microsec and passing the value.
*/
#define CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC31219
+
+/* AUXCLKx reg fields */
+#define AUXCLK_ENABLE_MASK (1 << 8)
+#define AUXCLK_SRCSELECT_SHIFT 1
+#define AUXCLK_SRCSELECT_MASK (3 << 1)
+#define AUXCLK_CLKDIV_SHIFT16
+#define AUXCLK_CLKDIV_MASK (0xF << 16)
+
+#define AUXCLK_SRCSELECT_SYS_CLK 0
+#define AUXCLK_SRCSELECT_CORE_DPLL 1
+#define AUXCLK_SRCSELECT_PER_DPLL 2
+#define AUXCLK_SRCSELECT_ALTERNATE 3
+
#endif /* _CLOCKS_OMAP5_H_ */
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index ee7b188..76f65ed 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -346,6 +346,10 @@ struct prcm_regs {
u32 cm_l3init_usbphy_clkctrl;
u32 cm_l4per_mcbsp4_clkctrl;
u32 prm_vc_cfg_channel;
+
+ /* SCRM stuff, used by some boards */
+ u32 scrm_auxclk0;
+ u32 scrm_auxclk1;
};
struct omap_sys_ctrl_regs {
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] OMAP5: Power: Add more functionality to Palmas driver
Add some useful functions, and the corresponding definitions.
Signed-off-by: Lubomir Popov
---
V2 aligns to changed PMIC name (and file names accordingly)
from twl6035 to Palmas and is based on current u-boot-ti
master.
drivers/power/palmas.c | 108 ++--
include/palmas.h | 81 +---
2 files changed, 171 insertions(+), 18 deletions(-)
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..1f9bd7e 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -25,28 +25,112 @@
void palmas_init_settings(void)
{
- return;
+#ifdef CONFIG_PALMAS_SMPS7_FPWM
+ int err;
+ /*
+* Set SMPS7 (1.8 V I/O supply) to forced PWM mode.
+* This reduces noise (but affects efficiency).
+*/
+ u8 val = SMPS_MODE_SLP_FPWM | SMPS_MODE_ACT_FPWM;
+ if ((err = palmas_i2c_write_u8(PALMAS_CHIP_P1, SMPS7_CTRL, val)))
+ printf("palmas: Could not force PWM for SMPS7: err = %d\n",
err);
+#endif
}
int palmas_mmc1_poweron_ldo(void)
{
u8 val = 0;
- /* set LDO9 TWL6035 to 3V */
- val = 0x2b; /* (3 -.9)*28 +1 */
-
- if (palmas_i2c_write_u8(0x48, LDO9_VOLTAGE, val)) {
- printf("twl6035: could not set LDO9 voltage.\n");
+ /* Set Palmas LDO9 to 3.0 V */
+ val = LDO_VOLT_3V0;
+ if (palmas_i2c_write_u8(PALMAS_CHIP_P1, LDO9_VOLTAGE, val)) {
+ printf("palmas: could not set LDO9 voltage.\n");
return 1;
}
-
/* TURN ON LDO9 */
- val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
-
- if (palmas_i2c_write_u8(0x48, LDO9_CTRL, val)) {
- printf("twl6035: could not turn on LDO9.\n");
+ val = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ if (palmas_i2c_write_u8(PALMAS_CHIP_P1, LDO9_CTRL, val)) {
+ printf("palmas: could not turn on LDO9.\n");
return 1;
}
-
return 0;
}
+
+/*
+ * On some hardware the SD card socket and LDO9_IN are powered by an
+ * external 3.3 V regulator, while the output of LDO9 delivers VDDS_SDCARD
+ * for the OMAP interface only. This implies that LDO9 could be set to
+ * 'bypass' mode when required (e.g. for 3.3 V cards).
+ */
+int palmas_mmc1_set_ldo9(u8 vsel)
+{
+ u8 cval=0, vval=0; /* Off by default */
+ int err;
+
+ if (vsel) {
+ /* Turn on */
+ if (vsel > LDO_VOLT_3V3) {
+ /* Put LDO9 in bypass */
+ cval = LDO9_BYP_EN | RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ vval = LDO_VOLT_3V3;
+ }
+ else {
+ cval = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ vval = vsel & 0x3f;
+ }
+ }
+ if ((err = palmas_i2c_write_u8(PALMAS_CHIP_P1, LDO9_VOLTAGE, vval))) {
+ printf("palmas: could not set LDO9 %s: err = %d\n",
+ vsel > LDO_VOLT_3V3 ? "bypass" : "voltage", err);
+ return err;
+ }
+ if ((err = palmas_i2c_write_u8(PALMAS_CHIP_P1, LDO9_CTRL, cval)))
+ printf("palmas: could not turn %s LDO9: err = %d\n",
+ cval ? "on" : "off", err);
+ return err;
+}
+
+/* Turn audio codec power and 32 kHz clock on/off. Use for TWL604x only. */
+int palmas_audio_power(u8 on)
+{
+ u8 cval=0, vval=0, c32k=0;
+ int err;
+
+ if (on) {
+ vval = SMPS_VOLT_2V1;
+ cval = SMPS_MODE_SLP_AUTO | SMPS_MODE_ACT_AUTO;
+ c32k = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ }
+ /* Set SMPS9 to 2.1 V (for TWL604x), or to 0 (off) */
+ if ((err = palmas_i2c_write_u8(PALMAS_CHIP_P1, SMPS9_VOLTAGE, vval))) {
+ printf("palmas: could not set SMPS9 voltage: err = %d\n", err);
+ return err;
+ }
+ /* Turn on or off SMPS9 */
+ if ((err = palmas_i2c_write_u8(PALMAS_CHIP_P1, SMPS9_CTRL, cval))) {
+ printf("palmas: could not turn SMPS9 %s: err = %d\n",
+ cval ? "on" : "off", err);
+ return err;
+ }
+ /* Output 32 kHz clock on or off */
+ if ((err = palmas_i2c_write_u8(PALMAS_CHIP_P1, CLK32KGAUDIO_CTRL,
c32k)))
+ printf("palmas: could not turn CLK32KGAUDIO %s: err = %d\n",
+ c32k ? "on" : "off", err);
+ return err;
+}
+
+/*
+ * Enable/disable back-up battery (or super cap) charging.
+ * Please use defined BB_xxx values.
+ */
+int palmas_enable_bb_charge(u8 bb_fields)
+{
+ u8 val = bb_fields & 0x0f;
+ int err;
+
+ val |= (VRTC_EN_SLP | VRTC_EN_OFF | VRTC_PWEN);
+ if ((err = palmas_i2c_write_u8(PALMAS_CHIP_P1, BB_VRTC_CTRL, val)))
+ printf("palmas: could not set BB_VRTC_CTRL to 0x%02x: err =
%d\n", val, err);
+ return err;
+}
+
diff --git a/include/palmas.h b/include/palmas.h
Re: [U-Boot] [PATCH 4/5] arm: ensure u-boot only uses relative relocations
Hi Benoît, On Wed, 15 May 2013 15:49:10 +0200 (CEST), Benoît Thébaudeau wrote: > Hi Albert, > > On Wednesday, May 15, 2013 11:38:37 AM, Albert ARIBAUD wrote: > > Hi again Benoît, > > > > On Wed, 15 May 2013 09:46:17 +0200, Albert ARIBAUD > > wrote: > > > > > Hi Benoît, > > > > > > On Wed, 15 May 2013 00:12:24 +0200 (CEST), Benoît Thébaudeau > > > wrote: > > > > > > > Hi Albert, > > > > > > > > --- a/Makefile > > > > > +++ b/Makefile > > > > > @@ -746,6 +746,13 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE) > > > > > $(MAKE) -C $@ all > > > > > endif# config.mk > > > > > > > > > > +# ARM relocations should all be R_ARM_RELATIVE. > > > > > +checkarmreloc: $(obj)u-boot > > > > > + @if test "R_ARM_RELATIVE" != \ > > > > > + "`readelf -r $(obj)u-boot | cut -d ' ' -f 4 | grep > > > > > R_ARM | sort > > > > > -u`"; \ > > > > ^ > > > > or $$< to avoid a duplicate? > > > > > > Will fix as suggested. > > > > > > > + then echo "$(obj)u-boot contains relocations other than > > > > > \ > > > >^ > > > >or $$< too, or no $(obj) prefix at all for > > > >this message? > > > > > > I prefer leaving the prefix so that failures during out-of-tree builds > > > or during MAKEALL builds with BUILD_NBUILDS>1 log the correct path. > > > > Actually $$< does not work within backquotes unless escaped as a less > > legible \$\$<, and does not work properly at all within double quotes, > > whether escaped or not. > > > > Do you prefer that I change only the first $(obj)u-boot into \$\$< and > > leave the second one untouched, or that I leave both $(obj)u-boot > > instances as-is for the sake of homogeneity? > > Actually, a single dollar sign (i.e. "$<") would be needed since it must have > been expanded by make before reaching the shell, and no shell backslash escape > sequences should be required. > > If this still does not pass smoothly, then I prefer simplicity and > homogeneity. Single unescaped $< works like a charm within backward as well as double quotes, thanks! > Best regards, > Benoît Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [systemd-devel] 2013 Plumber's CFP: Fastboot
> From: Lucas De Marchi [lucas.de.mar...@gmail.com] > Sent: Wednesday, May 15, 2013 7:04 AM > > On Wed, May 15, 2013 at 9:50 AM, Lennart Poettering > wrote: > > On Wed, 15.05.13 11:43, Jeremiah Foster (jeremiah.fos...@pelagicore.com) > > wrote: > > > >> On Tue, May 14, 2013 at 1:51 AM, Mehaffey, John > >> wrote: > >> > >> > Hello All, > >> > > >> > >> Hey John! > >> > >> > >> > I am proposing a microconference on fastboot at the Linux Plumber's > >> > conference 2013 in New Orleans. The goal is to get to sub 1S boot times > >> > for > >> > a large (IVI) system using NAND flash. This pushes the state of the art, > >> > and will require innovative solutions in may areas of Linux plumbing, > >> > including bootloader, kernel init, UBI, and systemd. > >> > > >> > Note that fastboot improvements will (generally) help all architectures > >> > so > >> > I am not limiting this to automotive systems. > >> > > >> > Please visit http://wiki.linuxplumbersconf.org/2013:fastboot for more > >> > information or if you want to submit a topic. > >> > > >> > >> I've linked to your micrconference from the automotive microconference: > >> http://wiki.linuxplumbersconf.org/2013:automotive > >> > >> I'm a bit confused about the LPC format though. John, is it planned to have > >> the non-Android fastboot discussion as part of the automotive > >> microconference or is this separate (despite its automotive relevance.) I > >> ask because it might be nice to have the participants in both > >> microconferences and it would be a shame to lose attendees to one or the > >> other if they're competing tracks. > >> > >> Can someone clue me in to the microconference format as regards LPC? > > > > > > BTW, there's also this MC we proposed: > > > > http://wiki.linuxplumbersconf.org/2013:boot_and_core_os > > > > which sounds pretty close to fastboot? > > > > What if we merge the proposals? > > John, are you ok with proposing (some of) these topics in the "Boot > and Core OS" track? I could help with the module-related part, too. > > > Lucas De Marchi Hi Lucas, Lennart, I am fine with merging the two boot related sessions. I did not want to have it be a topic in the automotive microconf, as I believe there is enough material for a couple of hours on fastboot alone. It was not clear to me what topics might be in the boot and core os microconf, so I proposed fastboot as separate. Jeremiah, you bring up a good point about overlapping interest, probably when a proposal is accepted, we will need to point out potential scheduling conflicts with other accepted microconfs to the program committee. Sincerely, John Mehaffey Senior System Architect (Automotive) Mentor Graphics Corporation ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM v7: Flush icache when executing a program with go
Hi Henrik, On Tue, 14 May 2013 16:16:02 +0200, Henrik Nordström wrote: > Tom Rini wanted me to post this again. There is no change from previous > version. > > I do agree with Wolfgang Denk that this really SHOULD NOT be arch > specific. The only reason why I made this ARMv7 specific is because > blindly calling invalidate_icache_all() from the go command will cause > loud complains on other arches where the icache is not > supported/enabled. The question is what is the correct solution > > - Doing it arch specific like this (or other arch aproach?) > > - Change invalidate_icache_all() to be silent if the icache is not > enabled/supported? > > - Something else? What is the rationale behind putting it in arch/ rather than in common/ by adding this to the existing common/cmd_boot.c file under ARMv7 conditionals? Also: > ARM v7 runs with icache enabled. For reliable results the go command > needs to flush the icache before jumping or it may risk running > cached instructions that differ from what currently is in memory. IIUC, the issue is due to cache being enabled when doing the go, rather than due to armv7 per se. So, should we not have this icache flush conditioned at compile time on cache being compiled in, and at run time on cache being enabled? This way, we would automatically cater for the same issue appearing in other ARM CPUs, and even more, in other architectures. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx23-olinuxino: occasional memory errors
On Wed, May 15, 2013 at 6:49 AM, Kiril Zyapkov wrote: ... > The mini board, despite having R17 removed, shows occasional memory > errors, here are some: ... What about including R17 and giving it a go? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc and fat bug fixes
Hi Ruud,
On Wednesday, May 15, 2013 4:23:51 PM, Ruud Commandeur wrote:
> This patch fixes a number of mmc and fat-related bugs:
There should be only one logical change per patch.
>
> > Added a check for blkcnt > 0 in mmc_write_blocks (drivers/mmc.c) to prevent
> > a hangup for further mmc commands.
Adding Andy, the MMC custodian, to Cc.
>
> > Solved a checksum issue in fs/fat/fat.c. The mkcksum has const char
> > arguments with a size specifier, like "const char name[8]". In the
> > function, it is assumed that sizeof(name) will have the value 8, but this
> > is not the case (at least not for the Sourcery CodeBench compiler and
> > probably not according to ANSI C). This causes "long filename checksum
> > errors" for each fat file listed or written.
>
> > Made some changes to fs/fat/fat_write.c. Fixed testing fat_val for
> > 0x/0xfff8 and 0xfff/0xff8 by adding the corresponding fatsize
> > in the test (as read in earlier posts) and some changes in debug output.
Expressions like "as read in earlier posts" should not be present in a patch
description since it is unclear what it refers to once the patch has been
applied.
Line lengths should be at most 80 characters, including in the patch
description.
>
> Signed-off-by: Ruud Commandeur
> Cc: Tom Rini
> Cc: Benoît Thébaudeau
> Cc: Mats Karrman
>
> Index: drivers/mmc/mmc.c
> ===
> --- drivers/mmc/mmc.c (revision 9)
> +++ drivers/mmc/mmc.c (working copy)
> @@ -282,8 +282,9 @@
>
> if (blkcnt > 1)
> cmd.cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK;
> - else
> + else if (blkcnt > 0)
> cmd.cmdidx = MMC_CMD_WRITE_SINGLE_BLOCK;
> + else return 0; //Called with blkcnt = 0
The comment above is useless. Also, the comment style in U-Boot is /**/, not //.
>
> if (mmc->high_capacity)
> cmd.cmdarg = start;
> Index: fs/fat/fat.c
> ===
> --- fs/fat/fat.c (revision 9)
> +++ fs/fat/fat.c (working copy)
> @@ -569,10 +569,12 @@
>
> __u8 ret = 0;
>
> - for (i = 0; i < sizeof(name); i++)
> + for (i = 0; i < 8; i++) {
> ret = (((ret & 1) << 7) | ((ret & 0xfe) >> 1)) + name[i];
> - for (i = 0; i < sizeof(ext); i++)
> + }
> + for (i = 0; i < 3; i++) {
> ret = (((ret & 1) << 7) | ((ret & 0xfe) >> 1)) + ext[i];
> + }
>
> return ret;
> }
There should not be curly braces for single-line blocks.
Anyway, this has already been done by Marek in commit 6ad77d8, so this hunk
should be dropped.
> Index: fs/fat/fat_write.c
> ===
> --- fs/fat/fat_write.c(revision 9)
> +++ fs/fat/fat_write.c(working copy)
> @@ -41,6 +41,7 @@
> }
>
> static int total_sector;
> +
> static int disk_write(__u32 block, __u32 nr_blocks, void *buf)
> {
> if (!cur_dev || !cur_dev->block_write)
This hunk is not very useful.
> @@ -104,8 +105,7 @@
> } else
> memcpy(dirent->ext, s_name + period_location + 1, 3);
>
> - debug("name : %s\n", dirent->name);
> - debug("ext : %s\n", dirent->ext);
> + debug("name.ext : %.8s.%.3s\n", dirent->name, dirent->ext);
Correct. You could just remove the space before the colon since this is the
standard English formatting.
> }
>
> static __u8 num_of_fats;
> @@ -264,6 +264,7 @@
> goto name0_4;
> }
> slotptr->name0_4[j] = name[*idx];
> + slotptr->name0_4[j + 1] = 0x00;
> (*idx)++;
> end_idx++;
> }
> @@ -275,6 +276,7 @@
> goto name5_10;
> }
> slotptr->name5_10[j] = name[*idx];
> + slotptr->name5_10[j + 1] = 0x00;
> (*idx)++;
> end_idx++;
> }
> @@ -286,6 +288,7 @@
> goto name11_12;
> }
> slotptr->name11_12[j] = name[*idx];
> + slotptr->name11_12[j + 1] = 0x00;
> (*idx)++;
> end_idx++;
> }
These 3 hunks are correct, but they should be mentioned in the patch
description.
> @@ -569,7 +572,7 @@
> else
> startsect = mydata->rootdir_sect;
>
> - debug("clustnum: %d, startsect: %d\n", clustnum, startsect);
> + debug("clustnum: %d, startsect: %d, size %lu\n", clustnum, startsect,
> size);
Line too long: max 80 chars.
>
> if (disk_write(startsect, size / mydata->sect_size, buffer) < 0) {
> debug("Error writing data\n");
> @@ -587,10 +590,7 @@
> debug("Error writing data\n");
> return -1;
> }
> -
> - return 0;
OK.
> }
> -
This empty line would be better kept for code legibility.
> return 0;
> }
>
> @@ -656,7 +656,8 @@
> else
>
[U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
Prerequisites: appropriate patches to the USB EHCI and Eth
drivers, and to the OMAP5 clock register definitions.
Signed-off-by: Lubomir Popov
---
Assumption is that this code shall run on TI 750-2628-21X
hardware (also known as OMAP5432 ES2.0 PandaBoard5) - the
GPIOs that I used used for HSIC reset correspond to that
board. Looking at mux_data.h however, I'm somewhat concerned.
All the uevm board files are inherited from the sEVM, which
is a very different hardware platform, and I'm afraid that
only changing the file names might not be sufficient.
The patch is not tested yet due to lack of hardware. Tom,
I'm hoping for your assistance.
board/ti/omap5_uevm/evm.c| 59 +-
include/configs/omap5_uevm.h | 34 +++-
2 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 46db1bf..3144fba 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -26,13 +26,20 @@
#include
#include
#include
+#include
#include "mux_data.h"
+#ifdef CONFIG_USB_EHCI
+#include
+#include
+#include
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
const struct omap_sysinfo sysinfo = {
- "Board: OMAP5430 EVM\n"
+ "Board: OMAP5432 uEVM\n"
};
/**
@@ -99,3 +106,53 @@ int board_mmc_init(bd_t *bis)
return 0;
}
#endif
+
+#ifdef CONFIG_USB_EHCI
+static struct omap_usbhs_board_data usbhs_bdata = {
+ .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
+ .port_mode[1] = OMAP_EHCI_PORT_MODE_HSIC, /* USB3503 hub */
+ .port_mode[2] = OMAP_EHCI_PORT_MODE_HSIC, /* LAN9730 Ethernet */
+};
+
+int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor)
+{
+ int ret;
+
+ /* Enbale USB ports 2 & 3 UHH, UTMI and HSIC clocks */
+ setbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl,
+ USB_HOST_HS_CLKCTRL_EN);
+ /* Enbale USB host ports TLL clocks */
+ setbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl,
+ USB_TLL_HS_CLKCTRL_EN);
+
+ /*
+* The hub uses OMAP FREF_CLK1_OUT at 19.2 MHz. Use default source
+* (SYS_CLK) and default divider of 1, so just turn it on.
+*/
+ setbits_le32((*prcm)->scrm_auxclk1, AUXCLK_ENABLE_MASK);
+ udelay(1000); /* Let PLL lock */
+
+ ret = omap_ehci_hcd_init(&usbhs_bdata, hccr, hcor);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+int ehci_hcd_stop(void)
+{
+ int ret;
+
+ ret = omap_ehci_hcd_stop();
+
+ clrbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl,
+ USB_HOST_HS_CLKCTRL_EN);
+ clrbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl,
+ USB_TLL_HS_CLKCTRL_EN);
+
+ /* Stop FREF_CLK1_OUT */
+ clrbits_le32((*prcm)->scrm_auxclk1, AUXCLK_ENABLE_MASK);
+ return ret;
+}
+#endif /* CONFIG_USB_EHCI */
+
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index c791789..e15dd99 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -52,7 +52,39 @@
#define CONFIG_PARTITION_UUIDS
#define CONFIG_CMD_PART
-#define CONFIG_SYS_PROMPT "OMAP5430 EVM # "
+/* USB UHH support options */
+#define CONFIG_CMD_USB
+#define CONFIG_USB_HOST
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_OMAP
+#define CONFIG_USB_STORAGE
+#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3
+
+/*
+ * Due to OMAP5 HSIC connect ussues, device reset is required
+ * upon applying port power. A GPIO is needed per HSIC device:
+ */
+#define CONFIG_OMAP_HSIC_PORT2_RESET_GPIO 80 /* USB 3-port hub */
+#define CONFIG_OMAP_HSIC_PORT3_RESET_GPIO 79 /* Ethernet Ctrlr */
+
+/*
+ * Enable bit fields for USB ports 2 & 3 HS clocks setup in regs
+ * cm_l3init_hsusbhost_clkctrl and cm_l3init_hsusbtll_clkctrl:
+ */
+#define USB_HOST_HS_CLKCTRL_EN 0xd6c0
+#define USB_TLL_HS_CLKCTRL_EN 0x0600
+
+/* USB Networking options */
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_SMSC95XX
+
+/* Enabled commands */
+#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot */
+#define CONFIG_CMD_NFS /* NFS support */
+#define CONFIG_CMD_DHCP/* DHCP support */
+#define CONFIG_CMD_PING/* PING support */
+
+#define CONFIG_SYS_PROMPT "OMAP5432 uEVM # "
#define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296
#endif /* __CONFIG_OMAP5_EVM_H */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt_support: Use CONFIG_NR_DRAM_BANKS if defined
On Tue, Apr 30, 2013 at 2:14 PM, Tom Rini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/30/2013 04:49 PM, Doug Anderson wrote: >> Tom, >> >> On Tue, Apr 30, 2013 at 1:35 PM, Tom Rini wrote: >>> And I guess having this knowledge correct for the kernel is >>> useful in other contexts like when we want to power down some >>> banks of memory but not others? I mean, there's "lots" of >>> platforms that lie and say 1 bank since we require contiguous >>> mapping. Thanks! >> >> Thanks for the review! >> >> At the moment I'm _not_ convinced that there's a good reason to >> specify 8 banks. We appear to have lied and said 1 bank on >> exynos5250-snow (ARM Chromebook) and I don't know of any bad side >> effects. >> >> The code I'm looking at right now indicates 8 banks. We need to >> track down why someone did that but it doesn't seem totally crazy >> to allow specifying the proper number of banks so I figured I'd >> send this patch up. >> >> If you prefer, we can leave this patch hanging until we actually >> track down if specifying 8 banks was really needed. > > Yes please, lets hold. Thanks! > I looked into this a bit more, what happens on this particular target (Exynos5420 with 4GB DRAM onboard) is that out of 4GB of memory only 3.5GB is usable, as the lower .5 GB of address range is taken by the architecture, and the address bus width is 32 bits. U-boot code makes several assumptions: - bank size is a power of 2 - bank base is aligned with bank size - all bank sizes are the same with this in mind, the only way to describe our memory situation is to define 7 banks, .5GB each, the lowest one starting at 0x2000 (.5GB). This is not a big deal for u-boot (maybe very marginally inefficient when determining the actual memory size). Is this a big deal for kernel? I mean it is easy to squash these seven memory banks into one when filling out the memory node of the device tree, the question is is it even necessary? cheers --vb > - -- > Tom > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRgDQoAAoJENk4IS6UOR1WztkP+QEs7IvExh9Dq0AHrj81wQ9Q > Ml29BZGsdJ5mLIt6jhJ7HSr310cu3FODgbVuNt01Aj0Q2X+C1mCRYqhoIDwfcSUJ > EWVhUaphlmiBd2OrMH+3HPUwQ+kFfjt5LNFuXwRei0tgz+sy6NTQ+QZFuZ9FiBJD > UKtavOsvd3XipdklU5UEGoBj6OJxU6hBOyehZ3Cckwgfeg0L/1uV07Vd8kSFFc5e > xoWXN7O+QkdlNkWeruxPF7uq1MeM2VusCuvGWK4srrED+WSAKFhqsi7t3N66iNny > lXDhYPtuSr5HF5xua4kwWdbM/GneVd5m0p979TvIwvwhM1bMr00mfIoH9HEjzNF6 > Bvq0wcCwIEZLwBFNNpn9X9zIzwXIgUKbMqjHQXiuizY8LROdXXnkg53k9o2pDO5+ > uGO8cKZMXJYEU4zW+wbSlI/Cz7WoylsXhSBPfF5gkRSIxKtYmcS/iQn/nKMgebVO > TaGx76/r8xOvA5WY+wCs7HMEJip5UU00rG7MvjokwxOSUf/2rVHiDWl0MEAlh7M4 > 4KAMzb61P/fUiXrZv5K9Z6sgPmGynjItKnw0UigTWKG6DvRy0HuOlF//O8qAuWKH > +eyjg2F24pS9cGRMni3M9cUBH1W6secIpZkqs3goxeNVZyfb29kswolymfbcU4GC > zXmnz8gBTLDKGtTzLlXC > =s42z > -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
On 18:55-20130515, Lubomir Popov wrote:
> Prerequisites: appropriate patches to the USB EHCI and Eth
> drivers, and to the OMAP5 clock register definitions.
proper commit message is needed before this goes from RFC to patch.
>
> Signed-off-by: Lubomir Popov
> ---
> Assumption is that this code shall run on TI 750-2628-21X
> hardware (also known as OMAP5432 ES2.0 PandaBoard5) - the
uEVM - there is no PandaBoard5 in existence.
https://www.svtronics.com/index.php?route=product/product&product_id=33
Just a minor nit:
> const struct omap_sysinfo sysinfo = {
> - "Board: OMAP5430 EVM\n"
> + "Board: OMAP5432 uEVM\n"
nit: does not belong to this patch.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/9] at91: Correct CONFIG_AUTOBOOT_PROMPT definition for pm9263
This is not currently used, since autoboot is not enabled for this board, but the string is missing a parameter. Add it. Signed-off-by: Simon Glass --- Changes in v4: None Changes in v3: None include/configs/pm9263.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/pm9263.h b/include/configs/pm9263.h index b60a9ad..6f6ddfa 100644 --- a/include/configs/pm9263.h +++ b/include/configs/pm9263.h @@ -355,7 +355,7 @@ #define CONFIG_BOOTCOMMAND "run flashboot" #define CONFIG_ROOTPATH"/ronetix/rootfs" -#define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds\n" +#define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds\n", bootdelay #define CONFIG_CON_ROT "fbcon=rotate:3 " #define CONFIG_BOOTARGS"root=/dev/mtdblock4 rootfstype=jffs2 "\ -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/9] net: Add prototype for update_tftp
This function should be declared in net.h.
Signed-off-by: Simon Glass
---
Changes in v4:
- Removed autoconf() code for now
Changes in v3: None
common/cmd_fitupd.c | 3 +--
common/main.c | 4
include/net.h | 3 +++
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/common/cmd_fitupd.c b/common/cmd_fitupd.c
index 7a3789e..618ff7c 100644
--- a/common/cmd_fitupd.c
+++ b/common/cmd_fitupd.c
@@ -8,13 +8,12 @@
#include
#include
+#include
#if !defined(CONFIG_UPDATE_TFTP)
#error "CONFIG_UPDATE_TFTP required"
#endif
-extern int update_tftp(ulong addr);
-
static int do_fitupd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
ulong addr = 0UL;
diff --git a/common/main.c b/common/main.c
index 953ef29..9890184 100644
--- a/common/main.c
+++ b/common/main.c
@@ -57,10 +57,6 @@ DECLARE_GLOBAL_DATA_PTR;
void inline __show_boot_progress (int val) {}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
-#if defined(CONFIG_UPDATE_TFTP)
-int update_tftp (ulong addr);
-#endif /* CONFIG_UPDATE_TFTP */
-
#define MAX_DELAY_STOP_STR 32
#undef DEBUG_PARSER
diff --git a/include/net.h b/include/net.h
index 970d4d1..23fb947 100644
--- a/include/net.h
+++ b/include/net.h
@@ -695,6 +695,9 @@ extern void copy_filename(char *dst, const char *src, int
size);
/* get a random source port */
extern unsigned int random_port(void);
+/* Update U-Boot over TFTP */
+extern int update_tftp(ulong addr);
+
/**/
#endif /* __NET_H__ */
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/9] main: Separate out the two abortboot() functions
There are two implementations of abortboot(). Turn these into two separate
functions, and create a single abortboot() which calls either one or the
other.
Also it seems that nothing uses abortboot() outside main, so make it static.
At this point there is no further use of CONFIG_MENU in main.c.
Signed-off-by: Simon Glass
---
Changes in v4:
- Create a patch that moves the code but still uses #ifdef
Changes in v3:
- Fix commit message which said autoboot() instead of abortboot()
- Add note about CONFIG_MENU not being needed in main.c anymore
common/main.c| 19 +++
include/common.h | 3 ---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/common/main.c b/common/main.c
index 9890184..22ea8fd 100644
--- a/common/main.c
+++ b/common/main.c
@@ -89,10 +89,7 @@ extern void mdm_init(void); /* defined in board.c */
*/
#if defined(CONFIG_BOOTDELAY)
# if defined(CONFIG_AUTOBOOT_KEYED)
-#ifndef CONFIG_MENU
-static inline
-#endif
-int abortboot(int bootdelay)
+static int abortboot_keyed(int bootdelay)
{
int abort = 0;
uint64_t etime = endtick(bootdelay);
@@ -211,10 +208,7 @@ int abortboot(int bootdelay)
static int menukey = 0;
#endif
-#ifndef CONFIG_MENU
-static inline
-#endif
-int abortboot(int bootdelay)
+static int abortboot_normal(int bootdelay)
{
int abort = 0;
unsigned long ts;
@@ -271,6 +265,15 @@ int abortboot(int bootdelay)
return abort;
}
# endif/* CONFIG_AUTOBOOT_KEYED */
+
+static int abortboot(int bootdelay)
+{
+#ifdef CONFIG_AUTOBOOT_KEYED
+ return abortboot_keyed(bootdelay);
+#else
+ return abortboot_normal(bootdelay);
+#endif
+}
#endif /* CONFIG_BOOTDELAY */
/*
diff --git a/include/common.h b/include/common.h
index e682bd8..126891d 100644
--- a/include/common.h
+++ b/include/common.h
@@ -310,9 +310,6 @@ int readline_into_buffer(const char *const prompt, char
*buffer,
intparse_line (char *, char *[]);
void init_cmd_timeout(void);
void reset_cmd_timeout(void);
-#ifdef CONFIG_MENU
-intabortboot(int bootdelay);
-#endif
extern char console_buffer[];
/* arch/$(ARCH)/lib/board.c */
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/9] main: Use get/setenv_ulong()
These functions are now available, so use them to avoid extra code here.
Signed-off-by: Simon Glass
Reviewed-by: Joe Hershberger
---
Changes in v4: None
Changes in v3: None
common/main.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/common/main.c b/common/main.c
index 159b8e1..38fadac 100644
--- a/common/main.c
+++ b/common/main.c
@@ -352,18 +352,14 @@ static void process_boot_delay(void)
#ifdef CONFIG_BOOTCOUNT_LIMIT
unsigned long bootcount = 0;
unsigned long bootlimit = 0;
- char *bcs;
- char bcs_set[16];
#endif /* CONFIG_BOOTCOUNT_LIMIT */
#ifdef CONFIG_BOOTCOUNT_LIMIT
bootcount = bootcount_load();
bootcount++;
bootcount_store (bootcount);
- sprintf (bcs_set, "%lu", bootcount);
- setenv ("bootcount", bcs_set);
- bcs = getenv ("bootlimit");
- bootlimit = bcs ? simple_strtoul (bcs, NULL, 10) : 0;
+ setenv_ulong("bootcount", bootcount);
+ bootlimit = getenv_ulong("bootlimit", 10, 0);
#endif /* CONFIG_BOOTCOUNT_LIMIT */
s = getenv ("bootdelay");
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 8/9] main: Add debug_parser() to avoid #ifdefs
Define a simple debug condition at the top of the file, to avoid using
lots of #ifdefs later on.
Signed-off-by: Simon Glass
Reviewed-by: Joe Hershberger
---
Changes in v4: None
Changes in v3: None
common/main.c | 58 +++---
1 file changed, 23 insertions(+), 35 deletions(-)
diff --git a/common/main.c b/common/main.c
index e5173d7..fcce0f3 100644
--- a/common/main.c
+++ b/common/main.c
@@ -48,7 +48,11 @@ void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progre
#define MAX_DELAY_STOP_STR 32
-#undef DEBUG_PARSER
+#define DEBUG_PARSER 0 /* set to 1 to debug */
+
+#define debug_parser(fmt, args...) \
+ debug_cond(DEBUG_PARSER, fmt, ##args)
+
charconsole_buffer[CONFIG_SYS_CBSIZE + 1]; /* console I/O buffer
*/
@@ -1179,9 +1183,7 @@ int parse_line (char *line, char *argv[])
{
int nargs = 0;
-#ifdef DEBUG_PARSER
- printf ("parse_line: \"%s\"\n", line);
-#endif
+ debug_parser("parse_line: \"%s\"\n", line);
while (nargs < CONFIG_SYS_MAXARGS) {
/* skip any white space */
@@ -1190,10 +1192,8 @@ int parse_line (char *line, char *argv[])
if (*line == '\0') {/* end of line, no more args*/
argv[nargs] = NULL;
-#ifdef DEBUG_PARSER
- printf ("parse_line: nargs=%d\n", nargs);
-#endif
- return (nargs);
+ debug_parser("parse_line: nargs=%d\n", nargs);
+ return nargs;
}
argv[nargs++] = line; /* begin of argument string */
@@ -1204,10 +1204,8 @@ int parse_line (char *line, char *argv[])
if (*line == '\0') {/* end of line, no more args*/
argv[nargs] = NULL;
-#ifdef DEBUG_PARSER
- printf ("parse_line: nargs=%d\n", nargs);
-#endif
- return (nargs);
+ debug_parser("parse_line: nargs=%d\n", nargs);
+ return nargs;
}
*line++ = '\0'; /* terminate current arg */
@@ -1215,9 +1213,7 @@ int parse_line (char *line, char *argv[])
printf ("** Too many args (max. %d) **\n", CONFIG_SYS_MAXARGS);
-#ifdef DEBUG_PARSER
- printf ("parse_line: nargs=%d\n", nargs);
-#endif
+ debug_parser("parse_line: nargs=%d\n", nargs);
return (nargs);
}
@@ -1235,12 +1231,10 @@ static void process_macros (const char *input, char
*output)
/* 1 = waiting for '(' or '{' */
/* 2 = waiting for ')' or '}' */
/* 3 = waiting for ''' */
-#ifdef DEBUG_PARSER
char *output_start = output;
- printf ("[PROCESS_MACROS] INPUT len %d: \"%s\"\n", strlen (input),
- input);
-#endif
+ debug_parser("[PROCESS_MACROS] INPUT len %zd: \"%s\"\n", strlen(input),
+input);
prev = '\0';/* previous character */
@@ -1328,10 +1322,8 @@ static void process_macros (const char *input, char
*output)
else
*(output - 1) = 0;
-#ifdef DEBUG_PARSER
- printf ("[PROCESS_MACROS] OUTPUT len %d: \"%s\"\n",
- strlen (output_start), output_start);
-#endif
+ debug_parser("[PROCESS_MACROS] OUTPUT len %zd: \"%s\"\n",
+strlen(output_start), output_start);
}
/
@@ -1362,12 +1354,12 @@ static int builtin_run_command(const char *cmd, int
flag)
int repeatable = 1;
int rc = 0;
-#ifdef DEBUG_PARSER
- printf ("[RUN_COMMAND] cmd[%p]=\"", cmd);
- puts (cmd ? cmd : "NULL"); /* use puts - string may be lng */
- puts ("\"\n");
-#endif
-
+ debug_parser("[RUN_COMMAND] cmd[%p]=\"", cmd);
+ if (DEBUG_PARSER) {
+ /* use puts - string may be lng */
+ puts(cmd ? cmd : "NULL");
+ puts("\"\n");
+ }
clear_ctrlc(); /* forget any previous Control C */
if (!cmd || !*cmd) {
@@ -1385,9 +1377,7 @@ static int builtin_run_command(const char *cmd, int flag)
* repeatable commands
*/
-#ifdef DEBUG_PARSER
- printf ("[PROCESS_SEPARATORS] %s\n", cmd);
-#endif
+ debug_parser("[PROCESS_SEPARATORS] %s\n", cmd);
while (*str) {
/*
@@ -1416,9 +1406,7 @@ static int builtin_run_command(const char *cmd, int flag)
}
else
str = sep; /* no more commands for next pass */
-#ifdef DEBUG_PARSER
- printf ("token: \"%s\"\n", token);
-#endif
+ debug_parser("token: \"%s\"\n", token);
/* find macros in this token and replace them */
process_macros (token, finaltoken);
--
1.8.2.1
___
U-Boot mailing list
U-Boo
[U-Boot] [PATCH v4 6/9] main: Fix typos and checkpatch warnings in command line reading
There are a few over-long lines and other checkpatch problems in this area
of the code. Prepare the ground for the next patch by tidying these up.
Signed-off-by: Simon Glass
Reviewed-by: Joe Hershberger
---
Changes in v4: None
Changes in v3:
- Separate out checkpatch fixes in command line reading code into new patch
common/main.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/common/main.c b/common/main.c
index 38fadac..1adfea6 100644
--- a/common/main.c
+++ b/common/main.c
@@ -1078,20 +1078,20 @@ int readline_into_buffer(const char *const prompt, char
*buffer, int timeout)
* Special character handling
*/
switch (c) {
- case '\r': /* Enter
*/
+ case '\r': /* Enter*/
case '\n':
*p = '\0';
puts ("\r\n");
- return (p - p_buf);
+ return p - p_buf;
- case '\0': /* nul
*/
+ case '\0': /* nul */
continue;
- case 0x03: /* ^C - break
*/
+ case 0x03: /* ^C - break */
p_buf[0] = '\0';/* discard input */
- return (-1);
+ return -1;
- case 0x15: /* ^U - erase line
*/
+ case 0x15: /* ^U - erase line */
while (col > plen) {
puts (erase_seq);
--col;
@@ -1100,15 +1100,15 @@ int readline_into_buffer(const char *const prompt, char
*buffer, int timeout)
n = 0;
continue;
- case 0x17: /* ^W - erase word
*/
+ case 0x17: /* ^W - erase word */
p=delete_char(p_buf, p, &col, &n, plen);
while ((n > 0) && (*p != ' ')) {
p=delete_char(p_buf, p, &col, &n, plen);
}
continue;
- case 0x08: /* ^H - backspace
*/
- case 0x7F: /* DEL - backspace
*/
+ case 0x08: /* ^H - backspace */
+ case 0x7F: /* DEL - backspace */
p=delete_char(p_buf, p, &col, &n, plen);
continue;
@@ -1117,7 +1117,7 @@ int readline_into_buffer(const char *const prompt, char
*buffer, int timeout)
* Must be a normal character then
*/
if (n < CONFIG_SYS_CBSIZE-2) {
- if (c == '\t') {/* expand TABs
*/
+ if (c == '\t') {/* expand TABs */
#ifdef CONFIG_AUTO_COMPLETE
/* if auto completion triggered just
continue */
*p = '\0';
@@ -1132,7 +1132,7 @@ int readline_into_buffer(const char *const prompt, char
*buffer, int timeout)
char buf[2];
/*
-* Echo input using puts() to force am
+* Echo input using puts() to force an
* LCD flush if we are using an LCD
*/
++col;
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 9/9] main: Add debug_bootkeys to avoid #ifdefs
Define a simple debug condition at the top of the file, to avoid using
lots of #ifdefs later on.
Signed-off-by: Simon Glass
Reviewed-by: Joe Hershberger
---
Changes in v4: None
Changes in v3: None
common/main.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/common/main.c b/common/main.c
index fcce0f3..f6b9dc2 100644
--- a/common/main.c
+++ b/common/main.c
@@ -53,6 +53,11 @@ void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progre
#define debug_parser(fmt, args...) \
debug_cond(DEBUG_PARSER, fmt, ##args)
+#ifndef DEBUG_BOOTKEYS
+#define DEBUG_BOOTKEYS 0
+#endif
+#define debug_bootkeys(fmt, args...) \
+ debug_cond(DEBUG_BOOTKEYS, fmt, ##args)
charconsole_buffer[CONFIG_SYS_CBSIZE + 1]; /* console I/O buffer
*/
@@ -138,11 +143,9 @@ static int abortboot_keyed(int bootdelay)
presskey_max = presskey_max > delaykey[i].len ?
presskey_max : delaykey[i].len;
-# if DEBUG_BOOTKEYS
- printf("%s key:<%s>\n",
- delaykey[i].retry ? "delay" : "stop",
- delaykey[i].str ? delaykey[i].str : "NULL");
-# endif
+ debug_bootkeys("%s key:<%s>\n",
+ delaykey[i].retry ? "delay" : "stop",
+ delaykey[i].str ? delaykey[i].str : "NULL");
}
/* In order to keep up with incoming data, check timeout only
@@ -167,10 +170,9 @@ static int abortboot_keyed(int bootdelay)
memcmp (presskey + presskey_len - delaykey[i].len,
delaykey[i].str,
delaykey[i].len) == 0) {
-# if DEBUG_BOOTKEYS
- printf("got %skey\n",
- delaykey[i].retry ? "delay" : "stop");
-# endif
+ debug_bootkeys("got %skey\n",
+ delaykey[i].retry ? "delay" :
+ "stop");
# ifdef CONFIG_BOOT_RETRY_TIME
/* don't retry auto boot */
@@ -182,10 +184,8 @@ static int abortboot_keyed(int bootdelay)
}
} while (!abort && get_ticks() <= etime);
-# if DEBUG_BOOTKEYS
if (!abort)
- puts("key timeout\n");
-# endif
+ debug_bootkeys("key timeout\n");
#ifdef CONFIG_SILENT_CONSOLE
if (abort)
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 7/9] main: Correct header order
The headers are a bit out of order, so fix them. Signed-off-by: Simon Glass --- Changes in v4: - Rebase without autoconf changes Changes in v3: None common/main.c | 19 --- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/common/main.c b/common/main.c index 1adfea6..e5173d7 100644 --- a/common/main.c +++ b/common/main.c @@ -28,26 +28,15 @@ /* #define DEBUG */ #include -#include #include #include -#include -#include -#ifdef CONFIG_MODEM_SUPPORT -#include /* for free() prototype */ -#endif - -#ifdef CONFIG_SYS_HUSH_PARSER #include -#endif - -#ifdef CONFIG_OF_CONTROL -#include -#endif - +#include +#include #include +#include +#include #include -#include DECLARE_GLOBAL_DATA_PTR; -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/9] main: Move boot_delay code into its own function
Move this code into its own function, since it clutters up main_loop().
Signed-off-by: Simon Glass
---
Changes in v4:
- Make change without using autoconf
Changes in v3: None
common/main.c | 137 ++
1 file changed, 70 insertions(+), 67 deletions(-)
diff --git a/common/main.c b/common/main.c
index 22ea8fd..159b8e1 100644
--- a/common/main.c
+++ b/common/main.c
@@ -341,27 +341,14 @@ static void process_fdt_options(const void *blob)
}
#endif /* CONFIG_OF_CONTROL */
-
-//
-
-void main_loop (void)
+#ifdef CONFIG_BOOTDELAY
+static void process_boot_delay(void)
{
-#ifndef CONFIG_SYS_HUSH_PARSER
- static char lastcommand[CONFIG_SYS_CBSIZE] = { 0, };
- int len;
- int rc = 1;
- int flag;
-#endif
-#if defined(CONFIG_BOOTDELAY) && defined(CONFIG_OF_CONTROL)
+#ifdef CONFIG_OF_CONTROL
char *env;
#endif
-#if defined(CONFIG_BOOTDELAY)
char *s;
int bootdelay;
-#endif
-#ifdef CONFIG_PREBOOT
- char *p;
-#endif
#ifdef CONFIG_BOOTCOUNT_LIMIT
unsigned long bootcount = 0;
unsigned long bootlimit = 0;
@@ -369,8 +356,6 @@ void main_loop (void)
char bcs_set[16];
#endif /* CONFIG_BOOTCOUNT_LIMIT */
- bootstage_mark_name(BOOTSTAGE_ID_MAIN_LOOP, "main_loop");
-
#ifdef CONFIG_BOOTCOUNT_LIMIT
bootcount = bootcount_load();
bootcount++;
@@ -381,50 +366,6 @@ void main_loop (void)
bootlimit = bcs ? simple_strtoul (bcs, NULL, 10) : 0;
#endif /* CONFIG_BOOTCOUNT_LIMIT */
-#ifdef CONFIG_MODEM_SUPPORT
- debug ("DEBUG: main_loop: do_mdm_init=%d\n", do_mdm_init);
- if (do_mdm_init) {
- char *str = strdup(getenv("mdm_cmd"));
- setenv ("preboot", str); /* set or delete definition */
- if (str != NULL)
- free (str);
- mdm_init(); /* wait for modem connection */
- }
-#endif /* CONFIG_MODEM_SUPPORT */
-
-#ifdef CONFIG_VERSION_VARIABLE
- {
- setenv ("ver", version_string); /* set version variable */
- }
-#endif /* CONFIG_VERSION_VARIABLE */
-
-#ifdef CONFIG_SYS_HUSH_PARSER
- u_boot_hush_start ();
-#endif
-
-#if defined(CONFIG_HUSH_INIT_VAR)
- hush_init_var ();
-#endif
-
-#ifdef CONFIG_PREBOOT
- if ((p = getenv ("preboot")) != NULL) {
-# ifdef CONFIG_AUTOBOOT_KEYED
- int prev = disable_ctrlc(1);/* disable Control C checking */
-# endif
-
- run_command_list(p, -1, 0);
-
-# ifdef CONFIG_AUTOBOOT_KEYED
- disable_ctrlc(prev);/* restore Control C checking */
-# endif
- }
-#endif /* CONFIG_PREBOOT */
-
-#if defined(CONFIG_UPDATE_TFTP)
- update_tftp (0UL);
-#endif /* CONFIG_UPDATE_TFTP */
-
-#if defined(CONFIG_BOOTDELAY)
s = getenv ("bootdelay");
bootdelay = s ? (int)simple_strtol(s, NULL, 10) : CONFIG_BOOTDELAY;
@@ -473,26 +414,88 @@ void main_loop (void)
debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "");
if (bootdelay != -1 && s && !abortboot(bootdelay)) {
-# ifdef CONFIG_AUTOBOOT_KEYED
+#ifdef CONFIG_AUTOBOOT_KEYED
int prev = disable_ctrlc(1);/* disable Control C checking */
-# endif
+#endif
run_command_list(s, -1, 0);
-# ifdef CONFIG_AUTOBOOT_KEYED
+#ifdef CONFIG_AUTOBOOT_KEYED
disable_ctrlc(prev);/* restore Control C checking */
-# endif
+#endif
}
-# ifdef CONFIG_MENUKEY
+#ifdef CONFIG_MENUKEY
if (menukey == CONFIG_MENUKEY) {
s = getenv("menucmd");
if (s)
run_command_list(s, -1, 0);
}
#endif /* CONFIG_MENUKEY */
+}
#endif /* CONFIG_BOOTDELAY */
+void main_loop(void)
+{
+#ifndef CONFIG_SYS_HUSH_PARSER
+ static char lastcommand[CONFIG_SYS_CBSIZE] = { 0, };
+ int len;
+ int rc = 1;
+ int flag;
+#endif
+#ifdef CONFIG_PREBOOT
+ char *p;
+#endif
+
+ bootstage_mark_name(BOOTSTAGE_ID_MAIN_LOOP, "main_loop");
+
+#ifdef CONFIG_MODEM_SUPPORT
+ debug("DEBUG: main_loop: do_mdm_init=%d\n", do_mdm_init);
+ if (do_mdm_init) {
+ char *str = strdup(getenv("mdm_cmd"));
+ setenv("preboot", str); /* set or delete definition */
+ if (str != NULL)
+ free(str);
+ mdm_init(); /* wait for modem connection */
+ }
+#endif /* CONFIG_MODEM_SUPPORT */
+
+#ifdef CONFIG_VERSION_VARIABLE
+ {
+ setenv("ver", version_string); /* set version variable */
+ }
+#endif /* CONFIG_VERSION_VARIABLE */
+
+#ifdef CONFIG_SYS_HUSH_PARSER
+ u_boot_hush_start();
+#endif
+
+#if defined(CONFIG_HUSH_INIT_VAR)
+ hush_init_var();
+#endif
+
+#ifdef CONFIG_PREBOOT
+ p = getenv("preboot");
+ if (p != NULL) {
+# ifdef CONFIG_AUTOBOOT_KEYED
+ int prev = disable_ctrlc(1);/*
Re: [U-Boot] ARM v7: Flush icache when executing a program with go
ons 2013-05-15 klockan 17:11 +0200 skrev Albert ARIBAUD: > What is the rationale behind putting it in arch/ rather than in common/ > by adding this to the existing common/cmd_boot.c file under ARMv7 > conditionals? Only because of what I said earlier: blindly calling invalidate_icache_all() from the go command will cause loud complains on other arches where the icache is not supported/enabled. > Also: > > > ARM v7 runs with icache enabled. For reliable results the go command > > needs to flush the icache before jumping or it may risk running > > cached instructions that differ from what currently is in memory. > > IIUC, the issue is due to cache being enabled when doing the go, rather > than due to armv7 per se. Not entirely sure what you mean. > So, should we not have this icache flush conditioned at compile time on > cache being compiled in, and at run time on cache being enabled? This > way, we would automatically cater for the same issue appearing in other > ARM CPUs, and even more, in other architectures. Except.. see common/cmd_cache.c top of file and you'll see the yelling I am talking about. Regards Henrik ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/9] net: Add prototype for update_tftp
On Wed, May 15, 2013 at 11:23 AM, Simon Glass wrote: > This function should be declared in net.h. > > Signed-off-by: Simon Glass > --- > Changes in v4: > - Removed autoconf() code for now > > Changes in v3: None > > common/cmd_fitupd.c | 3 +-- > common/main.c | 4 > include/net.h | 3 +++ > 3 files changed, 4 insertions(+), 6 deletions(-) Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
