Re: [U-Boot] [PATCH 1/5] Add bmp_layout module for accessing BMP header data
On 02/05/13 01:11, Wolfgang Denk wrote: Dear Albert ARIBAUD, In message 20130204222628.545da91e@lilith you wrote: The point about md not checking alignment is indeed valid: one should know that a md.l requires a 4-byte-aligned address or it will abort. Or, one might do this _intentionally_ for some testing purposes. For me it is of utmost importance that U-Boot does not come in my way in such things. It is supposed to do _exactly_ what I ask it to do, even if this appears to be a stupid thing. I agree on this one, except for the case where doing that stupid thing bricks the board. OTOH, a cautious user may think that to ensure proper alignment, a BMP should be loaded on a 4-byte boundary, but IIUC that it precisely what will cause the load to fail, due to the sole 4-byte field of the BMP header being misaligned by two bytes. Sole 4 byte field? The bitmap file header has actually two 32-bit entries: file_size, and data_offset. [The reserved entry as we are using it should actually be two 16 bit entries, at least according to [1]). Yes, struct bmp_header is a packed array with non-natural order of entries; see also section Bitmap file header at [1]; we may consider this a really stupid thing to do, but we have to live with this fact. It was not that stupid in times of DOS and Win 3.1 when int was 16 bits long (and DRAM was 64K or even less)... [1] http://en.wikipedia.org/wiki/BMP_file_format As I understand the problem comes from the fact, that this issue has long been undetected, because the PTB that were/are responsible for GCC on ARM had decided that any access to apacked structure would be silently broken down into byte accesses, no matter what the actual data type was. While more recent versions of GCC started actually attempting 16 or 32 bit accesses, which failed on some systems. So if we leave BMP loading as it is now, the load address will need to be 16-bit-but-not-32-bit-aligned, which is complicated enough to require documentation. Indeed, this should be documented. And eventually the bmp command should print a warning message if it sees other alignment. Agreed on this also, but again what about the board brick case? Should we add the check for alignment and if it does not properly aligned deny further bmp header processing along with printing a warning? Or, the BMP struct could be prepended with two bytes so that the load address alignment requirement becomes a simple 4-byte boundary, which most users are... bound... to choose naturally. That would violate the standard defining the BMP header structure. Yep, I would not want this to happen. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx: Drop gpio0_7_pin_mux from phytec pcm051
On Monday 04 February 2013 at 18:23:02, Tom Rini wrote:
This mux is not currently used and appears to be a carry-over from the
am335x evm code.
This is absolutely right,so my
Acked-by: Lars Poeschel poesc...@lemonage.de
Cc: Lars Poeschel poesc...@lemonage.de
Signed-off-by: Tom Rini tr...@ti.com
---
board/phytec/pcm051/mux.c |5 -
1 file changed, 5 deletions(-)
diff --git a/board/phytec/pcm051/mux.c b/board/phytec/pcm051/mux.c
index 2cda331..4d3a1d5 100644
--- a/board/phytec/pcm051/mux.c
+++ b/board/phytec/pcm051/mux.c
@@ -63,11 +63,6 @@ static struct module_pin_mux spi0_pin_mux[] = {
};
#endif
-static struct module_pin_mux gpio0_7_pin_mux[] = {
- {OFFSET(ecap0_in_pwm0_out), (MODE(7) | PULLUDEN)}, /* GPIO0_7 */
- {-1},
-};
-
static struct module_pin_mux rmii1_pin_mux[] = {
{OFFSET(mii1_crs), MODE(1) | RXACTIVE}, /* RMII1_CRS */
{OFFSET(mii1_rxerr), MODE(1) | RXACTIVE}, /* RMII1_RXERR */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am33xx: pcm051: Remove wp pin mux for sd-card
From: Lars Poeschel poesc...@lemonage.de
The pcm051 does not have the wp pin connected to the sd-card socket.
Therefore remove the pinmux for the pin. The was a carry-over from
the am335x evm code.
Signed-off-by: Lars Poeschel poesc...@lemonage.de
---
board/phytec/pcm051/mux.c |1 -
1 file changed, 1 deletion(-)
diff --git a/board/phytec/pcm051/mux.c b/board/phytec/pcm051/mux.c
index 2cda331..74a873e 100644
--- a/board/phytec/pcm051/mux.c
+++ b/board/phytec/pcm051/mux.c
@@ -35,7 +35,6 @@ static struct module_pin_mux mmc0_pin_mux[] = {
{OFFSET(mmc0_dat0), (MODE(0) | RXACTIVE | PULLUP_EN)}, /* MMC0_DAT0 */
{OFFSET(mmc0_clk), (MODE(0) | RXACTIVE | PULLUP_EN)}, /* MMC0_CLK */
{OFFSET(mmc0_cmd), (MODE(0) | RXACTIVE | PULLUP_EN)}, /* MMC0_CMD */
- {OFFSET(mcasp0_aclkr), (MODE(4) | RXACTIVE)}, /* MMC0_WP */
{OFFSET(spi0_cs1), (MODE(5) | RXACTIVE | PULLUP_EN)}, /* MMC0_CD */
{-1},
};
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] SPL: ONENAND: Fix onenand_spl_load_image implementation.
From: Enric Balletbo i Serra eballe...@iseebcn.com
Tested with an IGEPv2 board seems that current onenand_spl_load_image
implementation
doesn't work. This patch fixes this function changing the read loop and reading
the
onenand blocks from page to page.
Tested with various IGEP based boards with a OneNAND from Numonyx.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
drivers/mtd/onenand/onenand_spl.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/onenand/onenand_spl.c
b/drivers/mtd/onenand/onenand_spl.c
index 50eaa71..4bec2c2 100644
--- a/drivers/mtd/onenand/onenand_spl.c
+++ b/drivers/mtd/onenand/onenand_spl.c
@@ -112,7 +112,7 @@ static int onenand_spl_read_page(uint32_t block, uint32_t
page, uint32_t *buf,
void onenand_spl_load_image(uint32_t offs, uint32_t size, void *dst)
{
uint32_t *addr = (uint32_t *)dst;
- uint32_t total_pages;
+ uint32_t to_page;
uint32_t block;
uint32_t page, rpage;
enum onenand_spl_pagesize pagesize;
@@ -125,22 +125,20 @@ void onenand_spl_load_image(uint32_t offs, uint32_t size,
void *dst)
* pulling further unwanted functions into the SPL.
*/
if (pagesize == 2048) {
- total_pages = DIV_ROUND_UP(size, 2048);
page = offs / 2048;
+ to_page = page + DIV_ROUND_UP(size, 2048);
} else {
- total_pages = DIV_ROUND_UP(size, 4096);
page = offs / 4096;
+ to_page = page + DIV_ROUND_UP(size, 4096);
}
- for (; page = total_pages; page++) {
+ for (; page = to_page; page++) {
block = page / ONENAND_PAGES_PER_BLOCK;
rpage = page (ONENAND_PAGES_PER_BLOCK - 1);
ret = onenand_spl_read_page(block, rpage, addr, pagesize);
- if (ret) {
- total_pages += ONENAND_PAGES_PER_BLOCK;
+ if (ret)
page += ONENAND_PAGES_PER_BLOCK - 1;
- } else {
+ else
addr += pagesize / 4;
- }
}
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] SPL: ONENAND: Support SPL to boot u-boot from OneNAND.
From: Enric Balletbo i Serra eballe...@iseebcn.com
This patch will allow use SPL to boot an u-boot from the OneNAND.
Tested with IGEPv2 board with a OneNAND from Numonyx.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/cpu/armv7/omap3/board.c |2 +-
common/spl/Makefile |1 +
common/spl/spl.c |5 +
common/spl/spl_onenand.c | 45 ++
4 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 common/spl/spl_onenand.c
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 89c587e..63063c8 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -110,7 +110,7 @@ int board_mmc_init(bd_t *bis)
void spl_board_init(void)
{
-#ifdef CONFIG_SPL_NAND_SUPPORT
+#if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT)
gpmc_init();
#endif
#ifdef CONFIG_SPL_I2C_SUPPORT
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 5698a23..da2afc1 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -18,6 +18,7 @@ COBJS-$(CONFIG_SPL_FRAMEWORK) += spl.o
COBJS-$(CONFIG_SPL_NOR_SUPPORT) += spl_nor.o
COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
COBJS-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
+COBJS-$(CONFIG_SPL_ONENAND_SUPPORT) += spl_onenand.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index ff9ba7b..c584247 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -197,6 +197,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_nand_load_image();
break;
#endif
+#ifdef CONFIG_SPL_ONENAND_SUPPORT
+ case BOOT_DEVICE_ONE_NAND:
+ spl_onenand_load_image();
+ break;
+#endif
#ifdef CONFIG_SPL_NOR_SUPPORT
case BOOT_DEVICE_NOR:
spl_nor_load_image();
diff --git a/common/spl/spl_onenand.c b/common/spl/spl_onenand.c
new file mode 100644
index 000..247f97b
--- /dev/null
+++ b/common/spl/spl_onenand.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (C) 2011
+ * Corscience GmbH Co. KG - Simon Schwarz schw...@corscience.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 config.h
+#include spl.h
+#include asm/io.h
+#include onenand_uboot.h
+
+void spl_onenand_load_image(void)
+{
+ struct image_header *header;
+ int *src __attribute__((unused));
+ int *dst __attribute__((unused));
+
+ debug(spl: onenand\n);
+
+ /*use CONFIG_SYS_TEXT_BASE as temporary storage area */
+ header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+ /* Load u-boot */
+ onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,
+ CONFIG_SYS_ONENAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,
+ spl_image.size, (void *)spl_image.load_addr);
+}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver forall T20 boards
Hi Tom,
Am Montag, 4. Februar 2013, 16:48:55 schrieb Tom Warren:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
Signed-off-by: Tom Warren twar...@nvidia.com
---
arch/arm/include/asm/arch-tegra/mmc.h |2 +-
arch/arm/include/asm/arch-tegra/tegra_mmc.h | 12 +-
board/avionic-design/common/tamonten.c|4 +-
board/compal/paz00/paz00.c| 14 +-
board/compulab/trimslice/trimslice.c | 10 +-
board/nvidia/harmony/harmony.c| 12 +-
board/nvidia/seaboard/seaboard.c | 14 +-
board/nvidia/whistler/whistler.c |4 +-
board/toradex/colibri_t20_iris/colibri_t20_iris.c |2 +-
drivers/mmc/tegra_mmc.c | 186
++--- include/fdtdec.h |
1 +
lib/fdtdec.c |1 +
12 files changed, 165 insertions(+), 97 deletions(-)
[...]
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
This looks wrong because the sd is on sdmmc0
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
and the emmc on sdmmc3. The DTS is correct.
Not your fault as it seems to be wrong in the original code already.
I guess it didn't made large difference but may in the future. I wonder how to
test this though.
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Add bmp_layout module for accessing BMP header data
Dear Nikita, In message 5110ac16.9000...@compulab.co.il you wrote: That's true, but when md traps you simply restart the board and everything's fine. If displaying a splash screen traps- you're stuck. In such a case you have forgotten to test your settings before activation these as default, i. e. you have committed a sin that carries with it its own punishment ;-) There's a difference between a bicycle with no training wheels and one that falls apart when you turn it the wrong way. It's not the bicyle falling apart, it's the rider falling down (with the risk of getting hurt) - and yes, exactly this happens in real life when you disobey basic caution. The same will happen for other stupid settings, too - like setting a bootdelay of 0 with a non-working bootcmd; or incorrect update commands that blow away U-Boot, or ... This is a boot loader, and there are no seatbelts or airbags; nothing prevents you to shoot yourself into the foot. 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 Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Add bmp_layout module for accessing BMP header data
Dear Igor Grinberg, In message 5110bdb2.8040...@compulab.co.il you wrote: Yes, struct bmp_header is a packed array with non-natural order of entries; see also section Bitmap file header at [1]; we may consider this a really stupid thing to do, but we have to live with this fact. It was not that stupid in times of DOS and Win 3.1 when int was 16 bits long (and DRAM was 64K or even less)... It was as stupid then, too. At that time, a large number of systems with similar alignment requirements existed, and experience with these existed, too. Do you remember the The Ten Commandments for C Programmers? If not, look them up and check how old these are. Note especially the ``All the world's a VAX'' part - this is exactly what we see here in operation. The design of the BMP header is just BRAINDEAD. Indeed, this should be documented. And eventually the bmp command should print a warning message if it sees other alignment. Agreed on this also, but again what about the board brick case? There is a ton of ways to brick a board. Why should we add protection for one special case while we agree to leave the 50 other ways onfixed? Should we add the check for alignment and if it does not properly aligned deny further bmp header processing along with printing a warning? Why should we? Who tells that this is not perfectly legal on the running system? Let me repeat it: U-Boot is a boot loader. It is not intended for meddling by avarage Johnny Loser, but for system programmers who know what they are doing. And anyone doing such things is well adviced to _test_ his settings on the command line before storing these for automatic use. As I mentioned before, omitting such tests is a sin that carries with it its own punishment. 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 Pig: An animal (Porcus omnivorous) closely allied to the human race by the splendor and vivacity of its appetite, which, however, is in- ferior in scope, for it balks at pig.- Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Tegra: MMC: Add DT support for MMC to T20 boards
On Mon, Feb 04, 2013 at 04:48:53PM -0700, Tom Warren wrote: This patchset adds device-tree support to the Tegra MMC driver. All device config is done via properties in the DT files instead of hard-coded config options/function arguments. I've tested this on my Seaboard and everything works fine, including card detect. For the other T20 boards, I've used the Linux kernel DTS files for the sdhci nodes where there wasn't one already, or expanded the info that was already there. Everything builds fine, but I haven't tested anything but Seaboard. Tom Warren (2): Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files Tegra: MMC: Add DT support to MMC driver for all T20 boards I've tested on TEC only, but since Medcom-Wide and Plutux are also based on Tamonten they should be good as well, so: Tested-by: Thierry Reding thierry.red...@avionic-design.de pgpuZSLmbIfA7.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/9 v8] Add TMU support for Exynos5250 based SMDK5250
This patch series adds support for TMU driver using device tree for Exynos5250 based SMDK5250 board. COMPILE=(MAKEALL -a arm) No errors or warnings related to dtt or tmu. TEST=Tested over smdk5250. Changes since v7: - Patch-1: None. - Patch-2: None. - Patch-3: None. - Patch-4: None. - Patch-5: None. - Patch-6: Few changes to avoid compilation errors and warnings. - Patch-7: None. - Patch-8: None. - Patch-9: Added 'Acked-by'. Akshay Saraswat (9): EXYNOS5: TMU: Add driver for Thermal Management Unit EXYNOS5: Implement board_poweroff for Thermal Management Unit EXYNOS5: FDT: Add TMU device node values EXYNOS5: TMU: Add TMU init and status check EXYNOS5: Config: Enable support for Exynos TMU driver TMU: Add TMU support in dtt command EXYNOS5: Config: Enable dtt command for TMU EXYNOS5: TMU: Add hardware tripping EXYNOS5: FDT: Add a H/W-trip member to TMU node arch/arm/cpu/armv7/exynos/power.c | 25 ++ arch/arm/dts/exynos5250.dtsi |5 + arch/arm/include/asm/arch-exynos/exynos-tmu.h | 58 + arch/arm/include/asm/arch-exynos/power.h |6 + board/samsung/dts/exynos5250-smdk5250.dts | 13 + board/samsung/smdk5250/smdk5250.c | 35 +++ common/cmd_dtt.c | 63 +++-- doc/device-tree-bindings/exynos/tmu.txt | 49 drivers/power/Makefile|1 + drivers/power/exynos-tmu.c| 317 + include/configs/exynos5250-dt.h |5 + include/dtt.h |2 +- include/fdtdec.h |1 + include/tmu.h | 46 lib/fdtdec.c |1 + 15 files changed, 600 insertions(+), 27 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/exynos-tmu.h create mode 100644 doc/device-tree-bindings/exynos/tmu.txt create mode 100644 drivers/power/exynos-tmu.c create mode 100644 include/tmu.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9 v8] EXYNOS5: TMU: Add driver for Thermal Management Unit
Adding Exynos Thermal Management Unit driver to monitor SOC
temperature and take actions corresponding to states of TMU.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v7:
- None.
arch/arm/include/asm/arch-exynos/exynos-tmu.h | 58 +
drivers/power/Makefile|1 +
drivers/power/exynos-tmu.c| 302 +
include/tmu.h | 46
4 files changed, 407 insertions(+)
create mode 100644 arch/arm/include/asm/arch-exynos/exynos-tmu.h
create mode 100644 drivers/power/exynos-tmu.c
create mode 100644 include/tmu.h
diff --git a/arch/arm/include/asm/arch-exynos/exynos-tmu.h
b/arch/arm/include/asm/arch-exynos/exynos-tmu.h
new file mode 100644
index 000..c79a520
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/exynos-tmu.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Akshay Saraswat aksha...@samsung.com
+ *
+ * EXYNOS - Thermal Management Unit
+ *
+ * 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 version 2 as
+ * published by the Free Software Foundation.
+ * 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 __ASM_ARCH_TMU_H
+#define __ASM_ARCH_TMU_H
+
+struct tmu_reg {
+ unsigned triminfo;
+ unsigned rsvd1;
+ unsigned rsvd2;
+ unsigned rsvd3;
+ unsigned rsvd4;
+ unsigned triminfo_control;
+ unsigned rsvd5;
+ unsigned rsvd6;
+ unsigned tmu_control;
+ unsigned rsvd7;
+ unsigned tmu_status;
+ unsigned sampling_internal;
+ unsigned counter_value0;
+ unsigned counter_value1;
+ unsigned rsvd8;
+ unsigned rsvd9;
+ unsigned current_temp;
+ unsigned rsvd10;
+ unsigned rsvd11;
+ unsigned rsvd12;
+ unsigned threshold_temp_rise;
+ unsigned threshold_temp_fall;
+ unsigned rsvd13;
+ unsigned rsvd14;
+ unsigned past_temp3_0;
+ unsigned past_temp7_4;
+ unsigned past_temp11_8;
+ unsigned past_temp15_12;
+ unsigned inten;
+ unsigned intstat;
+ unsigned intclear;
+ unsigned rsvd15;
+ unsigned emul_con;
+};
+#endif /* __ASM_ARCH_THERMAL_H */
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 8c71901..1dac16a 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -25,6 +25,7 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libpower.o
+COBJS-$(CONFIG_EXYNOS_TMU) += exynos-tmu.o
COBJS-$(CONFIG_FTPMU010_POWER) += ftpmu010.o
COBJS-$(CONFIG_TPS6586X_POWER) += tps6586x.o
COBJS-$(CONFIG_TWL4030_POWER) += twl4030.o
diff --git a/drivers/power/exynos-tmu.c b/drivers/power/exynos-tmu.c
new file mode 100644
index 000..83a2572
--- /dev/null
+++ b/drivers/power/exynos-tmu.c
@@ -0,0 +1,302 @@
+/*
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Akshay Saraswat aksha...@samsung.com
+ *
+ * EXYNOS - Thermal Management Unit
+ *
+ * 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 version 2 as
+ * published by the Free Software Foundation.
+ * 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 errno.h
+#include fdtdec.h
+#include tmu.h
+#include asm/arch/exynos-tmu.h
+
+#define TRIMINFO_RELOAD1
+#define CORE_EN1
+
+#define INTEN_RISE01
+#define INTEN_RISE1(1 4)
+#define INTEN_RISE2(1 8)
+#define INTEN_FALL0(1 16)
+#define INTEN_FALL1(1 20)
+#define INTEN_FALL2(1 24)
+
+#define TRIM_INFO_MASK 0xff
+
+#define INTCLEAR_RISE0 1
+#define INTCLEAR_RISE1 (1 4)
+#define INTCLEAR_RISE2 (1 8)
+#define INTCLEAR_FALL0 (1 16)
+#define INTCLEAR_FALL1 (1 20)
+#define INTCLEAR_FALL2 (1 24)
+#define INTCLEARALL(INTCLEAR_RISE0 | INTCLEAR_RISE1 | \
+INTCLEAR_RISE2 | INTCLEAR_FALL0 | \
+INTCLEAR_FALL1 | INTCLEAR_FALL2)
+
+/* Tmeperature threshold values for various thermal events */
+struct temperature_params {
+ /* minimum value in temperature code range */
+ unsigned int min_val;
+ /* maximum value in
[U-Boot] [PATCH 2/9 v8] EXYNOS5: Implement board_poweroff for Thermal Management Unit
Adding API in power for system shutdown when tripping value is reached
in Exynos Thermal Management Unit.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v7:
- None.
arch/arm/cpu/armv7/exynos/power.c| 15 +++
arch/arm/include/asm/arch-exynos/power.h |1 +
2 files changed, 16 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index d4bce6d..73f764e 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -95,3 +95,18 @@ void set_dp_phy_ctrl(unsigned int enable)
if (cpu_is_exynos5())
exynos5_dp_phy_control(enable);
}
+
+/*
+ * This function never returns.
+ * When called this function makes system hang and PAD driving value high
+ * which in turn makes system power down.
+ */
+void board_poweroff(void)
+{
+ struct exynos5_power *power =
+ (struct exynos5_power *)samsung_get_base_power();
+
+ clrbits_le32(power-ps_hold_control, POWER_PS_HOLD_CONTROL_DATA_HIGH);
+
+ hang();
+}
diff --git a/arch/arm/include/asm/arch-exynos/power.h
b/arch/arm/include/asm/arch-exynos/power.h
index d2fdb59..7463036 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -863,5 +863,6 @@ void set_usbhost_phy_ctrl(unsigned int enable);
void set_dp_phy_ctrl(unsigned int enable);
#define EXYNOS_DP_PHY_ENABLE (1 0)
+#define POWER_PS_HOLD_CONTROL_DATA_HIGH (1 8)
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9 v8] EXYNOS5: FDT: Add TMU device node values
Fdt entry for Exynos TMU driver specific pre-defined values used for
calibration of current temperature and defining threshold values.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v7:
- None.
arch/arm/dts/exynos5250.dtsi |5
board/samsung/dts/exynos5250-smdk5250.dts | 12
doc/device-tree-bindings/exynos/tmu.txt | 46 +
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
5 files changed, 65 insertions(+)
create mode 100644 doc/device-tree-bindings/exynos/tmu.txt
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index ed8c8dd..61d35a8 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -151,4 +151,9 @@
};
};
+ tmu@1006 {
+ compatible = samsung,exynos-tmu;
+ reg = 0x1006 0x1;
+ };
+
};
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index cbfab6f..00dac40 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -66,4 +66,16 @@
compatible = maxim,max77686_pmic;
};
};
+
+ tmu@1006 {
+ samsung,min-temp= 25;
+ samsung,max-temp= 125;
+ samsung,start-warning = 95;
+ samsung,start-tripping = 105;
+ samsung,efuse-min-value = 40;
+ samsung,efuse-value = 55;
+ samsung,efuse-max-value = 100;
+ samsung,slope = 274761730;
+ samsung,dc-value= 25;
+ };
};
diff --git a/doc/device-tree-bindings/exynos/tmu.txt
b/doc/device-tree-bindings/exynos/tmu.txt
new file mode 100644
index 000..779b01c
--- /dev/null
+++ b/doc/device-tree-bindings/exynos/tmu.txt
@@ -0,0 +1,46 @@
+Exynos Thermal management Unit
+
+The device node for TMU that is a part of Exynos5250
+SOC is as described in the document Open Firmware Recommended
+Practice : Universal Serial Bus with the following modifications
+and additions:
+
+Required properties:
+
+ - compatible : Should be samsung,exynos-tmu for TMU
+ - samsung,min-temp : Minimum temperature value (25 degree celsius)
+ - Current temperature of SoC should be more than this value.
+ - samsung,max-temp : Maximum temperature value (125 degree celsius)
+ - Current temperature of SoC should be less than this value.
+ - samsung,start-warning : Temperature at which TMU starts giving warning
(degree celsius)
+ - samsung,start-tripping : Temperature at which system will trip and shutdown
(degree celsius)
+ - samsung,efuse-min-value : SOC efuse min value (Constant 40)
+ - efuse-value should be more than this value.
+ - samsung,efuse-value : SOC actual efuse value (Literal value)
+ - This is the data trimming info.
+ - This value is used to calculate measuring error.
+ - samsung,efuse-max-value : SoC max efuse value (Constant 100)
+ - efuse-value should be less than this value.
+ - samsung,slope : Default value 274761730 (Constant 0x1060_8802).
+ - This is the default value for TMU_CONTROL register.
+ - It sets the gain of amplifier to the positive-tc generator block.
+ - It selects thermal tripping mode and enables thermal tripping.
+ - samsung,dc-value : Measured data calibration value (Constant 25)
+ - Used for tempearture calculation.
+ - This is 25 because temperature measured is always above 25 degrees.
+
+
+Example:
+
+tmu@1006 {
+ compatible = samsung,exynos-tmu
+ samsung,min-temp = 25;
+ samsung,max-temp = 125;
+ samsung,start-warning = 95;
+ samsung,start-tripping = 105;
+ samsung,efuse-min-value = 40;
+ samsung,efuse-value = 55;
+ samsung,efuse-max-value = 100;
+ samsung,slope = 274761730;
+ samsung,dc-value = 25;
+};
diff --git a/include/fdtdec.h b/include/fdtdec.h
index f77d195..058fb51 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -79,6 +79,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
COMPAT_SAMSUNG_EXYNOS_USB_PHY, /* Exynos phy controller for usb2.0 */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
+ COMPAT_SAMSUNG_EXYNOS_TMU, /* Exynos TMU */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 16921e1..4613fcd 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -54,6 +54,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS_EHCI, samsung,exynos-ehci),
COMPAT(SAMSUNG_EXYNOS_USB_PHY, samsung,exynos-usb-phy),
COMPAT(MAXIM_MAX77686_PMIC, maxim,max77686_pmic),
+ COMPAT(SAMSUNG_EXYNOS_TMU, samsung,exynos-tmu),
};
const char *fdtdec_get_compatible(enum
[U-Boot] [PATCH 4/9 v8] EXYNOS5: TMU: Add TMU init and status check
This adds call to tmu_init() and TMU boot time analysis
for the SoC temperature threshold breach.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v7:
- None.
board/samsung/smdk5250/smdk5250.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 7a5f132..7b9a8c5 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -35,9 +35,35 @@
#include asm/arch/sromc.h
#include asm/arch/dp_info.h
#include power/pmic.h
+#include tmu.h
DECLARE_GLOBAL_DATA_PTR;
+#if defined CONFIG_EXYNOS_TMU
+/*
+ * Boot Time Thermal Analysis for SoC temperature threshold breach
+ */
+void boot_temp_check(void)
+{
+ int temp;
+
+ switch (tmu_monitor(temp)) {
+ case TMU_STATUS_TRIPPED:
+ puts(EXYNOS_TMU: TRIPPING! Device power going down ...\n);
+ board_poweroff();
+ break;
+ case TMU_STATUS_WARNING:
+ puts(EXYNOS_TMU: WARNING! Temperature very high\n);
+ break;
+ case TMU_STATUS_NORMAL:
+ break;
+ case TMU_STATUS_INIT:
+ default:
+ debug(Unknown TMU state\n);
+ }
+}
+#endif
+
#ifdef CONFIG_USB_EHCI_EXYNOS
int board_usb_vbus_init(void)
{
@@ -57,6 +83,15 @@ int board_usb_vbus_init(void)
int board_init(void)
{
gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
+
+#if defined CONFIG_EXYNOS_TMU
+ if (tmu_init(gd-fdt_blob)) {
+ debug(%s: Failed to init TMU\n, __func__);
+ return -1;
+ }
+ boot_temp_check();
+#endif
+
#ifdef CONFIG_EXYNOS_SPI
spi_init();
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Add bmp_layout module for accessing BMP header data
On 02/05/13 11:57, Wolfgang Denk wrote: Dear Igor Grinberg, In message 5110bdb2.8040...@compulab.co.il you wrote: Yes, struct bmp_header is a packed array with non-natural order of entries; see also section Bitmap file header at [1]; we may consider this a really stupid thing to do, but we have to live with this fact. It was not that stupid in times of DOS and Win 3.1 when int was 16 bits long (and DRAM was 64K or even less)... It was as stupid then, too. At that time, a large number of systems with similar alignment requirements existed, and experience with these existed, too. Do you remember the The Ten Commandments for C Programmers? If not, look them up and check how old these are. Note especially the ``All the world's a VAX'' part - this is exactly what we see here in operation. Yep. Agreed on this. Although, I don't know, if anyone of us would tell the same 20+ years ago... It is now we can... The design of the BMP header is just BRAINDEAD. That is for sure. Indeed, this should be documented. And eventually the bmp command should print a warning message if it sees other alignment. Agreed on this also, but again what about the board brick case? There is a ton of ways to brick a board. Why should we add protection for one special case while we agree to leave the 50 other ways onfixed? Because, I think this one is a bit different because of the bmp header and also is of very high demand. Should we add the check for alignment and if it does not properly aligned deny further bmp header processing along with printing a warning? Why should we? Who tells that this is not perfectly legal on the running system? It might be perfectly legal, but we also consider a tons of work explaining why and how this should be done (needless to mention the amount of bricked boards). Instead of simplifying the case, and I think this is a special case, at least because of the high demand and user (who is not a programmer) selectable address, you want us to teach the whole world about the bmp header alignment issues? Let me repeat it: U-Boot is a boot loader. It is not intended for meddling by avarage Johnny Loser, but for system programmers who know what they are doing. And anyone doing such things is well adviced to _test_ his settings on the command line before storing these for automatic use. As I mentioned before, omitting such tests is a sin that carries with it its own punishment. What are you trying to say? Is it that the environment variables change and in particular the splash screen installation _must_ be done by a programmer? Hmm.. that does not sound good... -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9 v8] EXYNOS5: Config: Enable support for Exynos TMU driver
Enables TMU driver support for exynos5250 Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes since v7: - None. include/configs/exynos5250-dt.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index cabd2f2..53ca41f 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -117,6 +117,9 @@ #define CONFIG_BOOTDELAY 3 #define CONFIG_ZERO_BOOTDELAY_CHECK +/* Thermal Management Unit */ +#define CONFIG_EXYNOS_TMU + /* USB */ #define CONFIG_CMD_USB #define CONFIG_USB_EHCI -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9 v8] TMU: Add TMU support in dtt command
Add generic TMU support alongwith i2c sensors in dtt command
to enable temperature reading in cases where TMU is present
instead of i2c sensors.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v7:
- Made sensor_initialized static again.
- Changed return type to int in dtt_init declaration.
common/cmd_dtt.c | 63 --
include/dtt.h|2 +-
2 files changed, 38 insertions(+), 27 deletions(-)
diff --git a/common/cmd_dtt.c b/common/cmd_dtt.c
index cd94423..799e1c7 100644
--- a/common/cmd_dtt.c
+++ b/common/cmd_dtt.c
@@ -27,52 +27,52 @@
#include dtt.h
#include i2c.h
+#include tmu.h
+#if defined CONFIG_DTT_SENSORS
static unsigned long sensor_initialized;
+#endif
-static void _initialize_dtt(void)
+int dtt_tmu(void)
{
- int i;
- unsigned char sensors[] = CONFIG_DTT_SENSORS;
+#if defined CONFIG_TMU_CMD_DTT
+ int cur_temp;
- for (i = 0; i sizeof(sensors); i++) {
- if ((sensor_initialized (1 i)) == 0) {
- if (dtt_init_one(sensors[i]) != 0) {
- printf(DTT%d: Failed init!\n, i);
- continue;
- }
- sensor_initialized |= (1 i);
- }
+ /* Sense and return latest thermal info */
+ if (tmu_monitor(cur_temp) == TMU_STATUS_INIT) {
+ puts(TMU is in unknown state, temperature is invalid\n);
+ return -1;
}
-}
-
-void dtt_init(void)
-{
- int old_bus;
-
- /* switch to correct I2C bus */
- old_bus = I2C_GET_BUS();
- I2C_SET_BUS(CONFIG_SYS_DTT_BUS_NUM);
-
- _initialize_dtt();
+ printf(Current temperature: %u degrees Celsius\n, cur_temp);
+#endif
- /* switch back to original I2C bus */
- I2C_SET_BUS(old_bus);
+ return 0;
}
-int do_dtt (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
+int dtt_init(void)
{
+#if defined CONFIG_DTT_SENSORS
int i;
unsigned char sensors[] = CONFIG_DTT_SENSORS;
int old_bus;
/* Force a compilation error, if there are more then 32 sensors */
BUILD_BUG_ON(sizeof(sensors) 32);
+
/* switch to correct I2C bus */
old_bus = I2C_GET_BUS();
I2C_SET_BUS(CONFIG_SYS_DTT_BUS_NUM);
- _initialize_dtt();
+ /* Initialize dtt sensors */
+ for (i = 0; i sizeof(sensors); i++) {
+ if ((sensor_initialized (1 i)) == 0) {
+ if (dtt_init_one(sensors[i]) != 0) {
+ printf(DTT%d: Failed init!\n, i);
+ continue;
+ }
+ sensor_initialized |= (1 i);
+ }
+ }
/*
* Loop through sensors, read
@@ -83,8 +83,19 @@ int do_dtt (cmd_tbl_t * cmdtp, int flag, int argc, char *
const argv[])
/* switch back to original I2C bus */
I2C_SET_BUS(old_bus);
+#endif
return 0;
+}
+
+int do_dtt(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
+{
+ int err = 0;
+
+ err |= dtt_init();
+ err |= dtt_tmu();
+
+ return err;
} /* do_dtt() */
/***/
diff --git a/include/dtt.h b/include/dtt.h
index 6d5534d..94fbce3 100644
--- a/include/dtt.h
+++ b/include/dtt.h
@@ -52,7 +52,7 @@
#endif
#endif /* CONFIG_DTT_ADM1021 */
-extern void dtt_init(void);
+extern int dtt_init(void);
extern int dtt_init_one(int);
extern int dtt_read(int sensor, int reg);
extern int dtt_write(int sensor, int reg, int val);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9 v8] EXYNOS5: Config: Enable dtt command for TMU
This enables the dtt command to read the current SOC temperature with the help of TMU Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes since v7: - None. include/configs/exynos5250-dt.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 53ca41f..8a8e9fe 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -119,6 +119,8 @@ /* Thermal Management Unit */ #define CONFIG_EXYNOS_TMU +#define CONFIG_CMD_DTT +#define CONFIG_TMU_CMD_DTT /* USB */ #define CONFIG_CMD_USB -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9 v8] EXYNOS5: TMU: Add hardware tripping
This adds hardware tripping at 110 degrees celsius which must enable
forced system shutdown in case TMU fails to power off.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v7:
- None.
arch/arm/cpu/armv7/exynos/power.c| 10 ++
arch/arm/include/asm/arch-exynos/power.h |5 +
drivers/power/exynos-tmu.c | 25 -
3 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 73f764e..234c9f4 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -96,6 +96,16 @@ void set_dp_phy_ctrl(unsigned int enable)
exynos5_dp_phy_control(enable);
}
+/* Enables hardware tripping to power off the system when TMU fails */
+void power_enable_hw_thermal_trip(void)
+{
+ struct exynos5_power *power =
+ (struct exynos5_power *)samsung_get_base_power();
+
+ /* PS_HOLD_CONTROL register ENABLE_HW_TRIP bit*/
+ setbits_le32(power-ps_hold_control, POWER_ENABLE_HW_TRIP);
+}
+
/*
* This function never returns.
* When called this function makes system hang and PAD driving value high
diff --git a/arch/arm/include/asm/arch-exynos/power.h
b/arch/arm/include/asm/arch-exynos/power.h
index 7463036..034774f 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -857,6 +857,9 @@ void set_mipi_phy_ctrl(unsigned int dev_index, unsigned int
enable);
void set_usbhost_phy_ctrl(unsigned int enable);
+/* Enables hardware tripping to power off the system when TMU fails */
+void power_enable_hw_thermal_trip(void);
+
#define POWER_USB_HOST_PHY_CTRL_EN (1 0)
#define POWER_USB_HOST_PHY_CTRL_DISABLE(0 0)
@@ -864,5 +867,7 @@ void set_dp_phy_ctrl(unsigned int enable);
#define EXYNOS_DP_PHY_ENABLE (1 0)
#define POWER_PS_HOLD_CONTROL_DATA_HIGH (1 8)
+#define POWER_ENABLE_HW_TRIP (1UL 31)
+
#endif
diff --git a/drivers/power/exynos-tmu.c b/drivers/power/exynos-tmu.c
index 83a2572..9d28614 100644
--- a/drivers/power/exynos-tmu.c
+++ b/drivers/power/exynos-tmu.c
@@ -22,9 +22,11 @@
#include fdtdec.h
#include tmu.h
#include asm/arch/exynos-tmu.h
+#include asm/arch/power.h
#define TRIMINFO_RELOAD1
#define CORE_EN1
+#define THERM_TRIP_EN (1 12)
#define INTEN_RISE01
#define INTEN_RISE1(1 4)
@@ -55,6 +57,8 @@ struct temperature_params {
unsigned int start_warning;
/* temperature threshold CPU tripping */
unsigned int start_tripping;
+ /* temperature threshold for HW tripping */
+ unsigned int hardware_tripping;
};
/* Pre-defined values and thresholds for calibration of current temperature */
@@ -195,6 +199,9 @@ int get_tmu_fdt_values(struct tmu_info *info, const void
*blob)
info-data.ts.start_tripping = fdtdec_get_int(blob,
node, samsung,start-tripping, -1);
error |= info-data.ts.start_tripping;
+ info-data.ts.hardware_tripping = fdtdec_get_int(blob,
+ node, samsung,hw-tripping, -1);
+ error |= info-data.ts.hardware_tripping;
info-data.efuse_min_value = fdtdec_get_int(blob,
node, samsung,efuse-min-value, -1);
error |= info-data.efuse_min_value;
@@ -228,7 +235,7 @@ int get_tmu_fdt_values(struct tmu_info *info, const void
*blob)
void tmu_setup_parameters(struct tmu_info *info)
{
unsigned int te_code, con;
- unsigned int warning_code, trip_code;
+ unsigned int warning_code, trip_code, hwtrip_code;
unsigned int cooling_temp;
unsigned int rising_value;
struct tmu_data *data = info-data;
@@ -252,9 +259,14 @@ void tmu_setup_parameters(struct tmu_info *info)
+ info-te1 - info-dc_value;
trip_code = data-ts.start_tripping
+ info-te1 - info-dc_value;
+ hwtrip_code = data-ts.hardware_tripping
+ + info-te1 - info-dc_value;
+
cooling_temp = 0;
- rising_value = ((warning_code 8) | (trip_code 16));
+ rising_value = ((warning_code 8) |
+ (trip_code 16) |
+ (hwtrip_code 24));
/* Set interrupt level */
writel(rising_value, reg-threshold_temp_rise);
@@ -274,12 +286,15 @@ void tmu_setup_parameters(struct tmu_info *info)
/* TMU core enable */
con = readl(reg-tmu_control);
- con |= CORE_EN;
+ con |= THERM_TRIP_EN | CORE_EN;
writel(con, reg-tmu_control);
- /* LEV0 LEV1 LEV2 interrupt enable */
- writel(INTEN_RISE0 | INTEN_RISE1 | INTEN_RISE2, reg-inten);
+ /* Enable HW thermal trip */
+ power_enable_hw_thermal_trip();
+
+
[U-Boot] [PATCH 9/9 v8] EXYNOS5: FDT: Add a H/W-trip member to TMU node
This adds a member to TMU FDT node for providing hardware
tripping temperature threshold.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v7:
- Added Acked-by.
board/samsung/dts/exynos5250-smdk5250.dts |1 +
doc/device-tree-bindings/exynos/tmu.txt |5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index 00dac40..1c2d52d 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -72,6 +72,7 @@
samsung,max-temp= 125;
samsung,start-warning = 95;
samsung,start-tripping = 105;
+ samsung,hw-tripping = 110;
samsung,efuse-min-value = 40;
samsung,efuse-value = 55;
samsung,efuse-max-value = 100;
diff --git a/doc/device-tree-bindings/exynos/tmu.txt
b/doc/device-tree-bindings/exynos/tmu.txt
index 779b01c..dce06d1 100644
--- a/doc/device-tree-bindings/exynos/tmu.txt
+++ b/doc/device-tree-bindings/exynos/tmu.txt
@@ -13,7 +13,9 @@ Required properties:
- samsung,max-temp : Maximum temperature value (125 degree celsius)
- Current temperature of SoC should be less than this value.
- samsung,start-warning : Temperature at which TMU starts giving warning
(degree celsius)
- - samsung,start-tripping : Temperature at which system will trip and shutdown
(degree celsius)
+ - samsung,start-tripping : Temperature at which TMU shuts down the system
(degree celsius)
+ - samsung,hw-tripping : Temperature at which hardware tripping should happen
+ in case TMU fails to power off (degree celsius)
- samsung,efuse-min-value : SOC efuse min value (Constant 40)
- efuse-value should be more than this value.
- samsung,efuse-value : SOC actual efuse value (Literal value)
@@ -38,6 +40,7 @@ tmu@1006 {
samsung,max-temp = 125;
samsung,start-warning = 95;
samsung,start-tripping = 105;
+ samsung,hw-tripping = 110;
samsung,efuse-min-value = 40;
samsung,efuse-value = 55;
samsung,efuse-max-value = 100;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/5] ARM: OMAP5: clocks: Add OPP settings required for OMAP543X ES2.0 soc
Hi Nishanth,
On Tuesday 05 February 2013 01:46 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
--please be clear that these are for OPP_NOM. FYI, latest documentation
is 0.5 rev which was released in Jan, considering this patch was send in
Feb, might be good to cross verify any updates.
Thanks for the info, i was not aware of 0.5 version. I will recheck
if something is different here.
in addition, I suspect TRM was referred for certain DPLLs as well?
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |4 +
arch/arm/cpu/armv7/omap4/hw_data.c | 142 +++---
arch/arm/cpu/armv7/omap5/hw_data.c | 242 +++-
arch/arm/include/asm/arch-omap5/clocks.h |4 +
arch/arm/include/asm/omap_common.h |6 +-
5 files changed, 241 insertions(+), 157 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 88e5336..164253c 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -103,10 +103,14 @@ void setup_post_dividers(u32 const base, const struct
dpll_params *params)
writel(params-m6_h13, dpll_regs-cm_div_m6_h13_dpll);
if (params-m7_h14 = 0)
writel(params-m7_h14, dpll_regs-cm_div_m7_h14_dpll);
+ if (params-h21 = 0)
+ writel(params-h21, dpll_regs-cm_div_h21_dpll);
if (params-h22 = 0)
writel(params-h22, dpll_regs-cm_div_h22_dpll);
if (params-h23 = 0)
writel(params-h23, dpll_regs-cm_div_h23_dpll);
+ if (params-h24 = 0)
+ writel(params-h24, dpll_regs-cm_div_h24_dpll);
}
static inline void do_bypass_dpll(u32 const base)
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 892d016..b01bf5d 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -51,113 +51,113 @@ struct omap_sys_ctrl_regs const **ctrl =
/* dpll locked at 1400 MHz MPU clk at 700 MHz(OPP100) - DCC OFF */
this: equivalent to OPP_SB?
static const struct dpll_params mpu_dpll_params_1400mhz[NUM_SYS_CLKS] = {
- {175, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
- {700, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
- {125, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
- {401, 10, 1, -1, -1, -1, -1, -1, -1, -1}, /* 19.2 MHz */
- {350, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
- {700, 26, 1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
- {638, 34, 1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
+ {175, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
+ {700, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
+ {125, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
+ {401, 10, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 19.2 MHz */
+ {350, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
+ {700, 26, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
+ {638, 34, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
};
/* dpll locked at 1584 MHz - MPU clk at 792 MHz(OPP Turbo 4430) */
Do we even support this? there is no OPP Turbo for OMAP5, we have
OPP_HIGH which needs DCC and AVS etc..
static const struct dpll_params mpu_dpll_params_1600mhz[NUM_SYS_CLKS] = {
- {200, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
- {800, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
- {619, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 16.8 MHz */
- {125, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
- {400, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
- {800, 26, 1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
- {125, 5, 1, -1, -1, -1, -1, -1, -1, -1} /* 38.4 MHz */
+ {200, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
+ {800, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
+ {619, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 16.8 MHz */
+ {125, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
+ {400, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
+ {800, 26, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
+ {125, 5, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1} /* 38.4 MHz */
};
/* dpll locked at 1200 MHz - MPU clk at 600 MHz */
Please correct this.
static const struct dpll_params mpu_dpll_params_1200mhz[NUM_SYS_CLKS] = {
- {50, 0, 1, -1, -1, -1, -1, -1, -1, -1}, /* 12 MHz
Re: [U-Boot] [PATCH V2 1/5] ARM: OMAP5: Add silicon id support for ES2.0 revision.
On Tuesday 05 February 2013 01:11 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include/asm/armv7.h |1 +
arch/arm/include/asm/omap_common.h |2 ++
4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index dfc0e44..0d8c95d 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -216,8 +216,17 @@ void init_omap_revision(void)
break;
}
break;
- default:
- *omap_si_rev = OMAP5430_SILICON_ID_INVALID;
+ case MIDR_CORTEX_A15_R2P2:
+ switch (readl(CONTROL_ID_CODE)) {
+ case OMAP5430_CONTROL_ID_CODE_ES2_0:
+ *omap_si_rev = OMAP5430_ES2_0;
+ break;
+ case OMAP5432_CONTROL_ID_CODE_ES2_0:
+ *omap_si_rev = OMAP5432_ES2_0;
+ break;
+ default:
+ *omap_si_rev = OMAP5430_SILICON_ID_INVALID;
+ }
A first few samples of both ES1.0 and ES2.0 (in the few 10s of samples) came
with wrong efuse
ID fused in, why would we want to make it a standard to check ARMsilicon
revision *and then* cross verify against control fuse verification, *and
then* give up saying we dont support it?
Looks like an over check for me - IMHO, we should drop the MIDR checks
entirely.
In the same context, for some boards in past even in the actual samples
the CONTROL ID code was reading the older revision. So in those
cases ARM revision will help to differentiate them.
But then it should have been in the opposite way, like reading the
CONTROL_CODE first and then reading the ARM revision if required in
those cases where is it broken. I will change this logic here.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Add bmp_layout module for accessing BMP header data
Dear Igor, In message 5110ef4f.3080...@compulab.co.il you wrote: Why should we? Who tells that this is not perfectly legal on the running system? It might be perfectly legal, but we also consider a tons of work explaining why and how this should be done (needless to mention the amount of bricked boards). Please understand that I will not really buy this bricked bord argument. This is an issue where system builders and users are involved. Apparently the system builders agree that performance is so important that they compile with optimizer options that do not tolerate unaligned accesses, thus introducing the problem. This is OK for systems where only educated users have access. If you open the U-Boot console interface to uneducated users, you are always running some risk that a stupid command will brick the board or at least make it no longer usable to that user. And as a user you should well be aware that bad things can happen, and that it is an excellent idea to actually test any new settings or operations before installing these. If users ignore even such basic rules, then the situation is f*cked up and cannot be helped - if it's not the spalsh screen, then these users will find other ways to run into trouble. Let me repeat it: U-Boot is a boot loader. It is not intended for meddling by avarage Johnny Loser, but for system programmers who know what they are doing. And anyone doing such things is well adviced to _test_ his settings on the command line before storing these for automatic use. As I mentioned before, omitting such tests is a sin that carries with it its own punishment. What are you trying to say? Is it that the environment variables change and in particular the splash screen installation _must_ be done by a programmer? I tried to be clear: people who work on such a level are supposed to know what they are doing. I find it interesting that a lot of arguments get raised here how important this issue is (is it? who has actually bricked a system this way?), and how that is a special case (here I disagree), but so far you all appear to ignore my argument of testing settings before putting these to use. I see little excuse for neglecting such really basic diligence. 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 How many seconds are there in a year? If I tell you there are 3.155 x 10^7, you won't even try to remember it. On the other hand, who could forget that, to within half a percent, pi seconds is a nanocentury. - Tom Duff, Bell Labs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] how to configure u-boot to tell me more about NAND flash?
a few basic questions about a board i don't have access to right this minute but did yesterday and will later today. it's an AM1808 experimenter kit lookalike except that it has (allegedly) had its NOR flash replaced with 2G of NAND flash, and i want to figure out what i can add to the current u-boot da850evm configuration to let me poke around and get all the info i can on that flash because there seems to be something strange about the current setup. first, when i let the board boot fully into linux, dmesg told me this: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit) that appears to tell me 512M of NAND flash, not 2G. i asked someone who was initially adamant that there was 2G but promised to check with the H/W folks to make absolutely sure. is there a possible reason why 2G would show up only as 512M in dmesg? (not really a u-boot question, just wondering.) next, the u-boot that was on the board didn't have the flinfo command so i created my own board based on the da850evm version that was currently being used, defined CONFIG_CMD_FLASH, rebuilt, reflashed, came up to u-boot so first check for flash (oh, u-boot version is 2010.12, so i can do some substantial upgrading later): rday nand info Device 0: nand0, sector size 128 KiB rday ok, that looks good, at least u-boot sees a NAND device. but now: rday flinfo rday should flinfo not tell me about my flash? do i need another config setting for this micron flash chip (whose identity is still a bit of a mystery)? finally, i ran mtdparts to get: rday mtdparts mtdids not defined, no default present rday so i guess i'll add mtdids in later when i get my hands on the board again. main question -- should flinfo not tell me about my flash? what might this configuration be missing? i should have access to the board in an hour or two. thanks. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] SPL: ONENAND: Support SPL to boot u-boot from OneNAND.
Hi,
On Tue, Feb 5, 2013 at 6:23 PM, Enric Balletbo i Serra
eballe...@gmail.com wrote:
From: Enric Balletbo i Serra eballe...@iseebcn.com
This patch will allow use SPL to boot an u-boot from the OneNAND.
Tested with IGEPv2 board with a OneNAND from Numonyx.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/cpu/armv7/omap3/board.c |2 +-
It's not related with OneNAND SPL patch, can you split it two patches?
common/spl/Makefile |1 +
common/spl/spl.c |5 +
common/spl/spl_onenand.c | 45
++
4 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 common/spl/spl_onenand.c
diff --git a/arch/arm/cpu/armv7/omap3/board.c
b/arch/arm/cpu/armv7/omap3/board.c
index 89c587e..63063c8 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -110,7 +110,7 @@ int board_mmc_init(bd_t *bis)
void spl_board_init(void)
{
-#ifdef CONFIG_SPL_NAND_SUPPORT
+#if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT)
gpmc_init();
#endif
#ifdef CONFIG_SPL_I2C_SUPPORT
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 5698a23..da2afc1 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -18,6 +18,7 @@ COBJS-$(CONFIG_SPL_FRAMEWORK) += spl.o
COBJS-$(CONFIG_SPL_NOR_SUPPORT) += spl_nor.o
COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
COBJS-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
+COBJS-$(CONFIG_SPL_ONENAND_SUPPORT) += spl_onenand.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index ff9ba7b..c584247 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -197,6 +197,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_nand_load_image();
break;
#endif
+#ifdef CONFIG_SPL_ONENAND_SUPPORT
+ case BOOT_DEVICE_ONE_NAND:
ONE_NAND? It should be ONENAND.
+ spl_onenand_load_image();
+ break;
+#endif
#ifdef CONFIG_SPL_NOR_SUPPORT
case BOOT_DEVICE_NOR:
spl_nor_load_image();
diff --git a/common/spl/spl_onenand.c b/common/spl/spl_onenand.c
new file mode 100644
index 000..247f97b
--- /dev/null
+++ b/common/spl/spl_onenand.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (C) 2011
+ * Corscience GmbH Co. KG - Simon Schwarz schw...@corscience.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 config.h
+#include spl.h
+#include asm/io.h
+#include onenand_uboot.h
+
+void spl_onenand_load_image(void)
+{
+ struct image_header *header;
+ int *src __attribute__((unused));
+ int *dst __attribute__((unused));
why these are needed? just remove these.
Thank you,
Kyungmin Park
+
+ debug(spl: onenand\n);
+
+ /*use CONFIG_SYS_TEXT_BASE as temporary storage area */
+ header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+ /* Load u-boot */
+ onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,
+ CONFIG_SYS_ONENAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,
+ spl_image.size, (void *)spl_image.load_addr);
+}
--
1.7.10.4
___
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] how to configure u-boot to tell me more about NAND flash?
Hi Robert, Le Tue, 05 Feb 2013 08:37:20 -0500, Robert P. J. Day rpj...@crashcourse.ca a écrit : main question -- should flinfo not tell me about my flash? what might this configuration be missing? i should have access to the board in an hour or two. thanks. you can read : doc/README.nand which contains quite a lot of details on how the nand flash are handled in u-boot and how to use the nand commands. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to configure u-boot to tell me more about NAND flash?
Quoting Eric Bénard e...@eukrea.com: Hi Robert, Le Tue, 05 Feb 2013 08:37:20 -0500, Robert P. J. Day rpj...@crashcourse.ca a écrit : main question -- should flinfo not tell me about my flash? what might this configuration be missing? i should have access to the board in an hour or two. thanks. you can read : doc/README.nand which contains quite a lot of details on how the nand flash are handled in u-boot and how to use the nand commands. *sigh* ... i totally forgot about the doc/ directory. thanks. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] SPL: ONENAND: Support SPL to boot u-boot from OneNAND.
Hi Kyungmin,
Thanks for revisit the patch.
2013/2/5 Kyungmin Park kmp...@infradead.org:
Hi,
On Tue, Feb 5, 2013 at 6:23 PM, Enric Balletbo i Serra
eballe...@gmail.com wrote:
From: Enric Balletbo i Serra eballe...@iseebcn.com
This patch will allow use SPL to boot an u-boot from the OneNAND.
Tested with IGEPv2 board with a OneNAND from Numonyx.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/cpu/armv7/omap3/board.c |2 +-
It's not related with OneNAND SPL patch, can you split it two patches?
Ok, I'll do in v2.
common/spl/Makefile |1 +
common/spl/spl.c |5 +
common/spl/spl_onenand.c | 45
++
4 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 common/spl/spl_onenand.c
diff --git a/arch/arm/cpu/armv7/omap3/board.c
b/arch/arm/cpu/armv7/omap3/board.c
index 89c587e..63063c8 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -110,7 +110,7 @@ int board_mmc_init(bd_t *bis)
void spl_board_init(void)
{
-#ifdef CONFIG_SPL_NAND_SUPPORT
+#if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT)
gpmc_init();
#endif
#ifdef CONFIG_SPL_I2C_SUPPORT
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 5698a23..da2afc1 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -18,6 +18,7 @@ COBJS-$(CONFIG_SPL_FRAMEWORK) += spl.o
COBJS-$(CONFIG_SPL_NOR_SUPPORT) += spl_nor.o
COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
COBJS-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
+COBJS-$(CONFIG_SPL_ONENAND_SUPPORT) += spl_onenand.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index ff9ba7b..c584247 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -197,6 +197,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_nand_load_image();
break;
#endif
+#ifdef CONFIG_SPL_ONENAND_SUPPORT
+ case BOOT_DEVICE_ONE_NAND:
ONE_NAND? It should be ONENAND.
Well, I used ONE_NAND because this define was already defined in
arch/arm/include/asm/arch-omap3/spl.h:29:#define BOOT_DEVICE_ONE_NAND 3
arch/arm/include/asm/arch-omap5/spl.h:30:#define BOOT_DEVICE_ONE_NAND4
arch/arm/include/asm/arch-omap4/spl.h:30:#define BOOT_DEVICE_ONE_NAND 4
arch/arm/include/asm/arch-mx35/spl.h:30:#define BOOT_DEVICE_ONE_NAND4
For me, also looks better use ONENAND, but then, I need to change all
these defines. What do you prefer ? Maintain the use of ONE_NAND or
change these defines ?
+ spl_onenand_load_image();
+ break;
+#endif
#ifdef CONFIG_SPL_NOR_SUPPORT
case BOOT_DEVICE_NOR:
spl_nor_load_image();
diff --git a/common/spl/spl_onenand.c b/common/spl/spl_onenand.c
new file mode 100644
index 000..247f97b
--- /dev/null
+++ b/common/spl/spl_onenand.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (C) 2011
+ * Corscience GmbH Co. KG - Simon Schwarz schw...@corscience.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 config.h
+#include spl.h
+#include asm/io.h
+#include onenand_uboot.h
+
+void spl_onenand_load_image(void)
+{
+ struct image_header *header;
+ int *src __attribute__((unused));
+ int *dst __attribute__((unused));
why these are needed? just remove these.
Right, I'll remove.
Thank you,
Kyungmin Park
+
+ debug(spl: onenand\n);
+
+ /*use CONFIG_SYS_TEXT_BASE as temporary storage area */
+ header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+ /* Load u-boot */
+ onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,
+ CONFIG_SYS_ONENAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ onenand_spl_load_image(CONFIG_SYS_ONENAND_U_BOOT_OFFS,
+ spl_image.size, (void *)spl_image.load_addr);
+}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Thanks,
Enric
Re: [U-Boot] [PATCH 1/5] Add bmp_layout module for accessing BMP header data
On 02/05/13 15:20, Wolfgang Denk wrote: Dear Igor, In message 5110ef4f.3080...@compulab.co.il you wrote: Why should we? Who tells that this is not perfectly legal on the running system? It might be perfectly legal, but we also consider a tons of work explaining why and how this should be done (needless to mention the amount of bricked boards). Please understand that I will not really buy this bricked bord argument. This is an issue where system builders and users are involved. Apparently the system builders agree that performance is so important that they compile with optimizer options that do not tolerate unaligned accesses, thus introducing the problem. This is OK for systems where only educated users have access. If you open the U-Boot console interface to uneducated users, you are always running some risk that a stupid command will brick the board or at least make it no longer usable to that user. And as a user you should well be aware that bad things can happen, and that it is an excellent idea to actually test any new settings or operations before installing these. If users ignore even such basic rules, then the situation is f*cked up and cannot be helped - if it's not the spalsh screen, then these users will find other ways to run into trouble. Totally... I agree the bricked bored ;-) should not be an argument, but the tons of work might be... Let me repeat it: U-Boot is a boot loader. It is not intended for meddling by avarage Johnny Loser, but for system programmers who know what they are doing. And anyone doing such things is well adviced to _test_ his settings on the command line before storing these for automatic use. As I mentioned before, omitting such tests is a sin that carries with it its own punishment. What are you trying to say? Is it that the environment variables change and in particular the splash screen installation _must_ be done by a programmer? I tried to be clear: people who work on such a level are supposed to know what they are doing. I find it interesting that a lot of arguments get raised here how important this issue is (is it? who has actually bricked a system this way?), This is a relatively new default setting for the compiler, and I think this is the reason why you (still) haven't heard about it. Also, do you really expect that whoever gets the board bricked will go complaining to the mailing list? I know many users, that don't even know about the mailing list existence at all and they don't care... What they do care is for the feature to work and have a simple yet usable user API. and how that is a special case (here I disagree), but so far you all appear to ignore my argument of testing settings before putting these to use. Loading of the splash screen has been a part of the U-Boot boot sequence for ages, so the test of the feature is roughly just place the bmp image in the right place on the storage device, set the splashimage variable and reset the board. They don't think about the new compiler right away and they don't think about the bmp header. All they think about is: I always did it like this, so lets do it the same way..., and here comes the new compiler default... Now, I agree with you, that the above might be not the best way. And I agree that U-Boot, as a boot loader, should be just a dumb piece of code that does whatever the user/programmer tells it to do. Is there any argument, from what was said in this (and other) thread, you agree with? Can you propose a feasible (yet not too expensive and not out of mainline tree) solution? -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Create an API for safely accessing BMP header fields
On Mon, Feb 04, 2013 at 03:19:56PM +0100, Albert ARIBAUD wrote: Hi Nikita, On Mon, 04 Feb 2013 14:37:06 +0200, Nikita Kiryanov nik...@compulab.co.il wrote: Hi Albert, On 02/04/2013 01:57 PM, Albert ARIBAUD wrote: IIRC, you has submitted a fix so that BMP loads would result in correctly aligned fields and thus no need for accessors. Why this change of mind? I did mention that I consider that fix as temporary. I believe this fix is better because it addresses the issue everywhere and does so in a more maintainable way (does not require the address fix to be duplicated everywhere there is a problem). I actually like the new fix less, as it adds an API where there is no need of one -- it's not like the implementation of BMP is at risk of changing. What is the problem in fixing the load address at load time and then passing this fixed address around? OK, so I'm wondering. Isn't this an example of where our idea that unaligned accesses are a software problem to fix, rather than an area to let the hardware fixup for us, when able, is wrong? In other words, a real life example of why we should go with -munaligned-access being set for v7, set the HW bit and let things go? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please Ignore: email client test
You will NOT wrap long lines under any circumstances unless I tell you to, no matter what the line length is, because I know my intent better than you. Here are tabs because I want tabs. When I want spaces I will used them, and expect them to be where I put them. Finally, if you encapsulate this as a multipart\mime, I will rip out your bytes and nibble them into little bits, you dumb email client. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] undefined/undocumented CONFIG_CMD_* macros in u-boot
some time ago, i wrote some simple shell scripts that scanned the kernel source tree and identified oddities in configuration files -- things like Kconfig variables that were defined but never used, macros that were being tested but were never set, etc. i just tweaked one of those scripts to scan the u-boot tree to locate CONFIG_CMD_* variables that were being tested, but weren't #defined anywhere. nothing wrong with that, most of them are still documented and i've added at the bottom the fairly short output of those u-boot variables as well as their occurrence in the tree. they fall into three categories, with examples. here's one where there's no #define, but the variable is at least documented so no problem: = CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST README: CONFIG_CMD_DS4510_RST * ds4510 I2C rst command here's one where there's no #define, and apparently no documentation anywhere: = CONFIG_CMD_NAND_YAFFS common/cmd_nand.c:#ifdef CONFIG_CMD_NAND_YAFFS common/cmd_nand.c:#ifdef CONFIG_CMD_NAND_YAFFS drivers/mtd/nand/nand_util.c:#ifdef CONFIG_CMD_NAND_YAFFS drivers/mtd/nand/nand_util.c:#ifdef CONFIG_CMD_NAND_YAFFS include/configs/M54418TWR.h:#undef CONFIG_CMD_NAND_YAFFS finally, here's a case that looks like a reference to a command that was never added and thus represents pointless code: = CONFIG_CMD_FUSE arch/powerpc/cpu/mpc512x/iim.c:#ifdef CONFIG_CMD_FUSE arch/powerpc/cpu/mpc512x/iim.c:#endif /* CONFIG_CMD_FUSE */ board/esd/mecp5123/mecp5123.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/pdm360ng/pdm360ng.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/davedenx/aria/aria.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/freescale/mpc5121ads/mpc5121ads.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) include/configs/mecp5123.h:#undef CONFIG_CMD_FUSE include/configs/aria.h:#undef CONFIG_CMD_FUSE include/configs/mpc5121ads.h:#undef CONFIG_CMD_FUSE here's the full list -- not all that long: = CONFIG_CMD_DS4510_MEM drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_MEM drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_MEM drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_MEM drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_MEM drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_MEM README: CONFIG_CMD_DS4510_MEM * ds4510 I2C eeprom/sram commansd = CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST drivers/misc/ds4510.c:#ifdef CONFIG_CMD_DS4510_RST README: CONFIG_CMD_DS4510_RST * ds4510 I2C rst command = CONFIG_CMD_ENV_CALLBACK common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_CALLBACK) common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_CALLBACK) common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_CALLBACK) README: CONFIG_CMD_ENV_CALLBACK * display details about env callbacks = CONFIG_CMD_ENV_FLAGS common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_FLAGS) common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_FLAGS) common/cmd_nvedit.c:#if defined(CONFIG_CMD_ENV_FLAGS) common/env_flags.c:#ifdef CONFIG_CMD_ENV_FLAGS common/env_flags.c:#endif /* CONFIG_CMD_ENV_FLAGS */ include/env_flags.h:#ifdef CONFIG_CMD_ENV_FLAGS README: CONFIG_CMD_ENV_FLAGS* display details about env flags = CONFIG_CMD_FUSE arch/powerpc/cpu/mpc512x/iim.c:#ifdef CONFIG_CMD_FUSE arch/powerpc/cpu/mpc512x/iim.c:#endif /* CONFIG_CMD_FUSE */ board/esd/mecp5123/mecp5123.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/pdm360ng/pdm360ng.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/davedenx/aria/aria.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) board/freescale/mpc5121ads/mpc5121ads.c:#if defined(CONFIG_IIM) || defined(CONFIG_CMD_FUSE) include/configs/mecp5123.h:#undef CONFIG_CMD_FUSE include/configs/aria.h:#undef CONFIG_CMD_FUSE include/configs/mpc5121ads.h:#undef CONFIG_CMD_FUSE = CONFIG_CMD_LINK_LOCAL common/cmd_net.c:#if defined(CONFIG_CMD_LINK_LOCAL) common/cmd_net.c:#endif /* CONFIG_CMD_LINK_LOCAL */ doc/README.link-local:When CONFIG_CMD_LINK_LOCAL is defined in the board config file, doc/README.link-local:by env variables. It depends on CONFIG_CMD_LINK_LOCAL, CONFIG_CMD_DHCP, include/config_uncmd_spl.h:#undef CONFIG_CMD_LINK_LOCAL include/common.h: defined(CONFIG_CMD_LINK_LOCAL) lib/Makefile:COBJS-$(CONFIG_CMD_LINK_LOCAL) += rand.o net/arp.c:#ifdef CONFIG_CMD_LINK_LOCAL net/net.c:#if defined(CONFIG_CMD_LINK_LOCAL) net/link_local.h:#if defined(CONFIG_CMD_LINK_LOCAL) net/Makefile:COBJS-$(CONFIG_CMD_LINK_LOCAL) += link_local.o README: CONFIG_CMD_LINK_LOCAL * link-local IP address auto-configuration = CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES common/cmd_mtdparts.c:#if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) common/cmd_mtdparts.c:#if
Re: [U-Boot] [PATCH V2 1/5] ARM: OMAP5: Add silicon id support for ES2.0 revision.
On 18:02-20130205, R Sricharan wrote:
On Tuesday 05 February 2013 01:11 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include/asm/armv7.h |1 +
arch/arm/include/asm/omap_common.h |2 ++
4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index dfc0e44..0d8c95d 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -216,8 +216,17 @@ void init_omap_revision(void)
break;
}
break;
- default:
- *omap_si_rev = OMAP5430_SILICON_ID_INVALID;
+ case MIDR_CORTEX_A15_R2P2:
+ switch (readl(CONTROL_ID_CODE)) {
+ case OMAP5430_CONTROL_ID_CODE_ES2_0:
+ *omap_si_rev = OMAP5430_ES2_0;
+ break;
+ case OMAP5432_CONTROL_ID_CODE_ES2_0:
+ *omap_si_rev = OMAP5432_ES2_0;
+ break;
+ default:
+ *omap_si_rev = OMAP5430_SILICON_ID_INVALID;
+ }
A first few samples of both ES1.0 and ES2.0 (in the few 10s of samples) came
with wrong efuse
ID fused in, why would we want to make it a standard to check ARMsilicon
revision *and then* cross verify against control fuse verification, *and
then* give up saying we dont support it?
Looks like an over check for me - IMHO, we should drop the MIDR checks
entirely.
In the same context, for some boards in past even in the actual samples
the CONTROL ID code was reading the older revision. So in those
cases ARM revision will help to differentiate them.
which boards? Almost as a rule the first few samples on almost all
revisions on production floor had messed up control ID, however, beyond
that, all runs are properly updated.
But then it should have been in the opposite way, like reading the
CONTROL_CODE first and then reading the ARM revision if required in
those cases where is it broken. I will change this logic here.
Having cortex check is just redundant - IMHO, switching it over might be
better, but dropping it is more inline with expectation of the silicon
spec.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/5] ARM: OMAP5: clocks: Add OPP settings required for OMAP543X ES2.0 soc
On 17:32-20130205, R Sricharan wrote:
Hi Nishanth,
On Tuesday 05 February 2013 01:46 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
--please be clear that these are for OPP_NOM. FYI, latest documentation
is 0.5 rev which was released in Jan, considering this patch was send in
Feb, might be good to cross verify any updates.
Thanks for the info, i was not aware of 0.5 version. I will recheck
if something is different here.
in addition, I suspect TRM was referred for certain DPLLs as well?
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |4 +
arch/arm/cpu/armv7/omap4/hw_data.c | 142 +++---
arch/arm/cpu/armv7/omap5/hw_data.c | 242
+++-
arch/arm/include/asm/arch-omap5/clocks.h |4 +
arch/arm/include/asm/omap_common.h |6 +-
5 files changed, 241 insertions(+), 157 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 88e5336..164253c 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -103,10 +103,14 @@ void setup_post_dividers(u32 const base, const struct
dpll_params *params)
writel(params-m6_h13, dpll_regs-cm_div_m6_h13_dpll);
if (params-m7_h14 = 0)
writel(params-m7_h14, dpll_regs-cm_div_m7_h14_dpll);
+ if (params-h21 = 0)
+ writel(params-h21, dpll_regs-cm_div_h21_dpll);
if (params-h22 = 0)
writel(params-h22, dpll_regs-cm_div_h22_dpll);
if (params-h23 = 0)
writel(params-h23, dpll_regs-cm_div_h23_dpll);
+ if (params-h24 = 0)
+ writel(params-h24, dpll_regs-cm_div_h24_dpll);
}
static inline void do_bypass_dpll(u32 const base)
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 892d016..b01bf5d 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -51,113 +51,113 @@ struct omap_sys_ctrl_regs const **ctrl =
/* dpll locked at 1400 MHz MPU clk at 700 MHz(OPP100) - DCC OFF */
this: equivalent to OPP_SB?
static const struct dpll_params mpu_dpll_params_1400mhz[NUM_SYS_CLKS] = {
- {175, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
- {700, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
- {125, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
- {401, 10, 1, -1, -1, -1, -1, -1, -1, -1}, /* 19.2 MHz */
- {350, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
- {700, 26, 1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
- {638, 34, 1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
+ {175, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
+ {700, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
+ {125, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
+ {401, 10, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 19.2 MHz */
+ {350, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
+ {700, 26, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
+ {638, 34, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
};
/* dpll locked at 1584 MHz - MPU clk at 792 MHz(OPP Turbo 4430) */
Do we even support this? there is no OPP Turbo for OMAP5, we have
OPP_HIGH which needs DCC and AVS etc..
static const struct dpll_params mpu_dpll_params_1600mhz[NUM_SYS_CLKS] = {
- {200, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
- {800, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
- {619, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 16.8 MHz */
- {125, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
- {400, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
- {800, 26, 1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
- {125, 5, 1, -1, -1, -1, -1, -1, -1, -1} /* 38.4 MHz */
+ {200, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
+ {800, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
+ {619, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 16.8 MHz */
+ {125, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
+ {400, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
+ {800, 26, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
+ {125, 5, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1} /* 38.4 MHz */
};
/* dpll locked at 1200 MHz - MPU clk at 600 MHz */
Please correct this.
static const struct dpll_params mpu_dpll_params_1200mhz[NUM_SYS_CLKS] = {
- {50, 0, 1, -1, -1, -1, -1, -1, -1, -1}, /* 12 MHz */
- {600, 12, 1, -1, -1, -1
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver forall T20 boards
Marc,
On Tue, Feb 5, 2013 at 2:28 AM, Marc Dietrich marvi...@gmx.de wrote:
Hi Tom,
Am Montag, 4. Februar 2013, 16:48:55 schrieb Tom Warren:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
Signed-off-by: Tom Warren twar...@nvidia.com
---
arch/arm/include/asm/arch-tegra/mmc.h |2 +-
arch/arm/include/asm/arch-tegra/tegra_mmc.h | 12 +-
board/avionic-design/common/tamonten.c|4 +-
board/compal/paz00/paz00.c| 14 +-
board/compulab/trimslice/trimslice.c | 10 +-
board/nvidia/harmony/harmony.c| 12 +-
board/nvidia/seaboard/seaboard.c | 14 +-
board/nvidia/whistler/whistler.c |4 +-
board/toradex/colibri_t20_iris/colibri_t20_iris.c |2 +-
drivers/mmc/tegra_mmc.c | 186
++--- include/fdtdec.h |
1 +
lib/fdtdec.c |1 +
12 files changed, 165 insertions(+), 97 deletions(-)
[...]
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
This looks wrong because the sd is on sdmmc0
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
and the emmc on sdmmc3. The DTS is correct.
Not your fault as it seems to be wrong in the original code already.
I guess it didn't made large difference but may in the future. I wonder how to
test this though.
Marc
OK, so just the comments are wrong in paz00.c - I can fix that if I
have to do a V2 patchset, or when I apply the patches to u-boot-tegra.
As to testing, just stop at the command prompt and select each device
(mmc dev 0, etc.) and run mmcinfo. You should be able to tell from the
data displayed whether you are on an SD-card or eMMC chip. You can
also eject the SD-card and you should get a warning about card
presence due to the CD GPIO.
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Tegra: MMC: Add DT support for MMC to T20 boards
Thierry, On Tue, Feb 5, 2013 at 3:21 AM, Thierry Reding thierry.red...@avionic-design.de wrote: On Mon, Feb 04, 2013 at 04:48:53PM -0700, Tom Warren wrote: This patchset adds device-tree support to the Tegra MMC driver. All device config is done via properties in the DT files instead of hard-coded config options/function arguments. I've tested this on my Seaboard and everything works fine, including card detect. For the other T20 boards, I've used the Linux kernel DTS files for the sdhci nodes where there wasn't one already, or expanded the info that was already there. Everything builds fine, but I haven't tested anything but Seaboard. Tom Warren (2): Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files Tegra: MMC: Add DT support to MMC driver for all T20 boards I've tested on TEC only, but since Medcom-Wide and Plutux are also based on Tamonten they should be good as well, so: Tested-by: Thierry Reding thierry.red...@avionic-design.de Great! Thanks Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] #defined CONFIG_CMD_* variables that are never used -- short list
self-explanatory -- variables that are explicitly defined but are apparently never used anywhere in the code. amusingly, i had to open up the matching when i noticed the misspelling at the end. if all of these are superfluous, i can submit a single patch to remove it all. i will shut up and go back to work now, but if there's any particular scanning you want, i probably have a script that will do the trick. = CONFIG_CMD_CLEAR include/configs/nokia_rx51.h:#define CONFIG_CMD_CLEAR /* ANSI terminal clear screen command */ = CONFIG_CMD_DEFAULTENV_VARS include/configs/km/keymile-common.h:#define CONFIG_CMD_DEFAULTENV_VARS = CONFIG_CMD_DFL include/configs/armadillo-800eva.h:#define CONFIG_CMD_DFL include/configs/sh7752evb.h:#define CONFIG_CMD_DFL = CONFIG_CMD_MEMTEST include/configs/ppmc8260.h:#define CONFIG_CMD_MEMTEST = CONFIG_CMD_STORAGE include/configs/cam_enc_4xx.h:#define CONFIG_CMD_STORAGE /* inclue support for usb-storage cmd */ include/configs/da830evm.h:#define CONFIG_CMD_STORAGE /* inclue support for usb-storage cmd */ include/configs/davinci_dvevm.h:#define CONFIG_CMD_STORAGE include/configs/davinci_dm365evm.h:#define CONFIG_CMD_STORAGE /* include support for usb */ include/configs/davinci_dm365evm.h:#define CONFIG_CMD_STORAGE /* inclue support for usb-storage cmd */ = CONGIG_CMD_STORAGE include/configs/am3517_evm.h:#define CONGIG_CMD_STORAGE include/configs/am3517_crane.h:#define CONGIG_CMD_STORAGE include/configs/omap3_evm_common.h:#define CONGIG_CMD_STORAGE rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to configure u-boot to tell me more about NAND flash?
Dear Robert, In message 20130205083720.16752bc01ocd9...@crashcourse.ca you wrote: experimenter kit lookalike except that it has (allegedly) had its NOR flash replaced with 2G of NAND flash,... ... rday flinfo rday should flinfo not tell me about my flash? do i need another config setting for this micron flash chip (whose identity is still a bit of a mystery)? flinfo tells you every detail about the (NOR) flash it finds on your board... Sorry, flinfo is for NOR only. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Confound these ancestors They've stolen our best ideas! - Ben Jonson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/5] am33xx: support for booting via usbeth
On Mon, Dec 31, 2012 at 06:32:40AM -, Ilya Yanok wrote: This patch adds BOOT_DEVICE define for USB booting and fixes spl_board_init function to call arch_misc_init (this is the place there musb is initialized). Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com On further review, I drop my previous objection. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 4/5] spl: add possibility to force boot device
On Mon, Dec 31, 2012 at 06:32:42AM -, Ilya Yanok wrote: Sometimes (for debugging purposes mostly but also to overcome some hardware limitations) it's desirable to be able to force boot device to some fixed value. This patch adds this possibility via CONFIG_SPL_FORCE_BOOT_DEVICE option. Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com I don't like this, so I'm going to drop it. It does provide a proof of concept to allow earlier testing of USB SPL support, but fixed hardware exists now. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 5/5] am335x_evm: add new config with forced USB booting
On Mon, Dec 31, 2012 at 06:32:43AM -, Ilya Yanok wrote: Currently AM335X hardware has bug in it's ROM code that prevents USB booting from working normally. So we have to load SPL via serial console instead. But it's feasible to use USB for loading the main U-Boot image. This patch adds additional am335x_evm configuration for this. Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com And with 4/5 dropped, this one is also dropped. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9 v8] TMU: Add TMU support in dtt command
Hi Akshay,
On Tue, Feb 5, 2013 at 3:57 AM, Akshay Saraswat aksha...@samsung.com wrote:
Add generic TMU support alongwith i2c sensors in dtt command
to enable temperature reading in cases where TMU is present
instead of i2c sensors.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v7:
- Made sensor_initialized static again.
- Changed return type to int in dtt_init declaration.
common/cmd_dtt.c | 63
--
include/dtt.h|2 +-
2 files changed, 38 insertions(+), 27 deletions(-)
diff --git a/common/cmd_dtt.c b/common/cmd_dtt.c
index cd94423..799e1c7 100644
--- a/common/cmd_dtt.c
+++ b/common/cmd_dtt.c
@@ -27,52 +27,52 @@
#include dtt.h
#include i2c.h
+#include tmu.h
+#if defined CONFIG_DTT_SENSORS
static unsigned long sensor_initialized;
+#endif
-static void _initialize_dtt(void)
+int dtt_tmu(void)
{
- int i;
- unsigned char sensors[] = CONFIG_DTT_SENSORS;
+#if defined CONFIG_TMU_CMD_DTT
+ int cur_temp;
- for (i = 0; i sizeof(sensors); i++) {
- if ((sensor_initialized (1 i)) == 0) {
- if (dtt_init_one(sensors[i]) != 0) {
- printf(DTT%d: Failed init!\n, i);
- continue;
- }
- sensor_initialized |= (1 i);
- }
+ /* Sense and return latest thermal info */
+ if (tmu_monitor(cur_temp) == TMU_STATUS_INIT) {
+ puts(TMU is in unknown state, temperature is invalid\n);
+ return -1;
}
-}
-
-void dtt_init(void)
-{
- int old_bus;
-
- /* switch to correct I2C bus */
- old_bus = I2C_GET_BUS();
- I2C_SET_BUS(CONFIG_SYS_DTT_BUS_NUM);
-
- _initialize_dtt();
+ printf(Current temperature: %u degrees Celsius\n, cur_temp);
+#endif
- /* switch back to original I2C bus */
- I2C_SET_BUS(old_bus);
+ return 0;
}
-int do_dtt (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
+int dtt_init(void)
I think this function is supposed to initialize the sensors but you
have changed it to print them out. Other places call this function and
likely rely on the current behaviour.
I think all you need to do is:
- leave the two _initialize_dtt() and init_dtt() functions as they were
- put the code for the old dtt command into a function, like
dtt_i2c(), but leave it largely as is
Really then all you are doing is putting the current code in do_dtt()
into a dtt_i2c() function, and adding calls to dtt_i2c() and dtt_tmu()
from the now-empty do_dtt(). You actually have do_dtt() correct below,
although I suggest dtt_i2c() is a better name for the function than
dtt_init().
It is unfortunate that the existing code is so fixed-purpose, and not
particularly clean, but this approach should allow you to do what you
need.
{
+#if defined CONFIG_DTT_SENSORS
int i;
unsigned char sensors[] = CONFIG_DTT_SENSORS;
int old_bus;
/* Force a compilation error, if there are more then 32 sensors */
BUILD_BUG_ON(sizeof(sensors) 32);
+
/* switch to correct I2C bus */
old_bus = I2C_GET_BUS();
I2C_SET_BUS(CONFIG_SYS_DTT_BUS_NUM);
- _initialize_dtt();
+ /* Initialize dtt sensors */
+ for (i = 0; i sizeof(sensors); i++) {
+ if ((sensor_initialized (1 i)) == 0) {
+ if (dtt_init_one(sensors[i]) != 0) {
+ printf(DTT%d: Failed init!\n, i);
+ continue;
+ }
+ sensor_initialized |= (1 i);
+ }
+ }
/*
* Loop through sensors, read
@@ -83,8 +83,19 @@ int do_dtt (cmd_tbl_t * cmdtp, int flag, int argc, char *
const argv[])
/* switch back to original I2C bus */
I2C_SET_BUS(old_bus);
+#endif
return 0;
+}
+
+int do_dtt(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
+{
+ int err = 0;
+
+ err |= dtt_init();
+ err |= dtt_tmu();
+
+ return err;
} /* do_dtt() */
/***/
diff --git a/include/dtt.h b/include/dtt.h
index 6d5534d..94fbce3 100644
--- a/include/dtt.h
+++ b/include/dtt.h
@@ -52,7 +52,7 @@
#endif
#endif /* CONFIG_DTT_ADM1021 */
-extern void dtt_init(void);
+extern int dtt_init(void);
extern int dtt_init_one(int);
extern int dtt_read(int sensor, int reg);
extern int dtt_write(int sensor, int reg, int val);
--
1.7.9.5
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] changing bootcmd environment
On 02/04/2013 10:54:52 PM, Ratheendran R wrote: Dear All, I am using u-boot given by our Samsung based s3c2416 board vendor which support SD CARD based boot,I am trying to change the boot command variable adding few more steps to it from the serial console. The problem is I am not able to add all the steps to the bootcmd variable into the environment,it is truncated midway.so can any one share your valuable experience in fixing this issue. I am trying the below command.. setenv bootcmd sleep 1;nand scrub ;sleep 1;nand erase;sleep 1;movi read 380# 4 c000 ;sleep 1;nand write c000 0 4;sleep 1;movi read kernel c000;sleep 1;nand write c000 4 20;sleep 1;movi read 360# 380 c000 ;sleep 1; nand write.yaffs c000 40 35db4c0; sleep1; movi read 360# 380 c000; nand write.yaffs c000 600 35db4c0 Using nand scrub in this manner is totally wrong. Even without scrubbing, erasing and rewriting NAND on each boot is not a good idea. It also indicates you're using an old U-Boot, as for a while now full-chip erase commands have to be written as nand erase.chip. Plus I don't see a movi command in mainline U-Boot. Maybe you should be asking your board vendor for support? Why do you need all those sleep commands? You could shorten your bootcmd quite a bit by removing them... -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to configure u-boot to tell me more about NAND flash?
On 02/05/2013 07:37:20 AM, Robert P. J. Day wrote: a few basic questions about a board i don't have access to right this minute but did yesterday and will later today. it's an AM1808 experimenter kit lookalike except that it has (allegedly) had its NOR flash replaced with 2G of NAND flash, and i want to figure out what i can add to the current u-boot da850evm configuration to let me poke around and get all the info i can on that flash because there seems to be something strange about the current setup. first, when i let the board boot fully into linux, dmesg told me this: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit) that appears to tell me 512M of NAND flash, not 2G. i asked someone who was initially adamant that there was 2G but promised to check with the H/W folks to make absolutely sure. is there a possible reason why 2G would show up only as 512M in dmesg? (not really a u-boot question, just wondering.) Is it possible you have 4 chips, each of which are 512 MiB? If that's not it, probably the ID table is wrong. Maybe they're using the same ID for multiple sizes now (it's not exactly a large numberspace), and expecting you to use ONFI or other ID bytes to determine the actual size. What does U-Boot print on boot, regarding NAND? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to configure u-boot to tell me more about NAND flash?
Quoting Scott Wood scottw...@freescale.com: On 02/05/2013 07:37:20 AM, Robert P. J. Day wrote: a few basic questions about a board i don't have access to right this minute but did yesterday and will later today. it's an AM1808 experimenter kit lookalike except that it has (allegedly) had its NOR flash replaced with 2G of NAND flash, and i want to figure out what i can add to the current u-boot da850evm configuration to let me poke around and get all the info i can on that flash because there seems to be something strange about the current setup. first, when i let the board boot fully into linux, dmesg told me this: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit) that appears to tell me 512M of NAND flash, not 2G. i asked someone who was initially adamant that there was 2G but promised to check with the H/W folks to make absolutely sure. is there a possible reason why 2G would show up only as 512M in dmesg? (not really a u-boot question, just wondering.) Is it possible you have 4 chips, each of which are 512 MiB? false alarm ... i got bad initial info and the board really does have exactly 512M of NAND. whew ... wasn't looking forward to trying to debug that. rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Add bmp_layout module for accessing BMP header data
Dear Igor, In message 5c0f.60...@compulab.co.il you wrote: This is a relatively new default setting for the compiler, and I think this is the reason why you (still) haven't heard about it. Also, do you really expect that whoever gets the board bricked will go complaining to the mailing list? Then how do we kno if this is just an anticipated or a real problem? Loading of the splash screen has been a part of the U-Boot boot sequence for ages, so the test of the feature is roughly just place the bmp image in the right place on the storage device, set the splashimage variable and reset the board. Maybe I'm so weird then - I think I have never blindly installed a splash screen without checking before that it actually works and looks good, using the bmp command... Can you propose a feasible (yet not too expensive and not out of mainline tree) solution? Well, if I understand the situation correctly, the problem we have is that the bitmap address for the splash screen should be aligned to an even 32 bit boundary + 1. The address is stored in an environment variable. So why don't we implement a callback on that variable that checks itd's value when it gets set? We have all the features in place now; and we can even overwrite such a default setting on boards where it's not needed / wanted. So my recommendation is: add a new alignment-checking extension as a callback to the variable handling code. 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 Have you lived in this village all your life?No, not yet. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Create an API for safely accessing BMP header fields
Hi Tom, On Tue, 5 Feb 2013 09:58:52 -0500, Tom Rini tr...@ti.com wrote: On Mon, Feb 04, 2013 at 03:19:56PM +0100, Albert ARIBAUD wrote: Hi Nikita, On Mon, 04 Feb 2013 14:37:06 +0200, Nikita Kiryanov nik...@compulab.co.il wrote: Hi Albert, On 02/04/2013 01:57 PM, Albert ARIBAUD wrote: IIRC, you has submitted a fix so that BMP loads would result in correctly aligned fields and thus no need for accessors. Why this change of mind? I did mention that I consider that fix as temporary. I believe this fix is better because it addresses the issue everywhere and does so in a more maintainable way (does not require the address fix to be duplicated everywhere there is a problem). I actually like the new fix less, as it adds an API where there is no need of one -- it's not like the implementation of BMP is at risk of changing. What is the problem in fixing the load address at load time and then passing this fixed address around? OK, so I'm wondering. Isn't this an example of where our idea that unaligned accesses are a software problem to fix, rather than an area to let the hardware fixup for us, when able, is wrong? In other words, a real life example of why we should go with -munaligned-access being set for v7, set the HW bit and let things go? I feel this is addressed to me. :) And no, I don't think the BMP issue should be solved by relaxing HW constraints. BMP is not a HW-enforced or protocol format. Anyway, as I said, even if we really could not avoid misaligned fields (and we know at least two ways we could), then the solution would not be to flip a general HW switch controlling all accesses, since only the BMP accesses are a problem! We could just make sure we access the poorly aligned fields through dedicated unaligned accessors, e.g. readl_u(field) / writel_u(field). Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
On 02/04/2013 04:48 PM, Tom Warren wrote:
Linux dts files were used for those boards that didn't already
have sdhci info populated. If a cd-gpio was present, I set
removable = 1, else removable = 0.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
sdhci@c8000200 {
compatible = nvidia,tegra20-sdhci;
reg = 0xc8000200 0x200;
interrupts = 47 ;
+ status = disabled;
+ /* PERIPH_ID_SDMMC2, PLLP_OUT? */
+ clocks = tegra_car 9;
};
What does PLLP_OUT? mean?
I'm not entirely convinced it's a good idea to add this comment, since
it creates a diff between the .dts files in the kernel and U-Boot.
Similarly, the status and clocks properties are in the other order in
the kernel .dts files. It'd be good to be consistent to allow minimal
diffs between them.
diff --git a/board/avionic-design/dts/tegra20-medcom-wide.dts
b/board/avionic-design/dts/tegra20-medcom-wide.dts
I suppose that there are no aliases in this file because only one SDHCI
controller is enabled. I wonder if we should add aliases to all .dts
files just to be explicit? Perhaps it's not necessary because this board
really will never ever get another SDHCI controller added (I assume that
any SDHCI controllers the board has are already enabled, although I
wonder about SDIO...), so there doesn't need to be a hint that there
should be an alias added too?
+ sdhci@c8000600 {
In the kernel, this SDHCI node is part of tegra20-tamonten.dtsi, since
its parameters are defined by the carrier board. I think U-Boot .dts
files should match.
The following 3 comments apply to all the .dts files (or at least the
1st and 3rd; not sure about the 2nd):
+ status = okay;
+ /* Parameter 3 bit 0:1=output, 0=input; bit 1:1=high, 0=low */
I don't think that comment is particularly useful. While it's true,
duplicating it every single place a GPIO is used seems wasteful. And the
comment is more re: the GPIO binding that anything to do with SDHCI.
Plus, it makes another diff relative to the kernel.
+ cd-gpios = gpio 58 0;/* gpio PH2 */
+ wp-gpios = gpio 59 0;/* gpio PH3 */
The kernel appears to have a space before the comment not a TAB, so this
makes another diff..
+ bus-width = 4;
+ removable = 1;
What is removable? That's not in the binding documentation. There is a
non-removable property defined in the kernel's
Documentation/devicetree/bindings/mmc/mmc.txt though...
+ };
diff --git a/board/nvidia/dts/tegra20-ventana.dts
b/board/nvidia/dts/tegra20-ventana.dts
This file doesn't have any aliases added.
+ sdhci@c800 {
+ status = okay;
+ power-gpios = gpio 86 0; /* gpio PK6 */
+ bus-width = 4;
+ removable = 0;
+ };
I think that's the WiFi SDIO port, so you may not need to add it to U-Boot.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
On 02/04/2013 04:48 PM, Tom Warren wrote:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
return 0;
}
That doesn't look right. The board code still has knowledge of which
SDHCI controllers are in use by the board. Instead, the board should
just call tegra_mmc_init() with no parameters at all, and the MMC driver
should scan the device tree for all present-and-enabled SDHCI nodes, and
instantiate a U-Boot SDHCI device. Without this, the device tree isn't
in control of the whole process, so there's little point doing the
conversion; a new board couldn't be supported /just/ by creating a new
device tree file.
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
+#ifndef CONFIG_OF_CONTROL
+#error Please enable device tree support to use this driver
+#endif
So CONFIG_OF_CONTROL must be enabled ...
static void tegra_get_setup(struct mmc_host *host, int dev_index)
{
- debug(tegra_get_setup: dev_index = %d\n, dev_index);
+ debug(%s: dev_index = %d\n, __func__, dev_index);
+
+#ifdef CONFIG_OF_CONTROL
... so there's no need for that ifdef
+ int count, node = 0;
+ int node_list[MAX_HOSTS];
+
+ count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
+ COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
+ debug(%s: count of nodes is %d\n, __func__, count);
+
+ if (count dev_index) {
+ printf(%s: device index %d exceeds node count (%d)!\n,
+ __func__, dev_index, count);
+ return;
+ }
This requires that an alias exist in order for the SDHCI node to be
found/processed. This isn't correct; the SDHCI nodes must be enumerated
themselves, and then the aliases (if any are present) provide a naming
hint for them, but even without aliases, the SDHCI nodes must be processed.
+ /*
+ * NOTE: mmc-bus_width is determined by mmc.c dynamically.
+ * Should we override it with this value?
+ */
+ host-width = fdtdec_get_int(gd-fdt_blob, node, bus-width, 0);
+ if (!host-width)
+ debug(%s: no sdmmc width found\n, __func__);
It should be possible to inform the MMC core of the width of the bus in
terms of wires on the PCB. It should only probe the connected device up
to that width. If that feature is missing, it can be added later though,
outside the scope of this patch set.
You didn't Cc the MMC maintainer; they should be Cc'd since this code is
in drivers/mmc/.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driverforall T20 boards
On Tuesday 05 February 2013 08:31:03 Tom Warren wrote:
Marc,
On Tue, Feb 5, 2013 at 2:28 AM, Marc Dietrich marvi...@gmx.de wrote:
[...]
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
This looks wrong because the sd is on sdmmc0
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
and the emmc on sdmmc3. The DTS is correct.
Not your fault as it seems to be wrong in the original code already.
I guess it didn't made large difference but may in the future. I wonder
how to test this though.
Marc
OK, so just the comments are wrong in paz00.c - I can fix that if I
have to do a V2 patchset, or when I apply the patches to u-boot-tegra.
ah no, this is weird!
index 3 maps to sdmmc1
index 2 maps to sdmmc2
index 1 maps to sdmmc3
index 0 maps to sdmmc4
so all is fine, nearly ...
As to testing, just stop at the command prompt and select each device
(mmc dev 0, etc.) and run mmcinfo. You should be able to tell from the
data displayed whether you are on an SD-card or eMMC chip. You can
also eject the SD-card and you should get a warning about card
presence due to the CD GPIO.
the sd card is not detected because:
TEGRA20
Board: Compal Paz00
DRAM: 512 MiB
MMC: tegra_get_setup: dev_index = 0
tegra_get_setup: count of nodes is 2
tegra_get_setup: found controller at c8000600, width = 8, periph_id = 15
tegra_mmc_init: index 0, bus width 8 pwr_gpio -1 cd_gpio -1
tegra_mmc_init: bus width = 8
tegra_get_setup: dev_index = 3
tegra_get_setup: count of nodes is 2
tegra_get_setup: device index 3 exceeds node count (2)!
If I understand correctly, you are counting the aliases only, not the
controllers..., so index 3 (the sdcard) is not initialized at all. Arrr,
debugging stole all of my time, but I guess this needs fixing.
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
Stephen,
On Tue, Feb 5, 2013 at 12:54 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/04/2013 04:48 PM, Tom Warren wrote:
Linux dts files were used for those boards that didn't already
have sdhci info populated. If a cd-gpio was present, I set
removable = 1, else removable = 0.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
sdhci@c8000200 {
compatible = nvidia,tegra20-sdhci;
reg = 0xc8000200 0x200;
interrupts = 47 ;
+ status = disabled;
+ /* PERIPH_ID_SDMMC2, PLLP_OUT? */
+ clocks = tegra_car 9;
};
What does PLLP_OUT? mean?
The clock source used for this periph. I removed it in the I2C DT
files - I'll remove it here, too, because it's up to the driver to
choose that based on the freq.
I'm not entirely convinced it's a good idea to add this comment, since
it creates a diff between the .dts files in the kernel and U-Boot.
Similarly, the status and clocks properties are in the other order in
the kernel .dts files. It'd be good to be consistent to allow minimal
diffs between them.
I used the kernel DTS files you pointed to in our internal 'Initialize
SDHCI from device tree' bug:
repo git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
branch for-next
The order matches arch/arm/boot/dts/tegra20.dtsi. I don't see a clocks
property in that kernel file, either. I do see that the interrupts
(that were already in tegra20.dtsi before I edited it) don't match the
kernel dtsi for most peripherals (i2c, i2s, sdhci, gpio). I'll fix the
SDHCI ones in the next patchset, though.
diff --git a/board/avionic-design/dts/tegra20-medcom-wide.dts
b/board/avionic-design/dts/tegra20-medcom-wide.dts
I suppose that there are no aliases in this file because only one SDHCI
controller is enabled. I wonder if we should add aliases to all .dts
files just to be explicit? Perhaps it's not necessary because this board
really will never ever get another SDHCI controller added (I assume that
any SDHCI controllers the board has are already enabled, although I
wonder about SDIO...), so there doesn't need to be a hint that there
should be an alias added too?
If there was already an alias property in the DT file, then I tried to
be consistent and add one for mmc. But adding aliases to
other-than-NVIDIA boards should be up to the board
maintainer/manufacturer, IMO.
+ sdhci@c8000600 {
In the kernel, this SDHCI node is part of tegra20-tamonten.dtsi, since
its parameters are defined by the carrier board. I think U-Boot .dts
files should match.
Saw that, but I didn't replicate it here because, well, U-Boot's Not
Linux, and IMO each board file (dts) should have its periph nodes
called out explicitly. If they all happen to be exactly the same for
each board, then I think the manufacturer/board maintainer can do that
'optimization' if they wish - they know better than I if they're
coming out with a new board that may differ in its SDHCI properties
(GPIOs, for instance).
The following 3 comments apply to all the .dts files (or at least the
1st and 3rd; not sure about the 2nd):
+ status = okay;
+ /* Parameter 3 bit 0:1=output, 0=input; bit 1:1=high, 0=low */
I don't think that comment is particularly useful. While it's true,
duplicating it every single place a GPIO is used seems wasteful. And the
comment is more re: the GPIO binding that anything to do with SDHCI.
Plus, it makes another diff relative to the kernel.
Diffing the DTS files against the kernel isn't really that big a deal
with a decent diff program (kompare, etc.). That GPIO comment is
useful if you need to understand the 3rd param for the pwr-gpios, for
instance (the cd and wp gpios almost always are input/low). And it
only appears once in each DTS file, not in every single place a GPIO
is used.
+ cd-gpios = gpio 58 0;/* gpio PH2 */
+ wp-gpios = gpio 59 0;/* gpio PH3 */
The kernel appears to have a space before the comment not a TAB, so this
makes another diff..
Really? That seems a little nit-picky. :/
My whitespace is consistent through-out the DTS file, and with how I
always space comments on the end of a line of 'code'.
+ bus-width = 4;
+ removable = 1;
What is removable? That's not in the binding documentation. There is a
non-removable property defined in the kernel's
Documentation/devicetree/bindings/mmc/mmc.txt though...
These are left-over from Seaboard's original DTS file (with which I
did my original development). It isn't used anywhere in U-Boot that I
can see. I can remove it.
+ };
diff --git a/board/nvidia/dts/tegra20-ventana.dts
b/board/nvidia/dts/tegra20-ventana.dts
This file doesn't have any aliases added.
+ sdhci@c800 {
+ status = okay;
+ power-gpios = gpio 86 0; /* gpio PK6 */
+ bus-width = 4;
+ removable
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driverforall T20 boards
Marc,
On Tue, Feb 5, 2013 at 1:06 PM, Marc Dietrich marvi...@gmx.de wrote:
On Tuesday 05 February 2013 08:31:03 Tom Warren wrote:
Marc,
On Tue, Feb 5, 2013 at 2:28 AM, Marc Dietrich marvi...@gmx.de wrote:
[...]
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
This looks wrong because the sd is on sdmmc0
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
and the emmc on sdmmc3. The DTS is correct.
Not your fault as it seems to be wrong in the original code already.
I guess it didn't made large difference but may in the future. I wonder
how to test this though.
Marc
OK, so just the comments are wrong in paz00.c - I can fix that if I
have to do a V2 patchset, or when I apply the patches to u-boot-tegra.
ah no, this is weird!
index 3 maps to sdmmc1
index 2 maps to sdmmc2
index 1 maps to sdmmc3
index 0 maps to sdmmc4
so all is fine, nearly ...
As to testing, just stop at the command prompt and select each device
(mmc dev 0, etc.) and run mmcinfo. You should be able to tell from the
data displayed whether you are on an SD-card or eMMC chip. You can
also eject the SD-card and you should get a warning about card
presence due to the CD GPIO.
the sd card is not detected because:
TEGRA20
Board: Compal Paz00
DRAM: 512 MiB
MMC: tegra_get_setup: dev_index = 0
tegra_get_setup: count of nodes is 2
tegra_get_setup: found controller at c8000600, width = 8, periph_id = 15
tegra_mmc_init: index 0, bus width 8 pwr_gpio -1 cd_gpio -1
tegra_mmc_init: bus width = 8
tegra_get_setup: dev_index = 3
tegra_get_setup: count of nodes is 2
tegra_get_setup: device index 3 exceeds node count (2)!
If I understand correctly, you are counting the aliases only, not the
controllers..., so index 3 (the sdcard) is not initialized at all. Arrr,
debugging stole all of my time, but I guess this needs fixing.
Yep, I am checking the aliases to get a node count (just like the
Tegra SPI, SLINK, and I2C drivers, and the Exynos SPI and S3C I2C
drivers).
I left the Paz00 tegra_mmc_init(3) call the same as originally (w/o
the width and GPIO params, of course). The device numbering is kind of
arbitrary - if there are only 2 MMC devices present, I'd expect dev 0
to be eMMC and dev 1 to be SD (again, like my T20 reference board,
Seaboard). I don't see that Paz uses mmc anywhere in its config files
for a boot script - does it have to have mmc dev 3 be SD? or would dev
1 work? Note that the tegra20-common-post.h file that all T20 boards
inherit uses dev 0 and dev 1.
Let me look into it - wish I had a Paz00 board here to debug with.
I'll try to simulate this on my Seaboard, maybe with all 4 MMC device
addresses in the alias.
Thanks for the help,
Tom
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
On 02/05/2013 01:29 PM, Tom Warren wrote:
Stephen,
On Tue, Feb 5, 2013 at 12:54 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/04/2013 04:48 PM, Tom Warren wrote:
Linux dts files were used for those boards that didn't already
have sdhci info populated. If a cd-gpio was present, I set
removable = 1, else removable = 0.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
sdhci@c8000200 {
compatible = nvidia,tegra20-sdhci;
reg = 0xc8000200 0x200;
interrupts = 47 ;
+ status = disabled;
+ /* PERIPH_ID_SDMMC2, PLLP_OUT? */
+ clocks = tegra_car 9;
};
What does PLLP_OUT? mean?
The clock source used for this periph. I removed it in the I2C DT
files - I'll remove it here, too, because it's up to the driver to
choose that based on the freq.
I'm not entirely convinced it's a good idea to add this comment, since
it creates a diff between the .dts files in the kernel and U-Boot.
Similarly, the status and clocks properties are in the other order in
the kernel .dts files. It'd be good to be consistent to allow minimal
diffs between them.
I used the kernel DTS files you pointed to in our internal 'Initialize
SDHCI from device tree' bug:
repo git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
branch for-next
linux-next or the Tegra git tree have the latest additions. arm-soc
hopefully will have them merged in the next day or two.
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(whatever the latest tag is there)
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
(for-next)
diff --git a/board/avionic-design/dts/tegra20-medcom-wide.dts
b/board/avionic-design/dts/tegra20-medcom-wide.dts
I suppose that there are no aliases in this file because only one SDHCI
controller is enabled. I wonder if we should add aliases to all .dts
files just to be explicit? Perhaps it's not necessary because this board
really will never ever get another SDHCI controller added (I assume that
any SDHCI controllers the board has are already enabled, although I
wonder about SDIO...), so there doesn't need to be a hint that there
should be an alias added too?
If there was already an alias property in the DT file, then I tried to
be consistent and add one for mmc. But adding aliases to
other-than-NVIDIA boards should be up to the board
maintainer/manufacturer, IMO.
I don't think so; at least with the driver as-is, the code appears not
to work without aliases, so not adding them causes a regression. Even
ignoring that, I don't see why the code-DT conversion patch shouldn't
do this for all boards.
+ sdhci@c8000600 {
In the kernel, this SDHCI node is part of tegra20-tamonten.dtsi, since
its parameters are defined by the carrier board. I think U-Boot .dts
files should match.
Saw that, but I didn't replicate it here because, well, U-Boot's Not
Linux, and IMO each board file (dts) should have its periph nodes
called out explicitly. If they all happen to be exactly the same for
each board, then I think the manufacturer/board maintainer can do that
'optimization' if they wish - they know better than I if they're
coming out with a new board that may differ in its SDHCI properties
(GPIOs, for instance).
No, this has nothing to do with U-Boot vs. Linux. The device tree files
are (should eventually be) standard between the two, and indeed hosted
outside U-Boot. Unrelated, common code is common and should be
represented at a common location. In this case, the vendor for this
particular file has already correctly chosen to put the SDHCI nodes in
the common file, so this needs to be maintained.
The following 3 comments apply to all the .dts files (or at least the
1st and 3rd; not sure about the 2nd):
+ status = okay;
+ /* Parameter 3 bit 0:1=output, 0=input; bit 1:1=high, 0=low */
I don't think that comment is particularly useful. While it's true,
duplicating it every single place a GPIO is used seems wasteful. And the
comment is more re: the GPIO binding that anything to do with SDHCI.
Plus, it makes another diff relative to the kernel.
Diffing the DTS files against the kernel isn't really that big a deal
with a decent diff program (kompare, etc.). That GPIO comment is
useful if you need to understand the 3rd param for the pwr-gpios, for
instance (the cd and wp gpios almost always are input/low). And it
only appears once in each DTS file, not in every single place a GPIO
is used.
If there is no diff at all, it's even easier.
The third parameter is already documented in the binding documentation.
+ cd-gpios = gpio 58 0;/* gpio PH2 */
+ wp-gpios = gpio 59 0;/* gpio PH3 */
The kernel appears to have a space before the comment not a TAB, so this
makes another diff..
Really? That seems a little nit-picky. :/
My whitespace is consistent
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driverforall T20 boards
On 02/05/2013 01:41 PM, Tom Warren wrote: ... I left the Paz00 tegra_mmc_init(3) call the same as originally (w/o the width and GPIO params, of course). The device numbering is kind of arbitrary - if there are only 2 MMC devices present, I'd expect dev 0 to be eMMC and dev 1 to be SD (again, like my T20 reference board, Seaboard). I don't see that Paz uses mmc anywhere in its config files for a boot script - does it have to have mmc dev 3 be SD? or would dev 1 work? Note that the tegra20-common-post.h file that all T20 boards inherit uses dev 0 and dev 1. This board currently uses U-Boot MMC device ID 0 for the eMMC and U-Boot MMC device ID 1 for the SD card slot. The U-Boot device ID's aren't directly related to the Tegra HW instance IDs. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMCdriverforall T20 boards
Tom,
On Tuesday 05 February 2013 13:41:21 Tom Warren wrote:
Marc,
On Tue, Feb 5, 2013 at 1:06 PM, Marc Dietrich marvi...@gmx.de wrote:
On Tuesday 05 February 2013 08:31:03 Tom Warren wrote:
Marc,
On Tue, Feb 5, 2013 at 2:28 AM, Marc Dietrich marvi...@gmx.de wrote:
[...]
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
This looks wrong because the sd is on sdmmc0
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
and the emmc on sdmmc3. The DTS is correct.
Not your fault as it seems to be wrong in the original code already.
I guess it didn't made large difference but may in the future. I wonder
how to test this though.
Marc
OK, so just the comments are wrong in paz00.c - I can fix that if I
have to do a V2 patchset, or when I apply the patches to u-boot-tegra.
ah no, this is weird!
index 3 maps to sdmmc1
index 2 maps to sdmmc2
index 1 maps to sdmmc3
index 0 maps to sdmmc4
so all is fine, nearly ...
As to testing, just stop at the command prompt and select each device
(mmc dev 0, etc.) and run mmcinfo. You should be able to tell from the
data displayed whether you are on an SD-card or eMMC chip. You can
also eject the SD-card and you should get a warning about card
presence due to the CD GPIO.
the sd card is not detected because:
TEGRA20
Board: Compal Paz00
DRAM: 512 MiB
MMC: tegra_get_setup: dev_index = 0
tegra_get_setup: count of nodes is 2
tegra_get_setup: found controller at c8000600, width = 8, periph_id = 15
tegra_mmc_init: index 0, bus width 8 pwr_gpio -1 cd_gpio -1
tegra_mmc_init: bus width = 8
tegra_get_setup: dev_index = 3
tegra_get_setup: count of nodes is 2
tegra_get_setup: device index 3 exceeds node count (2)!
If I understand correctly, you are counting the aliases only, not the
controllers..., so index 3 (the sdcard) is not initialized at all. Arrr,
debugging stole all of my time, but I guess this needs fixing.
Yep, I am checking the aliases to get a node count (just like the
Tegra SPI, SLINK, and I2C drivers, and the Exynos SPI and S3C I2C
drivers).
I left the Paz00 tegra_mmc_init(3) call the same as originally (w/o
the width and GPIO params, of course). The device numbering is kind of
arbitrary - if there are only 2 MMC devices present, I'd expect dev 0
to be eMMC and dev 1 to be SD (again, like my T20 reference board,
Seaboard). I don't see that Paz uses mmc anywhere in its config files
for a boot script - does it have to have mmc dev 3 be SD? or would dev
1 work? Note that the tegra20-common-post.h file that all T20 boards
inherit uses dev 0 and dev 1.
U-boot scans all devices during boot, so no need to specify a specific one. I
think what Stephen is suggesting is the right way. Forget all this dev ids and
let the device tree control everything. The aliases can be used for enumbering
if someone really needs it.
Let me look into it - wish I had a Paz00 board here to debug with.
I'll try to simulate this on my Seaboard, maybe with all 4 MMC device
addresses in the alias.
He, if you ever come to old Europe, there are still some shops selling
them ;-)
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
Stephen,
On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/04/2013 04:48 PM, Tom Warren wrote:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
return 0;
}
That doesn't look right. The board code still has knowledge of which
SDHCI controllers are in use by the board. Instead, the board should
just call tegra_mmc_init() with no parameters at all, and the MMC driver
should scan the device tree for all present-and-enabled SDHCI nodes, and
instantiate a U-Boot SDHCI device. Without this, the device tree isn't
in control of the whole process, so there's little point doing the
conversion; a new board couldn't be supported /just/ by creating a new
device tree file.
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
+#ifndef CONFIG_OF_CONTROL
+#error Please enable device tree support to use this driver
+#endif
So CONFIG_OF_CONTROL must be enabled ...
static void tegra_get_setup(struct mmc_host *host, int dev_index)
{
- debug(tegra_get_setup: dev_index = %d\n, dev_index);
+ debug(%s: dev_index = %d\n, __func__, dev_index);
+
+#ifdef CONFIG_OF_CONTROL
... so there's no need for that ifdef
I took Allen's recent SPI/SLINK driver(s) as an example, but as you
point out, if CONFIG_OF_CONTROL isn't enabled, you get build errors
anyway.
+ int count, node = 0;
+ int node_list[MAX_HOSTS];
+
+ count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
+ COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
+ debug(%s: count of nodes is %d\n, __func__, count);
+
+ if (count dev_index) {
+ printf(%s: device index %d exceeds node count (%d)!\n,
+ __func__, dev_index, count);
+ return;
+ }
This requires that an alias exist in order for the SDHCI node to be
found/processed. This isn't correct; the SDHCI nodes must be enumerated
themselves, and then the aliases (if any are present) provide a naming
hint for them, but even without aliases, the SDHCI nodes must be processed.
Again, I used Allen's SLINK driver for as a template here. In fact, it
looks like our I2C and SPI/SLINK drivers do this, as well as the
Exynos SPI and S3C24x0 I2C driver all do this. Can you point out a
U-Boot driver that does it the right way (preferably with more than 1
node, like MMC)? I can take a look at that code to use as an example
of what you're proposing above.
+ /*
+ * NOTE: mmc-bus_width is determined by mmc.c dynamically.
+ * Should we override it with this value?
+ */
+ host-width = fdtdec_get_int(gd-fdt_blob, node, bus-width, 0);
+ if (!host-width)
+ debug(%s: no sdmmc width found\n, __func__);
It should be possible to inform the MMC core of the width of the bus in
terms of wires on the PCB. It should only probe the connected device up
to that width. If that feature is missing, it can be added later though,
outside the scope of this patch set.
You didn't Cc the MMC maintainer; they should be Cc'd since this code is
in drivers/mmc/.
Thanks, added Andy Fleming to CC.
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] imx: mx5: lowlevel_init: Simplify code
Don't use several instructions to build constant values. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com --- Changes in v3: - New patch. Changes in v2: None arch/arm/cpu/armv7/mx5/lowlevel_init.S |8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index 6d9396a..dfce0ca 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -309,8 +309,7 @@ setup_pll_func: ldr r0, =CCM_BASE_ADDR ldr r1, =0x00015154 str r1, [r0, #CLKCTL_CBCMR] -ldr r1, =0x02888945 -orr r1, r1, #(1 16) +ldr r1, =0x02898945 str r1, [r0, #CLKCTL_CBCDR] /* make sure change is effective */ 1: ldr r1, [r0, #CLKCTL_CDHIPR] @@ -321,10 +320,7 @@ setup_pll_func: /* Switch peripheral to PLL2 */ ldr r0, =CCM_BASE_ADDR - ldr r1, =0x00808145 - orr r1, r1, #(2 10) - orr r1, r1, #(0 16) - orr r1, r1, #(1 19) + ldr r1, =0x00888945 str r1, [r0, #CLKCTL_CBCDR] ldr r1, =0x00016154 -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] nand: mxc: Prepare to add support for i.MX5
Add some abstraction to NFC defitnitions so that some parts of the current code
can also be used for future i.MX5 code.
Clean up a few things by the way.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3:
- Separate code reformatting from behavioral changes.
Changes in v2:
- Fix warning for unused tmp variable in board_nand_init() for NFC V1.
drivers/mtd/nand/mxc_nand.c | 92 +-
include/fsl_nfc.h| 72 -
nand_spl/nand_boot_fsl_nfc.c | 47 +++--
3 files changed, 97 insertions(+), 114 deletions(-)
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index d0ded48..045df49 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -150,7 +150,7 @@ static uint32_t *mxc_nand_memcpy32(uint32_t *dest, uint32_t
*source, size_t size
/*
* This function polls the NANDFC to wait for the basic operation to
- * complete by checking the INT bit of config2 register.
+ * complete by checking the INT bit.
*/
static void wait_op_done(struct mxc_nand_host *host, int max_retries,
uint16_t param)
@@ -158,10 +158,10 @@ static void wait_op_done(struct mxc_nand_host *host, int
max_retries,
uint32_t tmp;
while (max_retries-- 0) {
- if (readw(host-regs-config2) NFC_INT) {
- tmp = readw(host-regs-config2);
- tmp = ~NFC_INT;
- writew(tmp, host-regs-config2);
+ tmp = readnfc(host-regs-config2);
+ if (tmp NFC_V1_V2_CONFIG2_INT) {
+ tmp = ~NFC_V1_V2_CONFIG2_INT;
+ writenfc(tmp, host-regs-config2);
break;
}
udelay(1);
@@ -180,8 +180,8 @@ static void send_cmd(struct mxc_nand_host *host, uint16_t
cmd)
{
MTDDEBUG(MTD_DEBUG_LEVEL3, send_cmd(host, 0x%x)\n, cmd);
- writew(cmd, host-regs-flash_cmd);
- writew(NFC_CMD, host-regs-config2);
+ writenfc(cmd, host-regs-flash_cmd);
+ writenfc(NFC_CMD, host-regs-operation);
/* Wait for operation to complete */
wait_op_done(host, TROP_US_DELAY, cmd);
@@ -196,8 +196,8 @@ static void send_addr(struct mxc_nand_host *host, uint16_t
addr)
{
MTDDEBUG(MTD_DEBUG_LEVEL3, send_addr(host, 0x%x)\n, addr);
- writew(addr, host-regs-flash_addr);
- writew(NFC_ADDR, host-regs-config2);
+ writenfc(addr, host-regs-flash_addr);
+ writenfc(NFC_ADDR, host-regs-operation);
/* Wait for operation to complete */
wait_op_done(host, TROP_US_DELAY, addr);
@@ -229,19 +229,19 @@ static void send_prog_page(struct mxc_nand_host *host,
uint8_t buf_id,
}
}
- writew(buf_id, host-regs-buf_addr);
+ writenfc(buf_id, host-regs-buf_addr);
/* Configure spare or page+spare access */
if (!host-pagesize_2k) {
- uint16_t config1 = readw(host-regs-config1);
+ uint16_t config1 = readnfc(host-regs-config1);
if (spare_only)
- config1 |= NFC_SP_EN;
+ config1 |= NFC_CONFIG1_SP_EN;
else
- config1 = ~NFC_SP_EN;
- writew(config1, host-regs-config1);
+ config1 = ~NFC_CONFIG1_SP_EN;
+ writenfc(config1, host-regs-config1);
}
- writew(NFC_INPUT, host-regs-config2);
+ writenfc(NFC_INPUT, host-regs-operation);
/* Wait for operation to complete */
wait_op_done(host, TROP_US_DELAY, spare_only);
@@ -256,19 +256,19 @@ static void send_read_page(struct mxc_nand_host *host,
uint8_t buf_id,
{
MTDDEBUG(MTD_DEBUG_LEVEL3, send_read_page (%d)\n, spare_only);
- writew(buf_id, host-regs-buf_addr);
+ writenfc(buf_id, host-regs-buf_addr);
/* Configure spare or page+spare access */
if (!host-pagesize_2k) {
- uint32_t config1 = readw(host-regs-config1);
+ uint32_t config1 = readnfc(host-regs-config1);
if (spare_only)
- config1 |= NFC_SP_EN;
+ config1 |= NFC_CONFIG1_SP_EN;
else
- config1 = ~NFC_SP_EN;
- writew(config1, host-regs-config1);
+ config1 = ~NFC_CONFIG1_SP_EN;
+ writenfc(config1, host-regs-config1);
}
- writew(NFC_OUTPUT, host-regs-config2);
+ writenfc(NFC_OUTPUT, host-regs-operation);
/* Wait for operation to complete */
wait_op_done(host, TROP_US_DELAY, spare_only);
@@ -296,14 +296,14 @@ static void send_read_id(struct mxc_nand_host *host)
uint16_t tmp;
/* NANDFC buffer 0 is used for device ID output */
- writew(0x0, host-regs-buf_addr);
+ writenfc(0x0,
[U-Boot] [PATCH v3 2/4] nand: mxc: Add support for i.MX5
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3:
- Separate code reformatting from behavioral changes.
Changes in v2: None
arch/arm/include/asm/arch-mx5/imx-regs.h |9 +++
drivers/mtd/nand/mxc_nand.c | 129 +++---
include/fsl_nfc.h| 79 +-
nand_spl/nand_boot_fsl_nfc.c | 67 +++-
4 files changed, 269 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 249d15a..9aa0c6a 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -224,6 +224,15 @@
#define CS0_32M_CS1_32M_CS2_32M_CS3_32M3
/*
+ * SRC register definitions
+ */
+#if defined(CONFIG_MX51)
+#define SRC_SBMR_NF16B (1 2)
+#elif defined(CONFIG_MX53)
+#define SRC_SBMR_NF16B (1 13)
+#endif
+
+/*
* CSPI register definitions
*/
#define MXC_ECSPI
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index 045df49..cead757 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -22,7 +22,8 @@
#include nand.h
#include linux/err.h
#include asm/io.h
-#if defined(CONFIG_MX25) || defined(CONFIG_MX27) || defined(CONFIG_MX35)
+#if defined(CONFIG_MX25) || defined(CONFIG_MX27) || defined(CONFIG_MX35) || \
+ defined(CONFIG_MX51) || defined(CONFIG_MX53)
#include asm/arch/imx-regs.h
#endif
#include fsl_nfc.h
@@ -36,6 +37,9 @@ struct mxc_nand_host {
struct nand_chip*nand;
struct fsl_nfc_regs __iomem *regs;
+#ifdef MXC_NFC_V3_2
+ struct fsl_nfc_ip_regs __iomem *ip_regs;
+#endif
int spare_only;
int status_request;
int pagesize_2k;
@@ -77,7 +81,7 @@ static struct nand_ecclayout nand_hw_eccoob2k = {
.oobfree = { {2, 4}, {11, 11}, {27, 11}, {43, 11}, {59, 5} },
};
#endif
-#elif defined(MXC_NFC_V2_1)
+#elif defined(MXC_NFC_V2_1) || defined(MXC_NFC_V3_2)
#ifndef CONFIG_SYS_NAND_LARGEPAGE
static struct nand_ecclayout nand_hw_eccoob = {
.eccbytes = 9,
@@ -130,6 +134,16 @@ static int is_16bit_nand(void)
else
return 0;
}
+#elif defined(CONFIG_MX51) || defined(CONFIG_MX53)
+static int is_16bit_nand(void)
+{
+ struct src *src = (struct src *)SRC_BASE_ADDR;
+
+ if (readl(src-sbmr) SRC_SBMR_NF16B)
+ return 1;
+ else
+ return 0;
+}
#else
#warning 8/16 bit NAND autodetection not supported
static int is_16bit_nand(void)
@@ -158,10 +172,17 @@ static void wait_op_done(struct mxc_nand_host *host, int
max_retries,
uint32_t tmp;
while (max_retries-- 0) {
+#if defined(MXC_NFC_V1) || defined(MXC_NFC_V2_1)
tmp = readnfc(host-regs-config2);
if (tmp NFC_V1_V2_CONFIG2_INT) {
tmp = ~NFC_V1_V2_CONFIG2_INT;
writenfc(tmp, host-regs-config2);
+#elif defined(MXC_NFC_V3_2)
+ tmp = readnfc(host-ip_regs-ipc);
+ if (tmp NFC_V3_IPC_INT) {
+ tmp = ~NFC_V3_IPC_INT;
+ writenfc(tmp, host-ip_regs-ipc);
+#endif
break;
}
udelay(1);
@@ -213,7 +234,7 @@ static void send_prog_page(struct mxc_nand_host *host,
uint8_t buf_id,
if (spare_only)
MTDDEBUG(MTD_DEBUG_LEVEL1, send_prog_page (%d)\n, spare_only);
- if (is_mxc_nfc_21()) {
+ if (is_mxc_nfc_21() || is_mxc_nfc_32()) {
int i;
/*
* The controller copies the 64 bytes of spare data from
@@ -229,11 +250,18 @@ static void send_prog_page(struct mxc_nand_host *host,
uint8_t buf_id,
}
}
+#if defined(MXC_NFC_V1) || defined(MXC_NFC_V2_1)
writenfc(buf_id, host-regs-buf_addr);
+#elif defined(MXC_NFC_V3_2)
+ uint32_t tmp = readnfc(host-regs-config1);
+ tmp = ~NFC_V3_CONFIG1_RBA_MASK;
+ tmp |= NFC_V3_CONFIG1_RBA(buf_id);
+ writenfc(tmp, host-regs-config1);
+#endif
/* Configure spare or page+spare access */
if (!host-pagesize_2k) {
- uint16_t config1 = readnfc(host-regs-config1);
+ uint32_t config1 = readnfc(host-regs-config1);
if (spare_only)
config1 |= NFC_CONFIG1_SP_EN;
else
@@ -256,7 +284,14 @@ static void send_read_page(struct mxc_nand_host *host,
uint8_t buf_id,
{
MTDDEBUG(MTD_DEBUG_LEVEL3, send_read_page (%d)\n, spare_only);
+#if defined(MXC_NFC_V1) || defined(MXC_NFC_V2_1)
writenfc(buf_id, host-regs-buf_addr);
+#elif defined(MXC_NFC_V3_2)
+ uint32_t tmp = readnfc(host-regs-config1);
+ tmp = ~NFC_V3_CONFIG1_RBA_MASK;
+ tmp |= NFC_V3_CONFIG1_RBA(buf_id);
+
[U-Boot] [PATCH v3 4/4] imx: mx53ard: Add support for NAND Flash
Add support for the Samsung K9LAG08U0M NAND Flash (2-GiB MLC NAND Flash, 2-kiB
pages, 256-kiB blocks, 30-ns R/W cycles, 1 CS) on mx53ard.
eNFC_CLK_ROOT is set up with a cycle time of 37.5 ns (400 MHz / 3 / 5) for this
board, which satisfies the 30-ns NF R/W cycle requirement.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3:
- New patch.
Changes in v2: None
board/freescale/mx53ard/mx53ard.c | 18 ++
include/configs/mx53ard.h | 10 ++
2 files changed, 28 insertions(+)
diff --git a/board/freescale/mx53ard/mx53ard.c
b/board/freescale/mx53ard/mx53ard.c
index 2fc8570..8907388 100644
--- a/board/freescale/mx53ard/mx53ard.c
+++ b/board/freescale/mx53ard/mx53ard.c
@@ -58,6 +58,23 @@ void dram_init_banksize(void)
gd-bd-bi_dram[1].size = PHYS_SDRAM_2_SIZE;
}
+#ifdef CONFIG_NAND_MXC
+static void setup_iomux_nand(void)
+{
+ mxc_request_iomux(MX53_PIN_NANDF_CLE, IOMUX_CONFIG_ALT0);
+ mxc_request_iomux(MX53_PIN_NANDF_ALE, IOMUX_CONFIG_ALT0);
+ mxc_request_iomux(MX53_PIN_NANDF_CS0, IOMUX_CONFIG_ALT0);
+ mxc_request_iomux(MX53_PIN_NANDF_RE_B, IOMUX_CONFIG_ALT0);
+ mxc_request_iomux(MX53_PIN_NANDF_WE_B, IOMUX_CONFIG_ALT0);
+ mxc_request_iomux(MX53_PIN_NANDF_WP_B, IOMUX_CONFIG_ALT0);
+ mxc_request_iomux(MX53_PIN_NANDF_RB0, IOMUX_CONFIG_ALT0);
+}
+#else
+static void setup_iomux_nand(void)
+{
+}
+#endif
+
static void setup_iomux_uart(void)
{
/* UART1 RXD */
@@ -277,6 +294,7 @@ static void weim_cs1_settings(void)
int board_early_init_f(void)
{
+ setup_iomux_nand();
setup_iomux_uart();
return 0;
}
diff --git a/include/configs/mx53ard.h b/include/configs/mx53ard.h
index 62cb42b..148f7a2 100644
--- a/include/configs/mx53ard.h
+++ b/include/configs/mx53ard.h
@@ -41,6 +41,16 @@
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_MXC_GPIO
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#define CONFIG_SYS_NAND_BASE NFC_BASE_ADDR_AXI
+#define CONFIG_NAND_MXC
+#define CONFIG_MXC_NAND_REGS_BASE NFC_BASE_ADDR_AXI
+#define CONFIG_MXC_NAND_IP_REGS_BASE NFC_BASE_ADDR
+#define CONFIG_SYS_NAND_LARGEPAGE
+#define CONFIG_MXC_NAND_HWECC
+#define CONFIG_SYS_NAND_USE_FLASH_BBT
+#define CONFIG_CMD_NAND
+
#define CONFIG_MXC_UART
#define CONFIG_MXC_UART_BASE UART1_BASE
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMCdriverforall T20 boards
Marc,
On Tue, Feb 5, 2013 at 1:54 PM, Marc Dietrich marvi...@gmx.de wrote:
Tom,
On Tuesday 05 February 2013 13:41:21 Tom Warren wrote:
Marc,
On Tue, Feb 5, 2013 at 1:06 PM, Marc Dietrich marvi...@gmx.de wrote:
On Tuesday 05 February 2013 08:31:03 Tom Warren wrote:
Marc,
On Tue, Feb 5, 2013 at 2:28 AM, Marc Dietrich marvi...@gmx.de wrote:
[...]
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
This looks wrong because the sd is on sdmmc0
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
and the emmc on sdmmc3. The DTS is correct.
Not your fault as it seems to be wrong in the original code already.
I guess it didn't made large difference but may in the future. I wonder
how to test this though.
Marc
OK, so just the comments are wrong in paz00.c - I can fix that if I
have to do a V2 patchset, or when I apply the patches to u-boot-tegra.
ah no, this is weird!
index 3 maps to sdmmc1
index 2 maps to sdmmc2
index 1 maps to sdmmc3
index 0 maps to sdmmc4
so all is fine, nearly ...
As to testing, just stop at the command prompt and select each device
(mmc dev 0, etc.) and run mmcinfo. You should be able to tell from the
data displayed whether you are on an SD-card or eMMC chip. You can
also eject the SD-card and you should get a warning about card
presence due to the CD GPIO.
the sd card is not detected because:
TEGRA20
Board: Compal Paz00
DRAM: 512 MiB
MMC: tegra_get_setup: dev_index = 0
tegra_get_setup: count of nodes is 2
tegra_get_setup: found controller at c8000600, width = 8, periph_id = 15
tegra_mmc_init: index 0, bus width 8 pwr_gpio -1 cd_gpio -1
tegra_mmc_init: bus width = 8
tegra_get_setup: dev_index = 3
tegra_get_setup: count of nodes is 2
tegra_get_setup: device index 3 exceeds node count (2)!
If I understand correctly, you are counting the aliases only, not the
controllers..., so index 3 (the sdcard) is not initialized at all. Arrr,
debugging stole all of my time, but I guess this needs fixing.
Yep, I am checking the aliases to get a node count (just like the
Tegra SPI, SLINK, and I2C drivers, and the Exynos SPI and S3C I2C
drivers).
I left the Paz00 tegra_mmc_init(3) call the same as originally (w/o
the width and GPIO params, of course). The device numbering is kind of
arbitrary - if there are only 2 MMC devices present, I'd expect dev 0
to be eMMC and dev 1 to be SD (again, like my T20 reference board,
Seaboard). I don't see that Paz uses mmc anywhere in its config files
for a boot script - does it have to have mmc dev 3 be SD? or would dev
1 work? Note that the tegra20-common-post.h file that all T20 boards
inherit uses dev 0 and dev 1.
U-boot scans all devices during boot, so no need to specify a specific one. I
think what Stephen is suggesting is the right way. Forget all this dev ids and
let the device tree control everything. The aliases can be used for enumbering
if someone really needs it.
Yeah, I just now realized the the tegra_mmc driver used this code to
assign base addresses to dev IDs:
switch (dev_index) {
case 1:
host-base = TEGRA_SDMMC3_BASE;
host-mmc_id = PERIPH_ID_SDMMC3;
break;
case 2:
host-base = TEGRA_SDMMC2_BASE;
host-mmc_id = PERIPH_ID_SDMMC2;
break;
case 3:
host-base = TEGRA_SDMMC1_BASE;
host-mmc_id = PERIPH_ID_SDMMC1;
break;
case 0:
default:
host-base = TEGRA_SDMMC4_BASE;
host-mmc_id = PERIPH_ID_SDMMC4;
break;
}
which puts SDMMC4 at dev 0 (eMMC, I knew that) and the other 3
(usually SDIO) in reverse order, SDMMC1 = dev 3, etc. I didn't know
that.
As you say, letting the DT control it all, with only a single
'mmc_init' call from the board file is the way to go. I'll redo and
submit a V2 later in the week.
Thanks again!
Let me look into it - wish I had
[U-Boot] [PATCH v2 0/3] USB SPL support for AM33xx / am335x_evm
Hey all, The following is a slight update to Ilya's previous series for USB SPL on am33xx platforms. The changes are that I've dropped two patches needed to force usage on older platforms (where a ROM bug prevents USB from being usable in ROM, so we had to feed SPL via UART, then feed U-Boot via USB, which is useful for proof of concept) and a change to make usb_ether determine the MAC to use, and follow the ROMs behavior here. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] am33xx: support for booting via usbeth
From: Ilya Yanok ilya.ya...@cogentembedded.com This patch adds BOOT_DEVICE define for USB booting and fixes spl_board_init function to call arch_misc_init (this is the place there musb is initialized). Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com --- arch/arm/cpu/armv7/omap-common/boot-common.c |3 +++ arch/arm/include/asm/arch-am33xx/spl.h |1 + 2 files changed, 4 insertions(+) diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c b/arch/arm/cpu/armv7/omap-common/boot-common.c index 2b584e0..1c8b617 100644 --- a/arch/arm/cpu/armv7/omap-common/boot-common.c +++ b/arch/arm/cpu/armv7/omap-common/boot-common.c @@ -55,6 +55,9 @@ void spl_board_init(void) #ifdef CONFIG_SPL_NAND_SUPPORT gpmc_init(); #endif +#if defined(CONFIG_AM33XX) defined(CONFIG_SPL_MUSB_NEW_SUPPORT) + arch_misc_init(); +#endif } int board_mmc_init(bd_t *bis) diff --git a/arch/arm/include/asm/arch-am33xx/spl.h b/arch/arm/include/asm/arch-am33xx/spl.h index 644ff35..e961ce0 100644 --- a/arch/arm/include/asm/arch-am33xx/spl.h +++ b/arch/arm/include/asm/arch-am33xx/spl.h @@ -29,6 +29,7 @@ #define BOOT_DEVICE_MMC2 9 /* eMMC or daughter card */ #define BOOT_DEVICE_SPI11 #define BOOT_DEVICE_UART 65 +#define BOOT_DEVICE_USBETH 68 #define BOOT_DEVICE_CPGMAC 70 #define BOOT_DEVICE_MMC2_2 0xFF #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] spl: support for booting via usbeth
From: Ilya Yanok ilya.ya...@cogentembedded.com In case of usbeth booting just call net_load_image(usb_ether). This patch also adds CONFIG_SPL_USBETH_SUPPORT and CONFIG_SPL_MUSB_NEW_SUPPORT config options to enable linking of SPL against USB gagdet support and new MUSB driver resp. Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com --- common/spl/spl.c |5 + spl/Makefile |2 ++ 2 files changed, 7 insertions(+) diff --git a/common/spl/spl.c b/common/spl/spl.c index ff9ba7b..6a5a136 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -221,6 +221,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2) #endif break; #endif +#ifdef CONFIG_SPL_USBETH_SUPPORT + case BOOT_DEVICE_USBETH: + spl_net_load_image(usb_ether); + break; +#endif default: debug(SPL: Un-supported Boot Device\n); hang(); diff --git a/spl/Makefile b/spl/Makefile index 6dbb105..cde 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -81,6 +81,8 @@ LIBS-$(CONFIG_SPL_POST_MEM_SUPPORT) += post/drivers/memory.o LIBS-$(CONFIG_SPL_NET_SUPPORT) += net/libnet.o LIBS-$(CONFIG_SPL_ETH_SUPPORT) += drivers/net/libnet.o LIBS-$(CONFIG_SPL_ETH_SUPPORT) += drivers/net/phy/libphy.o +LIBS-$(CONFIG_SPL_MUSB_NEW_SUPPORT) += drivers/usb/musb-new/libusb_musb-new.o +LIBS-$(CONFIG_SPL_USBETH_SUPPORT) += drivers/usb/gadget/libusb_gadget.o ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX),) LIBS-y += $(CPUDIR)/omap-common/libomap-common.o -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] am335x_evm: enable support for booting via USB
From: Ilya Yanok ilya.ya...@cogentembedded.com
This adds necessary config options and a new build target,
am335x_evm_usbspl, to enable usb booting and fixes board_eth_init()
function to take into account that we may have USB ether support in SPL
now. This uses the same MAC for both cpsw and USB, in order to match
ROM behavior.
The usbspl build target does not contain UART SPL, CPSW SPL or extra
environment settings, so that we may fit within our binary size
constraint.
--
v2: Set usb eth MAC to E-Fuse first MAC to match ROM, add
am335x_evm_usbspl build target. - trini
Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com
Signed-off-by: Tom Rini tr...@ti.com
---
board/ti/am335x/board.c | 38 +-
boards.cfg |1 +
include/configs/am335x_evm.h | 14 ++
3 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index ed4229e..bced870 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -343,7 +343,8 @@ int board_late_init(void)
}
#endif
-#ifdef CONFIG_DRIVER_TI_CPSW
+#if (defined(CONFIG_DRIVER_TI_CPSW) !defined(CONFIG_SPL_BUILD)) || \
+ (defined(CONFIG_SPL_ETH_SUPPORT) defined(CONFIG_SPL_BUILD))
static void cpsw_control(int enabled)
{
/* VTP can be added here */
@@ -388,26 +389,26 @@ static struct cpsw_platform_data cpsw_data = {
int board_eth_init(bd_t *bis)
{
int rv, n = 0;
-#ifdef CONFIG_DRIVER_TI_CPSW
uint8_t mac_addr[6];
uint32_t mac_hi, mac_lo;
- if (!eth_getenv_enetaddr(ethaddr, mac_addr)) {
- debug(ethaddr not set. Reading from E-fuse\n);
- /* try reading mac address from efuse */
- mac_lo = readl(cdev-macid0l);
- mac_hi = readl(cdev-macid0h);
- mac_addr[0] = mac_hi 0xFF;
- mac_addr[1] = (mac_hi 0xFF00) 8;
- mac_addr[2] = (mac_hi 0xFF) 16;
- mac_addr[3] = (mac_hi 0xFF00) 24;
- mac_addr[4] = mac_lo 0xFF;
- mac_addr[5] = (mac_lo 0xFF00) 8;
+ /* try reading mac address from efuse */
+ mac_lo = readl(cdev-macid0l);
+ mac_hi = readl(cdev-macid0h);
+ mac_addr[0] = mac_hi 0xFF;
+ mac_addr[1] = (mac_hi 0xFF00) 8;
+ mac_addr[2] = (mac_hi 0xFF) 16;
+ mac_addr[3] = (mac_hi 0xFF00) 24;
+ mac_addr[4] = mac_lo 0xFF;
+ mac_addr[5] = (mac_lo 0xFF00) 8;
+
+#if (defined(CONFIG_DRIVER_TI_CPSW) !defined(CONFIG_SPL_BUILD)) || \
+ (defined(CONFIG_SPL_ETH_SUPPORT) defined(CONFIG_SPL_BUILD))
+ if (!getenv(ethaddr)) {
+ printf(ethaddr not set. Validating first E-fuse MAC\n);
if (is_valid_ether_addr(mac_addr))
eth_setenv_enetaddr(ethaddr, mac_addr);
- else
- goto try_usbether;
}
if (board_is_bone() || board_is_bone_lt() || board_is_idk()) {
@@ -426,8 +427,11 @@ int board_eth_init(bd_t *bis)
else
n += rv;
#endif
-try_usbether:
-#if defined(CONFIG_USB_ETHER) !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_USB_ETHER) \
+ (!defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_USBETH_SUPPORT))
+ if (is_valid_ether_addr(mac_addr))
+ eth_setenv_enetaddr(usbnet_devaddr, mac_addr);
+
rv = usb_eth_initialize(bis);
if (rv 0)
printf(Error %d registering USB_ETHER\n, rv);
diff --git a/boards.cfg b/boards.cfg
index 98f7a14..a50a8a4 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -236,6 +236,7 @@ am335x_evm_uart2 arm armv7 am335x
ti
am335x_evm_uart3 arm armv7 am335x ti
am33xx am335x_evm:SERIAL4,CONS_INDEX=4
am335x_evm_uart4 arm armv7 am335x ti
am33xx am335x_evm:SERIAL5,CONS_INDEX=5
am335x_evm_uart5 arm armv7 am335x ti
am33xx am335x_evm:SERIAL6,CONS_INDEX=6
+am335x_evm_usbsplarm armv7 am335x ti
am33xx am335x_evm:SERIAL1,CONS_INDEX=1,SPL_USBETH_SUPPORT
highbank arm armv7 highbank-
highbank
mx51_efikamx arm armv7 mx51_efikamx
genesi mx5
mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKAMX,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_mx.cfg
mx51_efikasb arm armv7 mx51_efikamx
genesi mx5
mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKASB,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_sb.cfg
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 72459d8..9585c59 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -238,6 +238,7 @@
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
On 02/05/2013 02:02 PM, Tom Warren wrote:
Stephen,
On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/04/2013 04:48 PM, Tom Warren wrote:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
...
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
...
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
...
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
That doesn't look right. The board code still has knowledge of which
SDHCI controllers are in use by the board. Instead, the board should
just call tegra_mmc_init() with no parameters at all, and the MMC driver
should scan the device tree for all present-and-enabled SDHCI nodes, and
instantiate a U-Boot SDHCI device. Without this, the device tree isn't
in control of the whole process, so there's little point doing the
conversion; a new board couldn't be supported /just/ by creating a new
device tree file.
...
static void tegra_get_setup(struct mmc_host *host, int dev_index)
...
+ int count, node = 0;
+ int node_list[MAX_HOSTS];
+
+ count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
+ COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
+ debug(%s: count of nodes is %d\n, __func__, count);
+
+ if (count dev_index) {
+ printf(%s: device index %d exceeds node count (%d)!\n,
+ __func__, dev_index, count);
+ return;
+ }
This requires that an alias exist in order for the SDHCI node to be
found/processed. This isn't correct; the SDHCI nodes must be enumerated
themselves, and then the aliases (if any are present) provide a naming
hint for them, but even without aliases, the SDHCI nodes must be processed.
Again, I used Allen's SLINK driver for as a template here. In fact, it
looks like our I2C and SPI/SLINK drivers do this, as well as the
Exynos SPI and S3C24x0 I2C driver all do this. Can you point out a
U-Boot driver that does it the right way (preferably with more than 1
node, like MMC)? I can take a look at that code to use as an example
of what you're proposing above.
Tegra's I2C driver has just a single i2c_init_board() function, which
calls fdtdec_find_aliases_for_id() to find all the DT nodes for a given
compatible value (and associated aliases if there are any, I believe),
then calls process_nodes() to loop over them all, and
initialize/register them.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PPC405 with XMD boot
Rommel, I am using your recently posted patch to boot my custom Virtex4 board with XMD. Execution gets stuck in the NS16550_init() function. It gets stuck at this line: #if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT)) while (!(serial_in(com_port-lsr) UART_LSR_TEMT)) ; #endif If I define CONFIG_SYS_NS16550_BROKEN_TEMT, it gets stuck in the while loop in NS16550_putc: while ((serial_in(com_port-lsr) UART_LSR_THRE) == 0) ; serial_out(c, com_port-thr); From the GDB output, I can see it is using the correct address for the the serial port (0x8400) (gdb) target remote localhost:1234 Remote debugging using localhost:1234 NS16550_putc (com_port=0x8400, c=13 '\r') at ns16550.c:91 91while ((serial_in(com_port-lsr) UART_LSR_THRE) == 0) (gdb) In your opinion, is your patch providing everything that I need to boot with XMD? Can you suggest what I might be doing wrong? Thanks for any insight you may have, Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please Ignore: email client test
Dear Gray Remlin, You will NOT wrap long lines under any circumstances unless I tell you to, no matter what the line length is, because I know my intent better than you. Here are tabs because I want tabs. When I want spaces I will used them, and expect them to be where I put them. Finally, if you encapsulate this as a multipart\mime, I will rip out your bytes and nibble them into little bits, you dumb email client. You can play around here [1]. [1] http://lists.denx.de/mailman/listinfo/test Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3 V2] EXYNOS5: Add gpio pin numbering feature
Hi Rajeshwari,
On Sun, Feb 3, 2013 at 10:26 PM, Rajeshwari Birje
rajeshwari.bi...@gmail.com wrote:
Hi Simon,
Thank you for comments
On Sun, Jan 27, 2013 at 1:22 AM, Simon Glass s...@chromium.org wrote:
Hi,
On Wed, Jan 23, 2013 at 2:48 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch adds support for gpio pin numbering support on EXYNOS5
pinmux.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- none.
arch/arm/cpu/armv7/exynos/pinmux.c | 148 +
arch/arm/include/asm/arch-exynos/gpio.h | 360
++-
2 files changed, 413 insertions(+), 95 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
b/arch/arm/include/asm/arch-exynos/gpio.h
index cfe1024..af882dd 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -272,15 +272,355 @@ void s5p_gpio_set_rate(struct s5p_gpio_bank *bank,
int gpio, int mode);
- EXYNOS5_GPIO_PART3_BASE) / sizeof(struct s5p_gpio_bank)) \
* GPIO_PER_BANK) + pin) + EXYNOS5_GPIO_PART2_MAX)
+/* A list of valid GPIO numbers for the asm-generic/gpio.h interface */
+enum exynos5_gpio_pin {
+ /* GPIO_PART1_STARTS */
+ GPIO_A00,
+ GPIO_A01,
+ GPIO_A02,
+ GPIO_A03,
[snip]
+ GPIO_V44,
+ GPIO_V45,
+ GPIO_V46,
+ GPIO_V47,
+
+ /* GPIO_PART4_STARTS */
+ GPIO_PART3_MAX,
+ GPIO_Z0 = GPIO_PART3_MAX,
+ GPIO_Z1,
+ GPIO_Z2,
+ GPIO_Z3,
+ GPIO_Z4,
+ GPIO_Z5,
+ GPIO_Z6,
+ GPIO_MAX_PORT
+};
+
static inline unsigned int s5p_gpio_base(int nr)
{
if (cpu_is_exynos5()) {
- if (nr EXYNOS5_GPIO_PART1_MAX)
+ if (nr GPIO_PART1_MAX)
return EXYNOS5_GPIO_PART1_BASE;
- else if (nr EXYNOS5_GPIO_PART2_MAX)
+ else if (nr GPIO_PART2_MAX)
return EXYNOS5_GPIO_PART2_BASE;
- else
+ else if (nr GPIO_PART3_MAX)
return EXYNOS5_GPIO_PART3_BASE;
+ else
+ return EXYNOS5_GPIO_PART4_BASE;
} else if (cpu_is_exynos4()) {
if (nr EXYNOS4_GPIO_PART1_MAX)
@@ -295,12 +635,14 @@ static inline unsigned int s5p_gpio_base(int nr)
static inline unsigned int s5p_gpio_part_max(int nr)
{
if (cpu_is_exynos5()) {
- if (nr EXYNOS5_GPIO_PART1_MAX)
+ if (nr GPIO_PART1_MAX)
return 0;
- else if (nr EXYNOS5_GPIO_PART2_MAX)
- return EXYNOS5_GPIO_PART1_MAX;
+ else if (nr GPIO_PART2_MAX)
+ return GPIO_PART1_MAX;
+ else if (nr GPIO_PART3_MAX)
+ return GPIO_PART2_MAX;
else
- return EXYNOS5_GPIO_PART2_MAX;
+ return GPIO_PART3_MAX;
} else if (cpu_is_exynos4()) {
if (nr EXYNOS4_GPIO_PART1_MAX)
@@ -311,6 +653,10 @@ static inline unsigned int s5p_gpio_part_max(int nr)
return 0;
}
Do these functions need to be inline in the header file, or could they
move to the GPIO driver?
We use a generic GPIO driver across S5P platform and these changes
being specific to EXYNOS it would not be good to move them to driver.
OK.
+
+void gpio_cfg_pin(int gpio, int cfg);
+void gpio_set_pull(int gpio, int mode);
+void gpio_set_drv(int gpio, int mode);
#endif
/* Pin configurations */
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Regards,
Rajeshwari Shinde
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 V2] EXYNOS5: GPIO: Enable GPIO Command for EXYNOS5
Hi Rajeshwari,
On Sun, Feb 3, 2013 at 10:35 PM, Rajeshwari Birje
rajeshwari.bi...@gmail.com wrote:
Hi Simon,
Thank you for comments.
On Sun, Jan 27, 2013 at 1:29 AM, Simon Glass s...@chromium.org wrote:
Hi Rajeshwari,
On Wed, Jan 23, 2013 at 2:48 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch enables GPIO Command for EXYNOS5.
Function has been added to asm/gpio.h to decode the
input gpio name to gpio number.
example: gpio set gpa00
GPIO_INPUT in cmd_gpio.c has been modified to
GPIO_DIRECTION_INPUT as GPIO_INPUT is alraedy defined in
exynos5 and leading to a error.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Great to see this - some comments below.
---
Chnages in V2:
- New patch
arch/arm/include/asm/arch-exynos/gpio.h | 88
+++
common/cmd_gpio.c |6 +-
include/configs/exynos5250-dt.h |1 +
3 files changed, 92 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
b/arch/arm/include/asm/arch-exynos/gpio.h
index af882dd..66e4a8e 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -657,6 +657,94 @@ static inline unsigned int s5p_gpio_part_max(int nr)
void gpio_cfg_pin(int gpio, int cfg);
void gpio_set_pull(int gpio, int mode);
void gpio_set_drv(int gpio, int mode);
+
+#include common.h
+
+static inline int name_to_gpio(const char *name)
+{
+ int num;
+
+ name++;
+
+ if (*name == 'p') {
+ ++name;
+
+ switch (*name) {
+ case 'a':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_A00 + num;
+ break;
+ case 'b':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_B00 + num;
+ break;
+ case 'c':
+ name++;
+ num = simple_strtoul(name, NULL, 10);
+ if (num = 40)
+ num = GPIO_C40 + (num - 40);
+ else {
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_C00 + num;
+ }
+ break;
+ case 'd':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_D00 + num;
+ break;
+ case 'y':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_Y00 + num;
+ break;
+ case 'x':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_X00 + num;
+ break;
+ case 'e':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_E00 + num;
+ break;
+ case 'f':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_F00 + num;
+ break;
+ case 'g':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_G00 + num;
+ break;
+ case 'h':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_H00 + num;
+ break;
+ case 'v':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_V00 + num;
+ break;
+ case 'z':
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = GPIO_Z0 + num;
+ break;
+ default:
It seems like you need a table (C struct) containing the GPIO letter
and the associated GPIO_... value. Then this code could become a for()
loop to search for the match. This would reduce code duplication. 'c'
would presumable still be a special case.
-Okay
+ return -1;
+ }
+ } else
+ return -1;
+
+ return num;
+}
+
+#define name_to_gpio(n) name_to_gpio(n)
#endif
/* Pin configurations */
diff --git a/common/cmd_gpio.c b/common/cmd_gpio.c
index 47eee89..450e6d1 100644
--- a/common/cmd_gpio.c
+++ b/common/cmd_gpio.c
@@ -16,7 +16,7 @@
#endif
enum gpio_cmd {
- GPIO_INPUT,
+ GPIO_DIRECTION_INPUT,
Re: [U-Boot] changing bootcmd environment
Thanks Scott for your valuable feedback suggestion. I am using the board which is uses SD Card boot NAND boot options,SD CARD boot is used to write firmware to be NAND flash and used only to update the firmware to NAND. MOVI command may be added by the board vendor to support SD CARD boot,curently I am having to work around by updating the config file and recompiling the u-boot code. Ratheendran On Tue, Feb 5, 2013 at 11:10 PM, Scott Wood scottw...@freescale.com wrote: On 02/04/2013 10:54:52 PM, Ratheendran R wrote: Dear All, I am using u-boot given by our Samsung based s3c2416 board vendor which support SD CARD based boot,I am trying to change the boot command variable adding few more steps to it from the serial console. The problem is I am not able to add all the steps to the bootcmd variable into the environment,it is truncated midway.so can any one share your valuable experience in fixing this issue. I am trying the below command.. setenv bootcmd sleep 1;nand scrub ;sleep 1;nand erase;sleep 1;movi read 380# 4 c000 ;sleep 1;nand write c000 0 4;sleep 1;movi read kernel c000;sleep 1;nand write c000 4 20;sleep 1;movi read 360# 380 c000 ;sleep 1; nand write.yaffs c000 40 35db4c0; sleep1; movi read 360# 380 c000; nand write.yaffs c000 600 35db4c0 Using nand scrub in this manner is totally wrong. Even without scrubbing, erasing and rewriting NAND on each boot is not a good idea. It also indicates you're using an old U-Boot, as for a while now full-chip erase commands have to be written as nand erase.chip. Plus I don't see a movi command in mainline U-Boot. Maybe you should be asking your board vendor for support? Why do you need all those sleep commands? You could shorten your bootcmd quite a bit by removing them... -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
Hi,
On Tue, Feb 5, 2013 at 12:49 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/05/2013 01:29 PM, Tom Warren wrote:
Stephen,
On Tue, Feb 5, 2013 at 12:54 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 02/04/2013 04:48 PM, Tom Warren wrote:
Linux dts files were used for those boards that didn't already
have sdhci info populated. If a cd-gpio was present, I set
removable = 1, else removable = 0.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
sdhci@c8000200 {
compatible = nvidia,tegra20-sdhci;
reg = 0xc8000200 0x200;
interrupts = 47 ;
+ status = disabled;
+ /* PERIPH_ID_SDMMC2, PLLP_OUT? */
+ clocks = tegra_car 9;
};
What does PLLP_OUT? mean?
The clock source used for this periph. I removed it in the I2C DT
files - I'll remove it here, too, because it's up to the driver to
choose that based on the freq.
I'm not entirely convinced it's a good idea to add this comment, since
it creates a diff between the .dts files in the kernel and U-Boot.
Similarly, the status and clocks properties are in the other order in
the kernel .dts files. It'd be good to be consistent to allow minimal
diffs between them.
I used the kernel DTS files you pointed to in our internal 'Initialize
SDHCI from device tree' bug:
repo git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
branch for-next
linux-next or the Tegra git tree have the latest additions. arm-soc
hopefully will have them merged in the next day or two.
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(whatever the latest tag is there)
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
(for-next)
diff --git a/board/avionic-design/dts/tegra20-medcom-wide.dts
b/board/avionic-design/dts/tegra20-medcom-wide.dts
I suppose that there are no aliases in this file because only one SDHCI
controller is enabled. I wonder if we should add aliases to all .dts
files just to be explicit? Perhaps it's not necessary because this board
really will never ever get another SDHCI controller added (I assume that
any SDHCI controllers the board has are already enabled, although I
wonder about SDIO...), so there doesn't need to be a hint that there
should be an alias added too?
If there was already an alias property in the DT file, then I tried to
be consistent and add one for mmc. But adding aliases to
other-than-NVIDIA boards should be up to the board
maintainer/manufacturer, IMO.
I don't think so; at least with the driver as-is, the code appears not
to work without aliases, so not adding them causes a regression. Even
ignoring that, I don't see why the code-DT conversion patch shouldn't
do this for all boards.
+ sdhci@c8000600 {
In the kernel, this SDHCI node is part of tegra20-tamonten.dtsi, since
its parameters are defined by the carrier board. I think U-Boot .dts
files should match.
Saw that, but I didn't replicate it here because, well, U-Boot's Not
Linux, and IMO each board file (dts) should have its periph nodes
called out explicitly. If they all happen to be exactly the same for
each board, then I think the manufacturer/board maintainer can do that
'optimization' if they wish - they know better than I if they're
coming out with a new board that may differ in its SDHCI properties
(GPIOs, for instance).
No, this has nothing to do with U-Boot vs. Linux. The device tree files
are (should eventually be) standard between the two, and indeed hosted
outside U-Boot. Unrelated, common code is common and should be
represented at a common location. In this case, the vendor for this
particular file has already correctly chosen to put the SDHCI nodes in
the common file, so this needs to be maintained.
The following 3 comments apply to all the .dts files (or at least the
1st and 3rd; not sure about the 2nd):
+ status = okay;
+ /* Parameter 3 bit 0:1=output, 0=input; bit 1:1=high, 0=low
*/
I don't think that comment is particularly useful. While it's true,
duplicating it every single place a GPIO is used seems wasteful. And the
comment is more re: the GPIO binding that anything to do with SDHCI.
Plus, it makes another diff relative to the kernel.
Diffing the DTS files against the kernel isn't really that big a deal
with a decent diff program (kompare, etc.). That GPIO comment is
useful if you need to understand the 3rd param for the pwr-gpios, for
instance (the cd and wp gpios almost always are input/low). And it
only appears once in each DTS file, not in every single place a GPIO
is used.
If there is no diff at all, it's even easier.
The third parameter is already documented in the binding documentation.
+ cd-gpios = gpio 58 0;/* gpio PH2 */
+ wp-gpios = gpio 59 0;/* gpio PH3 */
The kernel appears to have a space before the comment not a TAB, so this
Re: [U-Boot] [PATCH] Exynos5: Add support for USB download boot mode
Hi Simon,
On Tue, Feb 5, 2013 at 2:56 AM, Simon Glass s...@chromium.org wrote:
Hi,
On Mon, Jan 28, 2013 at 2:39 AM, Vivek Gautam gautam.vi...@samsung.com
wrote:
Exynos5250 supports secondary USB device boot mode. If the iROM fails
to download u-boot from the primary boot device (such as SD or eMMC),
it will try to retrieve from the secondary boot device (such as USB).
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Thanks for reviewing.
But please see comment below.
---
NOTE:
- Based on 'master' branch of u-boot-samsung.
- Tested with smdk5250 for usb download mode.
board/samsung/smdk5250/spl_boot.c | 40
+++-
include/configs/exynos5250-dt.h |5
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/board/samsung/smdk5250/spl_boot.c
b/board/samsung/smdk5250/spl_boot.c
index d8f3c1e..c0bcf46 100644
--- a/board/samsung/smdk5250/spl_boot.c
+++ b/board/samsung/smdk5250/spl_boot.c
@@ -32,6 +32,21 @@ enum boot_mode {
};
typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
+ typedef u32 (*usb_copy_func_t)(void);
+
+/*
+ * Set/clear program flow prediction and return the previous state.
+ */
+static int config_branch_prediction(int set_cr_z)
+{
+ unsigned int cr;
+
+ /* System Control Register: 11th bit Z Branch prediction enable */
+ cr = get_cr();
+ set_cr(set_cr_z ? cr | CR_Z : cr ~CR_Z);
+
+ return cr CR_Z;
+}
/*
* Copy U-boot from mmc to RAM:
@@ -41,10 +56,20 @@ enum boot_mode {
void copy_uboot_to_ram(void)
{
spi_copy_func_t spi_copy;
- enum boot_mode bootmode;
+ usb_copy_func_t usb_copy;
+
+ int is_cr_z_set;
+ unsigned int sec_boot_check;
+ enum boot_mode bootmode = BOOT_MODE_OM;
u32 (*copy_bl2)(u32, u32, u32);
- bootmode = readl(EXYNOS5_POWER_BASE) OM_STAT;
+ /* Read iRAM location to check for secondary USB boot mode */
+ sec_boot_check = readl(EXYNOS_IRAM_SECONDARY_BASE);
+ if (sec_boot_check == EXYNOS_USB_SECONDARY_BOOT)
+ bootmode = BOOT_MODE_USB;
+
+ if (bootmode == BOOT_MODE_OM)
+ bootmode = readl(EXYNOS5_POWER_BASE) OM_STAT;
switch (bootmode) {
case BOOT_MODE_SERIAL:
@@ -57,6 +82,17 @@ void copy_uboot_to_ram(void)
copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
CONFIG_SYS_TEXT_BASE);
break;
+ case BOOT_MODE_USB:
+ /*
+* iROM needs program flow prediction to be disabled
+* before copy from USB device to RAM
+*/
+ is_cr_z_set = config_branch_prediction(0);
+ usb_copy = *(usb_copy_func_t *)
+ EXYNOS_COPY_USB_FNPTR_ADDR;
+ usb_copy();
+ config_branch_prediction(is_cr_z_set);
+ break;
default:
break;
}
diff --git a/include/configs/exynos5250-dt.h
b/include/configs/exynos5250-dt.h
index cabd2f2..6728b0e 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -123,6 +123,11 @@
#define CONFIG_USB_EHCI_EXYNOS
#define CONFIG_USB_STORAGE
+/* USB boot mode */
+#define EXYNOS_COPY_USB_FNPTR_ADDR 0x02020070
+#define EXYNOS_USB_SECONDARY_BOOT 0xfeed0002
+#define EXYNOS_IRAM_SECONDARY_BASE 0x02020018
What happened to the function pointer table patch?
I think i missed that patch from Amar, :-(
will remove these #defines and use the function pointer table instead.
+
/* MMC SPL */
#define CONFIG_SPL
#define COPY_BL2_FNPTR_ADDR0x02020030
--
1.7.6.5
--
Thanks Regards
Vivek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/5] ARM: OMAP5: Add silicon id support for ES2.0 revision.
Hi,
On Tuesday 05 February 2013 08:49 PM, Nishanth Menon wrote:
On 18:02-20130205, R Sricharan wrote:
On Tuesday 05 February 2013 01:11 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include/asm/armv7.h |1 +
arch/arm/include/asm/omap_common.h |2 ++
4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index dfc0e44..0d8c95d 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -216,8 +216,17 @@ void init_omap_revision(void)
break;
}
break;
- default:
- *omap_si_rev = OMAP5430_SILICON_ID_INVALID;
+ case MIDR_CORTEX_A15_R2P2:
+ switch (readl(CONTROL_ID_CODE)) {
+ case OMAP5430_CONTROL_ID_CODE_ES2_0:
+ *omap_si_rev = OMAP5430_ES2_0;
+ break;
+ case OMAP5432_CONTROL_ID_CODE_ES2_0:
+ *omap_si_rev = OMAP5432_ES2_0;
+ break;
+ default:
+ *omap_si_rev = OMAP5430_SILICON_ID_INVALID;
+ }
A first few samples of both ES1.0 and ES2.0 (in the few 10s of samples) came
with wrong efuse
ID fused in, why would we want to make it a standard to check ARMsilicon
revision *and then* cross verify against control fuse verification, *and
then* give up saying we dont support it?
Looks like an over check for me - IMHO, we should drop the MIDR checks
entirely.
In the same context, for some boards in past even in the actual samples
the CONTROL ID code was reading the older revision. So in those
cases ARM revision will help to differentiate them.
which boards? Almost as a rule the first few samples on almost all
revisions on production floor had messed up control ID, however, beyond
that, all runs are properly updated.
I have seen this issue on some OMAP4 revisions as well. It was only
after that we introduced this logic of double checking using ARM
revision ID.
But then it should have been in the opposite way, like reading the
CONTROL_CODE first and then reading the ARM revision if required in
those cases where is it broken. I will change this logic here.
Having cortex check is just redundant - IMHO, switching it over might be
better, but dropping it is more inline with expectation of the silicon
spec.
According to me the best way to do it is, use CONTROL_ID first and
then use ARM revision for those which has wrong IDs. This will always
be a fool proof even for those non-working boards.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend] armv7/ltimer: Add support for local timer on armv7 cpus
On 2/3/2013 7:28 PM, Albert ARIBAUD wrote:
Hi Vipin,
On Thu, 6 Dec 2012 14:52:55 +0530, Vipin Kumarvipin.ku...@st.com
wrote:
Certain ARMV7 cpus eg. CortexA9 contains a local and a global timer within the
CPU core itself. This patch adds generic support for local timer.
Signed-off-by: Vipin Kumarvipin.ku...@st.com
---
arch/arm/cpu/armv7/Makefile | 11 ++-
arch/arm/cpu/armv7/ca9_ltimer.c | 152 ++
arch/arm/include/asm/ca9_ltimer.h | 40 ++
3 files changed, 199 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/cpu/armv7/ca9_ltimer.c
create mode 100644 arch/arm/include/asm/ca9_ltimer.h
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 4fdbee4..3ef01f6 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -27,15 +27,18 @@ LIB = $(obj)lib$(CPU).o
START := start.o
-COBJS += cache_v7.o
+COBJS-y+= cache_v7.o
-COBJS += cpu.o
-COBJS += syslib.o
+COBJS-y+= cpu.o
+COBJS-y+= syslib.o
+COBJS-$(CONFIG_ARMV7_CA9LTIMER) += ca9_ltimer.o
ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA20),)
-SOBJS += lowlevel_init.o
+SOBJS-y+= lowlevel_init.o
endif
+COBJS := $(sort $(COBJS-y))
+SOBJS := $(sort $(SOBJS-y))
SRCS := $(START:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
START := $(addprefix $(obj),$(START))
diff --git a/arch/arm/cpu/armv7/ca9_ltimer.c b/arch/arm/cpu/armv7/ca9_ltimer.c
new file mode 100644
index 000..cbf1552
--- /dev/null
+++ b/arch/arm/cpu/armv7/ca9_ltimer.c
@@ -0,0 +1,152 @@
+/*
+ * (C) Copyright 2012
+ * Vipin Kumar, ST Micoelectronics, vipin.ku...@st.com.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#includecommon.h
+#includeasm/io.h
+#includeasm/ca9_ltimer.h
+#includeasm/arch/hardware.h
+
+#define READ_TIMER() readl(ca9_timer_p-count)
+
+static struct ca9_timer_regs *const ca9_timer_p =
+ (struct ca9_timer_regs *)CONFIG_ARMV7_LTIMER_BASE;
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define timestamp gd-tbl
+#define lastdecgd-lastinc
+#define tickshzgd-timer_rate_hz
+#define ticksper10usec gd-tbu
+
+int timer_init(void)
+{
+ u32 prescaler, timertickshz;
+ /*
+* Genrally, CortexA9 MPUs are operating from 500MHz to 1500MHz which
+* means that CA9 local timer clock would be in the range of 250 MHz to
+* 750MHz.
+* Try to find a prescaler which can perfectly divide the local timer
+* clock. Take prescaler as 200 if nothing is found
+*/
+ for (prescaler = 255; prescaler 1; prescaler--) {
+ if (CONFIG_ARMV7_LTMR_CLK ==
+ (CONFIG_ARMV7_LTMR_CLK / prescaler) * prescaler)
+ break;
+ }
+
+ if (prescaler == 1)
+ prescaler = 200;
+ timertickshz = CONFIG_ARMV7_LTMR_CLK / prescaler;
+ ticksper10usec = timertickshz / (100 * 1000);
+ tickshz = timertickshz / CONFIG_SYS_HZ;
+
+ /* disable timers */
+ writel(((prescaler - 1) 8) | AUTO_RELOAD,ca9_timer_p-control);
+
+ /* load value for free running */
+ writel(FREE_RUNNING,ca9_timer_p-load);
+
+ /* auto reload, start timer */
+ setbits_le32(ca9_timer_p-control, TIMER_ENABLE);
+
+ reset_timer_masked();
+
+ return 0;
+}
+
+/*
+ * timer without interrupts
+ */
+
+void reset_timer(void)
+{
+ reset_timer_masked();
+}
+
+ulong get_timer(ulong base)
+{
+ return (get_timer_masked() / tickshz) - base;
+}
+
+void set_timer(ulong t)
+{
+ timestamp = t;
+}
+
+void __udelay(unsigned long usec)
+{
+ ulong tmo;
+ ulong start = get_timer_masked();
+ ulong rndoff;
+
+ rndoff = (usec % 10) ? 1 : 0;
+ tmo = ((usec / 10) + rndoff) * ticksper10usec;
+
+ while ((ulong) (get_timer_masked() - start) tmo);
+}
+
+void reset_timer_masked(void)
+{
+ /* reset time */
+ lastdec = READ_TIMER();
+ timestamp = 0;
+}
+
+ulong get_timer_masked(void)
+{
+ ulong now = READ_TIMER();
+
+ if (now= lastdec) {
+ /* normal mode */
+ timestamp += lastdec - now;
+
Re: [U-Boot] [PATCH V2 3/5] ARM: OMAP5: clocks: Add OPP settings required for OMAP543X ES2.0 soc
On Tuesday 05 February 2013 08:59 PM, Nishanth Menon wrote:
[..]
Answering all of your above questions here.
The above data is for OMAP4 and not OMAP5. This file was modified
here just to include dummy dividers. Because we were now using a
common dpll_params structure, there was no functional change in this
file. I think the problem was commit log was missing this info.
I will update to clarify this.
I dont think updating commit log alone is the right solution - renaming the
variables make more sense - making ones meant for OMAP4 as _omap4430, 60
etc help readability of code.
omap4/hw_data.c has separate arrays to represent 4430, 4460 dplls data.
[...]
/* ABE M N values with 32K clock as source */
static const struct dpll_params abe_dpll_params_32k_196608khz = {
We do not intend to support 32K ABE source except when doing DPLL
cascading - so this is in effect an configuration which is
un-used in any s/w line.
1) In fact we not locking ABE, IVA, USB DPLLs any more in bootloader
unless some one enable a CLOCKS_ENABLE_ALL config.
But we still have there data, so that we can quickly experiment
when needed.
it is no longer supported on OMAP5. If you have doubts on the silicon
usecase specification, I recommend you do read the TI internal
documentation for the same.
2) I remember that locking with 32K source was considered better
because, we can cut sys_clk when audio is still running.
Also i think that the jitter was not a real problem for audio
even when running with 32Khz clock. I have to check this point
again.
please check again.
I even checked the latest version of ES2.0 TRM.
M, N specified are 750, 0. So these are ones used to lock at 32KHZ.
The reason we had both the sources supported was just from an
experiment motive. I have seen that during pre silicon, we have
As a rule, experimentation code should NOT be in mainline. only
recommended operation code should ever be put in mainline - real
products are supposed to ramp with this code.
Yes, by default we have set it to OPP_NOM.
There where many situations where there was a need to boot with
higher OPPs for performance measurements with mainline.
So it was better to change just one variable than to add the full
data for that OPP in those cases. This has helped many times in the
past.
to switch the clock source from default to get locking. So having
support for both helps in those cases.
not if the silicon is neither validated NOR expected to be supported at
this.
[...]
static const struct dpll_params mpu_dpll_params_1_5ghz[NUM_SYS_CLKS] = {
I am not sure we'd like to do this.
This file is common for ES1.0 as well. Also i have added frequency
tables for OPP_HIGH and OPP_LOW as well. We some times find it
nessecary to boot with a different than OPP_NOM to do experiments.
So this is useful from that point. But what is missing is the VDDs
which I usually add manually while testing. But now to complete
this, i will add that as well.
Why? Es1.0 will never be publically released, it never was meant to be
public. ES2.0 is the only one meant to go out. Supporting ES1.0 and
ES2.0 means a ton of redundant code being maintained in mainline with no
product lines meant to actively using it - ever! Do we really want to do
this??
Ok, i will clean up ES1.0 data in a separate patch series after this.
- {125, 0, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
- {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
- {625, 6, 1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
- {625, 7, 1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
- {750, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
- {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
- {625, 15, 1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
+ {125, 0, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
+ {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
+ {625, 6, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
+ {625, 7, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
+ {750, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
+ {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
+ {625, 15, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
};
static const struct dpll_params mpu_dpll_params_2ghz[NUM_SYS_CLKS] = {
again, frequency is wrong for es2.0?
This file is common for ES1.0 as well.
ES1.0 DOES NOT run at 2GHz!
Ok, i will clean up ES1.0 data separately.
- {500, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
- {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
- {2024, 16, 1, -1, -1, -1, -1, -1, -1, -1}, /* 16.8 MHz */
-
