Re: [U-Boot] [PATCH v3 2/3] ARM:AM33XX: Add mmc/sd support
Hi Chandan, Tom,
On 01/03/12 08:42, Chandan Nath wrote:
This patch add supports for mmc/sd driver on AM335X platform.
PLL and pinmux configurations for mmc/sd are configured in this
patch.
Signed-off-by: Chandan Nath chandan.n...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
Changes since v2:
- No change
Changes since v1:
- Removed unwanted code from omap_hsmmc.c file
- Rebased to master branch
arch/arm/cpu/armv7/am33xx/board.c |7 +
arch/arm/cpu/armv7/am33xx/clock.c |5 +
arch/arm/include/asm/arch-am33xx/mmc_host_def.h | 164
+++
board/ti/am335x/mux.c | 20 +++
include/configs/am335x_evm.h|9 ++
5 files changed, 205 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-am33xx/mmc_host_def.h
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 78db3a5..312643c 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -64,3 +64,10 @@ void init_timer(void)
/* Start the Timer */
writel(0x1, (timer_base-tclr));
}
+
+#if defined(CONFIG_OMAP_HSMMC) !defined(CONFIG_SPL_BUILD)
+int board_mmc_init(bd_t *bis)
+{
+ return omap_mmc_init(0);
+}
I would suggest to make this definition weak,
so it can be overridden if needed by the board code.
+#endif
diff --git a/arch/arm/cpu/armv7/am33xx/clock.c
b/arch/arm/cpu/armv7/am33xx/clock.c
index 7070e7d..98cfd93 100644
--- a/arch/arm/cpu/armv7/am33xx/clock.c
+++ b/arch/arm/cpu/armv7/am33xx/clock.c
@@ -108,6 +108,11 @@ static void enable_per_clocks(void)
writel(PRCM_MOD_EN, cmwkup-wkup_uart0ctrl);
while (readl(cmwkup-wkup_uart0ctrl) != PRCM_MOD_EN)
;
+
+ /* MMC0*/
+ writel(PRCM_MOD_EN, cmper-mmc0clkctrl);
+ while (readl(cmper-mmc0clkctrl) != PRCM_MOD_EN)
+ ;
}
static void mpu_pll_config(void)
diff --git a/arch/arm/include/asm/arch-am33xx/mmc_host_def.h
b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h
new file mode 100644
index 000..e56c018
--- /dev/null
+++ b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h
@@ -0,0 +1,164 @@
+/*
+ * mmc_host_def.h
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef MMC_HOST_DEF_H
+#define MMC_HOST_DEF_H
+
+/*
+ * OMAP HSMMC register definitions
+ */
+#define OMAP_HSMMC1_BASE 0x48060100
+#define OMAP_HSMMC2_BASE 0x481D8000
+#define OMAP_HSMMC3_BASE 0x47C24000
+
+typedef struct hsmmc {
+ unsigned char res1[0x10];
+ unsigned int sysconfig; /* 0x10 */
+ unsigned int sysstatus; /* 0x14 */
+ unsigned char res2[0x14];
+ unsigned int con; /* 0x2C */
+ unsigned char res3[0xD4];
+ unsigned int blk; /* 0x104 */
+ unsigned int arg; /* 0x108 */
+ unsigned int cmd; /* 0x10C */
+ unsigned int rsp10; /* 0x110 */
+ unsigned int rsp32; /* 0x114 */
+ unsigned int rsp54; /* 0x118 */
+ unsigned int rsp76; /* 0x11C */
+ unsigned int data; /* 0x120 */
+ unsigned int pstate;/* 0x124 */
+ unsigned int hctl; /* 0x128 */
+ unsigned int sysctl;/* 0x12C */
+ unsigned int stat; /* 0x130 */
+ unsigned int ie;/* 0x134 */
+ unsigned char res4[0x8];
+ unsigned int capa; /* 0x140 */
+} hsmmc_t;
+
+/*
+ * OMAP HS MMC Bit definitions
+ */
+#define MMC_SOFTRESET(0x1 1)
+#define RESETDONE(0x1 0)
+#define NOOPENDRAIN (0x0 0)
+#define OPENDRAIN(0x1 0)
+#define OD (0x1 0)
Most of the names here are too generic,
but the above one is just...
OD - what does it stand for? Open Drain?
Then why do you have two of them (with the same value)?
+#define INIT_NOINIT (0x0 1)
+#define INIT_INITSTREAM (0x1 1)
+#define HR_NOHOSTRESP(0x0 2)
+#define STR_BLOCK(0x0 3)
+#define MODE_FUNC(0x0 4)
+#define DW8_1_4BITMODE (0x0 5)
+#define MIT_CTO (0x0 6)
+#define CDP_ACTIVEHIGH (0x0 7)
Re: [U-Boot] [PATCH] lsxl: add support for lschlv2 and lsxhl
Dear Michael, In message 201201030132.02862.mich...@walle.cc you wrote: If Buffalo is the vendor, then why do you add this to the Marvell vendor directory? I was just guessing. It is a Marvell SoC and marvell SoC boards of other vendors are in the Marvell/ directory, too. But i'm also happy with Buffalo/ (or buffalo/?). board/buffalo/, please. NAK. We do not allow such static network configurations. i've already guessed that ;) you may remember our lengthy discussions about the board which don't have a dedicated NVRAM for the ethernet address. Well, this is such a board. I would have expected more responses from other maintainers of this type of boards, esp. after the patch which removes the mac randomization from the ethernet driver, was merged. Actuaklly this is the standard case. Only a tiny minority of boards provide such storage for the MAC address. The overwhelming majority has none, and just uses the environment. So if #define CONFIG_ETHADDR xxx #define CONFIG_OVERWRITE_ETHADDR_ONCE is a no-no (i really dont see the point, why it's not allowed, sorry), i guess i have to maintain this on my own tree :( It is not allowed because a MAC address is a _unique_ identifier. Can you explain why you think it is needed at all? There are probably some 900+ board configurations which don't need it (only in mainline, not counting any out-of-tree ports), so why do you need it? 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 A wise person makes his own decisions, a weak one obeys public opinion. -- Chinese proverb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it
Dear Simon Glass, In message CAPnjgZ2jS8kzCt06LbYnXSyEKm6ck8apm=p1yqqdtnz0+q9...@mail.gmail.com you wrote: Well let's see how we go with the incremental approach - hopefully we can get the same result with less pain and risk, and not too much work. Did you miss my proposal not to change the existing coe for all boards, but to provide anew implementation and convert boards one by one? What do you think about such an approach? 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 The X11 source code style is ATROCIOUS and should not be used as a model. - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] ARM:AM33XX: Add SPL support for AM335X EVM
On 01/03/12 08:42, Chandan Nath wrote:
This patch is added to support SPL feature on AM335X
platform. In this patch, MMC1 is configured as boot
device for SPL and support for other devices will be
added in the next patch series.
Signed-off-by: Chandan Nath chandan.n...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
Changes since v2:
- Added missing omap.h file
Changes since v1:
- Rebased to master branch
- Replaced am33xx lowleve_init.S with omap-common lowlevel_init.S
in order to use common code for omap_bootmode.
arch/arm/cpu/armv7/am33xx/Makefile|2 -
arch/arm/cpu/armv7/am33xx/board.c | 65 +--
arch/arm/cpu/armv7/am33xx/config.mk | 18 ++
arch/arm/cpu/armv7/am33xx/emif4.c |2 +-
arch/arm/cpu/armv7/am33xx/lowlevel_init.S | 72
-
arch/arm/cpu/armv7/omap-common/Makefile |3 +
arch/arm/include/asm/arch-am33xx/common_def.h | 22
arch/arm/include/asm/arch-am33xx/omap.h | 59
arch/arm/include/asm/arch-am33xx/sys_proto.h |1 +
arch/arm/include/asm/omap_common.h|5 ++
board/ti/am335x/common_def.h | 24
board/ti/am335x/evm.c |2 +-
board/ti/am335x/mux.c |2 +-
include/configs/am335x_evm.h | 39 -
spl/Makefile | 13 ++---
15 files changed, 214 insertions(+), 115 deletions(-)
create mode 100644 arch/arm/cpu/armv7/am33xx/config.mk
delete mode 100644 arch/arm/cpu/armv7/am33xx/lowlevel_init.S
create mode 100644 arch/arm/include/asm/arch-am33xx/common_def.h
create mode 100644 arch/arm/include/asm/arch-am33xx/omap.h
delete mode 100644 board/ti/am335x/common_def.h
diff --git a/arch/arm/cpu/armv7/am33xx/Makefile
b/arch/arm/cpu/armv7/am33xx/Makefile
index 6beafbb..7768912 100644
--- a/arch/arm/cpu/armv7/am33xx/Makefile
+++ b/arch/arm/cpu/armv7/am33xx/Makefile
@@ -16,8 +16,6 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(SOC).o
-SOBJS:= lowlevel_init.o
-
COBJS+= clock.o
COBJS+= sys_info.o
COBJS+= ddr.o
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 312643c..2a45933 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -19,19 +19,45 @@
#include common.h
#include asm/arch/cpu.h
#include asm/arch/hardware.h
+#include asm/arch/omap.h
#include asm/arch/ddr_defs.h
#include asm/arch/clock.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/common_def.h
#include asm/io.h
+#include asm/omap_common.h
DECLARE_GLOBAL_DATA_PTR;
struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE;
+struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
+
+struct omap_boot_parameters boot_params __attribute__ ((section(.data)));
+
+#ifdef CONFIG_SPL_BUILD
+u32 omap_bootmode = MMCSD_MODE_FAT;
+
+u32 omap_boot_device(void)
+{
+ return (u32) (boot_params.omap_bootdevice);
+}
+
+u32 omap_boot_mode(void)
+{
+ return omap_bootmode;
+}
+
can't arch/arm/cpu/armv7/omap-common/hwinit-common.c be used for this?
[...]
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] ARM:AM33XX: Add SPL support for AM335X EVM
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Tuesday, January 03, 2012 1:44 PM
To: Kumar Nath, Chandan
Cc: u-boot@lists.denx.de; Rini, Tom
Subject: Re: [U-Boot] [PATCH v3 3/3] ARM:AM33XX: Add SPL support for
AM335X EVM
On 01/03/12 08:42, Chandan Nath wrote:
This patch is added to support SPL feature on AM335X
platform. In this patch, MMC1 is configured as boot
device for SPL and support for other devices will be
added in the next patch series.
Signed-off-by: Chandan Nath chandan.n...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
Changes since v2:
- Added missing omap.h file
Changes since v1:
- Rebased to master branch
- Replaced am33xx lowleve_init.S with omap-common lowlevel_init.S
in order to use common code for omap_bootmode.
arch/arm/cpu/armv7/am33xx/Makefile|2 -
arch/arm/cpu/armv7/am33xx/board.c | 65
+--
arch/arm/cpu/armv7/am33xx/config.mk | 18 ++
arch/arm/cpu/armv7/am33xx/emif4.c |2 +-
arch/arm/cpu/armv7/am33xx/lowlevel_init.S | 72 ---
--
arch/arm/cpu/armv7/omap-common/Makefile |3 +
arch/arm/include/asm/arch-am33xx/common_def.h | 22
arch/arm/include/asm/arch-am33xx/omap.h | 59
arch/arm/include/asm/arch-am33xx/sys_proto.h |1 +
arch/arm/include/asm/omap_common.h|5 ++
board/ti/am335x/common_def.h | 24
board/ti/am335x/evm.c |2 +-
board/ti/am335x/mux.c |2 +-
include/configs/am335x_evm.h | 39 -
spl/Makefile | 13 ++---
15 files changed, 214 insertions(+), 115 deletions(-)
create mode 100644 arch/arm/cpu/armv7/am33xx/config.mk
delete mode 100644 arch/arm/cpu/armv7/am33xx/lowlevel_init.S
create mode 100644 arch/arm/include/asm/arch-am33xx/common_def.h
create mode 100644 arch/arm/include/asm/arch-am33xx/omap.h
delete mode 100644 board/ti/am335x/common_def.h
diff --git a/arch/arm/cpu/armv7/am33xx/Makefile
b/arch/arm/cpu/armv7/am33xx/Makefile
index 6beafbb..7768912 100644
--- a/arch/arm/cpu/armv7/am33xx/Makefile
+++ b/arch/arm/cpu/armv7/am33xx/Makefile
@@ -16,8 +16,6 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
-SOBJS := lowlevel_init.o
-
COBJS += clock.o
COBJS += sys_info.o
COBJS += ddr.o
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 312643c..2a45933 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -19,19 +19,45 @@
#include common.h
#include asm/arch/cpu.h
#include asm/arch/hardware.h
+#include asm/arch/omap.h
#include asm/arch/ddr_defs.h
#include asm/arch/clock.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/common_def.h
#include asm/io.h
+#include asm/omap_common.h
DECLARE_GLOBAL_DATA_PTR;
struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE;
+struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
+
+struct omap_boot_parameters boot_params __attribute__
((section(.data)));
+
+#ifdef CONFIG_SPL_BUILD
+u32 omap_bootmode = MMCSD_MODE_FAT;
+
+u32 omap_boot_device(void)
+{
+ return (u32) (boot_params.omap_bootdevice);
+}
+
+u32 omap_boot_mode(void)
+{
+ return omap_bootmode;
+}
+
can't arch/arm/cpu/armv7/omap-common/hwinit-common.c be used for this?
I tried using hwinit-common.c file, but there are some other functions defined
which are not required. Could you tell me if there is any method to use only
Above functions from hwinit-common.c file.
[...]
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] ARM:AM33XX: Add SPL support for AM335X EVM
Hi Chandan,
On 01/03/12 10:18, Kumar Nath, Chandan wrote:
On 01/03/12 08:42, Chandan Nath wrote:
This patch is added to support SPL feature on AM335X
platform. In this patch, MMC1 is configured as boot
device for SPL and support for other devices will be
added in the next patch series.
Signed-off-by: Chandan Nath chandan.n...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
Changes since v2:
- Added missing omap.h file
Changes since v1:
- Rebased to master branch
- Replaced am33xx lowleve_init.S with omap-common lowlevel_init.S
in order to use common code for omap_bootmode.
[...]
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 312643c..2a45933 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -19,19 +19,45 @@
#include common.h
#include asm/arch/cpu.h
#include asm/arch/hardware.h
+#include asm/arch/omap.h
#include asm/arch/ddr_defs.h
#include asm/arch/clock.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/common_def.h
#include asm/io.h
+#include asm/omap_common.h
DECLARE_GLOBAL_DATA_PTR;
struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE;
+struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
+
+struct omap_boot_parameters boot_params __attribute__
((section(.data)));
+
+#ifdef CONFIG_SPL_BUILD
+u32 omap_bootmode = MMCSD_MODE_FAT;
+
+u32 omap_boot_device(void)
+{
+ return (u32) (boot_params.omap_bootdevice);
+}
+
+u32 omap_boot_mode(void)
+{
+ return omap_bootmode;
+}
+
can't arch/arm/cpu/armv7/omap-common/hwinit-common.c be used for this?
I tried using hwinit-common.c file, but there are some other functions defined
which are not required. Could you tell me if there is any method to use only
Above functions from hwinit-common.c file.
At least two ways, I can think of:
The less pretty, is introduce ifdefs in that file.
Another and IMO better option is split the file into
common and less common content and then reuse the right one.
With the later, you prevent the needless ifdeffery, but need to
be careful not to break any existing platforms.
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] ARM:AM33XX: Add SPL support for AM335X EVM
Dear Kumar Nath, Chandan, In message 1feb0f76d6f5e244ac1dae6c32484bbd034...@dbde01.ent.ti.com you wrote: can't arch/arm/cpu/armv7/omap-common/hwinit-common.c be used for this? I tried using hwinit-common.c file, but there are some other functions defined which are not required. Could you tell me if there is any method to use only Above functions from hwinit-common.c file. Does not -ffunction-sections in combination with -gc-sections take care of that? 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 That said, there may be good reasons for what you did beyond obsequi- ous sycophantic parody. Perhaps you might be so kind as to elucidate. -- Tom Christiansen in 5ldjbm$jtk$1...@csnews.cs.colorado.edu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it
Hi Wolfgang, On 03/01/12 19:12, Wolfgang Denk wrote: Dear Simon Glass, In message CAPnjgZ2jS8kzCt06LbYnXSyEKm6ck8apm=p1yqqdtnz0+q9...@mail.gmail.com you wrote: Well let's see how we go with the incremental approach - hopefully we can get the same result with less pain and risk, and not too much work. Did you miss my proposal not to change the existing coe for all boards, but to provide anew implementation and convert boards one by one? What do you think about such an approach? My idea was to migrate each arch to the 'pure processing loops' implementation I have just posted for x86. We can then factor out the processing loop code into common code leaving just the init function arrays in arch/foo/lib/board.c We can then look at how to deal with the disparate init sequences - I'm going to have a look at my new 'initcall' proposal to see if that is viable - If so, we auto generate init_sequence.c Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] 4k page ONFI NAND
Hello, We have a Micron 4K page sized ONFI NAND MT29F16G08 I am encountering frequent errors while reading the device. Although the data area is protected for 8bit correction with BCH8 algorithm, the oob area is unprotected and is susceptible to bit flips These errors are very frequent and it results in jffs2 file system mounting problems and other related issues I also confirmed the problem through oobtest module. Can you please suggest any solutions/workaround Regards Vipin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add support for MMC to fw_printenv/setenv
Hi,
Below is a patch that allows fw_printenv/fw_setenv to also operate
on MMC memory.
Thanks,
csd
From b835008c9654cce32b11059cde4f339ccd250672 Mon Sep 17 00:00:00 2001
From: Christian Daudt c...@broadcom.com
Date: Mon, 19 Dec 2011 17:50:18 -0800
Subject: [PATCH] Add support for MMC to fw_printenv/setenv
This patch checks if the fd is MTD and if not (using an MTD-specific IOCTL)
and skips the flash unlock/erase/lock sequence if it is not MTD.
- fd_is_mtd function added to determine MTD/MMC
- flash_write_block made to not try MTD operations if mtd_type == MTD_ABSENT
- flash_read works with MMC devices now.
Signed-off-by: Christian Daudt c...@broadcom.com
---
tools/env/fw_env.c | 100 +++
1 files changed, 68 insertions(+), 32 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 996682e..b7aa771 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -211,6 +211,27 @@ static int flash_io (int mode);
static char *envmatch (char * s1, char * s2);
static int parse_config (void);
+
+/*
+ * Returns 1 if it is MTD and 0 if it is not MTD
+ */
+static int fd_is_mtd(int fd)
+{
+ struct mtd_info_user mtdinfo;
+ int rc;
+
+ rc = ioctl (fd, MEMGETINFO, mtdinfo);
+ if (rc 0) {
+ // Failed MEMGETINFO, not MTD
+ return 0;
+ } else {
+ // Succeeded, MTD
+ return 1;
+ }
+}
+
+
+
#if defined(CONFIG_FILE)
static int get_config (char *);
#endif
@@ -836,31 +857,33 @@ static int flash_write_buf (int dev, int fd,
void *buf, size_t count,
/* This only runs once on NOR flash and SPI-dataflash */
while (processed write_total) {
- rc = flash_bad_block (fd, mtd_type, blockstart);
- if (rc 0) /* block test failed */
- return rc;
+ if (mtd_type != MTD_ABSENT) {
+ rc = flash_bad_block (fd, mtd_type, blockstart);
+ if (rc 0) /* block test failed */
+ return rc;
- if (blockstart + erasesize top_of_range) {
- fprintf (stderr, End of range reached, aborting\n);
- return -1;
- }
+ if (blockstart + erasesize top_of_range) {
+ fprintf (stderr, End of range reached,
aborting\n);
+ return -1;
+ }
- if (rc) { /* block is bad */
- blockstart += blocklen;
- continue;
- }
+ if (rc) { /* block is bad */
+ blockstart += blocklen;
+ continue;
+ }
- erase.start = blockstart;
- ioctl (fd, MEMUNLOCK, erase);
+ erase.start = blockstart;
+ ioctl (fd, MEMUNLOCK, erase);
- /* Dataflash does not need an explicit erase cycle */
- if (mtd_type != MTD_DATAFLASH)
- if (ioctl (fd, MEMERASE, erase) != 0) {
- fprintf (stderr, MTD erase error on %s: %s\n,
-DEVNAME (dev),
-strerror (errno));
- return -1;
- }
+ /* Dataflash does not need an explicit erase cycle */
+ if (mtd_type != MTD_DATAFLASH)
+ if (ioctl (fd, MEMERASE, erase) != 0) {
+ fprintf (stderr, MTD erase error on
%s: %s\n,
+DEVNAME (dev),
+strerror (errno));
+ return -1;
+ }
+ }
if (lseek (fd, blockstart, SEEK_SET) == -1) {
fprintf (stderr,
@@ -878,7 +901,8 @@ static int flash_write_buf (int dev, int fd, void
*buf, size_t count,
return -1;
}
- ioctl (fd, MEMLOCK, erase);
+ if (mtd_type != MTD_ABSENT)
+ ioctl (fd, MEMLOCK, erase);
processed += blocklen;
block_seek = 0;
@@ -964,18 +988,30 @@ static int flash_read (int fd)
{
struct mtd_info_user mtdinfo;
int rc;
+ int is_mtd;
- rc = ioctl (fd, MEMGETINFO, mtdinfo);
- if (rc 0) {
- perror (Cannot get MTD information);
- return -1;
- }
+ is_mtd = fd_is_mtd(fd);
- if (mtdinfo.type != MTD_NORFLASH
- mtdinfo.type != MTD_NANDFLASH
- mtdinfo.type != MTD_DATAFLASH) {
- fprintf (stderr,
Re: [U-Boot] initcall revisited - A new idea to discuss
Hi Wolfgang,
On 03/01/12 01:49, Wolfgang Denk wrote:
Dear Graeme Russ,
In message 4f019abb.9010...@gmail.com you wrote:
Which got me to thinking, what if we had an initcall macro which included
the dependency information. Imagine this rough example:
...
INITCALL(display_banner, banner, dram,board_early)
Which says that the display_banner() function, when completed fulfils the
'banner' dependency, and requires both the 'dram' and 'board_early'
dependencies to be fulfilled in order to run
Sounds great!
OK, I think I can do this...
#define INIT_FUNC(fn, stage, reqs, prereqs, postreqs) \
static const char *__initfunc_ ## fn __used \
__attribute__((__section__(.initfuncs))) = \
#stage : #fn : #reqs : #prereqs : #postreqs
'postreq' are requisite functions that the given function must be run
before (USB init priot to console if using a USB serial dongle for example)
Then:
INIT_FUNC(cpu_init_f, f, fred, blah, foo);
Generates the string:
f:cpu_init_f:fred:blah:foo
and we can parse each of the elf archives to obtain a list of string
pointers from the .initfuncs, extract the strings and process them to
generate the init arrays
and add:
/DISCARD/ : { *(.initfuncs*) }
to the linker script to throw away the strings
It's a tad ugly under the hood, but the output will be very clean
Does this sound like a plan?
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lsxl: add support for lschlv2 and lsxhl
Hi Wolfgang, On Tue, January 3, 2012 09:09, Wolfgang Denk wrote: NAK. We do not allow such static network configurations. i've already guessed that ;) you may remember our lengthy discussions about the board which don't have a dedicated NVRAM for the ethernet address. Well, this is such a board. I would have expected more responses from other maintainers of this type of boards, esp. after the patch which removes the mac randomization from the ethernet driver, was merged. Actuaklly this is the standard case. Only a tiny minority of boards provide such storage for the MAC address. The overwhelming majority has none, and just uses the environment. So if #define CONFIG_ETHADDR xxx #define CONFIG_OVERWRITE_ETHADDR_ONCE is a no-no (i really dont see the point, why it's not allowed, sorry), i guess i have to maintain this on my own tree :( It is not allowed because a MAC address is a _unique_ identifier. Can you explain why you think it is needed at all? There are probably some 900+ board configurations which don't need it (only in mainline, not counting any out-of-tree ports), so why do you need it? The linkstations don't have a (populated) serial port. There is no way to access an unmodified board other than using the netconsole. If you want to recover from a bad environment setting or an empty environment, you can do this only with a working network connection. -- michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] ARM:AM33XX: Add mmc/sd support
On 01/03/2012 01:00 AM, Igor Grinberg wrote: Hi Chandan, Tom, On 01/03/12 08:42, Chandan Nath wrote: This patch add supports for mmc/sd driver on AM335X platform. PLL and pinmux configurations for mmc/sd are configured in this patch. Signed-off-by: Chandan Nath chandan.n...@ti.com Signed-off-by: Tom Rini tr...@ti.com [snip] diff --git a/arch/arm/include/asm/arch-am33xx/mmc_host_def.h b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h new file mode 100644 index 000..e56c018 --- /dev/null +++ b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h [snip] Ahh, I see... most of it is just a copy/paste of the same data in: arch/arm/include/asm/arch-omap3/mmc_host_def.h And arch-omap4 and arch-omap5, except for the base locations. I've talked a little with Wolfgang about this and on my cleanup list is making then posting something to give us plat/ for includes (name like the kernel, extra deep directory structure to create it, hopefully not). -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] ARM:AM33XX: Add SPL support for AM335X EVM
On 01/03/2012 01:18 AM, Kumar Nath, Chandan wrote:
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Tuesday, January 03, 2012 1:44 PM
To: Kumar Nath, Chandan
Cc: u-boot@lists.denx.de; Rini, Tom
Subject: Re: [U-Boot] [PATCH v3 3/3] ARM:AM33XX: Add SPL support for
AM335X EVM
On 01/03/12 08:42, Chandan Nath wrote:
This patch is added to support SPL feature on AM335X
platform. In this patch, MMC1 is configured as boot
device for SPL and support for other devices will be
added in the next patch series.
Signed-off-by: Chandan Nath chandan.n...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
Changes since v2:
- Added missing omap.h file
Changes since v1:
- Rebased to master branch
- Replaced am33xx lowleve_init.S with omap-common lowlevel_init.S
in order to use common code for omap_bootmode.
arch/arm/cpu/armv7/am33xx/Makefile|2 -
arch/arm/cpu/armv7/am33xx/board.c | 65
+--
arch/arm/cpu/armv7/am33xx/config.mk | 18 ++
arch/arm/cpu/armv7/am33xx/emif4.c |2 +-
arch/arm/cpu/armv7/am33xx/lowlevel_init.S | 72 ---
--
arch/arm/cpu/armv7/omap-common/Makefile |3 +
arch/arm/include/asm/arch-am33xx/common_def.h | 22
arch/arm/include/asm/arch-am33xx/omap.h | 59
arch/arm/include/asm/arch-am33xx/sys_proto.h |1 +
arch/arm/include/asm/omap_common.h|5 ++
board/ti/am335x/common_def.h | 24
board/ti/am335x/evm.c |2 +-
board/ti/am335x/mux.c |2 +-
include/configs/am335x_evm.h | 39 -
spl/Makefile | 13 ++---
15 files changed, 214 insertions(+), 115 deletions(-)
create mode 100644 arch/arm/cpu/armv7/am33xx/config.mk
delete mode 100644 arch/arm/cpu/armv7/am33xx/lowlevel_init.S
create mode 100644 arch/arm/include/asm/arch-am33xx/common_def.h
create mode 100644 arch/arm/include/asm/arch-am33xx/omap.h
delete mode 100644 board/ti/am335x/common_def.h
diff --git a/arch/arm/cpu/armv7/am33xx/Makefile
b/arch/arm/cpu/armv7/am33xx/Makefile
index 6beafbb..7768912 100644
--- a/arch/arm/cpu/armv7/am33xx/Makefile
+++ b/arch/arm/cpu/armv7/am33xx/Makefile
@@ -16,8 +16,6 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
-SOBJS := lowlevel_init.o
-
COBJS += clock.o
COBJS += sys_info.o
COBJS += ddr.o
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 312643c..2a45933 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -19,19 +19,45 @@
#include common.h
#include asm/arch/cpu.h
#include asm/arch/hardware.h
+#include asm/arch/omap.h
#include asm/arch/ddr_defs.h
#include asm/arch/clock.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/common_def.h
#include asm/io.h
+#include asm/omap_common.h
DECLARE_GLOBAL_DATA_PTR;
struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE;
+struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
+
+struct omap_boot_parameters boot_params __attribute__
((section(.data)));
+
+#ifdef CONFIG_SPL_BUILD
+u32 omap_bootmode = MMCSD_MODE_FAT;
+
+u32 omap_boot_device(void)
+{
+ return (u32) (boot_params.omap_bootdevice);
+}
+
+u32 omap_boot_mode(void)
+{
+ return omap_bootmode;
+}
+
can't arch/arm/cpu/armv7/omap-common/hwinit-common.c be used for this?
I tried using hwinit-common.c file, but there are some other functions defined
which are not required. Could you tell me if there is any method to use only
Above functions from hwinit-common.c file.
This probably just means there's further common code that am33xx needs
to be moved over to use from the omap4/5 family. For example, the emif
code.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] beagle: add eeprom expansion board info for bct brettl3
From: Peter Meerwald p.meerw...@bct-electronic.com this is for a prototyping board vendor/product ids have been added to http://elinux.org/BeagleBoardPinMux#List_of_Vendor_and_Device_IDs --- board/ti/beagle/beagle.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c index 6a457cb..5c04b34 100644 --- a/board/ti/beagle/beagle.c +++ b/board/ti/beagle/beagle.c @@ -71,6 +71,7 @@ extern volatile struct ehci_hcor *hcor; #define BBTOYS_WIFI0x01000B00 #define BBTOYS_VGA 0x02000B00 #define BBTOYS_LCD 0x03000B00 +#define BCT_BRETTL30x01000F00 #define BEAGLE_NO_EEPROM 0x DECLARE_GLOBAL_DATA_PTR; @@ -379,6 +380,9 @@ int misc_init_r(void) case BBTOYS_LCD: printf(Recognized BeagleBoardToys LCD board\n); break;; + case BCT_BRETTL3: + printf(Recognized bct electronic GmbH brettl3 board\n); + break; case BEAGLE_NO_EEPROM: printf(No EEPROM on expansion board\n); setenv(buddy, none); -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/omap3: limit chip select iteration based on board config
On 12/22/2011 12:28 PM, Grant Erickson wrote: Only attempt to configure and add DRAM at chip select 1 if the board has configured more than one bank of DRAM. This prevents boards that have CONFIG_NR_DRAM_BANKS set to 1 from getting an incorrect DRAM size. Signed-off-by: Grant Erickson maratho...@gmail.com Cc: Tom Rini tr...@ti.com OK, what problem (and on what board) are you seeing? Many boards only have CS0 populated with DRAM but when we try and configure CS1 the mem_ok() call fails and we don't try and use it, so we don't get a wrong amount of memory. Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] omap3: make get_board_rev() function weak
On 01/02/2012 07:01 AM, Igor Grinberg wrote: From: Nikita Kiryanov nik...@compulab.co.il Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Signed-off-by: Igor Grinberg grinb...@compulab.co.il Please add linux/compiler.h and just put __weak in front of get_board_rev, thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] initcall revisited - A new idea to discuss
Dear Graeme,
In message 4f02da64.60...@gmail.com you wrote:
INITCALL(display_banner, banner, dram,board_early)
Which says that the display_banner() function, when completed fulfils the
'banner' dependency, and requires both the 'dram' and 'board_early'
dependencies to be fulfilled in order to run
Sounds great!
OK, I think I can do this...
#define INIT_FUNC(fn, stage, reqs, prereqs, postreqs) \
static const char *__initfunc_ ## fn __used \
__attribute__((__section__(.initfuncs))) = \
#stage : #fn : #reqs : #prereqs : #postreqs
'postreq' are requisite functions that the given function must be run
before (USB init priot to console if using a USB serial dongle for example)
Then:
INIT_FUNC(cpu_init_f, f, fred, blah, foo);
Generates the string:
f:cpu_init_f:fred:blah:foo
and we can parse each of the elf archives to obtain a list of string
pointers from the .initfuncs, extract the strings and process them to
generate the init arrays
and add:
/DISCARD/ : { *(.initfuncs*) }
to the linker script to throw away the strings
It's a tad ugly under the hood, but the output will be very clean
Does this sound like a plan?
Yes. Looks good to me.
One thing comes to mind: it would be nice if we can find a way that
the INIT_FUNC definitions behave similar to weak functions - if an
init_func can be redefined / overwritten / modified by board specific
code we eventually have a very nice way to get rid of the related
#ifdef's.
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
Life sucks, but it's better than the alternative.
- Peter da Silva
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lsxl: add support for lschlv2 and lsxhl
Dear Michael, In message b96abc7f27f132b4b00377ddd9ca632d.squir...@ssl.serverraum.org you wrote: The linkstations don't have a (populated) serial port. There is no way to access an unmodified board other than using the netconsole. If you want to recover from a bad environment setting or an empty environment, you can do this only with a working network connection. I understand they have USB? Can we use console over USB instead? 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 Where shall I begin, please your Majesty? he asked. Begin at the beginning, the King said, gravely, and go on till you come to the end: then stop.- Alice's Adventures in Wonderland, Lewis Carroll ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] ARM:AM33XX: Add mmc/sd support
Hi Tom, On 01/03/12 16:21, Tom Rini wrote: On 01/03/2012 01:00 AM, Igor Grinberg wrote: Hi Chandan, Tom, On 01/03/12 08:42, Chandan Nath wrote: This patch add supports for mmc/sd driver on AM335X platform. PLL and pinmux configurations for mmc/sd are configured in this patch. Signed-off-by: Chandan Nath chandan.n...@ti.com Signed-off-by: Tom Rini tr...@ti.com [snip] diff --git a/arch/arm/include/asm/arch-am33xx/mmc_host_def.h b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h new file mode 100644 index 000..e56c018 --- /dev/null +++ b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h [snip] Ahh, I see... most of it is just a copy/paste of the same data in: arch/arm/include/asm/arch-omap3/mmc_host_def.h And arch-omap4 and arch-omap5, except for the base locations. I've talked a little with Wolfgang about this and on my cleanup list is making then posting something to give us plat/ for includes (name like the kernel, extra deep directory structure to create it, hopefully not). While this sounds promising, but I don't think this is the right thing to do... The reason why I think so, is that you are one person with that cleanup list, while many others work on the current code and probably don't have that (or any other) cleanup list. So they just add new code (in many cases copy/pasted) and you accept it while pushing another task to your cleanup list? Well, I don't care, you can keep doing it, but that does not sound right... and the your cleanup list will never get empty... -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] cm-t35: add EEPROM module and pass Linux a serial number
On 01/02/2012 07:01 AM, Igor Grinberg wrote: From: Nikita Kiryanov nik...@compulab.co.il Add board specific EEPROM handling module, read the serial number from the EEPROM and pass it to Linux. Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Signed-off-by: Igor Grinberg grinb...@compulab.co.il [snip] +#define EEPROM_ADDR 0x50 Some grepping around says this is usually CONFIG_SYS_I2C_EEPROM_ADDR (in the config.h). Thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] ARM:AM33XX: Add mmc/sd support
On 01/03/2012 07:50 AM, Igor Grinberg wrote: Hi Tom, On 01/03/12 16:21, Tom Rini wrote: On 01/03/2012 01:00 AM, Igor Grinberg wrote: Hi Chandan, Tom, On 01/03/12 08:42, Chandan Nath wrote: This patch add supports for mmc/sd driver on AM335X platform. PLL and pinmux configurations for mmc/sd are configured in this patch. Signed-off-by: Chandan Nath chandan.n...@ti.com Signed-off-by: Tom Rini tr...@ti.com [snip] diff --git a/arch/arm/include/asm/arch-am33xx/mmc_host_def.h b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h new file mode 100644 index 000..e56c018 --- /dev/null +++ b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h [snip] Ahh, I see... most of it is just a copy/paste of the same data in: arch/arm/include/asm/arch-omap3/mmc_host_def.h And arch-omap4 and arch-omap5, except for the base locations. I've talked a little with Wolfgang about this and on my cleanup list is making then posting something to give us plat/ for includes (name like the kernel, extra deep directory structure to create it, hopefully not). While this sounds promising, but I don't think this is the right thing to do... The reason why I think so, is that you are one person with that cleanup list, while many others work on the current code and probably don't have that (or any other) cleanup list. So they just add new code (in many cases copy/pasted) and you accept it while pushing another task to your cleanup list? Well, I don't care, you can keep doing it, but that does not sound right... and the your cleanup list will never get empty... I will put my TODO list up soon, but in this case, there's not going to be another new 'arch' added that copy/pastes this file too soon. The flip side is that I know that Chandan has a lot of hard work in front of him to get the rest of the drivers for am33xx into submittable shape that I don't want to delay that for this. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Cleanups and updates for cm-t35/3730
On 01/02/2012 07:01 AM, Igor Grinberg wrote: This patch series some what clean up cm-t35 board files, add separate EEPROM handling file, fixes the incorrect board revision passed to Linux. Nikita Kiryanov (6): cm-t35: cleanup the config file cm-t35: various cleanups cm-t35: add EEPROM module and pass Linux a serial number omap3: make get_board_rev() function weak cm-t35: pass correct revision information to Linux cm-t35: use the new EEPROM module to read the MAC address arch/arm/cpu/armv7/omap3/sys_info.c |3 +- board/cm_t35/Makefile |4 +- board/cm_t35/cm_t35.c | 16 ++--- board/cm_t35/eeprom.c | 125 +++ board/cm_t35/eeprom.h | 45 + include/configs/cm_t35.h| 80 +++--- 6 files changed, 223 insertions(+), 50 deletions(-) create mode 100644 board/cm_t35/eeprom.c create mode 100644 board/cm_t35/eeprom.h I've read the whole series now and commented on a few of them. Thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
Hi, On Mon, Jan 02, 2012 at 10:39:04AM -0800, Simon Glass wrote: diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt new file mode 100644 index 000..1db8e12 --- /dev/null +++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt @@ -0,0 +1,27 @@ +A simple common binding for matrix-connected key boards. Currently targeted at +defining the keys in the scope of linux key codes since that is a stable and +standardized interface at this time. + +Required properties: +- compatible: matrix-keyboard-controller +- linux,keymap: an array of packed 1-cell entries containing the equivalent + of row, column and linux key-code. The 32-bit big endian cell is packed + as: + row 24 | column 16 | key-code This looks much better than the Samsung binding and the original 3-cell one. U-Boot Tegra (keyboard patch series) currently uses a 16x8 matrix, and uses a single byte (the ASCII character) for a total of 128 bytes per keymap. Since U-Boot does not have (or apparently want) the concept of key codes or the added code and intermediate data this requires, the binding presented here will not suit U-Boot so far. These rows and columns embedded in the cell make it more of a pain to write the fdt description. If you just set up the cells in (column, row) order and set the matrix size (rows, columns) then you end up with 128 entries on Tegra. If you use uint16 then this could be 256 bytes instead of 512. The binding you present for Tegra would be 109 * 4 = 436 bytes. However I take your point that Fn maps are much more sparse, so overall this is likely to be similar (512 bytes for either method once Fn mappings are taken into account). Looking at the keymap you posted, you define 62 keys and 16 function keys. So if that is all you care about on your particular keyboard, that means that the layout with the 1-cell format is 248 bytes for the base keymap, and 64 bytes for the fn-keymap. The benefit of using the row/column/keycode format is that the table is only as large as the number of keys you care about. But going back to U-Boot, it does not have the intermediate table that you malloc and decant into, it does not understand key codes so doesn't know what to do when Shift is pressed, doesn't understand languages, etc. In order to use these Linux bindings in U-Boot we would need to add new input layer, extra decode code and intermediate tables. I can almost hear the NAKs already (bear in mind fdt only went into U-Boot in the December release and people are more sensitive to code size / performance there than in Linux). I did ask about this on this list a few weeks ago but no response yet. We could perhaps add an alternative direct ASCII binding like this example (which would have to be in a separate node): You keep saying direct ASCII, but your map contains non-ASCII characters. ASCII provides no way at all to specify things such as shift, or arrow keys, or other common new keys on keyboards. Instead you have had to make up an ad-hoc custom map that contains your own special codes for these keys. For example, for arrow keys you seem to overload the FS/GS/RS/US. I'm not saying we expect to need to use those ascii codes, but it does seem arbitrary to just grab them for arrow keys. So in essence you have come up with your own encoding of non-ASCII keys instead of reusing what is already available through the linux keycodes. Also, for example with return, does it encode as CR, LF or CR+LF? Etc. Doing a binding in pseudo-ASCII is just asking for extra complications, in my opinion. Over time that encoding is likely to swell to similar sizes anyway, but still be incompatible. /* Use a packed binding which doesn't include row,column numbers in each cell */ packed-binding; matrix-columns = 8; matrix-rows = 16; ascii-binding; /* ASCII characters instead of keycodes */ u-boot,keymap = /size/ 8 00 00 'w' 's' 'a' 'z' 00 DE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '5' '4' 'r' 'e' 'f' 'd' 'x' 00 '7' '6' 't' 'h' 'g' 'v' 'c' ' ' '9' '8' 'u' 'y' 'j' 'n' 'b' 5C '-' '0' 'o' 'i' 'l' 'k' ',' 'm' 00 '=' ']' 0D 00 00 00 00 00 00 00 00 DF DF 00 00 00 00 00 00 00 DC 00 DD 00 00 00 00 00 00 00 00 '[' 'p' 27 ';' '/' '.' 00 00 00 00 08 '3' '2' 1E 00 00 00 7F 00 00 00 1D 1F
Re: [U-Boot] [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it
Hi Wolfgang, On Tue, Jan 3, 2012 at 12:12 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message CAPnjgZ2jS8kzCt06LbYnXSyEKm6ck8apm=p1yqqdtnz0+q9...@mail.gmail.com you wrote: Well let's see how we go with the incremental approach - hopefully we can get the same result with less pain and risk, and not too much work. Did you miss my proposal not to change the existing coe for all boards, but to provide anew implementation and convert boards one by one? What do you think about such an approach? Sorry I must have misread this as 'architecture' instead of 'board'. I suppose this would work since there is a simple CONFIG switch to move over. The concern with doing this for a whole architecture was the board breakages, and this idea would avoid that. I wonder what would be the incentive for boards to move over? Perhaps eventually it could be the default, or we could discourage patches to the old code. I have brought in PPC to board_f.c and board_r.c but not dealt with relocation. Once I have done that, gone through the new x86 series again and MAKEALL doesn't scream too loudly I'll do another RFC along these lines. If Graham can move his initcall stuff along too then we can also get rid of the #ifdefs, which it IMO the main ugliness with my RFC. Regards, Simon 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 The X11 source code style is ATROCIOUS and should not be used as a model. - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] initcall revisited - A new idea to discuss
Hi Graham,
On Tue, Jan 3, 2012 at 2:37 AM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Wolfgang,
On 03/01/12 01:49, Wolfgang Denk wrote:
Dear Graeme Russ,
In message 4f019abb.9010...@gmail.com you wrote:
Which got me to thinking, what if we had an initcall macro which included
the dependency information. Imagine this rough example:
...
INITCALL(display_banner, banner, dram,board_early)
Which says that the display_banner() function, when completed fulfils the
'banner' dependency, and requires both the 'dram' and 'board_early'
dependencies to be fulfilled in order to run
Sounds great!
OK, I think I can do this...
#define INIT_FUNC(fn, stage, reqs, prereqs, postreqs) \
static const char *__initfunc_ ## fn __used \
__attribute__((__section__(.initfuncs))) = \
#stage : #fn : #reqs : #prereqs : #postreqs
'postreq' are requisite functions that the given function must be run
before (USB init priot to console if using a USB serial dongle for example)
Then:
INIT_FUNC(cpu_init_f, f, fred, blah, foo);
Generates the string:
f:cpu_init_f:fred:blah:foo
and we can parse each of the elf archives to obtain a list of string
pointers from the .initfuncs, extract the strings and process them to
generate the init arrays
and add:
/DISCARD/ : { *(.initfuncs*) }
to the linker script to throw away the strings
It's a tad ugly under the hood, but the output will be very clean
Does this sound like a plan?
Good with me - will be very interesting to see where this takes us.
I have been thinking if there is a way we can avoid the
post-processing perhaps by specifying two function parameters to the
macro (the init function to call and its prerequisite) and having the
initcall code sort the list before starting. We could have dummy
functions to mark particular stages of interest to boards. But it
can't deal with adding a new function as a prerequisite of an existing
one without perhaps a third parameter. I haven't looked at the
algorithm either...
But I wonder if it would be possible for your macro to generate a
table which includes the init function as well as the string? That way
we get a compile warning and link error if the function doesn't exist.
Regards,
Simon
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/15] New board support: Nokia RX-51 aka N900
On Sun, Dec 18, 2011 at 2:34 PM, Pali Rohár pali.ro...@gmail.com wrote: This board definition results in a u-boot.bin which can be chainloaded from NOLO in qemu or on a real N900. It does very little hardware config because NOLO has already configured the board. Only needed is enabling internal eMMC memory via twl4030 regulator which is not enabled by NOLO. [snip] +/* + * Routine: save_boot_params (called after reset from start.S) + * Description: Save atag address and attached kernel address. + * Move u-boot to address CONFIG_SYS_TEXT_BASE + */ +asm( +startaddr:\n /* address where should be u-boot after relocation */ Please put this into its own .S file so it's more readable, thanks. [snip] +/* + * High Level Configuration Options + */ + +#define CONFIG_ARMV7 /* This is an ARM V7 CPU core */ This isn't used. +#define CONFIG_L2_OFF /* kernel won't boot if l2 enabled */ This isn't correct for disabling L2 now and doesn't do anything. So L2 is probably enabled :) [snip] +/* DDR - I use Micron DDR */ +#define CONFIG_OMAP3_MICRON_DDR No you don't :) This can go away. [snip] +#ifdef CONFIG_USE_IRQ +#define CONFIG_STACKSIZE_IRQ (4 10) /* IRQ stack 4 KiB */ +#define CONFIG_STACKSIZE_FIQ (4 10) /* FIQ stack 4 KiB */ +#endif We just removed all of these from other config files. +/*--- + * Physical Memory Map + */ +#define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be populated */ +#define PHYS_SDRAM_1 OMAP34XX_SDRC_CS0 +#define PHYS_SDRAM_2 OMAP34XX_SDRC_CS1 + +/* SDRAM Bank Allocation method */ +#define SDRC_R_B_C 1 And I'm not sure if any of these are really needed now. Thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/15] RX-51: Add support for bootmenu
On Sun, Dec 18, 2011 at 2:34 PM, Pali Rohár pali.ro...@gmail.com wrote: * default bootmenu entries: NOLO kernel, internal eMMC memory, external SD card, u-boot boot order * when keyboard slide is closed always boot NOLO kernel * when keyborad slide is open in CONFIG_PREBOOT try load bootmenu.scr from first FAT partition of internal eMMC memory (also known as MyDocs) which (should) overwrite default bootmenu entries Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Tom Rini tr...@ti.com -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/6] overo: add SPL support / CONFIG_SYS_TEXT_BASE changed to 0x80100000
On Thu, Dec 22, 2011 at 3:49 AM, Andreas Müller schnitzelt...@gmx.de wrote: * implementation based on ti beagleboard/omap3evm * timing data and i2c workaround for revision 0 boards taken from x-loader * run-tested with overo revision 0 and 1 / boot from NAND and SDcard Signed-off-by: Andreas Müller schnitzelt...@gmx.de Two big changes requested: 1) Please move the 'Texas Instruments' part of the preloader_console_init print to the default weak omap_rev_parse and then just provide an Overo version of the function. 2) Please see http://patchwork.ozlabs.org/patch/131431/ for how to configure SPL (and CONFIG_SYS_TEXT_BASE) so that SPL or x-loader can be used as the first stage. Since we're punting on some of the early revs of the boards (if I follow your emails right) this is important. Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
Hi Olof, On Tue, Jan 3, 2012 at 7:43 AM, Olof Johansson o...@lixom.net wrote: Hi, On Mon, Jan 02, 2012 at 10:39:04AM -0800, Simon Glass wrote: diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt new file mode 100644 index 000..1db8e12 --- /dev/null +++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt @@ -0,0 +1,27 @@ +A simple common binding for matrix-connected key boards. Currently targeted at +defining the keys in the scope of linux key codes since that is a stable and +standardized interface at this time. + +Required properties: +- compatible: matrix-keyboard-controller +- linux,keymap: an array of packed 1-cell entries containing the equivalent + of row, column and linux key-code. The 32-bit big endian cell is packed + as: + row 24 | column 16 | key-code This looks much better than the Samsung binding and the original 3-cell one. U-Boot Tegra (keyboard patch series) currently uses a 16x8 matrix, and uses a single byte (the ASCII character) for a total of 128 bytes per keymap. Since U-Boot does not have (or apparently want) the concept of key codes or the added code and intermediate data this requires, the binding presented here will not suit U-Boot so far. These rows and columns embedded in the cell make it more of a pain to write the fdt description. If you just set up the cells in (column, row) order and set the matrix size (rows, columns) then you end up with 128 entries on Tegra. If you use uint16 then this could be 256 bytes instead of 512. The binding you present for Tegra would be 109 * 4 = 436 bytes. However I take your point that Fn maps are much more sparse, so overall this is likely to be similar (512 bytes for either method once Fn mappings are taken into account). Looking at the keymap you posted, you define 62 keys and 16 function keys. So if that is all you care about on your particular keyboard, that means that the layout with the 1-cell format is 248 bytes for the base keymap, and 64 bytes for the fn-keymap. The benefit of using the row/column/keycode format is that the table is only as large as the number of keys you care about. Yes - my point is that the number of entries in the 1-byte binding (with no row, column embedded) is unlikely to be more than the next power of 2. So by avoiding including 2 or 3 unnecessary bytes we can actually get a size reduction in most cases. It is also easier to enter IMO. Can the Linux key codes fit in 8 bits? But going back to U-Boot, it does not have the intermediate table that you malloc and decant into, it does not understand key codes so doesn't know what to do when Shift is pressed, doesn't understand languages, etc. In order to use these Linux bindings in U-Boot we would need to add new input layer, extra decode code and intermediate tables. I can almost hear the NAKs already (bear in mind fdt only went into U-Boot in the December release and people are more sensitive to code size / performance there than in Linux). I did ask about this on this list a few weeks ago but no response yet. We could perhaps add an alternative direct ASCII binding like this example (which would have to be in a separate node): You keep saying direct ASCII, but your map contains non-ASCII characters. ASCII provides no way at all to specify things such as shift, or arrow keys, or other common new keys on keyboards. Instead you have had to make up an ad-hoc custom map that contains your own special codes for these keys. For example, for arrow keys you seem to overload the FS/GS/RS/US. I'm not saying we expect to need to use those ascii codes, but it does seem arbitrary to just grab them for arrow keys. So in essence you have come up with your own encoding of non-ASCII keys instead of reusing what is already available through the linux keycodes. Also, for example with return, does it encode as CR, LF or CR+LF? Etc. Doing a binding in pseudo-ASCII is just asking for extra complications, in my opinion. Over time that encoding is likely to swell to similar sizes anyway, but still be incompatible. Yes it would be better to use one binding, just so long as it is efficient and doesn't introduce a lot of new complexity in U-Boot which is useful only with fdt. /* Use a packed binding which doesn't include row,column numbers in each cell */ packed-binding; matrix-columns = 8; matrix-rows = 16; ascii-binding; /* ASCII characters instead of keycodes */ u-boot,keymap = /size/ 8 00 00 'w' 's' 'a' 'z' 00 DE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '5' '4' 'r' 'e' 'f' 'd' 'x' 00 '7' '6' 't' 'h' 'g' 'v' 'c' ' '
Re: [U-Boot] [PATCH v2 0/6] overo: add SPL support
On Thu, Dec 22, 2011 at 4:04 AM, Andreas Müller schnitzelt...@gmx.de wrote: I manually sent this series to Steve as suggested in review by Tom Parts 1 to 5 are fine and I've sent my comments on 6, thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend] OMAP3: Remove unused define CONFIG_OMAP3_*_DDR
On Mon, Jan 2, 2012 at 9:47 AM, Thomas Weber thomas.x.we...@googlemail.com wrote: This patch removes the unused definitions: CONFIG_OMAP3_MICRON_DDR CONFIG_OMAP3_NUMONYX_DDR CONFIG_OMAP3_INFINEON_DDR Acked-by: Igor Grinberg grinb...@compulab.co.il Acked-by: Luca Ceresoli luca.ceres...@comelit.it Signed-off-by: Thomas Weber we...@corscience.de This is already in u-boot-ti/next and I sent a pull request to Albert with it back in December. I'll be sending him a new pull request with this patch, along with some others, soon. Thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, davinci: Change byte order of RTC kick register values
On Wed, Dec 21, 2011 at 7:49 AM, Christian Riesch christian.rie...@omicron.at wrote: Now the values in the defines agree with those in the manuals. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Tom Rini tr...@ti.com Cc: Heiko Schocher h...@denx.de Applied to u-boot-ti/master, thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
On Tue, Jan 3, 2012 at 8:44 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Tue, Jan 03, 2012 at 04:29:30PM +, Russell King - ARM Linux wrote: On Tue, Jan 03, 2012 at 08:22:21AM -0800, Simon Glass wrote: Can the Linux key codes fit in 8 bits? That depends on your point of view. If you hack on X, then the answer is yes and you ignore the squeels of your users when certain key presses get misinterpreted. (The Psion LX platform, otherwise known as the Netbook Pro, suffered with this problem.) If you are a kernel hacker, the answer is no, because key codes currently go all the way to 0x300. For bootloader environment 0-255 range is probably sufficient though, the upper keys are somewhat recent additions to the maps... To keep things in common it would be convenient to not cap the key code at 8 bits for everybody though, since we're looking at reaching agreement on a common solution between firmware and linux. And no matter what the size of the word is there will be need for a translation table. -Olof ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] ARMV7: Add support For Logic OMAP35x/DM37x modules
On Tue, Dec 20, 2011 at 12:18 AM, Igor Grinberg grinb...@compulab.co.il wrote: On 12/20/11 07:54, Peter Barada wrote: This patch adds basic support for OMAP35x/DM37x SOM LV/Torpedo reference boards. It assumes U-boot is loaded to SDRAM with the help of another small bootloader (x-load) running from SRAM. Signed-off-by: Peter Barada peter.bar...@logicpd.com Cc: Tom Rini tom.r...@gmail.com Cc: Igor Grinberg grinb...@compulab.co.il Cc: Wolfgang Denk w...@denx.de Acked-by: Igor Grinberg grinb...@compulab.co.il Applied to u-boot-ti/master, thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] beagle: add eeprom expansion board info for bct brettl3
On Tue, Jan 3, 2012 at 7:14 AM, Peter Meerwald pme...@pmeerw.net wrote: From: Peter Meerwald p.meerw...@bct-electronic.com this is for a prototyping board vendor/product ids have been added to http://elinux.org/BeagleBoardPinMux#List_of_Vendor_and_Device_IDs Since this follows existing boards and seems to meet the outside criteria for being here, I'm putting this into u-boot-ti/master now, even if it's not been 24h. Thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap4: fix boot issue on ES2.0 Panda
On Sat, Dec 31, 2011 at 5:27 AM, asad ar...@example.net wrote: On 12/29/2011 07:47 PM, Aneesh V wrote: Fix boot issue on ES2.0 Panda by tuning some IO settings. The CONTROL_EFUSE_2 register has to be over-ridden in software for 4430 boards. Commit 23e9f0723e48615332119de4f4ec7a833a282628 wrongly did this for CONTROL_EFUSE_1. Reverting this and doing it for CONTROL_EFUSE_2. Signed-off-by: Aneesh V ane...@ti.com [snip] Hi, works fine: U-Boot SPL 2011.12-00046-gbfcc40b-dirty (Dec 31 2011 - 12:14:09) Texas Instruments OMAP4430 ES2.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2011.12-00046-gbfcc40b-dirty (Dec 31 2011 - 12:14:09) CPU : OMAP4430 ES2.0 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment Thanks! Tested-by: Raúl Porcel armi...@gentoo.org Applied to u-boot-ti/master, thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 4k page ONFI NAND
On 01/03/2012 03:36 AM, Vipin Kumar wrote: Hello, We have a Micron 4K page sized ONFI NAND MT29F16G08 I am encountering frequent errors while reading the device. Although the data area is protected for 8bit correction with BCH8 algorithm, the oob area is unprotected and is susceptible to bit flips These errors are very frequent and it results in jffs2 file system mounting problems and other related issues I also confirmed the problem through oobtest module. Can you please suggest any solutions/workaround Use ubi -- the OOB will then only be used for ECC. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP MMC: Add delay before waiting for status
On Thu, Dec 22, 2011 at 2:56 AM, Andreas Müller schnitzelt...@gmx.de wrote: Loading kernel from MMC created the following error message reproducable: | reading uImage | mmc_send_cmd: timedout waiting for stat! | | 2860468 bytes read Tested on overo with OMAP3530: * OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz Die ID #470e0004040398d31402100c * OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz Die ID #112404035c140101b011 Signed-off-by: Andreas Müller schnitzelt...@gmx.de OK, I'm going to NAK this as-is. Over at https://lists.yoctoproject.org/pipermail/meta-ti/2012-January/000316.html Andreas has provided more details about what he saw (thread is about someone else who hit this problem on a beagleboard xM). I've done a bit more poking at the other MMC drivers and it seems that the send the mmc command function has anywhere from a 10ms timeout (sdhci.c) to 1ms (omap, fsl). Now, digging more, I see that the kernel sets the mmc timeout to 20ms and has since the driver went in, so this is presumably a more safe value to use. I've updated the code to use that, have a more clear comment and name (and some related cleanup) and I've sent some test binaries to someone internally that's reported the problem. I'll post a patch and cc Andreas and Peter and see if this change also fixes the problem (it really should, but lets be safe). Thanks folks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap: mmc: Raise timeout value to 20ms
With certain SD cards the code detects a timeout when the hardware
has not timed out. We change the timeout used to match the kernel
which gives software 20ms to detect a timeout. We also define to
match the kernel and expand the previously incorrect comment.
Finally, we let get_timer() perform subtraction for us as it offers.
Signed-off-by: Tom Rini tr...@ti.com
---
drivers/mmc/omap_hsmmc.c | 30 +-
1 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index c38b9e6..378fbda 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -33,8 +33,12 @@
#include asm/arch/mmc_host_def.h
#include asm/arch/sys_proto.h
-/* If we fail after 1 second wait, something is really bad */
-#define MAX_RETRY_MS 1000
+/*
+ * Set our timeout value to 20ms. This has always been the timeout value
+ * used by the kernel. We define this in terms of usec since we check
+ * against get_timer calls which returns a usec value.
+ */
+#define MMC_TIMEOUT_USEC 2
static int mmc_read_data(struct hsmmc *mmc_base, char *buf, unsigned int size);
static int mmc_write_data(struct hsmmc *mmc_base, const char *buf,
@@ -107,7 +111,7 @@ void mmc_init_stream(struct hsmmc *mmc_base)
writel(MMC_CMD0, mmc_base-cmd);
start = get_timer(0);
while (!(readl(mmc_base-stat) CC_MASK)) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for cc!\n, __func__);
return;
}
@@ -118,7 +122,7 @@ void mmc_init_stream(struct hsmmc *mmc_base)
;
start = get_timer(0);
while (!(readl(mmc_base-stat) CC_MASK)) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for cc2!\n, __func__);
return;
}
@@ -140,7 +144,7 @@ static int mmc_init_setup(struct mmc *mmc)
mmc_base-sysconfig);
start = get_timer(0);
while ((readl(mmc_base-sysstatus) RESETDONE) == 0) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for cc2!\n, __func__);
return TIMEOUT;
}
@@ -148,7 +152,7 @@ static int mmc_init_setup(struct mmc *mmc)
writel(readl(mmc_base-sysctl) | SOFTRESETALL, mmc_base-sysctl);
start = get_timer(0);
while ((readl(mmc_base-sysctl) SOFTRESETALL) != 0x0) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for softresetall!\n,
__func__);
return TIMEOUT;
@@ -171,7 +175,7 @@ static int mmc_init_setup(struct mmc *mmc)
(dsor CLKD_OFFSET) | ICE_OSCILLATE);
start = get_timer(0);
while ((readl(mmc_base-sysctl) ICS_MASK) == ICS_NOTREADY) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for ics!\n, __func__);
return TIMEOUT;
}
@@ -199,7 +203,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
start = get_timer(0);
while ((readl(mmc_base-pstate) DATI_MASK) == DATI_CMDDIS) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for cmddis!\n, __func__);
return TIMEOUT;
}
@@ -207,7 +211,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
writel(0x, mmc_base-stat);
start = get_timer(0);
while (readl(mmc_base-stat)) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for stat!\n, __func__);
return TIMEOUT;
}
@@ -270,7 +274,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
start = get_timer(0);
do {
mmc_stat = readl(mmc_base-stat);
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s : timeout: No status update\n, __func__);
return TIMEOUT;
}
@@ -322,7 +326,7 @@ static int mmc_read_data(struct hsmmc *mmc_base, char *buf,
unsigned int size)
ulong start = get_timer(0);
do {
mmc_stat = readl(mmc_base-stat);
-
Re: [U-Boot] [PATCH] lsxl: add support for lschlv2 and lsxhl
Am Dienstag 03 Januar 2012, 15:46:09 schrieb Wolfgang Denk: Dear Michael, In message b96abc7f27f132b4b00377ddd9ca632d.squir...@ssl.serverraum.org you wrote: The linkstations don't have a (populated) serial port. There is no way to access an unmodified board other than using the netconsole. If you want to recover from a bad environment setting or an empty environment, you can do this only with a working network connection. I understand they have USB? Can we use console over USB instead? yeah that should be possible. another idea by Mario Fetka is to load a resuce environment from an usb storage. i don't know if that is easy to achieve. Maybe someone knows a board which does sth similar? or maybe sth like windows autostart, that is if there is some special file on the storage run it as a script. -- michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap: mmc: Raise timeout value to 20ms
On Tue, Jan 3, 2012 at 2:24 PM, Tom Rini tr...@ti.com wrote:
With certain SD cards the code detects a timeout when the hardware
has not timed out. We change the timeout used to match the kernel
which gives software 20ms to detect a timeout. We also define to
match the kernel and expand the previously incorrect comment.
Finally, we let get_timer() perform subtraction for us as it offers.
This doesn't work for me with the SanDisk 4GB card on the
BeagleBoard-xM. I updated the recipe to remove Andreas' original
patch, substituted the new one, and I get the following, which is the
behavior before I used Andreas' patch except that now it takes about
20 seconds for each timeout message to print.
Peter
SD/MMC found on device 0
reading uEnv.txt
mmc_send_cmd: timedout waiting for stat!
294 bytes read
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
Setting bus to 1
Loading file /boot/uImage from mmc device 0:2 (xxa2)
mmc_send_cmd: timedout waiting for stat!
mmc_send_cmd: timedout waiting for stat!
Signed-off-by: Tom Rini tr...@ti.com
---
drivers/mmc/omap_hsmmc.c | 30 +-
1 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index c38b9e6..378fbda 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -33,8 +33,12 @@
#include asm/arch/mmc_host_def.h
#include asm/arch/sys_proto.h
-/* If we fail after 1 second wait, something is really bad */
-#define MAX_RETRY_MS 1000
+/*
+ * Set our timeout value to 20ms. This has always been the timeout value
+ * used by the kernel. We define this in terms of usec since we check
+ * against get_timer calls which returns a usec value.
+ */
+#define MMC_TIMEOUT_USEC 2
static int mmc_read_data(struct hsmmc *mmc_base, char *buf, unsigned int
size);
static int mmc_write_data(struct hsmmc *mmc_base, const char *buf,
@@ -107,7 +111,7 @@ void mmc_init_stream(struct hsmmc *mmc_base)
writel(MMC_CMD0, mmc_base-cmd);
start = get_timer(0);
while (!(readl(mmc_base-stat) CC_MASK)) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for cc!\n, __func__);
return;
}
@@ -118,7 +122,7 @@ void mmc_init_stream(struct hsmmc *mmc_base)
;
start = get_timer(0);
while (!(readl(mmc_base-stat) CC_MASK)) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for cc2!\n, __func__);
return;
}
@@ -140,7 +144,7 @@ static int mmc_init_setup(struct mmc *mmc)
mmc_base-sysconfig);
start = get_timer(0);
while ((readl(mmc_base-sysstatus) RESETDONE) == 0) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for cc2!\n, __func__);
return TIMEOUT;
}
@@ -148,7 +152,7 @@ static int mmc_init_setup(struct mmc *mmc)
writel(readl(mmc_base-sysctl) | SOFTRESETALL, mmc_base-sysctl);
start = get_timer(0);
while ((readl(mmc_base-sysctl) SOFTRESETALL) != 0x0) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for softresetall!\n,
__func__);
return TIMEOUT;
@@ -171,7 +175,7 @@ static int mmc_init_setup(struct mmc *mmc)
(dsor CLKD_OFFSET) | ICE_OSCILLATE);
start = get_timer(0);
while ((readl(mmc_base-sysctl) ICS_MASK) == ICS_NOTREADY) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for ics!\n, __func__);
return TIMEOUT;
}
@@ -199,7 +203,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
start = get_timer(0);
while ((readl(mmc_base-pstate) DATI_MASK) == DATI_CMDDIS) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
printf(%s: timedout waiting for cmddis!\n, __func__);
return TIMEOUT;
}
@@ -207,7 +211,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
writel(0x, mmc_base-stat);
start = get_timer(0);
while (readl(mmc_base-stat)) {
- if (get_timer(0) - start MAX_RETRY_MS) {
+ if (get_timer(start) MMC_TIMEOUT_USEC) {
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
On Tue, Jan 03, 2012 at 04:29:30PM +, Russell King - ARM Linux wrote: On Tue, Jan 03, 2012 at 08:22:21AM -0800, Simon Glass wrote: Can the Linux key codes fit in 8 bits? That depends on your point of view. If you hack on X, then the answer is yes and you ignore the squeels of your users when certain key presses get misinterpreted. (The Psion LX platform, otherwise known as the Netbook Pro, suffered with this problem.) If you are a kernel hacker, the answer is no, because key codes currently go all the way to 0x300. For bootloader environment 0-255 range is probably sufficient though, the upper keys are somewhat recent additions to the maps... -- Dmitry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
On Tue, Jan 03, 2012 at 05:06:15PM +, Russell King - ARM Linux wrote: On Tue, Jan 03, 2012 at 08:44:32AM -0800, Dmitry Torokhov wrote: On Tue, Jan 03, 2012 at 04:29:30PM +, Russell King - ARM Linux wrote: On Tue, Jan 03, 2012 at 08:22:21AM -0800, Simon Glass wrote: Can the Linux key codes fit in 8 bits? That depends on your point of view. If you hack on X, then the answer is yes and you ignore the squeels of your users when certain key presses get misinterpreted. (The Psion LX platform, otherwise known as the Netbook Pro, suffered with this problem.) If you are a kernel hacker, the answer is no, because key codes currently go all the way to 0x300. For bootloader environment 0-255 range is probably sufficient though, the upper keys are somewhat recent additions to the maps... I assume you deem 'recent' to mean 8 years ago - they've been there since at least 2.6.9, which is where the problem I refer to above was first noticed. Well, what's 8 years ;) On a more serious note keys above 255 are really the extended set - keys of remote controls, camera control, touchpad, various aplication launchers, etc that are not very interesting for bootloader. But, as Olof mentioned, the encoding must be sufficient for Linux as well as bootloader, so limiting it is not a good idea. -- Dmitry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
On Tue, Jan 03, 2012 at 08:22:21AM -0800, Simon Glass wrote: Can the Linux key codes fit in 8 bits? That depends on your point of view. If you hack on X, then the answer is yes and you ignore the squeels of your users when certain key presses get misinterpreted. (The Psion LX platform, otherwise known as the Netbook Pro, suffered with this problem.) If you are a kernel hacker, the answer is no, because key codes currently go all the way to 0x300. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
On Tue, Jan 03, 2012 at 08:44:32AM -0800, Dmitry Torokhov wrote: On Tue, Jan 03, 2012 at 04:29:30PM +, Russell King - ARM Linux wrote: On Tue, Jan 03, 2012 at 08:22:21AM -0800, Simon Glass wrote: Can the Linux key codes fit in 8 bits? That depends on your point of view. If you hack on X, then the answer is yes and you ignore the squeels of your users when certain key presses get misinterpreted. (The Psion LX platform, otherwise known as the Netbook Pro, suffered with this problem.) If you are a kernel hacker, the answer is no, because key codes currently go all the way to 0x300. For bootloader environment 0-255 range is probably sufficient though, the upper keys are somewhat recent additions to the maps... I assume you deem 'recent' to mean 8 years ago - they've been there since at least 2.6.9, which is where the problem I refer to above was first noticed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap: mmc: Raise timeout value to 20ms
On 01/03/2012 01:50 PM, Peter Bigot wrote: On Tue, Jan 3, 2012 at 2:24 PM, Tom Rini tr...@ti.com wrote: With certain SD cards the code detects a timeout when the hardware has not timed out. We change the timeout used to match the kernel which gives software 20ms to detect a timeout. We also define to match the kernel and expand the previously incorrect comment. Finally, we let get_timer() perform subtraction for us as it offers. This doesn't work for me with the SanDisk 4GB card on the BeagleBoard-xM. I updated the recipe to remove Andreas' original patch, substituted the new one, and I get the following, which is the behavior before I used Andreas' patch except that now it takes about 20 seconds for each timeout message to print. Dang. Is your card a class 6 card by chance? I'm going to go and see if I can pick one up locally real quick. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MX28: Fix MXSBOOT segfault if no params specified
Signed-off-by: Marek Vasut marek.va...@gmail.com
Cc: Wolfgang Denk w...@denx.de
Cc: Stefano Babic sba...@denx.de
---
tools/mxsboot.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 176753d..8246831 100644
--- a/tools/mxsboot.c
+++ b/tools/mxsboot.c
@@ -606,6 +606,9 @@ int parse_ops(int argc, char **argv)
};
int type;
+ if (argc 4)
+ return -1;
+
for (i = 1; i argc; i++) {
if (!strncmp(argv[i], -w, 2))
type = PARAM_WRITE;
BUMP
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MXS-NAND: Backport ecc.size from linux kernel
On 12/19/2011 02:23 PM, Marek Vasut wrote: On 12/18/2011 11:50 AM, Marek Vasut wrote: What specifically is happening in ubi part with ecc.size = 512? The driver doesn\t support subpage writes. Is this meant to be a workaround for the NAND layer ignoring a driver setting NAND_NO_SUBPAGE_WRITE? I'd rather just fix that... -Scott Any news here ? M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MXS-NAND: Backport ecc.size from linux kernel
On 01/03/2012 03:20 PM, Marek Vasut wrote: On 12/19/2011 02:23 PM, Marek Vasut wrote: On 12/18/2011 11:50 AM, Marek Vasut wrote: What specifically is happening in ubi part with ecc.size = 512? The driver doesn\t support subpage writes. Is this meant to be a workaround for the NAND layer ignoring a driver setting NAND_NO_SUBPAGE_WRITE? I'd rather just fix that... -Scott Any news here ? I just got back from end-of-year vacation; I'll look at it soon (will probably just remove the mask and trust the driver to not set flags that don't make sense). Thanks for the reminder. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Sat, Dec 3, 2011 at 11:31 PM, shuo@freescale.com wrote: From: Liu Shuo shuo@freescale.com Freescale FCM controller has a 2K size limitation of buffer RAM. In order to support the Nand flash chip whose page size is larger than 2K bytes, we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save them to a large buffer. (Starting a new thread so I don't hijack your patch) Hi Scott / Liu, We're using the MPC8313 and booting from a 2k NAND (using a SPL image). Like others, we're a bit concerned about continued availability of 2k parts. So this change -- being able to use the FCM with a 4k chip -- would be very useful to us. However, so far all of the 4k chips that we've seen have a higher error rate than our current 2k chips. Therefore they all recommend that something stronger than 1-bit ECC is used. Since the FCM only supports 1-bit ECC in hardware, it implies that we'll need to use software BCH to utilize a 4k chip. But this seems like it's going to pose problems when we build U-Boot: the SPL boot code is already heavily trimmed down to make it squeeze into the requisite 4k, so it seems unlikely that we can add software BCH support and remain within that size limit. Have you guys run in to this issue, or are you booting U-Boot from another source (e.g. NOR)? If using the U-Boot SPL: are you using a 4k part that works with just 1-bit ECC? (If so, which one?) Or are you using 1-bit ECC for U-Boot, then BCH for the remainder of flash? (This seems dangerous for long-term usage, if errors accumulate in the blocks containing U-Boot) At this point we're mainly trying to size up our long-term options, if 2k part availability becomes a problem. Thanks! -- Matthew L. Creech ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap: mmc: Raise timeout value to 20ms
On Tue, Jan 3, 2012 at 3:03 PM, Tom Rini tr...@ti.com wrote: On 01/03/2012 01:50 PM, Peter Bigot wrote: On Tue, Jan 3, 2012 at 2:24 PM, Tom Rini tr...@ti.com wrote: With certain SD cards the code detects a timeout when the hardware has not timed out. We change the timeout used to match the kernel which gives software 20ms to detect a timeout. We also define to match the kernel and expand the previously incorrect comment. Finally, we let get_timer() perform subtraction for us as it offers. This doesn't work for me with the SanDisk 4GB card on the BeagleBoard-xM. I updated the recipe to remove Andreas' original patch, substituted the new one, and I get the following, which is the behavior before I used Andreas' patch except that now it takes about 20 seconds for each timeout message to print. Dang. Is your card a class 6 card by chance? I'm going to go and see if I can pick one up locally real quick. It claims to be a class 4 card. Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] User Question
Is this the list I can ask questions for deploying uboot to a custom board based off the blackfin bf548? Some of my questions are not processor specific (like what is the approach to getting the micrel ks8995 and a smsc lan9215 talking and started -the ks8995 needs a spi start command)? I've started digging into the documentation at http://www.denx.de/wiki/U-Boot/Documentation and the git repository. And I'm trying to find out if someone has already done this so I don't have to reinvent the wheel. Thanks for any replies and my apologies if I am in the wrong spot. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] initcall revisited - A new idea to discuss
Hi Wolfgang, On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk w...@denx.de wrote: Dear Graeme, In message 4f02da64.60...@gmail.com you wrote: [snip] One thing comes to mind: it would be nice if we can find a way that the INIT_FUNC definitions behave similar to weak functions - if an init_func can be redefined / overwritten / modified by board specific code we eventually have a very nice way to get rid of the related #ifdef's. Well a lot of the #ifdefs will disappear when the INIT_FUNC macros gets migrated the the corresponding source files as the Makefile logic will take care of things for us I do have in the back of my mind the 'what if' case of the dependencies needing to be different between two arches or boards, but I really can't think of a case where this would be the case. I added the 'post-req' to the macro to allow an init function to be inserted before an existing function which I think will be the most likely case (initialising on-board hardware such as an FPGA prior to timer initialisation for example) We'll see how it pans out Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On 01/03/2012 03:48 PM, Matthew L. Creech wrote: On Sat, Dec 3, 2011 at 11:31 PM, shuo@freescale.com wrote: From: Liu Shuo shuo@freescale.com Freescale FCM controller has a 2K size limitation of buffer RAM. In order to support the Nand flash chip whose page size is larger than 2K bytes, we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save them to a large buffer. (Starting a new thread so I don't hijack your patch) Hi Scott / Liu, We're using the MPC8313 and booting from a 2k NAND (using a SPL image). Like others, we're a bit concerned about continued availability of 2k parts. So this change -- being able to use the FCM with a 4k chip -- would be very useful to us. However, so far all of the 4k chips that we've seen have a higher error rate than our current 2k chips. Therefore they all recommend that something stronger than 1-bit ECC is used. Since the FCM only supports 1-bit ECC in hardware, it implies that we'll need to use software BCH to utilize a 4k chip. Even on SLC chips, when using an ECC block size of 512 bytes? Or are you only able to find MLC? I looked for a datasheet for a 4K NAND chip, but couldn't find one readily available from a Google search. Hopefully someone internally can provide me with the one for the chip we're using. But this seems like it's going to pose problems when we build U-Boot: the SPL boot code is already heavily trimmed down to make it squeeze into the requisite 4k, so it seems unlikely that we can add software BCH support and remain within that size limit. There's also the issue of ECC on the boot page itself -- that has to be hardware ECC, because there's no software running yet. If using the U-Boot SPL: are you using a 4k part that works with just 1-bit ECC? (If so, which one?) Or are you using 1-bit ECC for U-Boot, then BCH for the remainder of flash? (This seems dangerous for long-term usage, if errors accumulate in the blocks containing U-Boot) AFAIK, we've just been using 1-bit hw ECC. I don't know what NAND chip was used for testing, or how much stress testing was done. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/15] bootstage: record and publish boot progress timing
Hi, On Sat, Dec 10, 2011 at 1:07 PM, Simon Glass s...@chromium.org wrote: This series creates a simple boot progress timing feature in U-Boot. Previous discussion on this is here: http://lists.denx.de/pipermail/u-boot/2011-May/thread.html#92584 A request was made to unify this with show_boot_progress(). As discussed in the v1 RFC patch, this series addresses this the following way: Are there comments / objections on this series at this stage? I am wanting to build it on with a new series. Regards, Simon 1. Create bootstage.h with the intent of replacing integers with enums. This will allow the values to be easily changed or rationalised later as required. It also makes it more explicit that (for example) 15 means we are about to run an OS. 2. Change show_boot_progress() to use these enums. This first patch just shows doing this with one (commonly used) integer value. 3. Create bootstage.c file which permits recording of bootstage timestamps. 4. Change the existing show_boot_progress() handlers within board files to use a provided bootstage progress handler instead. This is easy enough as there are few users. 5. Change show_boot_progress() to call into bootstage, which in turns calls the board-provided progress handler, if defined, after recording a timestamp. The function signature will stay the same for now. Ultimately I would like boot timing available from before U-Boot to user space in Linux. See RFC patch for Linux here: http://lwn.net/Articles/460432/ and discussion here: http://comments.gmane.org/gmane.linux.kernel/1194861 Still to do: change the microsecond time printout to use the Linux seconds.microseconds format. Changes in v2: - Unify show_boot_progress() into this series Simon Glass (15): bootstage: Create an initial header for boot progress integers bootstage: Make use of BOOTSTAGE_ID_RUN_OS in show_boot_progress() bootstage: Use show_boot_error() for -ve progress numbers bootstage: Convert progress numbers 1-9 into enums bootstage: Convert progress numbers 10-19 to enums bootstage: Convert progress numbers 20-41 to enums bootstage: Convert IDE progress numbers to enums bootstage: Convert NAND progress numbers to enums bootstage: Convert net progress numbers to enums bootstage: Convert FIT progress numbers to enums bootstage: Define an optional microsecond timer bootstage: Replace show_boot_progress/error() with bootstage_...() bootstage: Add microsecond boot time measurement bootstage: Plumb in bootstage calls for basic operations bootstage: arm: Add bootstage calls in board and bootm README | 25 +++ arch/arm/lib/board.c | 3 + arch/arm/lib/bootm.c | 6 +- arch/avr32/lib/bootm.c | 2 +- arch/m68k/lib/bootm.c | 2 +- arch/microblaze/lib/bootm.c | 2 +- arch/mips/lib/bootm.c | 2 +- arch/mips/lib/bootm_qemu_mips.c | 2 +- arch/nds32/lib/bootm.c | 2 +- arch/powerpc/lib/board.c | 2 +- arch/powerpc/lib/bootm.c | 2 +- arch/sparc/lib/board.c | 2 +- arch/x86/lib/board.c | 19 +-- board/Seagate/dockstar/dockstar.c | 4 +- board/a4m072/a4m072.c | 2 +- board/bf533-stamp/bf533-stamp.c | 30 ++-- board/hermes/hermes.c | 8 +- board/ivm/ivm.c | 2 +- board/matrix_vision/common/mv_common.c | 2 +- board/matrix_vision/mvbc_p/mvbc_p.c | 8 +- board/pcs440ep/pcs440ep.c | 50 +++--- board/scb9328/scb9328.c | 6 - board/sixnet/sixnet.c | 2 +- board/ti/beagle/beagle.c | 2 +- common/Makefile | 1 + common/bootstage.c | 160 common/cmd_bootm.c | 95 ++-- common/cmd_ide.c | 46 +++--- common/cmd_nand.c | 34 ++-- common/cmd_net.c | 23 ++- common/cmd_usb.c | 1 + common/env_common.c | 2 +- common/image.c | 56 --- include/bootstage.h | 260 include/common.h | 13 +- lib/time.c | 17 ++ net/bootp.c | 4 + net/eth.c | 6 +- net/net.c | 1 + post/post.c | 4 +- 40 files changed, 698 insertions(+), 212 deletions(-) create mode 100644 common/bootstage.c create mode 100644 include/bootstage.h -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de
Re: [U-Boot] [RFC PATCH 1/2] fdt: Add fdtdec_find_aliases() to deal with alias nodes
Hi,
On Mon, Dec 26, 2011 at 2:31 PM, Simon Glass s...@chromium.org wrote:
Stephen Warren pointed out that we should use nodes whether or not they
have an alias in the /aliases section. The aliases section specifies the
order so far as it can, but is not essential. Operating without alisses
is useful when the enumerated order of nodes does not matter (admittedly
rare in U-Boot).
This is considerably more complex, and it is important to keep this
complexity out of driver code. This patch creates a function
fdtdec_find_aliases() which returns an ordered list of node offsets
for a particular compatible ID, taking account of alias nodes.
Signed-off-by: Simon Glass s...@chromium.org
Does this look like a reasonable solution to the problem as described?
Any comments before I respin as a real patch?
Regards,
Simon
---
include/fdtdec.h | 51 +++
lib/fdtdec.c | 89
++
2 files changed, 140 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 5547676..0992130 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -228,3 +228,54 @@ int fdtdec_decode_gpio(const void *blob, int node, const
char *prop_name,
* @return 0 if all ok or gpio was FDT_GPIO_NONE; -1 on error
*/
int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
+
+/**
+ * Find the nodes for a peripheral and return a list of them in the correct
+ * order. This is used to enumerate all the peripherals of a certain type.
+ *
+ * To use this, optionally set up a /aliases node with alias properties for
+ * a peripheral. For example, for usb you could have:
+ *
+ * aliases {
+ * usb0 = /ehci@c5008000;
+ * usb1 = /ehci@c500;
+ * };
+ *
+ * Pass usb as the name to this function and will return a list of two
+ * nodes offsets: /ehci@c5008000 and ehci@c500.
+ *
+ * All nodes returned will match the compatible ID, as it is assumed that
+ * all peripherals use the same driver.
+ *
+ * If no alias node is found, then the node list will be returned in the
+ * order found in the fdt. If the aliases mention a node which doesn't
+ * exist, then this will be ignored. If nodes are found with no aliases,
+ * they will be added in any order.
+ *
+ * The array returned will not have any gaps.
+ *
+ * If there is a gap in the aliases, then this function will only return up
+ * to the number of nodes it found until the gap. It will also print a
warning
+ * in this case. As an example, say you define aliases for usb2 and usb3, and
+ * have 3 nodes. Then in this case the node without an alias will become usb0
+ * and the aliases will be use for usb2 and usb3. But since there is no
+ * usb1, this function will only list one node (usb0), and will print a
+ * warning.
+ *
+ * This function does not check node properties - so it is possible that the
+ * node is marked disabled (status = disabled). The caller is expected to
+ * deal with this.
+ * TBD: It might be nicer to handle this here since we don't want a
+ * discontiguous list to result in the caller.
+ *
+ * Note: the algorithm used is O(maxcount).
+ *
+ * @param blob FDT blob to use
+ * @param name Root name of alias to search for
+ * @param id Compatible ID to look for
+ * @param node Place to put list of found nodes
+ * @param maxcount Maximum number of nodes to find
+ * @return number of nodes found on success, FTD_ERR_... on error
+ */
+int fdtdec_find_aliases(const void *blob, const char *name,
+ enum fdt_compat_id id, int *node_list, int maxcount);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index fb3d79d..b01978d 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -147,6 +147,95 @@ int fdtdec_next_alias(const void *blob, const char *name,
return node;
}
+/* TODO: Can we tighten this code up a little? */
+int fdtdec_find_aliases(const void *blob, const char *name,
+ enum fdt_compat_id id, int *node_list, int maxcount)
+{
+ int nodes[maxcount];
+ int num_found = 0;
+ int alias_node;
+ int node;
+ int count;
+ int i, j;
+
+ /* find the alias node if present */
+ alias_node = fdt_path_offset(blob, /aliases);
+
+ /*
+ * start with nothing, and we can assume that the root node can't
+ * match
+ */
+ memset(nodes, '\0', sizeof(nodes));
+
+ /* First find all the compatible nodes */
+ node = 0;
+ for (node = count = 0; node = 0 count maxcount;) {
+ node = fdtdec_next_compatible(blob, node, id);
+ if (node 0)
+ nodes[count++] = node;
+ }
+
+ /* Now find all the aliases */
+ memset(node_list, '\0', sizeof(*node_list) * maxcount);
+ for (i = 0; i maxcount; i++) {
+ int found;
+
Re: [U-Boot] [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it
Dear Simon Glass, In message CAPnjgZ3592m_m=tmafptwzo+_o94veykvrffdgpp599igef...@mail.gmail.com you wrote: I have brought in PPC to board_f.c and board_r.c but not dealt with relocation. Once I have done that, gone through the new x86 series again and MAKEALL doesn't scream too loudly I'll do another RFC along these lines. I'm seriously concerned about you insisting to include relocation here. This has nothign to do with it. Leave that out. 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 When the only tool you have is a hammer, you tend to treat everything as if it were a nail.- Abraham Maslow ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] initcall revisited - A new idea to discuss
Dear Simon Glass, In message capnjgz3aoyvypa93ecbmyqhcaazcbphfcyhxyya1ax+9_ue...@mail.gmail.com you wrote: I have been thinking if there is a way we can avoid the post-processing perhaps by specifying two function parameters to the macro (the init function to call and its prerequisite) and having the initcall code sort the list before starting. We could have dummy You mean sort at runtime? NAK. all this must be done when building, i. e. at compile time. 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 The combination of a number of things to make existence worthwhile. Yes, the philosophy of 'none,' meaning 'all.' -- Spock and Lincoln, The Savage Curtain, stardate 5906.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] initcall revisited - A new idea to discuss
Hi Wolfgang, On Tue, Jan 3, 2012 at 2:36 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message capnjgz3aoyvypa93ecbmyqhcaazcbphfcyhxyya1ax+9_ue...@mail.gmail.com you wrote: I have been thinking if there is a way we can avoid the post-processing perhaps by specifying two function parameters to the macro (the init function to call and its prerequisite) and having the initcall code sort the list before starting. We could have dummy You mean sort at runtime? NAK. all this must be done when building, i. e. at compile time. Yes that's what I meant. It is more flexible to do this at build time if we are happy with the additional build step. OK. Regards, Simon 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 The combination of a number of things to make existence worthwhile. Yes, the philosophy of 'none,' meaning 'all.' -- Spock and Lincoln, The Savage Curtain, stardate 5906.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Tue, Jan 3, 2012 at 5:08 PM, Scott Wood scottw...@freescale.com wrote: Even on SLC chips, when using an ECC block size of 512 bytes? Or are you only able to find MLC? I looked for a datasheet for a 4K NAND chip, but couldn't find one readily available from a Google search. Hopefully someone internally can provide me with the one for the chip we're using. Yes, this is SLC. The Micron MT29F8G08ABABAWP is one example. The datasheet is here (sign-up required, unfortunately - I can send a copy if you want): https://www.micron.com/parts/nand-flash/mass-storage/mt29f8g08ababawp On page 93, it says Minimum required ECC: 4-bit ECC per 540 bytes of data. Maybe there are some 4k parts around that don't have this limitation, but our hardware guy informed me that all of the common (high availability) 4k parts he saw were similar. There's also the issue of ECC on the boot page itself -- that has to be hardware ECC, because there's no software running yet. True. I guess for random bit-flips, maybe that's just as much a problem as the other blocks/pages? I know that the first block is somewhat special, in that it's guaranteed not to be bad for some minimum # of P/E cycles; will ECC errors still accumulate the same as any other block? AFAIK, we've just been using 1-bit hw ECC. I don't know what NAND chip was used for testing, or how much stress testing was done. OK. Thanks for the quick reply Scott! -- Matthew L. Creech ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it
Hi Wolfgang, On Tue, Jan 3, 2012 at 2:35 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message CAPnjgZ3592m_m=tmafptwzo+_o94veykvrffdgpp599igef...@mail.gmail.com you wrote: I have brought in PPC to board_f.c and board_r.c but not dealt with relocation. Once I have done that, gone through the new x86 series again and MAKEALL doesn't scream too loudly I'll do another RFC along these lines. I'm seriously concerned about you insisting to include relocation here. This has nothign to do with it. Leave that out. I'm not insisting, only that I have already done a series for generic relocation so figured this new series would come second. I did signal this right at the beginning when suggesting the approach: http://lists.denx.de/pipermail/u-boot/2011-November/109987.html Anyway, leaving out relocation is easier so I will rebase this series on top of master instead. Regards, Simon 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 When the only tool you have is a hammer, you tend to treat everything as if it were a nail. - Abraham Maslow ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On 01/03/2012 04:43 PM, Matthew L. Creech wrote: On Tue, Jan 3, 2012 at 5:08 PM, Scott Wood scottw...@freescale.com wrote: Even on SLC chips, when using an ECC block size of 512 bytes? Or are you only able to find MLC? I looked for a datasheet for a 4K NAND chip, but couldn't find one readily available from a Google search. Hopefully someone internally can provide me with the one for the chip we're using. Yes, this is SLC. The Micron MT29F8G08ABABAWP is one example. The datasheet is here (sign-up required, unfortunately - I can send a copy if you want): https://www.micron.com/parts/nand-flash/mass-storage/mt29f8g08ababawp The sign-up terms say: Use License Permission is granted to download one (1) copy of the materials on Micron's websites for personal, non-commercial transitory viewing only. This is the grant of a limited and non-exclusive license, not a transfer of title, and under this license you may not: (a) modify or further copy the materials; (b) use the materials for any commercial purpose, or for any public display (commercial or noncommercial); (c) attempt to decompile or reverse engineer any software contained on Micron's websites; (d) remove any copyright or other proprietary notices on the materials; (e) transfer the materials to another person or mirror or frame the materials on any other website or server. It could be argued that my purpose is commercial, since I'm trying to gain information to help support NAND controller hardware that my employer sells (even though it's to Micron's benefit to maximize the number of systems their NAND chips can interoperate with...). Of course, that logic also applies to anyone using the information to build a product for sale, that includes a Micron chip -- which seems to be exactly who they'd be wanting to access these documents -- so it's probably not what they meant (unless they give customers access via some other terms). It's not obvious what they *do* mean, though. On page 93, it says Minimum required ECC: 4-bit ECC per 540 bytes of data. OK. Is booting from a source other than NAND (at least enough to fit software BCH support) an option? Maybe there are some 4k parts around that don't have this limitation, but our hardware guy informed me that all of the common (high availability) 4k parts he saw were similar. I found this after some more searching, but I've no idea if it (or related chips) are highly available: http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NANDFlash/SLC_LargeBlock/8Gbit/K9F8G08U0M/ds_k9f8g08x0m_rev10.pdf There's also the issue of ECC on the boot page itself -- that has to be hardware ECC, because there's no software running yet. True. I guess for random bit-flips, maybe that's just as much a problem as the other blocks/pages? I know that the first block is somewhat special, in that it's guaranteed not to be bad for some minimum # of P/E cycles; will ECC errors still accumulate the same as any other block? The datasheets I checked say things like guaranteed to be a valid block up to 1K program/erase cycles with 1bit/512Byte ECC (this is on a chip that wants 1bit ECC normally) -- so it looks like it's just guaranteed to not be an official bad block, not guaranteed to not have any bit flips. You could check your datasheet to see what its specific claim is. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] User Question
Is this the list I can ask questions for deploying uboot to a custom board based off the blackfin bf548? Some of my questions are not processor specific (like what is the approach to getting the micrel ks8995 and a smsc lan9215 talking and started -the ks8995 needs a spi start command)? I've started digging into the documentation at http://www.denx.de/wiki/U-Boot/Documentation and the git repository. And I'm trying to find out if someone has already done this so I don't have to reinvent the wheel. Thanks for any replies and my apologies if I am in the wrong spot. I think you need to bug Mike with this stuff. btw yes, this list should be the right place. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MXS-NAND: Backport ecc.size from linux kernel
On 01/03/2012 03:20 PM, Marek Vasut wrote: On 12/19/2011 02:23 PM, Marek Vasut wrote: On 12/18/2011 11:50 AM, Marek Vasut wrote: What specifically is happening in ubi part with ecc.size = 512? The driver doesn\t support subpage writes. Is this meant to be a workaround for the NAND layer ignoring a driver setting NAND_NO_SUBPAGE_WRITE? I'd rather just fix that... -Scott Any news here ? I just got back from end-of-year vacation; I hope you had good time :) I'll look at it soon (will probably just remove the mask and trust the driver to not set flags that don't make sense). Thanks for the reminder. Naw, it should be fixed in linux too! We should probably start a discussion there. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] Exynos: PWM: Add TCMPB3 field in pwm structure
Dear Chander Kashyap, On 19 December 2011 17:56, Chander Kashyap chander.kash...@linaro.org wrote: Add TCMPB3 field in pwm structure, earliar this was res1. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- arch/arm/include/asm/arch-exynos/pwm.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to u-boot-samsung. Thanks,Minkyu Kang.-- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Chander Kashyap, On 19 December 2011 17:56, Chander Kashyap chander.kash...@linaro.org wrote: Earliar ARM clock frequency was calculated by: MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. It is fixed by calculating it as follows: ARMCLK=MOUTCORE / (DIVCORE + 1) / (DIVCORE2 + 1) Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- Changes for V2: - Fixed commit comment - Fixed comment in clock.c exynos4_get_arm_clk () - Renamed dout_apll to armclk in clock.c exynos4_get_arm_clk () arch/arm/cpu/armv7/exynos/clock.c | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) applied to u-boot-samsung. Thanks, Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/17] x86: Import glibc memcpy implementation
On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
Taken from glibc version 2.14.90
Signed-off-by: Graeme Russ graeme.r...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---
arch/x86/include/asm/string.h | 2 +-
arch/x86/lib/string.c | 61
+
2 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
index 3aa6c11..0ad612f 100644
--- a/arch/x86/include/asm/string.h
+++ b/arch/x86/include/asm/string.h
@@ -14,7 +14,7 @@ extern char * strrchr(const char * s, int c);
#undef __HAVE_ARCH_STRCHR
extern char * strchr(const char * s, int c);
-#undef __HAVE_ARCH_MEMCPY
+#define __HAVE_ARCH_MEMCPY
extern void * memcpy(void *, const void *, __kernel_size_t);
#undef __HAVE_ARCH_MEMMOVE
diff --git a/arch/x86/lib/string.c b/arch/x86/lib/string.c
index f2ea7e4..1fde81b 100644
--- a/arch/x86/lib/string.c
+++ b/arch/x86/lib/string.c
@@ -85,3 +85,64 @@ void *memset(void *dstpp, int c, size_t len)
return dstpp;
}
+
+#define OP_T_THRES 8
+#define OPSIZ (sizeof(op_t))
+
+#define BYTE_COPY_FWD(dst_bp, src_bp, nbytes) \
+do { \
+ int __d0; \
+ asm volatile( \
+ /* Clear the direction flag, so copying goes forward. */ \
+ cld\n \
+ /* Copy bytes. */ \
+ rep\n \
+ movsb : \
+ =D (dst_bp), =S (src_bp), =c (__d0) : \
+ 0 (dst_bp), 1 (src_bp), 2 (nbytes) : \
+ memory); \
+} while (0)
+
+#define WORD_COPY_FWD(dst_bp, src_bp, nbytes_left, nbytes) \
+do { \
+ int __d0; \
+ asm volatile( \
+ /* Clear the direction flag, so copying goes forward. */ \
+ cld\n \
+ /* Copy longwords. */ \
+ rep\n \
+ movsl : \
+ =D (dst_bp), =S (src_bp), =c (__d0) : \
+ 0 (dst_bp), 1 (src_bp), 2 ((nbytes) / 4) : \
+ memory); \
+ (nbytes_left) = (nbytes) % 4; \
+} while (0)
+
+void *memcpy(void *dstpp, const void *srcpp, size_t len)
+{
+ unsigned long int dstp = (long int)dstpp;
+ unsigned long int srcp = (long int)srcpp;
+
+ /* Copy from the beginning to the end. */
+
+ /* If there not too few bytes to copy, use word copy. */
+ if (len = OP_T_THRES) {
+ /* Copy just a few bytes to make DSTP aligned. */
+ len -= (-dstp) % OPSIZ;
+ BYTE_COPY_FWD(dstp, srcp, (-dstp) % OPSIZ);
+
+ /* Copy from SRCP to DSTP taking advantage of the known
+ * alignment of DSTP. Number of bytes remaining is put
+ * in the third argument, i.e. in LEN. This number may
+ * vary from machine to machine.
+ */
+ WORD_COPY_FWD(dstp, srcp, len, len);
+
+ /* Fall out and copy the tail. */
+ }
+
+ /* There are just a few bytes to copy. Use byte memory operations. */
+ BYTE_COPY_FWD(dstp, srcp, len);
+
+ return dstpp;
+}
--
1.7.5.2.317.g391b14
___
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 v4 3/4] mmc: fsl_esdhc: Implement card-detect hook.
2012/1/2 Thierry Reding thierry.red...@avionic-design.de:
This card-detect hook probably doesn't work. Perhaps somebody with more
knowledge about the hardware can comment on this. I think that perhaps
even the complete code from esdhc_init() could go into the getcd()
function instead or mmc_getcd() needs to be called at some later time
after mmc_init(), which, however, would require many other drivers to
change.
yes, the hook in the patch does not work for the fsl i.mx sdhc controller due to
silicon issues and we need always use gpio to read the card detection status.
In addition to implementing the hook, this patch also removes the call
to the board_mmc_getcd() function which is now called from the MMC
framework and is no longer required here.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
Tested ok on i.mx51evk board,
Tested-by: Jason Liu jason@linaro.org
drivers/mmc/fsl_esdhc.c | 29 -
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index f038acc..1ed5355 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -418,7 +418,6 @@ static int esdhc_init(struct mmc *mmc)
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
int timeout = 1000;
- int ret = 0;
/* Reset the entire host controller */
esdhc_write32(regs-sysctl, SYSCTL_RSTA);
@@ -445,24 +444,19 @@ static int esdhc_init(struct mmc *mmc)
/* Set timout to the maximum value */
esdhc_clrsetbits32(regs-sysctl, SYSCTL_TIMEOUT_MASK, 14 16);
- /* Check if there is a callback for detecting the card */
- ret = board_mmc_getcd(mmc);
- if (ret 0) {
- timeout = 1000;
- while (!(esdhc_read32(regs-prsstat) PRSSTAT_CINS)
- --timeout)
- udelay(1000);
+ return 0;
+}
- if (timeout = 0)
- ret = NO_CARD_ERR;
- } else {
- if (ret == 0)
- ret = NO_CARD_ERR;
- else
- ret = 0;
- }
+static int esdhc_getcd(struct mmc *mmc)
+{
+ struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
+ int timeout = 1000;
+
+ while (!(esdhc_read32(regs-prsstat) PRSSTAT_CINS) --timeout)
+ udelay(1000);
- return ret;
+ return timeout 0;
}
static void esdhc_reset(struct fsl_esdhc *regs)
@@ -500,6 +494,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg
*cfg)
mmc-send_cmd = esdhc_send_cmd;
mmc-set_ios = esdhc_set_ios;
mmc-init = esdhc_init;
+ mmc-getcd = esdhc_getcd;
voltage_caps = 0;
caps = regs-hostcapblt;
--
1.7.8.1
___
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 02/17] x86: Speed up copy-to-RAM and clear BSS operations
Hi Graeme,
On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
The implementations of memcpy and memset are now the optimised versions
from glibc, so use them instead of simple copy loops
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
arch/x86/lib/board.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index d742fec..ba6b59f 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -188,26 +188,19 @@ static int calculate_relocation_address(void)
static int copy_uboot_to_ram(void)
{
- ulong *dst_addr = (ulong *)gd-relocaddr;
- ulong *src_addr = (ulong *)__text_start;
- ulong *end_addr = (ulong *)__data_end;
+ size_t len = (size_t)(__data_end) - (size_t)(__text_start);
Extra brackets here. Also is the type of these not char[] already? Same Q below.
- while (src_addr end_addr)
- *dst_addr++ = *src_addr++;
+ memcpy((void *)gd-relocaddr, (void *)__text_start, len);
return 0;
}
static int clear_bss(void)
{
- void *bss_start = __bss_start;
- void *bss_end = __bss_end;
+ ulong dst_addr = (ulong)(__bss_start) + gd-reloc_off;
+ size_t len = (size_t)(__bss_end) - (size_t)(__bss_start);
- ulong *dst_addr = (ulong *)(bss_start + gd-reloc_off);
- ulong *end_addr = (ulong *)(bss_end + gd-reloc_off);
-
- while (dst_addr end_addr)
- *dst_addr++ = 0x;
+ memset((void *)dst_addr, 0x00, len);
return 0;
}
--
1.7.5.2.317.g391b14
___
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 v4 1/4] mmc: Change board_mmc_getcd() function prototype.
2012/1/2 Thierry Reding thierry.red...@avionic-design.de: The new API no longer uses the extra cd parameter that was used to store the card presence state. Instead, this information is returned via the function's return value. board_mmc_getcd() returns -1 to indicate that no card-detection mechanism is implemented; 0 indicates that no card is present and 1 is returned if it was detected that a card is present. The rationale for this change can be found in the following email thread: http://lists.denx.de/pipermail/u-boot/2011-November/110180.html In summary, the old API was not consistent with the rest of the MMC API which always passes a struct mmc as the first parameter. Furthermore the cd parameter was used to mean card absence in some implementations and card presence in others. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- board/efikamx/efikamx.c | 9 + board/emk/top9000/top9000.c | 12 ++-- board/freescale/mx51evk/mx51evk.c | 9 + board/freescale/mx53ard/mx53ard.c | 9 + board/freescale/mx53evk/mx53evk.c | 9 + board/freescale/mx53loco/mx53loco.c | 9 + board/freescale/mx53smd/mx53smd.c | 6 ++ doc/README.atmel_mci | 12 ++-- drivers/mmc/fsl_esdhc.c | 8 +--- drivers/mmc/mmc.c | 4 ++-- include/mmc.h | 2 +- 11 files changed, 39 insertions(+), 50 deletions(-) Tested ok on i.mx51evk board, Tested-by: Jason Liu jason@linaro.org [...] ___ 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 03/17] x86: Remove GDR related magic numbers
Hi Graeme, On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/x86/cpu/start.S | 3 ++- arch/x86/include/asm/processor.h | 6 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S index f87633b..7f9b6a7 100644 --- a/arch/x86/cpu/start.S +++ b/arch/x86/cpu/start.S @@ -29,6 +29,7 @@ #include config.h #include version.h #include asm/global_data.h +#include asm/processor.h #include asm/processor-flags.h #include generated/asm-offsets.h @@ -58,7 +59,7 @@ _start: /* This is the 32-bit cold-reset entry point */ /* Load the segement registes to match the gdt loaded in start16.S */ - movl $0x18, %eax + movl $(GDT_ENTRY_32BIT_DS * 8), %eax movw %ax, %fs movw %ax, %ds movw %ax, %gs diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 1e5dccd..203c63a 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -24,9 +24,13 @@ #ifndef __ASM_PROCESSOR_H_ #define __ASM_PROCESSOR_H_ 1 -#define GDT_ENTRY_32BIT_CS 2 +#define GDT_ENTRY_NULL 0 +#define GDT_ENTRY_UNUSED (GDT_ENTRY_NULL + 1) +#define GDT_ENTRY_32BIT_CS (GDT_ENTRY_UNUSED + 1) #define GDT_ENTRY_32BIT_DS (GDT_ENTRY_32BIT_CS + 1) #define GDT_ENTRY_16BIT_CS (GDT_ENTRY_32BIT_DS + 1) #define GDT_ENTRY_16BIT_DS (GDT_ENTRY_16BIT_CS + 1) +#define GDT_NUM_ENTRIES (GDT_ENTRY_16BIT_DS + 1) + Ick - any reason not to use an enum here? Regards, Simon #endif -- 1.7.5.2.317.g391b14 ___ 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 v4 2/4] mmc: Implement card detection.
2012/1/2 Thierry Reding thierry.red...@avionic-design.de: Check for card detect each time an MMC/SD device is initialized. If card detection is not implemented, this code behaves as before and continues assuming a card is present. If no card is detected, has_init is reset for the MMC/SD device (to force initialization next time) and an error is returned. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- drivers/mmc/arm_pl180_mmci.c | 1 + drivers/mmc/bfin_sdh.c | 1 + drivers/mmc/davinci_mmc.c | 1 + drivers/mmc/ftsdc010_esdhc.c | 1 + drivers/mmc/gen_atmel_mci.c | 1 + drivers/mmc/mmc.c | 18 ++ drivers/mmc/mmc_spi.c | 1 + drivers/mmc/mxcmmc.c | 1 + drivers/mmc/mxsmmc.c | 1 + drivers/mmc/omap_hsmmc.c | 1 + drivers/mmc/pxa_mmc_gen.c | 1 + drivers/mmc/s5p_mmc.c | 1 + drivers/mmc/sdhci.c | 1 + drivers/mmc/sh_mmcif.c | 1 + include/mmc.h | 2 ++ 15 files changed, 33 insertions(+), 0 deletions(-) Tested ok on i.mx51evk board, Tested-by: Jason Liu jason@linaro.org [...] -- 1.7.8.1 ___ 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 05/17] x86: Simplify Flash-to-RAM code execution transition
Hi Graeme,
On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
Signed-off-by: Graeme Russ graeme.r...@gmail.com
Commit message?
---
arch/x86/cpu/start.S | 20 +---
arch/x86/include/asm/u-boot-x86.h | 2 ++
arch/x86/lib/board.c | 25 ++---
3 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
index 7f9b6a7..9592158 100644
--- a/arch/x86/cpu/start.S
+++ b/arch/x86/cpu/start.S
@@ -96,32 +96,22 @@ car_init_ret:
movw $0x85, %ax
jmp die
-.globl relocate_code
-.type relocate_code, @function
-relocate_code:
+.globl board_init_f_r_trampoline
+.type board_init_f_r_trampoline, @function
+board_init_f_r_trampoline:
/*
* SDRAM has been initialised, U-Boot code has been copied into
* RAM, BSS has been cleared and relocation adjustments have been
* made. It is now time to jump into the in-RAM copy of U-Boot
*
* %eax = Address of top of stack
*new* top of stack?
- * %edx = Address of Global Data
- * %ecx = Base address of in-RAM copy of U-Boot
*/
/* Setup stack in RAM */
movl %eax, %esp
- /* Setup call address of in-RAM copy of board_init_r() */
- movl $board_init_r, %ebp
- addl (GENERATED_GD_RELOC_OFF)(%edx), %ebp
-
- /* Setup parameters to board_init_r() */
- movl %edx, %eax
- movl %ecx, %edx
-
- /* Jump to in-RAM copy of board_init_r() */
- call *%ebp
+ /* Re-enter U-Boot by calling board_init_f_r */
+ call board_init_f_r
Isn't this a bit of a funny name? Why not call it something like
call_board_init_r() ?
die:
hlt
diff --git a/arch/x86/include/asm/u-boot-x86.h
b/arch/x86/include/asm/u-boot-x86.h
index 755f88a..c3d2277 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -61,5 +61,7 @@ u32 isa_map_rom(u32 bus_addr, int size);
int video_bios_init(void);
int video_init(void);
+void board_init_f_r_trampoline(ulong) __attribute__ ((noreturn));
+void board_init_f_r(void) __attribute__ ((noreturn));
#endif /* _U_BOOT_I386_H_ */
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index ba6b59f..978beaa 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -253,10 +253,29 @@ void board_init_f(ulong boot_flags)
gd-flags |= GD_FLG_RELOC;
- /* Enter the relocated U-Boot! */
- relocate_code(gd-start_addr_sp, gd, gd-relocaddr);
+ /*
+ * SDRAM is now initialised, U-Boot has been copied into SDRAM,
+ * the BSS has been cleared etc. The final stack can now be setup
+ * in SDRAM. Code execution will continue (momentarily) in Flash,
+ * but with the stack in SDRAM and Global Data in temporary memory
+ * (CPU cache)
+ */
+ board_init_f_r_trampoline(gd-start_addr_sp);
+
+ /* NOTREACHED - board_init_f_r_trampoline() does not return */
+ while (1)
+ ;
+}
+
+void board_init_f_r(void)
+{
+ /*
+ * Transfer execution from Flash to RAM by calculating the address
+ * of the in-RAM copy of board_init_r() and calling it
+ */
+ (board_init_r + gd-reloc_off)(gd, gd-relocaddr);
Nice that this is in C.
Regards,
Simon
- /* NOTREACHED - relocate_code() does not return */
+ /* NOTREACHED - board_init_r() does not return */
while (1)
;
}
--
1.7.5.2.317.g391b14
___
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 06/17] x86: Rework relocation calcuations
Hi Graeme, On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com I think all of these patches should have a commit message. Anyway: Acked-by: Simon Glass s...@chromium.org Regards, Simon --- arch/x86/lib/board.c | 23 +++ 1 files changed, 11 insertions(+), 12 deletions(-) diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c index 978beaa..bc5027b 100644 --- a/arch/x86/lib/board.c +++ b/arch/x86/lib/board.c @@ -164,24 +164,23 @@ static int calculate_relocation_address(void) ulong text_start = (ulong)__text_start; ulong bss_end = (ulong)__bss_end; ulong dest_addr; - ulong rel_offset; - - /* Calculate destination RAM Address and relocation offset */ - dest_addr = gd-ram_size; - dest_addr -= CONFIG_SYS_STACK_SIZE; - dest_addr -= (bss_end - text_start); /* - * Round destination address down to 16-byte boundary to keep - * IDT and GDT 16-byte aligned + * NOTE: All destination address are rounded down to 16-byte + * boundary to satisfy various worst-case alignment + * requirements */ - dest_addr = ~15; - rel_offset = dest_addr - text_start; + /* Stack is at top of available memory */ + dest_addr = gd-ram_size; + gd-start_addr_sp = dest_addr; - gd-start_addr_sp = gd-ram_size; + /* U-Boot is below the stack */ + dest_addr -= CONFIG_SYS_STACK_SIZE; + dest_addr -= (bss_end - text_start); + dest_addr = ~15; gd-relocaddr = dest_addr; - gd-reloc_off = rel_offset; + gd-reloc_off = (dest_addr - text_start); return 0; } -- 1.7.5.2.317.g391b14 ___ 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 07/17] x86: Use fs for global data
Hi Graeme,
On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
Use the base address of the 'F' segment as a pointer to the global data
structure. By adding the linear address (i.e. the 'D' segment address)
as the first word of the global data structure, the address of the
global data relative to the 'D' segment can be found simply, for
example, by:
fs movl 0, %eax
This makes the gd 'pointer' writable prior to relocation (by reloading
the GDT) which brings x86 into line with all other arches
What is the GDT?
NOTE: Writing to the gd 'pointer' is expensive (but we only do it
twice) but using it to access global data members (read and write) is
still fairly cheap
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
arch/x86/cpu/cpu.c | 53 --
arch/x86/cpu/start.S | 8 -
arch/x86/include/asm/global_data.h | 21 +
arch/x86/include/asm/processor.h | 6 +++-
arch/x86/include/asm/u-boot-x86.h | 2 +
arch/x86/lib/board.c | 56
+---
6 files changed, 98 insertions(+), 48 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index bf55c26..e7a5fc0 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -90,6 +90,37 @@ static void load_gdt(const u64 *boot_gdt, u16 num_entries)
asm volatile(lgdtl %0\n : : m (gdt));
}
+void init_gd(gd_t *id, u64 *gdt_addr)
+{
+ id-gd_addr = (ulong)id;
+ setup_gdt(id, gdt_addr);
+}
+
+void setup_gdt(gd_t *id, u64 *gdt_addr)
I will probably never understand this function but a comment might be nice.
+{
+ /* CS: code, read/execute, 4 GB, base 0 */
+ gdt_addr[GDT_ENTRY_32BIT_CS] = GDT_ENTRY(0xc09b, 0, 0xf);
+
+ /* DS: data, read/write, 4 GB, base 0 */
+ gdt_addr[GDT_ENTRY_32BIT_DS] = GDT_ENTRY(0xc093, 0, 0xf);
+
+ /* FS: data, read/write, 4 GB, base (Global Data Pointer) */
+ gdt_addr[GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093, (ulong)id, 0xf);
+
+ /* 16-bit CS: code, read/execute, 64 kB, base 0 */
Extra indent?
+ gdt_addr[GDT_ENTRY_16BIT_CS] = GDT_ENTRY(0x109b, 0, 0x0);
+
+ /* 16-bit DS: data, read/write, 64 kB, base 0 */
+ gdt_addr[GDT_ENTRY_16BIT_DS] = GDT_ENTRY(0x1093, 0, 0x0);
+
+ load_gdt(gdt_addr, GDT_NUM_ENTRIES);
+ load_ds(GDT_ENTRY_32BIT_DS);
+ load_es(GDT_ENTRY_32BIT_DS);
+ load_gs(GDT_ENTRY_32BIT_DS);
+ load_ss(GDT_ENTRY_32BIT_DS);
+ load_fs(GDT_ENTRY_32BIT_FS);
+}
+
int x86_cpu_init_f(void)
{
const u32 em_rst = ~X86_CR0_EM;
@@ -117,28 +148,6 @@ int x86_cpu_init_r(void)
movl %%eax, %%cr0\n
wbinvd\n : : i (nw_cd_rst) : eax);
- /*
- * There are machines which are known to not boot with the GDT
- * being 8-byte unaligned. Intel recommends 16 byte alignment
- */
- static const u64 boot_gdt[] __aligned(16) = {
- /* CS: code, read/execute, 4 GB, base 0 */
- [GDT_ENTRY_32BIT_CS] = GDT_ENTRY(0xc09b, 0, 0xf),
- /* DS: data, read/write, 4 GB, base 0 */
- [GDT_ENTRY_32BIT_DS] = GDT_ENTRY(0xc093, 0, 0xf),
- /* 16-bit CS: code, read/execute, 64 kB, base 0 */
- [GDT_ENTRY_16BIT_CS] = GDT_ENTRY(0x109b, 0, 0x0),
- /* 16-bit DS: data, read/write, 64 kB, base 0 */
- [GDT_ENTRY_16BIT_DS] = GDT_ENTRY(0x1093, 0, 0x0),
- };
-
- load_gdt(boot_gdt, GDT_NUM_ENTRIES);
- load_ds(GDT_ENTRY_32BIT_DS);
- load_es(GDT_ENTRY_32BIT_DS);
- load_fs(GDT_ENTRY_32BIT_DS);
- load_gs(GDT_ENTRY_32BIT_DS);
- load_ss(GDT_ENTRY_32BIT_DS);
-
/* Initialize core interrupt and exception functionality of CPU */
cpu_init_interrupts();
return 0;
diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
index 9592158..4fb9e6b 100644
--- a/arch/x86/cpu/start.S
+++ b/arch/x86/cpu/start.S
@@ -31,7 +31,7 @@
#include asm/global_data.h
#include asm/processor.h
#include asm/processor-flags.h
-#include generated/asm-offsets.h
+#include generated/generic-asm-offsets.h
.section .text
.code32
@@ -85,6 +85,12 @@ car_init_ret:
*/
movl $CONFIG_SYS_INIT_SP_ADDR, %esp
+ /* Initialise the Global Data Pointer */
+ movl $CONFIG_SYS_INIT_GD_ADDR, %eax
+ movl %eax, %edx
+ addl $GENERATED_GBL_DATA_SIZE, %edx
+ call init_gd;
+
/* Set parameter to board_init_f() to boot flags */
xorl %eax, %eax
movw %bx, %ax
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index 05a2139..908a02c 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -36,6 +36,8 @@
#ifndef __ASSEMBLY__
typedef
Re: [U-Boot] [PATCH 08/17] x86: Set GD_FLG_RELOC after entering in-RAM copy of U-Boot
On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com Acked-by: Simon Glass s...@chromium.org --- arch/x86/lib/board.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c index 9c4ecda..4e54dba 100644 --- a/arch/x86/lib/board.c +++ b/arch/x86/lib/board.c @@ -252,8 +252,6 @@ void board_init_f(ulong boot_flags) hang(); } - gd-flags |= GD_FLG_RELOC; - /* * SDRAM is now initialised, U-Boot has been copied into SDRAM, * the BSS has been cleared etc. The final stack can now be setup @@ -322,6 +320,8 @@ void board_init_r(gd_t *id, ulong dest_addr) /* compiler optimization barrier needed for GCC = 3.4 */ __asm__ __volatile__( : : : memory); + gd-flags |= GD_FLG_RELOC; + gd-bd = bd_data; memset(gd-bd, 0, sizeof(bd_t)); show_boot_progress(0x22); -- 1.7.5.2.317.g391b14 ___ 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 09/17] x86: Create weak init_cache() function
Hi Graeme,
On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
arch/x86/cpu/cpu.c | 18 +++---
arch/x86/include/asm/u-boot-x86.h | 1 +
arch/x86/lib/board.c | 1 +
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index e7a5fc0..4351f20 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -140,6 +140,14 @@ int cpu_init_f(void) __attribute__((weak,
alias(x86_cpu_init_f)));
int x86_cpu_init_r(void)
{
+ /* Initialize core interrupt and exception functionality of CPU */
+ cpu_init_interrupts();
+ return 0;
+}
This doesn't seem to match the commit title.
+int cpu_init_r(void) __attribute__((weak, alias(x86_cpu_init_r)));
+
+void x86_enable_caches(void)
+{
const u32 nw_cd_rst = ~(X86_CR0_NW | X86_CR0_CD);
/* turn on the cache and disable write through */
@@ -147,12 +155,16 @@ int x86_cpu_init_r(void)
andl %0, %%eax\n
movl %%eax, %%cr0\n
wbinvd\n : : i (nw_cd_rst) : eax);
+}
+void enable_caches(void) __attribute__((weak, alias(x86_enable_caches)));
+
+int x86_init_cache(void)
+{
+ enable_caches();
Does this enable both I and D caches?
- /* Initialize core interrupt and exception functionality of CPU */
- cpu_init_interrupts();
return 0;
}
-int cpu_init_r(void) __attribute__((weak, alias(x86_cpu_init_r)));
+int init_cache(void) __attribute__((weak, alias(x86_init_cache)));
int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
diff --git a/arch/x86/include/asm/u-boot-x86.h
b/arch/x86/include/asm/u-boot-x86.h
index 5540d51..878a1ee 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -39,6 +39,7 @@ int x86_cpu_init_f(void);
int cpu_init_f(void);
void init_gd(gd_t *id, u64 *gdt_addr);
void setup_gdt(gd_t *id, u64 *gdt_addr);
+int init_cache(void);
/* cpu/.../timer.c */
void timer_isr(void *);
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index 4e54dba..ffddfbe 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -140,6 +140,7 @@ init_fnc_t *init_sequence_f[] = {
init_fnc_t *init_sequence_r[] = {
copy_gd_to_ram,
+ init_cache,
Would enable_caches be a better name?
cpu_init_r, /* basic cpu dependent setup */
board_early_init_r, /* basic board dependent setup */
dram_init, /* configure available RAM banks */
--
1.7.5.2.317.g391b14
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/17] x86: Allow cache before copy to RAM
Hi Graeme,
On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
arch/x86/lib/board.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index ffddfbe..52e27e1 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -131,16 +131,11 @@ init_fnc_t *init_sequence_f[] = {
console_init_f,
dram_init_f,
calculate_relocation_address,
- copy_uboot_to_ram,
- clear_bss,
- do_elf_reloc_fixups,
NULL,
};
init_fnc_t *init_sequence_r[] = {
- copy_gd_to_ram,
- init_cache,
cpu_init_r, /* basic cpu dependent setup */
board_early_init_r, /* basic board dependent setup */
dram_init, /* configure available RAM banks */
@@ -269,6 +264,16 @@ void board_init_f(ulong boot_flags)
void board_init_f_r(void)
{
+ if (copy_gd_to_ram() != 0)
+ hang();
+
+ if (init_cache() != 0)
+ hang();
+
+ copy_uboot_to_ram();
+ clear_bss();
+ do_elf_reloc_fixups();
Can you not just put these in the init list above? Why do they need to
move back into this functoin?
Regards,
Simon
+
/*
* Transfer execution from Flash to RAM by calculating the address
* of the in-RAM copy of board_init_r() and calling it
--
1.7.5.2.317.g391b14
___
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 11/17] CHECKPATCH: arch/x86/cpu/*
Hi Graeme,
On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
Signed-off-by: Graeme Russ graeme.r...@gmail.com
Seems a bit more than just checkpatch.
Acked-by: Simon Glass s...@chromium.org
Regards,
Simon
---
arch/x86/cpu/interrupts.c | 2 +-
arch/x86/cpu/start16.S | 57 +++-
2 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c
index e0958eb..43ec3f8 100644
--- a/arch/x86/cpu/interrupts.c
+++ b/arch/x86/cpu/interrupts.c
@@ -174,7 +174,7 @@ struct desc_ptr {
unsigned short segment;
} __packed;
-struct idt_entry idt[256] __attribute__((aligned(16)));
+struct idt_entry idt[256] __aligned(16);
struct desc_ptr idt_ptr;
diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S
index 33e53cd..cc393ff 100644
--- a/arch/x86/cpu/start16.S
+++ b/arch/x86/cpu/start16.S
@@ -86,7 +86,11 @@ gdt_ptr:
.word 0x20 /* limit (32 bytes = 4 GDT entries) */
.long BOOT_SEG + gdt /* base */
- /* The GDT table ...
+/* Some CPUs are picky about GDT alignment... */
+.align 16
+gdt:
+ /*
+ * The GDT table ...
*
* Selector Type
* 0x00 NULL
@@ -94,17 +98,46 @@ gdt_ptr:
* 0x10 32bit code
* 0x18 32bit data/stack
*/
+ /* The NULL Desciptor - Mandatory */
+ .word 0x /* limit_low */
+ .word 0x /* base_low */
+ .byte 0x00 /* base_middle */
+ .byte 0x00 /* access */
+ .byte 0x00 /* flags + limit_high */
+ .byte 0x00 /* base_high */
-gdt:
- .word 0, 0, 0, 0 /* NULL */
- .word 0, 0, 0, 0 /* unused */
+ /* Unused Desciptor - (matches Linux) */
+ .word 0x /* limit_low */
+ .word 0x /* base_low */
+ .byte 0x00 /* base_middle */
+ .byte 0x00 /* access */
+ .byte 0x00 /* flags + limit_high */
+ .byte 0x00 /* base_high */
- .word 0x /* 4Gb - (0x10*0x1000 = 4Gb) */
- .word 0 /* base address = 0 */
- .word 0x9B00 /* code read/exec */
- .word 0x00CF /* granularity = 4096, 386 (+5th nibble of
limit) */
+ /*
+ * The Code Segment Descriptor:
+ * - Base = 0x
+ * - Size = 4GB
+ * - Access = Present, Ring 0, Exec (Code), Readable
+ * - Flags = 4kB Granularity, 32-bit
+ */
+ .word 0x /* limit_low */
+ .word 0x /* base_low */
+ .byte 0x00 /* base_middle */
+ .byte 0x9b /* access */
+ .byte 0xcf /* flags + limit_high */
+ .byte 0x00 /* base_high */
- .word 0x /* 4Gb - (0x10*0x1000 = 4Gb) */
- .word 0x0 /* base address = 0 */
- .word 0x9300 /* data read/write */
- .word 0x00CF /* granularity = 4096, 386 (+5th nibble of
limit) */
+ /*
+ * The Data Segment Descriptor:
+ * - Base = 0x
+ * - Size = 4GB
+ * - Access = Present, Ring 0, Non-Exec (Data), Writable
+ * - Flags = 4kB Granularity, 32-bit
+ */
+ .word 0x /* limit_low */
+ .word 0x /* base_low */
+ .byte 0x00 /* base_middle */
+ .byte 0x93 /* access */
+ .byte 0xcf /* flags + limit_high */
+ .byte 0x00 /* base_high */
--
1.7.5.2.317.g391b14
___
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 12/17] CHECKPATCH: arch/x86/lib/*
Hi Graeme, On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com Acked-by: Simon Glass s...@chromium.org Thanks for the x86 assembler lesson :-) Regards, Simon --- arch/x86/lib/bios.S | 134 +-- arch/x86/lib/realmode_switch.S | 61 +++ 2 files changed, 122 insertions(+), 73 deletions(-) diff --git a/arch/x86/lib/bios.S b/arch/x86/lib/bios.S index ce8deb5..239aaa9 100644 --- a/arch/x86/lib/bios.S +++ b/arch/x86/lib/bios.S @@ -246,11 +246,9 @@ rm_int1f: rm_def_int: iret - /* - * All interrupt jumptable entries jump to here - * after pushing the interrupt vector number onto the - * stack. + * All interrupt jumptable entries jump to here after pushing the + * interrupt vector number onto the stack. */ any_interrupt16: MAKE_BIOS_STACK @@ -272,7 +270,8 @@ gs movw OFFS_VECTOR(%bp), %ax je Lint_1ah movw $0x, %ax jmp Lout -Lint_10h: /* VGA BIOS services */ +Lint_10h: + /* VGA BIOS services */ call bios_10h jmp Lout Lint_11h: @@ -281,35 +280,42 @@ Lint_11h: Lint_12h: call bios_12h jmp Lout -Lint_13h: /* BIOS disk services */ +Lint_13h: + /* BIOS disk services */ call bios_13h jmp Lout -Lint_15h: /* Misc. BIOS services */ +Lint_15h: + /* Misc. BIOS services */ call bios_15h jmp Lout -Lint_16h: /* keyboard services */ +Lint_16h: + /* keyboard services */ call bios_16h jmp Lout -Lint_1ah: /* PCI bios */ +Lint_1ah: + /* PCI bios */ call bios_1ah jmp Lout Lout: cmpw $0, %ax je Lhandeled - /* Insert code for unhandeled INTs here. + /* + * Insert code for unhandeled INTs here. * - * ROLO prints a message to the console - * (we could do that but then we're in 16bit mode - * so we'll have to get back into 32bit mode - * to use the console I/O routines (if we do this - * we shuls make int 0x10 and int 0x16 work as well)) + * ROLO prints a message to the console we could do that but then + * we're in 16bit mode so we'll have to get back into 32bit mode + * to use the console I/O routines (if we do this we should make + * int 0x10 and int 0x16 work as well) */ Lhandeled: RESTORE_CALLERS_STACK - addw $2,%sp /* dump vector number */ - iret /* return from interrupt */ + /* dump vector number */ + addw $2,%sp + + /* return from interrupt */ + iret /* @@ -327,22 +333,24 @@ gs movw OFFS_AX(%bp), %ax je Lvid_cfg movw $0x, %ax ret -Lcur_pos: /* Read Cursor Position and Size */ +Lcur_pos: + /* Read Cursor Position and Size */ gs movw $0, OFFS_CX(%bp) gs movw $0, OFFS_DX(%bp) xorw %ax, %ax ret -Lvid_state: /* Get Video State */ -gs movw $(80 8|0x03), OFFS_AX(%bp) /* 80 columns, 80x25, 16 colors */ +Lvid_state: + /* Get Video State - 80 columns, 80x25, 16 colors */ +gs movw $(80 8|0x03), OFFS_AX(%bp) gs movw $0, OFFS_BX(%bp) xorw %ax, %ax ret -Lvid_cfg: /* Video Subsystem Configuration (EGA/VGA) */ -gs movw $0x10, OFFS_BX(%bp) /* indicate CGA/MDA/HGA */ +Lvid_cfg: + /* Video Subsystem Configuration (EGA/VGA) - indicate CGA/MDA/HGA */ +gs movw $0x10, OFFS_BX(%bp) xorw %ax, %ax ret - /* * BIOS interrupt 11h -- Equipment determination @@ -355,7 +363,6 @@ gs movw %ax, OFFS_AX(%bp) xorw %ax, %ax ret - /* * BIOS interrupt 12h -- Get Memory Size @@ -370,16 +377,18 @@ cs movw ram_in_64kb_chunks, %ax b12_more_than_640k: movw $0x280, %ax b12_return: -gs movw %ax, OFFS_AX(%bp) /* return number of kilobytes in ax */ + /* return number of kilobytes in ax */ +gs movw %ax, OFFS_AX(%bp) gs movw OFFS_FLAGS(%bp), %ax - andw $0xfffe, %ax /* clear carry -- function succeeded */ + + /* clear carry -- function succeeded */ + andw
Re: [U-Boot] [PATCH 13/17] x86: Move do_go_exec() out of board.c
On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
Signed-off-by: Graeme Russ graeme.r...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---
arch/x86/lib/Makefile | 1 +
arch/x86/lib/board.c | 27 ---
arch/x86/lib/cmd_boot.c | 64
+++
3 files changed, 65 insertions(+), 27 deletions(-)
create mode 100644 arch/x86/lib/cmd_boot.c
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index d584aa4..7820895 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -32,6 +32,7 @@ SOBJS-$(CONFIG_SYS_X86_REALMODE) += realmode_switch.o
COBJS-$(CONFIG_SYS_PC_BIOS) += bios_setup.o
COBJS-y += board.o
COBJS-y += bootm.o
+COBJS-y += cmd_boot.o
COBJS-y += gcc.o
COBJS-y += interrupts.o
COBJS-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index 52e27e1..533adf1 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -487,33 +487,6 @@ void hang(void)
;
}
-unsigned long do_go_exec(ulong (*entry)(int, char * const []),
- int argc, char * const argv[])
-{
- unsigned long ret = 0;
- char **argv_tmp;
-
- /*
- * x86 does not use a dedicated register to pass the pointer to
- * the global_data, so it is instead passed as argv[-1]. By using
- * argv[-1], the called 'Application' can use the contents of
- * argv natively. However, to safely use argv[-1] a new copy of
- * argv is needed with the extra element
- */
- argv_tmp = malloc(sizeof(char *) * (argc + 1));
-
- if (argv_tmp) {
- argv_tmp[0] = (char *)gd;
-
- memcpy(argv_tmp[1], argv, (size_t)(sizeof(char *) * argc));
-
- ret = (entry) (argc, argv_tmp[1]);
- free(argv_tmp);
- }
-
- return ret;
-}
-
void setup_pcat_compatibility(void)
__attribute__((weak, alias(__setup_pcat_compatibility)));
diff --git a/arch/x86/lib/cmd_boot.c b/arch/x86/lib/cmd_boot.c
new file mode 100644
index 000..a81a9a3
--- /dev/null
+++ b/arch/x86/lib/cmd_boot.c
@@ -0,0 +1,64 @@
+/*
+ * (C) Copyright 2008-2011
+ * Graeme Russ, graeme.r...@gmail.com
+ *
+ * (C) Copyright 2002
+ * Daniel Engström, Omicron Ceti AB, dan...@omicron.se
+ *
+ * (C) Copyright 2002
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH www.elinos.com
+ * Marius Groeger mgroe...@sysgo.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include command.h
+#include malloc.h
+#include asm/u-boot-x86.h
+
+unsigned long do_go_exec(ulong (*entry)(int, char * const []),
+ int argc, char * const argv[])
+{
+ unsigned long ret = 0;
+ char **argv_tmp;
+
+ /*
+ * x86 does not use a dedicated register to pass the pointer to
+ * the global_data, so it is instead passed as argv[-1]. By using
+ * argv[-1], the called 'Application' can use the contents of
+ * argv natively. However, to safely use argv[-1] a new copy of
+ * argv is needed with the extra element
+ */
+ argv_tmp = malloc(sizeof(char *) * (argc + 1));
+
+ if (argv_tmp) {
+ argv_tmp[0] = (char *)gd;
+
+ memcpy(argv_tmp[1], argv, (size_t)(sizeof(char *) * argc));
+
+ ret = (entry) (argc, argv_tmp[1]);
+ free(argv_tmp);
+ }
+
+ return ret;
+}
--
1.7.5.2.317.g391b14
___
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 14/17] x86: Move setup_pcat_compatibility() out of board.c
Hi Graeme,
On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
Signed-off-by: Graeme Russ graeme.r...@gmail.com
Perhaps mention why? Anyway:
Acked-by: Simon Glass s...@chromium.org
Regards,
Simon
---
arch/x86/lib/board.c | 7 ---
arch/x86/lib/zimage.c | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index 533adf1..993e7df 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -486,10 +486,3 @@ void hang(void)
for (;;)
;
}
-
-void setup_pcat_compatibility(void)
- __attribute__((weak, alias(__setup_pcat_compatibility)));
-
-void __setup_pcat_compatibility(void)
-{
-}
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index bb40517..2214286 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -314,6 +314,13 @@ void boot_zimage(void *setup_base, void *load_address)
#endif
}
+void setup_pcat_compatibility(void)
+ __attribute__((weak, alias(__setup_pcat_compatibility)));
+
+void __setup_pcat_compatibility(void)
+{
+}
+
int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
{
struct boot_params *base_ptr;
--
1.7.5.2.317.g391b14
___
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 16/17] x86: Simplify board.c
Hi Graeme, On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/x86/include/asm/init_helpers.h | 39 + arch/x86/include/asm/init_wrappers.h | 42 + arch/x86/lib/Makefile | 2 + arch/x86/lib/board.c | 297 +- arch/x86/lib/init_helpers.c | 142 arch/x86/lib/init_wrappers.c | 137 What is the rationale for putting these into separate files? If you didn't then they would be static and presumably less code size. Also for the commit message, is this really a simplification? It looks more like you are splitting the code into separate functions. Regards, Simon 6 files changed, 438 insertions(+), 221 deletions(-) create mode 100644 arch/x86/include/asm/init_helpers.h create mode 100644 arch/x86/include/asm/init_wrappers.h create mode 100644 arch/x86/lib/init_helpers.c create mode 100644 arch/x86/lib/init_wrappers.c diff --git a/arch/x86/include/asm/init_helpers.h b/arch/x86/include/asm/init_helpers.h new file mode 100644 index 000..14ef11a --- /dev/null +++ b/arch/x86/include/asm/init_helpers.h @@ -0,0 +1,39 @@ +/* + * (C) Copyright 2011 + * Graeme Russ, graeme.r...@gmail.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 + */ + +#ifndef _INIT_HELPERS_H_ +#define _INIT_HELPERS_H_ + +int display_banner(void); +int display_dram_config(void); +int init_baudrate_f(void); + +int mem_malloc_init_r(void); +int init_bd_struct_r(void); +int flash_init_r(void); +int init_ip_address_r(void); +int status_led_set_r(void); +int set_bootfile_r(void); +int set_load_addr_r(void); + +#endif /* !_INIT_HELPERS_H_ */ diff --git a/arch/x86/include/asm/init_wrappers.h b/arch/x86/include/asm/init_wrappers.h new file mode 100644 index 000..899ffb1 --- /dev/null +++ b/arch/x86/include/asm/init_wrappers.h @@ -0,0 +1,42 @@ +/* + * (C) Copyright 2011 + * Graeme Russ, graeme.r...@gmail.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 + */ + +#ifndef _INIT_WRAPPERS_H_ +#define _INIT_WRAPPERS_H_ + +int serial_initialize_r(void); +int env_relocate_r(void); +int pci_init_r(void); +int jumptable_init_r(void); +int pcmcia_init_r(void); +int kgdb_init_r(void); +int enable_interrupts_r(void); +int eth_initialize_r(void); +int reset_phy_r(void); +int ide_init_r(void); +int scsi_init_r(void); +int doc_init_r(void); +int bb_miiphy_init_r(void); +int post_run_r(void); + +#endif /* !_INIT_WRAPPERS_H_ */ diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index 57b6896..51836da 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -34,6 +34,8 @@ COBJS-y += board.o COBJS-y += bootm.o COBJS-y += cmd_boot.o COBJS-y += gcc.o +COBJS-y += init_helpers.o +COBJS-y += init_wrappers.o COBJS-y += interrupts.o COBJS-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o COBJS-$(CONFIG_SYS_GENERIC_TIMER) += pcat_timer.o diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c index fc7d0b7..f0a8e9c 100644 --- a/arch/x86/lib/board.c +++ b/arch/x86/lib/board.c @@ -33,62 +33,12 @@ #include common.h #include watchdog.h -#include command.h #include stdio_dev.h -#include version.h -#include malloc.h -#include net.h -#include ide.h
Re: [U-Boot] [PATCH 17/17] x86: Tweak initialisation procedure
Hi Graeme, On Sun, Jan 1, 2012 at 8:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/x86/include/asm/init_helpers.h | 5 + arch/x86/include/asm/relocate.h | 33 ++ arch/x86/lib/board.c | 188 +-- arch/x86/lib/init_helpers.c | 75 ++ arch/x86/lib/relocate.c | 32 +- 5 files changed, 206 insertions(+), 127 deletions(-) Seems like a fairly major tweak :-) Should this commit be split, and/or perhaps explain the purpose in the commit message? Regards, Simon create mode 100644 arch/x86/include/asm/relocate.h diff --git a/arch/x86/include/asm/init_helpers.h b/arch/x86/include/asm/init_helpers.h index 14ef11a..192f18e 100644 --- a/arch/x86/include/asm/init_helpers.h +++ b/arch/x86/include/asm/init_helpers.h @@ -27,7 +27,12 @@ int display_banner(void); int display_dram_config(void); int init_baudrate_f(void); +int calculate_relocation_address(void); +int copy_gd_to_ram_f_r(void); +int init_cache_f_r(void); + +int set_reloc_flag_r(void); int mem_malloc_init_r(void); int init_bd_struct_r(void); int flash_init_r(void); diff --git a/arch/x86/include/asm/relocate.h b/arch/x86/include/asm/relocate.h new file mode 100644 index 000..33129ef --- /dev/null +++ b/arch/x86/include/asm/relocate.h @@ -0,0 +1,33 @@ +/* + * (C) Copyright 2011 + * Graeme Russ, graeme.r...@gmail.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 + */ + +#ifndef _RELOCATE_H_ +#define _RELOCATE_H_ + +#include common.h + +int copy_uboot_to_ram(void); +int clear_bss(void); +int do_elf_reloc_fixups(void); + +#endif /* !_RELOCATE_H_ */ diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c index f0a8e9c..d45b8fd 100644 --- a/arch/x86/lib/board.c +++ b/arch/x86/lib/board.c @@ -35,7 +35,7 @@ #include watchdog.h #include stdio_dev.h #include asm/u-boot-x86.h -#include asm/processor.h +#include asm/relocate.h #include asm/init_helpers.h #include asm/init_wrappers.h @@ -43,31 +43,58 @@ /* * Breath some life into the board... * - * Initialize an SMC for serial comms, and carry out some hardware - * tests. + * Getting the board up and running is a three-stage process: + * 1) Execute from Flash, SDRAM Uninitialised + * At this point, there is a limited amount of non-SDRAM memory + * (typically the CPU cache, but can also be SRAM or even a buffer of + * of some peripheral). This limited memory is used to hold: + * - The initial copy of the Global Data Structure + * - A temporary stack + * - A temporary x86 Global Descriptor Table + * - The pre-console buffer (if enabled) * - * The first part of initialization is running from Flash memory; - * its main purpose is to initialize the RAM so that we - * can relocate the monitor code to RAM. + * The following is performed during this phase of execution: + * - Core low-level CPU initialisation + * - Console initialisation + * - SDRAM initialisation + * + * 2) Execute from Flash, SDRAM Initialised + * At this point we copy Global Data from the initial non-SDRAM + * memory and set up the permanent stack in SDRAM. The CPU cache is no + * longer being used as temporary memory, so we can now fully enable + * it. + * + * The following is performed during this phase of execution: + * - Create final stack in SDRAM + * - Copy Global Data from temporary memory to SDRAM + * - Enabling of CPU cache(s), + * - Copying of U-Boot code and data from Flash to RAM + * - Clearing of the BSS + * - ELF relocation adjustments + * + * 3) Execute from SDRAM + * The following is performed during this phase of execution: + * - All remaining initialisation */ /* - * All attempts to come up with a common initialization sequence - * that works for all boards and architectures failed: some of the - * requirements are just _too_ different. To get rid of the resulting - * mess of board dependend #ifdef'ed code we now make the whole - * initialization sequence configurable to
Re: [U-Boot] [PATCH] Origen: Select SCLKMPLL as FIMD0 parent clock
Dear Chander Kashyap, On 19 December 2011 15:16, Chander Kashyap chander.kash...@linaro.org wrote: Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- board/samsung/origen/lowlevel_init.S | 5 + board/samsung/origen/origen_setup.h | 12 2 files changed, 17 insertions(+), 0 deletions(-) applied to u-boot-samsung. Thanks, Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
