Re: [U-Boot] v2011.12 and later do not boot on dreamplug.
On Sun, 2012-01-08 at 17:54 -0500, Jason wrote:
On Sun, Jan 08, 2012 at 07:49:05PM +, Ian Campbell wrote:
On Sun, 2012-01-08 at 15:30 +, Ian Campbell wrote:
diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index dfe542d..db8ba8b 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -66,7 +66,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
debug(data = 0x%08x \n, data);
writel(KWSPI_SMEMRDIRQ, spireg-irq_cause);
- writel(KWSPI_IRQMASK, spireg-irq_mask);
+ writel(KWSPI_IRQMASK, spireg-irq_mask);
/* program mpp registers to select SPI_CSn */
if (cs) {
--
1.7.5.4
Acked-By: Jason Cooper u-b...@lakedaemon.net
Dammit. My apologies. I should've caught that. Thanks for the patch.
No problem, was interesting to dig into u-boot for the first time!
Did I get the CC list right to cover whoever will eventually apply this
patch?
You are also working on upstreaming dreamplug support into Linux, is
that right? What is the current state of the art? I'm currently using a
3.1 kernel + patches from
http://people.debian.org/~zumbi/dreamplug/patches/ . (BTW feel free to
reply off list or switch to e.g. linux-arm-kernel since I guess this is
strict speaking off-topic here).
Thanks,
Ian.
--
Ian Campbell
Revolution, n.:
A form of government abroad.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] EXYNOS: Add SMDK5250 board support
Dear Chander Kashyap, On 11 January 2012 22:55, Chander Kashyap chander.kash...@linaro.org wrote: SMDK5250 board is based on Samsungs EXYNOS5250 SoC. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- Changes for v2: - This patch is bifurcated into borad support and SoC support - Fixed typo: s/EEYNOS/EXYNOS - Squashed patch SMDK5250: enable device tree support in this. Changes for v3: - None MAINTAINERS | 1 + board/samsung/smdk5250/Makefile | 48 +++ board/samsung/smdk5250/lowlevel_init.S | 528 +++ board/samsung/smdk5250/mem_setup.S | 600 +++ Simon and Wolfgang have been commented to make these files to C. So, What is your plan? board/samsung/smdk5250/smdk5250.c | 125 +++ board/samsung/smdk5250/smdk5250_setup.h | 589 ++ boards.cfg | 1 + include/configs/smdk5250.h | 185 ++ 8 files changed, 2077 insertions(+), 0 deletions(-) create mode 100644 board/samsung/smdk5250/Makefile create mode 100644 board/samsung/smdk5250/lowlevel_init.S create mode 100644 board/samsung/smdk5250/mem_setup.S create mode 100644 board/samsung/smdk5250/smdk5250.c create mode 100644 board/samsung/smdk5250/smdk5250_setup.h create mode 100644 include/configs/smdk5250.h Thanks, Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] EXYNOS: Add SMDK5250 board support
Dear Minkyu kang, On 12 January 2012 14:06, Minkyu Kang proms...@gmail.com wrote: Dear Chander Kashyap, On 11 January 2012 22:55, Chander Kashyap chander.kash...@linaro.org wrote: SMDK5250 board is based on Samsungs EXYNOS5250 SoC. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- Changes for v2: - This patch is bifurcated into borad support and SoC support - Fixed typo: s/EEYNOS/EXYNOS - Squashed patch SMDK5250: enable device tree support in this. Changes for v3: - None MAINTAINERS | 1 + board/samsung/smdk5250/Makefile | 48 +++ board/samsung/smdk5250/lowlevel_init.S | 528 +++ board/samsung/smdk5250/mem_setup.S | 600 +++ Simon and Wolfgang have been commented to make these files to C. So, What is your plan? I am working on it. If possible please merge these patches. As soon as I am finished with converting in to c files I will submit the patches to replace assembly with c files. board/samsung/smdk5250/smdk5250.c | 125 +++ board/samsung/smdk5250/smdk5250_setup.h | 589 ++ boards.cfg | 1 + include/configs/smdk5250.h | 185 ++ 8 files changed, 2077 insertions(+), 0 deletions(-) create mode 100644 board/samsung/smdk5250/Makefile create mode 100644 board/samsung/smdk5250/lowlevel_init.S create mode 100644 board/samsung/smdk5250/mem_setup.S create mode 100644 board/samsung/smdk5250/smdk5250.c create mode 100644 board/samsung/smdk5250/smdk5250_setup.h create mode 100644 include/configs/smdk5250.h Thanks, Minkyu Kang. -- from. prom. www.promsoft.net -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] ARM: EXYNOS: Add support for Exynos5 based SoCs
Dear Chander Kashyap,
On 11 January 2012 22:55, Chander Kashyap chander.kash...@linaro.org wrote:
Samsung's ARM Cortex-A15 based SoCs are known as Exynos5 series of
SoCs. This patch adds the support for Exynos5.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Changes for v2:
- This patch was part of EXYNOS: Add SMDK5250 board support
- Now it is seprated as SoC support.
Changes for v333:
- Populated complete exynos5 gpio structures
arch/arm/cpu/armv7/exynos/clock.c | 209 +++-
arch/arm/include/asm/arch-exynos/clock.h | 326
++
arch/arm/include/asm/arch-exynos/cpu.h | 35 +++-
arch/arm/include/asm/arch-exynos/gpio.h | 101 +-
4 files changed, 658 insertions(+), 13 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
b/arch/arm/include/asm/arch-exynos/cpu.h
index 6d97b99..645336e 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -22,6 +22,8 @@
#ifndef _EXYNOS4_CPU_H
#define _EXYNOS4_CPU_H
+#define DEVICE_NOT_AVAILABLE 0
+
#define EXYNOS4_ADDR_BASE 0x1000
/* EXYNOS4 */
@@ -46,7 +48,34 @@
#define EXYNOS4_ADC_BASE 0x1391
#define EXYNOS4_PWMTIMER_BASE 0x139D
#define EXYNOS4_MODEM_BASE 0x13A0
-#define EXYNOS4_USBPHY_CONTROL 0x10020704
+#define EXYNOS4_USBPHY_CONTROL 0x10020704
+
+#define EXYNOS4_GPIO_PART4_BASE DEVICE_NOT_AVAILABLE
+
+/* EXYNOS5 */
+#define EXYNOS5_GPIO_PART4_BASE 0x0386
+#define EXYNOS5_PRO_ID 0x1000
+#define EXYNOS5_CLOCK_BASE 0x1001
+#define EXYNOS5_POWER_BASE 0x1004
+#define EXYNOS5_SWRESET 0x10040400
+#define EXYNOS5_SYSREG_BASE 0x1005
+#define EXYNOS5_WATCHDOG_BASE 0x101D
+#define EXYNOS5_PHY0_CTRL_BASE 0x10C0
+#define EXYNOS5_PHY1_CTRL_BASE 0x10C1
Please make the name clearly.
EXYNOS5_DMC_PHY0_BASE is better.
+#define EXYNOS5_GPIO_PART3_BASE 0x10D1
+#define EXYNOS5_DMC_CTRL_BASE 0x10DD
+#define EXYNOS5_GPIO_PART1_BASE 0x1140
+#define EXYNOS5_MMC_BASE 0x1220
+#define EXYNOS5_SROMC_BASE 0x1225
+#define EXYNOS5_USBOTG_BASE 0x1248
+#define EXYNOS5_USBPHY_BASE 0x1248
+#define EXYNOS5_UART_BASE 0x12C0
+#define EXYNOS5_PWMTIMER_BASE 0x12DD
+#define EXYNOS5_GPIO_PART2_BASE 0x1340
+#define EXYNOS5_FIMD_BASE 0x1440
+
+#define EXYNOS5_ADC_BASE DEVICE_NOT_AVAILABLE
+#define EXYNOS5_MODEM_BASE DEVICE_NOT_AVAILABLE
#ifndef __ASSEMBLY__
#include asm/io.h
@@ -83,12 +112,15 @@ static inline int cpu_is_##type(void)
\
}
IS_SAMSUNG_TYPE(exynos4, 0xc210)
+IS_SAMSUNG_TYPE(exynos5, 0xc520)
#define SAMSUNG_BASE(device, base) \
static inline unsigned int samsung_get_base_##device(void) \
{ \
if (cpu_is_exynos4()) \
return EXYNOS4_##base; \
+ else if (cpu_is_exynos5()) \
+ return EXYNOS5_##base; \
else \
return 0; \
}
@@ -99,6 +131,7 @@ SAMSUNG_BASE(fimd, FIMD_BASE)
SAMSUNG_BASE(gpio_part1, GPIO_PART1_BASE)
SAMSUNG_BASE(gpio_part2, GPIO_PART2_BASE)
SAMSUNG_BASE(gpio_part3, GPIO_PART3_BASE)
+SAMSUNG_BASE(gpio_part4, GPIO_PART4_BASE)
SAMSUNG_BASE(pro_id, PRO_ID)
SAMSUNG_BASE(mmc, MMC_BASE)
SAMSUNG_BASE(modem, MODEM_BASE)
diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
b/arch/arm/include/asm/arch-exynos/gpio.h
index 9863a12..cdd6255 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
static inline unsigned int s5p_gpio_base(int nr)
{
- if (nr GPIO_PART1_MAX)
- return EXYNOS4_GPIO_PART1_BASE;
+ if (cpu_is_exynos5()) {
+ if (nr EXYNOS5_GPIO_PART1_MAX)
+ return EXYNOS5_GPIO_PART1_BASE;
+ else if (nr EXYNOS5_GPIO_PART2_MAX)
+ return EXYNOS5_GPIO_PART2_BASE;
+ else
+ return EXYNOS5_GPIO_PART3_BASE;
+
+ } else if (cpu_is_exynos4()) {
+ if (nr EXYNOS4_GPIO_PART1_MAX)
+ return EXYNOS4_GPIO_PART1_BASE;
+ else
+ return EXYNOS4_GPIO_PART2_BASE;
+ }
else
- return EXYNOS4_GPIO_PART2_BASE;
-
- return 0;
Re: [U-Boot] [PATCH v2] sdhc_boot: Introduce CONFIG_FSL_FIXED_MMC_LOCATION option
On 11/01/2012 20:20, Fabio Estevam wrote: Since commit 97039ab98 (env_mmc: Allow board code to override the environment address) mmc_get_env_addr is a weak-aliased function in common/env_mmc.c The mmc_get_env_addr implementation that exists at board/freescale/common/sdhc_boot.c is meant to be used only for PowerPC boards, but currently it is being used for all platforms that have CONFIG_ENV_IS_IN_MMC defined. Introduce CONFIG_FSL_FIXED_MMC_LOCATION so that the boards that need to use the mmc_get_env_addr version from board/freescale/common/sdhc_boot.c could activate this config option on their board file. This fixes the retrieval of CONFIG_ENV_OFFSET on non-PowerPC boards. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v1: - Remove unneeded ifdef from board/freescale/common/sdhc_boot.c board/freescale/common/Makefile |2 +- include/configs/MPC8536DS.h |1 + include/configs/P1010RDB.h |1 + include/configs/P1_P2_RDB.h |1 + include/configs/P2020COME.h |1 + include/configs/P2020DS.h |1 + include/configs/P2041RDB.h |1 + include/configs/corenet_ds.h|1 + include/configs/p1_p2_rdb_pc.h |1 + 9 files changed, 9 insertions(+), 1 deletions(-) Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arm, davinci: Add support for the Calimain board from OMICRON electronics
This patch adds support for the Calimain board from OMICRON electronics GmbH. The board features a Texas Instruments AM1808 SoC, 128 MB DDR2 memory, and 64 MB NOR flash memory connected to CS2 and CS3. Signed-off-by: Christian Riesch christian.rie...@omicron.at --- Changes for v2: - Removed CONFIG_NET_MULTI as suggested by Tom Rini - Rebased to apply on top of Sughosh Ganu's patch for the Hawkboard SPL Prerequisites: [U-Boot,2/2,V4] Changes to move hawkboard to the new spl infrastructure http://patchwork.ozlabs.org/patch/135433/ Best regards, Christian MAINTAINERS |5 + board/omicron/calimain/Makefile | 45 + board/omicron/calimain/calimain.c | 188 +++ boards.cfg|1 + include/configs/calimain.h| 363 + 5 files changed, 602 insertions(+), 0 deletions(-) create mode 100644 board/omicron/calimain/Makefile create mode 100644 board/omicron/calimain/calimain.c create mode 100644 include/configs/calimain.h diff --git a/MAINTAINERS b/MAINTAINERS index c79283f..25d7a95 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -792,6 +792,11 @@ Thierry Reding thierry.red...@avionic-design.de plutux Tegra2 (ARM7 A9 Dual Core) medcom Tegra2 (ARM7 A9 Dual Core) +Christian Riesch christian.rie...@omicron.at +Manfred Rudigier manfred.rudig...@omicron.at + + calimainARM926EJS (AM1808 SoC) + Tom Rini tr...@ti.com omap3_evm ARM ARMV7 (OMAP3xx SoC) diff --git a/board/omicron/calimain/Makefile b/board/omicron/calimain/Makefile new file mode 100644 index 000..cd1f0d4 --- /dev/null +++ b/board/omicron/calimain/Makefile @@ -0,0 +1,45 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# Copyright (C) 2007 Sergey Kubushyn k...@koi8.net +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := $(BOARD).o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +# +# This is for $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/omicron/calimain/calimain.c b/board/omicron/calimain/calimain.c new file mode 100644 index 000..97ba74a --- /dev/null +++ b/board/omicron/calimain/calimain.c @@ -0,0 +1,188 @@ +/* + * Copyright (C) 2011 OMICRON electronics GmbH + * + * Based on da850evm.c. Original Copyrights follow: + * + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/ + * Copyright (C) 2009 Nick Thompson, GE Fanuc, Ltd. nick.thomp...@gefanuc.com + * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include common.h +#include i2c.h +#include net.h +#include netdev.h +#include watchdog.h +#include asm/io.h +#include asm/arch/hardware.h +#include asm/arch/gpio.h +#include asm/arch/emif_defs.h +#include asm/arch/emac_defs.h +#include asm/arch/pinmux_defs.h +#include asm/arch/davinci_misc.h +#include asm/arch/timer_defs.h + +DECLARE_GLOBAL_DATA_PTR; + +#define CALIMAIN_HWVERSION_MASK0x7f00 +#define CALIMAIN_HWVERSION_SHIFT 24 + +/* Hardware version pinmux settings */ +const struct pinmux_config
Re: [U-Boot] [PATCH 2/2 V4] Changes to move hawkboard to the new spl infrastructure
Hi Sughosh, On Wed, Jan 11, 2012 at 6:03 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: This patch moves hawkboard to the new spl infrastructure from the older nand_spl one. Removed the hawkboard_nand_config build option -- The spl code now gets compiled with hawkboard_config, after building the main u-boot image, using the CONFIG_SPL_TEXT_BASE. Modified the README.hawkboard to reflect the same. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com Signed-off-by: Heiko Schocher h...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Christian Riesch christian.rie...@omicron.at Cc: Sudhakar Rajashekhara sudhakar@ti.com Cc: Tom Rini tr...@ti.com I have tested this with both the da850evm and the calimain board (see [1]), and the low level initialization still works :-) Therefore Acked-by: Christian Riesch christian.rie...@omicron.at Regards, Christian [1] http://patchwork.ozlabs.org/patch/135593/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
Hi Govindraj,
On 01/12/12 07:45, Govindraj wrote:
Hi Igor,
On Wed, Jan 11, 2012 at 8:33 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
Hi Guys,
On 01/11/12 16:34, Marek Vasut wrote:
On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut marek.va...@gmail.com wrote:
On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut marek.va...@gmail.com
wrote:
On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut marek.va...@gmail.com
wrote:
Hi Marek,
Thanks for you review.
On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut
marek.va...@gmail.com
wrote:
From: Govindraj.R govindraj.r...@ti.com
Clean up added ehci-omap.c and make it generic for re-use
across soc having same ehci ip block. Also pass the modes to
be configured and configure the ports accordingly. All usb
layers are not cache aligned till then keep cache off for usb
ops as ehci will use internally dma for all usb ops.
* Add a generic common header ehci-omap.h having common ip
block data and reg shifts.
* Rename and modify ehci-omap3 to ehci.h retain only
conflicting sysc reg shifts remove others and move to common
header file.
Don't reimplement the ulpi stuff ... there's already some ulpi
stuff in uboot that needs fixing, so fix it and use it.
I am not implementing any ulpi stuff I am just configuring OMAP on
soc usb host controller (ehci). All the configuration stuff
is OMAP specific things which are done in ehci-omap.c file
stuffs done are like soft-reset, port mode to be used and putting
port in no -idle mode(omap specific pm implementation) etc.
This stuff:
+/* ULPI */
+#define ULPI_SET(a)(a + 1)
+#define ULPI_CLR(a)(a + 2)
+#define ULPI_FUNC_CTRL 0x04
+#define ULPI_FUNC_CTRL_RESET (1 5)
is just accidentally conforming to ULPI spec?
These are for configuring INSNREG05_ULPI reg in EHCI reg map
of omap while configuring in ulpi-phy mode.
looking into struct ulpi_regs {..}
then it doesn't map this configuration.
Can you point me to some documentation about this please? It's not
that I don't trust you, I'd rather prefer to avoid unnecessary
duplication.
Yes that would be fine.
You can download the omap4460 public trm from here:
http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip
Go to chapter 23.11.6.6.1 EHCI Register Summary
(page number 5171 and 5186/87)
Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for
that purpose, the struct ulpi_regs is fitting ok.
Actually ... can you check the ulpi_read and ulpi_write stuff that's
already in u-boot and explain why they can not be used with this port?
echi-omap.c is no where writing to those registers
and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map
reg map in 23.11.6.3 used only for a external ulpi-phy communication.
and debug purpose(to view vid, pid etc) and to hack external phy
configuration through ulpi commands
from omap - usb host controller point of view only needs
INSNREG05_ULPI reg in EHCI reg configuration
rest on soc host controller takes care of it.
Can someone else comment on this? I think I don't understand well (as I'm
not
OMAP guy).
Well, it is on my list, actually,
but I will be able to get to it only in a couple of days.
(I'm really busy right now).
Could you please let me know what exactly that you will be
updating?
So that I can accordingly post my v3 of this patch fixing comments
from Marek Vasut marek.va...@gmail.com
Well, I did not say, I'm going to update anything.
What I meant is that I'm going to look into TI's documentation
regarding EHCI and the ULPI to understand the dependencies and see
how your code meets those and if the generic ULPI layer can be used
for that.
So to lower the work load from from you, I'd suggest you to wait
till Monday (if you can of course) to let me look into this.
It is also possible that I will be able to check the above today
or tomorrow, but I can't promise, as I'm really busy now.
Thanks.
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] imximage: Sort bootops alphabetically
Signed-off-by: Dirk Behme dirk.be...@de.bosch.com
CC: Fabio Estevam feste...@gmail.com
CC: Stefano Babic sba...@denx.de
CC: Jason Liu jason@linaro.org
---
Note: This was requested by Wolfgang in
http://www.mail-archive.com/u-boot@lists.denx.de/msg71842.html
tools/imximage.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/imximage.c b/tools/imximage.c
index f3da139..1e0f5d4 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -47,12 +47,12 @@ static table_entry_t imximage_cmds[] = {
* this is needed to set the correct flash offset
*/
static table_entry_t imximage_bootops[] = {
- {FLASH_OFFSET_SPI, spi, SPI Flash,},
- {FLASH_OFFSET_NAND, nand, NAND Flash, },
- {FLASH_OFFSET_SD, sd, SD Card, },
{FLASH_OFFSET_ONENAND, onenand, OneNAND Flash,},
+ {FLASH_OFFSET_NAND, nand, NAND Flash, },
{FLASH_OFFSET_NOR, nor, NOR Flash,},
{FLASH_OFFSET_SATA, sata, SATA Disk,},
+ {FLASH_OFFSET_SD, sd, SD Card, },
+ {FLASH_OFFSET_SPI, spi, SPI Flash,},
{-1,, Invalid, },
};
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] imximage: Add MX53 to the documentation
i.MX53 is supported, too. Add this to the introduction of the documentation. Signed-off-by: Dirk Behme dirk.be...@de.bosch.com CC: Fabio Estevam feste...@gmail.com CC: Stefano Babic sba...@denx.de CC: Jason Liu jason@linaro.org --- doc/README.imximage |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/doc/README.imximage b/doc/README.imximage index c74239d..c3704a4 100644 --- a/doc/README.imximage +++ b/doc/README.imximage @@ -3,7 +3,7 @@ Imximage Boot Image generation using mkimage - This document describes how to set up a U-Boot image -that can be booted by Freescale MX25, MX35 and MX51 +that can be booted by Freescale MX25, MX35, MX51 and MX53 processors via internal boot mode. These processors can boot directly from NAND, SPI flash and SD card flash -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] imximage: Add support for i.MX6
The i.MX6 processor can boot from NOR flash and SATA disks,
additionally. Add the flash offsets for these additional
boot modes.
Signed-off-by: Dirk Behme dirk.be...@de.bosch.com
Signed-off-by: Fabio Estevam feste...@gmail.com
CC: Stefano Babic sba...@denx.de
CC: Jason Liu jason@linaro.org
---
doc/README.imximage | 13 +++--
tools/imximage.c|4 +++-
tools/imximage.h|2 ++
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/doc/README.imximage b/doc/README.imximage
index c3704a4..073e3fc 100644
--- a/doc/README.imximage
+++ b/doc/README.imximage
@@ -2,12 +2,13 @@
Imximage Boot Image generation using mkimage
-
-This document describes how to set up a U-Boot image
-that can be booted by Freescale MX25, MX35, MX51 and MX53
-processors via internal boot mode.
+This document describes how to set up a U-Boot image that can be booted
+by Freescale MX25, MX35, MX51, MX53 and MX6 processors via internal boot
+mode.
These processors can boot directly from NAND, SPI flash and SD card flash
-using its internal boot ROM support. They can boot from an internal
+using its internal boot ROM support. MX6 processors additionally support
+boot from NOR flash and SATA disks. All processors can boot from an internal
UART, if booting from device media fails.
Booting from NOR flash does not require to use this image type.
@@ -59,12 +60,12 @@ Configuration command line syntax:
-- ---
IMXIMAGE_VERSION1/2
1 is for mx25/mx35/mx51 compatible,
- 2 is for mx53 compatible,
+ 2 is for mx53/mx6 compatible,
others is invalid and error is generated.
This command need appear the fist before
other valid commands in configuration file.
- BOOT_FROM nand/spi/sd/onenand
+ BOOT_FROM nand/spi/sd/onenand/nor/sata
Example:
BOOT_FROM spi
DATAtype address value
diff --git a/tools/imximage.c b/tools/imximage.c
index 8e81bdb..f3da139 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -51,6 +51,8 @@ static table_entry_t imximage_bootops[] = {
{FLASH_OFFSET_NAND, nand, NAND Flash, },
{FLASH_OFFSET_SD, sd, SD Card, },
{FLASH_OFFSET_ONENAND, onenand, OneNAND Flash,},
+ {FLASH_OFFSET_NOR, nor, NOR Flash,},
+ {FLASH_OFFSET_SATA, sata, SATA Disk,},
{-1,, Invalid, },
};
@@ -59,7 +61,7 @@ static table_entry_t imximage_bootops[] = {
*/
static table_entry_t imximage_versions[] = {
{IMXIMAGE_V1, , (i.MX25/35/51 compatible), },
- {IMXIMAGE_V2, , (i.MX53 compatible), },
+ {IMXIMAGE_V2, , (i.MX53/6 compatible), },
{-1,, (Invalid), },
};
diff --git a/tools/imximage.h b/tools/imximage.h
index d126a46..d784a8d 100644
--- a/tools/imximage.h
+++ b/tools/imximage.h
@@ -37,6 +37,8 @@
#define FLASH_OFFSET_SDFLASH_OFFSET_STANDARD
#define FLASH_OFFSET_SPI FLASH_OFFSET_STANDARD
#define FLASH_OFFSET_ONENAND 0x100
+#define FLASH_OFFSET_NOR 0x1000
+#define FLASH_OFFSET_SATA FLASH_OFFSET_STANDARD
#define IVT_HEADER_TAG 0xD1
#define IVT_VERSION 0x40
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 V4] Changes to move hawkboard to the new spl infrastructure
hi Christian, On Thu Jan 12, 2012 at 10:02:47AM +0100, Christian Riesch wrote: Hi Sughosh, On Wed, Jan 11, 2012 at 6:03 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: This patch moves hawkboard to the new spl infrastructure from the older nand_spl one. Removed the hawkboard_nand_config build option -- The spl code now gets compiled with hawkboard_config, after building the main u-boot image, using the CONFIG_SPL_TEXT_BASE. Modified the README.hawkboard to reflect the same. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com Signed-off-by: Heiko Schocher h...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Christian Riesch christian.rie...@omicron.at Cc: Sudhakar Rajashekhara sudhakar@ti.com Cc: Tom Rini tr...@ti.com I have tested this with both the da850evm and the calimain board (see [1]), and the low level initialization still works :-) Therefore Acked-by: Christian Riesch christian.rie...@omicron.at Thanks for the review and ack :) Can you also please test out this patch. http://patchwork.ozlabs.org/patch/135275/ Just wanted to make sure it does not introduce any regressions. This is a generic arm926ejs fix, so you should be able to test this on any arm926ejs based board -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-imx on Freescale MX28EVK
Hi Fabio, thanks for your details. Some of the discrete switches where messed up. Boot Mode was fine. So now it's working fine. Even the power button is not needed ;-) I still have to investigate a little to get USB recovery working. This does not work out of the box as with Freescale'S initial 2009.08 u-boot for this CPU. Matthias On 11.01.2012 16:12, Fabio Estevam wrote: Hi Matthias, On Wed, Jan 11, 2012 at 12:41 PM, Matthias Fuchs matthias.fu...@esd.eu wrote: Hi Fabio, can you confirm that the current u-boot-imx tree runs fine on the MX28EVK? I tried it but the debug console stays dead. Yes, it works fine. This is what I did: 1) make mx28evk I think you meant mx28evk_config 2) make u-boot.sb 3) ./tools/mxsboot sd u-boot.sb u-boot-sd.sb 4) prepare an SD card as described in doc/README.m28 (only one partition of type 53) 5) dd u-boot-sd.sb to above partition 6) install SD and press power button On my board I don't have to press the power button in order to get the console output. Please check your MX28EVK settings: - Boot Mode Select: 1 0 0 1 - JTAG PSWITCH RESET: To the left (reset enabled) - Battery Source: Down - Wall 5V: Up - VDD 5V: To the left (off) - Hold Button: Down (off) Also, I have only tested this on a MX28EVK rev.D board. BTW: Did you ever try Freescales sd_loader to download u-boot into RAM? FYI: There also seems to be a Linux version of the USB loader (http://svn.rockbox.org/viewvc.cgi/trunk/utils/imxtools/). I haven't tried this yet. Regards, Fabio Estevam ___ 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] u-boot-imx on Freescale MX28EVK
Hi Matthias, On Thu, Jan 12, 2012 at 8:07 AM, Matthias Fuchs matthias.fu...@esd.eu wrote: Hi Fabio, thanks for your details. Some of the discrete switches where messed up. Boot Mode was fine. So now it's working fine. Even the power button is not needed ;-) I am glad to know it is working now. I will create a README file with these jumper settings. Also, can you please let me know what is your board version? Is it also mx28evk revD? I still have to investigate a little to get USB recovery working. This does not work out of the box as with Freescale'S initial 2009.08 u-boot for this CPU. Ok, good. m28evk has USB support as far as I know, so maybe you can look at it for reference. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] imx: tt01: add MMC support
Hi, this is imx related, subject wasn't taken from the compose email. Helmut -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] net: ll_temac: Add LL TEMAC driver to u-boot
Wolfgang Denk wrote: Dear Stephan Linz, In message 1325956366.18981.47.camel@keto you wrote: I'll provide the same way for the Xilinx LL_TEMAC driver as for the Xilinx AXI-EMAC driver. I prepare the microblaze-generic board code to support all potential Ethernet drivers but leave out the specific usage. You are right when you say that there is no code that refere to the new driver code -- there are also no configuration for this. And yes we adapt/change the xparameters.h out of mainline tree to enable the driver code -- but I think, that is not really a out of tree port. But what would be the best implementation for unspecified targets here? The question is actually a very simple one here: is there any board configuration in mainline that will actually compile and link against this driver? If yes, then everything is fine. If not, we would not even know if there were gross syntax errors in that code, and we would never notce when changes to other parts break compatibility with it. This is why I will not add any code that is not used in mainline - out-of-tree users don't help a bit. OK. Stephan, please send v8 with suggested changes with all patches or link to patches which are necessary to use. Please also define fake address XILINX_LLTEMAC_BASEADDR in xparameters.h to be compiled. The same we will do for axi emac driver. Stephan if you like I can add that changes to my custodian git tree and do final testing before we ask Wolfgang to merge. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v7] arm926ejs: add NXP LPC32x0 cpu series support
On 12.01.2012 01:51, Marek Vasut wrote: This change adds initial support for NXP LPC32x0 SoC series. Signed-off-by: Vladimir Zapolskiyv...@mleia.com Cc: Albert ARIBAUDalbert.u.b...@aribaud.net Cc: Wolfgang Denkw...@denx.de --- Changes from v6 to v7: * get use of setbits_le32() and friends * add arch_cpu_init() routine Changes from v5 to v6: * replaced some spaces with tabs in macro declarations * more rules separating 14-clock and ns16650 UARTs in config.h Changes from v4 to v5: * corrected address in GPLv2+ licence header in files Changes from v3 to v4: * extended memory controller definitions are introduced * added print_cpuinfo() function Changes from v2 to v3: * checkpatch.pl reports zero errors and warnings Changes from v1 to v2: * BIT(n) and SBF(s, v) macro are not used anymore * removed NS16550 and 14-clock UART definitions from uart.h * added devices.c file, which contains standard UART preinitialization routine * added get_serial_clock() function, it returns actual frequency of UART clock * __udelay() realization is simplified, no need of interrupt handling arch/arm/cpu/arm926ejs/lpc32xx/Makefile | 45 +++ arch/arm/cpu/arm926ejs/lpc32xx/clkpwr.c | 118 + arch/arm/cpu/arm926ejs/lpc32xx/cpu.c | 68 ++ arch/arm/cpu/arm926ejs/lpc32xx/devices.c | 52 arch/arm/cpu/arm926ejs/lpc32xx/timer.c| 90 + arch/arm/include/asm/arch-lpc32xx/clk.h | 170 + arch/arm/include/asm/arch-lpc32xx/config.h | 76 +++ arch/arm/include/asm/arch-lpc32xx/cpu.h | 64 + arch/arm/include/asm/arch-lpc32xx/emc.h | 92 + arch/arm/include/asm/arch-lpc32xx/sys_proto.h | 25 arch/arm/include/asm/arch-lpc32xx/timer.h | 74 +++ arch/arm/include/asm/arch-lpc32xx/uart.h | 54 arch/arm/include/asm/arch-lpc32xx/wdt.h | 51 13 files changed, 979 insertions(+), 0 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/Makefile create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/clkpwr.c create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/cpu.c create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/devices.c create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/timer.c create mode 100644 arch/arm/include/asm/arch-lpc32xx/clk.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/config.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/cpu.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/emc.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/sys_proto.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/timer.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/uart.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/wdt.h diff --git a/arch/arm/cpu/arm926ejs/lpc32xx/Makefile b/arch/arm/cpu/arm926ejs/lpc32xx/Makefile new file mode 100644 index 000..e6222e4 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/lpc32xx/Makefile @@ -0,0 +1,45 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License +# as published by the Free Software Foundation; either version 2 +# of the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(SOC).o + +COBJS = cpu.o clkpwr.o devices.o timer.o + +SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS:= $(addprefix $(obj),$(COBJS) $(SOBJS)) + +all:$(obj).depend $(LIB) + +$(LIB): $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +### ## + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +### ## diff --git a/arch/arm/cpu/arm926ejs/lpc32xx/clkpwr.c b/arch/arm/cpu/arm926ejs/lpc32xx/clkpwr.c new file mode 100644 index 000..103157a --- /dev/null +++ b/arch/arm/cpu/arm926ejs/lpc32xx/clkpwr.c @@ -0,0 +1,118 @@ +/* + * Copyright (C) 2011 by Vladimir Zapolskiyv...@mleia.com + *
Re: [U-Boot] [PATCH 2/2 V4] Changes to move hawkboard to the new spl infrastructure
On Thu, Jan 12, 2012 at 10:39 AM, Sughosh Ganu urwithsugh...@gmail.com wrote: hi Christian, On Thu Jan 12, 2012 at 10:02:47AM +0100, Christian Riesch wrote: Hi Sughosh, On Wed, Jan 11, 2012 at 6:03 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: This patch moves hawkboard to the new spl infrastructure from the older nand_spl one. Removed the hawkboard_nand_config build option -- The spl code now gets compiled with hawkboard_config, after building the main u-boot image, using the CONFIG_SPL_TEXT_BASE. Modified the README.hawkboard to reflect the same. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com Signed-off-by: Heiko Schocher h...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Christian Riesch christian.rie...@omicron.at Cc: Sudhakar Rajashekhara sudhakar@ti.com Cc: Tom Rini tr...@ti.com I have tested this with both the da850evm and the calimain board (see [1]), and the low level initialization still works :-) Therefore Acked-by: Christian Riesch christian.rie...@omicron.at Thanks for the review and ack :) Can you also please test out this patch. http://patchwork.ozlabs.org/patch/135275/ Just wanted to make sure it does not introduce any regressions. This is a generic arm926ejs fix, so you should be able to test this on any arm926ejs based board Ok, I'll do a few tests and reply in the other thread. Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] EXYNOS: Add SMDK5250 board support
Dear Chander Kashyap, In message CANuQgHF96iPBA=rjl0cndr5pykjzz6de6mk4a6chysnjf7n...@mail.gmail.com you wrote: Simon and Wolfgang have been commented to make these files to C. So, What is your plan? I am working on it. If possible please merge these patches. As soon as I am finished with converting in to c files I will submit the patches to replace assembly with c files. No, this is not how it works. We will wait for your submission with C files. 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 An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
Hi Sughosh, On Tue, Jan 10, 2012 at 7:12 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: The current implementation invalidates the cache instead of flushing it. This causes problems on platforms where the spl/u-boot is already loaded to the RAM, with caches enabled by a first stage bootloader. The V bit of the cp15's control register c1 is set to the value of VINITHI on reset. Do not clear this bit by default, as there are SOC's with no valid memory region at 0x0. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net --- Changes since V1 * Added arm926 keyword to the subject line * Removed the superfluous setting of r0. * Fixed the comment to reflect the fact that V is not being cleared I did a few tests of this patch with the da850evm (on an AM1808 experimenter's kit) and the calimain (on our custom board) configurations. I used u-boot from git://git.denx.de/u-boot-ti.git master, head is 14023683951b9a2bd277e999b0798b4917aca5d5. On top of this I applied these three patches: [U-Boot,1/2,V2] arm926: Flush the data cache before disabling it. http://patchwork.ozlabs.org/patch/135275/ [U-Boot,2/2,V4] Changes to move hawkboard to the new spl infrastructure http://patchwork.ozlabs.org/patch/135433/ [U-Boot,v2] arm, davinci: Add support for the Calimain board from OMICRON electronics http://patchwork.ozlabs.org/patch/135593/ First I compiled for the da850evm. make mrproper make da850evm_config make -j3 -s u-boot.ais I flashed the resulting u-boot.ais to the SPI flash of the AM1808 experimenter's kit: mono dvflashutils/OMAP-L138/GNU/sfh_OMAP-L138.exe -targetType AM1808 -flashType SPI_MEM -p /dev/ttyUSB0 -flash_noubl ../u-boot/u-boot.ais And tried to boot - SUCCESS I also tried the TI way (using the ubl): mono dvflashutils/OMAP-L138/GNU/sfh_OMAP-L138.exe -targetType AM1808 -flashType SPI_MEM -p /dev/ttyUSB0 -flash dvflashutils/OMAP-L138/GNU/ubl/ubl_AM1808_SPI_MEM.bin ../u-boot/u-boot.bin And tried to boot - SUCCESS Countercheck: I reverted patch [U-Boot,1/2,V2] arm926: Flush the data cache before disabling it. and rebuilt git revert HEAD~2 make mrproper make da850evm_config make -j3 -s u-boot.ais Again I tried with ubl and without - both worked - SUCCESS Since you state that problems arise with the AIS scripts I also did a test loading u-boot with an AIS. This is my da850evm.ini [General] busWidth=8 BootMode=SPIMASTER crcCheckType=NO_CRC [PLLANDCLOCKCONFIG] PLL0CFG0 = 0x00180001 PLL0CFG1 = 0x0205 PERIPHCLKCFG = 0x0002 [EMIF3DDR] PLL1CFG0 = 0x15010001 PLL1CFG1 = 0x0002 DDRPHYC1R = 0x00C4 SDCR = 0x0A034622 SDTIMR = 0x184929C8 SDTIMR2 = 0xB80FC700 SDRCR = 0x0406 CLK2XSRC = 0x [INPUTFILE] FILENAME=u-boot.bin LOADADDRESS=0xC108 ENTRYPOINTADDRESS=0xC108 I run mono dvflashutils/OMAP-L138/GNU/AISUtils/HexAIS_OMAP-L138.exe -ini da850evm.ini -o u-boot.ais program to flash and run - SUCCESS I undo the revert git reset --hard HEAD^ and rebuild make mrproper make da850evm_config make -j3 -s u-boot.ais program and run - SUCCESS Similar tests with the calimain board were also successful. Since all my tests were successful I wonder what issues did you have with the cache? Can you describe the problems you had? I think the difference is that you are booting from NAND and have an OMAP-L138, whereas I boot from SPI (on the da850evm) or from NOR (on calimain) and have an AM1808 on both boards, right? Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bootm not taking dtb
U-Boot 2009.06 (Apr 19 2011 - 12:54:10) Note that I did not compile or install this uboot version on the system. JR On Jan 11, 2012, at 9:29 PM, Wolfgang Denk wrote: Dear JR Rivers, In message cdd94667-69dd-496a-90f5-ede4f9f2a...@cumulusnetworks.com you wrote: I am working with a powerpc embedded system where u-boot seems to be passing in a constructed fdt (or one embedded in u-boot) as opposed to one that is either passed directly to bootm or as the third image of a multi-file image. And which exact version of U-Boot is this? Please also provide the commit ID printed with the version string. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If the hours are long enough and the pay is short enough, someone will say it's women's work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/6] cm-t35: add EEPROM module and pass Linux a serial number
From: Nikita Kiryanov nik...@compulab.co.il
Add board specific EEPROM handling module,
read the serial number from the EEPROM and pass it to Linux.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
Changes in v2:
* Use CONFIG_SYS_I2C_EEPROM_ADDR instead of a custom define
* Fix strange linker warning: .bss section overlaps previous sections
by changing the type of the eeprom_layout static global variable to int
(probably this is a compiler bug).
Changes in v3:
* Move the default implementation of get_board_serial out of eeprom.h and into
cm_t35.c
* Make get_board_serial default implementation weak.
board/cm_t35/Makefile|4 ++-
board/cm_t35/cm_t35.c| 11 ++
board/cm_t35/eeprom.c| 78 ++
include/configs/cm_t35.h |3 ++
4 files changed, 95 insertions(+), 1 deletions(-)
create mode 100644 board/cm_t35/eeprom.c
diff --git a/board/cm_t35/Makefile b/board/cm_t35/Makefile
index 27693f0..894fa09 100644
--- a/board/cm_t35/Makefile
+++ b/board/cm_t35/Makefile
@@ -25,7 +25,9 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := cm_t35.o leds.o
+COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += eeprom.o
+
+COBJS := cm_t35.o leds.o $(COBJS-y)
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/cm_t35/cm_t35.c b/board/cm_t35/cm_t35.c
index ff372d8..0d5a401 100644
--- a/board/cm_t35/cm_t35.c
+++ b/board/cm_t35/cm_t35.c
@@ -33,6 +33,7 @@
#include net.h
#include i2c.h
#include twl4030.h
+#include linux/compiler.h
#include asm/io.h
#include asm/arch/mem.h
@@ -421,3 +422,13 @@ int board_eth_init(bd_t *bis)
return rc;
}
#endif
+
+void __weak get_board_serial(struct tag_serialnr *serialnr)
+{
+ /*
+* This corresponds to what happens when we can communicate with the
+* eeprom but don't get a valid board serial value.
+*/
+ serialnr-low = 0;
+ serialnr-high = 0;
+};
diff --git a/board/cm_t35/eeprom.c b/board/cm_t35/eeprom.c
new file mode 100644
index 000..93ed6cb
--- /dev/null
+++ b/board/cm_t35/eeprom.c
@@ -0,0 +1,78 @@
+/*
+ * (C) Copyright 2011 CompuLab, Ltd. www.compulab.co.il
+ *
+ * Authors: Nikita Kiryanov nik...@compulab.co.il
+ * Igor Grinberg grinb...@compulab.co.il
+ *
+ * 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.
+ */
+
+#include common.h
+#include i2c.h
+
+#define EEPROM_LAYOUT_VER_OFFSET 44
+#define BOARD_SERIAL_OFFSET20
+#define BOARD_SERIAL_OFFSET_LEGACY 8
+
+#define LAYOUT_INVALID 0
+#define LAYOUT_LEGACY 0xff
+
+static int eeprom_layout; /* Implicitly LAYOUT_INVALID */
+
+static int cm_t3x_eeprom_read(uint offset, uchar *buf, int len)
+{
+ return i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, offset,
+ CONFIG_SYS_I2C_EEPROM_ADDR_LEN, buf, len);
+}
+
+static int eeprom_setup_layout(void)
+{
+ int res;
+
+ if (eeprom_layout != LAYOUT_INVALID)
+ return 0;
+
+ res = cm_t3x_eeprom_read(EEPROM_LAYOUT_VER_OFFSET,
+ (uchar *)eeprom_layout, 1);
+ if (res) {
+ eeprom_layout = LAYOUT_INVALID;
+ return res;
+ }
+
+ if (eeprom_layout == 0 || eeprom_layout = 0x20)
+ eeprom_layout = LAYOUT_LEGACY;
+
+ return 0;
+}
+
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+ u32 serial[2];
+ uint offset;
+
+ memset(serialnr, 0, sizeof(*serialnr));
+ if (eeprom_setup_layout())
+ return;
+
+ offset = (eeprom_layout != LAYOUT_LEGACY) ?
+ BOARD_SERIAL_OFFSET : BOARD_SERIAL_OFFSET_LEGACY;
+ if (cm_t3x_eeprom_read(offset, (uchar *)serial, 8))
+ return;
+
+ if (serial[0] != 0x serial[1] != 0x) {
+ serialnr-low = serial[0];
+ serialnr-high = serial[1];
+ }
+}
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 61226d5..fe91c10 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -72,6 +72,7 @@
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_INITRD_TAG
#define CONFIG_REVISION_TAG
+#define CONFIG_SERIAL_TAG
/*
* Size of malloc() pool
@@ -153,6 +154,8 @@
#define CONFIG_SYS_I2C_BUS 0
Re: [U-Boot] u-boot-imx on Freescale MX28EVK
On 12.01.2012 11:15, Fabio Estevam wrote: Hi Matthias, On Thu, Jan 12, 2012 at 8:07 AM, Matthias Fuchs matthias.fu...@esd.eu wrote: Hi Fabio, thanks for your details. Some of the discrete switches where messed up. Boot Mode was fine. So now it's working fine. Even the power button is not needed ;-) I am glad to know it is working now. I will create a README file with these jumper settings. Also, can you please let me know what is your board version? Is it also mx28evk revD? Yes, revD. I still have to investigate a little to get USB recovery working. This does not work out of the box as with Freescale'S initial 2009.08 u-boot for this CPU. Ok, good. m28evk has USB support as far as I know, so maybe you can look at it for reference. You did not really understand what I mean. I am not talking about using the USBs host/device from u-boot. The i.MX28 is capable to boot via USB. In this case the SOC's ROM implementes a HID device and you can use some tools on your PC (see previous posting) to download the code (boot jumper setting 0-0-0-0. I tried it with Freescale's sb_loader (Wind**s). This works fine when downloading a u-boot (imx28_ivt_uboot.sb) based on Freescale's 2009.08 source + imx-bootlets-src-10.12.01. But it does not work when using sb_loader with u-boot.sb build from the u-boot-imx repo. I can can imagine that the SPL code somehow breaks the internal download code. Matthias Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
hi Christian, On Thu Jan 12, 2012 at 01:03:05PM +0100, Christian Riesch wrote: Hi Sughosh, On Tue, Jan 10, 2012 at 7:12 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: The current implementation invalidates the cache instead of flushing it. This causes problems on platforms where the spl/u-boot is already loaded to the RAM, with caches enabled by a first stage bootloader. The V bit of the cp15's control register c1 is set to the value of VINITHI on reset. Do not clear this bit by default, as there are SOC's with no valid memory region at 0x0. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net --- Changes since V1 * Added arm926 keyword to the subject line * Removed the superfluous setting of r0. * Fixed the comment to reflect the fact that V is not being cleared I did a few tests of this patch with the da850evm (on an AM1808 experimenter's kit) and the calimain (on our custom board) configurations. I used u-boot from git://git.denx.de/u-boot-ti.git master, head is 14023683951b9a2bd277e999b0798b4917aca5d5. On top of this I applied these three patches: [U-Boot,1/2,V2] arm926: Flush the data cache before disabling it. http://patchwork.ozlabs.org/patch/135275/ [U-Boot,2/2,V4] Changes to move hawkboard to the new spl infrastructure http://patchwork.ozlabs.org/patch/135433/ [U-Boot,v2] arm, davinci: Add support for the Calimain board from OMICRON electronics http://patchwork.ozlabs.org/patch/135593/ First I compiled for the da850evm. make mrproper make da850evm_config make -j3 -s u-boot.ais I flashed the resulting u-boot.ais to the SPI flash of the AM1808 experimenter's kit: mono dvflashutils/OMAP-L138/GNU/sfh_OMAP-L138.exe -targetType AM1808 -flashType SPI_MEM -p /dev/ttyUSB0 -flash_noubl ../u-boot/u-boot.ais And tried to boot - SUCCESS I also tried the TI way (using the ubl): mono dvflashutils/OMAP-L138/GNU/sfh_OMAP-L138.exe -targetType AM1808 -flashType SPI_MEM -p /dev/ttyUSB0 -flash dvflashutils/OMAP-L138/GNU/ubl/ubl_AM1808_SPI_MEM.bin ../u-boot/u-boot.bin And tried to boot - SUCCESS Countercheck: I reverted patch [U-Boot,1/2,V2] arm926: Flush the data cache before disabling it. and rebuilt git revert HEAD~2 make mrproper make da850evm_config make -j3 -s u-boot.ais Again I tried with ubl and without - both worked - SUCCESS Since you state that problems arise with the AIS scripts I also did a test loading u-boot with an AIS. snip I run mono dvflashutils/OMAP-L138/GNU/AISUtils/HexAIS_OMAP-L138.exe -ini da850evm.ini -o u-boot.ais program to flash and run - SUCCESS I undo the revert git reset --hard HEAD^ and rebuild make mrproper make da850evm_config make -j3 -s u-boot.ais program and run - SUCCESS Similar tests with the calimain board were also successful. Since all my tests were successful I wonder what issues did you have with the cache? Can you describe the problems you had? I think the difference is that you are booting from NAND and have an OMAP-L138, whereas I boot from SPI (on the da850evm) or from NOR (on calimain) and have an AM1808 on both boards, right? Thanks a lot for all the testing. One difference i think we have on these boards and hawkboard, is that on hawkboard, the rbl configures the memory and loads the target image(spl in this case) directly to the ram. Looking at da850evm's lds file, it looks like the spl gets loaded to the sram, configures dram and then copies u-boot to the target load address. I think the rbl is enabling the caches in case of hawkboard, and on loading spl, it causes a problem when the cache is invalidated instead of being flushed. I'm pretty sure this is the problem, as the hawkboard does not boot without this fix. Thanks for the time taken for doing such elaborate tests. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
On Thu, Jan 12, 2012 at 2:53 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: On Thu Jan 12, 2012 at 01:03:05PM +0100, Christian Riesch wrote: On Tue, Jan 10, 2012 at 7:12 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: The current implementation invalidates the cache instead of flushing it. This causes problems on platforms where the spl/u-boot is already loaded to the RAM, with caches enabled by a first stage bootloader. The V bit of the cp15's control register c1 is set to the value of VINITHI on reset. Do not clear this bit by default, as there are SOC's with no valid memory region at 0x0. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net --- Changes since V1 * Added arm926 keyword to the subject line * Removed the superfluous setting of r0. * Fixed the comment to reflect the fact that V is not being cleared I did a few tests of this patch with the da850evm (on an AM1808 experimenter's kit) and the calimain (on our custom board) configurations. I used u-boot from git://git.denx.de/u-boot-ti.git master, head is 14023683951b9a2bd277e999b0798b4917aca5d5. On top of this I applied these three patches: [U-Boot,1/2,V2] arm926: Flush the data cache before disabling it. http://patchwork.ozlabs.org/patch/135275/ [U-Boot,2/2,V4] Changes to move hawkboard to the new spl infrastructure http://patchwork.ozlabs.org/patch/135433/ [U-Boot,v2] arm, davinci: Add support for the Calimain board from OMICRON electronics http://patchwork.ozlabs.org/patch/135593/ First I compiled for the da850evm. make mrproper make da850evm_config make -j3 -s u-boot.ais I flashed the resulting u-boot.ais to the SPI flash of the AM1808 experimenter's kit: mono dvflashutils/OMAP-L138/GNU/sfh_OMAP-L138.exe -targetType AM1808 -flashType SPI_MEM -p /dev/ttyUSB0 -flash_noubl ../u-boot/u-boot.ais And tried to boot - SUCCESS I also tried the TI way (using the ubl): mono dvflashutils/OMAP-L138/GNU/sfh_OMAP-L138.exe -targetType AM1808 -flashType SPI_MEM -p /dev/ttyUSB0 -flash dvflashutils/OMAP-L138/GNU/ubl/ubl_AM1808_SPI_MEM.bin ../u-boot/u-boot.bin And tried to boot - SUCCESS Countercheck: I reverted patch [U-Boot,1/2,V2] arm926: Flush the data cache before disabling it. and rebuilt git revert HEAD~2 make mrproper make da850evm_config make -j3 -s u-boot.ais Again I tried with ubl and without - both worked - SUCCESS Since you state that problems arise with the AIS scripts I also did a test loading u-boot with an AIS. snip I run mono dvflashutils/OMAP-L138/GNU/AISUtils/HexAIS_OMAP-L138.exe -ini da850evm.ini -o u-boot.ais program to flash and run - SUCCESS I undo the revert git reset --hard HEAD^ and rebuild make mrproper make da850evm_config make -j3 -s u-boot.ais program and run - SUCCESS Similar tests with the calimain board were also successful. Since all my tests were successful I wonder what issues did you have with the cache? Can you describe the problems you had? I think the difference is that you are booting from NAND and have an OMAP-L138, whereas I boot from SPI (on the da850evm) or from NOR (on calimain) and have an AM1808 on both boards, right? Thanks a lot for all the testing. One difference i think we have on these boards and hawkboard, is that on hawkboard, the rbl configures the memory and loads the target image(spl in this case) directly to the ram. Looking at da850evm's lds file, it looks like the spl gets loaded to the sram, configures dram and then copies u-boot to the target load address. This is only true if the SPL is actually used. Have a closer look at my test report, I tested three different methods: 1) The first test was done with the SPL and yes, here the RBL loads the SPL into SRAM, initializes DDR memory and then copies u-boot.bin to DDR memory. 2) The second test was done with TI's UBL. Here, the RBL loads the UBL into SRAM, the UBL initializes DDR memory and then copies u-boot.bin to DDR memory. 3) The third test was done without SPL and without UBL: Here the DDR memory init is in the AIS, so in fact the RBL does memory initialization and then RBL loads u-boot.bin to DDR memory. This is the same case that you have on the hawkboard (only that you have the OMAP-L138 and NAND flash instead) and it works for me regardless of your patch. Christian I think the rbl is enabling the caches in case of hawkboard, and on loading spl, it causes a problem when the cache is invalidated instead of being flushed. I'm pretty sure this is the problem, as the hawkboard does not boot without this fix. Thanks for the time taken for doing such elaborate tests. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
hi Christian, On Thu Jan 12, 2012 at 03:04:37PM +0100, Christian Riesch wrote: On Thu, Jan 12, 2012 at 2:53 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: On Thu Jan 12, 2012 at 01:03:05PM +0100, Christian Riesch wrote: snip Since all my tests were successful I wonder what issues did you have with the cache? Can you describe the problems you had? I think the difference is that you are booting from NAND and have an OMAP-L138, whereas I boot from SPI (on the da850evm) or from NOR (on calimain) and have an AM1808 on both boards, right? Thanks a lot for all the testing. One difference i think we have on these boards and hawkboard, is that on hawkboard, the rbl configures the memory and loads the target image(spl in this case) directly to the ram. Looking at da850evm's lds file, it looks like the spl gets loaded to the sram, configures dram and then copies u-boot to the target load address. This is only true if the SPL is actually used. Have a closer look at my test report, I tested three different methods: 1) The first test was done with the SPL and yes, here the RBL loads the SPL into SRAM, initializes DDR memory and then copies u-boot.bin to DDR memory. 2) The second test was done with TI's UBL. Here, the RBL loads the UBL into SRAM, the UBL initializes DDR memory and then copies u-boot.bin to DDR memory. 3) The third test was done without SPL and without UBL: Here the DDR memory init is in the AIS, so in fact the RBL does memory initialization and then RBL loads u-boot.bin to DDR memory. This is the same case that you have on the hawkboard (only that you have the OMAP-L138 and NAND flash instead) and it works for me regardless of your patch. Yes, the third case is similar to the one used in hawkboard. I'm not sure as to why it causes a problem on my board, though i'm not sure if we can compare the two cases, as we have different rbl's. It could be that the rbl used on hawkboard initialises the caches, as the caches are off by default on reset. Here are the values i use in my ini file for ddr init. [EMIF3DDR] PLL1CFG0 = 0x15010001 PLL1CFG1 = 0x0002 DDRPHYC1R = 0x0043 SDCR = 0x00134632 SDTIMR = 0x26492a09 SDTIMR2 = 0x7d13c722 SDRCR = 0x0249 CLK2XSRC = 0x -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2011.12 and later do not boot on dreamplug.
Ian,
On Thu, Jan 12, 2012 at 08:01:45AM +, Ian Campbell wrote:
On Sun, 2012-01-08 at 17:54 -0500, Jason wrote:
On Sun, Jan 08, 2012 at 07:49:05PM +, Ian Campbell wrote:
On Sun, 2012-01-08 at 15:30 +, Ian Campbell wrote:
diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index dfe542d..db8ba8b 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -66,7 +66,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
debug(data = 0x%08x \n, data);
writel(KWSPI_SMEMRDIRQ, spireg-irq_cause);
- writel(KWSPI_IRQMASK, spireg-irq_mask);
+ writel(KWSPI_IRQMASK, spireg-irq_mask);
/* program mpp registers to select SPI_CSn */
if (cs) {
--
1.7.5.4
Acked-By: Jason Cooper u-b...@lakedaemon.net
Dammit. My apologies. I should've caught that. Thanks for the patch.
No problem, was interesting to dig into u-boot for the first time!
Well, at least my mistake created another u-boot hacker. ;-)
Did I get the CC list right to cover whoever will eventually apply this
patch?
Meh, I've been pondering this. The merge window is open right now, go
ahead and resubmit according to [1]. Make sure to put the Message-Id:
of the original patch email you sent as an In-Reply-To:, and mention in
the changelog that this 'v2' follows [1] for patch submissions.
Also, make sure Prafulla and Albert are in the CC if they aren't
already.
I think the original will get lost in the shuffle because it doesn't
have [PATCH 1/1] in the subject line.
You are also working on upstreaming dreamplug support into Linux, is
that right? What is the current state of the art? I'm currently using a
3.1 kernel + patches from
http://people.debian.org/~zumbi/dreamplug/patches/ . (BTW feel free to
reply off list or switch to e.g. linux-arm-kernel since I guess this is
strict speaking off-topic here).
I use this [2] for 3.1, since it uses the same nor flash partitioning as
u-boot does. This way, you could edit the u-boot config from userspace
or upgrade u-boot from userspace.
hth,
Jason.
[1] http://www.denx.de/wiki/U-Boot/Patches
[2] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/143116
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] SPI: Add i.MX ECSPI driver
From: Eric Nelson eric.nel...@boundarydevices.com
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
CC: Jason Liu jason@linaro.org
CC: Stefano Babic sba...@denx.de
---
drivers/spi/Makefile|1 +
drivers/spi/imx_ecspi.c | 334 +++
include/imx_spi.h | 97 ++
3 files changed, 432 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/imx_ecspi.c
create mode 100644 include/imx_spi.h
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index c967d87..e27ef41 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_ATMEL_SPI) += atmel_spi.o
COBJS-$(CONFIG_BFIN_SPI) += bfin_spi.o
COBJS-$(CONFIG_CF_SPI) += cf_spi.o
COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
+COBJS-$(CONFIG_IMX_ECSPI) += imx_ecspi.o
COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
COBJS-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
diff --git a/drivers/spi/imx_ecspi.c b/drivers/spi/imx_ecspi.c
new file mode 100644
index 000..1468208
--- /dev/null
+++ b/drivers/spi/imx_ecspi.c
@@ -0,0 +1,334 @@
+/*
+ * (C) Copyright 2008-2010 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include config.h
+#include common.h
+#include spi.h
+#include asm/errno.h
+#include linux/types.h
+#include asm/io.h
+#include malloc.h
+#include asm/arch/clock.h
+#include imx_spi.h
+
+static inline struct imx_spi_dev_t *to_imx_spi_slave(struct spi_slave *slave)
+{
+ return container_of(slave, struct imx_spi_dev_t, slave);
+}
+
+static s32 spi_reset(struct spi_slave *slave)
+{
+ u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
+ u32 pre_div = 0, post_div = 0, reg_ctrl, reg_config;
+ struct imx_spi_dev_t *dev = to_imx_spi_slave(slave);
+ struct spi_reg_t *reg = (dev-reg);
+
+ if (dev-freq == 0) {
+ printf(Error: desired clock is 0\n);
+ return 1;
+ }
+
+ reg_ctrl = readl(dev-base + SPI_CON_REG);
+ reg_config = readl(dev-base + SPI_CFG_REG);
+ /* Reset spi */
+ writel(0, dev-base + SPI_CON_REG);
+ writel((reg_ctrl | 0x1), dev-base + SPI_CON_REG);
+
+ /* Control register setup */
+ pre_div = (clk_src + dev-freq - 1) / dev-freq;
+ while (pre_div 16) {
+ pre_div = (pre_div + 1) 1;
+ post_div++;
+ }
+ if (post_div 0x0f) {
+ printf(Error: no divider can meet the freq: %d\n, dev-freq);
+ return -1;
+ }
+ if (pre_div)
+ pre_div--;
+
+ debug(pre_div = %d, post_div=%d, clk_src=%d, spi_freq=%d\n, pre_div,
+ post_div, clk_src, (clk_src/(pre_div + 1)) post_div);
+ reg_ctrl = ~((3 18) | (0xF 12) | (0xF 8));
+ reg_ctrl |= (dev-ss 18);
+ reg_ctrl |= (pre_div 12);
+ reg_ctrl |= (post_div 8);
+ reg_ctrl |= (1 (dev-ss + 4)); /* always set to master mode */
+ reg_ctrl |= 1;
+
+ /* configuration register setup */
+ reg_config = ~(0x11 dev-ss);
+ reg_config |= (dev-in_sctl (dev-ss + 20));
+ reg_config |= (dev-in_dctl (dev-ss + 16));
+ reg_config |= (dev-ss_pol (dev-ss + 12));
+ reg_config |= (dev-ssctl (dev-ss + 8));
+ reg_config |= (dev-sclkpol (dev-ss + 4));
+ reg_config |= (dev-sclkpha (dev-ss));
+
+ reg_config = 0x0f 12 ;
+ reg_config |= (dev-ss_pol)(12+dev-ss);
+ debug(ss%x, reg_config = 0x%x\n, dev-ss, reg_config);
+ writel(reg_config, dev-base + SPI_CFG_REG);
+ debug(ss%x, reg_ctrl = 0x%x\n, dev-ss, reg_ctrl);
+ writel(reg_ctrl ~1, dev-base + SPI_CON_REG);
+
+ /* save config register and control register */
+ reg-cfg_reg = reg_config;
+ reg-ctrl_reg = reg_ctrl;
+
+ /* clear interrupt reg */
+ writel(0, dev-base + SPI_INT_REG);
+ writel(3 6, dev-base + SPI_STAT_REG);
+ return 0;
+}
+
+void spi_init(void)
+{
+}
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+{
+ struct imx_spi_dev_t *imx_spi_slave = NULL;
+
+ if
[U-Boot] [PATCH 2/2] i.mx6q: SabreLite: Add SPI NOR support
From: Eric Nelson eric.nel...@boundarydevices.com
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
CC: Jason Liu jason@linaro.org
CC: Stefano Babic sba...@denx.de
---
Note: These two patches are against the recent head of u-boot-imx.git including
the SabreLite support:
5b894e4d00ff94a221f8cc23d54d08b889f54190
i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board
board/freescale/mx6qsabrelite/imximage.cfg|2 +-
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 51 +
include/configs/mx6qsabrelite.h | 15 +++
3 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/imximage.cfg
b/board/freescale/mx6qsabrelite/imximage.cfg
index 83dee6f..c389427 100644
--- a/board/freescale/mx6qsabrelite/imximage.cfg
+++ b/board/freescale/mx6qsabrelite/imximage.cfg
@@ -156,7 +156,7 @@ DATA 4 0x021b0404 0x00011006
# set the default clock gate to save power
DATA 4 0x020c4068 0x00C03F3F
-DATA 4 0x020c406c 0x0030FC00
+DATA 4 0x020c406c 0x0030FC03
DATA 4 0x020c4070 0x0FFFC000
DATA 4 0x020c4074 0x3FF0
DATA 4 0x020c4078 0x00FFF300
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 4028789..d69adfa 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -29,6 +29,10 @@
#include asm/gpio.h
#include mmc.h
#include fsl_esdhc.h
+#ifdef CONFIG_IMX_ECSPI
+#include spi.h
+#include imx_spi.h
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -40,6 +44,10 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_LOW | \
PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+#define SPI_PAD_CTRL (PAD_CTL_HYS |\
+ PAD_CTL_PUS_100K_DOWN | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+
int dram_init(void)
{
gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -128,6 +136,46 @@ int board_mmc_init(bd_t *bis)
}
#endif
+#ifdef CONFIG_IMX_ECSPI
+s32 spi_get_cfg(struct imx_spi_dev_t *dev)
+{
+ int rval = 0 ;
+ if (1 == dev-slave.cs) {
+ dev-base = ECSPI1_BASE_ADDR;
+ dev-ss = 1 ;
+ dev-ss_pol = IMX_SPI_ACTIVE_LOW; /* SPI NOR */
+ dev-freq = 2500;
+ dev-fifo_sz = 64 * 4;
+ dev-us_delay = 0;
+ } else {
+ printf(%s: invalid chip select %d\n, __func__, dev-slave.cs);
+ rval = -EINVAL ;
+ }
+ return rval;
+}
+
+void spi_io_init(struct imx_spi_dev_t *dev, int active)
+{
+ if (dev-ss == 1)
+ gpio_set_value(83, active ? 0 : 1); /* GPIO 3.19 */
+}
+
+iomux_v3_cfg_t ecspi1_pads[] = {
+ /* SS1 */
+ MX6Q_PAD_EIM_D19__GPIO_3_19 | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6Q_PAD_EIM_D17__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6Q_PAD_EIM_D18__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6Q_PAD_EIM_D16__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
+};
+
+void setup_spi(void)
+{
+ gpio_direction_output(83, 1); /* GPIO 3.19 */
+ imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
+ARRAY_SIZE(ecspi1_pads));
+}
+#endif
+
int board_early_init_f(void)
{
setup_iomux_uart();
@@ -140,6 +188,9 @@ int board_init(void)
/* address of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
+#ifdef CONFIG_IMX_ECSPI
+ setup_spi();
+#endif
return 0;
}
diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h
index 464f0ec..48db42c 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -44,6 +44,21 @@
#define CONFIG_MXC_UART
#define CONFIG_MXC_UART_BASE UART2_BASE
+#define CONFIG_CMD_SF
+/*
+ * SPI Configs
+ */
+#ifdef CONFIG_CMD_SF
+ #define CONFIG_FSL_SF 1
+ #define CONFIG_SPI_FLASH 1
+ #define CONFIG_SPI_FLASH_SST1
+ #define CONFIG_SPI_FLASH_CS 1
+ #define CONFIG_IMX_ECSPI
+ #define IMX_CSPI_VER_2_31
+
+ #define MAX_SPI_BYTES (64 * 4)
+#endif
+
/* MMC Configs */
#define CONFIG_FSL_ESDHC
#define CONFIG_FSL_USDHC
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] i.mx6q: SabreLite: Add SPI NOR support
On Thu, Jan 12, 2012 at 1:27 PM, Dirk Behme dirk.be...@de.bosch.com wrote: +#ifdef CONFIG_CMD_SF + #define CONFIG_FSL_SF 1 + #define CONFIG_SPI_FLASH 1 + #define CONFIG_SPI_FLASH_SST 1 + #define CONFIG_SPI_FLASH_CS 1 + #define CONFIG_IMX_ECSPI + #define IMX_CSPI_VER_2_3 1 Please remove all these unneeded 1. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPI: Add i.MX ECSPI driver
From: Eric Nelson eric.nel...@boundarydevices.com
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
CC: Jason Liu jason@linaro.org
CC: Stefano Babic sba...@denx.de
---
drivers/spi/Makefile|1 +
drivers/spi/imx_ecspi.c | 334
+++ include/imx_spi.h |
97 ++
3 files changed, 432 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/imx_ecspi.c
create mode 100644 include/imx_spi.h
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index c967d87..e27ef41 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_ATMEL_SPI) += atmel_spi.o
COBJS-$(CONFIG_BFIN_SPI) += bfin_spi.o
COBJS-$(CONFIG_CF_SPI) += cf_spi.o
COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
+COBJS-$(CONFIG_IMX_ECSPI) += imx_ecspi.o
COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
COBJS-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
diff --git a/drivers/spi/imx_ecspi.c b/drivers/spi/imx_ecspi.c
new file mode 100644
index 000..1468208
--- /dev/null
+++ b/drivers/spi/imx_ecspi.c
@@ -0,0 +1,334 @@
+/*
+ * (C) Copyright 2008-2010 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include config.h
+#include common.h
+#include spi.h
+#include asm/errno.h
+#include linux/types.h
+#include asm/io.h
+#include malloc.h
+#include asm/arch/clock.h
+#include imx_spi.h
+
+static inline struct imx_spi_dev_t *to_imx_spi_slave(struct spi_slave
*slave) +{
+ return container_of(slave, struct imx_spi_dev_t, slave);
+}
+
+static s32 spi_reset(struct spi_slave *slave)
+{
+ u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
+ u32 pre_div = 0, post_div = 0, reg_ctrl, reg_config;
+ struct imx_spi_dev_t *dev = to_imx_spi_slave(slave);
+ struct spi_reg_t *reg = (dev-reg);
+
+ if (dev-freq == 0) {
+ printf(Error: desired clock is 0\n);
+ return 1;
+ }
+
+ reg_ctrl = readl(dev-base + SPI_CON_REG);
+ reg_config = readl(dev-base + SPI_CFG_REG);
+ /* Reset spi */
+ writel(0, dev-base + SPI_CON_REG);
+ writel((reg_ctrl | 0x1), dev-base + SPI_CON_REG);
+
+ /* Control register setup */
+ pre_div = (clk_src + dev-freq - 1) / dev-freq;
+ while (pre_div 16) {
+ pre_div = (pre_div + 1) 1;
+ post_div++;
+ }
+ if (post_div 0x0f) {
+ printf(Error: no divider can meet the freq: %d\n, dev-freq);
+ return -1;
+ }
+ if (pre_div)
+ pre_div--;
+
+ debug(pre_div = %d, post_div=%d, clk_src=%d, spi_freq=%d\n, pre_div,
+ post_div, clk_src, (clk_src/(pre_div + 1)) post_div);
+ reg_ctrl = ~((3 18) | (0xF 12) | (0xF 8));
Magic numbers, fix globally
+ reg_ctrl |= (dev-ss 18);
+ reg_ctrl |= (pre_div 12);
+ reg_ctrl |= (post_div 8);
+ reg_ctrl |= (1 (dev-ss + 4)); /* always set to master mode */
+ reg_ctrl |= 1;
+
+ /* configuration register setup */
+ reg_config = ~(0x11 dev-ss);
+ reg_config |= (dev-in_sctl (dev-ss + 20));
+ reg_config |= (dev-in_dctl (dev-ss + 16));
+ reg_config |= (dev-ss_pol (dev-ss + 12));
+ reg_config |= (dev-ssctl (dev-ss + 8));
+ reg_config |= (dev-sclkpol (dev-ss + 4));
+ reg_config |= (dev-sclkpha (dev-ss));
+
+ reg_config = 0x0f 12 ;
+ reg_config |= (dev-ss_pol)(12+dev-ss);
+ debug(ss%x, reg_config = 0x%x\n, dev-ss, reg_config);
+ writel(reg_config, dev-base + SPI_CFG_REG);
+ debug(ss%x, reg_ctrl = 0x%x\n, dev-ss, reg_ctrl);
+ writel(reg_ctrl ~1, dev-base + SPI_CON_REG);
+
+ /* save config register and control register */
+ reg-cfg_reg = reg_config;
+ reg-ctrl_reg = reg_ctrl;
+
+ /* clear interrupt reg */
+ writel(0, dev-base + SPI_INT_REG);
+ writel(3 6, dev-base + SPI_STAT_REG);
+ return 0;
+}
+
+void spi_init(void)
+{
+}
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+{
+
Re: [U-Boot] [PATCH 2/2] i.mx6q: SabreLite: Add SPI NOR support
From: Eric Nelson eric.nel...@boundarydevices.com
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
CC: Jason Liu jason@linaro.org
CC: Stefano Babic sba...@denx.de
---
Note: These two patches are against the recent head of u-boot-imx.git
including the SabreLite support:
5b894e4d00ff94a221f8cc23d54d08b889f54190
i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board
board/freescale/mx6qsabrelite/imximage.cfg|2 +-
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 51
+ include/configs/mx6qsabrelite.h |
15 +++
3 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/imximage.cfg
b/board/freescale/mx6qsabrelite/imximage.cfg index 83dee6f..c389427 100644
--- a/board/freescale/mx6qsabrelite/imximage.cfg
+++ b/board/freescale/mx6qsabrelite/imximage.cfg
@@ -156,7 +156,7 @@ DATA 4 0x021b0404 0x00011006
# set the default clock gate to save power
DATA 4 0x020c4068 0x00C03F3F
-DATA 4 0x020c406c 0x0030FC00
+DATA 4 0x020c406c 0x0030FC03
DATA 4 0x020c4070 0x0FFFC000
DATA 4 0x020c4074 0x3FF0
DATA 4 0x020c4078 0x00FFF300
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c index 4028789..d69adfa
100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -29,6 +29,10 @@
#include asm/gpio.h
#include mmc.h
#include fsl_esdhc.h
+#ifdef CONFIG_IMX_ECSPI
+#include spi.h
+#include imx_spi.h
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -40,6 +44,10 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_LOW | \
PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+#define SPI_PAD_CTRL (PAD_CTL_HYS |\
+ PAD_CTL_PUS_100K_DOWN | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+
int dram_init(void)
{
gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -128,6 +136,46 @@ int board_mmc_init(bd_t *bis)
}
#endif
+#ifdef CONFIG_IMX_ECSPI
+s32 spi_get_cfg(struct imx_spi_dev_t *dev)
+{
+ int rval = 0 ;
+ if (1 == dev-slave.cs) {
+ dev-base = ECSPI1_BASE_ADDR;
+ dev-ss = 1 ;
; again.
Also, Do you even need the ecspi thing? Doesn't uboot support some kind of imx
spi driver already?
M
+ dev-ss_pol = IMX_SPI_ACTIVE_LOW; /* SPI NOR */
+ dev-freq = 2500;
+ dev-fifo_sz = 64 * 4;
+ dev-us_delay = 0;
+ } else {
+ printf(%s: invalid chip select %d\n, __func__, dev-slave.cs);
+ rval = -EINVAL ;
+ }
+ return rval;
+}
+
+void spi_io_init(struct imx_spi_dev_t *dev, int active)
+{
+ if (dev-ss == 1)
+ gpio_set_value(83, active ? 0 : 1); /* GPIO 3.19 */
+}
+
+iomux_v3_cfg_t ecspi1_pads[] = {
+ /* SS1 */
+ MX6Q_PAD_EIM_D19__GPIO_3_19 | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6Q_PAD_EIM_D17__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6Q_PAD_EIM_D18__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6Q_PAD_EIM_D16__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
+};
+
+void setup_spi(void)
+{
+ gpio_direction_output(83, 1); /* GPIO 3.19 */
+ imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
+ ARRAY_SIZE(ecspi1_pads));
+}
+#endif
+
int board_early_init_f(void)
{
setup_iomux_uart();
@@ -140,6 +188,9 @@ int board_init(void)
/* address of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
+#ifdef CONFIG_IMX_ECSPI
+ setup_spi();
+#endif
return 0;
}
diff --git a/include/configs/mx6qsabrelite.h
b/include/configs/mx6qsabrelite.h index 464f0ec..48db42c 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -44,6 +44,21 @@
#define CONFIG_MXC_UART
#define CONFIG_MXC_UART_BASE UART2_BASE
+#define CONFIG_CMD_SF
+/*
+ * SPI Configs
+ */
+#ifdef CONFIG_CMD_SF
+ #define CONFIG_FSL_SF 1
+ #define CONFIG_SPI_FLASH 1
+ #define CONFIG_SPI_FLASH_SST1
+ #define CONFIG_SPI_FLASH_CS 1
+ #define CONFIG_IMX_ECSPI
+ #define IMX_CSPI_VER_2_31
+
+ #define MAX_SPI_BYTES (64 * 4)
+#endif
+
/* MMC Configs */
#define CONFIG_FSL_ESDHC
#define CONFIG_FSL_USDHC
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPI: Add i.MX ECSPI driver
On Thu, Jan 12, 2012 at 1:27 PM, Dirk Behme dirk.be...@de.bosch.com wrote:
+static s32 spi_reset(struct spi_slave *slave)
+{
+ u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
+ u32 pre_div = 0, post_div = 0, reg_ctrl, reg_config;
+ struct imx_spi_dev_t *dev = to_imx_spi_slave(slave);
+ struct spi_reg_t *reg = (dev-reg);
+
+ if (dev-freq == 0) {
+ printf(Error: desired clock is 0\n);
+ return 1;
I think that returning a negative error code, such as -EINVAL would be
better here.
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] i.mx6q: SabreLite: Add SPI NOR support
On Thu, Jan 12, 2012 at 1:38 PM, Marek Vasut marek.va...@gmail.com wrote: Also, Do you even need the ecspi thing? Doesn't uboot support some kind of imx spi driver already? Yes, this is the same question I have. Can't drivers/spi/mxc_spi.c be extended to support mx6? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] net: ll_temac: Add LL TEMAC driver to u-boot
Am Donnerstag, den 12.01.2012, 11:53 +0100 schrieb Michal Simek: Wolfgang Denk wrote: Dear Stephan Linz, But what would be the best implementation for unspecified targets here? The question is actually a very simple one here: is there any board configuration in mainline that will actually compile and link against this driver? If yes, then everything is fine. If not, we would not even know if there were gross syntax errors in that code, and we would never notce when changes to other parts break compatibility with it. This is why I will not add any code that is not used in mainline - out-of-tree users don't help a bit. OK. Stephan, please send v8 with suggested changes with all patches or link to patches which are necessary to use. Please also define fake address XILINX_LLTEMAC_BASEADDR in xparameters.h to be compiled. The same we will do for axi emac driver. Stephan if you like I can add that changes to my custodian git tree and do final testing before we ask Wolfgang to merge. I can release the v8 patch next week. I will do some tests on weekend before I post the results here on list. The next release will be prepared to support more than one TEMAC cores (LL_TEMAC0 nad LL_TEMAC1). So I need a little bit more time to test -- Best regards, Stephan Linz __ MB-Ref: http://www.li-pro.de/xilinx_mb:mbref:start OpenDCC: http://www.li-pro.net/opendcc.phtml PC/M: http://www.li-pro.net/pcm.phtml Sourceforge: http://sourceforge.net/users/slz Gitorious: https://gitorious.org/~slz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kirkwood_spi: correct access to irq_mask register
Problem appears to have been present since day one but masked because alignment
aborts were not enabled. ca4b55800ed7 arm, arm926ejs: always do cpu critical
inits turned on alignment aborts and uncovered this latent problem.
Signed-off-by: Ian Campbell i...@hellion.org.uk
Acked-By: Jason Cooper u-b...@lakedaemon.net
Tested-By: Holger Brunck holger.bru...@keymile.com
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
---
v2: Resending per patch submission guidelines.
---
drivers/spi/kirkwood_spi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index dfe542d..db8ba8b 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -66,7 +66,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned
int cs,
debug(data = 0x%08x \n, data);
writel(KWSPI_SMEMRDIRQ, spireg-irq_cause);
- writel(KWSPI_IRQMASK, spireg-irq_mask);
+ writel(KWSPI_IRQMASK, spireg-irq_mask);
/* program mpp registers to select SPI_CSn */
if (cs) {
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kirkwood_spi: correct access to irq_mask register
-Original Message-
From: Ian Campbell [mailto:i...@hellion.org.uk]
Sent: 12 January 2012 21:40
To: u-boot@lists.denx.de
Cc: Ian Campbell; Prafulla Wadaskar; Albert ARIBAUD
Subject: [PATCH] kirkwood_spi: correct access to irq_mask register
Problem appears to have been present since day one but masked because
alignment
aborts were not enabled. ca4b55800ed7 arm, arm926ejs: always do cpu
critical
inits turned on alignment aborts and uncovered this latent problem.
Signed-off-by: Ian Campbell i...@hellion.org.uk
Acked-By: Jason Cooper u-b...@lakedaemon.net
Tested-By: Holger Brunck holger.bru...@keymile.com
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
---
v2: Resending per patch submission guidelines.
---
drivers/spi/kirkwood_spi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index dfe542d..db8ba8b 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -66,7 +66,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
debug(data = 0x%08x \n, data);
writel(KWSPI_SMEMRDIRQ, spireg-irq_cause);
- writel(KWSPI_IRQMASK, spireg-irq_mask);
+ writel(KWSPI_IRQMASK, spireg-irq_mask);
/* program mpp registers to select SPI_CSn */
if (cs) {
Hi Ian
Thanks for the patch (resend :-) )
Actually it was in my pipeline.
I will pull this ASAP as well as other patches in my plate.
Regards..
Prafulla . ..
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] powerpc/srio: Correct the register defined errors in the struct ccsr_rio_t
On Jan 10, 2012, at 5:42 AM, Liu Gang wrote: + u32 didcar; /* 0xc - Device Identity CAR */ Drop the '0xc' prefix in the comment, same comment for all registers. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kirkwood_spi: correct access to irq_mask register
On Thu, 2012-01-12 at 08:22 -0800, Prafulla Wadaskar wrote:
-Original Message-
From: Ian Campbell [mailto:i...@hellion.org.uk]
Sent: 12 January 2012 21:40
To: u-boot@lists.denx.de
Cc: Ian Campbell; Prafulla Wadaskar; Albert ARIBAUD
Subject: [PATCH] kirkwood_spi: correct access to irq_mask register
Problem appears to have been present since day one but masked because
alignment
aborts were not enabled. ca4b55800ed7 arm, arm926ejs: always do cpu
critical
inits turned on alignment aborts and uncovered this latent problem.
Signed-off-by: Ian Campbell i...@hellion.org.uk
Acked-By: Jason Cooper u-b...@lakedaemon.net
Tested-By: Holger Brunck holger.bru...@keymile.com
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
---
v2: Resending per patch submission guidelines.
---
drivers/spi/kirkwood_spi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index dfe542d..db8ba8b 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -66,7 +66,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
debug(data = 0x%08x \n, data);
writel(KWSPI_SMEMRDIRQ, spireg-irq_cause);
- writel(KWSPI_IRQMASK, spireg-irq_mask);
+ writel(KWSPI_IRQMASK, spireg-irq_mask);
/* program mpp registers to select SPI_CSn */
if (cs) {
Hi Ian
Thanks for the patch (resend :-) )
Actually it was in my pipeline.
I will pull this ASAP as well as other patches in my plate.
Thanks!
Ian.
Regards..
Prafulla . ..
--
1.7.5.4
--
Ian Campbell
Current Noise: Monster Magnet - Cry
A kid'll eat the middle of an Oreo, eventually.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] tegra: Add I2C driver and associated parts
This series brings in an I2C driver for Tegra which can be configured by a flat device tree. It supports 8- and 16-bit addresses and both the normal I2C ports and the DVC port (for controlling the power management unit (PMU)). Recent Linux bindings are used, based on example .dts files found in branch for-3.3/dt at: git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git (I could not find the actual binding documentation to include here) Changes in v2: - Adjust definitions to fit new peripheral clock bindings - Change 'speed' to 'clock-frequency' - Remove u-boot,pinmux binding (sadly) - Use DIV_ROUND_UP() instead of a home-grown macro - Tidy comment style - Change i2c array to static - Remove i2c configuring using CONFIG (use fdt instead) - Make i2c/dvc decision come from fdt - Use new fdtdec alias decode function - Simplify code in i2c_addr_ok() - Return an error if an unavailable i2c bus is selected - Add build warning if CONFIG_SYS_I2C_INIT_BOARD is not defined - Disable port 2 as it is not used Simon Glass (6): tegra: Rename NV_PA_PMC_BASE to TEGRA2_PMC_BASE fdt: Add function to allow aliases to refer to multiple nodes tegra: fdt: Add extra I2C bindings for U-Boot tegra: Initialise I2C on Nvidia boards tegra: Select I2C ordering for Seaboard tegra: Enable I2C on Seaboard Yen Lin (1): tegra: Add I2C driver arch/arm/cpu/armv7/tegra2/ap20.c | 10 +- arch/arm/cpu/armv7/tegra2/board.c |2 +- arch/arm/dts/tegra20.dtsi | 10 +- arch/arm/include/asm/arch-tegra2/tegra2.h |4 +- arch/arm/include/asm/arch-tegra2/tegra2_i2c.h | 160 +++ board/nvidia/common/board.c |7 + board/nvidia/dts/tegra2-seaboard.dts | 10 + drivers/i2c/Makefile |1 + drivers/i2c/tegra2_i2c.c | 551 + include/configs/seaboard.h|8 + include/fdtdec.h | 17 + lib/fdtdec.c | 18 +- 12 files changed, 785 insertions(+), 13 deletions(-) create mode 100644 arch/arm/include/asm/arch-tegra2/tegra2_i2c.h create mode 100644 drivers/i2c/tegra2_i2c.c -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/7] tegra: Initialise I2C on Nvidia boards
This enables I2C on all Nvidia boards including Seaboard and Harmony. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Add build warning if CONFIG_SYS_I2C_INIT_BOARD is not defined board/nvidia/common/board.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c index a7c566d..ddcfcf4 100644 --- a/board/nvidia/common/board.c +++ b/board/nvidia/common/board.c @@ -34,6 +34,7 @@ #include asm/arch/uart.h #include spi.h #include asm/arch/usb.h +#include i2c.h #include board.h DECLARE_GLOBAL_DATA_PTR; @@ -69,6 +70,12 @@ int board_init(void) #endif /* boot param addr */ gd-bd-bi_boot_params = (NV_PA_SDRAM_BASE + 0x100); +#ifdef CONFIG_TEGRA2_I2C +#ifndef CONFIG_SYS_I2C_INIT_BOARD +#error You must define CONFIG_SYS_I2C_INIT_BOARD to use i2c on Nvidia boards +#endif + i2c_init_board(); +#endif #ifdef CONFIG_USB_EHCI_TEGRA /* For USB GPIO PD0. for now, since we have no pinmux in fdt */ -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/7] tegra: fdt: Add extra I2C bindings for U-Boot
Add U-Boot's peripheral clock information to the Tegra20 device tree file.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Adjust definitions to fit new peripheral clock bindings
- Change 'speed' to 'clock-frequency'
- Remove u-boot,pinmux binding (sadly)
arch/arm/dts/tegra20.dtsi | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index ca7b523..963cf27 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -45,6 +45,8 @@
compatible = nvidia,tegra20-i2c;
reg = 0x7000C000 0x100;
interrupts = 70 ;
+ clock-frequency = 10;
+ clocks = periph_clk 12; // PERIPH_ID_I2C1
};
i2c@7000c400 {
@@ -53,6 +55,8 @@
compatible = nvidia,tegra20-i2c;
reg = 0x7000C400 0x100;
interrupts = 116 ;
+ clock-frequency = 10;
+ clocks = periph_clk 54; // PERIPH_ID_I2C2
};
i2c@7000c500 {
@@ -61,14 +65,18 @@
compatible = nvidia,tegra20-i2c;
reg = 0x7000C500 0x100;
interrupts = 124 ;
+ clock-frequency = 10;
+ clocks = periph_clk 67; // PERIPH_ID_I2C3
};
i2c@7000d000 {
#address-cells = 1;
#size-cells = 0;
- compatible = nvidia,tegra20-i2c;
+ compatible = nvidia,tegra20-i2c-dvc;
reg = 0x7000D000 0x200;
interrupts = 85 ;
+ clock-frequency = 10;
+ clocks = periph_clk 47; // PERIPH_ID_DVC_I2C
};
i2s@70002800 {
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] tegra: Rename NV_PA_PMC_BASE to TEGRA2_PMC_BASE
Change this name to fit with the current convention in the Tegra
header file.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Stephen Warren swar...@nvidia.com
---
arch/arm/cpu/armv7/tegra2/ap20.c | 10 +-
arch/arm/cpu/armv7/tegra2/board.c |2 +-
arch/arm/include/asm/arch-tegra2/tegra2.h |4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c b/arch/arm/cpu/armv7/tegra2/ap20.c
index 4c44bb3..3ea2e26 100644
--- a/arch/arm/cpu/armv7/tegra2/ap20.c
+++ b/arch/arm/cpu/armv7/tegra2/ap20.c
@@ -105,14 +105,14 @@ static void enable_cpu_clock(int enable)
static int is_cpu_powered(void)
{
- struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
+ struct pmc_ctlr *pmc = (struct pmc_ctlr *)TEGRA2_PMC_BASE;
return (readl(pmc-pmc_pwrgate_status) CPU_PWRED) ? 1 : 0;
}
static void remove_cpu_io_clamps(void)
{
- struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
+ struct pmc_ctlr *pmc = (struct pmc_ctlr *)TEGRA2_PMC_BASE;
u32 reg;
/* Remove the clamps on the CPU I/O signals */
@@ -126,7 +126,7 @@ static void remove_cpu_io_clamps(void)
static void powerup_cpu(void)
{
- struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
+ struct pmc_ctlr *pmc = (struct pmc_ctlr *)TEGRA2_PMC_BASE;
u32 reg;
int timeout = IO_STABILIZATION_DELAY;
@@ -157,7 +157,7 @@ static void powerup_cpu(void)
static void enable_cpu_power_rail(void)
{
- struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
+ struct pmc_ctlr *pmc = (struct pmc_ctlr *)TEGRA2_PMC_BASE;
u32 reg;
reg = readl(pmc-pmc_cntrl);
@@ -277,7 +277,7 @@ void enable_scu(void)
void init_pmc_scratch(void)
{
- struct pmc_ctlr *const pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
+ struct pmc_ctlr *const pmc = (struct pmc_ctlr *)TEGRA2_PMC_BASE;
int i;
/* SCRATCH0 is initialized by the boot ROM and shouldn't be cleared */
diff --git a/arch/arm/cpu/armv7/tegra2/board.c
b/arch/arm/cpu/armv7/tegra2/board.c
index 410d0bd..77a627d 100644
--- a/arch/arm/cpu/armv7/tegra2/board.c
+++ b/arch/arm/cpu/armv7/tegra2/board.c
@@ -47,7 +47,7 @@ enum {
unsigned int query_sdram_size(void)
{
- struct pmc_ctlr *const pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
+ struct pmc_ctlr *const pmc = (struct pmc_ctlr *)TEGRA2_PMC_BASE;
u32 reg;
reg = readl(pmc-pmc_scratch20);
diff --git a/arch/arm/include/asm/arch-tegra2/tegra2.h
b/arch/arm/include/asm/arch-tegra2/tegra2.h
index baae2eb..ca1881e 100644
--- a/arch/arm/include/asm/arch-tegra2/tegra2.h
+++ b/arch/arm/include/asm/arch-tegra2/tegra2.h
@@ -39,7 +39,7 @@
#define NV_PA_APB_UARTD_BASE (NV_PA_APB_MISC_BASE + 0x6300)
#define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400)
#define TEGRA2_SPI_BASE(NV_PA_APB_MISC_BASE + 0xC380)
-#define NV_PA_PMC_BASE 0x7000E400
+#define TEGRA2_PMC_BASE(NV_PA_APB_MISC_BASE + 0xE400)
#define NV_PA_CSITE_BASE 0x7004
#define TEGRA_USB1_BASE0xC500
#define TEGRA_USB3_BASE0xC5008000
@@ -55,7 +55,7 @@ struct timerus {
unsigned int cntr_1us;
};
#else /* __ASSEMBLY__ */
-#define PRM_RSTCTRLNV_PA_PMC_BASE
+#define PRM_RSTCTRLTEGRA2_PMC_BASE
#endif
#endif /* TEGRA2_H */
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/7] tegra: Select I2C ordering for Seaboard
Select the port ordering for I2C on Seaboard.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Stephen Warren swar...@nvidia.com
---
Changes in v2:
- Disable port 2 as it is not used
board/nvidia/dts/tegra2-seaboard.dts | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/board/nvidia/dts/tegra2-seaboard.dts
b/board/nvidia/dts/tegra2-seaboard.dts
index 7a4ecae..d2cc428 100644
--- a/board/nvidia/dts/tegra2-seaboard.dts
+++ b/board/nvidia/dts/tegra2-seaboard.dts
@@ -15,6 +15,11 @@
/* This defines the order of our USB ports */
usb0 = /usb@c5008000;
usb1 = /usb@c500;
+
+ i2c0 = /i2c@7000d000;
+ i2c1 = /i2c@7000c000;
+ i2c2 = /i2c@7000c400;
+ i2c3 = /i2c@7000c500;
};
memory {
@@ -44,4 +49,9 @@
usb@c5004000 {
status = disabled;
};
+
+ i2c@7000c400 {
+ status = disabled;
+ };
+
};
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] fdt: Add function to allow aliases to refer to multiple nodes
Some devices can deal with multiple compatible properties. The devices
need to know which nodes to bind to which features. For example an
I2C driver which supports two different controller types will want to
know which type it is dealing with in each case.
The new fdtdec_add_aliases_for_id() function deals with this by allowing
the driver to search for additional compatible nodes for a different ID.
It can then detect the new ones and perform appropriate processing.
Another option considered was to return a tuple (node offset, compat id)
and have the function be passed a list of compatible IDs. This is more
overhead for the common case though. We may add such a function later if
more drivers in U-Boot require it.
Signed-off-by: Simon Glass s...@chromium.org
---
include/fdtdec.h | 15 +++
lib/fdtdec.c | 16
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index bdc..e6d63f9 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -200,6 +200,21 @@ int fdtdec_find_aliases_for_id(const void *blob, const
char *name,
enum fdt_compat_id id, int *node_list, int maxcount);
/*
+ * This function is similar to fdtdec_find_aliases_for_id() except that it
+ * adds to the node_list that is passed in. Any 0 elements are considered
+ * available for allocation - others are considered already used and are
+ * skipped.
+ *
+ * You can use this by calling fdtdec_find_aliases_for_id() with an
+ * uninitialised array, then setting the elements that are returned to -1,
+ * say, then calling this function, perhaps with a different compat id.
+ * Any elements you get back that are 0 are new nodes added by the call
+ * to this function.
+ */
+int fdtdec_add_aliases_for_id(const void *blob, const char *name,
+ enum fdt_compat_id id, int *node_list, int maxcount);
+
+/*
* Get the name for a compatible ID
*
* @param id Compatible ID to look for
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index daf2c7e..ddd56b9 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -151,10 +151,18 @@ int fdtdec_next_alias(const void *blob, const char *name,
return node;
}
-/* TODO: Can we tighten this code up a little? */
int fdtdec_find_aliases_for_id(const void *blob, const char *name,
enum fdt_compat_id id, int *node_list, int maxcount)
{
+ memset(node_list, '\0', sizeof(*node_list) * maxcount);
+
+ return fdtdec_add_aliases_for_id(blob, name, id, node_list, maxcount);
+}
+
+/* TODO: Can we tighten this code up a little? */
+int fdtdec_add_aliases_for_id(const void *blob, const char *name,
+ enum fdt_compat_id id, int *node_list, int maxcount)
+{
int name_len = strlen(name);
int nodes[maxcount];
int num_found = 0;
@@ -184,8 +192,6 @@ int fdtdec_find_aliases_for_id(const void *blob, const char
*name,
__func__, name);
/* Now find all the aliases */
- memset(node_list, '\0', sizeof(*node_list) * maxcount);
-
for (offset = fdt_first_property_offset(blob, alias_node);
offset 0;
offset = fdt_next_property_offset(blob, offset)) {
@@ -232,11 +238,13 @@ int fdtdec_find_aliases_for_id(const void *blob, const
char *name,
* it as done.
*/
if (fdtdec_get_is_enabled(blob, node)) {
+ if (node_list[number])
+ continue;
node_list[number] = node;
if (number = num_found)
num_found = number + 1;
}
- nodes[j] = 0;
+ nodes[found] = 0;
}
/* Add any nodes not mentioned by an alias */
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/7] tegra: Enable I2C on Seaboard
This enables I2C on Seaboard. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/seaboard.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index 6937bcc..1494fc0 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -64,6 +64,14 @@ #define CONFIG_CMD_SF #define CONFIG_SPI_FLASH_SIZE (4 20) +/* I2C */ +#define CONFIG_TEGRA2_I2C +#define CONFIG_SYS_I2C_INIT_BOARD +#define CONFIG_I2C_MULTI_BUS +#define CONFIG_SYS_MAX_I2C_BUS 4 +#define CONFIG_SYS_I2C_SPEED 10 +#define CONFIG_CMD_I2C + /* SD/MMC */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] tegra: Add I2C driver
From: Yen Lin ye...@nvidia.com
Add basic i2c driver for Tegra2 with 8- and 16-bit address support.
The driver requires CONFIG_OF_CONTROL to obtain its configuration
from the device tree.
(Simon Glass: s...@chromium.org modified for upstream)
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Use DIV_ROUND_UP() instead of a home-grown macro
- Tidy comment style
- Change i2c array to static
- Adjust definitions to fit new peripheral clock bindings
- Remove i2c configuring using CONFIG (use fdt instead)
- Make i2c/dvc decision come from fdt
- Use new fdtdec alias decode function
- Simplify code in i2c_addr_ok()
- Return an error if an unavailable i2c bus is selected
arch/arm/include/asm/arch-tegra2/tegra2_i2c.h | 160 +++
drivers/i2c/Makefile |1 +
drivers/i2c/tegra2_i2c.c | 551 +
include/fdtdec.h |2 +
lib/fdtdec.c |2 +
5 files changed, 716 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra2/tegra2_i2c.h
create mode 100644 drivers/i2c/tegra2_i2c.c
diff --git a/arch/arm/include/asm/arch-tegra2/tegra2_i2c.h
b/arch/arm/include/asm/arch-tegra2/tegra2_i2c.h
new file mode 100644
index 000..86f6a01
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra2/tegra2_i2c.h
@@ -0,0 +1,160 @@
+/*
+ * NVIDIA Tegra2 I2C controller
+ *
+ * Copyright 2010-2011 NVIDIA Corporation
+ *
+ * This software may be used and distributed according to the
+ * terms of the GNU Public License, Version 2, incorporated
+ * herein by reference.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _TEGRA2_I2C_H_
+#define _TEGRA2_I2C_H_
+
+#include asm/types.h
+
+/* Convert i2c slave address to be put on bus */
+#define I2C_ADDR_ON_BUS(chip) (chip 1)
+
+enum {
+ I2C_TIMEOUT_USEC = 1, /* Wait time for completion */
+ I2C_FIFO_DEPTH = 8, /* I2C fifo depth */
+};
+
+enum i2c_transaction_flags {
+ I2C_IS_WRITE = 0x1, /* for I2C write operation */
+ I2C_IS_10_BIT_ADDRESS = 0x2,/* for 10-bit I2C slave address */
+ I2C_USE_REPEATED_START = 0x4, /* for repeat start */
+ I2C_NO_ACK = 0x8, /* for slave that won't generate ACK */
+ I2C_SOFTWARE_CONTROLLER = 0x10, /* for I2C transfer using GPIO */
+ I2C_NO_STOP = 0x20,
+};
+
+/* Contians the I2C transaction details */
+struct i2c_trans_info {
+ /* flags to indicate the transaction details */
+ enum i2c_transaction_flags flags;
+ u32 address;/* I2C slave device address */
+ u32 num_bytes; /* number of bytes to be transferred */
+ /*
+* Send/receive buffer. For the I2C send operation this buffer should
+* be filled with the data to be sent to the slave device. For the I2C
+* receive operation this buffer is filled with the data received from
+* the slave device.
+*/
+ u8 *buf;
+ int is_10bit_address;
+};
+
+struct i2c_control {
+ u32 tx_fifo;
+ u32 rx_fifo;
+ u32 packet_status;
+ u32 fifo_control;
+ u32 fifo_status;
+ u32 int_mask;
+ u32 int_status;
+};
+
+struct dvc_ctlr {
+ u32 ctrl1; /* 00: DVC_CTRL_REG1 */
+ u32 ctrl2; /* 04: DVC_CTRL_REG2 */
+ u32 ctrl3; /* 08: DVC_CTRL_REG3 */
+ u32 status; /* 0C: DVC_STATUS_REG */
+ u32 ctrl; /* 10: DVC_I2C_CTRL_REG */
+ u32 addr_data; /* 14: DVC_I2C_ADDR_DATA_REG */
+ u32 reserved_0[2]; /* 18: */
+ u32 req;/* 20: DVC_REQ_REGISTER */
+ u32 addr_data3; /* 24: DVC_I2C_ADDR_DATA_REG_3 */
+ u32 reserved_1[6]; /* 28: */
+ u32 cnfg; /* 40: DVC_I2C_CNFG */
+ u32 cmd_addr0; /* 44: DVC_I2C_CMD_ADDR0 */
+ u32 cmd_addr1; /* 48: DVC_I2C_CMD_ADDR1 */
+ u32 cmd_data1; /* 4C: DVC_I2C_CMD_DATA1 */
+ u32 cmd_data2; /* 50: DVC_I2C_CMD_DATA2 */
+ u32 reserved_2[2]; /* 54: */
+ u32 i2c_status; /* 5C: DVC_I2C_STATUS */
+
Re: [U-Boot] [PATCH 7/7] tegra: Enable I2C on Seaboard
+U-Boot, which I seemed to have dropped by mistake Hi Stephen, On Thu, Jan 12, 2012 at 10:59 AM, Stephen Warren swar...@nvidia.com wrote: Simon Glass wrote at Wednesday, January 11, 2012 8:00 PM: On Mon, Jan 9, 2012 at 1:45 PM, Stephen Warren swar...@nvidia.com wrote: On 12/26/2011 11:11 AM, Simon Glass wrote: This enables I2C on Seaboard. ... diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h ... +#define CONFIG_SYS_I2C_INIT_BOARD I don't think that option is correct for Seaboard; the description in the README indicates this causes a function named i2c_init_board() to be called from boards/xxx/board.c, which is supposed to use GPIOs to unhang the I2C bus. However, this raises a couple of issues: 1) Patch 5 in this series calls i2c_init_board() ifdef CONFIG_TEGRA2_I2C rather than depending on this CONFIG option. 2) Tegra's i2c_init_board() doesn't appear to be anything to do with bus unhanging, but is instead regular I2C initialization. Perhaps the function should be renamed? I have had a bit of a look at this. From what I can see the problem is that i2c_init() is passed a bus speed, but this is just CONFIG_SYS_I2C_SPEED. We want to control the speed individually for each port. Yes would could use i2c_init() and ignore the speed, but that seems odd also. At least with the way it is we don't ignore the setting. We also don't define CONFIG_HARD_I2C which again seems odd, but I suppose is for the same reason (we don't want to call i2c_init()). Hmm. It sounds like we should replace CONFIG_TEGRA2_I2C with CONFIG_HARD_I2C given the README description of the latter? Well we could, but we would need to ignore the speed argument. Do you think that is better? Also U-Boot tends to call i2c_init() before every use of i2c, whereas we just want to init once and be done with it. I think the function name is correct, but perhaps I should change the #ifdef you mention in 1 above to CONFIG_SYS_I2C_INIT_BOARD. But for i2c to function on Tegra boards, this must be defined, so in fact this might be counterproductive. So perhaps a check that it is defined is best? But README explicitly says that i2c_init_board() is for bus unhanging which isn't what the Tegra implementation does. How can the function name be correct given that? Well we should rename the function IMO. It seems to me that with a a name like that it is for initing i2c on the board. Don't we just want to make i2c_init() use a global/static variable to determine whether the device has already been initialized, and defer all the init until first usage or something like that? That seems in line with U-Boot's desire not to initialize drivers until they're actually used. Actually that might work - if we keep i2c_init() a no-op, and wait until we get a request for a bus before we look up the fdt and init that port. But I suspect we might need to init port 0 immediately since there is no explicit call to i2c_set_bus_num() for that. It's a little wonky whatever we do. What do you think? (have just sent the series again with fdt changes, but can update once we sort this out). Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] tegra: Add I2C driver
Simon Glass wrote ednesday, January 11, 2012 9:18 PM:
On Mon, Jan 9, 2012 at 2:07 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/26/2011 11:11 AM, Simon Glass wrote:
From: Yen Lin ye...@nvidia.com
Add basic i2c driver for Tegra2 with 8- and 16-bit address support.
The driver supports building both with and without CONFIG_OF_CONTROL.
Without CONFIG_OF_CONTROL a number of CONFIG options must be supplied
in the board config header file:
I2CSPEED_KHZ - speed to run I2C bus at (typically 10)
CONFIG_I2Cx_PIN_MUX - pin mux setting for each port (P, 1, 2, 3)
(typically this will be 0 to bring the port out the common
pins)
...
...
diff --git a/drivers/i2c/tegra2_i2c.c b/drivers/i2c/tegra2_i2c.c
...
+struct i2c_bus i2c_controllers[CONFIG_SYS_MAX_I2C_BUS];
What if there are I2C bus extenders/muxes/... such that there are more
I2C buses in the system than Tegra I2C controllers? I'd rather see an
explicit TEGRA_I2C_NUM_CONTROLLERS define used throughout this patch.
We don't actually support CONFIG_I2C_MUX, so I can't see how that
could happen. Can you please explain a bit more?
We may not support it now, but I see no reason we won't in the future.
If we confuse the two defines now, it'll make it harder to allow muxes
in the future. The fix is simply using the correct define name within
the I2C driver isn't it; pretty simple.
+int i2c_init_board(void)
+{
+ struct i2c_bus *i2c_bus;
+ int index = 0;
+ int i;
+
+ /* build the i2c_controllers[] for each controller */
+ for (i = 0; i CONFIG_SYS_MAX_I2C_BUS; ++i) {
+ i2c_bus = i2c_controllers[i];
+ i2c_bus-id = i;
+
+ if (i2c_get_config(index, i2c_bus)) {
+ printf(i2c_init_board: failed to find bus %d\n,
i);
+ return -1;
+ }
+
+ if (i2c_bus-periph_id == PERIPH_ID_DVC_I2C)
+ i2c_bus-control =
+ ((struct dvc_ctlr
*)i2c_bus-regs)-control;
+ else
+ i2c_bus-control = i2c_bus-regs-control;
When instantiating controllers from device tree (as opposed to the
static !CONFIG_OF_CONTROL case), that conditional should be driven by
device tree properties. The kernel already represents this using two
separate compatible values for the different HW: nvidia,tegra20-i2c and
nvidia,tegra20-i2c-dvc.
Not in the device tree file I got from the kernel...has it changed?
Yes, the latest is:
i2c@7000c000 {
compatible = nvidia,tegra20-i2c;
i2c@7000c400 {
compatible = nvidia,tegra20-i2c;
i2c@7000c500 {
compatible = nvidia,tegra20-i2c;
i2c@7000d000 {
compatible = nvidia,tegra20-i2c-dvc;
+
+ i2c_init_controller(i2c_bus);
+ }
+
+ return 0;
+}
+void i2c_init(int speed, int slaveaddr)
+{
+ debug(i2c_init(speed=%u, slaveaddr=0x%x)\n, speed, slaveaddr);
+}
Surely that function needs to actually do something, at least set up the
clocks so that the (user?) requested rate is honored, or print an error
message if you're only allowed to use the hard-coded bus rate.
See my other message. I suppose we could reinit, but we really don't
want to honour the speed, since the fdt speed setting is then lost and
irrecoverable. For now it feels like we should ignore it.
Hmm. I suspect the answer here is roughly to override the following in
cmd_i2c.c:
/* TODO: Implement architecture-specific get/set functions */
unsigned int __def_i2c_get_bus_speed(void)
{
return CONFIG_SYS_I2C_SPEED;
}
unsigned int i2c_get_bus_speed(void)
__attribute__((weak, alias(__def_i2c_get_bus_speed)));
int __def_i2c_set_bus_speed(unsigned int speed)
{
if (speed != CONFIG_SYS_I2C_SPEED)
return -1;
return 0;
}
int i2c_set_bus_speed(unsigned int)
__attribute__((weak, alias(__def_i2c_set_bus_speed)));
To actually read/write the rate in use by the driver.
Then, fix do_i2c_reset() to use i2c_get_bus_speed() so it interacts
correctly with those functions.
There may be other places that need to be updates to use those function
instead of hard-coding CONFIG_SYS_I2C_SPEED too. Perhaps we could even
get away without defining CONFIG_SYS_I2C_SPEED for Tegra since it's
meaningless. Instead, ifdef those default function definitions above
based on whether CONFIG_SYS_I2C_SPEED is defined or not.
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] tegra: Enable I2C on Seaboard
Simon Glass wrote at Thursday, January 12, 2012 12:10 PM: On Thu, Jan 12, 2012 at 10:59 AM, Stephen Warren swar...@nvidia.com wrote: Simon Glass wrote at Wednesday, January 11, 2012 8:00 PM: ... Also U-Boot tends to call i2c_init() before every use of i2c, whereas we just want to init once and be done with it. I think the function name is correct, but perhaps I should change the #ifdef you mention in 1 above to CONFIG_SYS_I2C_INIT_BOARD. But for i2c to function on Tegra boards, this must be defined, so in fact this might be counterproductive. So perhaps a check that it is defined is best? But README explicitly says that i2c_init_board() is for bus unhanging which isn't what the Tegra implementation does. How can the function name be correct given that? Well we should rename the function IMO. It seems to me that with a a name like that it is for initing i2c on the board. You mean change the function that's activated by CONFIG_SYS_I2C_INIT_BOARD to be something more like i2c_unhang_board()? That makes sense to me. I have no idea how much of a hassle it'd be to update any existing boards. Don't we just want to make i2c_init() use a global/static variable to determine whether the device has already been initialized, and defer all the init until first usage or something like that? That seems in line with U-Boot's desire not to initialize drivers until they're actually used. Actually that might work - if we keep i2c_init() a no-op, and wait until we get a request for a bus before we look up the fdt and init that port. But I suspect we might need to init port 0 immediately since there is no explicit call to i2c_set_bus_num() for that. It's a little wonky whatever we do. What do you think? It does make sense to me to at least parse out all the DT stuff early on, so there's a single place to do all the alias processing etc. Given what I just wrote in the other email about fixing the I2C bus speed stuff, would making those changes here help this at all? -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] tegra: Enable I2C on Seaboard
Hi Stephen, On Thu, Jan 12, 2012 at 11:21 AM, Stephen Warren swar...@nvidia.com wrote: Simon Glass wrote at Thursday, January 12, 2012 12:10 PM: On Thu, Jan 12, 2012 at 10:59 AM, Stephen Warren swar...@nvidia.com wrote: Simon Glass wrote at Wednesday, January 11, 2012 8:00 PM: ... Also U-Boot tends to call i2c_init() before every use of i2c, whereas we just want to init once and be done with it. I think the function name is correct, but perhaps I should change the #ifdef you mention in 1 above to CONFIG_SYS_I2C_INIT_BOARD. But for i2c to function on Tegra boards, this must be defined, so in fact this might be counterproductive. So perhaps a check that it is defined is best? But README explicitly says that i2c_init_board() is for bus unhanging which isn't what the Tegra implementation does. How can the function name be correct given that? Well we should rename the function IMO. It seems to me that with a a name like that it is for initing i2c on the board. You mean change the function that's activated by CONFIG_SYS_I2C_INIT_BOARD to be something more like i2c_unhang_board()? That makes sense to me. I have no idea how much of a hassle it'd be to update any existing boards. Well we should change the README or change the function name. I'm not sure which is correct. Don't we just want to make i2c_init() use a global/static variable to determine whether the device has already been initialized, and defer all the init until first usage or something like that? That seems in line with U-Boot's desire not to initialize drivers until they're actually used. Actually that might work - if we keep i2c_init() a no-op, and wait until we get a request for a bus before we look up the fdt and init that port. But I suspect we might need to init port 0 immediately since there is no explicit call to i2c_set_bus_num() for that. It's a little wonky whatever we do. What do you think? It does make sense to me to at least parse out all the DT stuff early on, so there's a single place to do all the alias processing etc. Given what I just wrote in the other email about fixing the I2C bus speed stuff, would making those changes here help this at all? I think the device tree processing should be done later because i2c_init() is called very early, before the dcache is enabled. It is very s l o w to touch device tree before then. To be honest, that's another reason for leaving it as it is, with i2c_init() being a no-op. But we might be able to init the bus on first use with enough if() statements :-) I will take a look. I am not going to refactor U-Boot I2C here, although I think it could use a few tweaked... Regards, Simon -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] post/Makefile: Only build FP post tests if enabled via CONFIG_SYS_POST_FPU
Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- post/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/post/Makefile b/post/Makefile index 200e2f1..55b7d21 100644 --- a/post/Makefile +++ b/post/Makefile @@ -32,7 +32,7 @@ COBJS-$(CONFIG_POST_STD_LIST) += tests.o SPLIB-$(CONFIG_HAS_POST) = drivers/libpostdrivers.o SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d lib_$(ARCH) ]; then echo \ lib_$(ARCH)/libpost$(ARCH).o; fi) -SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d lib_$(ARCH)/fpu ]; then echo \ +SPLIB-$(CONFIG_SYS_POST_FPU) += $(shell if [ -d lib_$(ARCH)/fpu ]; then echo \ lib_$(ARCH)/fpu/libpost$(ARCH)fpu.o; fi) SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d cpu/$(CPU) ]; then echo \ cpu/$(CPU)/libpost$(CPU).o; fi) -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] tegra: Add tegra_get_chip_type() to detect SKU
Hi Stephen,
On Mon, Jan 9, 2012 at 3:24 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/26/2011 12:32 PM, Simon Glass wrote:
We want to know which type of chip we are running on - the Tegra
family has several SKUs. This can be determined by reading a
fuse register, so add this function to ap20.
...
diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c
b/arch/arm/cpu/armv7/tegra2/ap20.c
...
+int tegra_get_chip_type(void)
+{
+ struct fuse_regs *fuse = (struct fuse_regs *)TEGRA2_FUSE_BASE;
+ uint tegra_sku_id;
+
+ tegra_sku_id = readl(fuse-sku_info) 0xff;
+
+ switch (tegra_sku_id) {
I think this should read/validate/switch-on the SoC ID field too; I
assume the SKU IDs can only be interpreted relative to some specific SoC ID.
Chip ID is bits 15:8 of the register APB_MISC + 0x804, and has value
0x20 for Tegra20, 0x30 for Tegra30.
My TRM doesn't mention those values. What version are you referring
to? I have v06.
Regards,
Simon
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] tegra: Add tegra_get_chip_type() to detect SKU
Simon Glass wrote at Thursday, January 12, 2012 12:36 PM: On Mon, Jan 9, 2012 at 3:24 PM, Stephen Warren swar...@nvidia.com wrote: On 12/26/2011 12:32 PM, Simon Glass wrote: ... I think this should read/validate/switch-on the SoC ID field too; I assume the SKU IDs can only be interpreted relative to some specific SoC ID. Chip ID is bits 15:8 of the register APB_MISC + 0x804, and has value 0x20 for Tegra20, 0x30 for Tegra30. My TRM doesn't mention those values. What version are you referring to? I have v06. In both v06 and v01p (the public version), the register is in section 11.1.6.8. I guess that doesn't actually define the values of the fields, sigh. But, I can say that Tegra20 is 0x20 and Tegra30 is 0x30. For example, see: http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=arch/arm/mach-tegra/fuse.c;h=fd703f9c1621a6d93db787e60b0d1b6314f8fb3e;hb=android-tegra-nv-2.6.39 function void tegra_get_tegraid_from_hw, and: http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=arch/arm/mach-tegra/include/mach/hardware.h;h=d8f9bfbce42d4255d3e91db166f283a48bb4a8f2;hb=android-tegra-nv-2.6.39 for definitions of TEGRA_CHIPID_*. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] please pull u-boot-mpc85xx
The following changes since commit 9a4209869bd2c37affd931d627b3c3e72952: Rob Herring (1): ARM: highbank: enable networking and pxe are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Kyle Moffett (2): eXMeritus HWW-1U-1A: Minor environment variable tweaks eXMeritus HWW-1U-1A: Add support for the AT24C128N I2C EEPROM Paul Gortmaker (9): MPC85xxCDS: Fix missing LCRR_DBYP bits for 66-133MHz LBC Revert SBC8548: fix address mask to allow 64M flash sbc8548: relocate 64MB user flash to sane boundary sbc8548: enable ability to boot from alternate flash sbc8548: Fix LBC SDRAM initialization settings sbc8548: Make enabling SPD RAM configuration work sbc8548: relocate fixed ddr init code to ddr.c file sbc8548: enable support for hardware SPD errata workaround sbc8548: Fix up local bus init to be frequency aware board/freescale/mpc8541cds/mpc8541cds.c |2 +- board/freescale/mpc8555cds/mpc8555cds.c |2 +- board/sbc8548/ddr.c | 77 board/sbc8548/law.c | 16 +++- board/sbc8548/sbc8548.c | 111 +++ board/sbc8548/tlb.c | 24 - doc/README.sbc8548 | 79 +++- include/configs/HWW1U1A.h | 36 +++- include/configs/sbc8548.h | 151 --- 9 files changed, 389 insertions(+), 109 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/14] tegra: Add EMC support for optimal memory timings
Hi Stephen,
On Mon, Jan 9, 2012 at 3:38 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/26/2011 12:32 PM, Simon Glass wrote:
From: Jimmy Zhang jimmzh...@nvidia.com
Add support for setting up the memory controller parameters. Boards
can call tegra_set_emc() with a table containing the required
parameters.
...
diff --git a/arch/arm/cpu/armv7/tegra2/emc.c
b/arch/arm/cpu/armv7/tegra2/emc.c
...
+static const struct tegra_emc_table *tegra_emc_table;
+static int tegra_emc_table_size;
This isn't table_size, but number_of_tables or num_tables or
table_count. This sounds nit-picky, but it made me think about this
change more than I needed to given its simplicity.
OK changed to num_emc_tables.
+static const unsigned long emc_reg_addr[TEGRA_EMC_NUM_REGS] = {
+ 0x2c, /* RC */
For reference, I validated that the order or registers here matches that
in the DT binding that Olof published for the kernel, which is good.
http://patchwork.ozlabs.org/patch/132928/
Yes I would hope so :-) Thanks for checking. I can't see it committed,
so will reply on that thread.
+/* The EMC registers have shadow registers. When the EMC clock is updated
+ * in the clock controller, the shadow registers are copied to the active
+ * registers, allowing glitchless memory bus frequency changes.
+ * This function updates the shadow registers for a new clock frequency,
+ * and relies on the clock lock on the emc clock to avoid races between
+ * multiple frequency changes */
+#define EMC_SDRAM_RATE_T20 (333000 * 2 * 1000)
+#define EMC_SDRAM_RATE_T25 (38 * 2 * 1000)
...
+int tegra_set_emc(const struct tegra_emc_table *table, int table_size)
...
+ switch (tegra_get_chip_type()) {
+ case TEGRA_SOC_T20:
+ rate = EMC_SDRAM_RATE_T20;
+ break;
+ case TEGRA_SOC_T25:
+ rate = EMC_SDRAM_RATE_T25;
+ break;
+ default:
+ /* unknown chip type, no clk change*/
+ return -1;
+ }
I'm not convinced that limiting this to those two specific clocks is
correct. I've certainly seen BCTs that appear to run the EMC clock at
other frequencies. Specifically, for Seaboard, we appear to have BCTs
for 190, 333, 380, and 400MHz internally. I think a board should be able
to at least override the default rate selected by that switch statement.
OK. It might be time to move this to the fdt, I will take a look.
In tegra_emc_set_rate(), it's unclear to me why
clock_ll_set_source_divisor() is used to trigger use of the new EMC
register content, rather than say clock_set_rate(). I guess that's just
how the HW work?
It should be possible to do something like:
clock_adjust_periph_pll(PERIPH_ID_EMC, CLOCK_ID_MEMORY, 0,
clock_get_rate(CLOCK_ID_MEMORY));
although it is a lot less efficient. I will try it.
Regards,
Simon
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_source: introduce run_script()
Am Mittwoch 11 Januar 2012, 00:40:04 schrieb Mike Frysinger: although i wonder if it'd be possible to merge this into existing run_commands2() ... do we allow newlines now in variables that get run ? mh if the hush parser is enabled this seems to be true. eg. source() and run_commands2() use the same parse_string_outer(). btw. shouldnt set source() FLAG_EXIT_FROM_LOOP, too? i'm trying to unify things and just noticed this. -- michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-imx on Freescale MX28EVK
Hi Matthias, I have a fully functional U-Boot for the mx28evk board: - Both Ethernet ports work - Both MMC slots work - NAND works (if configure in, one MMC slot will be configured out, due to shared pins) - USB works - I2C works - Currently working on SPI It's basically an integration of u-boot-imx and Marek's work on m28evk_config in the mainline. I'm still working on making a posting-quality patch, but I'll be happy to help you out with a patch or a tar-ball, so feel free to drop me an email. Freescale's 2009.08 works too, but their script to get it on an sd-card is broken. I can get you a replacement for that one as well, but you'd better step up to a more recent version, because the MMC driver in the FreeScale version has a nasty bug in the MMC driver. This bug prevents you from loading files from a file system on an SD-Card. Robert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Stefano, Le 04/01/2012 17:57, Stefano Babic a écrit : Hi Albert, please pull from u-boot-imx, thanks. The following changes since commit a747cc0a8c55d69a56a6db80a35cdb48c853447d: tegra2: Optimize out-of-tree build for Ventana. (2011-12-24 10:23:32 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Eric Nelson (1): i.mx6q: mx6qarm2: Enable the usboh3 clock Fabio Estevam (6): net: imx: Add multi-FEC support for imx_get_mac_from_fuse mx28: Let imx_get_mac_from_fuse be common for mx28 mx28: Let dram_init be common for mx28 mx28evk: Add initial support for MX28EVK board mx28evk: Remove 'all' target from Makefile m28evk: Use GENERATED_GBL_DATA_SIZE Jason Liu (4): i.mx: i.mx6q: Add the enet clock function fec: add the i.mx6q enet driver support i.mx6q: arm2: Add the enet function support i.mx6:imx6q: allign MAC address with burned-in ordering Marek Vasut (1): MX28: Fix MXSBOOT segfault if no params specified Veli-Pekka Peltola (1): mx28: remove omap specific config options MAINTAINERS|1 + arch/arm/cpu/arm1136/mx35/generic.c|2 +- arch/arm/cpu/arm926ejs/mx25/generic.c |2 +- arch/arm/cpu/arm926ejs/mx27/generic.c |2 +- arch/arm/cpu/arm926ejs/mx28/mx28.c | 67 +++ arch/arm/cpu/arm926ejs/mx28/start.S|6 - arch/arm/cpu/armv7/mx6/clock.c |5 + arch/arm/cpu/armv7/mx6/soc.c | 16 ++- arch/arm/include/asm/arch-mx28/sys_proto.h |2 + arch/arm/include/asm/arch-mx6/imx-regs.h |4 +- board/denx/m28evk/m28evk.c | 53 + board/freescale/mx28evk/Makefile | 47 board/freescale/mx28evk/iomux.c| 138 ++ board/freescale/mx28evk/mx28evk.c | 169 ++ board/freescale/mx28evk/u-boot.bd | 14 +++ board/freescale/mx6qarm2/imximage.cfg |2 +- board/freescale/mx6qarm2/mx6qarm2.c| 90 ++ boards.cfg |1 + drivers/net/fec_mxc.c | 19 +++- drivers/net/fec_mxc.h |9 +- include/configs/m28evk.h |9 ++- include/configs/mx28evk.h | 176 include/configs/mx6qarm2.h | 12 ++- tools/mxsboot.c|3 + 24 files changed, 769 insertions(+), 80 deletions(-) create mode 100644 board/freescale/mx28evk/Makefile create mode 100644 board/freescale/mx28evk/iomux.c create mode 100644 board/freescale/mx28evk/mx28evk.c create mode 100644 board/freescale/mx28evk/u-boot.bd create mode 100644 include/configs/mx28evk.h Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] compile the u-boot
Hi there, Today I downloaded u-boot-2011.12. When I tried to build the u-boot for omap4_panda, I go the following error msg: /u-boot-2011.12/include/common.h:744: error: expected declaration specifiers or '...' before 'va_list' In file included from lib/asm-offsets.c:18: /u-boot-2011.12/include/common.h:777: error: expected declaration specifiers or '...' before 'va_list' make: *** [lib/asm-offsets.s] Error 1 What is the issue? Thanks, Jilin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, Le 04/01/2012 17:19, Tom Rini a écrit : Hi Albert, This replaces the pull request I sent for u-boot-ti/next back around Dec 23rd that wasn't pulled. The following changes since commit a747cc0a8c55d69a56a6db80a35cdb48c853447d: Thierry Reding (1): tegra2: Optimize out-of-tree build for Ventana. are available in the git repository at: git://git.denx.de/u-boot-ti.git master Aneesh V (1): omap4: fix boot issue on ES2.0 Panda Christian Riesch (3): arm, davinci: Use a common configuration file for da850evm and da850_am18xxevm da850evm: Remove CONFIG_SYS_xxCACHE_OFF defines arm, davinci: Change byte order of RTC kick register values Peter Barada (1): ARMV7: Add support For Logic OMAP35x/DM37x modules Peter Meerwald (1): beagle: add eeprom expansion board info for bct brettl3 Thomas Weber (1): OMAP3: Remove unused define CONFIG_OMAP3_*_DDR MAINTAINERS |4 + arch/arm/cpu/armv7/omap4/hwinit.c|4 +- arch/arm/include/asm/arch-davinci/hardware.h |4 +- arch/arm/include/asm/arch-omap4/omap.h |2 +- board/enbw/enbw_cmc/enbw_cmc.c |4 +- board/logicpd/omap3som/Makefile | 42 +++ board/logicpd/omap3som/omap3logic.c | 247 ++ board/logicpd/omap3som/omap3logic.h | 47 board/ti/beagle/beagle.c |4 + boards.cfg |3 +- include/configs/cm_t35.h |3 - include/configs/da850_am18xxevm.h| 246 - include/configs/da850evm.h |3 - include/configs/dig297.h |3 - include/configs/igep0020.h |3 - include/configs/igep0030.h |3 - include/configs/omap3_logic.h| 362 ++ include/configs/omap3_mvblx.h|3 - include/configs/omap3_overo.h|3 - include/configs/omap3_pandora.h |3 - include/configs/omap3_sdp3430.h |3 - include/configs/omap3_zoom1.h|3 - include/configs/omap3_zoom2.h|3 - 23 files changed, 715 insertions(+), 287 deletions(-) create mode 100644 board/logicpd/omap3som/Makefile create mode 100644 board/logicpd/omap3som/omap3logic.c create mode 100644 board/logicpd/omap3som/omap3logic.h delete mode 100644 include/configs/da850_am18xxevm.h create mode 100644 include/configs/omap3_logic.h Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] compile the u-boot
Hi Jilin, Le 12/01/2012 21:42, Jilin Zhou a écrit : Hi there, Today I downloaded u-boot-2011.12. When I tried to build the u-boot for omap4_panda, I go the following error msg: /u-boot-2011.12/include/common.h:744: error: expected declaration specifiers or '...' before 'va_list' In file included from lib/asm-offsets.c:18: /u-boot-2011.12/include/common.h:777: error: expected declaration specifiers or '...' before 'va_list' make: *** [lib/asm-offsets.s] Error 1 What is the issue? Seems it is on your side: I don't get these errors when I build this board, with ELDK42. What compiler and which build command do you us? Thanks, Jilin Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, arm-kirkwood: disable l2c before linux boot
Hi Michael, Le 02/01/2012 19:37, Michael Walle a écrit : Am Mittwoch 21 Dezember 2011, 00:35:46 schrieb Michael Walle: The decompressor expects the L2 cache to be disabled. This fixes booting some kernels, which have CONFIG_ARM_PATCH_PHYS_VIRT enabled. Ping :) Sorry, start of year was hectic. That's V2 of the patch, correct? But it has no V2 tag, nor history. Also, I'm missing something: you introduce two functions, for enabling and disabling the cache, yet the code uses only the one for disabling. So what enabled it in the first place? Regards, Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_source: introduce run_script()
Am Donnerstag 12 Januar 2012, 22:51:48 schrieb Michael Walle: Am Mittwoch 11 Januar 2012, 00:40:04 schrieb Mike Frysinger: although i wonder if it'd be possible to merge this into existing run_commands2() ... do we allow newlines now in variables that get run ? mh if the hush parser is enabled this seems to be true. eg. source() and run_commands2() use the same parse_string_outer(). Actually parse_string_outer() terminates on '\n'. So i think the current version of source() is broken. -- Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] tegra: Add EMC settings for Seaboard, Harmony
Hi Stephen,
On Tue, Jan 10, 2012 at 10:46 AM, Stephen Warren swar...@nvidia.com wrote:
On 12/26/2011 12:33 PM, Simon Glass wrote:
From: Jimmy Zhang jimmzh...@nvidia.com
Set Seaboard and Harmony to optimal memory settings based on the SOC
in use (T20 or T25).
Signed-off-by: Simon Glass s...@chromium.org
diff --git a/board/nvidia/common/emc.c b/board/nvidia/common/emc.c
...
+static const struct tegra_emc_table seaboard_emc_tables_hynix_333Mhz[] = {
...
+static const struct tegra_emc_table seaboard_emc_tables_hynix_380Mhz[] = {
...
+void seaboard_emc_init(void)
...
+static struct emc_init board_table[] = {
+ {
+ .id = MACH_TYPE_HARMONY,
+ .init = NULL,
+ },
+ {
+ .id = MACH_TYPE_SEABOARD,
+ .init = seaboard_emc_init,
+ },
+};
Why not just put the Seaboard-specific code into Seaboard's board
directory instead of a common location? Then you wouldn't need this
table at all, and boards other than Seaboard wouldn't be required to
carry the Seaboard EMC tables.
I have moved this into the device tree.
There don't appear to be any tables for Harmony, which is inconsistent
with the commit description.
Updated the commit description :-)
+int board_emc_init(void)
+{
+ int i;
+ DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_TEGRA_PMU
+ /* if voltage has not been set properly, return */
+ if (!pmu_is_voltage_nominal())
+ return -1;
+#endif
Why/when would the PMU voltage not be nominal?
On boot, it starts up lower and we raise it to nominal so we can run
at full speed.
Can't we error out the compile if the options that cause the PMU voltage
to be initialized to nominal are not set, instead of detecting this at
runtime?
I don't think so, since we can't know in U-Boot what the start-up voltages are.
Finally, I don't think there are EMC tables here for all the EMC
frequencies that we have BCTs for. Perhaps that's not an issue, and
perhaps I should ignore the other BCTs (e.g. 400MHZ EMC) since nobody
actually uses them?
Yes I think maximum speed is all anyone is probably interested in now.
Regards,
Simon
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/14] tegra: Add PMU to manage power supplies
Hi Stephen, On Tue, Jan 10, 2012 at 9:56 AM, Stephen Warren swar...@nvidia.com wrote: On 12/26/2011 12:33 PM, Simon Glass wrote: From: Jimmy Zhang jimmzh...@nvidia.com Power supplies must be adjusted in line with clock frequency. This code provides a simple routine to set the voltage to allow operation at maximum frequency. Signed-off-by: Simon Glass s...@chromium.org --- arch/arm/cpu/armv7/tegra2/Makefile | 1 + arch/arm/cpu/armv7/tegra2/pmu.c | 355 arch/arm/include/asm/arch-tegra2/pmu.h | 63 ++ 3 files changed, 419 insertions(+), 0 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/pmu.c create mode 100644 arch/arm/include/asm/arch-tegra2/pmu.h This driver appears to be for an I2C-based device, so I assume it'd for a particular PMIC not Tegra's PMC HW module. I imagine this is a driver for the TI TPS6586X, right? As such, naming this pmu and putting it into the Tegra directory doesn't make sense. There should be a generic TPS6586X driver, and possibly a separate file and patch to implement the use of that chip in conjunction with Tegra. Oh dear, but yes you are right. It is a TPS658621C according to my schematic. I will leap into this also. Regards, Simon -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] tegra: Add EMC settings for Seaboard, Harmony
Simon Glass wrote at Thursday, January 12, 2012 4:05 PM:
On Tue, Jan 10, 2012 at 10:46 AM, Stephen Warren swar...@nvidia.com wrote:
On 12/26/2011 12:33 PM, Simon Glass wrote:
From: Jimmy Zhang jimmzh...@nvidia.com
Set Seaboard and Harmony to optimal memory settings based on the SOC
in use (T20 or T25).
...
+int board_emc_init(void)
+{
+ int i;
+ DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_TEGRA_PMU
+ /* if voltage has not been set properly, return */
+ if (!pmu_is_voltage_nominal())
+ return -1;
+#endif
Why/when would the PMU voltage not be nominal?
On boot, it starts up lower and we raise it to nominal so we can run
at full speed.
Can't we error out the compile if the options that cause the PMU voltage
to be initialized to nominal are not set, instead of detecting this at
runtime?
I don't think so, since we can't know in U-Boot what the start-up voltages
are.
So how does the system get to the nominal state? And if board_emc_init()
is called when the system isn't in the nominal state, does it somehow get
called again later once it is, so that the EMC initialization doesn't fail
the error-check quoted above?
In other words, presumably U-Boot explicitly programs the PMU into the
nominal stage at some point. Shouldn't we defer calling board_emc_init()
until after that time, thus making that error-check redundant?
Finally, I don't think there are EMC tables here for all the EMC
frequencies that we have BCTs for. Perhaps that's not an issue, and
perhaps I should ignore the other BCTs (e.g. 400MHZ EMC) since nobody
actually uses them?
Yes I think maximum speed is all anyone is probably interested in now.
400MHz is faster than the entries in the table in this change, IIRC.
But if the tables in this change are for the standard frequencies average
people use (i.e. not those doing board/memory quals), it's probably fine.
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/14] tegra: Set up PMU for Nvidia boards
Hi Stephen, On Tue, Jan 10, 2012 at 10:02 AM, Stephen Warren swar...@nvidia.com wrote: On 12/26/2011 12:33 PM, Simon Glass wrote: Adjust PMU to permit maximum frequency operation. ... diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c ... +#ifdef CONFIG_TEGRA2_I2C + i2c_init_board(); + +#ifdef CONFIG_TEGRA_PMU + pmu_set_nominal(); +#endif +#endif + return 0; } I think there's some patch confusion here; weren't the outer ifdef and call to i2c_init_board() added in the I2C patch series too? Yes, I moved some code around and duplicated it. I will fix this. Regards, Simon -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/14] tegra: Add PMU to manage power supplies
Simon Glass wrote at Thursday, January 12, 2012 4:17 PM: On Tue, Jan 10, 2012 at 9:56 AM, Stephen Warren swar...@nvidia.com wrote: On 12/26/2011 12:33 PM, Simon Glass wrote: From: Jimmy Zhang jimmzh...@nvidia.com Power supplies must be adjusted in line with clock frequency. This code provides a simple routine to set the voltage to allow operation at maximum frequency. Signed-off-by: Simon Glass s...@chromium.org --- arch/arm/cpu/armv7/tegra2/Makefile | 1 + arch/arm/cpu/armv7/tegra2/pmu.c | 355 arch/arm/include/asm/arch-tegra2/pmu.h | 63 ++ 3 files changed, 419 insertions(+), 0 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/pmu.c create mode 100644 arch/arm/include/asm/arch-tegra2/pmu.h This driver appears to be for an I2C-based device, so I assume it'd for a particular PMIC not Tegra's PMC HW module. I imagine this is a driver for the TI TPS6586X, right? As such, naming this pmu and putting it into the Tegra directory doesn't make sense. There should be a generic TPS6586X driver, and possibly a separate file and patch to implement the use of that chip in conjunction with Tegra. Oh dear, but yes you are right. It is a TPS658621C according to my schematic. I will leap into this also. I believe some number of the devices are compatible, hence the kernel has a tps6586x driver rather than more individual drivers for each value of x. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/14] tegra: Add PMU to manage power supplies
Hi Stephen, On Thu, Jan 12, 2012 at 3:43 PM, Stephen Warren swar...@nvidia.com wrote: Simon Glass wrote at Thursday, January 12, 2012 4:17 PM: On Tue, Jan 10, 2012 at 9:56 AM, Stephen Warren swar...@nvidia.com wrote: On 12/26/2011 12:33 PM, Simon Glass wrote: From: Jimmy Zhang jimmzh...@nvidia.com Power supplies must be adjusted in line with clock frequency. This code provides a simple routine to set the voltage to allow operation at maximum frequency. Signed-off-by: Simon Glass s...@chromium.org --- arch/arm/cpu/armv7/tegra2/Makefile | 1 + arch/arm/cpu/armv7/tegra2/pmu.c | 355 arch/arm/include/asm/arch-tegra2/pmu.h | 63 ++ 3 files changed, 419 insertions(+), 0 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/pmu.c create mode 100644 arch/arm/include/asm/arch-tegra2/pmu.h This driver appears to be for an I2C-based device, so I assume it'd for a particular PMIC not Tegra's PMC HW module. I imagine this is a driver for the TI TPS6586X, right? As such, naming this pmu and putting it into the Tegra directory doesn't make sense. There should be a generic TPS6586X driver, and possibly a separate file and patch to implement the use of that chip in conjunction with Tegra. Oh dear, but yes you are right. It is a TPS658621C according to my schematic. I will leap into this also. I believe some number of the devices are compatible, hence the kernel has a tps6586x driver rather than more individual drivers for each value of x. OK I will follow along with that. Regards, Simon -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] tegra: Add EMC settings for Seaboard, Harmony
Simon Glass wrote at Thursday, January 12, 2012 4:55 PM:
On Thu, Jan 12, 2012 at 3:42 PM, Stephen Warren swar...@nvidia.com wrote:
Simon Glass wrote at Thursday, January 12, 2012 4:05 PM:
On Tue, Jan 10, 2012 at 10:46 AM, Stephen Warren swar...@nvidia.com
wrote:
On 12/26/2011 12:33 PM, Simon Glass wrote:
From: Jimmy Zhang jimmzh...@nvidia.com
Set Seaboard and Harmony to optimal memory settings based on the SOC
in use (T20 or T25).
...
+int board_emc_init(void)
+{
+ int i;
+ DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_TEGRA_PMU
+ /* if voltage has not been set properly, return */
+ if (!pmu_is_voltage_nominal())
+ return -1;
+#endif
Why/when would the PMU voltage not be nominal?
On boot, it starts up lower and we raise it to nominal so we can run
at full speed.
Can't we error out the compile if the options that cause the PMU voltage
to be initialized to nominal are not set, instead of detecting this at
runtime?
I don't think so, since we can't know in U-Boot what the start-up voltages
are.
So how does the system get to the nominal state? And if board_emc_init()
is called when the system isn't in the nominal state, does it somehow get
called again later once it is, so that the EMC initialization doesn't fail
the error-check quoted above?
We call board_emc_init() after pmu_set_nominal().
In other words, presumably U-Boot explicitly programs the PMU into the
nominal stage at some point. Shouldn't we defer calling board_emc_init()
until after that time, thus making that error-check redundant?
Yes, but if you look at the patch above, that's what we do:
#ifdef CONFIG_TEGRA_PMU
pmu_set_nominal();
+
+ board_emc_init();
#endif
#endif
OK, so in practice,
/* if voltage has not been set properly, return */
if (!pmu_is_voltage_nominal())
... will never fire. My original point was that if so, why is that check
needed? I suppose it's a reasonable safety net though - that's the
reason?
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx28evk_config integration
On Thu, Jan 12, 2012 at 8:07 PM, Robert Deliën rob...@delien.nl wrote: Hi Stefano, Can I post a patch for your u-boot-imx tree with my integration of extra subsystems for the mx28evk board, or should I wait until your work on mx28evk_config is in the mainline? I think it is OK if you post patches against Stefano's imx tree. By the way, I have the stranges issue with both your mx28evk_config, Marek's m28evk_config and my combined version: When I'm booting a Kernel that works perfectly well with the old FreeScale 2009.08 U-boot, the Kernel just hang during the boot process. It seems like something goes wrong in emi_set_rate in the Kernel. If you could point me into the right direction, I'd really appreciate it. Which kernel version are you using? Please post the full U-boot and kernel output messages. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] tegra: Add EMC settings for Seaboard, Harmony
Simon Glass wrote at Thursday, January 12, 2012 5:06 PM:
On Thu, Jan 12, 2012 at 4:01 PM, Stephen Warren swar...@nvidia.com wrote:
Simon Glass wrote at Thursday, January 12, 2012 4:55 PM:
On Thu, Jan 12, 2012 at 3:42 PM, Stephen Warren swar...@nvidia.com wrote:
Simon Glass wrote at Thursday, January 12, 2012 4:05 PM:
On Tue, Jan 10, 2012 at 10:46 AM, Stephen Warren swar...@nvidia.com
wrote:
On 12/26/2011 12:33 PM, Simon Glass wrote:
From: Jimmy Zhang jimmzh...@nvidia.com
Set Seaboard and Harmony to optimal memory settings based on the SOC
in use (T20 or T25).
...
+int board_emc_init(void)
+{
+ int i;
+ DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_TEGRA_PMU
+ /* if voltage has not been set properly, return */
+ if (!pmu_is_voltage_nominal())
+ return -1;
+#endif
Why/when would the PMU voltage not be nominal?
On boot, it starts up lower and we raise it to nominal so we can run
at full speed.
Can't we error out the compile if the options that cause the PMU
voltage
to be initialized to nominal are not set, instead of detecting this at
runtime?
I don't think so, since we can't know in U-Boot what the start-up
voltages are.
So how does the system get to the nominal state? And if board_emc_init()
is called when the system isn't in the nominal state, does it somehow get
called again later once it is, so that the EMC initialization doesn't
fail
the error-check quoted above?
We call board_emc_init() after pmu_set_nominal().
In other words, presumably U-Boot explicitly programs the PMU into the
nominal stage at some point. Shouldn't we defer calling board_emc_init()
until after that time, thus making that error-check redundant?
Yes, but if you look at the patch above, that's what we do:
#ifdef CONFIG_TEGRA_PMU
pmu_set_nominal();
+
+ board_emc_init();
#endif
#endif
OK, so in practice,
/* if voltage has not been set properly, return */
if (!pmu_is_voltage_nominal())
... will never fire. My original point was that if so, why is that check
needed? I suppose it's a reasonable safety net though - that's the
reason?
OK I see. It certainly shouldn't - it is a check that everything is
well since this code is in a different file and it is possible that
someone may get this wrong. If they do then the system may continue
but die later in interesting ways. Still, the user has other equally
complex things to worry about.
I'm happy to remove this particularly as this might become example
code for other boards - what do you think?
The check itself is probably fine for the reasons you state. However,
I'd suggest adjusting the comment to something more like:
This code should only be called once the PMU is operating at nominal
voltage. Hence, this test should never fail. However, this prevents
unpredictable failures from occurring later if this pre-condition is
not met.
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] tegra: Add EMC settings for Seaboard, Harmony
Hi Stephen,
On Thu, Jan 12, 2012 at 4:10 PM, Stephen Warren swar...@nvidia.com wrote:
Simon Glass wrote at Thursday, January 12, 2012 5:06 PM:
On Thu, Jan 12, 2012 at 4:01 PM, Stephen Warren swar...@nvidia.com wrote:
Simon Glass wrote at Thursday, January 12, 2012 4:55 PM:
On Thu, Jan 12, 2012 at 3:42 PM, Stephen Warren swar...@nvidia.com
wrote:
Simon Glass wrote at Thursday, January 12, 2012 4:05 PM:
On Tue, Jan 10, 2012 at 10:46 AM, Stephen Warren swar...@nvidia.com
wrote:
On 12/26/2011 12:33 PM, Simon Glass wrote:
From: Jimmy Zhang jimmzh...@nvidia.com
Set Seaboard and Harmony to optimal memory settings based on the SOC
in use (T20 or T25).
...
+int board_emc_init(void)
+{
+ int i;
+ DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_TEGRA_PMU
+ /* if voltage has not been set properly, return */
+ if (!pmu_is_voltage_nominal())
+ return -1;
+#endif
Why/when would the PMU voltage not be nominal?
On boot, it starts up lower and we raise it to nominal so we can run
at full speed.
Can't we error out the compile if the options that cause the PMU
voltage
to be initialized to nominal are not set, instead of detecting this
at
runtime?
I don't think so, since we can't know in U-Boot what the start-up
voltages are.
So how does the system get to the nominal state? And if board_emc_init()
is called when the system isn't in the nominal state, does it somehow
get
called again later once it is, so that the EMC initialization doesn't
fail
the error-check quoted above?
We call board_emc_init() after pmu_set_nominal().
In other words, presumably U-Boot explicitly programs the PMU into the
nominal stage at some point. Shouldn't we defer calling board_emc_init()
until after that time, thus making that error-check redundant?
Yes, but if you look at the patch above, that's what we do:
#ifdef CONFIG_TEGRA_PMU
pmu_set_nominal();
+
+ board_emc_init();
#endif
#endif
OK, so in practice,
/* if voltage has not been set properly, return */
if (!pmu_is_voltage_nominal())
... will never fire. My original point was that if so, why is that check
needed? I suppose it's a reasonable safety net though - that's the
reason?
OK I see. It certainly shouldn't - it is a check that everything is
well since this code is in a different file and it is possible that
someone may get this wrong. If they do then the system may continue
but die later in interesting ways. Still, the user has other equally
complex things to worry about.
I'm happy to remove this particularly as this might become example
code for other boards - what do you think?
The check itself is probably fine for the reasons you state. However,
I'd suggest adjusting the comment to something more like:
This code should only be called once the PMU is operating at nominal
voltage. Hence, this test should never fail. However, this prevents
unpredictable failures from occurring later if this pre-condition is
not met.
OK, will do.
Regards,
Simon
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3 v3] serial: add LPC32X0 high-speed UART devices support
This change adds an implementation of high-speed UART found on NXP
LPC32X0 SoCs. Such UARTs are enumerated as UART1, UART2 and UART7.
Signed-off-by: Vladimir Zapolskiy v...@mleia.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Wolfgang Denk w...@denx.de
---
Changes from v2 to v3:
* renamed struct hsuart_t to hsuart_regs
Changes from v1 to v2:
* simplified lpc32xx_hsuart_init() a little
* put SoC specific changes into patch 1/3
arch/arm/include/asm/arch-lpc32xx/uart.h | 60
drivers/serial/Makefile |1 +
drivers/serial/lpc32xx_hsuart.c | 112 ++
3 files changed, 173 insertions(+), 0 deletions(-)
create mode 100644 drivers/serial/lpc32xx_hsuart.c
diff --git a/arch/arm/include/asm/arch-lpc32xx/uart.h
b/arch/arm/include/asm/arch-lpc32xx/uart.h
index b613df8..ec12893 100644
--- a/arch/arm/include/asm/arch-lpc32xx/uart.h
+++ b/arch/arm/include/asm/arch-lpc32xx/uart.h
@@ -22,6 +22,66 @@
#include asm/types.h
+/* 14-clock UART Registers */
+struct hsuart_regs {
+ union {
+ u32 rx; /* Receiver FIFO*/
+ u32 tx; /* Transmitter FIFO */
+ };
+ u32 level; /* FIFO Level Register */
+ u32 iir;/* Interrupt ID Register*/
+ u32 ctrl; /* Control Register */
+ u32 rate; /* Rate Control Register*/
+};
+
+/* 14-clock UART Receiver FIFO Register bits */
+#define HSUART_RX_BREAK(1 10)
+#define HSUART_RX_ERROR(1 9)
+#define HSUART_RX_EMPTY(1 8)
+#define HSUART_RX_DATA (0xff 0)
+
+/* 14-clock UART Level Register bits */
+#define HSUART_LEVEL_TX(0xff 8)
+#define HSUART_LEVEL_RX(0xff 0)
+
+/* 14-clock UART Interrupt Identification Register bits */
+#define HSUART_IIR_TX_INT_SET (1 6)
+#define HSUART_IIR_RX_OE (1 5)
+#define HSUART_IIR_BRK (1 4)
+#define HSUART_IIR_FE (1 3)
+#define HSUART_IIR_RX_TIMEOUT (1 2)
+#define HSUART_IIR_RX_TRIG (1 1)
+#define HSUART_IIR_TX (1 0)
+
+/* 14-clock UART Control Register bits */
+#define HSUART_CTRL_HRTS_INV (1 21)
+#define HSUART_CTRL_HRTS_TRIG_48 (0x3 19)
+#define HSUART_CTRL_HRTS_TRIG_32 (0x2 19)
+#define HSUART_CTRL_HRTS_TRIG_16 (0x1 19)
+#define HSUART_CTRL_HRTS_TRIG_8(0x0 19)
+#define HSUART_CTRL_HRTS_EN(1 18)
+#define HSUART_CTRL_TMO_16 (0x3 16)
+#define HSUART_CTRL_TMO_8 (0x2 16)
+#define HSUART_CTRL_TMO_4 (0x1 16)
+#define HSUART_CTRL_TMO_DISABLED (0x0 16)
+#define HSUART_CTRL_HCTS_INV (1 15)
+#define HSUART_CTRL_HCTS_EN(1 14)
+#define HSUART_CTRL_HSU_OFFSET(n) ((n) 9)
+#define HSUART_CTRL_HSU_BREAK (1 8)
+#define HSUART_CTRL_HSU_ERR_INT_EN (1 7)
+#define HSUART_CTRL_HSU_RX_INT_EN (1 6)
+#define HSUART_CTRL_HSU_TX_INT_EN (1 5)
+#define HSUART_CTRL_HSU_RX_TRIG_48 (0x5 2)
+#define HSUART_CTRL_HSU_RX_TRIG_32 (0x4 2)
+#define HSUART_CTRL_HSU_RX_TRIG_16 (0x3 2)
+#define HSUART_CTRL_HSU_RX_TRIG_8 (0x2 2)
+#define HSUART_CTRL_HSU_RX_TRIG_4 (0x1 2)
+#define HSUART_CTRL_HSU_RX_TRIG_1 (0x0 2)
+#define HSUART_CTRL_HSU_TX_TRIG_16 (0x3 0)
+#define HSUART_CTRL_HSU_TX_TRIG_8 (0x2 0)
+#define HSUART_CTRL_HSU_TX_TRIG_4 (0x1 0)
+#define HSUART_CTRL_HSU_TX_TRIG_0 (0x0 0)
+
/* UART Control Registers */
struct uart_ctrl_regs {
u32 ctrl; /* Control Register */
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 616b857..65d0f23 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -29,6 +29,7 @@ COBJS-$(CONFIG_ALTERA_UART) += altera_uart.o
COBJS-$(CONFIG_ALTERA_JTAG_UART) += altera_jtag_uart.o
COBJS-$(CONFIG_ARM_DCC) += arm_dcc.o
COBJS-$(CONFIG_ATMEL_USART) += atmel_usart.o
+COBJS-$(CONFIG_LPC32XX_HSUART) += lpc32xx_hsuart.o
COBJS-$(CONFIG_MCFUART) += mcfuart.o
COBJS-$(CONFIG_NS9750_UART) += ns9750_serial.o
COBJS-$(CONFIG_OPENCORES_YANU) += opencores_yanu.o
diff --git a/drivers/serial/lpc32xx_hsuart.c b/drivers/serial/lpc32xx_hsuart.c
new file mode 100644
index 000..e435343
--- /dev/null
+++ b/drivers/serial/lpc32xx_hsuart.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2011 Vladimir Zapolskiy v...@mleia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; 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
[U-Boot] [PATCH 0/3 v3] devkit3250: add Timll DevKit3250 board initial support
This patchset adds generic NXP LPC32XX SoC support and basic support for Embest/Timll DevKit3250 board, which powered by this SoC. The patchset is done on top of u-boot/master branch. The general difference of this resent series from the previous ones is that high speed UART driver was added into support. Changes from v2 to v3 * renamed register structures from *_t to *_regs * renamed clkpwr.c file to clk.c * fixed bi_boot_params initialization * applied some cosmetic fixes Changes from v1 to v2: * setbits_le32() and similar helpers are used * added general arch_cpu_init() routine Vladimir Zapolskiy (3): arm926ejs: add NXP LPC32x0 cpu series support serial: add LPC32X0 high-speed UART devices support devkit3250: add Timll DevKit3250 board initial support MAINTAINERS |4 + arch/arm/cpu/arm926ejs/lpc32xx/Makefile | 45 +++ arch/arm/cpu/arm926ejs/lpc32xx/clk.c | 117 + arch/arm/cpu/arm926ejs/lpc32xx/cpu.c | 70 ++ arch/arm/cpu/arm926ejs/lpc32xx/devices.c | 52 arch/arm/cpu/arm926ejs/lpc32xx/timer.c| 90 + arch/arm/include/asm/arch-lpc32xx/clk.h | 170 + arch/arm/include/asm/arch-lpc32xx/config.h| 76 +++ arch/arm/include/asm/arch-lpc32xx/cpu.h | 64 + arch/arm/include/asm/arch-lpc32xx/emc.h | 92 + arch/arm/include/asm/arch-lpc32xx/sys_proto.h | 25 arch/arm/include/asm/arch-lpc32xx/timer.h | 74 +++ arch/arm/include/asm/arch-lpc32xx/uart.h | 114 + arch/arm/include/asm/arch-lpc32xx/wdt.h | 51 board/timll/devkit3250/Makefile | 44 +++ board/timll/devkit3250/devkit3250.c | 65 ++ boards.cfg|1 + drivers/serial/Makefile |1 + drivers/serial/lpc32xx_hsuart.c | 112 include/configs/devkit3250.h | 117 + 20 files changed, 1384 insertions(+), 0 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/Makefile create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/clk.c create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/cpu.c create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/devices.c create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/timer.c create mode 100644 arch/arm/include/asm/arch-lpc32xx/clk.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/config.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/cpu.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/emc.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/sys_proto.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/timer.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/uart.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/wdt.h create mode 100644 board/timll/devkit3250/Makefile create mode 100644 board/timll/devkit3250/devkit3250.c create mode 100644 drivers/serial/lpc32xx_hsuart.c create mode 100644 include/configs/devkit3250.h -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3 v5] devkit3250: add Timll DevKit3250 board initial support
This change adds a basic support for Embest/Timll DevKit3250 board,
NOR and UART are the only supported peripherals for a moment. The board
doesn't require low-level init, because the initial SDRAM and GPIO
configuration is performed during kickstart bootloader execution.
Signed-off-by: Vladimir Zapolskiy v...@mleia.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Wolfgang Denk w...@denx.de
---
Changes from v4 to v5:
* fixed bi_boot_params initialization
* cosmetic changes in board configuration
Changes from v3 to v4:
* removed dcache flushing from board_init()
* tabs instead of spaces in board config file
Changes from v2 to v3:
* updated a relocation address
* combined a record in maintainers file into the patch
* use high speed UART2 by default
Changes from v1 to v2:
* corrected address in GPLv2+ licence header in files
* removed clean and distclean targets from board makefile
* do not set machine id explicitly, if CONFIG_MACH_TYPE is defined
* minor indentation cleanups
MAINTAINERS |4 +
board/timll/devkit3250/Makefile | 44 +
board/timll/devkit3250/devkit3250.c | 65 +++
boards.cfg |1 +
include/configs/devkit3250.h| 117 +++
5 files changed, 231 insertions(+), 0 deletions(-)
create mode 100644 board/timll/devkit3250/Makefile
create mode 100644 board/timll/devkit3250/devkit3250.c
create mode 100644 include/configs/devkit3250.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 4bf12b5..68dedae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -914,6 +914,10 @@ Sughosh Ganu urwithsugh...@gmail.com
hawkboard ARM926EJS (OMAP-L138)
+Vladimir Zapolskiy v...@mleia.com
+
+ devkit3250 lpc32xx
+
-
Unknown / orphaned boards:
diff --git a/board/timll/devkit3250/Makefile b/board/timll/devkit3250/Makefile
new file mode 100644
index 000..ea7827c
--- /dev/null
+++ b/board/timll/devkit3250/Makefile
@@ -0,0 +1,44 @@
+#
+# Copyright (C) 2011 by Vladimir Zapolskiy v...@mleia.com
+# Copyright (C) 2008, Guennadi Liakhovetski l...@denx.de
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301, USA.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := devkit3250.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/timll/devkit3250/devkit3250.c
b/board/timll/devkit3250/devkit3250.c
new file mode 100644
index 000..6b0ec80
--- /dev/null
+++ b/board/timll/devkit3250/devkit3250.c
@@ -0,0 +1,65 @@
+/*
+ * Embest/Timll DevKit3250 board support
+ *
+ * Copyright (C) 2011 Vladimir Zapolskiy v...@mleia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include common.h
+#include asm/arch/sys_proto.h
+#include asm/arch/cpu.h
+#include asm/arch/emc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static struct emc_regs *emc = (struct emc_regs *)EMC_BASE;
+
+int board_early_init_f(void)
+{
+ lpc32xx_uart_init(CONFIG_SYS_LPC32XX_UART);
+
+ return 0;
+}
+
+int board_init(void)
+{
+ /* adress of boot parameters */
+
[U-Boot] [PATCH 1/3 v8] arm926ejs: add NXP LPC32x0 cpu series support
This change adds initial support for NXP LPC32x0 SoC series. Signed-off-by: Vladimir Zapolskiy v...@mleia.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Wolfgang Denk w...@denx.de --- Changes from v7 to v8: * renamed register structures from *_t to *_regs * renamed clkpwr.c file to clk.c * fixed several macro definitions * various cosmetic fixes Changes from v6 to v7: * get use of setbits_le32() and friends * add arch_cpu_init() routine Changes from v5 to v6: * replaced some spaces with tabs in macro declarations * more rules separating 14-clock and ns16650 UARTs in config.h Changes from v4 to v5: * corrected address in GPLv2+ licence header in files Changes from v3 to v4: * extended memory controller definitions are introduced * added print_cpuinfo() function Changes from v2 to v3: * checkpatch.pl reports zero errors and warnings Changes from v1 to v2: * BIT(n) and SBF(s, v) macro are not used anymore * removed NS16550 and 14-clock UART definitions from uart.h * added devices.c file, which contains standard UART preinitialization routine * added get_serial_clock() function, it returns actual frequency of UART clock * __udelay() realization is simplified, no need of interrupt handling arch/arm/cpu/arm926ejs/lpc32xx/Makefile | 45 +++ arch/arm/cpu/arm926ejs/lpc32xx/clk.c | 117 + arch/arm/cpu/arm926ejs/lpc32xx/cpu.c | 70 ++ arch/arm/cpu/arm926ejs/lpc32xx/devices.c | 52 arch/arm/cpu/arm926ejs/lpc32xx/timer.c| 90 + arch/arm/include/asm/arch-lpc32xx/clk.h | 170 + arch/arm/include/asm/arch-lpc32xx/config.h| 76 +++ arch/arm/include/asm/arch-lpc32xx/cpu.h | 64 + arch/arm/include/asm/arch-lpc32xx/emc.h | 92 + arch/arm/include/asm/arch-lpc32xx/sys_proto.h | 25 arch/arm/include/asm/arch-lpc32xx/timer.h | 74 +++ arch/arm/include/asm/arch-lpc32xx/uart.h | 54 arch/arm/include/asm/arch-lpc32xx/wdt.h | 51 13 files changed, 980 insertions(+), 0 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/Makefile create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/clk.c create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/cpu.c create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/devices.c create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/timer.c create mode 100644 arch/arm/include/asm/arch-lpc32xx/clk.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/config.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/cpu.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/emc.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/sys_proto.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/timer.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/uart.h create mode 100644 arch/arm/include/asm/arch-lpc32xx/wdt.h diff --git a/arch/arm/cpu/arm926ejs/lpc32xx/Makefile b/arch/arm/cpu/arm926ejs/lpc32xx/Makefile new file mode 100644 index 000..ae1f0a5 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/lpc32xx/Makefile @@ -0,0 +1,45 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License +# as published by the Free Software Foundation; either version 2 +# of the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(SOC).o + +COBJS = cpu.o clk.o devices.o timer.o + +SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS:= $(addprefix $(obj),$(COBJS) $(SOBJS)) + +all:$(obj).depend $(LIB) + +$(LIB): $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/arm/cpu/arm926ejs/lpc32xx/clk.c b/arch/arm/cpu/arm926ejs/lpc32xx/clk.c new file mode 100644 index 000..6f26d62 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/lpc32xx/clk.c @@ -0,0 +1,117 @@ +/* + * Copyright (C) 2011 by Vladimir Zapolskiy v...@mleia.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the
[U-Boot] [PATCH 1/2] nand: Introduce CONFIG_SYS_NAND_SELF_INIT
This allows a driver to run code between nand_scan_ident() and
nand_scan_tail(), among other things. See the additions to
doc/README.nand for details.
To allow a gradual transition, Boards that don't set
CONFIG_SYS_NAND_SELF_INIT will still be initialized the old way, but
new drivers should not require this, and existing drivers should be
converted when convenient.
Signed-off-by: Scott Wood scottw...@freescale.com
---
doc/README.nand | 62 ++
drivers/mtd/nand/nand.c | 96 +--
include/nand.h |5 ++
3 files changed, 126 insertions(+), 37 deletions(-)
diff --git a/doc/README.nand b/doc/README.nand
index 023740e..04a87c9 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -120,6 +120,68 @@ Configuration Options:
CONFIG_SYS_NAND_MAX_CHIPS
The maximum number of NAND chips per device to be supported.
+ CONFIG_SYS_NAND_SELF_INIT
+ Traditionally, glue code in drivers/mtd/nand/nand.c has driven
+ the initialization process -- it provides the mtd and nand
+ structs, calls a board init function for a specific device,
+ calls nand_scan(), and registers with mtd.
+
+ This arrangement does not provide drivers with the flexibility to
+ run code between nand_scan_ident() and nand_scan_tail(), or other
+ deviations from the normal flow.
+
+ If a board defines CONFIG_SYS_NAND_SELF_INIT, drivers/mtd/nand/nand.c
+ will make one call to board_nand_init(), with no arguments. That
+ function is responsible for calling a driver init function for
+ each NAND device on the board, that performs all initialization
+ tasks except setting mtd-name, and registering with the rest of
+ U-Boot. Those last tasks are accomplished by calling nand_register()
+ on the new mtd device.
+
+ Example of new init to be added to the end of an existing driver
+ init:
+
+ /*
+* devnum is the device number to be used in nand commands
+* and in mtd-name. Must be less than
+* CONFIG_SYS_NAND_MAX_DEVICE.
+*/
+ mtd = nand_info[devnum];
+
+ /* chip is struct nand_chip, and is now provided by the driver. */
+ mtd-priv = chip;
+
+ /*
+* Fill in appropriate values if this driver uses these fields,
+* or uses the standard read_byte/write_buf/etc. functions from
+* nand_base.c that use these fields.
+*/
+ chip.IO_ADDR_R = ...;
+ chip.IO_ADDR_W = ...;
+
+ if (nand_scan_ident(mtd, CONFIG_SYS_MAX_NAND_CHIPS, NULL))
+ error out
+
+ /*
+* Insert here any code you wish to run after the chip has been
+* identified, but before any other I/O is done.
+*/
+
+ if (nand_scan_tail(mtd))
+ error out
+
+ if (nand_register(devnum))
+ error out
+
+ In addition to providing more flexibility to the driver, it reduces
+ the difference between a U-Boot driver and its Linux counterpart.
+ nand_init() is now reduced to calling board_nand_init() once, and
+ printing a size summary. This should also make it easier to
+ transition to delayed NAND initialization.
+
+ Please convert your driver even if you don't need the extra
+ flexibility, so that one day we can eliminate the old mechanism.
+
NOTE:
=
diff --git a/drivers/mtd/nand/nand.c b/drivers/mtd/nand/nand.c
index d987f4c..4cf4c1c 100644
--- a/drivers/mtd/nand/nand.c
+++ b/drivers/mtd/nand/nand.c
@@ -23,6 +23,7 @@
#include common.h
#include nand.h
+#include errno.h
#ifndef CONFIG_SYS_NAND_BASE_LIST
#define CONFIG_SYS_NAND_BASE_LIST { CONFIG_SYS_NAND_BASE }
@@ -31,63 +32,84 @@
DECLARE_GLOBAL_DATA_PTR;
int nand_curr_device = -1;
+
+
nand_info_t nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
+#ifndef CONFIG_SYS_NAND_SELF_INIT
static struct nand_chip nand_chip[CONFIG_SYS_MAX_NAND_DEVICE];
static ulong base_address[CONFIG_SYS_MAX_NAND_DEVICE] =
CONFIG_SYS_NAND_BASE_LIST;
+#endif
+
+static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
+
+static unsigned long total_nand_size; /* in kiB */
+
+/* Register an initialized NAND mtd device with the U-Boot NAND command. */
+int nand_register(int devnum)
+{
+ struct mtd_info *mtd;
+
+ if (devnum = CONFIG_SYS_MAX_NAND_DEVICE)
+ return -EINVAL;
+
+ mtd = nand_info[devnum];
+
+ sprintf(dev_name[devnum], nand%d, devnum);
+ mtd-name = dev_name[devnum];
+
+#ifdef CONFIG_MTD_DEVICE
+ /*
+* Add MTD device so that we can reference it later
+* via the mtdcore infrastructure (e.g. ubi).
+*/
+ add_mtd_device(mtd);
+#endif
+
+ total_nand_size += mtd-size / 1024;
-static const char default_nand_name[] = nand;
-static __attribute__((unused)) char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
+ if (nand_curr_device == -1)
+ nand_curr_device = devnum;
+
+ return 0;
[U-Boot] [PATCH 2/2] nand/fsl_elbc: Convert to self-init
This driver doesn't yet make use of the added flexibility (not that that
should stop anyone from converting...), but it will with the in-progress
hack to support 4k-page NAND.
Signed-off-by: Scott Wood scottw...@freescale.com
---
drivers/mtd/nand/fsl_elbc_nand.c | 43 +
include/nand.h | 11 +
2 files changed, 49 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 99d1061..9076ad4 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -22,6 +22,7 @@
#include common.h
#include malloc.h
+#include nand.h
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
@@ -57,7 +58,6 @@ struct fsl_elbc_ctrl;
/* mtd information per set */
struct fsl_elbc_mtd {
- struct mtd_info mtd;
struct nand_chip chip;
struct fsl_elbc_ctrl *ctrl;
@@ -686,10 +686,13 @@ static void fsl_elbc_ctrl_init(void)
elbc_ctrl-addr = NULL;
}
-int board_nand_init(struct nand_chip *nand)
+static int fsl_elbc_chip_init(int devnum, u8 *addr)
{
+ struct mtd_info *mtd = nand_info[devnum];
+ struct nand_chip *nand;
struct fsl_elbc_mtd *priv;
uint32_t br = 0, or = 0;
+ int ret;
if (!elbc_ctrl) {
fsl_elbc_ctrl_init();
@@ -702,19 +705,19 @@ int board_nand_init(struct nand_chip *nand)
return -ENOMEM;
priv-ctrl = elbc_ctrl;
- priv-vbase = nand-IO_ADDR_R;
+ priv-vbase = addr;
/* Find which chip select it is connected to. It'd be nice
* if we could pass more than one datum to the NAND driver...
*/
for (priv-bank = 0; priv-bank MAX_BANKS; priv-bank++) {
- phys_addr_t base_addr = virt_to_phys(nand-IO_ADDR_R);
+ phys_addr_t phys_addr = virt_to_phys(addr);
br = in_be32(elbc_ctrl-regs-bank[priv-bank].br);
or = in_be32(elbc_ctrl-regs-bank[priv-bank].or);
if ((br BR_V) (br BR_MSEL) == BR_MS_FCM
- (br or BR_BA) == BR_PHYS_ADDR(base_addr))
+ (br or BR_BA) == BR_PHYS_ADDR(phys_addr))
break;
}
@@ -724,6 +727,9 @@ int board_nand_init(struct nand_chip *nand)
return -ENODEV;
}
+ nand = priv-chip;
+ mtd-priv = nand;
+
elbc_ctrl-chips[priv-bank] = priv;
/* fill in nand_chip structure */
@@ -794,5 +800,32 @@ int board_nand_init(struct nand_chip *nand)
}
}
+ ret = nand_scan_ident(mtd, 1, NULL);
+ if (ret)
+ return ret;
+
+ ret = nand_scan_tail(mtd);
+ if (ret)
+ return ret;
+
+ ret = nand_register(devnum);
+ if (ret)
+ return ret;
+
return 0;
}
+
+#ifndef CONFIG_SYS_NAND_BASE_LIST
+#define CONFIG_SYS_NAND_BASE_LIST { CONFIG_SYS_NAND_BASE }
+#endif
+
+static unsigned long base_address[CONFIG_SYS_MAX_NAND_DEVICE] =
+ CONFIG_SYS_NAND_BASE_LIST;
+
+void board_nand_init(void)
+{
+ int i;
+
+ for (i = 0; i CONFIG_SYS_MAX_NAND_DEVICE; i++)
+ fsl_elbc_chip_init(i, (u8 *)base_address[i]);
+}
diff --git a/include/nand.h b/include/nand.h
index 5dd1710..8b3a1a7 100644
--- a/include/nand.h
+++ b/include/nand.h
@@ -24,6 +24,17 @@
#ifndef _NAND_H_
#define _NAND_H_
+#include config.h
+
+/*
+ * All boards using a given driver must convert to self-init
+ * at the same time, so do it here. When all drivers are
+ * converted, this will go away.
+ */
+#if defined(CONFIG_NAND_FSL_ELBC)
+#define CONFIG_SYS_NAND_SELF_INIT
+#endif
+
extern void nand_init(void);
#include linux/mtd/compat.h
--
1.7.7.rc3.4.g8d714
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] tegra: Add I2C driver and associated parts
Hello Simon, Simon Glass wrote: This series brings in an I2C driver for Tegra which can be configured by a flat device tree. It supports 8- and 16-bit addresses and both the normal I2C ports and the DVC port (for controlling the power management unit (PMU)). Recent Linux bindings are used, based on example .dts files found in branch for-3.3/dt at: git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git (I could not find the actual binding documentation to include here) Changes in v2: Hups, seems I missed the v1 ... please add the i2c custodian (me ;-) to cc in further EMails, thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] tegra: fdt: Add extra I2C bindings for U-Boot
Hello Simon, Simon Glass wrote: Add U-Boot's peripheral clock information to the Tegra20 device tree file. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Adjust definitions to fit new peripheral clock bindings - Change 'speed' to 'clock-frequency' - Remove u-boot,pinmux binding (sadly) arch/arm/dts/tegra20.dtsi | 10 +- Hmm.. we have no such a directory in the u-boot source tree ... ? I think, this patch is for the linux tree? [...] bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] powerpc/boot: Slave module for boot from SRIO
Dear Wolfgang, On Wed, 2012-01-11 at 08:27 +0100, Wolfgang Denk wrote: Where is CONFIG_SYS_QE_FMAN_FW_IN_REMOTE documented? And where is the code that uses it? [Liu Gang-B34182] Sorry I documented this definition in [PATCH 6/8] powerpc/boot: Slave uploads ucode when boot from SRIO, I'll add descriptions about this definition in PATCH 5/8. The function fm_init_common in the file drivers/net/fm/fm.c uses the CONFIG_SYS_QE_FMAN_FW_IN_REMOTE. Please: - do not full-quote. - restrict your line length to some 70 characters or so - use proper quoting; see http://www.netmeister.org/news/learn2quote.html I'm sorry for the late reply because of some e-mail problem of my system. I'm learning the information you provided, it's very useful. Thanks very much! Best Regards, Liu Gang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] powerpc/boot: Master module for boot from SRIO
Dear Wolfgang, On Wed, 2012-01-11 at 08:31 +0100, Wolfgang Denk wrote: 3. Normally boot from local Nor flash. Please use NOR flash (or nor flash, if you insist). Nor makes no sense. Please fix globally. Thanks, will modify. + printf(SRIOBOOT - MASTER: Master port [ %d ] for srio boot.\n, + CONFIG_SRIOBOOT_MASTER_PORT); + /* configure inbound window1 for slave's u-boot image */ + printf(SRIOBOOT - MASTER: Inbound window1 for slave's image; + Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n, + (u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS1, + (u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS1, + CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE); As mentioned before, this looks a lot like debug code, that should be removed from a production version. Use debug() instead? These parameters are very important for the boot from srio, for the different productions may should be different values. So I think that would be better to keep these informations. I'll use debug() instead! This comment applies to the whole patch series: - Get rid of the base address + oofset notation. User C structs instead. - Get rid of hard coded magic numbers. #define the needed values in a readable way. Thanks, will modify. Best Regards, Liu Gang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] powerpc/boot: Slave uploads ucode when boot from SRIO
Dear Wolfgang, On Wed, 2012-01-11 at 08:23 +0100, Wolfgang Denk wrote: +#ifdef CONFIG_SRIOBOOT_SLAVE + /* +* *I*G - SRIOBOOT-SLAVE. 1M space from 0xffe0 for fetching ucode +* and ENV from master +*/ What is this *I*G - doing here? This means that the TLB entry will be set with attribute MAS2_I and MAS2_G. This follows the existing style of the file. +/* + *for slave UCODE instored in master memory space, + *PHYS must be aligned based on the SIZE + */ Please add a space between the '*' anf the text. Please fix globally. Thanks, will add. Best Regards, Liu Gang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] tegra: Add I2C driver
Hello Stephen,
Stephen Warren wrote:
Simon Glass wrote ednesday, January 11, 2012 9:18 PM:
On Mon, Jan 9, 2012 at 2:07 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/26/2011 11:11 AM, Simon Glass wrote:
From: Yen Lin ye...@nvidia.com
Add basic i2c driver for Tegra2 with 8- and 16-bit address support.
The driver supports building both with and without CONFIG_OF_CONTROL.
Without CONFIG_OF_CONTROL a number of CONFIG options must be supplied
in the board config header file:
I2CSPEED_KHZ - speed to run I2C bus at (typically 10)
CONFIG_I2Cx_PIN_MUX - pin mux setting for each port (P, 1, 2, 3)
(typically this will be 0 to bring the port out the common
pins)
...
...
diff --git a/drivers/i2c/tegra2_i2c.c b/drivers/i2c/tegra2_i2c.c
...
+struct i2c_bus i2c_controllers[CONFIG_SYS_MAX_I2C_BUS];
What if there are I2C bus extenders/muxes/... such that there are more
I2C buses in the system than Tegra I2C controllers? I'd rather see an
explicit TEGRA_I2C_NUM_CONTROLLERS define used throughout this patch.
We don't actually support CONFIG_I2C_MUX, so I can't see how that
could happen. Can you please explain a bit more?
We may not support it now, but I see no reason we won't in the future.
If we confuse the two defines now, it'll make it harder to allow muxes
in the future. The fix is simply using the correct define name within
the I2C driver isn't it; pretty simple.
If we really have this case, we *must* get the multibus/multiadapter
branch from here:
http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=shortlog;h=refs/heads/multibus_v2_2012
to uboot mainline! With that approach we could handle this case
in a clean way ... This branch is not in sync with current TOT, and
it has to be tested again, as I didn't found time for this in the
last year :-( Also, as its base is 2 years old, there are a lot
of checkpatch errors in this patchserie, which have to be cleaned
up ... hope I get some time for it ... help is welcome.
+int i2c_init_board(void)
+{
[...]
Surely that function needs to actually do something, at least set up the
clocks so that the (user?) requested rate is honored, or print an error
message if you're only allowed to use the hard-coded bus rate.
See my other message. I suppose we could reinit, but we really don't
want to honour the speed, since the fdt speed setting is then lost and
irrecoverable. For now it feels like we should ignore it.
Hmm. I suspect the answer here is roughly to override the following in
cmd_i2c.c:
/* TODO: Implement architecture-specific get/set functions */
unsigned int __def_i2c_get_bus_speed(void)
{
return CONFIG_SYS_I2C_SPEED;
}
unsigned int i2c_get_bus_speed(void)
__attribute__((weak, alias(__def_i2c_get_bus_speed)));
int __def_i2c_set_bus_speed(unsigned int speed)
{
if (speed != CONFIG_SYS_I2C_SPEED)
return -1;
return 0;
}
int i2c_set_bus_speed(unsigned int)
__attribute__((weak, alias(__def_i2c_set_bus_speed)));
To actually read/write the rate in use by the driver.
Yep, for this reason this functions are weak, and you can define
a driver specific function which returns the current used settings
in the driver.
Code should compile, if tegra2 not define CONFIG_SYS_I2C_SPEED,
as a default value for CONFIG_SYS_I2C_SPEED is defined in
include/i2c.h ...
Then, fix do_i2c_reset() to use i2c_get_bus_speed() so it interacts
correctly with those functions.
Yep, I think, you are right here, that should be fixed. As the
default function for i2c_get_bus_speed returns CONFIG_SYS_I2C_SPEED,
that should be OK.
There may be other places that need to be updates to use those function
instead of hard-coding CONFIG_SYS_I2C_SPEED too. Perhaps we could even
get away without defining CONFIG_SYS_I2C_SPEED for Tegra since it's
meaningless. Instead, ifdef those default function definitions above
based on whether CONFIG_SYS_I2C_SPEED is defined or not.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] powerpc/srio: Correct the register defined errors in the struct ccsr_rio_t
Hi, Kumar, On Thu, 2012-01-12 at 10:47 -0600, Kumar Gala wrote: On Jan 10, 2012, at 5:42 AM, Liu Gang wrote: + u32 didcar; /* 0xc - Device Identity CAR */ Drop the '0xc' prefix in the comment, same comment for all registers. Thanks, I'll rewrite this struct. Best Regards, Liu Gang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] zipitz2: enable pxa27x_mkp driver
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
v2: remove usbtty stuff from EXTRA_ENV_SETTINGS
v3: shift+backspace should produce backspace code
include/configs/zipitz2.h | 82 ++---
1 files changed, 77 insertions(+), 5 deletions(-)
diff --git a/include/configs/zipitz2.h b/include/configs/zipitz2.h
index 26204af..76054af 100644
--- a/include/configs/zipitz2.h
+++ b/include/configs/zipitz2.h
@@ -80,6 +80,12 @@
#defineCONFIG_CMD_MMC
#defineCONFIG_CMD_SPI
+#defineCONFIG_EXTRA_ENV_SETTINGS
\
+ stdout=lcd\0 \
+ stdin=pxa27x-mkp\0\
+ stderr=lcd\0 \
+
+#defineCONFIG_KEYBOARD
/*
* MMC Card Configuration
*/
@@ -206,15 +212,81 @@ unsigned char zipitz2_spi_read(void);
#define CONFIG_SYS_FLASH_PROTECTION
/*
+ * Matrix keypad
+ */
+#ifdef CONFIG_KEYBOARD
+#defineCONFIG_PXA27X_MKP
+
+#defineCONFIG_PXA27X_MKP_MKP_COLS 7
+#defineCONFIG_PXA27X_MKP_MKP_ROWS 6
+
+#defineCONFIG_PXA27X_MKP_DEBOUNCE 30
+#defineCONFIG_PXA27X_MKP_DELAY 3
+
+#defineCONFIG_PXA27X_MKP_MOD_SHIFT {5, 3}
+#defineCONFIG_PXA27X_MKP_MOD_ALT {5, 2}
+#defineCONFIG_PXA27X_MKP_MOD_CTRL {5, 4}
+
+#defineCONFIG_PXA27X_MKP_KEYMAP\
+ { 1, 1, 'q', 'Q', '1', 0xff }, \
+ { 2, 1, 'i', 'I', '8', 0xff }, \
+ { 3, 1, 'g', 'G', '\', 0xff }, \
+ { 4, 1, 'x', 'X', '/', 0xff }, \
+ { 5, 1, '\r', 0xff, 0xff, 0xff }, \
+ { 6, 1, '-', 0xff, 0xff, 0xff },\
+ \
+ { 1, 2, 'w', 'W', '2', 0xff }, \
+ { 2, 2, 'o', 'O', '9', 0xff }, \
+ { 3, 2, 'h', 'H', '\'', 0xff }, \
+ { 4, 2, 'c', 'C', '+', 0xff }, \
+ \
+ { 1, 3, 'e', 'E', '3', 0xff }, \
+ { 2, 3, 'p', 'P', '0', 0xff }, \
+ { 3, 3, 'j', 'J', '[', 0xff }, \
+ { 4, 3, 'v', 'V', '*', 0xff }, \
+ \
+ { 0, 4, '\e', 0xff, '|', 0xff },\
+ { 1, 4, 'r', 'R', '4', 0xff }, \
+ { 2, 4, 'a', 'A', '$', 0xff }, \
+ { 3, 4, 'k', 'K', ']', 0xff }, \
+ { 4, 4, 'b', 'B', '=', 0xff }, \
+ \
+ { 0, 5, '\t', 0xff, 0xff, 0xff }, \
+ { 1, 5, 't', 'T', '5', 0xff }, \
+ { 2, 5, 's', 'S', '#', 0xff }, \
+ { 3, 5, 'l', 'L', '-', 0xff }, \
+ { 4, 5, 'n', 'N', '_', 0xff }, \
+ { 5, 5, ' ', 0xff, 0xff, 0xff },\
+ \
+ { 1, 6, 'y', 'Y', '6', 0xff }, \
+ { 2, 6, 'd', 'D', '', 0xff }, \
+ { 3, 6, '\b', '\b', '\\', 0xff }, \
+ { 4, 6, 'm', 'M', '?', 0xff }, \
+ { 5, 6, ',', '(', '', '{' }, \
+ \
+ { 1, 7, 'u', 'U', '7', 0xff }, \
+ { 2, 7, 'f', 'F', '@', 0xff }, \
+ { 3, 7, 'z', 'Z', '!', 0xff }, \
+ { 4, 7, ';', '~', ':', 0xff }, \
+ { 5, 7, '.', ')', '', '}' }, \
+ \
+ { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }
+
+#defineCONFIG_SYS_CONSOLE_ENV_OVERWRITE
+#defineCONFIG_SYS_CONSOLE_IS_IN_ENV
+
+#endif
+
+/*
* GPIO settings
*/
#define CONFIG_SYS_GAFR0_L_VAL 0x02000140
-#define CONFIG_SYS_GAFR0_U_VAL 0x59188000
-#define CONFIG_SYS_GAFR1_L_VAL 0x6392
+#define CONFIG_SYS_GAFR0_U_VAL 0x59188005
+#define CONFIG_SYS_GAFR1_L_VAL 0x639420a2
#define CONFIG_SYS_GAFR1_U_VAL 0xaaa03950
#define CONFIG_SYS_GAFR2_L_VAL 0x0aaa
#define CONFIG_SYS_GAFR2_U_VAL 0x29000308
-#define CONFIG_SYS_GAFR3_L_VAL 0x5400
+#define CONFIG_SYS_GAFR3_L_VAL 0x56aa9500
#define CONFIG_SYS_GAFR3_U_VAL 0x00d5
#define CONFIG_SYS_GPCR0_VAL 0x
#define CONFIG_SYS_GPCR1_VAL 0x0020
@@ -222,7 +294,7 @@ unsigned char zipitz2_spi_read(void);
#define CONFIG_SYS_GPCR3_VAL 0x
#define CONFIG_SYS_GPDR0_VAL 0xdafcee00
#define CONFIG_SYS_GPDR1_VAL 0xffa3aaab
-#define CONFIG_SYS_GPDR2_VAL 0x8fe9
+#define CONFIG_SYS_GPDR2_VAL 0x8fe1
#define CONFIG_SYS_GPDR3_VAL 0x001b1f8a
#define CONFIG_SYS_GPSR0_VAL 0x06080400
#define CONFIG_SYS_GPSR1_VAL 0x007f
@@ -234,7 +306,7 @@ unsigned char zipitz2_spi_read(void);
/*
* Clock settings
*/
-#define CONFIG_SYS_CKEN0x00511220
+#define CONFIG_SYS_CKEN0x00591220
#define CONFIG_SYS_CCCR0x0190
/*
--
1.7.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] zipitz2: use pxa_mmc_gen as MMC driver
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
v2: mmcinfo is necessary to scan card for partitions
v3: replace mmcinfo with mmc rescan
board/zipitz2/zipitz2.c |8
include/configs/zipitz2.h | 14 --
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/board/zipitz2/zipitz2.c b/board/zipitz2/zipitz2.c
index b093c2f..4075fb6 100644
--- a/board/zipitz2/zipitz2.c
+++ b/board/zipitz2/zipitz2.c
@@ -79,6 +79,14 @@ void dram_init_banksize(void)
gd-bd-bi_dram[0].size = PHYS_SDRAM_1_SIZE;
}
+#ifdef CONFIG_CMD_MMC
+int board_mmc_init(bd_t *bis)
+{
+ pxa_mmc_register(0);
+ return 0;
+}
+#endif
+
#ifdef CONFIG_CMD_SPI
struct {
diff --git a/include/configs/zipitz2.h b/include/configs/zipitz2.h
index 76054af..4f48d9b 100644
--- a/include/configs/zipitz2.h
+++ b/include/configs/zipitz2.h
@@ -44,11 +44,12 @@
#defineCONFIG_SYS_MALLOC_LEN (128*1024)
#defineCONFIG_ARCH_CPU_INIT
-#defineCONFIG_BOOTCOMMAND
\
- if mmc init fatload mmc 0 0xa000 uboot.script ; then \
- source 0xa000;\
- else \
- bootm 0x6;\
+#defineCONFIG_BOOTCOMMAND
\
+ if mmc rescan 0 ext2load mmc 0 0xa000 boot/uboot.script ; \
+ then \
+ source 0xa000; \
+ else \
+ bootm 0x6; \
fi;
#defineCONFIG_BOOTARGS
\
console=tty0 console=ttyS2,115200 fbcon=rotate:3
@@ -91,7 +92,8 @@
*/
#ifdef CONFIG_CMD_MMC
#defineCONFIG_MMC
-#defineCONFIG_PXA_MMC
+#defineCONFIG_GENERIC_MMC
+#defineCONFIG_PXA_MMC_GENERIC
#defineCONFIG_SYS_MMC_BASE 0xF000
#defineCONFIG_CMD_FAT
#define CONFIG_CMD_EXT2
--
1.7.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-imx on Freescale MX28EVK
Hi Robert, I a patch would be welcome. I only need USB and SPI flash for my application. And USB was easy to setup. Currently I am also jiggling around the SPI / SPI flash support. I only mentioned the 2009.08 u-boot for reference in my initial posting. There was no plan to stay with it - of course :-) But there is still the difference that I can download 2009.08 + imx-bootlets via USB (sb_loader). This does not work with the recent u-boot-imx repo and the generated u-boot.sb target. Matthias On 12.01.2012 22:52, Robert Deliën wrote: Hi Matthias, I have a fully functional U-Boot for the mx28evk board: - Both Ethernet ports work - Both MMC slots work - NAND works (if configure in, one MMC slot will be configured out, due to shared pins) - USB works - I2C works - Currently working on SPI It's basically an integration of u-boot-imx and Marek's work on m28evk_config in the mainline. I'm still working on making a posting-quality patch, but I'll be happy to help you out with a patch or a tar-ball, so feel free to drop me an email. Freescale's 2009.08 works too, but their script to get it on an sd-card is broken. I can get you a replacement for that one as well, but you'd better step up to a more recent version, because the MMC driver in the FreeScale version has a nasty bug in the MMC driver. This bug prevents you from loading files from a file system on an SD-Card. Robert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Dipl.-Ing. Matthias Fuchs Head of System Design esd electronic system design gmbh Vahrenwalder Str. 207 - 30165 Hannover - GERMANY Phone: +49-511-37298-0 - Fax: +49-511-37298-68 Please visit our homepage http://www.esd.eu Quality Products - Made in Germany Besuchen Sie uns auf der embedded world 2012 in Halle 4, Stand 129 vom 28. Februar - 01. März 2012 in Nürnberg! Geschäftsführer: Klaus Detering Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832 - ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] i.mx6q: SabreLite: Add SPI NOR support
On 12.01.2012 16:48, Fabio Estevam wrote: On Thu, Jan 12, 2012 at 1:38 PM, Marek Vasut marek.va...@gmail.com wrote: Also, Do you even need the ecspi thing? Doesn't uboot support some kind of imx spi driver already? Yes, this is the same question I have. Can't drivers/spi/mxc_spi.c be extended to support mx6? Eric, what do you think? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] tegra: Add I2C driver
Hello Simon,
Simon Glass wrote:
From: Yen Lin ye...@nvidia.com
Add basic i2c driver for Tegra2 with 8- and 16-bit address support.
The driver requires CONFIG_OF_CONTROL to obtain its configuration
from the device tree.
(Simon Glass: s...@chromium.org modified for upstream)
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Use DIV_ROUND_UP() instead of a home-grown macro
- Tidy comment style
- Change i2c array to static
- Adjust definitions to fit new peripheral clock bindings
- Remove i2c configuring using CONFIG (use fdt instead)
Why? Ah found it ... Hmm.. why we don't need the non OF
case?
- Make i2c/dvc decision come from fdt
- Use new fdtdec alias decode function
- Simplify code in i2c_addr_ok()
- Return an error if an unavailable i2c bus is selected
arch/arm/include/asm/arch-tegra2/tegra2_i2c.h | 160 +++
drivers/i2c/Makefile |1 +
drivers/i2c/tegra2_i2c.c | 551
+
include/fdtdec.h |2 +
lib/fdtdec.c |2 +
5 files changed, 716 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra2/tegra2_i2c.h
create mode 100644 drivers/i2c/tegra2_i2c.c
[...]
diff --git a/drivers/i2c/tegra2_i2c.c b/drivers/i2c/tegra2_i2c.c
new file mode 100644
index 000..a7db714
--- /dev/null
+++ b/drivers/i2c/tegra2_i2c.c
@@ -0,0 +1,551 @@
[...]
+static void i2c_init_controller(struct i2c_bus *i2c_bus)
+{
+ /* TODO: Fix bug which makes us need to do this */
+ clock_start_periph_pll(i2c_bus-periph_id, CLOCK_ID_OSC,
+i2c_bus-speed * (8 * 2 - 1));
Can you use here some defines?
What is (8 * 2 - 1) ?
+#ifndef CONFIG_OF_CONTROL
+#error Please enable device tree support to use this driver
+#endif
Hmm.. see above question. Ok, if somebody need want to use this
driver without CONFIG_OF_CONTROL it must be added ...
+/*
+ * Process a list of nodes, adding them to our list of I2C ports.
+ *
+ * @param blob fdt blob
+ * @param node_list list of nodes to process (any =0 are ignored)
+ * @param count number of nodes to process
+ * @param is_dvc 1 if these are DVC ports, 0 if standard I2C
+ * @return 0 if ok, -1 on error
+ */
+static int process_nodes(const void *blob, int node_list[], int count,
+ int is_dvc)
+{
+ struct i2c_bus *i2c_bus;
+ int i;
+
+ /* build the i2c_controllers[] for each controller */
+ for (i = 0; i count; i++) {
+ int node = node_list[i];
+
+ if (node = 0)
+ continue;
+
+ i2c_bus = i2c_controllers[i];
+ i2c_bus-id = i;
+
+ if (i2c_get_config(blob, node, i2c_bus)) {
+ printf(i2c_init_board: failed to decode bus %d\n, i);
+ return -1;
+ }
+
+ i2c_bus-is_dvc = is_dvc;
+ if (is_dvc) {
+ i2c_bus-control =
+ ((struct dvc_ctlr *)i2c_bus-regs)-control;
+ } else {
+ i2c_bus-control = i2c_bus-regs-control;
+ }
+ debug(%s: controller bus %d at %p, periph_id %d, speed %d: ,
+ is_dvc ? dvc : i2c, i, i2c_bus-regs,
+ i2c_bus-periph_id, i2c_bus-speed);
+ i2c_init_controller(i2c_bus);
+ debug(ok\n);
+ i2c_bus-inited = 1;
+
+ /* Mark position as used */
+ node_list[i] = -1;
+ }
+
+ return 0;
+}
+
+int i2c_init_board(void)
+{
+ int node_list[CONFIG_SYS_MAX_I2C_BUS];
+ const void *blob = gd-fdt_blob;
+ int count;
+
+ /* First get the normal i2c ports */
+ count = fdtdec_find_aliases_for_id(blob, i2c,
+ COMPAT_NVIDIA_TEGRA20_I2C, node_list,
+ CONFIG_SYS_MAX_I2C_BUS);
+ if (process_nodes(blob, node_list, count, 0))
+ return -1;
+
+ /* Now look for dvc ports */
+ count = fdtdec_add_aliases_for_id(blob, i2c,
+ COMPAT_NVIDIA_TEGRA20_DVC, node_list,
+ CONFIG_SYS_MAX_I2C_BUS);
+ if (process_nodes(blob, node_list, count, 1))
+ return -1;
+
+ return 0;
+}
+
+void i2c_init(int speed, int slaveaddr)
+{
+ debug(i2c_init(speed=%u, slaveaddr=0x%x)\n, speed, slaveaddr);
+}
Hmm... i2c_init is called to init the i2c subsystem ... you do nothing
here ... and use i2c_init_board for init the i2c bus, right?
But i2c_init_board is not called from the driver ... ah, you do this
in board code ... Ok ...
I think, you do this, because i2c_init is called very early, and
so processing fdt is slow?
[...]
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
Re: [U-Boot] [PATCH 1/2] SPI: Add i.MX ECSPI driver
On 12.01.2012 16:37, Marek Vasut wrote: From: Eric Nelson eric.nel...@boundarydevices.com Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com CC: Jason Liu jason@linaro.org CC: Stefano Babic sba...@denx.de --- ... + if (max_hz imx_spi_slave-freq) + imx_spi_slave-freq = max_hz ; ; -- fix globally ... run tools/checkpatch.pl before submitting First, many thanks for the review! Just one question: Which checkpatch do you use for this? I ran checkpatch from Linux 3.2 before submitting and got [1] (which I think is ok). Using U-Boot's checkpatch I get [2]. Many thanks again and bet regards Dirk [1] linux-2.6.git/scripts/checkpatch.pl 0001-SPI-Add-i.MX-ECSPI-driver.patch WARNING: Use #include linux/errno.h instead of asm/errno.h #60: FILE: drivers/spi/imx_ecspi.c:26: +#include asm/errno.h WARNING: Use #include linux/io.h instead of asm/io.h #62: FILE: drivers/spi/imx_ecspi.c:28: +#include asm/io.h total: 0 errors, 2 warnings, 438 lines checked 0001-SPI-Add-i.MX-ECSPI-driver.patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. [2] u-boot/tools/checkpatch.pl 0001-SPI-Add-i.MX-ECSPI-driver.patch total: 0 errors, 0 warnings, 438 lines checked NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX MULTISTATEMENT_MACRO_USE_DO_WHILE 0001-SPI-Add-i.MX-ECSPI-driver.patch has no obvious style problems and is ready for submission. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
