[U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
Hi, On Monday, January 30, 2012, Heiko Schocher h...@denx.de wrote: Hello Christian, Christian Riesch wrote: Hi all, On Fri, Jan 27, 2012 at 7:33 PM, Tom Rini tom.r...@gmail.com wrote: So, what do we want to do here? We really want to get this fix in so we can get the hawkboard SPL changes in, and the other platforms / fixups that are gated by that. If I can sum it up, in the relevant section of code we have incorrect comments and the init code is not following what the manual says the correct sequence is. However, given the (potentially wide) impact the changes would have, Albert had previously requested making the change opt-in (but I believe this request came before the the manual says we must do ...). If this is still the case? If so, can we get an updated patch? Thanks! A few thoughts: 1) Before commit ca4b55800ed74207c35271bf7335a092d4955416 the low level initialization code that we are discussing here was only executed if CONFIG_SKIP_LOWLEVEL_INIT is not defined. For ARM926EJS the relevant section in start.S looked like this #ifndef CONFIG_SKIP_LOWLEVEL_INIT flush caches turn off dcache, do some other configurations of the CPU, enable icache call the SoC specific lowlevel_init #endif For DA850 SoCs we had no lowlevel_init routine and therefore CONFIG_SKIP_LOWLEVEL_INIT defined in all board configurations. The lowlevel initialization was done by TI's UBL boot loader. Now we have boards that don't use UBL (e.g. enbw_cmc, calimain, da850evm when used with the SPL), therefore we need some lowlevel init. Most important configuration is enabling icache, otherwise u-boot startup gets really slow. Since commit ca4b55800ed74207c35271bf7335a092d4955416 it is flush caches turn off dcache, do some other configurations of the CPU, enable icache #ifndef CONFIG_SKIP_LOWLEVEL_INIT call the SoC specific lowlevel_init #endif So the change that has a big impact is already done and in mainline. Yep. Perhaps we should revert that change and instead remove CONFIG_SKIP_LOWLEVEL_INIT from the da850 board config files. But since we don't need the lowlevel_init function for DA850 SoCs we must either add a dummy function or add some additional defines that allow removing the CONFIG_SKIP_LOWLEVEL_INIT define without calling lowlevel_init. Any suggestions how such defines should be called or how the logic behind them should be so it doesn't cause breakage of existing boards? or we should introduce a CONFIG_SKIP_CPU_CRIT_INIT define, which if defined, prevent the jump to cpu_init_crit ... so we have the same behaviour as before commit ca4b55800ed74207c35271bf7335a092d4955416 Boards which have problems with cpu_crit_init, should define this new define ... but it would be better to find out, what is really going on here ... Yes, that would be good of course. Another idea: Actually the init code that we are discussing here is executed twice. First in the SPL and then in the full-blown u-boot. Sughosh, are you sure it is the execution of the code in SPL that causes the trouble? I'm asking since we don't do any memory barrier related stuff in the code that loads u-boot from flash in SPL. Of course, dcache is off but icache is on. Regards, Christian ___ 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 Mon Jan 30, 2012 at 09:10:46AM +0100, Christian Riesch wrote: snip Perhaps we should revert that change and instead remove CONFIG_SKIP_LOWLEVEL_INIT from the da850 board config files. But since we don't need the lowlevel_init function for DA850 SoCs we must either add a dummy function or add some additional defines that allow removing the CONFIG_SKIP_LOWLEVEL_INIT define without calling lowlevel_init. Any suggestions how such defines should be called or how the logic behind them should be so it doesn't cause breakage of existing boards? or we should introduce a CONFIG_SKIP_CPU_CRIT_INIT define, which if defined, prevent the jump to cpu_init_crit ... so we have the same behaviour as before commit ca4b55800ed74207c35271bf7335a092d4955416 Boards which have problems with cpu_crit_init, should define this new define ... but it would be better to find out, what is really going on here ... Yes, that would be good of course. Another idea: Actually the init code that we are discussing here is executed twice. First in the SPL and then in the full-blown u-boot. Sughosh, are you sure it is the execution of the code in SPL that causes the trouble? I'm asking since we don't do any memory barrier related stuff in the code that loads u-boot from flash in SPL. Of course, dcache is off but icache is on. Yes, it is the spl that is executing the code. There is a spl specific string that gets displayed on the console, before spl goes on to load the u-boot image and jump to it, and i don't see that string on the console. -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.
Hello Heiko, On Mon, Jan 30, 2012 at 7:39 AM, Heiko Schocher h...@denx.de wrote: Christian Riesch wrote: 2) The current version of Sughosh's patch does not change the logic behind the LOWLEVEL_INIT defines but just fixes the code to agree with ARM's manual. Instead of invalidating the cache it now is flushed. I think we should therefore merge his patch (@Tom: Yes, the manual says we must do.). The big change that Albert fears was already done earlier in commit ca4b55800ed74207c35271bf7335a092d4955416. And while we are doing this we also get the comments right. What do you mean with commit ca4b55800ed74207c35271bf7335a092d4955416? I could not find it in mainline ... commit ca4b55800ed74207c35271bf7335a092d4955416 Author: Heiko Schocher h...@denx.de Date: Wed Nov 9 20:06:23 2011 + arm, arm926ejs: always do cpu critical inits Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to make a u-boot that supports a particular board.
On Sun, Jan 29, 2012 at 08:54:22PM +0530, jagan wrote: Hi, I need an info, what are the changes that can be added to plain u-boot that supports a particular board. Please point-out any specific doc or links. Thanks for your time. Regards, Jagan. That really depends on is board supported by u-boot or not. If not then you need to add entry to board.cfg and appropriate directories and files (you can use other boards as examples). Use code as documentation. If your board is supported by u-boot, then look for board name in boards.cfg and then use make boardname_config to configure and then just make to build. (which is documented perfectly in README). All the best, S. ___ 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
[U-Boot] [PATCH] tt01: add video support and setup for release
This enables the display on tt-01 along with some minor setup changes (and fixes) for the release. I removed the HALE logo again, using preboot we can use a splash image like approach, but left in the console extra info as it provides useful information even if the screen is used as stdout. [PATCH 1/3] tt01: fix environment size [PATCH 2/3] tt01: add video support [PATCH 3/3] tt01: fix hush parser config, add release config -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] tt01: add video support
The video setup for the Epson display is provided. Addtionally
some extra info is displayed next to the Linux logo.
Signed-off-by: Helmut Raiger helmut.rai...@hale.at
---
board/hale/tt01/tt01.c | 21 +
include/configs/tt01.h | 29 -
2 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/board/hale/tt01/tt01.c b/board/hale/tt01/tt01.c
index ed3fa6e..02e75ed 100644
--- a/board/hale/tt01/tt01.c
+++ b/board/hale/tt01/tt01.c
@@ -228,3 +228,24 @@ int board_eth_init(bd_t *bis)
#endif
return rc;
}
+
+#ifdef CONFIG_CONSOLE_EXTRA_INFO
+void video_get_info_str(int line_number, char *info)
+{
+ u32 srev = get_cpu_rev();
+
+ switch (line_number) {
+ case 2:
+ sprintf(info, CPU : Freescale i.MX31 rev %d.%d%s at %d MHz,
+ (srev 0xF0) 4, (srev 0x0F),
+ ((srev 0x8000) ? unknown : ),
+ mxc_get_clock(MXC_ARM_CLK) / 100);
+ break;
+ case 3:
+ strcpy(info, BOARD_STRING);
+ break;
+ default:
+ info[0] = 0;
+ }
+}
+#endif
diff --git a/include/configs/tt01.h b/include/configs/tt01.h
index 8dd657c..a3b90d5 100644
--- a/include/configs/tt01.h
+++ b/include/configs/tt01.h
@@ -185,6 +185,23 @@
#define CONFIG_GENERIC_MMC
#define CONFIG_MXC_MMC
#define CONFIG_MXC_MCI_REGS_BASE SDHC1_BASE_ADDR
+
+/* video support */
+#define CONFIG_VIDEO
+#define CONFIG_VIDEO_MX3
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VIDEO_LOGO
+#define CONFIG_VIDEO_SW_CURSOR
+#define CONFIG_CONSOLE_EXTRA_INFO /* display additional board info */
+#define CONFIG_VGA_AS_SINGLE_DEVICE /* display is an output only device */
+/* allow stdin, stdout and stderr variables to redirect output */
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+
+/* allow decompressing max. 4MB */
+#define CONFIG_VIDEO_BMP_GZIP
+/* this is not only used by cfb_console.c for the logo, but also in cmd_bmp.c
*/
+#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (4*1024*1024)
+
/*
* Command definition
*/
@@ -201,6 +218,7 @@
* the NAND_CMD_LOCK_STATUS command, however the NFC of i.MX31 supports
* a software locking scheme.
*/
+#define CONFIG_CMD_BMP
#define CONFIG_BOOTDELAY 3
@@ -208,9 +226,18 @@
* currently a default setting for booting via script is implemented
* set user to login name and serverip to tftp host, define your
* boot behaviour in bootscript.loginname
+ *
+ * TT-01 board specific TFT setup (used by drivers/video/mx3fb.c)
+ *
+ * This set-up is for the L5F30947T04 by Epson, which is
+ * 800x480, 33MHz pixel clock, 60Hz vsync, 31.6kHz hsync
+ * sync must be set to: DI_D3_DRDY_SHARP_POL | DI_D3_CLK_POL
*/
#defineCONFIG_EXTRA_ENV_SETTINGS \
- bootcmd=dhcp bootscript.$(user); source\0
+videomode=epson\0 \
+epson=video=ctfb:x:800,y:480,depth:16,mode:0,pclk:30076, \
+ le:215,ri:1,up:32,lo:13,hs:7,vs:10,sync:100663296,vmode:0\0 \
+bootcmd=dhcp bootscript.$(user); source\0
#define CONFIG_BOOTP_SERVERIP /* tftp serverip not overruled by dhcp server */
#define CONFIG_BOOTP_SEND_HOSTNAME /* if env-var 'hostname' is set, send it */
--
1.7.4.4
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] tt01: fix environment size
size of environment must match erasable block size in the flash. Signed-off-by: Helmut Raiger helmut.rai...@hale.at --- include/configs/tt01.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/tt01.h b/include/configs/tt01.h index 6846816..8dd657c 100644 --- a/include/configs/tt01.h +++ b/include/configs/tt01.h @@ -131,7 +131,7 @@ #define CONFIG_ENV_IS_IN_FLASH #define CONFIG_ENV_SECT_SIZE (128 * 1024) -#define CONFIG_ENV_SIZE(8 * 1024) /* smaller for faster access */ +#define CONFIG_ENV_SIZE(128 * 1024) /* Address and size of Redundant Environment Sector*/ #define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) -- 1.7.4.4 -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] tt01: fix hush parser config, add release config
Add PREBOOT, SILENT_CONSOLE and DEVICE_NULLDEV for release
build. Fixed bug in CONFIG_SYS_HUSH_PARSER define.
Signed-off-by: Helmut Raiger helmut.rai...@hale.at
---
include/configs/tt01.h | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/configs/tt01.h b/include/configs/tt01.h
index a3b90d5..c5bfe5f 100644
--- a/include/configs/tt01.h
+++ b/include/configs/tt01.h
@@ -191,11 +191,16 @@
#define CONFIG_VIDEO_MX3
#define CONFIG_CFB_CONSOLE
#define CONFIG_VIDEO_LOGO
+/* splash image won't work with NAND boot, use preboot script */
#define CONFIG_VIDEO_SW_CURSOR
#define CONFIG_CONSOLE_EXTRA_INFO /* display additional board info */
#define CONFIG_VGA_AS_SINGLE_DEVICE /* display is an output only device */
+
/* allow stdin, stdout and stderr variables to redirect output */
#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+#define CONFIG_SILENT_CONSOLE /* UARTs used externally (release) */
+#define CONFIG_SYS_DEVICE_NULLDEV /* allow console to be turned off */
+#define CONFIG_PREBOOT
/* allow decompressing max. 4MB */
#define CONFIG_VIDEO_BMP_GZIP
@@ -237,14 +242,14 @@
videomode=epson\0 \
epson=video=ctfb:x:800,y:480,depth:16,mode:0,pclk:30076, \
le:215,ri:1,up:32,lo:13,hs:7,vs:10,sync:100663296,vmode:0\0 \
-bootcmd=dhcp bootscript.$(user); source\0
+bootcmd=dhcp bootscript.${user}; source\0
#define CONFIG_BOOTP_SERVERIP /* tftp serverip not overruled by dhcp server */
#define CONFIG_BOOTP_SEND_HOSTNAME /* if env-var 'hostname' is set, send it */
/* Miscellaneous configurable options */
-#define CONFIG_HUSH_PARSER
-#define CONFIG_PROMPT_HUSH_PS2
+#define CONFIG_SYS_HUSH_PARSER
+#define CONFIG_SYS_PROMPT_HUSH_PS2
#define CONFIG_SYS_LONGHELP/* undef to save memory */
#define CONFIG_SYS_PROMPT TT01
--
1.7.4.4
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] tt01: add MMC support
On 19/01/2012 08:27, Helmut Raiger wrote: board_mmc_init() initializes the pins of SDHC1 and turns on V_MMC1 of the PMIC. Config adds support for EXT2 and FAT. Signed-off-by: Helmut Raiger helmut.rai...@hale.at --- Applied to u-boot-imx, thanks. 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
Re: [U-Boot] [PATCH V3 1/2] mc13783.h: create and add regulator mode 0 and 1
On 18/01/2012 11:41, Helmut Raiger wrote: Add bit definitions for register 32 and 33 of Freescale MC13783. Signed-off-by: Helmut Raiger helmut.rai...@hale.at --- Applied to u-boot-imx, thanks. 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] Fwd: Re: U-Boot not auto booting
On 01/18/2012 04:09 AM, Michael Aldridge wrote: the autobooting function of uboot is not functioning properly on my sheevaplug with debian. I have set the bootcmd and bootdelay variables, but I still can't get it to work. I can watch the countdown hit zero, and I do not hit any buttons and then the whole process just stops at the prompt. If I disconnect the serial cable from the computer, it still fails to proceed with the boot process. Below is the dump of 'printenv' any suggestions? Marvell printenv autostart=yes baudrate=115200 bootargs=console=ttyS0,115200 bootargs_console=console=ttyS0,115200 bootcmd=setenv bootargs $(bootargs_console); run bootcmd_mmc; bootm 0x0080 0x0110 bootcmd_mmc=mmc init; ext2load mmc 0:1 0x0080 /uImage; ext2load mmc 0:1 0x0110 /uInitrd Can you load your uImage and uInitrd from the mmc? What version of uboot are you running? Nowadays 'mmc init' is 'mmc rescan'. Try to type the commands individually: $ mmc rescan $ ext2load mmc 0:1 0x /uImage $ ext2load mmc 0:1 0x /uInitrd $ bootm and see where it stops working. 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 2/3] mx28evk: add USB support
On 1/18/12, Matthias Fuchs matthias.fu...@esd.eu wrote: This patch enables USB host support on the MX28EVK board. Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu Tested-by: Fabio Estevam fabio.este...@freescale.com Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mx28evk: add USB support
On 1/30/12, Fabio Estevam feste...@gmail.com wrote: On 1/18/12, Matthias Fuchs matthias.fu...@esd.eu wrote: This patch enables USB host support on the MX28EVK board. Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu Tested-by: Fabio Estevam fabio.este...@freescale.com Adding Stefano. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Davinci uboot
On Fri, Jan 27, 2012 at 5:29 AM, Christian Riesch christian.rie...@omicron.at wrote: Hi Manju, On Fri, Jan 27, 2012 at 12:34 PM, Hadli, Manjunath manjunath.ha...@ti.com wrote: Hi Tom, These patches have been posted earlier and have gone necessary reviews and I feel they are ready to be pulled. Please pull these pathes. I think the last time you posted these patches was in September, right? Since then, a number of patches have been applied that do changes in arch/arm/cpu/arm926ejs/davinci and two boards have been added (Added Heiko Schocher to CC). Also, include/configs/da850_am18xxevm.h was removed. Support for the new SPL framework was introduced for davinci boards and I see that you had to change your patches due to these changes. I think you should therefore re-submit the entire series for review. To be clear, I agree. Thanks! -- Tom ___ 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 Sun, Jan 29, 2012 at 6:36 AM, Christian Riesch christian.rie...@omicron.at wrote: 3) As Sughosh pointed out, the current code changes the V bit (location of exceptions). Sughosh's patch removes this code that does this change. I'm not sure if this is correct or not, so maybe you, Tom, could put your TI hat on again and clarify this? OK, I've asked Christian for questions I can pass along, and here's what's I've learned: Q1) Currently, the low level initialization code for ARM926EJS CPUs in the u-boot bootloader clears the V-bit of the cp15 control register c1. By default, this bit is set on AM1808 and OMAP-L138 before u-boot ist started. Sughosh Ganu now submitted a patch to remove the code that clears the V bit because he states that these SoCs have no valid memory region at 0x0. I had a look at the memory map of the AM1808 and yes, there is no valid memory at 0x0, so the V bit should be set and not cleared. My question is: Since the AM1808 has no valid memory at 0x0, does clearing the V bit have any effect on the operation of the processor? Or is is just a don't care bit since it doesn't make any sense to clear it? A1) This may be a design question, but I can say that the default value of the V-bit is set to 1 because of tie-offs to the core, but I'm not sure if the functionality of the V-bit is still active. I would guess that it is because I see no reason we would have mucked around in the ARM core design to remove that functionality, so unless there is another tie-off to the core that disables the V-bit functionality entirely, I would guess clearing the V-bit is not a good idea. In fact, I don't see why the u-boot init code needs to mess with the default value of that bit ever, for any device or arch. Q2) RBL: In an earlier post to the u-boot mailing list Tom Rini wrote that the RBLs of AM1808 and OMAP-L138 do not turn on caches. Does this mean that caches (dcache and/or icache) are *never* enabled or does it mean that they get enabled and then disabled before RBL exits. In the latter case, does RBL do everything that is necessary to ensure consistency between data and instruction streams (as described in the ARM926EJ-S Technical Reference Manual, http://infocenter.arm.com/help/index.jsp, Section Instruction Memory Barrier.1. About the instruction memory barrier operation)? Are there maybe earlier versions of RBL in earlier versions of the SoC that have a bug here? A2) The RBL NEVER enables the caches. Unfortunately, this does slow the operation of the ROM boot loader, but it is what is -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 6/7] mx6q: mx6qsabrelite: Provide default serial flash bus and chip-select
On 01/29/2012 07:36 PM, Marek Vasut wrote: On 01/29/2012 03:16 PM, Marek Vasut wrote: On 01/29/2012 01:11 PM, Marek Vasut wrote: On 01/29/2012 12:18 PM, Marek Vasut wrote: Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com Acked-by: Dirk Behmedirk.be...@de.bosch.com Acked-by: Stefano Babicsba...@denx.de --- include/configs/mx6qsabrelite.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 8dd6e39..cc770e2 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -46,9 +46,12 @@ #define CONFIG_CMD_SF #ifdef CONFIG_CMD_SF +#define GPIO_3_19 ((2*32)+19) I'd expect this to be in platform headers? This is a choice made in the SabreLite design. I don't think the same choice has been made for other i.MX6 boards. I mean the definition of the GPIO_3_19 ... I don't think we want to set precedent for defining constants for the 100s of GPIO numbers. That said, I could achieve my objective of clarifying what the number meant (that the constant refers to a GP) by changing this: #define CONFIG_SF_DEFAULT_CS (0|(GPIO_3_198)) to this #define CONFIG_SF_DEFAULT_CS (0|(IMX_GPIO_NR(3,19)8)) Why the (0| part ? Anyway, that indeed looks better, more standard even. And I think for MX5, there was even stuff defining the GPIO numbers imported from Linux. M There's a bit of an issue with this. The IMX_GPIO_NR() macro is defined in arch-mx6/gpio.h which is normally included after mx6qsabrelite.h because the latter defines the machine. And the CPP will choke on that ? Assembler or linker. IMX_GPIO_NR will be undefined and treated as an external unless we add this nested include into include/configs/mx6qsabrelite.h: #ifndef __ASSEMBLY__ #includeasm/arch/gpio.h #endif arch-mx6/gpio.h isn't directly ASM-friendly. This seems like a lot of #include-foo for giving a name to a constant, don't you think? Better than redefining stuff, which will eventually lead to errors and breakage. Hmmm. I just noticed that the IMX_GPIO_NR() macro isn't in Stefano's tree. My previous patches were against Dirk's tree on GitHub, which has a patch from Troy: https://github.com/dirkbehme/u-boot-imx6/commit/c8b2870efd041f820a91eebcb888c84a4f79f1f6 If we move this macro into arch-mx6/imx-regs.h, we avoid the #if. Looking at the remaining content of gpio.h, it seems that it's driver-specific anyway (only the driver should be worried about the register layout of the GPIO controller). If there are no objections, I'll forward a separate patch to define the macro. Should this be based on Stefano's tree? Please advise, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 6/7] mx6q: mx6qsabrelite: Provide default serial flash bus and chip-select
On 01/29/2012 07:36 PM, Marek Vasut wrote: On 01/29/2012 03:16 PM, Marek Vasut wrote: On 01/29/2012 01:11 PM, Marek Vasut wrote: On 01/29/2012 12:18 PM, Marek Vasut wrote: Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com Acked-by: Dirk Behmedirk.be...@de.bosch.com Acked-by: Stefano Babicsba...@denx.de --- include/configs/mx6qsabrelite.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 8dd6e39..cc770e2 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -46,9 +46,12 @@ #define CONFIG_CMD_SF #ifdef CONFIG_CMD_SF +#define GPIO_3_19 ((2*32)+19) I'd expect this to be in platform headers? This is a choice made in the SabreLite design. I don't think the same choice has been made for other i.MX6 boards. I mean the definition of the GPIO_3_19 ... I don't think we want to set precedent for defining constants for the 100s of GPIO numbers. That said, I could achieve my objective of clarifying what the number meant (that the constant refers to a GP) by changing this: #define CONFIG_SF_DEFAULT_CS (0|(GPIO_3_198)) to this #define CONFIG_SF_DEFAULT_CS (0|(IMX_GPIO_NR(3,19)8)) Why the (0| part ? Anyway, that indeed looks better, more standard even. And I think for MX5, there was even stuff defining the GPIO numbers imported from Linux. M There's a bit of an issue with this. The IMX_GPIO_NR() macro is defined in arch-mx6/gpio.h which is normally included after mx6qsabrelite.h because the latter defines the machine. And the CPP will choke on that ? Assembler or linker. IMX_GPIO_NR will be undefined and treated as an external unless we add this nested include into include/configs/mx6qsabrelite.h: #ifndef __ASSEMBLY__ #includeasm/arch/gpio.h #endif arch-mx6/gpio.h isn't directly ASM-friendly. This seems like a lot of #include-foo for giving a name to a constant, don't you think? Better than redefining stuff, which will eventually lead to errors and breakage. Hmmm. I just noticed that the IMX_GPIO_NR() macro isn't in Stefano's tree. My previous patches were against Dirk's tree on GitHub, which has a patch from Troy: https://github.com/dirkbehme/u-boot- imx6/commit/c8b2870efd041f820a91eebcb8 88c84a4f79f1f6 If we move this macro into arch-mx6/imx-regs.h, we avoid the #if. Looking at the remaining content of gpio.h, it seems that it's driver-specific anyway (only the driver should be worried about the register layout of the GPIO controller). If there are no objections, I'll forward a separate patch to define the macro. Should this be based on Stefano's tree? Definitelly. Please rebase to u-boot-imx. Thanks for the patches and good work so far! M Please advise, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial : Device tree support for multiple serial devices.
Hi, On Mon, Jan 23, 2012 at 1:01 PM, hanumant hanuman...@gmail.com wrote: Hi The board that I am working on has multiple serial ports. I am trying to use device trees to configure board resource of these ports as well as the serial framework. So the driver doesnot know apriori the number of uart ports on the board. But querries the device tree for it.I am facing the following issues. 1) Ports are memory mapped and each port has its own register space. As such the serial framework apis dont provide for passing a port id at the time of the call. So how do i access the correct register space for the corresponding port?. Or should i define for my own set of apis to be called by clients, allowing me to access specific ports corresponding address space, and use the serial framework api's only for the default serial console? 2) the default serial console, also gets configured based on information obtained from the device tree, at run time. If i keep a global representation of the default serial console with its base address etc, it will still have to be reinitialized after relocation. The default_serial_console() gives me an opportunity to reinitialize the global structure. Is that the way to go? I have done similar things. IMO the right way to go is to refactor the serial API so that it takes a device pointer as the first parameter. I haven't done it though. What I did for now was to implement a new fdt_serial.c file which defines 4 separate sets of function (each set containing putc, getc, etc.) with the device pointer built in to those functions. It's really ugly, and is what eserial does. Those functions look up the device tree during init and redirect to the real serial driver's functions of the same name. I could probably rustle up a patch if it would help. Regards, Simon Thanks Hanumant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 6/7] mx6q: mx6qsabrelite: Provide default serial flash bus and chip-select
On 30.01.2012 19:10, Eric Nelson wrote: On 01/29/2012 07:36 PM, Marek Vasut wrote: On 01/29/2012 03:16 PM, Marek Vasut wrote: On 01/29/2012 01:11 PM, Marek Vasut wrote: On 01/29/2012 12:18 PM, Marek Vasut wrote: Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com Acked-by: Dirk Behmedirk.be...@de.bosch.com Acked-by: Stefano Babicsba...@denx.de --- include/configs/mx6qsabrelite.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 8dd6e39..cc770e2 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -46,9 +46,12 @@ #define CONFIG_CMD_SF #ifdef CONFIG_CMD_SF +#define GPIO_3_19 ((2*32)+19) I'd expect this to be in platform headers? This is a choice made in the SabreLite design. I don't think the same choice has been made for other i.MX6 boards. I mean the definition of the GPIO_3_19 ... I don't think we want to set precedent for defining constants for the 100s of GPIO numbers. That said, I could achieve my objective of clarifying what the number meant (that the constant refers to a GP) by changing this: #define CONFIG_SF_DEFAULT_CS (0|(GPIO_3_198)) to this #define CONFIG_SF_DEFAULT_CS (0|(IMX_GPIO_NR(3,19)8)) Why the (0| part ? Anyway, that indeed looks better, more standard even. And I think for MX5, there was even stuff defining the GPIO numbers imported from Linux. M There's a bit of an issue with this. The IMX_GPIO_NR() macro is defined in arch-mx6/gpio.h which is normally included after mx6qsabrelite.h because the latter defines the machine. And the CPP will choke on that ? Assembler or linker. IMX_GPIO_NR will be undefined and treated as an external unless we add this nested include into include/configs/mx6qsabrelite.h: #ifndef __ASSEMBLY__ #includeasm/arch/gpio.h #endif arch-mx6/gpio.h isn't directly ASM-friendly. This seems like a lot of #include-foo for giving a name to a constant, don't you think? Better than redefining stuff, which will eventually lead to errors and breakage. Hmmm. I just noticed that the IMX_GPIO_NR() macro isn't in Stefano's tree. My previous patches were against Dirk's tree on GitHub, which has a patch from Troy: https://github.com/dirkbehme/u-boot-imx6/commit/c8b2870efd041f820a91eebcb888c84a4f79f1f6 If we move this macro into arch-mx6/imx-regs.h, we avoid the #if. Looking at the remaining content of gpio.h, it seems that it's driver-specific anyway (only the driver should be worried about the register layout of the GPIO controller). If there are no objections, I'll forward a separate patch to define the macro. Yes, please. I have this on my todo list, too. But I haven't found the time to look at the consequences trying to mainline this patch. I.e. if we try to mainline this, we have to touch all gpio_xxx() functions to use this new macro? At least for i.MX6? Or does this macro apply for more i.MX SoCs? If yes, do we have to find out for which it will work? And move it to a i.MX common gpio header? And then touch all i.MX code it applies to? Anyway, many thanks for your good work! Best regards Dirk Btw.: It looks to me that the patch series to introduce the i.MX6 SPI driver increases from each version of the patch series to the next one. I'm not sure if this is ok? Or if we should try to split it to smaller chunks which would be easier to get them merged? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 6/7] mx6q: mx6qsabrelite: Provide default serial flash bus and chip-select
On 01/30/2012 11:35 AM, Dirk Behme wrote: On 30.01.2012 19:10, Eric Nelson wrote: On 01/29/2012 07:36 PM, Marek Vasut wrote: On 01/29/2012 03:16 PM, Marek Vasut wrote: On 01/29/2012 01:11 PM, Marek Vasut wrote: On 01/29/2012 12:18 PM, Marek Vasut wrote: Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com Acked-by: Dirk Behmedirk.be...@de.bosch.com Acked-by: Stefano Babicsba...@denx.de --- include/configs/mx6qsabrelite.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 8dd6e39..cc770e2 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -46,9 +46,12 @@ #define CONFIG_CMD_SF #ifdef CONFIG_CMD_SF +#define GPIO_3_19 ((2*32)+19) I'd expect this to be in platform headers? This is a choice made in the SabreLite design. I don't think the same choice has been made for other i.MX6 boards. I mean the definition of the GPIO_3_19 ... I don't think we want to set precedent for defining constants for the 100s of GPIO numbers. That said, I could achieve my objective of clarifying what the number meant (that the constant refers to a GP) by changing this: #define CONFIG_SF_DEFAULT_CS (0|(GPIO_3_198)) to this #define CONFIG_SF_DEFAULT_CS (0|(IMX_GPIO_NR(3,19)8)) Why the (0| part ? Anyway, that indeed looks better, more standard even. And I think for MX5, there was even stuff defining the GPIO numbers imported from Linux. M There's a bit of an issue with this. The IMX_GPIO_NR() macro is defined in arch-mx6/gpio.h which is normally included after mx6qsabrelite.h because the latter defines the machine. And the CPP will choke on that ? Assembler or linker. IMX_GPIO_NR will be undefined and treated as an external unless we add this nested include into include/configs/mx6qsabrelite.h: #ifndef __ASSEMBLY__ #includeasm/arch/gpio.h #endif arch-mx6/gpio.h isn't directly ASM-friendly. This seems like a lot of #include-foo for giving a name to a constant, don't you think? Better than redefining stuff, which will eventually lead to errors and breakage. Hmmm. I just noticed that the IMX_GPIO_NR() macro isn't in Stefano's tree. My previous patches were against Dirk's tree on GitHub, which has a patch from Troy: https://github.com/dirkbehme/u-boot-imx6/commit/c8b2870efd041f820a91eebcb888c84a4f79f1f6 If we move this macro into arch-mx6/imx-regs.h, we avoid the #if. Looking at the remaining content of gpio.h, it seems that it's driver-specific anyway (only the driver should be worried about the register layout of the GPIO controller). If there are no objections, I'll forward a separate patch to define the macro. Yes, please. I have this on my todo list, too. But I haven't found the time to look at the consequences trying to mainline this patch. I.e. if we try to mainline this, we have to touch all gpio_xxx() functions to use this new macro? At least for i.MX6? Or does this macro apply for more i.MX SoCs? If yes, do we have to find out for which it will work? And move it to a i.MX common gpio header? And then touch all i.MX code it applies to? At the moment, the only code which uses IMX_GPIO_NR() is specific to MX6Q and Sabre-Lite. I looked for some commonality, but didn't find any in the i.MX trees. arch-mx35/mx35-pins.h defines GPIO_TO_PORT() and GPIO_TO_INDEX() which are the opposite of IMX_GPIO_NR(). arch-mx5/mx5x_pins.h does the same. arch-davinci and arch-tegra2 both define GPIO_BANK() and GPIO_PORT() for the same purpose mx28 defines PAD_BANK() and PAD_PIN() but use an input of iomux_cfg_t and not an integer. The Linux model allows the platform to define the mapping from GPIO numbers - drivers but doesn't use the concept of banks except within a driver. IOW, it doesn't seem like there's an obvious right thing to do, so I'd like to suggest that either: - We define GPIO_NUMBER(bank,offset) inside imx-regs.h for use in mapping to GPIO numbers - We follow the convention of arch-mx5/ and arch-mx35 and define macros GPIO_TO_PORT() and GPIO_TO_INDEX() to go the other direction - We update drivers/gpio/mxc_gpio.c to use the GPIO_TO_PORT() and GPIO_TO_INDEX() macros instead of code like this: unsigned int port = gpio 5; Or we just use the constant 0x53 for this value (as is done for the efikamx and vision2 boards). Anyway, many thanks for your good work! Best regards Dirk Btw.: It looks to me that the patch series to introduce the i.MX6 SPI driver increases from each version of the patch series to the next one. I'm not sure if this is ok? Or if we should try to split it to smaller chunks which would be easier to get them merged? Point taken. I've been wondering whether there was a way to steer clear of the rabbit hole... At the moment, I think patches 1-3 have been acked and really comprise the 'refactoring' part. I think I've addressed all of the concerns about patch 4
[U-Boot] [PATCH 2/3] mx6q: Add support for ECSPI through mxc_spi driver
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
Acked-by: Dirk Behme dirk.be...@de.bosch.com
Acked-by: Stefano Babic sba...@denx.de
---
arch/arm/include/asm/arch-mx6/imx-regs.h | 44 ++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 5227b44..ec74ff2 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -190,6 +190,50 @@ struct src {
u32 gpr10;
};
+/* ECSPI registers */
+struct cspi_regs {
+ u32 rxdata;
+ u32 txdata;
+ u32 ctrl;
+ u32 cfg;
+ u32 intr;
+ u32 dma;
+ u32 stat;
+ u32 period;
+};
+
+/*
+ * CSPI register definitions
+ */
+#define MXC_ECSPI
+#define MXC_CSPICTRL_EN(1 0)
+#define MXC_CSPICTRL_MODE (1 1)
+#define MXC_CSPICTRL_XCH (1 2)
+#define MXC_CSPICTRL_CHIPSELECT(x) (((x) 0x3) 12)
+#define MXC_CSPICTRL_BITCOUNT(x) (((x) 0xfff) 20)
+#define MXC_CSPICTRL_PREDIV(x) (((x) 0xF) 12)
+#define MXC_CSPICTRL_POSTDIV(x)(((x) 0xF) 8)
+#define MXC_CSPICTRL_SELCHAN(x)(((x) 0x3) 18)
+#define MXC_CSPICTRL_MAXBITS 0xfff
+#define MXC_CSPICTRL_TC(1 7)
+#define MXC_CSPICTRL_RXOVF (1 6)
+#define MXC_CSPIPERIOD_32KHZ (1 15)
+#define MAX_SPI_BYTES 32
+
+/* Bit position inside CTRL register to be associated with SS */
+#define MXC_CSPICTRL_CHAN 18
+
+/* Bit position inside CON register to be associated with SS */
+#define MXC_CSPICON_POL4
+#define MXC_CSPICON_PHA0
+#define MXC_CSPICON_SSPOL 12
+#define MXC_SPI_BASE_ADDRESSES \
+ ECSPI1_BASE_ADDR, \
+ ECSPI2_BASE_ADDR, \
+ ECSPI3_BASE_ADDR, \
+ ECSPI4_BASE_ADDR, \
+ ECSPI5_BASE_ADDR
+
struct iim_regs {
u32 ctrl;
u32 ctrl_set;
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] mxc_spi refactoring (for mx6q and mx6qsabrelite)
This patch set refactors mxc_spi as described in http://lists.denx.de/pipermail/u-boot/2010-March/068791.html and requested in http://lists.denx.de/pipermail/u-boot/2012-January/116023.html in order to add support for the MX6Q in general and the mx6qsabrelite specifically. Patch 1 simply moves the conditional parts of mxc_spi.c into the respective CPU-specific imx-regs.h files. Patch 2 adds general support for SPI to the i.MX6. Patch 3 adds support to the mx6qsabrelite board ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] mxc_spi: move machine specifics into CPU headers
Move (E)CSPI register declarations into the imx-regs.h files for each supported
CPU
Introduce two new macros to control conditional setup
MXC_CSPI - Used for processors with the Configurable Serial Peripheral
Interface (MX3x)
MXC_ECSPI - For processors with Enhanced Configurable... (MX5x, MX6x)
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
Acked-by: Dirk Behme dirk.be...@de.bosch.com
Acked-by: Stefano Babic sba...@denx.de
---
arch/arm/include/asm/arch-mx31/imx-regs.h | 27
arch/arm/include/asm/arch-mx35/imx-regs.h | 25
arch/arm/include/asm/arch-mx5/imx-regs.h | 30 +
drivers/spi/mxc_spi.c | 93 ++---
4 files changed, 88 insertions(+), 87 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx31/imx-regs.h
b/arch/arm/include/asm/arch-mx31/imx-regs.h
index 798cc74..6454acb 100644
--- a/arch/arm/include/asm/arch-mx31/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx31/imx-regs.h
@@ -901,4 +901,31 @@ struct esdc_regs {
#define MXC_EHCI_IPPUE_DOWN(1 8)
#define MXC_EHCI_IPPUE_UP (1 9)
+/*
+ * CSPI register definitions
+ */
+#define MXC_CSPI
+#define MXC_CSPICTRL_EN(1 0)
+#define MXC_CSPICTRL_MODE (1 1)
+#define MXC_CSPICTRL_XCH (1 2)
+#define MXC_CSPICTRL_SMC (1 3)
+#define MXC_CSPICTRL_POL (1 4)
+#define MXC_CSPICTRL_PHA (1 5)
+#define MXC_CSPICTRL_SSCTL (1 6)
+#define MXC_CSPICTRL_SSPOL (1 7)
+#define MXC_CSPICTRL_CHIPSELECT(x) (((x) 0x3) 24)
+#define MXC_CSPICTRL_BITCOUNT(x) (((x) 0x1f) 8)
+#define MXC_CSPICTRL_DATARATE(x) (((x) 0x7) 16)
+#define MXC_CSPICTRL_TC(1 8)
+#define MXC_CSPICTRL_RXOVF (1 6)
+#define MXC_CSPICTRL_MAXBITS 0x1f
+
+#define MXC_CSPIPERIOD_32KHZ (1 15)
+#define MAX_SPI_BYTES 4
+
+#define MXC_SPI_BASE_ADDRESSES \
+ 0x43fa4000, \
+ 0x5001, \
+ 0x53f84000,
+
#endif /* __ASM_ARCH_MX31_IMX_REGS_H */
diff --git a/arch/arm/include/asm/arch-mx35/imx-regs.h
b/arch/arm/include/asm/arch-mx35/imx-regs.h
index df74508..e570ad1 100644
--- a/arch/arm/include/asm/arch-mx35/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx35/imx-regs.h
@@ -179,6 +179,31 @@
#define IPU_CONF_IC_EN (11)
#define IPU_CONF_SCI_EN(10)
+/*
+ * CSPI register definitions
+ */
+#define MXC_CSPI
+#define MXC_CSPICTRL_EN(1 0)
+#define MXC_CSPICTRL_MODE (1 1)
+#define MXC_CSPICTRL_XCH (1 2)
+#define MXC_CSPICTRL_SMC (1 3)
+#define MXC_CSPICTRL_POL (1 4)
+#define MXC_CSPICTRL_PHA (1 5)
+#define MXC_CSPICTRL_SSCTL (1 6)
+#define MXC_CSPICTRL_SSPOL (1 7)
+#define MXC_CSPICTRL_CHIPSELECT(x) (((x) 0x3) 12)
+#define MXC_CSPICTRL_BITCOUNT(x) (((x) 0xfff) 20)
+#define MXC_CSPICTRL_DATARATE(x) (((x) 0x7) 16)
+#define MXC_CSPICTRL_TC(1 7)
+#define MXC_CSPICTRL_RXOVF (1 6)
+#define MXC_CSPICTRL_MAXBITS 0xfff
+#define MXC_CSPIPERIOD_32KHZ (1 15)
+#define MAX_SPI_BYTES 4
+
+#define MXC_SPI_BASE_ADDRESSES \
+ 0x43fa4000, \
+ 0x5001,
+
#define GPIO_PORT_NUM 3
#define GPIO_NUM_PIN 32
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 0ee88d2..4fa6658 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -223,6 +223,36 @@
#define CS0_32M_CS1_32M_CS2_32M_CS3_32M3
/*
+ * CSPI register definitions
+ */
+#define MXC_ECSPI
+#define MXC_CSPICTRL_EN(1 0)
+#define MXC_CSPICTRL_MODE (1 1)
+#define MXC_CSPICTRL_XCH (1 2)
+#define MXC_CSPICTRL_CHIPSELECT(x) (((x) 0x3) 12)
+#define MXC_CSPICTRL_BITCOUNT(x) (((x) 0xfff) 20)
+#define MXC_CSPICTRL_PREDIV(x) (((x) 0xF) 12)
+#define MXC_CSPICTRL_POSTDIV(x)(((x) 0xF) 8)
+#define MXC_CSPICTRL_SELCHAN(x)(((x) 0x3) 18)
+#define MXC_CSPICTRL_MAXBITS 0xfff
+#define MXC_CSPICTRL_TC(1 7)
+#define MXC_CSPICTRL_RXOVF (1 6)
+#define MXC_CSPIPERIOD_32KHZ (1 15)
+#define MAX_SPI_BYTES 32
+
+/* Bit position inside CTRL register to be associated with SS */
+#define MXC_CSPICTRL_CHAN 18
+
+/* Bit position inside CON register to be associated with SS */
+#define MXC_CSPICON_POL4
+#define MXC_CSPICON_PHA0
+#define MXC_CSPICON_SSPOL 12
+#define MXC_SPI_BASE_ADDRESSES \
+ CSPI1_BASE_ADDR, \
+ CSPI2_BASE_ADDR, \
+ CSPI3_BASE_ADDR,
+
+/*
* Number of GPIO pins per port
*/
#define GPIO_NUM_PIN32
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 2fa7486..2e15318 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -33,93 +33,12 @@
#error i.MX27 CSPI not supported due to drastic differences in register
definitions \
See linux mxc_spi driver from Freescale for details.
-
-#elif
[U-Boot] [PATCH 3/3] mx6q: mx6qsabrelite: Add ECSPI support to the Sabrelite platform
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
Acked-by: Dirk Behme dirk.be...@de.bosch.com
Acked-by: Stefano Babic sba...@denx.de
---
board/freescale/mx6qsabrelite/imximage.cfg|2 +-
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 25 +
include/configs/mx6qsabrelite.h |9 +
3 files changed, 35 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 a53b01f..b4282aa 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -46,6 +46,10 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | 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);
@@ -193,6 +197,23 @@ int board_mmc_init(bd_t *bis)
}
#endif
+#ifdef CONFIG_MXC_SPI
+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(IMX_GPIO_NR(3, 19), 1);
+ imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
+ARRAY_SIZE(ecspi1_pads));
+}
+#endif
+
#define MII_1000BASET_CTRL 0x9
#define MII_EXTENDED_CTRL 0xb
#define MII_EXTENDED_DATAW 0xc
@@ -239,6 +260,10 @@ int board_eth_init(bd_t *bis)
return ret;
}
+#ifdef CONFIG_MXC_SPI
+ setup_spi();
+#endif
+
return 0;
}
diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h
index d650ee3..bcb1a42 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -44,6 +44,15 @@
#define CONFIG_MXC_UART
#define CONFIG_MXC_UART_BASE UART2_BASE
+#define CONFIG_CMD_SF
+#ifdef CONFIG_CMD_SF
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_SST
+#define CONFIG_MXC_SPI
+#define CONFIG_SF_DEFAULT_SPEED 2500
+#define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0)
+#endif
+
/* MMC Configs */
#define CONFIG_FSL_ESDHC
#define CONFIG_FSL_USDHC
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] SPI flash enhancements: allow default bus and chip-selects
Patch 1 modifies the 'sf' command to allow a default bus and chip-select to be specified by board headers. This allows a bare 'sf' probe command: U-Boot sf probe instead of the more cumbersome usage when a GPIO is tacked onto the chip-select. Otherwise, this command-line would be needed to specify GP3:19 on SabreLite: U-Boot sf probe 0x5300 Patch 2 provides a description of usage and configuration of CONFIG_CMD_SF. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] README: Add description of SPI Flash (SF) command configuration
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- README | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/README b/README index 9d713e8..4dbebcb 100644 --- a/README +++ b/README @@ -809,6 +809,7 @@ The following options need to be configured: (requires CONFIG_CMD_I2C) CONFIG_CMD_SETGETDCR Support for DCR Register access (4xx only) + CONFIG_CMD_SF * Read/write/erase SPI NOR flash CONFIG_CMD_SHA1SUMprint sha1 memory digest (requires CONFIG_CMD_MEMORY) CONFIG_CMD_SOURCE source command Support @@ -2191,6 +2192,25 @@ The following options need to be configured: allows to read/write in Dataflash via the standard commands cp, md... +- Serial Flash support + CONFIG_CMD_SF + + Defining this option enables SPI flash commands + 'sf probe/read/write/erase/update'. + + Usage requires an initial 'probe' to define the serial + flash parameters, followed by read/write/erase/update + commands. + + The following defaults may be provided by the platform + to handle the common case when only a single serial + flash is present on the system. + + CONFIG_SF_DEFAULT_BUS Bus identifier + CONFIG_SF_DEFAULT_CSChip-select + CONFIG_SF_DEFAULT_MODE (see include/spi.h) + CONFIG_SF_DEFAULT_SPEED in Hz + - SystemACE Support: CONFIG_SYSTEMACE -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] sf command: allow default bus and chip selects
This patch allows a board configuration file to provide default bus
and chip-selects for SPI flash so that first argument to the 'sf' command
is optional.
On boards that use the mxc_spi driver and a GPIO for chip select, this allows
a much simpler command line:
U-Boot sf probe
instead of
U-Boot sf probe 0x5300
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
common/cmd_sf.c | 37 +
1 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 612fd18..98e4162 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -17,6 +17,12 @@
#ifndef CONFIG_SF_DEFAULT_MODE
# define CONFIG_SF_DEFAULT_MODESPI_MODE_3
#endif
+#ifndef CONFIG_SF_DEFAULT_CS
+# define CONFIG_SF_DEFAULT_CS 0
+#endif
+#ifndef CONFIG_SF_DEFAULT_BUS
+# define CONFIG_SF_DEFAULT_BUS 0
+#endif
static struct spi_flash *flash;
@@ -63,27 +69,26 @@ static int sf_parse_len_arg(char *arg, ulong *len)
static int do_spi_flash_probe(int argc, char * const argv[])
{
- unsigned int bus = 0;
- unsigned int cs;
+ unsigned int bus = CONFIG_SF_DEFAULT_BUS;
+ unsigned int cs = CONFIG_SF_DEFAULT_CS;
unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
unsigned int mode = CONFIG_SF_DEFAULT_MODE;
char *endp;
struct spi_flash *new;
- if (argc 2)
- return -1;
-
- cs = simple_strtoul(argv[1], endp, 0);
- if (*argv[1] == 0 || (*endp != 0 *endp != ':'))
- return -1;
- if (*endp == ':') {
- if (endp[1] == 0)
- return -1;
-
- bus = cs;
- cs = simple_strtoul(endp + 1, endp, 0);
- if (*endp != 0)
+ if (argc = 2) {
+ cs = simple_strtoul(argv[1], endp, 0);
+ if (*argv[1] == 0 || (*endp != 0 *endp != ':'))
return -1;
+ if (*endp == ':') {
+ if (endp[1] == 0)
+ return -1;
+
+ bus = cs;
+ cs = simple_strtoul(endp + 1, endp, 0);
+ if (*endp != 0)
+ return -1;
+ }
}
if (argc = 3) {
@@ -299,7 +304,7 @@ usage:
U_BOOT_CMD(
sf, 5, 1, do_spi_flash,
SPI flash sub-system,
- probe [bus:]cs [hz] [mode] - init flash device on given SPI bus\n
+ probe [[bus:]cs] [hz] [mode] - init flash device on given SPI bus\n
and chip select\n
sf read addr offset len- read `len' bytes starting at\n
`offset' to memory at `addr'\n
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6q: mx6qsabrelite: Provide default serial flash bus and chip-select
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com Acked-by: Dirk Behme dirk.be...@de.bosch.com Acked-by: Stefano Babic sba...@denx.de --- include/configs/mx6qsabrelite.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index bcb1a42..3bf7819 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -46,9 +46,12 @@ #define CONFIG_CMD_SF #ifdef CONFIG_CMD_SF +#define GPIO_3_19 ((2*32)+19) #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_SST #define CONFIG_MXC_SPI +#define CONFIG_SF_DEFAULT_BUS 0 +#define CONFIG_SF_DEFAULT_CS (0|(GPIO_3_198)) #define CONFIG_SF_DEFAULT_SPEED 2500 #define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0) #endif -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6q: mx6qsabrelite: Conditionally define macros for environment in serial flash
The default settings store the persistent environment on SD card and not serial flash (SPI NOR). To use SPI NOR to save the environment instead of SD card, edit include/configs/mx6qsabrelite.h and - undefine CONFIG_ENV_IS_IN_MMC - define CONFIG_ENV_IS_IN_SPI_FLASH The SPI driver can take as chip select the controller's chip selects as well as an external GPIO. The LSB byte has the value of the internal chip select, the highest (thought as 16-bit value) contains the GPIO number. The GPIO used on Sabre Lite is GP3:19 == 83. --- include/configs/mx6qsabrelite.h | 18 +++--- 1 files changed, 15 insertions(+), 3 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 3bf7819..70c9d10 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -175,10 +175,22 @@ /* FLASH and environment organization */ #define CONFIG_SYS_NO_FLASH -#define CONFIG_ENV_OFFSET (6 * 64 * 1024) -#define CONFIG_ENV_SIZE(8 * 1024) +#define CONFIG_ENV_SIZE(8 * 1024) + #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_SYS_MMC_ENV_DEV 0 +/* #define CONFIG_ENV_IS_IN_SPI_FLASH */ + +#if defined(CONFIG_ENV_IS_IN_MMC) +#define CONFIG_ENV_OFFSET (6 * 64 * 1024) +#define CONFIG_SYS_MMC_ENV_DEV 0 +#elif defined(CONFIG_ENV_IS_IN_SPI_FLASH) +#define CONFIG_ENV_OFFSET (768 * 1024) +#define CONFIG_ENV_SECT_SIZE (8 * 1024) +#define CONFIG_ENV_SPI_BUS CONFIG_SF_DEFAULT_BUS +#define CONFIG_ENV_SPI_CS CONFIG_SF_DEFAULT_CS +#define CONFIG_ENV_SPI_MODECONFIG_SF_DEFAULT_MODE +#define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED +#endif #define CONFIG_OF_LIBFDT -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx28 spl power cpu clock configuration
Hi Robert, On Wed, Jan 25, 2012 at 2:36 PM, Robert Deliën rob...@delien.nl wrote: Hi Fabio, Could you please post a patch with your proposed change so that we can test it? I was hoping for a suggestion from you, as you know this SoC far better than me. Currently I am trying different solutions. Even though they prevent the system from hanging up, they still don't enable me to step through the code. And since therey's no problem with normal operation, I think they aren't worth anything unless they fix instruction stepping. But as Marek, says: Instruction stepping this section can fail for another reason. I talked to some folks that reported that RV-ICE Jtag works fine on mx28. Will send you offline their init script, so that you could compare it with your BDI 3000 script. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap_hsmmc: Wait for CMDI to be clear
Before we can send a command we need both the DATI (command inhibit on
mmc_dat line) bit and CMDI (command inhibit on mmc_cmd line) are clear.
The previous behavior of only checking on DATI was insufficient on some
cards and incorrect behavior in any case. This makes the code check
for both bits being clear and makes the error print more clear as
to what happened. DATI_CMDDIS is removed as it was unused elsewhere
in the code and stood for 'DATI is set, cmds are disabled still'.
Fix originally spotted by Peter Bigot.
Tested-by: Peter A. Bigot big...@acm.org
Tested-by: Robert Nelson robertcnel...@gmail.com
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/include/asm/arch-am33xx/mmc_host_def.h |2 +-
arch/arm/include/asm/arch-omap3/mmc_host_def.h |2 +-
arch/arm/include/asm/arch-omap4/mmc_host_def.h |2 +-
arch/arm/include/asm/arch-omap5/mmc_host_def.h |2 +-
drivers/mmc/omap_hsmmc.c|5 +++--
5 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/mmc_host_def.h
b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h
index 5d7dd4b..943526b 100644
--- a/arch/arm/include/asm/arch-am33xx/mmc_host_def.h
+++ b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h
@@ -97,7 +97,7 @@ typedef struct hsmmc {
#define INDEX_MASK (0x3f 24)
#define INDEX(i) (i 24)
#define DATI_MASK (0x1 1)
-#define DATI_CMDDIS(0x1 1)
+#define CMDI_MASK (0x1 0)
#define DTW_1_BITMODE (0x0 1)
#define DTW_4_BITMODE (0x1 1)
#define DTW_8_BITMODE (0x1 5) /* CON[DW8]*/
diff --git a/arch/arm/include/asm/arch-omap3/mmc_host_def.h
b/arch/arm/include/asm/arch-omap3/mmc_host_def.h
index 2963679..f8c42c0 100644
--- a/arch/arm/include/asm/arch-omap3/mmc_host_def.h
+++ b/arch/arm/include/asm/arch-omap3/mmc_host_def.h
@@ -129,7 +129,7 @@ struct hsmmc {
#define INDEX_MASK (0x3f 24)
#define INDEX(i) (i 24)
#define DATI_MASK (0x1 1)
-#define DATI_CMDDIS(0x1 1)
+#define CMDI_MASK (0x1 0)
#define DTW_1_BITMODE (0x0 1)
#define DTW_4_BITMODE (0x1 1)
#define DTW_8_BITMODE (0x1 5) /* CON[DW8]*/
diff --git a/arch/arm/include/asm/arch-omap4/mmc_host_def.h
b/arch/arm/include/asm/arch-omap4/mmc_host_def.h
index 74439c9..ce1bce1 100644
--- a/arch/arm/include/asm/arch-omap4/mmc_host_def.h
+++ b/arch/arm/include/asm/arch-omap4/mmc_host_def.h
@@ -107,7 +107,7 @@ struct hsmmc {
#define INDEX_MASK (0x3f 24)
#define INDEX(i) (i 24)
#define DATI_MASK (0x1 1)
-#define DATI_CMDDIS(0x1 1)
+#define CMDI_MASK (0x1 0)
#define DTW_1_BITMODE (0x0 1)
#define DTW_4_BITMODE (0x1 1)
#define DTW_8_BITMODE (0x1 5) /* CON[DW8]*/
diff --git a/arch/arm/include/asm/arch-omap5/mmc_host_def.h
b/arch/arm/include/asm/arch-omap5/mmc_host_def.h
index 74439c9..ce1bce1 100644
--- a/arch/arm/include/asm/arch-omap5/mmc_host_def.h
+++ b/arch/arm/include/asm/arch-omap5/mmc_host_def.h
@@ -107,7 +107,7 @@ struct hsmmc {
#define INDEX_MASK (0x3f 24)
#define INDEX(i) (i 24)
#define DATI_MASK (0x1 1)
-#define DATI_CMDDIS(0x1 1)
+#define CMDI_MASK (0x1 0)
#define DTW_1_BITMODE (0x0 1)
#define DTW_4_BITMODE (0x1 1)
#define DTW_8_BITMODE (0x1 5) /* CON[DW8]*/
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index ef64e37..2400db2 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -198,9 +198,10 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
ulong start;
start = get_timer(0);
- while ((readl(mmc_base-pstate) DATI_MASK) == DATI_CMDDIS) {
+ while ((readl(mmc_base-pstate) (DATI_MASK | CMDI_MASK)) != 0) {
if (get_timer(0) - start MAX_RETRY_MS) {
- printf(%s: timedout waiting for cmddis!\n, __func__);
+ printf(%s: timedout waiting on cmd inhibit to clear\n,
+ __func__);
return TIMEOUT;
}
}
--
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 3/4] net: phy: add support for Micrel's KSZ9021
On 1/29/2012 7:26 PM, Andy Fleming wrote:
NAK, for reasons listed below.
On Thu, Jan 26, 2012 at 4:21 PM, Troy Kisky
troy.ki...@boundarydevices.com wrote:
Add the gigabit phy KSZ9021.
Signed-off-by: Troy Kiskytroy.ki...@boundarydevices.com
These commit messages are a bit over-brief. Please explain a bit more
if there's anything non-trivial in the patch.
---
drivers/net/phy/Makefile |1 +
drivers/net/phy/micrel_ksz9021.c | 124 ++
drivers/net/phy/phy.c|3 +
3 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/phy/micrel_ksz9021.c
[...]
diff --git a/drivers/net/phy/micrel_ksz9021.c b/drivers/net/phy/micrel_ksz9021.c
+
+/* This is used to set board specific things like clock skew */
+unsigned short ksz9021_por_cmds[] = {
+#ifdef CONFIG_PHY_MICREL_KSZ9021_INIT_CMDS
+ CONFIG_PHY_MICREL_KSZ9021_INIT_CMDS
+#endif
+ 0, 0
+};
+
+int ksz9021_send_phy_cmds(struct phy_device *phydev, unsigned short* p)
+{
+ for (;;) {
+ unsigned reg = *p++;
+ unsigned val = *p++;
+ if (reg == 0 val == 0)
+ break;
+ if (reg 32) {
+ phy_write(phydev, MDIO_DEVAD_NONE, reg, val);
+ } else {
+ phy_write(phydev, MDIO_DEVAD_NONE,
+ MII_KSZ9021_EXTENDED_CTRL, reg);
+ phy_write(phydev, MDIO_DEVAD_NONE,
+ MII_KSZ9021_EXTENDED_DATAW, val);
+ }
+ }
+ return 0;
+}
For instance, some wacky data-driven initializer function which
totally works around any attempts the community might make at dealing
with initialization in a transparent and functional way, and is
essentially a whole (undocumented) API in and of itself.
This should be a separate patch including documentation. But that
doesn't sound
sufficient for you.
Basically, this is the sort of capability that all PHYs need, and if
the current framework isn't sufficient to this PHY's needs, then we
should look at modifying PHY Lib to provide better board-level
initialization capabilities.
An earlier version of something like PHY Lib had a similar type of
mechanism, but a list of register writes is often insufficient to the
task of performing necessary initialization. Sometimes, one needs to
wait until a write takes effect, or do a different write based on link
state information, or make other sorts of decisions.
I thought that was a clean method of keeping board specific things in
the board.h file,
without needing to duplicate code in the board.c file.
Please suggest an alternative method. Right now, I'm just dead in the
water and
cannot see the way forward. Do you want a more complete API? Or do you want
want this as a function in the board file?
I could use board_phy_config, but that would mean duplicated code in
other board files.
The only sticking point is that board_phy_config is called after
drv-config, not before or
instead of. If it was changed to instead of, I could add the call to
phydev-drv-config(phydev)
to all existing board_phy_config functions. Currently that is
board/freescale/corenet_ds/eth_p4080.c
board/freescale/mpc8544ds/mpc8544ds.c
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index eb55180..7e1e4b6 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -438,6 +438,9 @@ int phy_init(void)
#ifdef CONFIG_PHY_MICREL
phy_micrel_init();
#endif
+#ifdef CONFIG_PHY_MICREL_KSZ9021
+ phy_ksz9021_init();
+#endif
I believe we're sorting this list alphabetically
And now I see that this is actually a Micrel PHY. Why are you making a
separate file for it? Put this code in the micrel.c file.
So, you want ifdefs in the micrel.c file? That seems unnecessarily ugly.
The micrel file currently supports only the ksz804 and uses only
genphy_xxx functions. Perhaps renaming this file to micrel_ksz804.c
would be more appropriate. Alternatively, change the name to genphy.c
and change the structure to
static struct phy_driver genphy_driver = {
.name = CONFIG_GENPHY_NAME,
.uid = CONFIG_GENPHY_UID,
.mask = CONFIG_GENPHY_MASK,
.features = PHY_BASIC_FEATURES,
.config = genphy_config,
.startup = genphy_startup,
.shutdown = genphy_shutdown,
};
So that all phys which are generic can be easily defined by the board which
uses it.
I think phy_init should be changed to traverse a section created by the
linker so that all these ifdefs could disappear. Something like
#define __phy_init_section __attribute__ ((__section__
(.data.phy_init_section)))
typedef int(*phy_init_rtn)(void);
static phy_init_rtn ksz9021_phy_init_rtn __phy_init_section =
phy_ksz9021_init;
extern phy_init_rtn __phy_init_section_start, __phy_init_section_end;
int phy_init(void)
{
phy_init_rtn* rtn = __phy_init_section_start;
while (rtn
Re: [U-Boot] mx28 spl power cpu clock configuration
Hi Robert, On Wed, Jan 25, 2012 at 2:36 PM, Robert Deliën rob...@delien.nl wrote: Hi Fabio, Could you please post a patch with your proposed change so that we can test it? I was hoping for a suggestion from you, as you know this SoC far better than me. Currently I am trying different solutions. Even though they prevent the system from hanging up, they still don't enable me to step through the code. And since therey's no problem with normal operation, I think they aren't worth anything unless they fix instruction stepping. But as Marek, says: Instruction stepping this section can fail for another reason. I talked to some folks that reported that RV-ICE Jtag works fine on mx28. Will send you offline their init script, so that you could compare it with your BDI 3000 script. Hi Fabio, did they also test stepping through the power_init() ? M Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx28 spl power cpu clock configuration
Hi Fabio, Could you please post a patch with your proposed change so that we can test it? Still working on it. Got delayed by an incompatibility between the SoC and an SD-Card controller. I'm the only software developer currently on this project, so I swich back-and-forth all the time. Sorry, but you'll get it when I have it. I talked to some folks that reported that RV-ICE Jtag works fine on mx28. Will send you offline their init script, so that you could compare it with your BDI 3000 script. That would be great! But I'm pretty sure they won't be able to step through the pll bypass disabling in spl_power, because that is stalling the CPU clock and disables JTAG. But I'll give it a good look; perhaps they've come up with something I didn't notice. Thanks a lot! Cheers, Robert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx28 spl power cpu clock configuration
On Mon, Jan 30, 2012 at 7:53 PM, Marek Vasut marek.va...@gmail.com wrote: Hi Fabio, did they also test stepping through the power_init() ? They tested stepping using their standalone code, not U-boot. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial : Device tree support for multiple serial devices.
On 1/30/2012 10:35 AM, Simon Glass wrote: What I did for now was to implement a new fdt_serial.c file which defines 4 separate sets of function (each set containing putc, getc, etc.) with the device pointer built in to those functions. It's really ugly, and is what eserial does. Those functions look up the device tree during init and redirect to the real serial driver's functions of the same name. I could probably rustle up a patch if it would help. Thank you a patch would help a great deal. Thanks hanumant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx28 spl power cpu clock configuration
On Mon, Jan 30, 2012 at 7:53 PM, Marek Vasut marek.va...@gmail.com wrote: Hi Fabio, did they also test stepping through the power_init() ? They tested stepping using their standalone code, not U-boot. Regards, Fabio Estevam Can you jab me on G? I'm on the problem and I have a possible suspect. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] integrator: rewrite the AP PCI driver
The PCI support for the Integrator AP has apparently never
been finished and I strongly suspect that it has never worked,
so let's fix it. This is a list of the more or less
un-splittable changes done in this driver rewrite:
- Replace the register definitions stashed into the config
file (!) with a copy if the register file from the Linux
kernels arch/arm/include/asm/hardware/pci_v3.h
- Delete the unreadable gigantic macros that perform the
config accesses and replace them with copyedited code from
Linux arch/arm/mach-integrator/pci_v3.c
- Rewrite the rest of the setup code to use the
v3_[read|write][lwb]() accessors.
- Enable PCI by default in the AP board configuration.
- Fix checkpatch warnings and make code more conformant.
Tested-by: Will Deacon will.dea...@arm.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
board/armltd/integrator/pci.c| 582 ++
board/armltd/integrator/pci_v3.h | 200 +
include/configs/integratorap.h | 148 +-
3 files changed, 538 insertions(+), 392 deletions(-)
create mode 100644 board/armltd/integrator/pci_v3.h
diff --git a/board/armltd/integrator/pci.c b/board/armltd/integrator/pci.c
index 6ee2a85..f040450 100644
--- a/board/armltd/integrator/pci.c
+++ b/board/armltd/integrator/pci.c
@@ -14,6 +14,10 @@
* ARM Ltd.
* Philippe Robin, philippe.ro...@arm.com
*
+ * (C) Copyright 2011
+ * Linaro
+ * Linus Walleij linus.wall...@linaro.org
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -32,15 +36,53 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
-
#include common.h
#include pci.h
+#include asm/io.h
+#include integrator-sc.h
+#include pci_v3.h
+
+#define INTEGRATOR_BOOT_ROM_BASE 0x2000
+#define INTEGRATOR_HDR0_SDRAM_BASE 0x8000
+
+/*
+ * These are in the physical addresses on the CPU side, i.e.
+ * where we read and write stuff - you don't want to try to
+ * move these around
+ */
+#define PHYS_PCI_MEM_BASE 0x4000
+#define PHYS_PCI_IO_BASE 0x6000 /* PCI I/O space base */
+#define PHYS_PCI_CONFIG_BASE 0x6100
+#define PHYS_PCI_V3_BASE 0x6200 /* V360EPC registers */
+#define SZ_256M0x1000
+
+/*
+ * These are in the PCI BUS address space
+ * Set to 0x in the Linux kernel, 0x4000 in Boot monitor
+ * we follow the example of the kernel, because that is the address
+ * range that devices actually use - what would they be doing at
+ * 0x4000?
+ */
+#define PCI_BUS_NONMEM_START 0x
+#define PCI_BUS_NONMEM_SIZESZ_256M
+
+#define PCI_BUS_PREMEM_START (PCI_BUS_NONMEM_START + PCI_BUS_NONMEM_SIZE)
+#define PCI_BUS_PREMEM_SIZESZ_256M
+
+#if PCI_BUS_NONMEM_START 0x000f
+#error PCI_BUS_NONMEM_START must be megabyte aligned
+#endif
+#if PCI_BUS_PREMEM_START 0x000f
+#error PCI_BUS_PREMEM_START must be megabyte aligned
+#endif
/*
* Initialize PCI Devices, report devices found.
*/
#ifndef CONFIG_PCI_PNP
+#define PCI_ENET0_IOADDR 0x6000 /* First card in PCI I/O space */
+#define PCI_ENET0_MEMADDR 0x4000 /* First card in PCI memory space */
static struct pci_config_table pci_integrator_config_table[] = {
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0x0f, PCI_ANY_ID,
pci_cfgfunc_config_device, { PCI_ENET0_IOADDR,
@@ -51,163 +93,187 @@ static struct pci_config_table
pci_integrator_config_table[] = {
#endif /* CONFIG_PCI_PNP */
/* V3 access routines */
-#define _V3Write16(o,v) (*(volatile unsigned short *)(PCI_V3_BASE + (unsigned
int)(o)) = (unsigned short)(v))
-#define _V3Read16(o) (*(volatile unsigned short *)(PCI_V3_BASE + (unsigned
int)(o)))
-
-#define _V3Write32(o,v) (*(volatile unsigned int *)(PCI_V3_BASE + (unsigned
int)(o)) = (unsigned int)(v))
-#define _V3Read32(o) (*(volatile unsigned int *)(PCI_V3_BASE + (unsigned
int)(o)))
-
-/* Compute address necessary to access PCI config space for the given */
-/* bus and device. */
-#define PCI_CONFIG_ADDRESS( __bus, __devfn, __offset ) ({
\
- unsigned int __address, __devicebit;
\
- unsigned short __mapaddress;
\
- unsigned int __dev = PCI_DEV (__devfn); /* FIXME to check!! (slot?) */
\
-
\
- if (__bus == 0) {
\
- /* local bus segment so need a type 0 config cycle */
\
- /* build the PCI configuration address with one-hot in
A31-A11 */ \
- __address = PCI_CONFIG_BASE;
\
- __address |= ((__devfn 0x07) 8);
\
-
[U-Boot] [PATCH] i.MX28: Fix VDDIO and VDDA setup
The DC power STS shouldn't be checked if booting off 5V supply.
Signed-off-by: Marek Vasut marek.va...@gmail.com
Cc: Wolfgang Denk w...@denx.de
Cc: Detlev Zundel d...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Robert Deliën rob...@delien.nl
Cc: Fabio Estevam feste...@gmail.com
Cc: Matthias Fuchs matthias.fu...@esd.eu
---
arch/arm/cpu/arm926ejs/mx28/spl_power_init.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
Note: Guys, please give this a testrun. I think it might fix the issue Robert
was observing. I dug into the imx-bootlets and the bootrom X-Files and found
this paranormal piece of code. Adding it fixes the boot issue on my crappy
board.
M
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
index ee0f237..c6c25d9 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -802,7 +802,9 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
new_brownout)
clrsetbits_le32(power_regs-hw_power_vddioctrl,
POWER_VDDIOCTRL_TRG_MASK, diff);
- if (powered_by_linreg)
+ if (powered_by_linreg ||
+ (readl(power_regs-hw_power_sts)
+ POWER_STS_VDD5V_GT_VDDIO))
early_delay(1500);
else {
while (!(readl(power_regs-hw_power_sts)
@@ -837,7 +839,9 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
new_brownout)
clrsetbits_le32(power_regs-hw_power_vddioctrl,
POWER_VDDIOCTRL_TRG_MASK, diff);
- if (powered_by_linreg)
+ if (powered_by_linreg ||
+ (readl(power_regs-hw_power_sts)
+ POWER_STS_VDD5V_GT_VDDIO))
early_delay(1500);
else {
while (!(readl(power_regs-hw_power_sts)
@@ -895,7 +899,9 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t
new_brownout)
clrsetbits_le32(power_regs-hw_power_vdddctrl,
POWER_VDDDCTRL_TRG_MASK, diff);
- if (powered_by_linreg)
+ if (powered_by_linreg ||
+ (readl(power_regs-hw_power_sts)
+ POWER_STS_VDD5V_GT_VDDIO))
early_delay(1500);
else {
while (!(readl(power_regs-hw_power_sts)
@@ -930,7 +936,9 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t
new_brownout)
clrsetbits_le32(power_regs-hw_power_vdddctrl,
POWER_VDDDCTRL_TRG_MASK, diff);
- if (powered_by_linreg)
+ if (powered_by_linreg ||
+ (readl(power_regs-hw_power_sts)
+ POWER_STS_VDD5V_GT_VDDIO))
early_delay(1500);
else {
while (!(readl(power_regs-hw_power_sts)
--
1.7.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] net: phy: add support for Micrel's KSZ9021
On Mon, Jan 30, 2012 at 3:30 PM, Troy Kisky
troy.ki...@boundarydevices.com wrote:
On 1/29/2012 7:26 PM, Andy Fleming wrote:
NAK, for reasons listed below.
An earlier version of something like PHY Lib had a similar type of
mechanism, but a list of register writes is often insufficient to the
task of performing necessary initialization. Sometimes, one needs to
wait until a write takes effect, or do a different write based on link
state information, or make other sorts of decisions.
I thought that was a clean method of keeping board specific things in the
board.h file,
without needing to duplicate code in the board.c file.
It seems that way, but, as I said, it can lead to more problems in the
future. It also makes the reasons for the initialization sequences
much less comprehensible.
Please suggest an alternative method. Right now, I'm just dead in the water
and
cannot see the way forward. Do you want a more complete API? Or do you want
want this as a function in the board file?
I could use board_phy_config, but that would mean duplicated code in other
board files.
The only sticking point is that board_phy_config is called after
drv-config, not before or
instead of. If it was changed to instead of, I could add the call to
phydev-drv-config(phydev)
to all existing board_phy_config functions. Currently that is
board/freescale/corenet_ds/eth_p4080.c
board/freescale/mpc8544ds/mpc8544ds.c
Calling board_phy_config() instead of drv-config() might be the most
straightforward solution. You don't have to have duplicate code,
though. If a given set of boards will have the same initialization
sequence, then share the code between them. Also, as these sequences
are all probably either enabling/disabling well-understood features,
or configuration, you could put those functions in the PHY driver
code, and your board code ends up looking like:
/* Muxing on bus adds extra delay on RX path */
ksz9021_set_rx_delay(phydev, 12ns);
/* New isolinear circuits go to 11 */
ksz9021_adjust_resonance_frequency(11);
/* Accidental feedback loop caused PHY to achieve homicidal rage */
ksz9021_disable_emotion_chip(phydev);
And there are other factors, which could be handled *generically* by
the config() function for your PHY:
if (phydev-interface == PHY_INTERFACE_MODE_SGMII) {
int cfg = phy_read(phydev, KSZ9021_CONFIG_SPECIAL);
cfg |= KSZ021_SGMII_MODE;
phy_write(phydev, KSZ9021_CONFIG_SPECIAL, cfg);
} else ...
That's the best solution, as it helps to contain knowledge about the
PHY inside the driver. However, there are definitely times when the
PHY requires some very specific configuration steps, which are best
contained in board code.
Summary: Yes, I think it would be a good idea to convert all the
current calls to phydev-drv-config to board_phy_config(), which
should default to just calling drv-config().
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index eb55180..7e1e4b6 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -438,6 +438,9 @@ int phy_init(void)
#ifdef CONFIG_PHY_MICREL
phy_micrel_init();
#endif
+#ifdef CONFIG_PHY_MICREL_KSZ9021
+ phy_ksz9021_init();
+#endif
I believe we're sorting this list alphabetically
And now I see that this is actually a Micrel PHY. Why are you making a
separate file for it? Put this code in the micrel.c file.
So, you want ifdefs in the micrel.c file? That seems unnecessarily ugly.
The micrel file currently supports only the ksz804 and uses only
genphy_xxx functions. Perhaps renaming this file to micrel_ksz804.c
would be more appropriate. Alternatively, change the name to genphy.c
and change the structure to
static struct phy_driver genphy_driver = {
.name = CONFIG_GENPHY_NAME,
.uid = CONFIG_GENPHY_UID,
.mask = CONFIG_GENPHY_MASK,
.features = PHY_BASIC_FEATURES,
.config = genphy_config,
.startup = genphy_startup,
.shutdown = genphy_shutdown,
};
So that all phys which are generic can be easily defined by the board which
uses it.
I meant you should follow the example of marvell.c or vitesse.c, and
put all Micrel PHY code in the micrel.c file. Frequently, the
different PHYs from the same companies share common features. We may
divide them up differently, later, but, if anything, this driver
should be the micrel driver, and the existing one is just a stub.
The idea of allowing the Micrel stub PHY to exist was so that someone
might come along one day, and decide to add to its functionality. It
seems likely that your code may get repurposed by some other developer
to better support the 804 on her board.
I think phy_init should be changed to traverse a section created by the
linker so that all these ifdefs could disappear. Something like
#define __phy_init_section __attribute__ ((__section__
(.data.phy_init_section)))
typedef int(*phy_init_rtn)(void);
static phy_init_rtn ksz9021_phy_init_rtn __phy_init_section =
phy_ksz9021_init;
[U-Boot] [PATCH] i.MX28: Make the stabilization delays shorter
Cut down the VDDIO/VDDA regulator stabilization delays to 500 uS. That should be
enough according to the datasheet and bootlets.
Signed-off-by: Marek Vasut marek.va...@gmail.com
Cc: Wolfgang Denk w...@denx.de
Cc: Detlev Zundel d...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Robert Deliën rob...@delien.nl
Cc: Fabio Estevam feste...@gmail.com
Cc: Matthias Fuchs matthias.fu...@esd.eu
---
arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
index c6c25d9..4b09b0c 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -805,7 +805,7 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
new_brownout)
if (powered_by_linreg ||
(readl(power_regs-hw_power_sts)
POWER_STS_VDD5V_GT_VDDIO))
- early_delay(1500);
+ early_delay(500);
else {
while (!(readl(power_regs-hw_power_sts)
POWER_STS_DC_OK))
@@ -842,7 +842,7 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
new_brownout)
if (powered_by_linreg ||
(readl(power_regs-hw_power_sts)
POWER_STS_VDD5V_GT_VDDIO))
- early_delay(1500);
+ early_delay(500);
else {
while (!(readl(power_regs-hw_power_sts)
POWER_STS_DC_OK))
@@ -902,7 +902,7 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t
new_brownout)
if (powered_by_linreg ||
(readl(power_regs-hw_power_sts)
POWER_STS_VDD5V_GT_VDDIO))
- early_delay(1500);
+ early_delay(500);
else {
while (!(readl(power_regs-hw_power_sts)
POWER_STS_DC_OK))
@@ -939,7 +939,7 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t
new_brownout)
if (powered_by_linreg ||
(readl(power_regs-hw_power_sts)
POWER_STS_VDD5V_GT_VDDIO))
- early_delay(1500);
+ early_delay(500);
else {
while (!(readl(power_regs-hw_power_sts)
POWER_STS_DC_OK))
--
1.7.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] net: phy: add support for Micrel's KSZ9021
On 1/30/2012 5:05 PM, Andy Fleming wrote:
On Mon, Jan 30, 2012 at 3:30 PM, Troy Kisky
troy.ki...@boundarydevices.com wrote:
On 1/29/2012 7:26 PM, Andy Fleming wrote:
NAK, for reasons listed below.
An earlier version of something like PHY Lib had a similar type of
mechanism, but a list of register writes is often insufficient to the
task of performing necessary initialization. Sometimes, one needs to
wait until a write takes effect, or do a different write based on link
state information, or make other sorts of decisions.
I thought that was a clean method of keeping board specific things in the
board.h file,
without needing to duplicate code in the board.c file.
It seems that way, but, as I said, it can lead to more problems in the
future. It also makes the reasons for the initialization sequences
much less comprehensible.
I'll take your word, as I have more difficulty imagining your future.
Please suggest an alternative method. Right now, I'm just dead in the water
and
cannot see the way forward. Do you want a more complete API? Or do you want
want this as a function in the board file?
I could use board_phy_config, but that would mean duplicated code in other
board files.
The only sticking point is that board_phy_config is called after
drv-config, not before or
instead of. If it was changed to instead of, I could add the call to
phydev-drv-config(phydev)
to all existing board_phy_config functions. Currently that is
board/freescale/corenet_ds/eth_p4080.c
board/freescale/mpc8544ds/mpc8544ds.c
Calling board_phy_config() instead of drv-config() might be the most
straightforward solution. You don't have to have duplicate code,
though. If a given set of boards will have the same initialization
sequence, then share the code between them. Also, as these sequences
are all probably either enabling/disabling well-understood features,
or configuration, you could put those functions in the PHY driver
code, and your board code ends up looking like:
/* Muxing on bus adds extra delay on RX path */
ksz9021_set_rx_delay(phydev, 12ns);
/* New isolinear circuits go to 11 */
ksz9021_adjust_resonance_frequency(11);
/* Accidental feedback loop caused PHY to achieve homicidal rage */
ksz9021_disable_emotion_chip(phydev);
And there are other factors, which could be handled *generically* by
the config() function for your PHY:
if (phydev-interface == PHY_INTERFACE_MODE_SGMII) {
int cfg = phy_read(phydev, KSZ9021_CONFIG_SPECIAL);
cfg |= KSZ021_SGMII_MODE;
phy_write(phydev, KSZ9021_CONFIG_SPECIAL, cfg);
} else ...
That's the best solution, as it helps to contain knowledge about the
PHY inside the driver. However, there are definitely times when the
PHY requires some very specific configuration steps, which are best
contained in board code.
Summary: Yes, I think it would be a good idea to convert all the
current calls to phydev-drv-config to board_phy_config(), which
should default to just calling drv-config().
Can do.
Thanks for providing a direction.
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index eb55180..7e1e4b6 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -438,6 +438,9 @@ int phy_init(void)
#ifdef CONFIG_PHY_MICREL
phy_micrel_init();
#endif
+#ifdef CONFIG_PHY_MICREL_KSZ9021
+ phy_ksz9021_init();
+#endif
I believe we're sorting this list alphabetically
And now I see that this is actually a Micrel PHY. Why are you making a
separate file for it? Put this code in the micrel.c file.
So, you want ifdefs in the micrel.c file? That seems unnecessarily ugly.
The micrel file currently supports only the ksz804 and uses only
genphy_xxx functions. Perhaps renaming this file to micrel_ksz804.c
would be more appropriate. Alternatively, change the name to genphy.c
and change the structure to
static struct phy_driver genphy_driver = {
.name = CONFIG_GENPHY_NAME,
.uid = CONFIG_GENPHY_UID,
.mask = CONFIG_GENPHY_MASK,
.features = PHY_BASIC_FEATURES,
.config =genphy_config,
.startup =genphy_startup,
.shutdown =genphy_shutdown,
};
So that all phys which are generic can be easily defined by the board which
uses it.
I meant you should follow the example of marvell.c or vitesse.c, and
put all Micrel PHY code in the micrel.c file. Frequently, the
different PHYs from the same companies share common features. We may
divide them up differently, later, but, if anything, this driver
should be the micrel driver, and the existing one is just a stub.
The idea of allowing the Micrel stub PHY to exist was so that someone
might come along one day, and decide to add to its functionality. It
seems likely that your code may get repurposed by some other developer
to better support the 804 on her board.
I'm doubtful, since that code has not changed since your initial commit
back in April.
Is anyone still using it today? Seems only powerPC platforms with
CONFIG_TSEC_ENET
have had a chance. But I guess that is an irrelevant
Re: [U-Boot] [PATCH 2/4] net: fec_mxc: add PHYLIB support
On 1/29/2012 7:04 PM, Andy Fleming wrote:
On Thu, Jan 26, 2012 at 4:21 PM, Troy Kisky
troy.ki...@boundarydevices.com wrote:
Signed-off-by: Troy Kiskytroy.ki...@boundarydevices.com
---
drivers/net/fec_mxc.c | 35 ++-
drivers/net/fec_mxc.h |1 +
2 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 3fffe79..4d7a38d 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -371,6 +371,20 @@ static int fec_set_hwaddr(struct eth_device *dev)
return 0;
}
+static void fec_eth_phy_config(struct eth_device *dev)
+{
+#ifdef CONFIG_PHYLIB
+ struct fec_priv *fec = (struct fec_priv *)dev-priv;
+ struct phy_device *phydev;
+
+ phydev = phy_connect(miiphy_get_dev_by_name(dev-name),
+ fec-phy_id, dev, PHY_INTERFACE_MODE_RGMII);
+ fec-phydev = phydev;
+ if (phydev)
+ phy_config(phydev);
+#endif
+}
+
/**
* Start the FEC engine
* @param[in] dev Our device to handle
@@ -427,9 +441,19 @@ static int fec_open(struct eth_device *edev)
}
#endif
- miiphy_wait_aneg(edev);
- speed = miiphy_speed(edev-name, fec-phy_id);
- miiphy_duplex(edev-name, fec-phy_id);
+ if (fec-phydev) {
+ /* Start up the PHY */
+#ifdef CONFIG_PHYLIB
+ phy_startup(fec-phydev);
+#endif
The old miiphy code is not truly compatible with the new PHY Lib code.
Please implement full support, rather than relying on the
compatibility shim. It should be straightforward, just convert all of
the miiphy-style calls into the newer mdio/phy calls.
Andy
How can I do this without running the risk of breaking existing boards?
Surely, there should be an intermediate stage where both are supported
until all boards are converted. Then, my shim can be safely removed.
Or am I entirely missing you point???
Sorry if I am. Please elaborate on how not to break existing boards which
I cannot test.
Thanks
Troy
___
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 Mon Jan 30, 2012 at 10:03:40AM -0700, Tom Rini wrote: Q1) Currently, the low level initialization code for ARM926EJS CPUs in the u-boot bootloader clears the V-bit of the cp15 control register c1. By default, this bit is set on AM1808 and OMAP-L138 before u-boot ist started. Sughosh Ganu now submitted a patch to remove the code that clears the V bit because he states that these SoCs have no valid memory region at 0x0. I had a look at the memory map of the AM1808 and yes, there is no valid memory at 0x0, so the V bit should be set and not cleared. My question is: Since the AM1808 has no valid memory at 0x0, does clearing the V bit have any effect on the operation of the processor? Or is is just a don't care bit since it doesn't make any sense to clear it? A1) This may be a design question, but I can say that the default value of the V-bit is set to 1 because of tie-offs to the core, but I'm not sure if the functionality of the V-bit is still active. I would guess that it is because I see no reason we would have mucked around in the ARM core design to remove that functionality, so unless there is another tie-off to the core that disables the V-bit functionality entirely, I would guess clearing the V-bit is not a good idea. In fact, I don't see why the u-boot init code needs to mess with the default value of that bit ever, for any device or arch. I'm not sure about whether the V-bit functionality is disabled by some setting, but the omapl-138 ref manual states this(section 2.4 Exceptions and Exception Vectors). NOTE: The VINTH signal is configurable by way of the register setting in CP15. However, it is not recommended to set VINTH = 0, as the device has no physical memory in the h address region. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4] AT91: pio: Add PIO3 features
This patch adds the support for new PIO controller introduced by some
AT91 SoCs.
New features include
* More peripheral multiplexing
* Pull-down, Schmitt trigger, Debouncer
* More irq trigger mode (may be not interesting in U-Boot)
Signed-off-by: Hong Xu hong...@atmel.com
Acked-by: Remy Bohmer li...@bohmer.net
---
Changes since V3
Add Acked-by from Remy Bohmer
arch/arm/include/asm/arch-at91/at91_pio.h | 48 ++-
drivers/gpio/at91_gpio.c | 130 +++-
2 files changed, 171 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/arch-at91/at91_pio.h
b/arch/arm/include/asm/arch-at91/at91_pio.h
index 416cabf..069368d 100644
--- a/arch/arm/include/asm/arch-at91/at91_pio.h
+++ b/arch/arm/include/asm/arch-at91/at91_pio.h
@@ -4,6 +4,7 @@
* Copyright (C) 2005 Ivan Kokshaysky
* Copyright (C) SAN People
* Copyright (C) 2009 Jens Scharsig (js_at...@scharsoft.de)
+ * Copyright (C) 2011 Hong Xu (hong...@atmel.com)
*
* Parallel I/O Controller (PIO) - System peripherals registers.
* Based on AT91RM9200 datasheet revision E.
@@ -17,7 +18,6 @@
#ifndef AT91_PIO_H
#define AT91_PIO_H
-
#define AT91_ASM_PIO_RANGE 0x200
#define AT91_ASM_PIOC_ASR \
(ATMEL_BASE_PIO + AT91_PIO_PORTC * AT91_ASM_PIO_RANGE + 0x70)
@@ -66,14 +66,51 @@ typedef struct at91_port {
u32 puer; /* 0x64 Pull-up Enable Register */
u32 pusr; /* 0x68 Pad Pull-up Status Register */
u32 reserved4;
+#if defined(ATMEL_CPU_HAS_PIO3)
+ u32 abcdsr1;/* 0x70 Peripheral ABCD Select Register 1 */
+ u32 abcdsr2;/* 0x74 Peripheral ABCD Select Register 2 */
+ u32 reserved5[2];
+ u32 ifscdr; /* 0x80 Input Filter SCLK Disable Register */
+ u32 ifscer; /* 0x84 Input Filter SCLK Enable Register */
+ u32 ifscsr; /* 0x88 Input Filter SCLK Status Register */
+ u32 scdr; /* 0x8C SCLK Divider Debouncing Register */
+#define PIO_SCDR_DIV_MASK (0x3fff 0) /* Slow Clock Divider Mask */
+ u32 ppddr; /* 0x90 Pad Pull-down Disable Register */
+ u32 ppder; /* 0x94 Pad Pull-down Enable Register */
+ u32 ppdsr; /* 0x98 Pad Pull-down Status Register */
+ u32 reserved6;
+#else
u32 asr;/* 0x70 Select A Register */
u32 bsr;/* 0x74 Select B Register */
u32 absr; /* 0x78 AB Select Status Register */
u32 reserved5[9]; /* */
+#endif
u32 ower; /* 0xA0 Output Write Enable Register */
u32 owdr; /* 0xA4 Output Write Disable Register */
- u32 owsr; /* OxA8 utput Write Status Register */
+ u32 owsr; /* OxA8 Output Write Status Register */
+#if defined(ATMEL_CPU_HAS_PIO3)
+ u32 reserved7; /* */
+ u32 aimer; /* Additional Interrupt Modes Enable Register*/
+ u32 aimdr; /* Additional Interrupt Modes Disable Register*/
+ u32 aimmr; /* Additional Intterupt Modes Mask Register */
+ u32 reserved8; /* */
+ u32 esr;/* 0xC0 Edge Select Register */
+ u32 lsr;/* 0xC4 Level Select Register */
+ u32 elsr; /* 0xC8 Edge/Level Status Register */
+ u32 reserved9; /* 0xCC */
+ u32 fellsr; /* 0xD0 Falling Edge/Low Level Select Register*/
+ u32 rehlsr; /* 0xD4 Rising Edge/High Level Select Register*/
+ u32 frlhsr; /* 0xD8 Fall/Rise - Low/High Status Register */
+ u32 reserved10; /* */
+ u32 locksr; /* 0xE0 Lock Status */
+ u32 wpmr; /* 0xE4 Write Protect Mode Register */
+ u32 wpsr; /* 0xE4 Write Protect Status Register */
+ u32 reserved11[5]; /* */
+ u32 schmitt;/* 0x100 Schmitt Trigger Register */
+ u32 reserved12[63];
+#else
u32 reserved6[85];
+#endif
} at91_port_t;
typedef union at91_pio {
@@ -94,6 +131,13 @@ typedef union at91_pio {
#ifdef CONFIG_AT91_GPIO
int at91_set_a_periph(unsigned port, unsigned pin, int use_pullup);
int at91_set_b_periph(unsigned port, unsigned pin, int use_pullup);
+#if defined(ATMEL_CPU_HAS_PIO3)
+int at91_set_c_periph(unsigned port, unsigned pin, int use_pullup);
+int at91_set_d_periph(unsigned port, unsigned pin, int use_pullup);
+int at91_set_pio_debounce(unsigned port, unsigned pin, int is_on, int div);
+int at91_set_pio_pulldown(unsigned port, unsigned pin, int is_on);
+int at91_set_pio_disable_schmitt_trig(unsigned port, unsigned pin);
+#endif
int at91_set_pio_input(unsigned port, unsigned pin, int use_pullup);
int at91_set_pio_multi_drive(unsigned port, unsigned pin, int is_on);
int at91_set_pio_output(unsigned port, unsigned pin, int
[U-Boot] [PATCH] integrator: rewrite the AP PCI driver
The PCI support for the Integrator AP has apparently never
been finished and I strongly suspect that it has never worked,
so let's fix it. This is a list of the more or less
un-splittable changes done in this driver rewrite:
- Replace the register definitions stashed into the config
file (!) with a copy if the register file from the Linux
kernels arch/arm/include/asm/hardware/pci_v3.h
- Delete the unreadable gigantic macros that perform the
config accesses and replace them with copyedited code from
Linux arch/arm/mach-integrator/pci_v3.c
- Rewrite the rest of the setup code to use the
v3_[read|write][lwb]() accessors.
- Enable PCI by default in the AP board configuration.
- Fix checkpatch warnings and make code more conformant.
Tested-by: Will Deacon will.dea...@arm.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
board/armltd/integrator/pci.c| 582 ++
board/armltd/integrator/pci_v3.h | 200 +
include/configs/integratorap.h | 148 +-
3 files changed, 538 insertions(+), 392 deletions(-)
create mode 100644 board/armltd/integrator/pci_v3.h
diff --git a/board/armltd/integrator/pci.c b/board/armltd/integrator/pci.c
index 6ee2a85..f040450 100644
--- a/board/armltd/integrator/pci.c
+++ b/board/armltd/integrator/pci.c
@@ -14,6 +14,10 @@
* ARM Ltd.
* Philippe Robin, philippe.ro...@arm.com
*
+ * (C) Copyright 2011
+ * Linaro
+ * Linus Walleij linus.wall...@linaro.org
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -32,15 +36,53 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
-
#include common.h
#include pci.h
+#include asm/io.h
+#include integrator-sc.h
+#include pci_v3.h
+
+#define INTEGRATOR_BOOT_ROM_BASE 0x2000
+#define INTEGRATOR_HDR0_SDRAM_BASE 0x8000
+
+/*
+ * These are in the physical addresses on the CPU side, i.e.
+ * where we read and write stuff - you don't want to try to
+ * move these around
+ */
+#define PHYS_PCI_MEM_BASE 0x4000
+#define PHYS_PCI_IO_BASE 0x6000 /* PCI I/O space base */
+#define PHYS_PCI_CONFIG_BASE 0x6100
+#define PHYS_PCI_V3_BASE 0x6200 /* V360EPC registers */
+#define SZ_256M0x1000
+
+/*
+ * These are in the PCI BUS address space
+ * Set to 0x in the Linux kernel, 0x4000 in Boot monitor
+ * we follow the example of the kernel, because that is the address
+ * range that devices actually use - what would they be doing at
+ * 0x4000?
+ */
+#define PCI_BUS_NONMEM_START 0x
+#define PCI_BUS_NONMEM_SIZESZ_256M
+
+#define PCI_BUS_PREMEM_START (PCI_BUS_NONMEM_START + PCI_BUS_NONMEM_SIZE)
+#define PCI_BUS_PREMEM_SIZESZ_256M
+
+#if PCI_BUS_NONMEM_START 0x000f
+#error PCI_BUS_NONMEM_START must be megabyte aligned
+#endif
+#if PCI_BUS_PREMEM_START 0x000f
+#error PCI_BUS_PREMEM_START must be megabyte aligned
+#endif
/*
* Initialize PCI Devices, report devices found.
*/
#ifndef CONFIG_PCI_PNP
+#define PCI_ENET0_IOADDR 0x6000 /* First card in PCI I/O space */
+#define PCI_ENET0_MEMADDR 0x4000 /* First card in PCI memory space */
static struct pci_config_table pci_integrator_config_table[] = {
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0x0f, PCI_ANY_ID,
pci_cfgfunc_config_device, { PCI_ENET0_IOADDR,
@@ -51,163 +93,187 @@ static struct pci_config_table
pci_integrator_config_table[] = {
#endif /* CONFIG_PCI_PNP */
/* V3 access routines */
-#define _V3Write16(o,v) (*(volatile unsigned short *)(PCI_V3_BASE + (unsigned
int)(o)) = (unsigned short)(v))
-#define _V3Read16(o) (*(volatile unsigned short *)(PCI_V3_BASE + (unsigned
int)(o)))
-
-#define _V3Write32(o,v) (*(volatile unsigned int *)(PCI_V3_BASE + (unsigned
int)(o)) = (unsigned int)(v))
-#define _V3Read32(o) (*(volatile unsigned int *)(PCI_V3_BASE + (unsigned
int)(o)))
-
-/* Compute address necessary to access PCI config space for the given */
-/* bus and device. */
-#define PCI_CONFIG_ADDRESS( __bus, __devfn, __offset ) ({
\
- unsigned int __address, __devicebit;
\
- unsigned short __mapaddress;
\
- unsigned int __dev = PCI_DEV (__devfn); /* FIXME to check!! (slot?) */
\
-
\
- if (__bus == 0) {
\
- /* local bus segment so need a type 0 config cycle */
\
- /* build the PCI configuration address with one-hot in
A31-A11 */ \
- __address = PCI_CONFIG_BASE;
\
- __address |= ((__devfn 0x07) 8);
\
-
[U-Boot] Can u-Boot Ran from RAM?
Hi there, While getting acquainted with possible u-Boot development issues, I read FAQ 14.2.1. Can U-Boot be configured such that it can be started in RAM? and was puzzled to learn that u-Boot cannot run from RAM. Considering a custom platform, using i.MX536, I understand that the i.MX53x processor has its own ROM-based code that performs boot time essential devices initialisation, etc. In the case when NAND flash is the program-image medium at the boot stage, first, the ROM-based code checks for Discovered Bad Blocks Table (DBBT) presence and searches for valid Firmware Configuration Block (FCB) on external NAND Flash. If FCB is found that points to the NAND Flash page(s) that contain the first 4K of initial firmware to be loaded from NAND Flash. Then, it loads the 4K of data, pointed by FCB, into the NFC RAM buffer. These data contain a valid Image Vector Table (IVT). Then, the ROM-based code processes IVT, executes the Device Configuration Data (DCD) sequences to initialize boot-related integrated peripherals (typically, these are IOMUX, SDRAM controller and boot memory controller), then copies the application code, also contained in IVT, to target memory (typically, SDRAM) and jumps to it. Typically, this application code is the custom primary bootloader that completes loading the application code (e.g. main OS bootloader) and passes the control to it. If FCB is not found the ROM-based code starts executing a download protocol over UART or USB port in an attempt to get a valid IVT from a host. If the IVT is eventually obtained it is processed as before. So the question is can this custom primary bootloader role, in fact, be played by u-Boot. Reading your text of FAQ 14.2.1., it seems to me that it cannot. On the other hand I know of some Freescale i.MX53x demo boards (e.g. ARD, LOCO) that use u-Boot. I wonder what I'm missing here. Regards, Bud ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] mxc_spi refactoring (for mx6q and mx6qsabrelite)
Eric, 2012/1/31 Eric Nelson eric.nel...@boundarydevices.com: This patch set refactors mxc_spi as described in http://lists.denx.de/pipermail/u-boot/2010-March/068791.html and requested in http://lists.denx.de/pipermail/u-boot/2012-January/116023.html in order to add support for the MX6Q in general and the mx6qsabrelite specifically. If this patch-set is re-send, please specify version Vx and change-log. Thanks, Patch 1 simply moves the conditional parts of mxc_spi.c into the respective CPU-specific imx-regs.h files. Patch 2 adds general support for SPI to the i.MX6. I can't find the patch 2/3 in my email system, miss it? Patch 3 adds support to the mx6qsabrelite board ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] mxc_spi refactoring (for mx6q and mx6qsabrelite)
On Tue, Jan 31, 2012 at 2:51 PM, Jason Liu liu.h.ja...@gmail.com wrote: Eric, 2012/1/31 Eric Nelson eric.nel...@boundarydevices.com: This patch set refactors mxc_spi as described in http://lists.denx.de/pipermail/u-boot/2010-March/068791.html and requested in http://lists.denx.de/pipermail/u-boot/2012-January/116023.html in order to add support for the MX6Q in general and the mx6qsabrelite specifically. If this patch-set is re-send, please specify version Vx and change-log. Thanks, Patch 1 simply moves the conditional parts of mxc_spi.c into the respective CPU-specific imx-regs.h files. Patch 2 adds general support for SPI to the i.MX6. I can't find the patch 2/3 in my email system, miss it? sorry, Ignore it. The email system get messed. Patch 3 adds support to the mx6qsabrelite board ___ 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
