Re: [U-Boot] [PATCH resend 2/2] arm/boards: Define a new config option CONFIG_BOOT_PARAMS_P
On 12/7/2012 8:17 PM, Wolfgang Denk wrote: Dear Vipin Kumar, In message<50c1b9a6.1020...@st.com> you wrote: Can you please suggest what is the best way here. Wolfgang, Albert ? I don't like this patch at all. It introduces yet more architecture specific stuff to lib/board.c, while we actually should be working on coming up with a common version for all architectures. If you want to simplify code, then please not by making it worse in other places. I agree, but this code adds an option to pass boot params pointer to board descriptor. Just two lines above the intended change, there is a mach_type initialization based on the definition of CONFIG_MACH_TYPE. Moreover, the lib/board.c exists in arch/arm as of today which means that it can contain all the stuff common for arm boards If I am right, the patch should also be OK Vipin Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2013.01-rc2 released
Hi Tom, On Fri, Dec 14, 2012 at 10:52 PM, Tom Rini wrote: > Hey all, > > I've tagged and pushed v2013.01-rc2 now. The next branch has been open > for a little bit, and is still open now, and in sync. Here's where > we're at: > - I expect a USB pull request from Marek soon. > - I've locally build-tested Simon's gd->arch series and will run-time > test it on a few platforms I have soon now. > - I know Albert is around and working on a u-boot-arm pull request. > > In my TODO list in patchwork, nothing strikes me as new feature posted > before the merge window closed. I see a few bug fixes I might pull in, > or might sit on to make sure they don't cause surprises. It's of course > possible I missed something, or something is assigned to someone else so > if this strikes anyone as wrong, please speak up now. Also, if you have > any bugfixes you expect me to pull, please get them out sooner rather > than later. The release is still planned for Jan 15, a month away, but > there's holidays in there which mean both some folks are not working and > other folks have some free time for hobby projects. The 'make env' build is currently (v2013.01-rc2) broken for me, the fix is http://patchwork.ozlabs.org/patch/198243/ The patchset includes also these patches, please see the comments/ACKs/NAKs. http://patchwork.ozlabs.org/patch/198241/ http://patchwork.ozlabs.org/patch/198242/ Thank you! Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imls: Add support to list images in NAND device
On 12/15/2012 12:29 AM, Scott Wood wrote:
On 12/14/2012 03:23:26 AM, Vipin Kumar wrote:
On 12/14/2012 3:22 AM, Scott Wood wrote:
On 12/13/2012 12:10:58 AM, Vipin Kumar wrote:
+ imgdata = malloc(read_size);
+ if (!imgdata) {
+ printf("Not able to list all
images " \
+ "(Low memory)\n");
Don't line-wrap error strings.
80 column ?
Error strings are an exception for the sake of greppability. From
Linux's Documentation/CodingStyle:
Statements longer than 80 columns will be broken into sensible
chunks, unless
exceeding 80 columns significantly increases readability and does
not hide
information. Descendants are always substantially shorter than
the
parent and
are placed substantially to the right. The same applies to
function
headers
with a long argument list. However, never break user-visible
strings
such as
printk messages, because that breaks the ability to grep for
them.
Yes, thanks for reminding. The error strings are more readable
already in v3. Please take a look
No, you're still breaking up strings (and you also have a totally
unnecessary backslash). If it's on one line in the output, it should
be on one line in the source.
Yes, got it. Please check v4. I will send it out soon
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] imls: Add support to list images in NAND device
This patch adds support to list images in NAND flash through imls
Signed-off-by: Vipin Kumar
---
Changes in v4
- Keep stdout dumps in one line
- Continue even after read errors for all the blocks
README | 3 +-
common/cmd_bootm.c | 167 -
2 files changed, 166 insertions(+), 4 deletions(-)
diff --git a/README b/README
index 2077c3b..46fd21d 100644
--- a/README
+++ b/README
@@ -831,7 +831,8 @@ The following options need to be configured:
CONFIG_CMD_I2C * I2C serial bus support
CONFIG_CMD_IDE * IDE harddisk support
CONFIG_CMD_IMIiminfo
- CONFIG_CMD_IMLS List all found images
+ CONFIG_CMD_IMLS List all images found in NOR flash
+ CONFIG_CMD_IMLS_NAND List all images found in NAND flash
CONFIG_CMD_IMMAP* IMMR dump support
CONFIG_CMD_IMPORTENV* import an environment
CONFIG_CMD_INI * import data from an ini file into the
env
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index d256ddf..938e500 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -80,9 +80,15 @@ static int image_info(unsigned long addr);
#include
#include
extern flash_info_t flash_info[]; /* info for FLASH chips */
+#endif
+
+#if defined(CONFIG_CMD_IMLS) || defined(CONFIG_CMD_IMLS_NAND)
static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
#endif
+#include
+#include
+
#ifdef CONFIG_SILENT_CONSOLE
static void fixup_silent_linux(void);
#endif
@@ -1175,7 +1181,7 @@ U_BOOT_CMD(
/* imls - list all images found in flash */
/***/
#if defined(CONFIG_CMD_IMLS)
-static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+static int do_imls_nor(void)
{
flash_info_t *info;
int i, j;
@@ -1224,6 +1230,161 @@ next_sector:;
}
next_bank: ;
}
+ return 0;
+}
+#endif
+
+#if defined(CONFIG_CMD_IMLS_NAND)
+static int nand_imls_legacyimage(nand_info_t *nand, int nand_dev, loff_t off,
+ size_t len)
+{
+ void *imgdata;
+ int ret;
+
+ imgdata = malloc(len);
+ if (!imgdata) {
+ printf("May be a Legacy Image at NAND device %d offset
%08llX:\n",
+ nand_dev, off);
+ printf(" Low memory(cannot allocate memory for image)\n");
+ return -ENOMEM;
+ }
+
+ ret = nand_read_skip_bad(nand, off, &len,
+ imgdata);
+ if (ret < 0 && ret != -EUCLEAN) {
+ free(imgdata);
+ return ret;
+ }
+
+ if (!image_check_hcrc(imgdata)) {
+ free(imgdata);
+ return 0;
+ }
+
+ printf("Legacy Image at NAND device %d offset %08llX:\n",
+ nand_dev, off);
+ image_print_contents(imgdata);
+
+ puts(" Verifying Checksum ... ");
+ if (!image_check_dcrc(imgdata))
+ puts("Bad Data CRC\n");
+ else
+ puts("OK\n");
+
+ free(imgdata);
+
+ return 0;
+}
+
+static int nand_imls_fitimage(nand_info_t *nand, int nand_dev, loff_t off,
+ size_t len)
+{
+ void *imgdata;
+ int ret;
+
+ imgdata = malloc(len);
+ if (!imgdata) {
+ printf("May be a FIT Image at NAND device %d offset %08llX:\n",
+ nand_dev, off);
+ printf(" Low memory(cannot allocate memory for image)\n");
+ return -ENOMEM;
+ }
+
+ ret = nand_read_skip_bad(nand, off, &len,
+ imgdata);
+ if (ret < 0 && ret != -EUCLEAN) {
+ free(imgdata);
+ return ret;
+ }
+
+ if (!fit_check_format(imgdata)) {
+ free(imgdata);
+ return 0;
+ }
+
+ printf("FIT Image at NAND device %d offset %08llX:\n", nand_dev, off);
+
+ fit_print_contents(imgdata);
+ free(imgdata);
+
+ return 0;
+}
+
+static int do_imls_nand(void)
+{
+ nand_info_t *nand;
+ int nand_dev = nand_curr_device;
+ size_t len;
+ loff_t off;
+ u32 buffer[16];
+
+ if (nand_dev < 0 || nand_dev >= CONFIG_SYS_MAX_NAND_DEVICE) {
+ puts("\nNo NAND devices available\n");
+ return -ENODEV;
+ }
+
+ printf("\n");
+
+ for (nand_dev = 0; nand_dev < CONFIG_SYS_MAX_NAND_DEVICE; nand_dev++) {
+ nand = &nand_info[nand_dev];
+ if (!nand->name || !nand->size)
+ continue;
+
+ for (off = 0; off < nand->size; off += nand->erasesize) {
+ const image_header_t *header;
+ int ret;
+
+ if (nand_block_isbad(nan
Re: [U-Boot] UBI Fixable bit-flip issue.
Hi, On 12/15/2012 04:14 AM, Vikram Narayanan wrote: > On 12/14/2012 11:33 PM, Vikram Narayanan wrote: >> >> I'm seeing a fixable bit-flip in the current u-boot (v2012.10) on a >> i.Mx6 Solo based custom board. The problem is similar to the one >> explained here [1]. >> >> As observed by the thread's author, does reverting the commit "1b1f9a9" >> solves the issue? Did someone face a similar issue? >> this was a workaround I had until I found a proper solution for v2011.09. In the meantime the following fix was included in u-boot: http://git.denx.de/?p=u-boot.git;a=commit;h=d63894654df72b010de2abb4b3f07d0d755f65b6 This solves this issue for my problem. This patch is included in v2012.10 so this should be ok. Maybe you hit a different problem. Regards Holger >> >> [1] http://lists.denx.de/pipermail/u-boot/2011-September/100237.html >> [2] http://lists.denx.de/pipermail/u-boot/2011-September/101887.html > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb/host/ehci: Add support for EHCI on spear
Add EHCI support for spear boards
Signed-off-by: Armando Visconti
Signed-off-by: Vipin Kumar
---
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-spear.c | 59 +++
2 files changed, 60 insertions(+)
create mode 100644 drivers/usb/host/ehci-spear.c
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 6c94794..9a6f982 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -54,6 +54,7 @@ COBJS-$(CONFIG_USB_EHCI_PPC4XX) += ehci-ppc4xx.o
COBJS-$(CONFIG_USB_EHCI_IXP4XX) += ehci-ixp.o
COBJS-$(CONFIG_USB_EHCI_MARVELL) += ehci-marvell.o
COBJS-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
+COBJS-$(CONFIG_USB_EHCI_SPEAR) += ehci-spear.o
COBJS-$(CONFIG_USB_EHCI_TEGRA) += ehci-tegra.o
COBJS-$(CONFIG_USB_EHCI_VCT) += ehci-vct.o
diff --git a/drivers/usb/host/ehci-spear.c b/drivers/usb/host/ehci-spear.c
new file mode 100644
index 000..f99bd1f
--- /dev/null
+++ b/drivers/usb/host/ehci-spear.c
@@ -0,0 +1,59 @@
+/*
+ * (C) Copyright 2010
+ * Armando Visconti, ST Micoelectronics, .
+ *
+ * (C) Copyright 2009
+ * Marvell Semiconductor
+ * Written-by: Prafulla Wadaskar
+ *
+ * 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
+ */
+
+#include
+#include
+#include
+#include "ehci.h"
+#include
+
+
+/*
+ * Create the appropriate control structures to manage
+ * a new EHCI host controller.
+ */
+int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor)
+{
+ *hccr = (struct ehci_hccr *)(CONFIG_SYS_UHC0_EHCI_BASE + 0x100);
+ *hcor = (struct ehci_hcor *)((uint32_t)*hccr
+ + HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
+
+ debug("SPEAr-ehci: init hccr %x and hcor %x hc_length %d\n",
+ (uint32_t)*hccr, (uint32_t)*hcor,
+ (uint32_t)HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
+
+ return 0;
+}
+
+/*
+ * Destroy the appropriate control structures corresponding
+ * the the EHCI host controller.
+ */
+int ehci_hcd_stop(int index)
+{
+ return 0;
+}
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usbtty: adapt buffers for large packet support
From: Shiraz Hashim
Increase buffer sizes at driver and tty level to accommodate kermit
large packet support.
Signed-off-by: Shiraz Hashim
---
drivers/serial/usbtty.c | 2 +-
include/usbdevice.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/usbtty.c b/drivers/serial/usbtty.c
index e47cb9a..148d1a6 100644
--- a/drivers/serial/usbtty.c
+++ b/drivers/serial/usbtty.c
@@ -63,7 +63,7 @@
/*
* Buffers to hold input and output data
*/
-#define USBTTY_BUFFER_SIZE 256
+#define USBTTY_BUFFER_SIZE 2048
static circbuf_t usbtty_input;
static circbuf_t usbtty_output;
diff --git a/include/usbdevice.h b/include/usbdevice.h
index 3edaf8b..7037efd 100644
--- a/include/usbdevice.h
+++ b/include/usbdevice.h
@@ -475,7 +475,9 @@ typedef struct urb_link {
* function driver to inform it that data has arrived.
*/
-#define URB_BUF_SIZE 128 /* in linux we'd malloc this, but in u-boot we prefer
static data */
+/* in linux we'd malloc this, but in u-boot we prefer static data */
+#define URB_BUF_SIZE 512
+
struct urb {
struct usb_endpoint_instance *endpoint;
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2013.01-rc2 released
Am 2012-12-14 22:52, schrieb Tom Rini: > In my TODO list in patchwork, nothing strikes me as new feature posted > before the merge window closed. I see a few bug fixes I might pull in, > or might sit on to make sure they don't cause surprises. It's of course > possible I missed something, or something is assigned to someone else so > if this strikes anyone as wrong, please speak up now. Also, if you have > any bugfixes you expect me to pull, please get them out sooner rather > than later. The release is still planned for Jan 15, a month away, but > there's holidays in there which mean both some folks are not working and > other folks have some free time for hobby projects. > Hello Tom, currently only one of the both targets for the eb_cpu5282 board works. This patch http://patchwork.ozlabs.org/patch/200310/ will fix this also for -rc2. It should be included in the release. Thanks Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend] armv7/ltimer: Add support for local timer on armv7 cpus
Ciao Vipin,
Yes, I agree about the need to have the generic
local_timer support in u-boot.
Internally I was not able to give comment about this
part. So, see my comments now.
On 12/06/2012 10:22 AM, Vipin KUMAR wrote:
Certain ARMV7 cpus eg. CortexA9 contains a local and a global timer within the
CPU core itself. This patch adds generic support for local timer.
Signed-off-by: Vipin Kumar
---
arch/arm/cpu/armv7/Makefile | 11 ++-
arch/arm/cpu/armv7/ca9_ltimer.c | 152 ++
arch/arm/include/asm/ca9_ltimer.h | 40 ++
3 files changed, 199 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/cpu/armv7/ca9_ltimer.c
create mode 100644 arch/arm/include/asm/ca9_ltimer.h
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 4fdbee4..3ef01f6 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -27,15 +27,18 @@ LIB = $(obj)lib$(CPU).o
START := start.o
-COBJS += cache_v7.o
+COBJS-y+= cache_v7.o
-COBJS += cpu.o
-COBJS += syslib.o
+COBJS-y+= cpu.o
+COBJS-y+= syslib.o
+COBJS-$(CONFIG_ARMV7_CA9LTIMER) += ca9_ltimer.o
Is it really necessary to have the 'ca9' prefix here?
I think it would be better to stay more generic here,
like: 'CONFIG_ARMV7_LTIMER' and 'ltimer.o'.
In linux as well is kept generic, even across architectures...
If accepted, apply globally...
ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA20),)
-SOBJS += lowlevel_init.o
+SOBJS-y+= lowlevel_init.o
endif
+COBJS := $(sort $(COBJS-y))
+SOBJS := $(sort $(SOBJS-y))
SRCS := $(START:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
START := $(addprefix $(obj),$(START))
diff --git a/arch/arm/cpu/armv7/ca9_ltimer.c b/arch/arm/cpu/armv7/ca9_ltimer.c
new file mode 100644
index 000..cbf1552
--- /dev/null
+++ b/arch/arm/cpu/armv7/ca9_ltimer.c
@@ -0,0 +1,152 @@
+/*
+ * (C) Copyright 2012
+ * Vipin Kumar, ST Micoelectronics, vipin.ku...@st.com.
+ *
+ * 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
+
+#define READ_TIMER() readl(&ca9_timer_p->count)
+
+static struct ca9_timer_regs *const ca9_timer_p =
+ (struct ca9_timer_regs *)CONFIG_ARMV7_LTIMER_BASE;
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define timestamp gd->tbl
+#define lastdecgd->lastinc
+#define tickshzgd->timer_rate_hz
+#define ticksper10usec gd->tbu
+
+int timer_init(void)
+{
+ u32 prescaler, timertickshz;
+ /*
+* Genrally, CortexA9 MPUs are operating from 500MHz to 1500MHz which
+* means that CA9 local timer clock would be in the range of 250 MHz to
+* 750MHz.
+* Try to find a prescaler which can perfectly divide the local timer
+* clock. Take prescaler as 200 if nothing is found
+*/
+ for (prescaler = 255; prescaler> 1; prescaler--) {
+ if (CONFIG_ARMV7_LTMR_CLK ==
+ (CONFIG_ARMV7_LTMR_CLK / prescaler) * prescaler)
+ break;
+ }
+
+ if (prescaler == 1)
+ prescaler = 200;
Where the default '200' prescaler selection come from?
Shouldn't it be a configurable option (i.e. CONFIG_)?
Or passed as an argument to this function?
+ timertickshz = CONFIG_ARMV7_LTMR_CLK / prescaler;
+ ticksper10usec = timertickshz / (100 * 1000);
+ tickshz = timertickshz / CONFIG_SYS_HZ;
+
+ /* disable timers */
+ writel(((prescaler - 1)<< 8) | AUTO_RELOAD,&ca9_timer_p->control);
+
Why can't single-shot be selectable?
Shouldn't it be passed as an argument to timer_init()?
+ /* load value for free running */
+ writel(FREE_RUNNING,&ca9_timer_p->load);
+
+ /* auto reload, start timer */
+ setbits_le32(&ca9_timer_p->control, TIMER_ENABLE);
+
+ reset_timer_masked();
+
+ return 0;
+}
+
+/*
+ * timer without interrupts
+ */
+
+void reset_timer(void)
+{
+ reset_timer_masked();
+}
+
+ulong get_timer(ulong base)
+{
+ return (get_timer_masked() / tickshz) - base;
+}
+
+void set_timer(ulong t)
+{
+ timestamp = t;
+}
+
+void __udelay(unsigned long usec)
[U-Boot] [PATCH 5/9] EXYNOS5: DWMMC: API to set mmc clock divisor
This API computes the divisor value based on MPLL clock and
writes it into the FSYS1 register.
Signed-off-by: Amar
---
arch/arm/cpu/armv7/exynos/clock.c | 39 ++-
arch/arm/include/asm/arch-exynos/clk.h |1 +
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 731bbff..6517296 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -379,7 +379,7 @@ static unsigned long exynos4_get_mmc_clk(int dev_index)
(struct exynos4_clock *)samsung_get_base_clock();
unsigned long uclk, sclk;
unsigned int sel, ratio, pre_ratio;
- int shift;
+ int shift = 0;
sel = readl(&clk->src_fsys);
sel = (sel >> (dev_index << 2)) & 0xf;
@@ -428,7 +428,7 @@ static unsigned long exynos5_get_mmc_clk(int dev_index)
(struct exynos5_clock *)samsung_get_base_clock();
unsigned long uclk, sclk;
unsigned int sel, ratio, pre_ratio;
- int shift;
+ int shift = 0;
sel = readl(&clk->src_fsys);
sel = (sel >> (dev_index << 2)) & 0xf;
@@ -526,6 +526,41 @@ static void exynos5_set_mmc_clk(int dev_index, unsigned
int div)
writel(val, addr);
}
+/* exynos5: set the mmc clock div ratio in fsys1 */
+int exynos5_mmc_set_clk_div(int dev_index)
+{
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+ unsigned int addr;
+ unsigned int clock;
+ unsigned int tmp;
+ unsigned int i;
+
+ /* get mpll clock */
+ clock = get_pll_clk(MPLL) / 100;
+
+ /*
+* CLK_DIV_FSYS1
+* MMC0_PRE_RATIO [15:8], MMC0_RATIO [3:0]
+* CLK_DIV_FSYS2
+* MMC2_PRE_RATIO [15:8], MMC2_RATIO [3:0]
+*/
+ if (dev_index < 2) {
+ addr = (unsigned int)&clk->div_fsys1;
+ } else {
+ addr = (unsigned int)&clk->div_fsys2;
+ }
+
+ tmp = readl(addr) & ~FSYS1_MMC0_DIV_MASK;
+ for (i = 0; i <= 0xf; i++) {
+ if ((clock / (i + 1)) <= 400) {
+ writel(tmp | i << 0, addr);
+ break;
+ }
+ }
+ return 0;
+}
+
/* get_lcd_clk: return lcd clock frequency */
static unsigned long exynos4_get_lcd_clk(void)
{
diff --git a/arch/arm/include/asm/arch-exynos/clk.h
b/arch/arm/include/asm/arch-exynos/clk.h
index ff155d8..b0ecdd4 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -36,6 +36,7 @@ unsigned long get_pwm_clk(void);
unsigned long get_uart_clk(int dev_index);
unsigned long get_mmc_clk(int deV_index);
void set_mmc_clk(int dev_index, unsigned int div);
+int exynos5_mmc_set_clk_div(int dev_index);
unsigned long get_lcd_clk(void);
void set_lcd_clk(void);
void set_mipi_clk(void);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] SMDK5250: Enable DWMMC
This patch enables DWMMC for SMDK5250.
Support both dt and non-dt versions.
Signed-off-by: Amar
---
board/samsung/smdk5250/smdk5250.c | 36
include/configs/exynos5250-dt.h |9 +
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 4d24978..7a9c8f6 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -192,16 +193,43 @@ int checkboard(void)
#ifdef CONFIG_GENERIC_MMC
int board_mmc_init(bd_t *bis)
{
- int err;
+ int err = 0, ret = 0;
+#ifdef CONFIG_OF_CONTROL
+ /* dwmmc initializattion for available channels */
+ err = exynos_dwmmc_init(gd->fdt_blob);
+ if (err) {
+ debug("dwmmc init failed\n");
+ }
+ ret |= err;
+#else
err = exynos_pinmux_config(PERIPH_ID_SDMMC0, PINMUX_FLAG_8BIT_MODE);
if (err) {
debug("SDMMC0 not configured\n");
- return err;
}
+ ret |= err;
- err = s5p_mmc_init(0, 8);
- return err;
+ /*eMMC: dwmmc Channel-0 with 8 bit bus width */
+ err = exynos_dwmmc_init(0, 8);
+ if (err) {
+ debug("dwmmc Channel-0 init failed\n");
+ }
+ ret |= err;
+
+ err = exynos_pinmux_config(PERIPH_ID_SDMMC2, PINMUX_FLAG_NONE);
+ if (err) {
+ debug("SDMMC2 not configured\n");
+ }
+ ret |= err;
+
+ /*SD: dwmmc Channel-2 with 4 bit bus width */
+ err = exynos_dwmmc_init(2, 4);
+ if (err) {
+ debug("dwmmc Channel-2 init failed\n");
+ }
+ ret |= err;
+#endif
+ return ret;
}
#endif
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 12f555c..3b89e20 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -84,6 +84,8 @@
#define CONFIG_MMC
#define CONFIG_SDHCI
#define CONFIG_S5P_SDHCI
+#define CONFIG_DWMMC
+#define CONFIG_EXYNOS_DWMMC
#define CONFIG_BOARD_EARLY_INIT_F
@@ -116,6 +118,13 @@
#define CONFIG_SPL
#define COPY_BL2_FNPTR_ADDR0x02020030
+/* eMMC4.4 SPL */
+#define EMMC44_COPY_BL2_FNPTR_ADDR 0x02020044
+#define EMMC44_END_BOOTOP_FNPTR_ADDR 0x02020048
+
+#define FSYS1_MMC0_DIV_MASK0xff0f
+
+
/* specific .lds file */
#define CONFIG_SPL_LDSCRIPT"board/samsung/smdk5250/smdk5250-uboot-spl.lds"
#define CONFIG_SPL_TEXT_BASE 0x02023400
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] MMC: APIs to support creation of boot partition
This pathc adds APIs to open, close and to create boot partiton for eMMC.
Signed-off-by: Amar
---
drivers/mmc/mmc.c | 118 +
include/mmc.h | 16 +++
2 files changed, 134 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 5ffd8c5..88b0435 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1302,3 +1302,121 @@ int mmc_initialize(bd_t *bis)
return 0;
}
+
+int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long bootsize,
+ unsigned long rpmbsize)
+{
+ int err;
+ struct mmc_cmd cmd;
+
+ /* Only use this command for raw eMMC moviNAND */
+ /* Enter backdoor mode */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = MMC_CMD62_ARG1;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_partition_size_change: Error1 = %d\n", err);
+ return err;
+ }
+
+ /* Boot partition changing mode */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = MMC_CMD62_ARG2;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_partition_size_change: Error2 = %d\n", err);
+ return err;
+ }
+ /* boot partition size is multiple of 128KB */
+ bootsize = ((bootsize*1024)/128);
+
+ /* Arg: boot partition size */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = bootsize;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_partition_size_change: Error3 = %d\n", err);
+ return err;
+ }
+ /* RPMB partition size is multiple of 128KB */
+ rpmbsize = ((rpmbsize*1024)/128);
+ /* Arg: RPMB partition size */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = rpmbsize;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_partition_size_change: Error4 = %d\n", err);
+ return err;
+ }
+ return 0;
+}
+
+int mmc_boot_open(struct mmc *mmc)
+{
+ int err;
+ struct mmc_cmd cmd;
+
+ /* Boot ack enable, boot partition enable , boot partition access */
+ cmd.cmdidx = MMC_CMD_SWITCH;
+ cmd.resp_type = MMC_RSP_R1b;
+
+ cmd.cmdarg = (MMC_SWITCH_MODE_WRITE_BYTE << 24 |
+ EXT_CSD_PART_CONF << 16 |
+ (EXT_CSD_BOOT_ACK_ENABLE |
+ EXT_CSD_BOOT_PARTITION_ENABLE |
+ EXT_CSD_PARTITION_ACCESS_ENABLE) << 8);
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_open: Error1 = %d\n", err);
+ return err;
+ }
+
+ /* 4bit transfer mode at booting time. */
+ cmd.cmdidx = MMC_CMD_SWITCH;
+ cmd.resp_type = MMC_RSP_R1b;
+
+ cmd.cmdarg = (MMC_SWITCH_MODE_WRITE_BYTE << 24|
+ EXT_CSD_BOOT_BUS_WIDTH << 16|
+ ((1<<0) << 8));
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_open: Error2 = %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
+
+int mmc_boot_close(struct mmc *mmc)
+{
+ int err;
+ struct mmc_cmd cmd;
+
+ /* Boot ack enable, boot partition enable , boot partition access */
+ cmd.cmdidx = MMC_CMD_SWITCH;
+ cmd.resp_type = MMC_RSP_R1b;
+
+ cmd.cmdarg = (MMC_SWITCH_MODE_WRITE_BYTE << 24|
+ EXT_CSD_PART_CONF << 16|
+ (EXT_CSD_BOOT_ACK_ENABLE |
+ EXT_CSD_BOOT_PARTITION_ENABLE |
+ EXT_CSD_PARTITION_ACCESS_DISABLE) << 8);
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_close: Error = %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
diff --git a/include/mmc.h b/include/mmc.h
index a13e2bd..999f0a3 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -86,6 +86,11 @@
#define MMC_CMD_APP_CMD55
#define MMC_CMD_SPI_READ_OCR 58
#define MMC_CMD_SPI_CRC_ON_OFF 59
+#define MMC_CMD_RES_MAN62
+
+#define MMC_CMD62_ARG1 0xefac62ec
+#define MMC_CMD62_ARG2 0xcbaea7
+
#define SD_CMD_SEND_RELATIVE_ADDR 3
#define SD_CMD_SWITCH_FUNC 6
@@ -153,6 +158,7 @@
*/
#define EXT_CSD_PARTITIONING_SUPPORT 160 /* RO */
#define EXT_CSD_ERASE_GROUP_DEF175 /* R/W */
+#define EXT_CSD_BOOT_BUS_WIDTH 177
#define EXT_CSD_PART_CONF 179 /* R/W */
#define EXT_CSD_BUS_WIDTH 183 /* R/W */
#define EXT_CSD_HS_TIMING 185 /* R/W */
@@ -177,6 +183,12 @
[U-Boot] [PATCH 8/9] SMDK5250: Enable eMMC booting
This patch adds support for eMMC booting on SMDK5250
Signed-off-by: Amar
---
board/samsung/smdk5250/spl_boot.c | 38 -
1 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/board/samsung/smdk5250/spl_boot.c
b/board/samsung/smdk5250/spl_boot.c
index d8f3c1e..2648b4e 100644
--- a/board/samsung/smdk5250/spl_boot.c
+++ b/board/samsung/smdk5250/spl_boot.c
@@ -23,15 +23,40 @@
#include
#include
+#include
+#include
+
+#define FSYS1_MMC0_DIV_VAL 0x0701
+
enum boot_mode {
BOOT_MODE_MMC = 4,
+ BOOT_MODE_eMMC = 8, /* eMMC44 */
BOOT_MODE_SERIAL = 20,
/* Boot based on Operating Mode pin settings */
BOOT_MODE_OM = 32,
BOOT_MODE_USB, /* Boot using USB download */
};
- typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
+typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
+static void set_emmc_clk(void);
+
+/*
+* Set MMC0 clock divisor value.
+* So that the mmc0 device operating freq is 50MHz.
+*/
+static void set_emmc_clk(void)
+{
+ struct exynos5_clock *clk = (struct exynos5_clock *)EXYNOS5_CLOCK_BASE;
+ unsigned int addr;
+ unsigned int div_mmc;
+
+ addr = (unsigned int) &clk->div_fsys1;
+
+ div_mmc = readl(addr) & ~FSYS1_MMC0_DIV_MASK;
+ div_mmc |= FSYS1_MMC0_DIV_VAL;
+ writel(div_mmc, addr);
+}
+
/*
* Copy U-boot from mmc to RAM:
@@ -43,6 +68,8 @@ void copy_uboot_to_ram(void)
spi_copy_func_t spi_copy;
enum boot_mode bootmode;
u32 (*copy_bl2)(u32, u32, u32);
+ u32 (*copy_bl2_emmc)(u32, u32);
+ void (*end_bootop_emmc)(void);
bootmode = readl(EXYNOS5_POWER_BASE) & OM_STAT;
@@ -57,6 +84,15 @@ void copy_uboot_to_ram(void)
copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
CONFIG_SYS_TEXT_BASE);
break;
+ case BOOT_MODE_eMMC:
+ set_emmc_clk();
+ end_bootop_emmc = (void *) *(u32 *)EMMC44_END_BOOTOP_FNPTR_ADDR;
+ copy_bl2_emmc = (void *) *(u32 *)EMMC44_COPY_BL2_FNPTR_ADDR;
+
+ copy_bl2_emmc(BL2_SIZE_BLOC_COUNT, CONFIG_SYS_TEXT_BASE);
+ end_bootop_emmc();
+ break;
+
default:
break;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 9/9] COMMON: MMC: Command to support eMMC booting
This patch adds commands to open, close and create partitions on eMMC
Signed-off-by: Amar
---
common/cmd_mmc.c | 101 +-
1 files changed, 100 insertions(+), 1 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 62a1c22..1fd6b94 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -248,6 +248,102 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
curr_device, mmc->part_num);
return 0;
+ } else if (strcmp(argv[1], "open") == 0) {
+ int dev;
+ struct mmc *mmc;
+
+ if (argc == 2)
+ dev = curr_device;
+ else if (argc == 3)
+ dev = simple_strtoul(argv[2], NULL, 10);
+ else if (argc == 4)
+ return 1;
+
+ else
+ return CMD_RET_USAGE;
+
+ mmc = find_mmc_device(dev);
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", dev);
+ return 1;
+ }
+
+ if (IS_SD(mmc)) {
+ printf("SD device cannot be opened/closed\n");
+ return 1;
+ }
+
+ if (!(mmc_boot_open(mmc))) {
+ printf("eMMC OPEN Success.!!\n");
+ printf("\t\t\t!!!Notice!!!\n");
+ printf("!You must close eMMC boot Partition"
+ "after all image writing!\n");
+ printf("!eMMC boot partition has continuity"
+ "at image writing time.!\n");
+ printf("!So, Do not close boot partition, Before,"
+ "all images is written.!\n");
+ } else {
+ printf("eMMC OPEN Failed.!!\n");
+ }
+ return 0;
+
+ } else if (strcmp(argv[1], "close") == 0) {
+ int dev;
+ struct mmc *mmc;
+
+ if (argc == 2)
+ dev = curr_device;
+ else if (argc == 3)
+ dev = simple_strtoul(argv[2], NULL, 10);
+ else if (argc == 4)
+ return 1;
+ else
+ return CMD_RET_USAGE;
+
+ mmc = find_mmc_device(dev);
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", dev);
+ return 1;
+ }
+
+ if (IS_SD(mmc)) {
+ printf("SD device cannot be opened/closed\n");
+ return 1;
+ }
+
+ if (!(mmc_boot_close(mmc)))
+ printf("eMMC CLOSE Success.!!\n");
+ else
+ printf("eMMC CLOSE Failed.!!\n");
+
+ return 0;
+
+ } else if (strcmp(argv[1], "bootpart") == 0) {
+ int dev;
+ dev = simple_strtoul(argv[2], NULL, 10);
+
+ struct mmc *mmc = find_mmc_device(dev);
+ u32 bootsize = simple_strtoul(argv[3], NULL, 10);
+ u32 rpmbsize = simple_strtoul(argv[4], NULL, 10);
+
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", dev);
+ return 1;
+ }
+
+ if (IS_SD(mmc)) {
+ printf("It is not a eMMC device\n");
+ return 1;
+ }
+
+ if (0 == mmc_boot_partition_size_change(mmc,
+ bootsize, rpmbsize)) {
+ printf("eMMC boot partition Size %d MB!!\n", bootsize);
+ printf("eMMC RPMB partition Size %d MB!!\n", rpmbsize);
+ } else {
+ printf("eMMC boot partition Size change Failed.!!\n");
+ }
+ return 0;
}
if (strcmp(argv[1], "read") == 0)
@@ -318,5 +414,8 @@ U_BOOT_CMD(
"mmc rescan\n"
"mmc part - lists available partition on current mmc device\n"
"mmc dev [dev] [part] - show or set current mmc device [partition]\n"
- "mmc list - lists available devices");
+ "mmc list - lists available devices\n"
+ "mmc open - opens the specified device\n"
+ "mmc close - closes the specified device\n"
+ "mmc bootpart \n");
#endif
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] FDT: Add compatible string for DWMMC
Add required compatible information for DWMMC driver.
Signed-off-by: Amar
---
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 539bb1b..f09c281 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -74,6 +74,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS5_SOUND, /* Exynos Sound */
COMPAT_WOLFSON_WM8994_CODEC,/* Wolfson WM8994 Sound Codec */
COMPAT_SAMSUNG_EXYNOS_SPI, /* Exynos SPI */
+ COMPAT_SAMSUNG_EXYNOS5_DWMMC, /* Exynos5 DWMMC controller */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 44c249d..6597661 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -51,6 +51,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS5_SOUND, "samsung,exynos-sound"),
COMPAT(WOLFSON_WM8994_CODEC, "wolfson,wm8994-codec"),
COMPAT(SAMSUNG_EXYNOS_SPI, "samsung,exynos-spi"),
+ COMPAT(SAMSUNG_EXYNOS5_DWMMC, "samsung,exynos5250-dwmmc"),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/9] EXYNOS5: Enable dwmmc
This patch set enables and initialises dwmmc for Exynos5250 on SMDK5250. Adds driver changes required for dwmmc. Adds dt support for dwmmc. Adds eMMC booting feature for SMDK5250. This patch set is based on: "EXYNOS: mmc: support DesignWare Controller for Samsung-SoC", which is merged in u-boot-mmc "Exynos: clock: support get_mmc_clk for exynos" "Add DT based ethernet driver for SMDK5250" "SMDK5250: Add FDT support" Amar (9): FDT: Add compatible string for DWMMC EXYNOS5: FDT: Add DWMMC device node data DWMMC: Initialise dwmci and resolved the boot partition write issue EXYNOS5: DWMMC: Added dt support for DWMMC EXYNOS5: DWMMC: API to set mmc clock divisor SMDK5250: Enable DWMMC MMC: APIs to support creation of boot partition SMDK5250: Enable eMMC booting COMMON: MMC: Command to support eMMC booting arch/arm/cpu/armv7/exynos/clock.c | 39 +- arch/arm/dts/exynos5250.dtsi | 32 arch/arm/include/asm/arch-exynos/clk.h|1 + arch/arm/include/asm/arch-exynos/dwmmc.h |4 + board/samsung/dts/exynos5250-smdk5250.dts | 24 ++ board/samsung/smdk5250/smdk5250.c | 36 - board/samsung/smdk5250/spl_boot.c | 38 +- common/cmd_mmc.c | 101 - drivers/mmc/dw_mmc.c | 12 +++- drivers/mmc/exynos_dw_mmc.c | 117 +++-- drivers/mmc/mmc.c | 118 + include/configs/exynos5250-dt.h |9 ++ include/dwmmc.h |4 + include/fdtdec.h |1 + include/mmc.h | 16 lib/fdtdec.c |1 + 16 files changed, 538 insertions(+), 15 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/9] EXYNOS5: FDT: Add DWMMC device node data
Add DWMMC device node data for exynos5
Signed-off-by: Amar
---
arch/arm/dts/exynos5250.dtsi | 32 +
board/samsung/dts/exynos5250-smdk5250.dts | 24 +
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index 1008797..b701ae5 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -138,4 +138,36 @@
reg = <0x131b 0x30>;
interrupts = <0 130 0>;
};
+
+ dwmmc@1220 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos5250-dwmmc";
+ reg = <0x1220 0x1000>;
+ interrupts = <0 75 0>;
+ };
+
+ dwmmc@1221 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos5250-dwmmc";
+ reg = <0x1221 0x1000>;
+ interrupts = <0 76 0>;
+ };
+
+ dwmmc@1222 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos5250-dwmmc";
+ reg = <0x1222 0x1000>;
+ interrupts = <0 77 0>;
+ };
+
+ dwmmc@1223 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos5250-dwmmc";
+ reg = <0x1223 0x1000>;
+ interrupts = <0 78 0>;
+ };
};
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index a8e62da..b1b8d71 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -30,6 +30,10 @@
spi2 = "/spi@12d4";
spi3 = "/spi@131a";
spi4 = "/spi@131b";
+ dwmmc0 = "/dwmmc@1220";
+ dwmmc1 = "/dwmmc@1221";
+ dwmmc2 = "/dwmmc@1222";
+ dwmmc3 = "/dwmmc@1223";
};
sromc@1225 {
@@ -59,4 +63,24 @@
compatible = "wolfson,wm8994-codec";
};
};
+
+ dwmmc@1220 {
+ index = <0>;
+ bus-width = <8>;
+ timing = <1 3 3>;
+ };
+
+ dwmmc@1221 {
+ status = "disabled";
+ };
+
+ dwmmc@1222 {
+ index = <2>;
+ bus-width = <4>;
+ timing = <1 2 3>;
+ };
+
+ dwmmc@1223 {
+ status = "disabled";
+ };
};
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9] EXYNOS5: DWMMC: Added dt support for DWMMC
Signed-off-by: Amar
---
arch/arm/include/asm/arch-exynos/dwmmc.h |4 +
drivers/mmc/exynos_dw_mmc.c | 117 --
include/dwmmc.h |4 +
3 files changed, 119 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
b/arch/arm/include/asm/arch-exynos/dwmmc.h
index 8acdf9b..92352df 100644
--- a/arch/arm/include/asm/arch-exynos/dwmmc.h
+++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
@@ -27,6 +27,9 @@
#define DWMCI_SET_DRV_CLK(x) ((x) << 16)
#define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
+#ifdef CONFIG_OF_CONTROL
+unsigned int exynos_dwmmc_init(const void *blob);
+#else
int exynos_dwmci_init(u32 regbase, int bus_width, int index);
static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
@@ -34,3 +37,4 @@ static inline unsigned int exynos_dwmmc_init(int index, int
bus_width)
unsigned int base = samsung_get_base_mmc() + (0x1 * index);
return exynos_dwmci_init(base, bus_width, index);
}
+#endif
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 72a31b7..3b3e3e5 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -19,23 +19,38 @@
*/
#include
-#include
#include
+#include
+#include
+#include
#include
#include
+#include
+
+#defineDWMMC_MAX_CH_NUM4
+#defineDWMMC_MAX_FREQ 5200
+#defineDWMMC_MIN_FREQ 40
+#defineDWMMC_MMC0_CLKSEL_VAL 0x03030001
+#defineDWMMC_MMC2_CLKSEL_VAL 0x03020001
static char *EXYNOS_NAME = "EXYNOS DWMMC";
static void exynos_dwmci_clksel(struct dwmci_host *host)
{
- u32 val;
- val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
- DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(0);
+ dwmci_writel(host, DWMCI_CLKSEL, host->clksel_val);
+}
- dwmci_writel(host, DWMCI_CLKSEL, val);
+unsigned int exynos_dwmci_get_clk(int dev_index)
+{
+ return get_mmc_clk(dev_index);
}
+#ifdef CONFIG_OF_CONTROL
+static int exynos_dwmci_init(u32 regbase, int bus_width,
+ int index, u32 *timing)
+#else
int exynos_dwmci_init(u32 regbase, int bus_width, int index)
+#endif
{
struct dwmci_host *host = NULL;
host = malloc(sizeof(struct dwmci_host));
@@ -44,14 +59,104 @@ int exynos_dwmci_init(u32 regbase, int bus_width, int
index)
return 1;
}
+ /* set the clock divisor - clk_div_fsys for mmc */
+ if (exynos5_mmc_set_clk_div(index)) {
+ debug("mmc clock div set failed\n");
+ return -1;
+ }
+
host->name = EXYNOS_NAME;
host->ioaddr = (void *)regbase;
host->buswidth = bus_width;
+#ifdef CONFIG_OF_CONTROL
+ host->clksel_val = (DWMCI_SET_SAMPLE_CLK(timing[0]) |
+ DWMCI_SET_DRV_CLK(timing[1]) |
+ DWMCI_SET_DIV_RATIO(timing[2]));
+#else
+ if (0 == index)
+ host->clksel_val = DWMMC_MMC0_CLKSEL_VAL;
+ if (2 == index)
+ host->clksel_val = DWMMC_MMC2_CLKSEL_VAL;
+#endif
host->clksel = exynos_dwmci_clksel;
host->dev_index = index;
+ host->mmc_clk = exynos_dwmci_get_clk;
- add_dwmci(host, 5200, 40);
+ add_dwmci(host, DWMMC_MAX_FREQ, DWMMC_MIN_FREQ);
return 0;
}
+#ifdef CONFIG_OF_CONTROL
+unsigned int exynos_dwmmc_init(const void *blob)
+{
+ u32 base;
+ int index, bus_width;
+ int node_list[DWMMC_MAX_CH_NUM];
+ int err = 0;
+ int dev_id, flag;
+ u32 timing[3];
+ int count, i;
+
+ count = fdtdec_find_aliases_for_id(blob, "dwmmc",
+ COMPAT_SAMSUNG_EXYNOS5_DWMMC, node_list,
+ DWMMC_MAX_CH_NUM);
+
+ for (i = 0; i < count; i++) {
+ int node = node_list[i];
+
+ if (node <= 0)
+ continue;
+
+ /* config pinmux for each mmc channel */
+ dev_id = pinmux_decode_periph_id(blob, node);
+ if (dev_id == PERIPH_ID_SDMMC0)
+ flag = PINMUX_FLAG_8BIT_MODE;
+ else
+ flag = PINMUX_FLAG_NONE;
+
+ err = exynos_pinmux_config(dev_id, flag);
+ if (err) {
+ debug("DWMMC not configured\n");
+ return err;
+ }
+
+ /* Get the base address from the device node */
+ base = fdtdec_get_addr(blob, node, "reg");
+ if (!base) {
+ debug("DWMMC: Can't get base address\n");
+ return -1;
+ }
+
+ /* Get the channel index from the device node */
+ index = fdtdec_get_int(blob, node, "index", 0);
+ if (index < 0) {
+
Re: [U-Boot] [PULL] u-boot-usb/master
Hi Marek, > Pantelis Antoniou (9): > g_dnl: Issue connect/disconnect as appropriate > g_dnl: Properly terminate string list. > dfu: Only perform DFU board_usb_init() for TRATS > dfu: Fix crash when wrong number of arguments given > dfu: Send correct DFU response from composite_setup > dfu: Properly zero out timeout value > dfu: Add a partition type target > dfu: Support larger than memory transfers. > usb: Fix bug when both DFU & ETHER are defined Can we wait with pulling DFU related patches? I didn't received tcpdump from Pantelis, so I don't know what is going on (or how to tackle the DFU problem). -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Lukasz, I'll sent the dump in a couple of hours. Been busy with other work items... Regards -- Pantelis On Dec 17, 2012, at 1:00 PM, Lukasz Majewski wrote: > Hi Marek, > >> Pantelis Antoniou (9): >> g_dnl: Issue connect/disconnect as appropriate >> g_dnl: Properly terminate string list. >> dfu: Only perform DFU board_usb_init() for TRATS >> dfu: Fix crash when wrong number of arguments given >> dfu: Send correct DFU response from composite_setup >> dfu: Properly zero out timeout value >> dfu: Add a partition type target >> dfu: Support larger than memory transfers. >> usb: Fix bug when both DFU & ETHER are defined > > Can we wait with pulling DFU related patches? > > I didn't received tcpdump from Pantelis, so I don't know what is going > on (or how to tackle the DFU problem). > > > -- > Best regards, > > Lukasz Majewski > > Samsung Poland R&D Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm/km: fix memory settings
Hi Prafulla, On 11/02/2012 11:15 AM, Holger Brunck wrote: > On kmcoge5un we faced some serious problems with the memory during > temperature tests. Reason was that we overwrite some registers for > memory settings which have to leave untouched. These where registers > 0x20148 , 0x2014c and 0x20154. > So writing these registers is prohibited and this patch removes them > from all km related config files. Even if the problem was only > seen on kmcoge5un. > > Signed-off-by: Holger Brunck > Signed-off-by: Valentin Longchamp > cc: Prafulla Wadaskar > --- > board/keymile/km_arm/kwbimage-memphis.cfg |6 +++--- > board/keymile/km_arm/kwbimage.cfg |6 +++--- > board/keymile/km_arm/kwbimage_128M16_1.cfg | 25 ++--- > board/keymile/km_arm/kwbimage_256M8_1.cfg | 25 ++--- > 4 files changed, 10 insertions(+), 52 deletions(-) > what about this patch serie? They were posted long time ago and we are already at -rc2 and they are sitting wether in the ARM tree nor in your marvell tree. So could you please pick up these four? Thanks, Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm/km: fix memory settings
> -Original Message- > From: Holger Brunck [mailto:holger.bru...@keymile.com] > Sent: 17 December 2012 18:13 > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Longchamp, > Valentin > Subject: Re: [PATCH 1/4] arm/km: fix memory settings > > Hi Prafulla, > > On 11/02/2012 11:15 AM, Holger Brunck wrote: > > On kmcoge5un we faced some serious problems with the memory during > > temperature tests. Reason was that we overwrite some registers for > > memory settings which have to leave untouched. These where registers > > 0x20148 , 0x2014c and 0x20154. > > So writing these registers is prohibited and this patch removes them > > from all km related config files. Even if the problem was only > > seen on kmcoge5un. > > > > Signed-off-by: Holger Brunck > > Signed-off-by: Valentin Longchamp > > cc: Prafulla Wadaskar > > --- > > board/keymile/km_arm/kwbimage-memphis.cfg |6 +++--- > > board/keymile/km_arm/kwbimage.cfg |6 +++--- > > board/keymile/km_arm/kwbimage_128M16_1.cfg | 25 ++--- > > > board/keymile/km_arm/kwbimage_256M8_1.cfg | 25 ++--- > > > 4 files changed, 10 insertions(+), 52 deletions(-) > > > > what about this patch serie? They were posted long time ago and we are > already > at -rc2 and they are sitting wether in the ARM tree nor in your > marvell tree. So > could you please pick up these four? Sure, I am doing the same, I will provide the pull request today. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/12 06:00, Lukasz Majewski wrote: > Hi Marek, > >> Pantelis Antoniou (9): g_dnl: Issue connect/disconnect as >> appropriate g_dnl: Properly terminate string list. dfu: Only >> perform DFU board_usb_init() for TRATS dfu: Fix crash when wrong >> number of arguments given dfu: Send correct DFU response from >> composite_setup dfu: Properly zero out timeout value dfu: Add a >> partition type target dfu: Support larger than memory transfers. >> usb: Fix bug when both DFU & ETHER are defined > > Can we wait with pulling DFU related patches? Agreed, thanks. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQzydFAAoJENk4IS6UOR1WZBcQAIe9W7xcMiRb0w6NSif1t3Z/ vkm9Wx5aWdAa2URRz8f3vzLn0Yj6zYzP+SVRmWRb1Cj2TLJstOtHknY0ni0qem6W AAaGd5bYYJryO3gp0qRR4YnlQv+xwTWPMG7QBbNCM8mqKPxoWBPSpnfN5Qu11bwm uuF4NQYcZopUvVEzFb1D4cElAr/VlOdp+Yh1kJ3nJvsRqv9mANriPSd4clRLFIM+ v/sWcAsWttHWO+F7fS4ZWqb/l29afBRTS06SsxfHoXrhfq2Z3IC+NANw+xyPktNe dRwJ09asublBqMbnfA7/C2Dl4qzr0ItZstoHnkCm5rDxVgh5XR46ero3d+9IIsmy MXGNQg7TdcFxqeiWCuAdz/MQew1ZNOMXXHDuL5Gm7j+EtgNg7Zhz1rgrjlgAVt86 uCS8gJ3FhSnpRsbER+9Dv3/QLiKdPZyhnaPI/7LgudOTI2CUIRWMuF81EXsn6Pkd BCtUZMXFHwR8Etmx2fEbfL2mY+BCbHyfud/lNjhhAchhYCJwai+u0+BeIBLqiIRx VGza3V0stlz22pN/4+8FjOjKrnecFP5ZTr+9ieVJcaOaj5nD5MUNLzx2DincICzc cdoNiuyRq+TxlhTghKTJisLCj2iWWk8tMXiuC0mFk4rkQ8OUpjfi7rO8VjjvWtXv 3fCwL41xPJ+wh0fljnEH =FZUT -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] dfu: Only perform DFU board_usb_init() for TRATS
On Wed, Nov 28, 2012 at 03:47:43PM +0100, Lukasz Majewski wrote: > Hi Pantelis, > > > USB initialization shouldn't happen for all the boards. > > > > The board_usb_init() follows u-boot policy, that SoC IPs (USB) are > enabled and configured just before their usage. Going back to this old thread as I dig at things again. How much of s3c_udc_probe is actually enabling hardware as opposed to registering that such hardware exists and can be enabled when we call usb_gadget_register_driver ? It looks like all of the clocking (and pin muxing?) is already being done. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Hi Lukasz,
Sorry for the slight delay, setting up the usb capture took a bit longer.
So we have two captures; one named bad (which is the tip of our internal tree
with the commit reverted.
cee8b859fdb9edc68c67624b2fa1c97a65d121e7
"dfu: Send correct DFU response from composite_setup"
With the commit reverted we get this:
> panto@sles11esa:~/ti/stuff/dfu-util$ sudo ./src/dfu-util -v -D ~/test.img -a
> rootfs
> dfu-util 0.7
>
> Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
> Copyright 2010-2012 Tormod Volden and Stefan Schmidt
> This program is Free Software and has ABSOLUTELY NO WARRANTY
> Please report bugs to dfu-u...@lists.gnumonks.org
>
> Opening DFU capable USB device... ID 0403:bd00
> Did not find cached descriptor
> WARNING: Can not find cached DFU functional descriptor
> Warning: Assuming DFU version 1.0
> Run-time device DFU version 0100
> Claiming USB DFU Runtime Interface...
> Determining device status: state = appIDLE, status = 0
> Device really in Runtime Mode, send DFU detach request...
> Resetting USB...
> Opening DFU USB Device...
> Found DFU: [0403:bd00] devnum=0, cfg=2, intf=0, alt=6, name="rootfs"
> Claiming USB DFU Interface...
> Setting Alternate Setting #6 ...
> Determining device status: state = dfuIDLE, status = 0
> dfuIDLE, continuing
> Did not find cached descriptor
> Error obtaining cached DFU functional descriptor
> DUMP of func_dfu
> bLength = 0
> bDescriptorType = 0
> bmAttributes= 0x00
> wDetachTimeOut = 0
> wTransferSize = 0
> bcdDFUVersion = 0x
> Error obtaining DFU functional descriptor
> Please report this as a bug!
> Warning: Assuming DFU version 1.0
> Warning: Transfer size can not be detected
> DFU mode device DFU version 0100
> Error: Transfer size must be specified
>
Looking at the capture file (usb-capture-bad-filter.pcap) we see the culprit at
packet 171 at bad capture and packet 169 at the good.
> USB URB
> URB id: 0x88032d9cbdc0
> URB type: URB_SUBMIT ('S')
> URB transfer type: URB_CONTROL (0x02)
> Endpoint: 0x80, Direction: IN
> 1... = Direction: IN (1)
> .000 = Endpoint value: 0
> Device: 34
> URB bus id: 3
> Device setup request: relevant (0)
> Data: not present ('<')
> URB sec: 1355753000
> URB usec: 572483
> URB status: Operation now in progress (-EINPROGRESS) (-115)
> URB length [bytes]: 9
> Data length [bytes]: 0
> [Response in: 172]
> URB setup
> bmRequestType: 0x80
> 1... = Direction: Device-to-host
> .00. = Type: Standard (0x00)
> ...0 = Recipient: Device (0x00)
> bRequest: GET DESCRIPTOR (6)
> Descriptor Index: 0x00
> bDescriptorType: HID (33)
> Language Id: no language specified (0x)
> wLength: 9
>
> c0 eb 99 28 03 88 ff ff 53 02 80 20 03 00 00 3c ...(S.. ...<
> 0010 d6 0e cf 50 00 00 00 00 a3 bf 0a 00 8d ff ff ff ...P
> 0020 09 00 00 00 00 00 00 00 80 06 00 21 00 00 09 00 ...!
> 0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
>
The response generated when the fix is applied is correct:
> USB URB
> URB id: 0x88032899ebc0
> URB type: URB_COMPLETE ('C')
> URB transfer type: URB_CONTROL (0x02)
> Endpoint: 0x80, Direction: IN
> 1... = Direction: IN (1)
> .000 = Endpoint value: 0
> Device: 32
> URB bus id: 3
> Device setup request: not relevant ('-')
> Data: present (0)
> URB sec: 1355747030
> URB usec: 704533
> URB status: Success (0)
> URB length [bytes]: 9
> Data length [bytes]: 9
> [Request in: 169]
> [Time from request: 0.000114000 seconds]
> [bInterfaceClass: Unknown (0x)]
> GET DESCRIPTOR data (unknown descriptor type 33)
>
> c0 eb 99 28 03 88 ff ff 43 02 80 20 03 00 2d 00 ...(C.. ..-.
> 0010 d6 0e cf 50 00 00 00 00 15 c0 0a 00 00 00 00 00 ...P
> 0020 09 00 00 00 09 00 00 00 00 00 00 00 00 00 00 00
> 0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
> 0040 09 21 0f 00 00 00 10 10 01.!...
Note that wireshark can't decode it - no DFU dissector.
And the dfu-util side:
> $ sudo ./src/dfu-util -v -D ~/test.img -a rootfs
> dfu-util 0.7
>
> Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
> Copyright 2010-2012 Tormod Volden and Stefan Schmidt
> This program is Free Software and has ABSOLUTELY NO WARRANTY
> Please report bugs to dfu-u...@lists.gnumonks.org
>
> Opening DFU capable USB device... ID 0403:bd00
> Did not find cached descriptor
> WARNING: Can not find cached DFU functional descriptor
> Warning: Assuming DFU version 1.0
> Run-time device DFU version 0100
> Claiming USB DFU Runtime Interface...
> Determining device status: state = appIDLE, status = 0
> Device really in Runtime Mode, send DFU detach request...
>
Re: [U-Boot] [PULL] u-boot-usb/master
Dear Tom Rini, > On 12/17/12 06:00, Lukasz Majewski wrote: > > Hi Marek, > > > >> Pantelis Antoniou (9): g_dnl: Issue connect/disconnect as > >> appropriate g_dnl: Properly terminate string list. dfu: Only > >> perform DFU board_usb_init() for TRATS dfu: Fix crash when wrong > >> number of arguments given dfu: Send correct DFU response from > >> composite_setup dfu: Properly zero out timeout value dfu: Add a > >> partition type target dfu: Support larger than memory transfers. > >> usb: Fix bug when both DFU & ETHER are defined > > > > Can we wait with pulling DFU related patches? > > Agreed, thanks. Ok, I'll schedule it for next then. I'll rebuild the fixes and reissue a pullRQ. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb/host/ehci: Add support for EHCI on spear
Dear Vipin Kumar, > Add EHCI support for spear boards > > Signed-off-by: Armando Visconti > Signed-off-by: Vipin Kumar [...] Applied, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: don't generate callback list entries for SPL
On Fri, Dec 14, 2012 at 06:54:05PM -0600, Scott Wood wrote: > SPL doesn't use the environment. These list entries prevent the > functions from being garbage-collected, even though nothing will look at > the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to > break due to size limitations. SPL with networking support uses the environment, so you need to toss CONFIG_SPL_NET_SUPPORT into the test. That said, it's not an interactive environment and this might push that area over the size limit too (in the USB case, which is already pretty tight). -- 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] please pull u-boot-samsung/resolve
Dear Albert, On Saturday, December 15, 2012, Albert ARIBAUD wrote: > Hi Minkyu, > > On Fri, 14 Dec 2012 09:14:11 +0900, Minkyu Kang > > > > wrote: > > On 14/12/12 04:56, Albert ARIBAUD wrote: > > > Hi Minkyu, > > > > > > On Tue, 11 Dec 2012 20:10:06 +0900, Minkyu Kang > > > wrote: > > >> Dear Albert, > > >> > > >> The following changes since commit > fd4d564b3c80b111f18c93adb14233a6a7ddb0e9: > > >> > > >> Merge branch 'master' of git://git.denx.de/u-boot-x86 (2012-12-07 > 08:47:59 -0700) > > >> > > >> are available in the git repository at: > > >> > > >> > > >> git://git.denx.de/u-boot-samsung resolve > > >> > > >> for you to fetch changes up to > fbef8e6e7f1233ed20f8c5045e12c9cf31b43540: > > >> > > >> universal_c210: check the NULL pointer when get the PMIC > (2012-12-11 17:37:28 +0900) > > >> > > >> > > >> Albert ARIBAUD (1): > > >> Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' > > >> > > >> Allen Martin (1): > > >> tegra: add CONSOLE_MUX support to tegra-kbc > > >> > > >> Ashok Kumar Reddy (1): > > >> ARM: arm1176: Define arch_cpu_init() for s3c64xx > > >> > > >> Benoît Thébaudeau (17): > > >> arm1136: Fix enable_caches() > > >> mx31: Move EHCI definitions to ehci-fsl.h > > >> ehci-mxc: Clean up > > >> ehci-mx5: Clean up > > >> ehci-mx5: Fix OC_DIS usage > > >> ehci-mx5: Fix OPM usage > > >> ehci-mx5: Fix *PM usage for i.MX53 > > >> ehci-mx5: Add missing OC_DIS for i.MX53 > > >> ehci-mxc: Make EHCI power/oc polarities configurable > > >> ehci-mxc: Make i.MX25 EHCI configurable > > >> ehci-mxc: Define host offsets > > >> ehci-mxc: Add support for i.MX35 > > >> mx35pdk: Add support for OTG > > >> ehci-mx5/6: Make board_ehci_hcd_init() optional > > >> ehci-mxc: Fix host power mask bit for i.MX35 > > >> ehci-mxc: Fix host power mask bit for i.MX25 > > >> mx5: Mark lowlevel_init board-specific code > > >> > > >> Chander Kashyap (1): > > >> Exynos5250: Enable PXE Support > > >> > > >> Fabio Estevam (24): > > >> mx25pdk: Include CONFIG_MX25 > > >> mx25pdk: Add esdhc support > > >> pmic_fsl: Introduce FSL_PMIC_I2C_LENGTH > > >> mx25: Place common functions into sys_proto.h > > >> pmic: Add support for mc34704 > > >> mx25pdk: Add Ethernet support > > >> mx53loco: Allow booting a zImage kernel > > >> mx25pdk: Allow booting a zImage kernel > > >> mx51evk: Allow booting a zImage kernel > > >> mx35pdk: Allow booting a zImage kernel > > >> mx6qsabre_common: Allow booting a zImage kernel > > >> mx5: Align SPI CS naming with i.MX53 reference manual > > >> mx5: Print CSPI clock in 'clock' command > > >> spi: mxc_spi: Fix handling of chip select > > >> spi: mxc_spi: Fix spi clock glitch durant reset > > >> mx6: clock: Only show CSPI clock if CSPI is enabled > > >> mx28evk: Configure CONFIG_BOOTDELAY to one second > > >> mx53loco: Configure CONFIG_BOOTDELAY to one second > > >> mx6qsabrelite: Configure CONFIG_BOOTDELAY to one second > > >> mx6qsabre_common: Configure CONFIG_BOOTDELAY to one second > > >> mx51evk: Configure CONFIG_BOOTDELAY to one second > > >> mx25pdk: Configure CONFIG_BOOTDELAY to one sYou're right. I was > a bit quick to reply when I read Stephen's > question. Can you please address it too? Address for what? > > > Thanks. > > Minkyu Kang. > > > > Amicalement, > -- > Albert. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] input: Add MELFAS mms144 touchscreen driver
Dear Donghwa Lee, In message <50ce7957.6070...@samsung.com> you wrote: > From: Sanggun Lee > > This is a TSP driver for touchscreen chip mms144 of MELFAS. > It uses soft I2C interface and supports single touch. > > This driver uses polling method. > If there are touch events, mms144_interrupt() reads and returns 0. > If not, mms144_interrupt() returns -1. Where exactly will this driver be used inside U-Boot? So far, we don't have any GUI support, do what is a touch driver good for? Are you just adding dead code here? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You see things; and you say ``Why?'' But I dream things that never were; and I say ``Why not?'' - George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Hi Pantelis,
Thanks for logs. I will go through them and let you know.
First thing, which I see, that needs to be done is upgrading dfu-util
(from dfu-util version 0.1+svnexported to dfu-util 0.7)
> Hi Lukasz,
>
> Sorry for the slight delay, setting up the usb capture took a bit
> longer.
>
> So we have two captures; one named bad (which is the tip of our
> internal tree with the commit reverted.
>
> cee8b859fdb9edc68c67624b2fa1c97a65d121e7
> "dfu: Send correct DFU response from composite_setup"
>
> With the commit reverted we get this:
>
> > panto@sles11esa:~/ti/stuff/dfu-util$ sudo ./src/dfu-util -v -D
> > ~/test.img -a rootfs dfu-util 0.7
> >
> > Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
> > Copyright 2010-2012 Tormod Volden and Stefan Schmidt
> > This program is Free Software and has ABSOLUTELY NO WARRANTY
> > Please report bugs to dfu-u...@lists.gnumonks.org
> >
> > Opening DFU capable USB device... ID 0403:bd00
> > Did not find cached descriptor
> > WARNING: Can not find cached DFU functional descriptor
> > Warning: Assuming DFU version 1.0
> > Run-time device DFU version 0100
> > Claiming USB DFU Runtime Interface...
> > Determining device status: state = appIDLE, status = 0
> > Device really in Runtime Mode, send DFU detach request...
> > Resetting USB...
> > Opening DFU USB Device...
> > Found DFU: [0403:bd00] devnum=0, cfg=2, intf=0, alt=6, name="rootfs"
> > Claiming USB DFU Interface...
> > Setting Alternate Setting #6 ...
> > Determining device status: state = dfuIDLE, status = 0
> > dfuIDLE, continuing
> > Did not find cached descriptor
> > Error obtaining cached DFU functional descriptor
> > DUMP of func_dfu
> > bLength = 0
> > bDescriptorType = 0
> > bmAttributes= 0x00
> > wDetachTimeOut = 0
> > wTransferSize = 0
> > bcdDFUVersion = 0x
> > Error obtaining DFU functional descriptor
> > Please report this as a bug!
> > Warning: Assuming DFU version 1.0
> > Warning: Transfer size can not be detected
> > DFU mode device DFU version 0100
> > Error: Transfer size must be specified
> >
>
> Looking at the capture file (usb-capture-bad-filter.pcap) we see the
> culprit at packet 171 at bad capture and packet 169 at the good.
>
> > USB URB
> > URB id: 0x88032d9cbdc0
> > URB type: URB_SUBMIT ('S')
> > URB transfer type: URB_CONTROL (0x02)
> > Endpoint: 0x80, Direction: IN
> > 1... = Direction: IN (1)
> > .000 = Endpoint value: 0
> > Device: 34
> > URB bus id: 3
> > Device setup request: relevant (0)
> > Data: not present ('<')
> > URB sec: 1355753000
> > URB usec: 572483
> > URB status: Operation now in progress (-EINPROGRESS) (-115)
> > URB length [bytes]: 9
> > Data length [bytes]: 0
> > [Response in: 172]
> > URB setup
> > bmRequestType: 0x80
> > 1... = Direction: Device-to-host
> > .00. = Type: Standard (0x00)
> > ...0 = Recipient: Device (0x00)
> > bRequest: GET DESCRIPTOR (6)
> > Descriptor Index: 0x00
> > bDescriptorType: HID (33)
> > Language Id: no language specified (0x)
> > wLength: 9
> >
> > c0 eb 99 28 03 88 ff ff 53 02 80 20 03 00 00
> > 3c ...(S.. ...< 0010 d6 0e cf 50 00 00 00 00 a3 bf 0a 00 8d
> > ff ff ff ...P 0020 09 00 00 00 00 00 00 00 80 06 00
> > 21 00 00 09 00 ...! 0030 00 00 00 00 00 00 00 00 00
> > 02 00 00 00 00 00 00
> >
>
>
> The response generated when the fix is applied is correct:
>
> > USB URB
> > URB id: 0x88032899ebc0
> > URB type: URB_COMPLETE ('C')
> > URB transfer type: URB_CONTROL (0x02)
> > Endpoint: 0x80, Direction: IN
> > 1... = Direction: IN (1)
> > .000 = Endpoint value: 0
> > Device: 32
> > URB bus id: 3
> > Device setup request: not relevant ('-')
> > Data: present (0)
> > URB sec: 1355747030
> > URB usec: 704533
> > URB status: Success (0)
> > URB length [bytes]: 9
> > Data length [bytes]: 9
> > [Request in: 169]
> > [Time from request: 0.000114000 seconds]
> > [bInterfaceClass: Unknown (0x)]
> > GET DESCRIPTOR data (unknown descriptor type 33)
> >
> > c0 eb 99 28 03 88 ff ff 43 02 80 20 03 00 2d
> > 00 ...(C.. ..-. 0010 d6 0e cf 50 00 00 00 00 15 c0 0a 00 00
> > 00 00 00 ...P 0020 09 00 00 00 09 00 00 00 00 00 00
> > 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00
> > 02 00 00 00 00 00 00 0040 09 21 0f 00 00 00 10
> > 10 01.!...
>
>
> Note that wireshark can't decode it - no DFU dissector.
>
> And the dfu-util side:
>
> > $ sudo ./src/dfu-util -v -D ~/test.img -a rootfs
> > dfu-util 0.7
> >
> > Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
> > Copyright 2010-2012 Tormod Volden and Stefan Schmidt
> > This program is Free Software
Re: [U-Boot] [PATCH 05/10] dfu: Only perform DFU board_usb_init() for TRATS
Hi Tom, > On Wed, Nov 28, 2012 at 03:47:43PM +0100, Lukasz Majewski wrote: > > > Hi Pantelis, > > > > > USB initialization shouldn't happen for all the boards. > > > > > > > The board_usb_init() follows u-boot policy, that SoC IPs (USB) are > > enabled and configured just before their usage. > > Going back to this old thread as I dig at things again. How much of > s3c_udc_probe is actually enabling hardware as opposed to registering > that such hardware exists and can be enabled when we call > usb_gadget_register_driver ? It looks like all of the clocking (and > pin muxing?) is already being done. > I will check if s3c_udc_probe can be removed totally and replaced by usb_gadget_register_driver (since some time has passed from original UDC driver posting). -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] dfu: Only perform DFU board_usb_init() for TRATS
On Mon, Dec 17, 2012 at 12:37 PM, Lukasz Majewski wrote: > Hi Tom, > >> On Wed, Nov 28, 2012 at 03:47:43PM +0100, Lukasz Majewski wrote: >> >> > Hi Pantelis, >> > >> > > USB initialization shouldn't happen for all the boards. >> > > >> > >> > The board_usb_init() follows u-boot policy, that SoC IPs (USB) are >> > enabled and configured just before their usage. >> >> Going back to this old thread as I dig at things again. How much of >> s3c_udc_probe is actually enabling hardware as opposed to registering >> that such hardware exists and can be enabled when we call >> usb_gadget_register_driver ? It looks like all of the clocking (and >> pin muxing?) is already being done. >> > > I will check if s3c_udc_probe can be removed totally and replaced by > usb_gadget_register_driver (since some time has passed from original > UDC driver posting). Well, not so much replace but just, if there's no actual HW init, move the "probe" (which isn't a probe, it's registering board infos) call into arch_misc_init or similar. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Hi Lukasz,
Absolutely no chance with a different version of dfu-util:
> $ sudo ./src/dfu-util -v -D ~/test.img -a rootfs
> dfu-util 0.7
>
> Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
> Copyright 2010-2012 Tormod Volden and Stefan Schmidt
> This program is Free Software and has ABSOLUTELY NO WARRANTY
> Please report bugs to dfu-u...@lists.gnumonks.org
>
> Opening DFU capable USB device... ID 0403:bd00
> Did not find cached descriptor
> WARNING: Can not find cached DFU functional descriptor
> Warning: Assuming DFU version 1.0
> Run-time device DFU version 0100
> Claiming USB DFU Runtime Interface...
> Determining device status: state = appIDLE, status = 0
> Device really in Runtime Mode, send DFU detach request...
> Resetting USB...
> Opening DFU USB Device...
> Found DFU: [0403:bd00] devnum=0, cfg=2, intf=0, alt=1, name="rootfs"
> Claiming USB DFU Interface...
> Setting Alternate Setting #1 ...
> Determining device status: state = dfuIDLE, status = 0
> dfuIDLE, continuing
> Did not find cached descriptor
> Error obtaining cached DFU functional descriptor
> Error obtaining DFU functional descriptor
> Please report this as a bug!
> Warning: Assuming DFU version 1.0
> Warning: Transfer size can not be detected
> DFU mode device DFU version 0100
> Error: Transfer size must be specified
>
Can you paste the log of your dfu-util session? Are you supplying a transfer
size for example?
Regards
-- Pantelis
On Dec 17, 2012, at 7:32 PM, Lukasz Majewski wrote:
> Hi Pantelis,
>
>
> Thanks for logs. I will go through them and let you know.
>
> First thing, which I see, that needs to be done is upgrading dfu-util
> (from dfu-util version 0.1+svnexported to dfu-util 0.7)
>
>> Hi Lukasz,
>>
>> Sorry for the slight delay, setting up the usb capture took a bit
>> longer.
>>
>> So we have two captures; one named bad (which is the tip of our
>> internal tree with the commit reverted.
>>
>> cee8b859fdb9edc68c67624b2fa1c97a65d121e7
>> "dfu: Send correct DFU response from composite_setup"
>>
>> With the commit reverted we get this:
>>
>>> panto@sles11esa:~/ti/stuff/dfu-util$ sudo ./src/dfu-util -v -D
>>> ~/test.img -a rootfs dfu-util 0.7
>>>
>>> Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
>>> Copyright 2010-2012 Tormod Volden and Stefan Schmidt
>>> This program is Free Software and has ABSOLUTELY NO WARRANTY
>>> Please report bugs to dfu-u...@lists.gnumonks.org
>>>
>>> Opening DFU capable USB device... ID 0403:bd00
>>> Did not find cached descriptor
>>> WARNING: Can not find cached DFU functional descriptor
>>> Warning: Assuming DFU version 1.0
>>> Run-time device DFU version 0100
>>> Claiming USB DFU Runtime Interface...
>>> Determining device status: state = appIDLE, status = 0
>>> Device really in Runtime Mode, send DFU detach request...
>>> Resetting USB...
>>> Opening DFU USB Device...
>>> Found DFU: [0403:bd00] devnum=0, cfg=2, intf=0, alt=6, name="rootfs"
>>> Claiming USB DFU Interface...
>>> Setting Alternate Setting #6 ...
>>> Determining device status: state = dfuIDLE, status = 0
>>> dfuIDLE, continuing
>>> Did not find cached descriptor
>>> Error obtaining cached DFU functional descriptor
>>> DUMP of func_dfu
>>> bLength = 0
>>> bDescriptorType = 0
>>> bmAttributes= 0x00
>>> wDetachTimeOut = 0
>>> wTransferSize = 0
>>> bcdDFUVersion = 0x
>>> Error obtaining DFU functional descriptor
>>> Please report this as a bug!
>>> Warning: Assuming DFU version 1.0
>>> Warning: Transfer size can not be detected
>>> DFU mode device DFU version 0100
>>> Error: Transfer size must be specified
>>>
>>
>> Looking at the capture file (usb-capture-bad-filter.pcap) we see the
>> culprit at packet 171 at bad capture and packet 169 at the good.
>>
>>> USB URB
>>>URB id: 0x88032d9cbdc0
>>>URB type: URB_SUBMIT ('S')
>>>URB transfer type: URB_CONTROL (0x02)
>>>Endpoint: 0x80, Direction: IN
>>>1... = Direction: IN (1)
>>>.000 = Endpoint value: 0
>>>Device: 34
>>>URB bus id: 3
>>>Device setup request: relevant (0)
>>>Data: not present ('<')
>>>URB sec: 1355753000
>>>URB usec: 572483
>>>URB status: Operation now in progress (-EINPROGRESS) (-115)
>>>URB length [bytes]: 9
>>>Data length [bytes]: 0
>>>[Response in: 172]
>>> URB setup
>>>bmRequestType: 0x80
>>>1... = Direction: Device-to-host
>>>.00. = Type: Standard (0x00)
>>>...0 = Recipient: Device (0x00)
>>>bRequest: GET DESCRIPTOR (6)
>>>Descriptor Index: 0x00
>>>bDescriptorType: HID (33)
>>>Language Id: no language specified (0x)
>>>wLength: 9
>>>
>>> c0 eb 99 28 03 88 ff ff 53 02 80 20 03 00 00
>>> 3c ...(S.. ...< 0010 d6 0e cf 50 00 00 00 00 a3 bf 0a 00 8d
>>> ff ff ff ...P 0020 09 00 00 00 00 00 00 00 80 06 00
>>> 21 00 00 09 00 ...! 0030 00 00 00 00 00 00 00 00 00
>>> 02 00 0
Re: [U-Boot] [PATCH resend] armv7/ltimer: Add support for local timer on armv7 cpus
Dear "Dennis Lan (dlan)", In message you wrote: > > > What would be the use of such timer support? Is there any code that > > actually needs it, and why does it need anything beyond the existing > > timer support we have? > I think vipin here is trying to provide a generic timer support for ARMV7 > architecture, > which contains private(local) and global timer. It's general a good thing > which means we can maximize the code usage.. Sorry, I don't get it. Why would we need separate global and local timers? And what exactly is "local" here - local to what? We don't need anything like that on other architectures - so why here? "general a good thing" sounds like "nice to have", and this is usually something we don't really need, especially not in a boot loader. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de One does not thank logic. -- Sarek, "Journey to Babel", stardate 3842.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend] armv7/ltimer: Add support for local timer on armv7 cpus
Dear Vipin Kumar, In message <50ce9e90.1090...@st.com> you wrote: > > Dennis is right. I am trying to provide the armv7 local timer support. Why would we need such? And how is the term "local" defined here? Local to what? > Well, actually the local timer was used in the spear13xx support which > is to be added later on. The global timer was not used and hence the > driver was not needed (at least by us). but I agree that such a driver > would be useful for a lot of people using armv7 cores and CPU timers Please explain why? We do have timer support on armv7, right? Why are you adding something new, then? If you are tring to replace existing code with some better implementation, I would expect to see code being removed, too? > The global timer support, even if it is added, would be added as a > separate driver so this is infact complete in its own Please understand that completeness has never been any goal for U-Boot, on contrary. Quote: Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Confound these ancestors They've stolen our best ideas!" - Ben Jonson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBI Fixable bit-flip issue.
Hi, On 12/17/2012 2:14 PM, Holger Brunck wrote: Hi, On 12/15/2012 04:14 AM, Vikram Narayanan wrote: On 12/14/2012 11:33 PM, Vikram Narayanan wrote: I'm seeing a fixable bit-flip in the current u-boot (v2012.10) on a i.Mx6 Solo based custom board. The problem is similar to the one explained here [1]. As observed by the thread's author, does reverting the commit "1b1f9a9" solves the issue? Did someone face a similar issue? this was a workaround I had until I found a proper solution for v2011.09. In the meantime the following fix was included in u-boot: http://git.denx.de/?p=u-boot.git;a=commit;h=d63894654df72b010de2abb4b3f07d0d755f65b6 This solves this issue for my problem. This patch is included in v2012.10 so this should be ok. Maybe you hit a different problem. Thanks for clarifying. I'll see if I can reproduce it someway and also rebase my work on top of v2012.10 to see if that solves the issue. Thanks, Vikram ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: don't generate callback list entries for SPL
On 12/17/2012 08:52:59 AM, Tom Rini wrote: On Fri, Dec 14, 2012 at 06:54:05PM -0600, Scott Wood wrote: > SPL doesn't use the environment. These list entries prevent the > functions from being garbage-collected, even though nothing will look at > the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to > break due to size limitations. SPL with networking support uses the environment, so you need to toss CONFIG_SPL_NET_SUPPORT into the test. That said, it's not an interactive environment and this might push that area over the size limit too (in the USB case, which is already pretty tight). OK, I saw "env_*" stuff in the "ifndef CONFIG_SPL_BUILD" section, but later some of it shows up in "ifdef CONFIG_SPL_BUILD" as well. So, do you want a v2, or is it OK because it's not interactive? In the latter case should env_callback.o be removed from the SPL build? Also, env_nvedit.o, env_common.o, and env_flash.o are included for SPL regardless of CONFIG_SPL_NET_SUPPORT. In fact it looks like env_nvedit.o will be included twice if CONFIG_SPL_NET_SUPPORT is enabled. :-P -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: don't generate callback list entries for SPL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/12 13:53, Scott Wood wrote: > On 12/17/2012 08:52:59 AM, Tom Rini wrote: >> On Fri, Dec 14, 2012 at 06:54:05PM -0600, Scott Wood wrote: >> >>> SPL doesn't use the environment. These list entries prevent >>> the functions from being garbage-collected, even though nothing >>> will >> look at >>> the list. This caused several SPL builds (e.g. >>> P2020RDB-PC_NAND) to break due to size limitations. >> >> SPL with networking support uses the environment, so you need to >> toss CONFIG_SPL_NET_SUPPORT into the test. That said, it's not >> an interactive environment and this might push that area over the >> size limit too (in the USB case, which is already pretty tight). > > OK, I saw "env_*" stuff in the "ifndef CONFIG_SPL_BUILD" section, > but later some of it shows up in "ifdef CONFIG_SPL_BUILD" as well. > > So, do you want a v2, or is it OK because it's not interactive? In > the latter case should env_callback.o be removed from the SPL > build? Lets do a v2 (since the commit message would have been wrong) and add in a comment saying SPL doesn't have interactive environment, so we don't need this code. > Also, env_nvedit.o, env_common.o, and env_flash.o are included for > SPL regardless of CONFIG_SPL_NET_SUPPORT. In fact it looks like > env_nvedit.o will be included twice if CONFIG_SPL_NET_SUPPORT is > enabled. :-P Since I'd assume 'sort' in make isn't sort -u, I'm not sure how it's filtering out the dupes unless we don't really need it afterall, am335x_evm builds with CONFIG_SPL_NET_SUPPORT enabled. I'm curious now, so I'm poking it. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQz26oAAoJENk4IS6UOR1WpL0QAJY0PussCOcq+B4Rr2eagtQj e4glJMGst//JKi8hhGac35QhbyAXIJJDO++QET6PUxItUs+ltPci9884gSfe3wvp 6mSB3UKtKVHhMckcVptOTDhrDqwBCDBUFEPKosONJTYRP0s0vOj3E92bAU+z0CJ4 JyVj94lEvstdNxUKHKxRsxu6PF+okSOb/q9X0efx/boxeuyqPUoT15B0zNrtz4kd G31Efjy0sP1HrSp73zvSFoVV2N6p+MbKoFJgxM8seRg+JsPRj7DYCnuGn1l/Hj9m vc+2UMsf9az8+p1333QejYgtFYEmcvrwXXrp4Dcg2e1DCD2mEpmVtCkdI3SFdKvs CbHUuJ9Uc3CACjo4TtH5V7ZiiDwC8+gsO1ucxmng7/Ezr1XCFLOs4nJZKTUXiqwh ZBXaGaApBTCi8vClPyH6jYycjgnKIT3R5bcWIjD8ArhpOypy1J3V2/xqqCJhmyzD gZa1Ym0NXnJ2bSdu2RWcYGyGOt9BLdlpr3nMb03ZdRr2jiy3KktGh2gptDGhz8jk HQ9IS3jUXEQK4QD+UoKYdNfUSbC3G6e6ISM8otCHDVQO4cef/04bT3sBnvo/oUwD RiBSxEDE/Gs9m4UHRuroI3bS+bqNjjdmQXSnq39cST3z+y6qMs7TpkN0iHKWoikz /d7+lr2MD61cneVS5/cj =kOOU -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: don't generate callback list entries for SPL
Dear Tom,
In message <50cf6ea8.4050...@ti.com> you wrote:
>
> Since I'd assume 'sort' in make isn't sort -u, I'm not sure how it's
> filtering out the dupes unless we don't really need it afterall,
> am335x_evm builds with CONFIG_SPL_NET_SUPPORT enabled. I'm curious
> now, so I'm poking it.
Wrong assumption.
RTFM shows:
`$(sort LIST)'
Sorts the words of LIST in lexical order, removing duplicate
words. The output is a list of words separated by single spaces.
Thus,
$(sort foo bar lose)
returns the value `bar foo lose'.
Incidentally, since `sort' removes duplicate words, you can use it
for this purpose even if you don't care about the sort order.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
[Doctors and Bartenders], We both get the same two kinds of customers
-- the living and the dying.
-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: don't generate callback list entries for SPL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/12 14:55, Wolfgang Denk wrote: > Dear Tom, > > In message <50cf6ea8.4050...@ti.com> you wrote: >> >> Since I'd assume 'sort' in make isn't sort -u, I'm not sure how >> it's filtering out the dupes unless we don't really need it >> afterall, am335x_evm builds with CONFIG_SPL_NET_SUPPORT enabled. >> I'm curious now, so I'm poking it. > > Wrong assumption. > > RTFM shows: > > `$(sort LIST)' Sorts the words of LIST in lexical order, removing > duplicate words. The output is a list of words separated by single > spaces. Thus, > > $(sort foo bar lose) > > returns the value `bar foo lose'. > > Incidentally, since `sort' removes duplicate words, you can use it > for this purpose even if you don't care about the sort order. Which means the Makefile is just a tad messy instead, thanks. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQz3lzAAoJENk4IS6UOR1WaSoP/AifZ5fTG9NiguJJnT9/q3D/ 9smKp39e8BfrtZ3QVk3ivlyN1fe6Ssgltl6VBBRc2oianwHAlxmb0+LDCC/X/WOc 88HYt7P1zmvkPWoaZ3H43qfYhTTmNviAk56w9bqIfGv6KC5a05+D9USCvP3X0EJ6 4uXKpwHj8V5+Tmi2GAvm1modeSVUvHvgko7Kte5QsrIYAiLq35nIAdjHwwPuv9zL HI484xsOYaRWfOGdphzJ/5io9dohWwwHzyEHyJYq/fQ3al777fEWQHxt6ZEcVkTO ysM/G2G0JxS3Btuq7R5LwJxKdzFKruTUtWwgoCi1YTVsSttAZ+z4p6py3Ju+81EF HplhQDpyNH/9OkSWMq5+IUDHgiNZKsSuE0AqLTFl/5C5zhni+y54mJ4mL3/jknfq aswCopSURTPsCnUBp9cdyq0wMBEUY8TjdnfLR5igM34YryL96oLTQiGwhMiGxwQN c1xXfyN4r+Fmalcb/5aeNa4+YBxdsVWntz958M3g59i59mETbWEWYlR1spqzl0FD DCQVdIo+h0HKNkPWHonBx9CCMzW59NGqGvfgAgD3FxRJwF+loQ/hKlIRNguOhY0F oFVKPq1kzm3AQkNrX/1fJHMXUNLKNyBTLKTRSH0sfqA2yaWlGChL6yyNJzfCgweH PyY7VaRODfQ/Ivra8FaL =/G2K -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: don't generate callback list entries for SPL
Hi Tom, On Mon, Dec 17, 2012 at 1:58 PM, Tom Rini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/17/12 14:55, Wolfgang Denk wrote: >> Dear Tom, >> >> In message <50cf6ea8.4050...@ti.com> you wrote: >>> >>> Since I'd assume 'sort' in make isn't sort -u, I'm not sure how >>> it's filtering out the dupes unless we don't really need it >>> afterall, am335x_evm builds with CONFIG_SPL_NET_SUPPORT enabled. >>> I'm curious now, so I'm poking it. >> >> Wrong assumption. >> >> RTFM shows: >> >> `$(sort LIST)' Sorts the words of LIST in lexical order, removing >> duplicate words. The output is a list of words separated by single >> spaces. Thus, >> >> $(sort foo bar lose) >> >> returns the value `bar foo lose'. >> >> Incidentally, since `sort' removes duplicate words, you can use it >> for this purpose even if you don't care about the sort order. Not only can you, that's the only reason it's added to those Makefiles. > Which means the Makefile is just a tad messy instead, thanks. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/58] ixp: Move timestamp to arch_global_data
Hi Marek,
On Fri, Dec 14, 2012 at 5:31 AM, Marek Vasut wrote:
> Dear Simon Glass,
>
>> Move this field into arch_global_data and tidy up.
>>
>> Signed-off-by: Simon Glass
>
> I think we should kill IXP. Did the IXP custodian show any activity? If not,
> let's just remove this piece of junk.
Not sure, quite possibly. I have tried to keep everything building for now.
>
> Otherwise Acked-by: Marek Vasut
>
Regards,
Simon
>> ---
>> Changes in v2: None
>>
>> arch/arm/cpu/ixp/timer.c |8
>> arch/arm/include/asm/global_data.h |6 +++---
>> 2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/cpu/ixp/timer.c b/arch/arm/cpu/ixp/timer.c
>> index 0450b51..663d989 100644
>> --- a/arch/arm/cpu/ixp/timer.c
>> +++ b/arch/arm/cpu/ixp/timer.c
>> @@ -70,14 +70,14 @@ unsigned long long get_ticks(void)
>>
>> if (readl(IXP425_OSST) & IXP425_OSST_TIMER_TS_PEND) {
>> /* rollover of timestamp timer register */
>> - gd->timestamp += (0x - gd->arch.lastinc) + now + 1;
>> + gd->arch.timestamp += (0x - gd->arch.lastinc) + now +
>> 1;
>> writel(IXP425_OSST_TIMER_TS_PEND, IXP425_OSST);
>> } else {
>> /* move stamp forward with absolut diff ticks */
>> - gd->timestamp += (now - gd->arch.lastinc);
>> + gd->arch.timestamp += (now - gd->arch.lastinc);
>> }
>> gd->arch.lastinc = now;
>> - return gd->timestamp;
>> + return gd->arch.timestamp;
>> }
>>
>>
>> @@ -86,7 +86,7 @@ void reset_timer_masked(void)
>> /* capture current timestamp counter */
>> gd->arch.lastinc = readl(IXP425_OSTS_B);
>> /* start "advancing" time stamp from 0 */
>> - gd->timestamp = 0;
>> + gd->arch.timestamp = 0;
>> }
>>
>> ulong get_timer_masked(void)
>> diff --git a/arch/arm/include/asm/global_data.h
>> b/arch/arm/include/asm/global_data.h index 95e23e1..35d07d0 100644
>> --- a/arch/arm/include/asm/global_data.h
>> +++ b/arch/arm/include/asm/global_data.h
>> @@ -41,6 +41,9 @@ struct arch_global_data {
>> unsigned long tbl;
>> unsigned long lastinc;
>> unsigned long long timer_reset_value;
>> +#ifdef CONFIG_IXP425
>> + unsigned long timestamp;
>> +#endif
>> };
>>
>> /*
>> @@ -65,9 +68,6 @@ typedef struct global_data {
>> #ifdef CONFIG_FSL_ESDHC
>> unsigned long sdhc_clk;
>> #endif
>> -#ifdef CONFIG_IXP425
>> - unsigned long timestamp;
>> -#endif
>> unsigned long relocaddr; /* Start address of U-Boot in RAM */
>> phys_size_t ram_size; /* RAM size */
>> unsigned long mon_len;/* monitor len */
>
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/14/12 17:26, Wolfgang Denk wrote: > Dear Tom Rini, > > In message <50cb8ed1.7020...@ti.com> you wrote: >> >> The other part is, take a look at the Allwinner thread from a >> week or so ago. We really need to define how we want early board >> specific data to come in because if we start saying we'll accept >> per-SoC solutions we'll be drowning in them in short time. We >> want to say here's our preferred way to pass this information >> in. > > ACK! > > And we already have a well-defined way to do this, which is the > device tree. So any attempts to implement something different > should be reviewed very carefully. Exactly. We are not yet making as much use of the device tree as we can/should, which is where at least part of the hurdle is. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQz4jNAAoJENk4IS6UOR1Wx+0P+wQuv3IKoCrhVCC4GXbCcGmZ 2XnE8dum/MnlpHBKETnvAqDmr8TV2JQc/34Efm6d+6A67OYDDcu7cD1wt+/aTFuw uYVZkWMEeGncdzZaHYTev9NK/YVikMbYezxF+PravzXaIblGpZGWw/xgBljemnBL smjugTtWNOz6vDu45g2+dFIg92jDxuP4rznJrOEkF6QG03Ll8tI1WBAK+s079vmk gkeTsTQnlOMsEtK++K8kNPoz5EK6JpPfAlmJKhv8P/Msfs0TR428JPtv/G9zKJkw 2VBk6Ru82xn7l7ygKSQqwiMRWygbsYzb1AX3hab+KjmsuCU+2UUZGYQMqv2aqY4U 4Uw1Pw21Q3eQNmHt16AIyQqB9PF1Byw11TmkjZrrm78Xbr/euCc9FtZoU6yB5y/T zpSSA/kgqoY0UTyHhMEpdDYXrmeScRBrs7MSHxTTA4gS92Ng0bmlPtkJZUG8iWTR hqKCRJj+2ymZzDh5e5nUYH60C4b2R2sW2eGJDEMmmB2yoGI2Jj6O3x4PAy25wvd1 dK2p03rYVgeFIw+wFeC7FD3ssidUq+l8Z9fDm2o1jQWmH3bJlC3zbftq39DJcTW0 PsRCk/a46oqDJuhUU1tbs5osgw220+1up3Xw/WldJ65wtwizsByHCUQ0aS+Y8qzG Fy29qoQxjn5u/C/bjfwn =CQyA -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/12 17:45, Stephen Warren wrote:
> On 12/14/2012 03:22 PM, Simon Glass wrote:
>> Hi Stephen,
> ...
>> Perhaps I can make the point another way. Assuming that the SOC
>> in question is ARM-based and has Linux support it either supports
>> FDT now or presumably will fairly soon.
>
> Sure, but I'm *explicitly* avoiding relying on DT for this,
> because there are plenty of things that happen before DT can or
> should be touched that might warrant serial port output.
Also totally true and valid. But what I'd like to see is:
parse_odmdata(void *ptr) {
if (ptr->console)
device_tree_register_uart(... fake it ...);
}
In other words, if we add the register a port call now, there's a
history of adding just one more thing, by someone else (say am335x and
our EVMs that differ on where primary UART is, and only need a little
different logic to say 'oh! this one.') and making a mess of things.
Once we deal with device trees in some manner, then we can just fake
their existence at this point and pass in the console information from
ODMDATA.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQz4n3AAoJENk4IS6UOR1WrqoP/0glYuxrrrn9hgZa4WOhKhCd
K14da+7svtAdZLEFNVzbBb67sMsK9f0BH3PiesIxDBU2wAj7CgAZMpkedyAhwPjY
/oX8ywaWouckSrtVe1k4FTT7yPJOW6WlljaOFypHvt5VWRfhKJ6kdlMlkAiPPMEY
ng8cE1YKcbZZD9RsxhMpW6+OGVN9iRcFDSDW3EvPpvQaIl5hp3LYcKnQvNi7I3kE
edGIdzakPjxtJTVv8KiPuIOhYtYlTUvgcaeLgqbm9g/57z01Cz+SrAAaHXR8qxOv
pwwR53owgh6Cb033QEClP9mDGrd9QOXs9mkZm/GxhTFI4bWS3qJXvh2I73NUVL3Y
OrN0XfoLX5RZzkk/oYUV46OsI6oxPOImH4KEDFm2ST/twni813DIEtPGcotrWZm4
oSKYxONOvofaRalcwH+P89Iq8zLWgjglWwNoOCgItWjhwvY75q/RCQPB2vOkSFtb
/Vt4Do5HeqfmR6XPHHvP0dUCZ2IS0/Xh7w+OO44HakDLESiWfnfr/dWSmTiiqBA+
wfWDMhE+pK/fnz3CG4eAOEUQ7Y7Uh3jGo42WpthpCuY0ZltnhyEHwmPJ6MuwAqbs
EDUXSbNnpLOC9iIRKnT6J0hkhONp/ip+1Mad2hsVluAMmqYBTdM7rKi/kuV0HdYl
LPh6xToy9xyUgkllZZbw
=nUfP
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/14/12 17:22, Simon Glass wrote: [snip] > Perhaps I can make the point another way. Assuming that the SOC in > question is ARM-based and has Linux support it either supports FDT > now or presumably will fairly soon. We found that some of the > things we want to know about at the low level are hardware > properties that are already sit in a node in the FDT. For example > the memory controller may have information about the memory type > attached to it. > > Given this, my suggestion is that this hardware information be kept > in one place (FDT) where possible, even if it unfortunately > temporarily needs to be translated into some simpler format as part > of the SPL build for efficiency reasons. Exactly. The fewer places we have to write down the details the better. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQz4n7AAoJENk4IS6UOR1WkQYP/RcnxKDaMLKdT9j+rQ+FEKtS s0vl4v8OFRMetmVzPqeMndHMk4IIbMFOgW58tiYnVZm0iJNCZDr/WyIiU0XRLmkl jWPl8qszw/9l5EkgOWOmPK4r9fBhv0QLGonyBMU3chUI6/uVH/fZXMm7m+f3rwS6 9JSiA+E+VAhSwFMgNeLyk4H85xyIDu3tH4q8hqWQ2c223sgTuZPD2/f3EUQ+KyrX 3Rk133/2LLeJHkXqwkJhYkhNgvvooHy/5SeUuv4LRsLDV3xqoo7mpJ1NREtinthN PnoiJP3wTDUffSe38kk0VKjQ//xaYuM28PfrTpZQ0O82GPOlSko4M0rpekWpFdiP Mvqf2LK01QqbxNF/dllwlv2AeU2hR2m2j8cSsT+Ugo1E9tLl/P+/ziXR2zMkbDe/ zJCzJmG3L9p7EtSzsReguUPNonsimxNlpDIhOBGdiob6W9jfKELIYHWoWI3O8tJr GhGmujoo/zmEa6berP2hDB0qs+lHXU3fk57wc+aIeOXKfTadqRoWhqSy4FeYlDHX yYyEOkOntmC61e3lJR01wmLUsPkHjLVRkfT3xR9ivTIhkAoQaSRJC1WoEPzlM7qU VTwnKkE9jlDl7n2ASXKa0A+r2hBaagV8i6rJceR+2z4CVrPOl1tJUFARAmRbxZWV WfxpfY0IMEbCpQ46Jhif =3dA/ -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling
Allen, If you come up with patches to fix the seaboard config files, I can add them to my copy of u-boot-tegra/master, push it to denx, and generate a pull request for Albert if you want. Tom On Sat, Dec 15, 2012 at 9:41 AM, Albert ARIBAUD wrote: > Hi Allen, > > On Tue, 11 Dec 2012 11:02:09 -0800, Allen Martin > wrote: >> On Mon, Dec 10, 2012 at 01:51:40PM -0800, Tom Warren wrote: >> > Albert, >> > >> > > On Sat, Dec 8, 2012 at 11:03 PM, Albert ARIBAUD >> > > wrote: >> > >> Hello, >> > >> >> > >> It seems like two commits 5ddcc38b (in u-boot, committed by Marek) >> > >> 29f3e3f2 (in u-boot-arm, committed by Tom from u-boot-tegra) are >> > >> conflicting on the seaboard configuration header file for USB (and >> > >> possibly other areas). >> > >> > One possible problem is that I've got new commits ready in >> > u-boot-tegra/next that were almost ready for a pull request, so I >> > copied them over to my tegra/master branch and pushed to >> > u-boot-tegra/master on denx. I assumed that once I got the 'applied >> > to u-boot-arm/master' response from you, that I could stage the next >> > pull request. But if you (or Allen) are pulling from >> > u-boot-tegra/master )or /next), you're gonna get commits that haven't >> > been merged into u-boot-arm/master. >> > >> > I can push the older tegra/master branch back to denx.de (the one that >> > I requested a pull from on Nov 19th) if that'll help. But I'm not >> > sure how it would help, since all those commits should have been >> > present in u-boot-arm/master (from my pull request) when you went to >> > merge w/u-boot/master. >> > >> > So I'm still not seeing how the conflict arose, or what the path is to >> > fixing it. >> > >> >> The conflict came from my config file changes for tegra USB keyboard >> which went up to u-boot/master through Marek's tree becasue they >> depend on my USB DMA alignment fix which was not a tegra change. >> There are subsequent changes in both the tegra and arm trees that were >> not based on that change, so they now conflict when attempting to >> merge back into u-boot/master. >> >> It's trivial for me to resolve the conflict since I have context on >> the changes. I see that there are other merge conflicts between >> u-boot/master and u-boot-arm/master though, so I'm not sure how to >> proceed. Albert do you just want me to post merged versions of the >> two files that conflict, so you know how to resolve the conflict >> during your merge? > > I would like you to post a pull request that would fix the two file > conflicts; I have asked other people to fix other merge conflicts. I > will merge all fix branches in one go (so that u-boot-arm keeps > building clean) once all fix branches are available. > > Amicalement, > -- > Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling
On Mon, Dec 17, 2012 at 02:13:29PM -0800, Tom Warren wrote: > Allen, > > If you come up with patches to fix the seaboard config files, I can > add them to my copy of u-boot-tegra/master, push it to denx, and > generate a pull request for Albert if you want. > The conflicting changes have already been merged to u-boot-arm/master, Albert were you planning to replay the merge of the already merged tegra patches? -Allen > Tom > > On Sat, Dec 15, 2012 at 9:41 AM, Albert ARIBAUD > wrote: > > Hi Allen, > > > > On Tue, 11 Dec 2012 11:02:09 -0800, Allen Martin > > wrote: > >> On Mon, Dec 10, 2012 at 01:51:40PM -0800, Tom Warren wrote: > >> > Albert, > >> > > >> > > On Sat, Dec 8, 2012 at 11:03 PM, Albert ARIBAUD > >> > > wrote: > >> > >> Hello, > >> > >> > >> > >> It seems like two commits 5ddcc38b (in u-boot, committed by Marek) > >> > >> 29f3e3f2 (in u-boot-arm, committed by Tom from u-boot-tegra) are > >> > >> conflicting on the seaboard configuration header file for USB (and > >> > >> possibly other areas). > >> > > >> > One possible problem is that I've got new commits ready in > >> > u-boot-tegra/next that were almost ready for a pull request, so I > >> > copied them over to my tegra/master branch and pushed to > >> > u-boot-tegra/master on denx. I assumed that once I got the 'applied > >> > to u-boot-arm/master' response from you, that I could stage the next > >> > pull request. But if you (or Allen) are pulling from > >> > u-boot-tegra/master )or /next), you're gonna get commits that haven't > >> > been merged into u-boot-arm/master. > >> > > >> > I can push the older tegra/master branch back to denx.de (the one that > >> > I requested a pull from on Nov 19th) if that'll help. But I'm not > >> > sure how it would help, since all those commits should have been > >> > present in u-boot-arm/master (from my pull request) when you went to > >> > merge w/u-boot/master. > >> > > >> > So I'm still not seeing how the conflict arose, or what the path is to > >> > fixing it. > >> > > >> > >> The conflict came from my config file changes for tegra USB keyboard > >> which went up to u-boot/master through Marek's tree becasue they > >> depend on my USB DMA alignment fix which was not a tegra change. > >> There are subsequent changes in both the tegra and arm trees that were > >> not based on that change, so they now conflict when attempting to > >> merge back into u-boot/master. > >> > >> It's trivial for me to resolve the conflict since I have context on > >> the changes. I see that there are other merge conflicts between > >> u-boot/master and u-boot-arm/master though, so I'm not sure how to > >> proceed. Albert do you just want me to post merged versions of the > >> two files that conflict, so you know how to resolve the conflict > >> during your merge? > > > > I would like you to post a pull request that would fix the two file > > conflicts; I have asked other people to fix other merge conflicts. I > > will merge all fix branches in one go (so that u-boot-arm keeps > > building clean) once all fix branches are available. > > > > Amicalement, > > -- > > Albert. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
On 12/17/2012 02:09 PM, Tom Rini wrote:
> On 12/14/12 17:45, Stephen Warren wrote:
>> On 12/14/2012 03:22 PM, Simon Glass wrote:
>>> Hi Stephen,
>> ...
>>> Perhaps I can make the point another way. Assuming that the SOC
>>> in question is ARM-based and has Linux support it either supports
>>> FDT now or presumably will fairly soon.
>
>> Sure, but I'm *explicitly* avoiding relying on DT for this,
>> because there are plenty of things that happen before DT can or
>> should be touched that might warrant serial port output.
>
> Also totally true and valid. But what I'd like to see is:
> parse_odmdata(void *ptr) {
> if (ptr->console)
> device_tree_register_uart(... fake it ...);
> }
Sorry, I'm having a hard time parsing:
> In other words, if we add the register a port call now, there's a
By "register a port call", do you mean the device_tree_register_uart()
you're proposing above, or the NS16550_set_dynamic_address() I'd
implemented in my patch?
Below, you appear to be pointing out problems with adding the "register
a port call now" which seems like you're arguing against your own example?
> history of adding just one more thing, by someone else (say am335x and
> our EVMs that differ on where primary UART is, and only need a little
> different logic to say 'oh! this one.') and making a mess of things.
> Once we deal with device trees in some manner, then we can just fake
> their existence at this point and pass in the console information from
> ODMDATA.
There are many ways besides device tree to enumerate hardware. For
example, consider PCI or USB (albeit USB isn't memory mapped). I don't
think we should tie any new U-Boot dynamic device registration API to
device tree, since that would seem to prevent (or imply against) usage
of that API with PCI for example.
Perhaps this is just bike-shedding over naming?
So, perhaps:
int device_register_uart(enum uart_type, u32 base_address)
So that all of the following cases could call that:
* DT parsing.
* PCI device enumeration.
* ODMDATA parsing.
(and where enum uart_type is some internal U-Boot identifier for the
UART drivers it supports)
Presumably the implementation would validate if the (uart_type,
base_address) combination had been seen already, and then do nothing.
that would allow for ODMDATA parsing to set up the UART, and then DT
parsing to avoid any special cases to skip handling DT nodes for serial
devices that were already registered.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Dear Stephen Warren, In message <50cf9baa.3050...@wwwdotorg.org> you wrote: > > There are many ways besides device tree to enumerate hardware. For > example, consider PCI or USB (albeit USB isn't memory mapped). I don't Yes, there are. But your console port cannot be compred against dynamically populated and scannable bus interfaces like USB or PCI, and I think you are aware of that. > think we should tie any new U-Boot dynamic device registration API to > device tree, since that would seem to prevent (or imply against) usage > of that API with PCI for example. Not any dynamic device registration. But here, it actually AIN'T dynamic - it is fully static, just board dependent. > Perhaps this is just bike-shedding over naming? No. > So that all of the following cases could call that: > > * DT parsing. > * PCI device enumeration. > * ODMDATA parsing. NAK. This is totally wrong. ODMDATA is just a different representation of information that could as well be encoded in a DT. PCI or USB bus scanning gives information which cannot be encoded in a DT passed to U-Boot (at least not unless you dynamically generate that DT using some other softeware performing such a bus scan). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you hear an onion ring, answer it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
On 12/17/2012 03:37 PM, Wolfgang Denk wrote: > Dear Stephen Warren, > > In message <50cf9baa.3050...@wwwdotorg.org> you wrote: >> >> There are many ways besides device tree to enumerate hardware. For >> example, consider PCI or USB (albeit USB isn't memory mapped). I don't > > Yes, there are. But your console port cannot be compred against > dynamically populated and scannable bus interfaces like USB or PCI, > and I think you are aware of that. I honestly don't know why you couldn't have a PCI-based console UART. >> think we should tie any new U-Boot dynamic device registration API to >> device tree, since that would seem to prevent (or imply against) usage >> of that API with PCI for example. > > Not any dynamic device registration. But here, it actually AIN'T > dynamic - it is fully static, just board dependent. If you want to run the same U-Boot binary on multiple different boards, then that does make the UART selection dynamic. There's no conceptual difference between dynamic information coming from a DT passed to U-Boot at runtime, SoC-defined enumeration/selection mechanisms such as Tegra's ODMDATA, or scanning a PCI bus. Or, is U-Boot going to ban addressing TI's case where the UART selection is stored in an I2C EEPROM that can be read at run-time, since instead during flashing that information could be extracted and hard-coded into the board's device tree instead? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] imls: Add support to list images in NAND device
On 12/17/2012 02:22:40 AM, Vipin Kumar wrote:
On 12/14/2012 11:40 PM, Scott Wood wrote:
On 12/14/2012 03:32:04 AM, Vipin Kumar wrote:
+
+ switch (genimg_get_format(buffer)) {
+ case IMAGE_FORMAT_LEGACY:
+ header = (const image_header_t *)buffer;
+ len = image_get_image_size(header);
+
+ ret = nand_imls_legacyimage(nand,
nand_dev,
+ off, len);
+ if (ret< 0&& ret != -ENOMEM)
+ return ret;
+ break;
+#if defined(CONFIG_FIT)
+ case IMAGE_FORMAT_FIT:
+ len = fit_get_size(buffer);
+ ret = nand_imls_fitimage(nand, nand_dev,
+ off, len);
+ if (ret< 0&& ret != -ENOMEM)
+ return ret;
+ break;
+#endif
+ }
Do you really mean to return from the main imls function just
because
one image has an error? By "use return" I meant return from the
subfunction.
This return only corresponds to the situation when there is an error
returned from nand read routine. In that case, I don't think there
is
any use reading the NAND any further.
Just because one page has an uncorrectable error doesn't mean the
entire NAND is bad. Note that this is different from what you
currently do if you get an error on the initial read where you look
for
a header.
Yes, I got your point.
I would now not announce the uncorrectable errors as they may hog the
whole stdout and still continue to work for the whole NAND device.
Please check the implementation in v4
I'd rather see errors be announced, with some reasonable limit on how
many (and a message indicating if further errors exist that were
suppressed).
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend] armv7/ltimer: Add support for local timer on armv7 cpus
On 12/17/2012 11:20 PM, Wolfgang Denk wrote: Dear "Dennis Lan (dlan)", In message you wrote: What would be the use of such timer support? Is there any code that actually needs it, and why does it need anything beyond the existing timer support we have? I think vipin here is trying to provide a generic timer support for ARMV7 architecture, which contains private(local) and global timer. It's general a good thing which means we can maximize the code usage.. Sorry, I don't get it. Why would we need separate global and local timers? And what exactly is "local" here - local to what? We don't need anything like that on other architectures - so why here? Let me start afresh. There are two timer peripherals (called as local and global) built into armv7 cores. The local timer is specific to each processor while the global timer is common for all cores. These timers may be initialized and used for timer operations in armv7 based SoCs "general a good thing" sounds like "nice to have", and this is usually something we don't really need, especially not in a boot loader. This is nothing but a timer peripheral driver. The timer is a part of armv7 core so it is kept in arch/arm/cpu/armv7 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407i/index.html Regards Vipin Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] imls: Add support to list images in NAND device
On 12/18/2012 5:35 AM, Scott Wood wrote:
On 12/17/2012 02:22:40 AM, Vipin Kumar wrote:
On 12/14/2012 11:40 PM, Scott Wood wrote:
On 12/14/2012 03:32:04 AM, Vipin Kumar wrote:
+
+ switch (genimg_get_format(buffer)) {
+ case IMAGE_FORMAT_LEGACY:
+ header = (const image_header_t *)buffer;
+ len = image_get_image_size(header);
+
+ ret = nand_imls_legacyimage(nand,
nand_dev,
+ off, len);
+ if (ret< 0&& ret != -ENOMEM)
+ return ret;
+ break;
+#if defined(CONFIG_FIT)
+ case IMAGE_FORMAT_FIT:
+ len = fit_get_size(buffer);
+ ret = nand_imls_fitimage(nand, nand_dev,
+ off, len);
+ if (ret< 0&& ret != -ENOMEM)
+ return ret;
+ break;
+#endif
+ }
Do you really mean to return from the main imls function just because
one image has an error? By "use return" I meant return from the
subfunction.
This return only corresponds to the situation when there is an error
returned from nand read routine. In that case, I don't think there is
any use reading the NAND any further.
Just because one page has an uncorrectable error doesn't mean the
entire NAND is bad. Note that this is different from what you
currently do if you get an error on the initial read where you look for
a header.
Yes, I got your point.
I would now not announce the uncorrectable errors as they may hog the
whole stdout and still continue to work for the whole NAND device.
Please check the implementation in v4
I'd rather see errors be announced, with some reasonable limit on how
many (and a message indicating if further errors exist that were
suppressed).
Hmm, OK. I would do it this way in v5
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] RFC: Secure boot framework
Hi, Can anyone comment on what has been discussed about a framework for secure boot and authentication, if there has been such a discussion, in the community? I have some U-boot code that is based off of a slightly older U-boot which does authentication and/or decryption. The main code that does the cryptography is in the ROM of the SoC. However, I'm sure there will be other U-boot developers requiring the crypto algorithms itself to be supported. My questions are : (1) Would a general framework for performing authentication and/or decryption of signed and/or encrypted images be useful for U-boot? These operations seem to make a lot of sense for a bootloader. (2) Does such a framework make sense for any of your usecase(s)? (3) Has there been any work or discussions of coming up with such a framework for U-boot? I imagine a framework like this will atleast consist of: 1. General purposes cryptographic functions in a library (which we might not need for our case), some light weight crypto library. 2. Hooks for board/Soc-specific functions that call into the general crypto lib and do any other board/SoC-specific stuff. 3. General commands (in a cmd_crpto.c) that calls into the callbacks mentioned in 2. for encryption and verification of an image already in memory. (making it commands can allow us to leave bootm alone and do the inplace decryption/verification independently - however for SPL, we don't need the commands and call into 2. directly). 4. Abstract any other change(s) to common boot code in a common place. Let me know your suggestions, thanks. Regards, Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Dear Stephen, In message <50cfa394.40...@wwwdotorg.org> you wrote: > > > Yes, there are. But your console port cannot be compred against > > dynamically populated and scannable bus interfaces like USB or PCI, > > and I think you are aware of that. > > I honestly don't know why you couldn't have a PCI-based console UART. This is actually another question. You cannot compare a statically configured UART port (where all configuration information you need is the index into the table of possible UARTs) to a dynamic bus scan where you cannot know in advance whether you detect any devices at all, or how many, or which types. You will have hard times using a PCI or USB based console port for early console output because the majority of the PCI and USB related code will only be runnable after relocation. > > Not any dynamic device registration. But here, it actually AIN'T > > dynamic - it is fully static, just board dependent. > > If you want to run the same U-Boot binary on multiple different boards, > then that does make the UART selection dynamic. There's no conceptual > difference between dynamic information coming from a DT passed to U-Boot > at runtime, SoC-defined enumeration/selection mechanisms such as Tegra's > ODMDATA, or scanning a PCI bus. Maybe there is no conceptual difference - but only if you chose to look at things at a relatively high abstraction level. Implementation-wise the difference it between passing a single integer variable (the UART index) and performing a dynamic bus scan, detecting number and type of devices and selecting appropriate drivers. > Or, is U-Boot going to ban addressing TI's case where the UART selection > is stored in an I2C EEPROM that can be read at run-time, since instead > during flashing that information could be extracted and hard-coded into > the board's device tree instead? Here again we are talking about a UART, which is statically confgured per board, and we just need this specific piece of board information. And yes, this piece of information should be encoded in the device tree. Note that the "hard-coded" you mantion has never been made a requirement. For simplicity of design it might make sense to actually use the DT format for such information right away. But as your own example shows, not all chip / board vendors do that. Simon and Tom already commented on what to do in such situations. It seems Simon, Tom and me mostly agree on what to do. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You have the capacity to learn from mistakes. You'll learn a lot today. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/phy: fix select line for TN80xx
TN80xx has same PHY ID as TN2020, but it needs different setting to register
30.93 which used to select line, so we read register 30.32 which has
bit 15:12 to indicate PHY hardware version, for TN20xx we will get 3 or 2,
for TN80xx we will get 5 or 4.
Signed-off-by: Shaohui Xie
---
drivers/net/phy/teranetics.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/teranetics.c b/drivers/net/phy/teranetics.c
index 78447b7..c0f13b8 100644
--- a/drivers/net/phy/teranetics.c
+++ b/drivers/net/phy/teranetics.c
@@ -34,9 +34,20 @@ int tn2020_config(struct phy_device *phydev)
unsigned short restart_an = (MDIO_AN_CTRL1_RESTART |
MDIO_AN_CTRL1_ENABLE |
MDIO_AN_CTRL1_XNP);
+ u8 phy_hwversion;
- phy_write(phydev, 30, 93, 2);
- phy_write(phydev, MDIO_MMD_AN, MDIO_CTRL1, restart_an);
+ /*
+* bit 15:12 of register 30.32 indicates PHY hardware
+* version. It can be used to distinguish TN80xx from
+* TN2020. TN2020 needs write 0x2 to 30.93, but TN80xx
+* needs 0x1.
+*/
+ phy_hwversion = (phy_read(phydev, 30, 32) >> 12) & 0xf;
+ if (phy_hwversion <= 3) {
+ phy_write(phydev, 30, 93, 2);
+ phy_write(phydev, MDIO_MMD_AN, MDIO_CTRL1, restart_an);
+ } else
+ phy_write(phydev, 30, 93, 1);
}
return 0;
--
1.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: Secure boot framework
Hi Joel, On Mon, Dec 17, 2012 at 9:11 PM, Fernandes, Joel A wrote: > Hi, > > Can anyone comment on what has been discussed about a framework for secure > boot and authentication, if there has been such a discussion, in the > community? > > I have some U-boot code that is based off of a slightly older U-boot which > does authentication and/or decryption. The main code that does the > cryptography is in the ROM of the SoC. However, I'm sure there will be > other U-boot developers requiring the crypto algorithms itself to be > supported. > > My questions are : > (1) Would a general framework for performing authentication and/or > decryption of signed and/or encrypted images be useful for U-boot? These > operations seem to make a lot of sense for a bootloader. > (2) Does such a framework make sense for any of your usecase(s)? > > (3) Has there been any work or discussions of coming up with such a > framework for U-boot? > We have created a secure boot system on top of U-Boot - it is in the Chromium tree if you want to take a look. Three ChromeOS devices have shipped with this so far. However it is not really suitable for generic upstream use, so... There have been some discussions lately on the list about using the FIT format to hold an image which can then be verified using a public key. We have put together a possible design for this and I am working on this as I make time. > I imagine a framework like this will atleast consist of: > > 1. General purposes cryptographic functions in a library (which we might > not need for our case), some light weight crypto library. > 2. Hooks for board/Soc-specific functions that call into the general > crypto lib and do any other board/SoC-specific stuff. > 3. General commands (in a cmd_crpto.c) that calls into the callbacks > mentioned in 2. for encryption and verification of an image already in > memory. (making it commands can allow us to leave bootm alone and do the > inplace decryption/verification independently - however for SPL, we don't > need the commands and call into 2. directly). > 4. Abstract any other change(s) to common boot code in a common place. > Yes that seems reasonable. A very basic hashing framework recently went into U-Boot, and this can be used to plumb in SOC hashing acceleration code. I suspect we will do the same with RSA, supporting a few different key lengths and associated padding. My plan at present is roughly (and in short order) to: 1. Define how signatures are represented in FIT 2. Enhance mkimage to sign an image or a configuration (consisting of image +fdt, for example) 3. Enhance FIT command to verify an image given a public key 4. Support checking of version information against a TPM rollback counter 5. Work this into the bootm code 6. Add RSA2048/4096 This would provide the pieces for verified boot, if not a full implementation. It should then be possible to do verified boot with a U-Boot script. If we get this far then it will provide a good basis for more advanced efforts. Regards, Simon > Let me know your suggestions, thanks. > > Regards, > Joel > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/7] omap mmc: implement card detect and write protection
Gentle ping. On 12/03/2012 02:19 PM, Nikita Kiryanov wrote: This patchset implements card detection and write protection check for omap mmc. The write protect implementation also adds generic code that is usable by other mmc drivers. The first 3 patches are preparation patches that contain general maintenance for omap mmc driver. This patchset depends on http://patchwork.ozlabs.org/patch/202384/ Nikita Kiryanov (7): omap: consolidate common mmc definitions omap_hsmmc: fix out of bounds array access omap_hsmmc: introduce omap_hsmmc_data struct omap_hsmmc: implement driver check for card detection cm-t35: implement board specific card detect check mmc: add support for write protection omap_hsmmc: add driver check for write protection arch/arm/cpu/armv7/am33xx/board.c |4 +- arch/arm/cpu/armv7/omap-common/boot-common.c|4 +- arch/arm/cpu/armv7/omap3/board.c|4 +- arch/arm/include/asm/arch-am33xx/mmc_host_def.h | 140 +-- arch/arm/include/asm/arch-omap3/mmc_host_def.h | 139 +-- arch/arm/include/asm/arch-omap4/mmc_host_def.h | 140 +-- arch/arm/include/asm/arch-omap5/mmc_host_def.h | 140 +-- arch/arm/include/asm/omap_mmc.h | 168 +++ board/cm_t35/cm_t35.c | 13 +- board/comelit/dig297/dig297.c |3 +- board/corscience/tricorder/tricorder.c |2 +- board/htkw/mcx/mcx.c|2 +- board/isee/igep0020/igep0020.c |3 +- board/isee/igep0030/igep0030.c |3 +- board/logicpd/am3517evm/am3517evm.c |3 +- board/logicpd/omap3som/omap3logic.c |2 +- board/logicpd/zoom1/zoom1.c |3 +- board/logicpd/zoom2/zoom2.c |3 +- board/matrix_vision/mvblx/mvblx.c |4 +- board/nokia/rx51/rx51.c |4 +- board/overo/overo.c |3 +- board/pandora/pandora.c |3 +- board/technexion/twister/twister.c |2 +- board/teejet/mt_ventoux/mt_ventoux.c|2 +- board/ti/am3517crane/am3517crane.c |3 +- board/ti/beagle/beagle.c|3 +- board/ti/evm/evm.c |3 +- board/ti/omap5_evm/evm.c|4 +- board/ti/panda/panda.c |3 +- board/ti/sdp3430/sdp.c |3 +- board/ti/sdp4430/sdp.c |4 +- board/timll/devkit8000/devkit8000.c |3 +- common/cmd_mmc.c|7 + drivers/mmc/arm_pl180_mmci.c|1 + drivers/mmc/bfin_sdh.c |1 + drivers/mmc/davinci_mmc.c |1 + drivers/mmc/fsl_esdhc.c |1 + drivers/mmc/ftsdc010_esdhc.c|1 + drivers/mmc/gen_atmel_mci.c |1 + drivers/mmc/mmc.c | 17 +++ drivers/mmc/mmc_spi.c |1 + drivers/mmc/mxcmmc.c|1 + drivers/mmc/mxsmmc.c|1 + drivers/mmc/omap_hsmmc.c| 78 +-- drivers/mmc/sdhci.c |1 + drivers/mmc/sh_mmcif.c |1 + drivers/mmc/tegra_mmc.c |1 + include/mmc.h |2 + 48 files changed, 324 insertions(+), 612 deletions(-) create mode 100644 arch/arm/include/asm/omap_mmc.h -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
