Re: [U-Boot] [PATCH v3 03/11] net: add Faraday FTMAC110 10/100Mbps ethernet support
2013/5/3 Tom Rini tr...@ti.com:
On Fri, Apr 26, 2013 at 04:02:32PM +0800, Kuo-Jung Su wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
[snip]
+ | (phyaddr PHYCR_ADDR_SHIFT)
+ | (phyreg PHYCR_REG_SHIFT)
+ | 0x3000;
Magic number.
It's the HW debug function, it would be removed at next version.
+
+ writel(tmp, regs-phycr);
+
+ for (ts = get_timer(0); get_timer(ts) 1000; ) {
Please define a TIMEOUT and use that insteadof 1000 all the time.
Got it, thanks
[snip]
+ /* interrupt at every packet transmit/receive */
+ writel(0x1010, regs-itc);
+ /* tx/rx poll interval=5.12us; rx_poll_cnt=1 */
+ writel(0x0001, regs-aptc);
+ /* rx fifo: high=1536, low=512 */
+ writel(0x0390, regs-dblac);
+ /* clear all interrupt status */
+ writel(0x03FF, regs-isr);
More magic numbers. Please fix globally. Thanks!
Got it, thanks
--
Tom
--
Best wishes,
Kuo-Jung Su
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/11] arm: add Faraday A36x SoC platform support
2013/5/3 Tom Rini tr...@ti.com:
On Fri, Apr 26, 2013 at 04:02:29PM +0800, Kuo-Jung Su wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
To: u-boot@lists.denx.de
CC: Albert Aribaud albert.u.b...@aribaud.net
These patches introduce Faraday A36x SoC platform support.
Here are some public documents for your reference.
http://www.faraday-tech.com/html/documentation/index.html
There is also a A369 QEMU emulator available at my github account:
https://github.com/dantesu1218/qemu.git
Here is quick start for QEMU:
1. Download the QEMU source tree
$ git clone -b qemu-1.3.0 https://github.com/dantesu1218/qemu.git
2. Build Install the QEMU:
$ ./configure --target-list=arm-softmmu
$ make
$ make install
3. Launch u-boot with QEMU:
$ qemu-system-arm -M a369 -m 512M -nographic -kernel
~/u-boot-devel/u-boot
Changes for v3:
- Coding Style cleanup.
There is still one warnning reported by checkpatch.pl,
however it's too deep for me to fix it.
Here is the shapshot for it:
-
WARNING: do not add new typedefs
#9735: FILE: include/lcd.h:258:
+typedef struct vidinfo {
-
- Drop bit fields from c struct.
- Drop macros for wirtel()/readl(), call them directly.
- Always insert a blank line between declarations and code.
- Replace all the infinite wait loop with a timeout.
- Add '__iomem' to all the declaration of HW register pointers.
- cmd_boot.c: Make it a separate stand-alone patch.
- ftspi020: Make it a separate stand-alone patch.
- dma-mapping.h: Have the global data ptr declared outside functions.
- dma-mapping.h: Add #if...#else...#endif to dma_free_coherent().
- MMU/D-Cache: Drop static non-cached region, now we use
map_physmem()/unmap_physmem() for dynamic mappings.
- ftmac110: Make a correction to multi-line comment style
- ftmac110: Use random MAC address while having trouble
to get one from environment variables.
- ftmac110: Add comments to timing control registers.
- ftnandc021: Re-write this driver with ECC enabled and
correct column address handling for OOB read/write,
and fixing issused addressed by Scott.
- a36x_config: No more static global network configurations.
- a36x_config: Add a common file for the redundant configurations.
I see a few:
/*
* Comment
*/
It's used in ftssp010_spi.c only, and it would be removed later.
in various places, and I pointed it out in the net changes, but I also
saw in the SPI block '100' being used as a timeout, rather than defined.
Please give everything a check for magic numbers and direct numbers used
as timeout, rather than a #define.
Got it, thanks
--
Tom
--
Best wishes,
Kuo-Jung Su
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] gpio: Add support for microblaze xilinx GPIO
Microblaze uses gpio which is connected to the system reset.
Currently gpio subsystem wasn't used for it.
Add gpio driver and change Microblaze reset logic to be done
via gpio subsystem.
There are various configurations which Microblaze can have
that's why gpio_alloc/gpio_alloc_dual(for dual channel)
function has been introduced and gpio can be allocated
dynamically.
Adding several gpios IP is also possible and supported.
For listing gpio configuration please use gpio status command
This patch also remove one compilation warning:
microblaze-generic.c: In function 'do_reset':
microblaze-generic.c:38:47: warning: operation on '*1073741824u'
may be undefined [-Wsequence-point]
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v2:
- Use asm-generic/gpio.h file
- Add gpio_set_value()
- Check return value from gpio_get_controller
GPIO support for Microblaze
I want to also write gpio support for Zynq
and this driver should be also used for arm zynq.
Currently we have support just for only gpio controller
but not for various of them.
That's why I would like to get some input from you
if possible to add dynamic gpio allocation which
could be also helpful for OF support.
Output from my gpio status on Microblaze is below.
Thanks,
Michal
U-Boot gpio status
gpio_info: reset/4000 (0-0)
GPIO_0: reset_pin is an INPUT value = 0
gpio_info: led/4004 (1-5)
GPIO_1: UNKNOWN is an INPUT value = 0
GPIO_2: UNKNOWN is an OUTPUT value = 1
GPIO_3: UNKNOWN is an INPUT value = 0
GPIO_4: UNKNOWN is an INPUT value = 0
GPIO_5: UNKNOWN is an OUTPUT value = 0
---
arch/microblaze/include/asm/gpio.h | 40 +--
.../xilinx/microblaze-generic/microblaze-generic.c | 17 +-
drivers/gpio/Makefile | 1 +
drivers/gpio/xilinx_gpio.c | 364 +
include/configs/microblaze-generic.h | 3 +-
5 files changed, 386 insertions(+), 39 deletions(-)
create mode 100644 drivers/gpio/xilinx_gpio.c
diff --git a/arch/microblaze/include/asm/gpio.h
b/arch/microblaze/include/asm/gpio.h
index 883f4d4..f5cad56 100644
--- a/arch/microblaze/include/asm/gpio.h
+++ b/arch/microblaze/include/asm/gpio.h
@@ -1,41 +1,15 @@
#ifndef _ASM_MICROBLAZE_GPIO_H_
#define _ASM_MICROBLAZE_GPIO_H_
-#include asm/io.h
+#include asm-generic/gpio.h
-static inline int gpio_request(unsigned gpio, const char *label)
-{
- return 0;
-}
+/* Allocation functions */
+extern int gpio_alloc_dual(u32 baseaddr, const char *name, u32 gpio_no0,
+ u32 gpio_no1);
+extern int gpio_alloc(u32 baseaddr, const char *name, u32 gpio_no);
-static inline int gpio_free(unsigned gpio)
-{
- return 0;
-}
+#define gpio_status() gpio_info()
+extern void gpio_info(void);
-static inline int gpio_direction_input(unsigned gpio)
-{
- return 0;
-}
-
-static inline int gpio_direction_output(unsigned gpio, int value)
-{
- return 0;
-}
-
-static inline int gpio_get_value(unsigned gpio)
-{
- return 0;
-}
-
-static inline int gpio_set_value(unsigned gpio, int value)
-{
- return 0;
-}
-
-static inline int gpio_is_valid(int number)
-{
- return 0;
-}
#endif
diff --git a/board/xilinx/microblaze-generic/microblaze-generic.c
b/board/xilinx/microblaze-generic/microblaze-generic.c
index befbb3a..2f5f20e 100644
--- a/board/xilinx/microblaze-generic/microblaze-generic.c
+++ b/board/xilinx/microblaze-generic/microblaze-generic.c
@@ -31,12 +31,17 @@
#include asm/processor.h
#include asm/microblaze_intc.h
#include asm/asm.h
+#include asm/gpio.h
+
+#ifdef CONFIG_XILINX_GPIO
+static int reset_pin = -1;
+#endif
int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
-#ifdef CONFIG_SYS_GPIO_0
- *((unsigned long *)(CONFIG_SYS_GPIO_0_ADDR)) =
- ++(*((unsigned long *)(CONFIG_SYS_GPIO_0_ADDR)));
+#ifdef CONFIG_XILINX_GPIO
+ if (reset_pin != -1)
+ gpio_direction_output(reset_pin, 1);
#endif
#ifdef CONFIG_XILINX_TB_WATCHDOG
@@ -52,8 +57,10 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
int gpio_init (void)
{
-#ifdef CONFIG_SYS_GPIO_0
- *((unsigned long *)(CONFIG_SYS_GPIO_0_ADDR)) = 0x;
+#ifdef CONFIG_XILINX_GPIO
+ reset_pin = gpio_alloc(CONFIG_SYS_GPIO_0_ADDR, reset, 1);
+ if (reset_pin != -1)
+ gpio_request(reset_pin, reset_pin);
#endif
return 0;
}
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 9df1e26..830e8e6 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -47,6 +47,7 @@ COBJS-$(CONFIG_OMAP_GPIO) += omap_gpio.o
COBJS-$(CONFIG_DB8500_GPIO)+= db8500_gpio.o
COBJS-$(CONFIG_BCM2835_GPIO) += bcm2835_gpio.o
COBJS-$(CONFIG_S3C2440_GPIO) += s3c2440_gpio.o
+COBJS-$(CONFIG_XILINX_GPIO)+= xilinx_gpio.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
new file mode 100644
index
[U-Boot] [PATCH v3 0/9] FPGA cleanup + zynq support
Fpga code is pretty old and none has tried to clean it up.
My attempt is related to new code I want to push to mainline
which is add support for checking bitstream and if bitstream
is valid for the selected device.
For this I need to do cleanup code and move code
from cmd_fpga.c to fpga.c in driver folder.
Zynq driver:
Depends on previous zynq patches sent some days ago.
Tested by:
set fload tftp \${addr} fpga.bin\;fpga info 0\;fpga load 0 \${addr} \${filesize}
set floadb tftp \${addr} download.bit\;fpga info 0\;fpga loadb 0 \${addr}
\${filesize}
set addr 1000
run fload
run floadb
set addr 1001
run fload
run floadb
set addr 1002
run fload
run floadb
set addr 1003
run fload
run floadb
Thanks for your comments,
Michal
Changes in v3:
- Setup fpga_loadbitstream as weak function
- New patch in this series
- Rebase because of change in previous patch
- fpga_validate should be global function
- fix one printf function
- change parameter name according to previous patch dev-devnum
- New patch in this series
Changes in v2:
- Fix compilation warnings
- Fix grammer in the commit message
- Fix bugs reported by Tom Rini
- Fix checkpatch warnings (fpga)
- Fix comments (fpga)
- Do not use CamelCase for XilinxZynq (fpga)
- Move to fpga series and extend this driver
- New patch in this series
Michal Simek (9):
fpga: Clean coding style
fpga: Fix debug message compilation error
cmd: fpga: Clean coding style
cmd: fpga: Move fpga_loadbitstream to fpga.c
fpga: Change the first parameter in fpga_loadbitstream
cmd: fpga: Do not include net.h
fpga: zynq: Add support for loading bitstream
fpga: Check device name against bitstream name
fpga: Remove all CONFIG_SYS_* fpga related options
arch/arm/cpu/armv7/zynq/slcr.c | 35 +++
arch/arm/include/asm/arch-zynq/hardware.h | 10 +-
arch/arm/include/asm/arch-zynq/sys_proto.h | 3 +
board/xilinx/zynq/board.c | 37 +++
common/cmd_fpga.c | 254 +++--
drivers/fpga/Makefile | 1 +
drivers/fpga/fpga.c| 225 +-
drivers/fpga/xilinx.c | 146
drivers/fpga/zynqpl.c | 355 +
include/altera.h | 17 --
include/configs/M54455EVB.h| 2 +-
include/configs/MERGERBOX.h| 2 +-
include/configs/MVBC_P.h | 2 +-
include/configs/MVBLM7.h | 2 +-
include/configs/MVSMR.h| 2 +-
include/configs/omap3_mvblx.h | 2 +-
include/configs/zynq.h | 6 +
include/fpga.h | 13 +-
include/lattice.h | 3 -
include/xilinx.h | 25 +-
include/zynqpl.h | 59 +
21 files changed, 848 insertions(+), 353 deletions(-)
create mode 100644 drivers/fpga/zynqpl.c
create mode 100644 include/zynqpl.h
--
1.8.2.1
pgp7I5fLp0Nfb.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/9] fpga: Clean coding style
No functional changes.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v3: None
Changes in v2:
- Fix compilation warnings
drivers/fpga/fpga.c | 216
1 file changed, 98 insertions(+), 118 deletions(-)
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 26d2443..ddebd49 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -22,122 +22,99 @@
*
*/
-/*
- * Generic FPGA support
- */
+/* Generic FPGA support */
#include common.h /* core U-Boot definitions */
#include xilinx.h /* xilinx specific definitions */
#include altera.h /* altera specific definitions */
#include lattice.h
-#if 0
-#define FPGA_DEBUG /* define FPGA_DEBUG to get debug messages */
-#endif
-
/* Local definitions */
#ifndef CONFIG_MAX_FPGA_DEVICES
#define CONFIG_MAX_FPGA_DEVICES5
#endif
-/* Enable/Disable debug console messages */
-#ifdef FPGA_DEBUG
-#definePRINTF(fmt,args...) printf (fmt ,##args)
-#else
-#definePRINTF(fmt,args...)
-#endif
-
/* Local static data */
static int next_desc = FPGA_INVALID_DEVICE;
static fpga_desc desc_table[CONFIG_MAX_FPGA_DEVICES];
-/* Local static functions */
-static __attribute__((__const__)) fpga_desc * __attribute__((__const__))
fpga_get_desc( int devnum );
-static __attribute__((__const__)) fpga_desc * __attribute__((__const__))
fpga_validate(int devnum, const void *buf,
-size_t bsize, char *fn );
-static int fpga_dev_info( int devnum );
-
-
-/* - */
-
-/* fpga_no_sup
+/*
+ * fpga_no_sup
* 'no support' message function
*/
-static void fpga_no_sup( char *fn, char *msg )
+static void fpga_no_sup(char *fn, char *msg)
{
- if ( fn msg ) {
- printf( %s: No support for %s.\n, fn, msg);
- } else if ( msg ) {
- printf( No support for %s.\n, msg);
- } else {
- printf( No FPGA suport!\n);
- }
+ if (fn msg)
+ printf(%s: No support for %s.\n, fn, msg);
+ else if (msg)
+ printf(No support for %s.\n, msg);
+ else
+ printf(No FPGA suport!\n);
}
/* fpga_get_desc
* map a device number to a descriptor
*/
-static __attribute__((__const__)) fpga_desc * __attribute__((__const__))
fpga_get_desc( int devnum )
+static const fpga_desc *const fpga_get_desc(int devnum)
{
- fpga_desc *desc = (fpga_desc * )NULL;
+ fpga_desc *desc = (fpga_desc *)NULL;
- if (( devnum = 0 ) (devnum next_desc )) {
+ if ((devnum = 0) (devnum next_desc)) {
desc = desc_table[devnum];
- PRINTF( %s: found fpga descriptor #%d @ 0x%p\n,
- __FUNCTION__, devnum, desc );
+ debug(%s: found fpga descriptor #%d @ 0x%p\n,
+ __func__, devnum, desc);
}
return desc;
}
-
-/* fpga_validate
+/*
+ * fpga_validate
* generic parameter checking code
*/
-static __attribute__((__const__)) fpga_desc * __attribute__((__const__))
fpga_validate(int devnum, const void *buf,
-size_t bsize, char *fn )
+static const fpga_desc *const fpga_validate(int devnum, const void *buf,
+size_t bsize, char *fn)
{
- fpga_desc * desc = fpga_get_desc( devnum );
+ const fpga_desc *desc = fpga_get_desc(devnum);
- if ( !desc ) {
- printf( %s: Invalid device number %d\n, fn, devnum );
- }
+ if (!desc)
+ printf(%s: Invalid device number %d\n, fn, devnum);
- if ( !buf ) {
- printf( %s: Null buffer.\n, fn );
+ if (!buf) {
+ printf(%s: Null buffer.\n, fn);
return (fpga_desc * const)NULL;
}
return desc;
}
-
-/* fpga_dev_info
+/*
+ * fpga_dev_info
* generic multiplexing code
*/
-static int fpga_dev_info( int devnum )
+static int fpga_dev_info(int devnum)
{
- int ret_val = FPGA_FAIL; /* assume failure */
- const fpga_desc * const desc = fpga_get_desc( devnum );
+ int ret_val = FPGA_FAIL; /* assume failure */
+ const fpga_desc * const desc = fpga_get_desc(devnum);
- if ( desc ) {
- PRINTF( %s: Device Descriptor @ 0x%p\n,
- __FUNCTION__, desc-devdesc );
+ if (desc) {
+ debug(%s: Device Descriptor @ 0x%p\n,
+ __func__, desc-devdesc);
- switch ( desc-devtype ) {
+ switch (desc-devtype) {
case fpga_xilinx:
#if defined(CONFIG_FPGA_XILINX)
- printf( Xilinx Device\nDescriptor @ 0x%p\n, desc );
- ret_val = xilinx_info( desc-devdesc );
+ printf(Xilinx Device\nDescriptor @
[U-Boot] [PATCH v3 2/9] fpga: Fix debug message compilation error
CONFIG_FPGA in past was a bitfield where bits were use for vendor identification. This fix should be the part of this commit: Improve configuration of FPGA subsystem (sha1: 0133502e39ff89b67c26cb4015e0e7e8d9571184) Signed-off-by: Michal Simek michal.si...@xilinx.com --- Changes in v3: None Changes in v2: - Fix grammer in the commit message drivers/fpga/fpga.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c index ddebd49..43bdf4f 100644 --- a/drivers/fpga/fpga.c +++ b/drivers/fpga/fpga.c @@ -145,7 +145,7 @@ void fpga_init(void) next_desc = 0; memset(desc_table, 0, sizeof(desc_table)); - debug(%s: CONFIG_FPGA = 0x%x\n, __func__, CONFIG_FPGA); + debug(%s\n, __func__); } /* -- 1.8.2.1 pgpK3qmqqokDg.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 6/9] cmd: fpga: Do not include net.h
There is no reason to include net.h header in fpga code. Signed-off-by: Michal Simek michal.si...@xilinx.com --- Changes in v3: None Changes in v2: None common/cmd_fpga.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/common/cmd_fpga.c b/common/cmd_fpga.c index aa14ceb..5e1d037 100644 --- a/common/cmd_fpga.c +++ b/common/cmd_fpga.c @@ -27,9 +27,6 @@ */ #include common.h #include command.h -#if defined(CONFIG_CMD_NET) -#include net.h -#endif #include fpga.h #include malloc.h -- 1.8.2.1 pgpQsWFeI5g4S.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/9] cmd: fpga: Clean coding style
No functional changes.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v3: None
Changes in v2: None
I had to shorten some debug messages and divide them
to two parts to pass checkpatch.
---
common/cmd_fpga.c | 213 +++---
1 file changed, 107 insertions(+), 106 deletions(-)
diff --git a/common/cmd_fpga.c b/common/cmd_fpga.c
index 1834246..f3579bb 100644
--- a/common/cmd_fpga.c
+++ b/common/cmd_fpga.c
@@ -34,7 +34,7 @@
#include malloc.h
/* Local functions */
-static int fpga_get_op (char *opstr);
+static int fpga_get_op(char *opstr);
/* Local defines */
#define FPGA_NONE -1
@@ -45,7 +45,7 @@ static int fpga_get_op (char *opstr);
#define FPGA_LOADMK 4
/* Convert bitstream data and load into the fpga */
-int fpga_loadbitstream(unsigned long dev, char* fpgadata, size_t size)
+int fpga_loadbitstream(unsigned long dev, char *fpgadata, size_t size)
{
#if defined(CONFIG_FPGA_XILINX)
unsigned int length;
@@ -58,38 +58,36 @@ int fpga_loadbitstream(unsigned long dev, char* fpgadata,
size_t size)
dataptr = (unsigned char *)fpgadata;
/* skip the first bytes of the bitsteam, their meaning is unknown */
- length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
- dataptr+=length;
+ length = (*dataptr 8) + *(dataptr + 1);
+ dataptr += 2;
+ dataptr += length;
/* get design name (identifier, length, string) */
- length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
+ length = (*dataptr 8) + *(dataptr + 1);
+ dataptr += 2;
if (*dataptr++ != 0x61) {
- debug(%s: Design name identifier not recognized
- in bitstream\n,
- __func__);
+ debug(%s: Design name id not recognized in bitstream\n,
+ __func__);
return FPGA_FAIL;
}
- length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
- for(i=0;ilength;i++)
+ length = (*dataptr 8) + *(dataptr + 1);
+ dataptr += 2;
+ for (i = 0; i length; i++)
buffer[i] = *dataptr++;
printf( design filename = \%s\\n, buffer);
/* get part number (identifier, length, string) */
if (*dataptr++ != 0x62) {
- printf(%s: Part number identifier not recognized
- in bitstream\n,
- __func__);
+ printf(%s: Part number id not recognized in bitstream\n,
+ __func__);
return FPGA_FAIL;
}
- length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
- for(i=0;ilength;i++)
+ length = (*dataptr 8) + *(dataptr + 1);
+ dataptr += 2;
+ for (i = 0; i length; i++)
buffer[i] = *dataptr++;
printf( part number = \%s\\n, buffer);
@@ -101,35 +99,35 @@ int fpga_loadbitstream(unsigned long dev, char* fpgadata,
size_t size)
}
length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
- for(i=0;ilength;i++)
+ dataptr += 2;
+ for (i = 0; i length; i++)
buffer[i] = *dataptr++;
printf( date = \%s\\n, buffer);
/* get time (identifier, length, string) */
if (*dataptr++ != 0x64) {
printf(%s: Time identifier not recognized in bitstream\n,
- __func__);
+ __func__);
return FPGA_FAIL;
}
length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
- for(i=0;ilength;i++)
+ dataptr += 2;
+ for (i = 0; i length; i++)
buffer[i] = *dataptr++;
printf( time = \%s\\n, buffer);
/* get fpga data length (identifier, length) */
if (*dataptr++ != 0x65) {
- printf(%s: Data length identifier not recognized in
bitstream\n,
- __func__);
+ printf(%s: Data length id not recognized in bitstream\n,
+ __func__);
return FPGA_FAIL;
}
- swapsize = ((unsigned int) *dataptr 24) +
- ((unsigned int) *(dataptr+1) 16) +
- ((unsigned int) *(dataptr+2) 8 ) +
- ((unsigned int) *(dataptr+3) ) ;
- dataptr+=4;
+ swapsize = ((unsigned int) *dataptr 24) +
+ ((unsigned int) *(dataptr + 1) 16) +
+ ((unsigned int) *(dataptr + 2) 8) +
+ ((unsigned int) *(dataptr + 3));
+ dataptr += 4;
printf( bytes in bitstream = %d\n, swapsize);
rc = fpga_load(dev, dataptr, swapsize);
@@ -148,81 +146,81 @@ int fpga_loadbitstream(unsigned long dev, char* fpgadata,
size_t size)
* If there is no data addr field, the fpgadata environment variable is used.
* The info command requires no data address field.
*/
-int do_fpga (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
[U-Boot] [PATCH v3 4/9] cmd: fpga: Move fpga_loadbitstream to fpga.c
In bitstream decoding you can directly check device
which you want to load and in fpga.c are fpga_validate
and fpga_dev_info functions which should be used for it.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v3:
- Setup fpga_loadbitstream as weak function
Changes in v2: None
common/cmd_fpga.c | 94 ---
drivers/fpga/fpga.c | 9 +
drivers/fpga/xilinx.c | 86 ++
include/fpga.h| 1 +
4 files changed, 96 insertions(+), 94 deletions(-)
diff --git a/common/cmd_fpga.c b/common/cmd_fpga.c
index f3579bb..aa14ceb 100644
--- a/common/cmd_fpga.c
+++ b/common/cmd_fpga.c
@@ -44,100 +44,6 @@ static int fpga_get_op(char *opstr);
#define FPGA_DUMP 3
#define FPGA_LOADMK 4
-/* Convert bitstream data and load into the fpga */
-int fpga_loadbitstream(unsigned long dev, char *fpgadata, size_t size)
-{
-#if defined(CONFIG_FPGA_XILINX)
- unsigned int length;
- unsigned int swapsize;
- char buffer[80];
- unsigned char *dataptr;
- unsigned int i;
- int rc;
-
- dataptr = (unsigned char *)fpgadata;
-
- /* skip the first bytes of the bitsteam, their meaning is unknown */
- length = (*dataptr 8) + *(dataptr + 1);
- dataptr += 2;
- dataptr += length;
-
- /* get design name (identifier, length, string) */
- length = (*dataptr 8) + *(dataptr + 1);
- dataptr += 2;
- if (*dataptr++ != 0x61) {
- debug(%s: Design name id not recognized in bitstream\n,
- __func__);
- return FPGA_FAIL;
- }
-
- length = (*dataptr 8) + *(dataptr + 1);
- dataptr += 2;
- for (i = 0; i length; i++)
- buffer[i] = *dataptr++;
-
- printf( design filename = \%s\\n, buffer);
-
- /* get part number (identifier, length, string) */
- if (*dataptr++ != 0x62) {
- printf(%s: Part number id not recognized in bitstream\n,
- __func__);
- return FPGA_FAIL;
- }
-
- length = (*dataptr 8) + *(dataptr + 1);
- dataptr += 2;
- for (i = 0; i length; i++)
- buffer[i] = *dataptr++;
- printf( part number = \%s\\n, buffer);
-
- /* get date (identifier, length, string) */
- if (*dataptr++ != 0x63) {
- printf(%s: Date identifier not recognized in bitstream\n,
- __func__);
- return FPGA_FAIL;
- }
-
- length = (*dataptr 8) + *(dataptr+1);
- dataptr += 2;
- for (i = 0; i length; i++)
- buffer[i] = *dataptr++;
- printf( date = \%s\\n, buffer);
-
- /* get time (identifier, length, string) */
- if (*dataptr++ != 0x64) {
- printf(%s: Time identifier not recognized in bitstream\n,
- __func__);
- return FPGA_FAIL;
- }
-
- length = (*dataptr 8) + *(dataptr+1);
- dataptr += 2;
- for (i = 0; i length; i++)
- buffer[i] = *dataptr++;
- printf( time = \%s\\n, buffer);
-
- /* get fpga data length (identifier, length) */
- if (*dataptr++ != 0x65) {
- printf(%s: Data length id not recognized in bitstream\n,
- __func__);
- return FPGA_FAIL;
- }
- swapsize = ((unsigned int) *dataptr 24) +
- ((unsigned int) *(dataptr + 1) 16) +
- ((unsigned int) *(dataptr + 2) 8) +
- ((unsigned int) *(dataptr + 3));
- dataptr += 4;
- printf( bytes in bitstream = %d\n, swapsize);
-
- rc = fpga_load(dev, dataptr, swapsize);
- return rc;
-#else
- printf(Bitstream support only for Xilinx devices\n);
- return FPGA_FAIL;
-#endif
-}
-
/* - */
/* command form:
* fpga op device number data addr datasize
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 43bdf4f..f0253bf 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -188,6 +188,15 @@ int fpga_add(fpga_type devtype, void *desc)
}
/*
+ * Convert bitstream data and load into the fpga
+ */
+int __weak fpga_loadbitstream(unsigned long dev, char *fpgadata, size_t size)
+{
+ printf(Bitstream support not implemented for this FPGA device\n);
+ return FPGA_FAIL;
+}
+
+/*
* Generic multiplexing code
*/
int fpga_load(int devnum, const void *buf, size_t bsize)
diff --git a/drivers/fpga/xilinx.c b/drivers/fpga/xilinx.c
index 32787b2..7d0342a 100644
--- a/drivers/fpga/xilinx.c
+++ b/drivers/fpga/xilinx.c
@@ -48,6 +48,92 @@ static int xilinx_validate (Xilinx_desc * desc, char *fn);
/* - */
+int fpga_loadbitstream(unsigned long dev, char *fpgadata, size_t size)
+{
+ unsigned int length;
+
[U-Boot] [PATCH v3 5/9] fpga: Change the first parameter in fpga_loadbitstream
All fpga functions use devnum as int. Only fpga_loadbitstream
is using it as unsinged long dev.
This patch synchronize it.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v3:
- New patch in this series
Changes in v2: None
drivers/fpga/fpga.c | 2 +-
drivers/fpga/xilinx.c | 4 ++--
include/fpga.h| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index f0253bf..244f503 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -190,7 +190,7 @@ int fpga_add(fpga_type devtype, void *desc)
/*
* Convert bitstream data and load into the fpga
*/
-int __weak fpga_loadbitstream(unsigned long dev, char *fpgadata, size_t size)
+int __weak fpga_loadbitstream(int devnum, char *fpgadata, size_t size)
{
printf(Bitstream support not implemented for this FPGA device\n);
return FPGA_FAIL;
diff --git a/drivers/fpga/xilinx.c b/drivers/fpga/xilinx.c
index 7d0342a..df5f9bf 100644
--- a/drivers/fpga/xilinx.c
+++ b/drivers/fpga/xilinx.c
@@ -48,7 +48,7 @@ static int xilinx_validate (Xilinx_desc * desc, char *fn);
/* - */
-int fpga_loadbitstream(unsigned long dev, char *fpgadata, size_t size)
+int fpga_loadbitstream(int devnum, char *fpgadata, size_t size)
{
unsigned int length;
unsigned int swapsize;
@@ -131,7 +131,7 @@ int fpga_loadbitstream(unsigned long dev, char *fpgadata,
size_t size)
dataptr += 4;
printf( bytes in bitstream = %d\n, swapsize);
- return fpga_load(dev, dataptr, swapsize);
+ return fpga_load(devnum, dataptr, swapsize);
}
int xilinx_load(Xilinx_desc *desc, const void *buf, size_t bsize)
diff --git a/include/fpga.h b/include/fpga.h
index 0d01e04..38f62c0 100644
--- a/include/fpga.h
+++ b/include/fpga.h
@@ -68,7 +68,7 @@ extern void fpga_init(void);
extern int fpga_add(fpga_type devtype, void *desc);
extern int fpga_count(void);
extern int fpga_load(int devnum, const void *buf, size_t bsize);
-extern int fpga_loadbitstream(unsigned long dev, char *fpgadata, size_t size);
+extern int fpga_loadbitstream(int devnum, char *fpgadata, size_t size);
extern int fpga_dump(int devnum, const void *buf, size_t bsize);
extern int fpga_info(int devnum);
--
1.8.2.1
pgpZTl7MNSGGO.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 7/9] fpga: zynq: Add support for loading bitstream
Devcfg device requires to load bitstream in binary format.
But u-boot also has an option for loading bitstream in bit
format. Let's handle both cases by zynqpl driver.
Also add suport for loading partial bitstreams.
The first driver version was done by:
Joe Hershberger joe.hershber...@ni.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v3: None
Changes in v2:
- Fix bugs reported by Tom Rini
- Fix checkpatch warnings (fpga)
- Fix comments (fpga)
- Do not use CamelCase for XilinxZynq (fpga)
- Move to fpga series and extend this driver
This patch was the part of zynq series but I have decided
to extend it with partial bitstream support, loadb support
and create separate patchset just for fpga patches.
The origin patch was reviewed by Tom Rini.
---
arch/arm/cpu/armv7/zynq/slcr.c | 35 +++
arch/arm/include/asm/arch-zynq/hardware.h | 10 +-
arch/arm/include/asm/arch-zynq/sys_proto.h | 3 +
board/xilinx/zynq/board.c | 37 +++
drivers/fpga/Makefile | 1 +
drivers/fpga/xilinx.c | 37 +++
drivers/fpga/zynqpl.c | 355 +
include/configs/zynq.h | 6 +
include/xilinx.h | 4 +
include/zynqpl.h | 59 +
10 files changed, 545 insertions(+), 2 deletions(-)
create mode 100644 drivers/fpga/zynqpl.c
create mode 100644 include/zynqpl.h
diff --git a/arch/arm/cpu/armv7/zynq/slcr.c b/arch/arm/cpu/armv7/zynq/slcr.c
index 5a8674a..52048c6 100644
--- a/arch/arm/cpu/armv7/zynq/slcr.c
+++ b/arch/arm/cpu/armv7/zynq/slcr.c
@@ -28,6 +28,9 @@
#define SLCR_LOCK_MAGIC0x767B
#define SLCR_UNLOCK_MAGIC 0xDF0D
+#define SLCR_IDCODE_MASK 0x1F000
+#define SLCR_IDCODE_SHIFT 12
+
static int slcr_lock = 1; /* 1 means locked, 0 means unlocked */
void zynq_slcr_lock(void)
@@ -87,3 +90,35 @@ void zynq_slcr_gem_clk_setup(u32 gem_id, u32 rclk, u32 clk)
out:
zynq_slcr_lock();
}
+
+void zynq_slcr_devcfg_disable(void)
+{
+ zynq_slcr_unlock();
+
+ /* Disable AXI interface */
+ writel(0x, slcr_base-fpga_rst_ctrl);
+
+ /* Set Level Shifters DT618760 */
+ writel(0xA, slcr_base-lvl_shftr_en);
+
+ zynq_slcr_lock();
+}
+
+void zynq_slcr_devcfg_enable(void)
+{
+ zynq_slcr_unlock();
+
+ /* Set Level Shifters DT618760 */
+ writel(0xF, slcr_base-lvl_shftr_en);
+
+ /* Disable AXI interface */
+ writel(0x0, slcr_base-fpga_rst_ctrl);
+
+ zynq_slcr_lock();
+}
+
+u32 zynq_slcr_get_idcode(void)
+{
+ return (readl(slcr_base-pss_idcode) SLCR_IDCODE_MASK)
+ SLCR_IDCODE_SHIFT;
+}
diff --git a/arch/arm/include/asm/arch-zynq/hardware.h
b/arch/arm/include/asm/arch-zynq/hardware.h
index 6af892a..8b8a91a 100644
--- a/arch/arm/include/asm/arch-zynq/hardware.h
+++ b/arch/arm/include/asm/arch-zynq/hardware.h
@@ -53,11 +53,17 @@ struct slcr_regs {
u32 boot_mode; /* 0x25c */
u32 reserved4[116];
u32 trust_zone; /* 0x430 */ /* FIXME */
- u32 reserved5[115];
+ u32 reserved5_1[63];
+ u32 pss_idcode; /* 0x530 */
+ u32 reserved5_2[51];
u32 ddr_urgent; /* 0x600 */
u32 reserved6[6];
u32 ddr_urgent_sel; /* 0x61c */
- u32 reserved7[188];
+ u32 reserved7[56];
+ u32 mio_pin[54]; /* 0x700 - 0x7D4 */
+ u32 reserved8[74];
+ u32 lvl_shftr_en; /* 0x900 */
+ u32 reserved9[3];
u32 ocm_cfg; /* 0x910 */
};
diff --git a/arch/arm/include/asm/arch-zynq/sys_proto.h
b/arch/arm/include/asm/arch-zynq/sys_proto.h
index af9e7f8..2317121 100644
--- a/arch/arm/include/asm/arch-zynq/sys_proto.h
+++ b/arch/arm/include/asm/arch-zynq/sys_proto.h
@@ -27,6 +27,9 @@ extern void zynq_slcr_lock(void);
extern void zynq_slcr_unlock(void);
extern void zynq_slcr_cpu_reset(void);
extern void zynq_slcr_gem_clk_setup(u32 gem_id, u32 rclk, u32 clk);
+extern void zynq_slcr_devcfg_disable(void);
+extern void zynq_slcr_devcfg_enable(void);
+extern u32 zynq_slcr_get_idcode(void);
/* Driver extern functions */
extern int zynq_sdhci_init(u32 regbase);
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 1589d21..b02c364 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -22,15 +22,52 @@
#include common.h
#include netdev.h
+#include zynqpl.h
#include asm/arch/hardware.h
#include asm/arch/sys_proto.h
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_FPGA
+Xilinx_desc fpga;
+
+/* It can be done differently */
+Xilinx_desc fpga010 = XILINX_XC7Z010_DESC(0x10);
+Xilinx_desc fpga020 = XILINX_XC7Z020_DESC(0x20);
+Xilinx_desc fpga030 = XILINX_XC7Z030_DESC(0x30);
+Xilinx_desc fpga045 = XILINX_XC7Z045_DESC(0x45);
+#endif
+
int board_init(void)
{
+#ifdef CONFIG_FPGA
+ u32 idcode;
+
+ idcode = zynq_slcr_get_idcode();
+
+ switch (idcode) {
+ case
[U-Boot] [PATCH v3 8/9] fpga: Check device name against bitstream name
Ensure that wrong bitstream won't be loaded
to current device.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v3:
- Rebase because of change in previous patch
- fpga_validate should be global function
- fix one printf function
- change parameter name according to previous patch dev-devnum
Changes in v2:
- New patch in this series
drivers/fpga/fpga.c | 4 ++--
drivers/fpga/xilinx.c | 23 +++
include/fpga.h| 2 ++
include/xilinx.h | 1 +
include/zynqpl.h | 8
5 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 244f503..f70bff6 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -72,8 +72,8 @@ static const fpga_desc *const fpga_get_desc(int devnum)
* fpga_validate
* generic parameter checking code
*/
-static const fpga_desc *const fpga_validate(int devnum, const void *buf,
-size_t bsize, char *fn)
+const fpga_desc *const fpga_validate(int devnum, const void *buf,
+size_t bsize, char *fn)
{
const fpga_desc *desc = fpga_get_desc(devnum);
diff --git a/drivers/fpga/xilinx.c b/drivers/fpga/xilinx.c
index 496aa2f..49e9437 100644
--- a/drivers/fpga/xilinx.c
+++ b/drivers/fpga/xilinx.c
@@ -30,6 +30,7 @@
*/
#include common.h
+#include fpga.h
#include virtex2.h
#include spartan2.h
#include spartan3.h
@@ -58,8 +59,14 @@ int fpga_loadbitstream(int devnum, char *fpgadata, size_t
size)
char buffer[80];
unsigned char *dataptr;
unsigned int i;
+ const fpga_desc *desc;
+ Xilinx_desc *xdesc;
dataptr = (unsigned char *)fpgadata;
+ /* Find out fpga_description */
+ desc = fpga_validate(devnum, dataptr, 0, (char *)__func__);
+ /* Assign xilinx device description */
+ xdesc = desc-devdesc;
/* skip the first bytes of the bitsteam, their meaning is unknown */
length = (*dataptr 8) + *(dataptr + 1);
@@ -93,6 +100,20 @@ int fpga_loadbitstream(int devnum, char *fpgadata, size_t
size)
dataptr += 2;
for (i = 0; i length; i++)
buffer[i] = *dataptr++;
+
+ if (xdesc-name) {
+ i = strncmp(buffer, xdesc-name, strlen(xdesc-name));
+ if (i) {
+ printf(%s: Wrong bitstream ID for this device\n,
+ __func__);
+ printf(%s: Bitstream ID %s, current device ID %d/%s\n,
+ __func__, buffer, devnum, xdesc-name);
+ return FPGA_FAIL;
+ }
+ } else {
+ printf(%s: Please fill correct device ID to Xilinx_desc\n,
+ __func__);
+ }
printf( part number = \%s\\n, buffer);
/* get date (identifier, length, string) */
@@ -306,6 +327,8 @@ int xilinx_info (Xilinx_desc * desc)
printf (Device Size: \t%d bytes\n
Cookie:\t0x%x (%d)\n,
desc-size, desc-cookie, desc-cookie);
+ if (desc-name)
+ printf(Device name: \t%s\n, desc-name);
if (desc-iface_fns) {
printf (Device Function Table @ 0x%p\n,
desc-iface_fns);
diff --git a/include/fpga.h b/include/fpga.h
index 38f62c0..ebefba8 100644
--- a/include/fpga.h
+++ b/include/fpga.h
@@ -71,5 +71,7 @@ extern int fpga_load(int devnum, const void *buf, size_t
bsize);
extern int fpga_loadbitstream(int devnum, char *fpgadata, size_t size);
extern int fpga_dump(int devnum, const void *buf, size_t bsize);
extern int fpga_info(int devnum);
+extern const fpga_desc *const fpga_validate(int devnum, const void *buf,
+ size_t bsize, char *fn);
#endif /* _FPGA_H_ */
diff --git a/include/xilinx.h b/include/xilinx.h
index 592cbea..bcfe76d 100644
--- a/include/xilinx.h
+++ b/include/xilinx.h
@@ -81,6 +81,7 @@ typedef struct { /* typedef Xilinx_desc */
size_t size;/* bytes of data part can accept */
void *iface_fns;/* interface function table */
int cookie; /* implementation specific cookie */
+ char *name; /* device name in bitstream */
} Xilinx_desc; /* end, typedef Xilinx_desc */
/* Generic Xilinx Functions
diff --git a/include/zynqpl.h b/include/zynqpl.h
index bc9b948..0247ef6 100644
--- a/include/zynqpl.h
+++ b/include/zynqpl.h
@@ -45,15 +45,15 @@ extern int zynq_info(Xilinx_desc *desc);
/* Descriptor Macros */
#define XILINX_XC7Z010_DESC(cookie) \
-{ xilinx_zynq, devcfg, XILINX_XC7Z010_SIZE, NULL, cookie }
+{ xilinx_zynq, devcfg, XILINX_XC7Z010_SIZE, NULL, cookie, 7z010 }
#define XILINX_XC7Z020_DESC(cookie) \
-{ xilinx_zynq, devcfg, XILINX_XC7Z020_SIZE, NULL, cookie }
+{ xilinx_zynq, devcfg, XILINX_XC7Z020_SIZE, NULL, cookie,
[U-Boot] [PATCH v3 9/9] fpga: Remove all CONFIG_SYS_* fpga related options
All these macros are completely unused by any code.
CONFIG_FPGA is not a bitfield anymore.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v3:
- New patch in this series
Changes in v2: None
include/altera.h | 17 -
include/configs/M54455EVB.h | 2 +-
include/configs/MERGERBOX.h | 2 +-
include/configs/MVBC_P.h | 2 +-
include/configs/MVBLM7.h | 2 +-
include/configs/MVSMR.h | 2 +-
include/configs/omap3_mvblx.h | 2 +-
include/fpga.h| 10 --
include/lattice.h | 3 ---
include/xilinx.h | 24
10 files changed, 6 insertions(+), 60 deletions(-)
diff --git a/include/altera.h b/include/altera.h
index 7a2bece..6aad5ee 100644
--- a/include/altera.h
+++ b/include/altera.h
@@ -27,23 +27,6 @@
#ifndef _ALTERA_H_
#define _ALTERA_H_
-/* Altera Model definitions
- */
-#define CONFIG_SYS_ACEX1K CONFIG_SYS_FPGA_DEV( 0x1 )
-#define CONFIG_SYS_CYCLON2 CONFIG_SYS_FPGA_DEV( 0x2 )
-#define CONFIG_SYS_STRATIX_II CONFIG_SYS_FPGA_DEV( 0x4 )
-
-#define CONFIG_SYS_ALTERA_ACEX1K (CONFIG_SYS_FPGA_ALTERA |
CONFIG_SYS_ACEX1K)
-#define CONFIG_SYS_ALTERA_CYCLON2 (CONFIG_SYS_FPGA_ALTERA |
CONFIG_SYS_CYCLON2)
-#define CONFIG_SYS_ALTERA_STRATIX_II (CONFIG_SYS_FPGA_ALTERA |
CONFIG_SYS_STRATIX_II)
-/* Add new models here */
-
-/* Altera Interface definitions
- */
-#define CONFIG_SYS_ALTERA_IF_PSCONFIG_SYS_FPGA_IF( 0x1 ) /*
passive serial */
-#define CONFIG_SYS_ALTERA_IF_FPP CONFIG_SYS_FPGA_IF( 0x2 ) /* fast
passive parallel */
-/* Add new interfaces here */
-
typedef enum { /* typedef Altera_iface */
min_altera_iface_type, /* insert all new types after this */
passive_serial, /* serial data and external clock */
diff --git a/include/configs/M54455EVB.h b/include/configs/M54455EVB.h
index 1bc2c5a..536b755 100644
--- a/include/configs/M54455EVB.h
+++ b/include/configs/M54455EVB.h
@@ -238,7 +238,7 @@
/* FPGA - Spartan 2 */
/* experiment
-#define CONFIG_FPGACONFIG_SYS_SPARTAN3
+#define CONFIG_FPGA
#define CONFIG_FPGA_COUNT 1
#define CONFIG_SYS_FPGA_PROG_FEEDBACK
#define CONFIG_SYS_FPGA_CHECK_CTRLC
diff --git a/include/configs/MERGERBOX.h b/include/configs/MERGERBOX.h
index c296e3c..30fb6c2 100644
--- a/include/configs/MERGERBOX.h
+++ b/include/configs/MERGERBOX.h
@@ -606,7 +606,7 @@
* FPGA
*/
#define CONFIG_FPGA_COUNT 1
-#define CONFIG_FPGACONFIG_SYS_ALTERA_CYCLON2
+#define CONFIG_FPGA
#define CONFIG_FPGA_ALTERA
#define CONFIG_FPGA_CYCLON2
diff --git a/include/configs/MVBC_P.h b/include/configs/MVBC_P.h
index 6850965..7271468 100644
--- a/include/configs/MVBC_P.h
+++ b/include/configs/MVBC_P.h
@@ -310,7 +310,7 @@
#undef FPGA_DEBUG
#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
-#define CONFIG_FPGACONFIG_SYS_ALTERA_CYCLON2
+#define CONFIG_FPGA
#define CONFIG_FPGA_ALTERA 1
#define CONFIG_FPGA_CYCLON21
#define CONFIG_FPGA_COUNT 1
diff --git a/include/configs/MVBLM7.h b/include/configs/MVBLM7.h
index a99ad3c..a9c00ac 100644
--- a/include/configs/MVBLM7.h
+++ b/include/configs/MVBLM7.h
@@ -499,7 +499,7 @@
#define CONFIG_FPGA_COUNT 1
-#define CONFIG_FPGACONFIG_SYS_ALTERA_CYCLON2
+#define CONFIG_FPGA
#define CONFIG_FPGA_ALTERA
#define CONFIG_FPGA_CYCLON2
diff --git a/include/configs/MVSMR.h b/include/configs/MVSMR.h
index bf2f44e..5d2ff14 100644
--- a/include/configs/MVSMR.h
+++ b/include/configs/MVSMR.h
@@ -280,7 +280,7 @@
#undef FPGA_DEBUG
#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
-#define CONFIG_FPGACONFIG_SYS_XILINX_SPARTAN2
+#define CONFIG_FPGA
#define CONFIG_FPGA_XILINX 1
#define CONFIG_FPGA_SPARTAN2 1
#define CONFIG_FPGA_COUNT 1
diff --git a/include/configs/omap3_mvblx.h b/include/configs/omap3_mvblx.h
index 376a3d0..f9adc01 100644
--- a/include/configs/omap3_mvblx.h
+++ b/include/configs/omap3_mvblx.h
@@ -273,7 +273,7 @@
#endif /* (CONFIG_CMD_NET) */
#define CONFIG_FPGA_COUNT 1
-#define CONFIG_FPGA CONFIG_SYS_ALTERA_CYCLON2
+#define CONFIG_FPGA
#define CONFIG_FPGA_ALTERA
#define CONFIG_FPGA_CYCLON2
#define CONFIG_SYS_FPGA_PROG_FEEDBACK
diff --git a/include/fpga.h b/include/fpga.h
index ebefba8..38e9018 100644
--- a/include/fpga.h
+++ b/include/fpga.h
@@ -31,16 +31,6 @@
#define CONFIG_MAX_FPGA_DEVICES5
#endif
-/* CONFIG_FPGA bit assignments */
-#define CONFIG_SYS_FPGA_MAN(x) (x)
-#define CONFIG_SYS_FPGA_DEV(x) ((x) 8 )
-#define CONFIG_SYS_FPGA_IF(x) ((x) 16 )
-
-/* FPGA Manufacturer bits in CONFIG_FPGA */
-#define CONFIG_SYS_FPGA_XILINX CONFIG_SYS_FPGA_MAN( 0x1 )
-#define CONFIG_SYS_FPGA_ALTERA CONFIG_SYS_FPGA_MAN(
[U-Boot] [PATCH 1/2] microblaze: bootm: Fix coding style issues
Prepare place for new patch.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
arch/microblaze/lib/bootm.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/microblaze/lib/bootm.c b/arch/microblaze/lib/bootm.c
index 66d21f4..b992a4d 100644
--- a/arch/microblaze/lib/bootm.c
+++ b/arch/microblaze/lib/bootm.c
@@ -32,11 +32,12 @@
DECLARE_GLOBAL_DATA_PTR;
-int do_bootm_linux(int flag, int argc, char * const argv[], bootm_headers_t
*images)
+int do_bootm_linux(int flag, int argc, char * const argv[],
+ bootm_headers_t *images)
{
/* First parameter is mapped to $r5 for kernel boot args */
- void(*theKernel) (char *, ulong, ulong);
- char*commandline = getenv (bootargs);
+ void(*thekernel) (char *, ulong, ulong);
+ char*commandline = getenv(bootargs);
ulong rd_data_start, rd_data_end;
if ((flag != 0) (flag != BOOTM_STATE_OS_GO))
@@ -51,10 +52,10 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
bootm_headers_t *ima
of_flat_tree = images-ft_addr;
#endif
- theKernel = (void (*)(char *, ulong, ulong))images-ep;
+ thekernel = (void (*)(char *, ulong, ulong))images-ep;
/* find ramdisk */
- ret = boot_get_ramdisk (argc, argv, images, IH_ARCH_MICROBLAZE,
+ ret = boot_get_ramdisk(argc, argv, images, IH_ARCH_MICROBLAZE,
rd_data_start, rd_data_end);
if (ret)
return 1;
@@ -64,9 +65,10 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
bootm_headers_t *ima
if (!of_flat_tree argc 3)
of_flat_tree = (char *)simple_strtoul(argv[3], NULL, 16);
#ifdef DEBUG
- printf (## Transferring control to Linux (at address 0x%08lx) \
- ramdisk 0x%08lx, FDT 0x%08lx...\n,
- (ulong) theKernel, rd_data_start, (ulong) of_flat_tree);
+ printf(## Transferring control to Linux (at address 0x%08lx) ,
+ (ulong)thekernel);
+ printf(ramdisk 0x%08lx, FDT 0x%08lx...\n,
+ rd_data_start, (ulong) of_flat_tree);
#endif
#ifdef XILINX_USE_DCACHE
@@ -78,7 +80,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
bootm_headers_t *ima
* r6: pointer to ramdisk
* r7: pointer to the fdt, followed by the board info data
*/
- theKernel (commandline, rd_data_start, (ulong) of_flat_tree);
+ thekernel(commandline, rd_data_start, (ulong)of_flat_tree);
/* does not return */
return 1;
--
1.8.2.1
pgprXnWHKIFFu.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] microblaze: bootm: Add support for loading initrd
fdt_initrd add additional information to DTB about initrd addresses which are later used by kernel. Signed-off-by: Michal Simek michal.si...@xilinx.com --- arch/microblaze/lib/bootm.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/microblaze/lib/bootm.c b/arch/microblaze/lib/bootm.c index b992a4d..bb01a71 100644 --- a/arch/microblaze/lib/bootm.c +++ b/arch/microblaze/lib/bootm.c @@ -64,6 +64,11 @@ int do_bootm_linux(int flag, int argc, char * const argv[], if (!of_flat_tree argc 3) of_flat_tree = (char *)simple_strtoul(argv[3], NULL, 16); + + /* fixup the initrd now that we know where it should be */ + if (images-rd_start images-rd_end of_flat_tree) + fdt_initrd(of_flat_tree, images-rd_start, images-rd_end, 1); + #ifdef DEBUG printf(## Transferring control to Linux (at address 0x%08lx) , (ulong)thekernel); -- 1.8.2.1 pgptnS3dEVBgu.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: Tegra: USB: Add driver support for Tegra30/Tegra114
On Fri, 2013-05-03 at 03:29 +0800, Stephen Warren wrote: On 04/29/2013 03:21 AM, Jim Lin wrote: Tegra30 and Tegra114 are compatible except 1. T30 takes 55 ms to finish Port Reset. T114 takes 50 ms. Is that 55-vs-50 some aspect of the HW specification itself, or the overall result of multiple separate delays? I ask because the statement that one piece of HW differs from another only in a delay, especially where that delay is enormous in HW terms, seem very unusual. 50 ms comes from USB 2.0 specification for root port. 55 ms comes from T30 Technical Reference Manual. Overall result of multiple separate delays. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] at91sam9x5ek: Pass serial and revision tags to Linux
This code is small snippet from patch
ftp://ftp.linux4sam.org/pub/uboot/u-boot-v2010.06/u-boot-5series_1.0.patch
Bug:-
For board at91sam9x5ek, U-boot doesn't pass serial and revision tags
to Linux kernel, hence kernel fails to identify correct revision and assumes
as rev-A, resulting in failing to detect NAND device.
This patch enables u-boot to pass serial and revision tags to Linux
kernel, which helps Linux to detect NAND device.
Signed-off-by: Julius Hemanth juliushema...@gmail.com
---
Changes for v2:
- access GPBR using c structure
- removed tailing 1 for #define
- s/Miscelaneous/Miscellaneous
- s/initialisations/initializations
board/atmel/at91sam9x5ek/at91sam9x5ek.c | 33 ++-
include/configs/at91sam9x5ek.h |5
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
index 8773e6f..c05bdb7 100644
--- a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
+++ b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
@@ -27,6 +27,7 @@
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/at91_rstc.h
+#include asm/arch/at91_gpbr.h
#include asm/arch/gpio.h
#include asm/arch/clk.h
#include lcd.h
@@ -48,8 +49,34 @@ DECLARE_GLOBAL_DATA_PTR;
/* - */
/*
- * Miscelaneous platform dependent initialisations
+ * Miscellaneous platform dependent initializations
*/
+
+#ifdef CONFIG_LOAD_ONE_WIRE_INFO
+static u32 system_rev;
+static u32 system_serial_low;
+
+u32 get_board_rev(void)
+{
+ return system_rev;
+}
+
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+ serialnr-high = 0; /* Not used */
+ serialnr-low = system_serial_low;
+}
+
+void load_1wire_info(void)
+{
+ at91_gpbr_t *gpbr = (at91_gpbr_t *) ATMEL_BASE_GPBR;
+
+ /* serial is in GPBR #2 and revision is in GPBR #3 */
+ system_serial_low = readl(gpbr-reg[2]);
+ system_rev = readl(gpbr-reg[3]);
+}
+#endif
+
#ifdef CONFIG_CMD_NAND
static void at91sam9x5ek_nand_hw_init(void)
{
@@ -282,6 +309,10 @@ int board_init(void)
/* adress of boot parameters */
gd-bd-bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
+#ifdef CONFIG_LOAD_ONE_WIRE_INFO
+ load_1wire_info();
+#endif
+
#ifdef CONFIG_CMD_NAND
at91sam9x5ek_nand_hw_init();
#endif
diff --git a/include/configs/at91sam9x5ek.h b/include/configs/at91sam9x5ek.h
index ee6e3fc..995e43b 100644
--- a/include/configs/at91sam9x5ek.h
+++ b/include/configs/at91sam9x5ek.h
@@ -38,6 +38,11 @@
#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_INITRD_TAG
+
+#define CONFIG_LOAD_ONE_WIRE_INFO
+#define CONFIG_REVISION_TAG
+#define CONFIG_SERIAL_TAG
+
#define CONFIG_SKIP_LOWLEVEL_INIT
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_DISPLAY_CPUINFO
--
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 1/3] ARM: Tegra: FDT: Add USB support for T20/T30/T114
On Fri, 2013-05-03 at 03:10 +0800, Stephen Warren wrote:
On 04/29/2013 03:21 AM, Jim Lin wrote:
Add DT node for USB function.
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
+/* This table has USB timing parameters for each Oscillator frequency we
+ * support. There are four sets of values:
+ *
+ * 1. PLLU configuration information (reference clock is osc/clk_m and
+ * PLLU-FOs are fixed at 12MHz/60MHz/480MHz).
+ * Reference frequency MHZ 12.0 13.0 19.2 26.0
+ *
+ * DIVN 960 960200 960
+ * DIVM 1213 426
+ * CPCON 1212 312
+ * LFCON 2 2 2 2
+ *
+ * 2. PLL CONFIGURATION PARAMETERS for different clock generators:
+ * Reference frequency MHZ 12.0 13.0 19.2 26.0
+ *
+ * PLLU_ENABLE_DLY_COUNT 02 2 3 4
+ * PLLU_STABLE_COUNT 475175 102
+ * PLL_ACTIVE_DLY_COUNT08 912 9
+ * XTAL_FREQ_COUNT118 127 188 254
+ *
+ * 3. Debounce values IdDig, Avalid, Bvalid, VbusValid, VbusWakeUp, and
+ * SessEnd. Each of these signals have their own debouncer and for each of
+ * those one out of two debouncing times can be chosen (BIAS_DEBOUNCE_A or
+ * BIAS_DEBOUNCE_B).
+ *
+ * The values of DEBOUNCE_A and DEBOUNCE_B are calculated as follows:
+ *0x - No debouncing at all
+ *n ms = n * 1000 / (1/19.2MHz) / 4
+ *
+ * So to program a 10 ms debounce for BIAS_DEBOUNCE_A, we have:
+ * BIAS_DEBOUNCE_A[15:0] = 10 * 1000 * 19.2 / 4 = 48000 = 0xBB80
+ *
+ * We need to use only DebounceA for BOOTROM. We don't need the DebounceB
+ * values, so we can keep those to default.
+ *
+ * 4. The 20 microsecond delay after bias cell operation.
+ *UTMIP_BIAS_PAD_TRK_COUNT
+ *
+ * enum {
+ * PARAM_DIVN, // PLL FEEDBACK DIVIDER
+ * PARAM_DIVM, // PLL INPUT DIVIDER
+ * PARAM_DIVP, // POST DIVIDER (2^N)
+ * PARAM_CPCON,// BASE PLLC CHARGE Pump setup ctrl
+ * PARAM_LFCON,// BASE PLLC LOOP FILter setup ctrl
+ * PARAM_ENABLE_DELAY_COUNT, // PLL-U Enable Delay Count
+ * PARAM_STABLE_COUNT, // PLL-U STABLE count
+ * PARAM_ACTIVE_DELAY_COUNT, // PLL-U Active delay count
+ * PARAM_XTAL_FREQ_COUNT, // PLL-U XTAL frequency count
+ * PARAM_DEBOUNCE_A_TIME, // 10MS DELAY for BIAS_DEBOUNCE_A
+ * PARAM_BIAS_TIME,// 20US DELAY AFter bias cell op
+ * // UTMIP_BIAS_PAD_TRK_COUNT
+ *};
+ */
+ usbparams@0 {
+ compatible = nvidia,usbparams;
+ osc-frequency = 1300;
+ /* DivN, DivM, DivP, CPCON, LFCON, Delays Debounce, Bias */
+ params = 0x3c0 0x0d 0x00 0xc 2 0x02 0x33 0x09 0x7f 0x7ef4 6;
+ };
+
+ usbparams@1 {
+ compatible = nvidia,usbparams;
+ osc-frequency = 1920;
+ params = 0x0c8 0x04 0x00 0x3 2 0x03 0x4b 0x0c 0xbc 0xbb80 8;
+ };
+
+ usbparams@2 {
+ compatible = nvidia,usbparams;
+ osc-frequency = 1200;
+ params = 0x3c0 0x0c 0x00 0xc 2 0x02 0x2f 0x08 0x76 0x7530 5;
+ };
+
+ usbparams@3 {
+ compatible = nvidia,usbparams;
+ osc-frequency = 2600;
+ params = 0x3c0 0x1a 0x00 0xc 2 0x04 0x66 0x09 0xfe 0xfde8
0xb;
+ };
None of the above should be present; this is SoC-specific information
and should be part of the USB driver itself. There's no benefit to
putting the information into DT just to parse it back out into the same
tables that the driver could have contained in the first place.
Parameters are not completely same for T20, T30, and T114.
Putting over dt file is for expanding on future chips.
The same comment applies to all 3 tegra*.dtsi files. For the Tegra20
case, please make sure that what you add here is identical to what has
been proposed for the final kernel USB bindings. Ask Venu (now CC'd) for
a pointer to that.
+ usb@7d00 {
+ compatible = nvidia,tegra30-ehci, nvidia,tegra114-ehci;
+ reg = 0x7d00 0x4000;
+ interrupts = 52 ;
There shouldn't be spaces after or before .
The bindings here don't match the kernel. Please make sure they do.
This patch only touches 2 board files: Cardhu and Dalmore. Will USB
support on other boards continue to work without any DT changes?
Existing functionality can't be broken. I'd expect to see a bunch more
DT files edited here.
For T20, I only have Seaboard and Harmony platforms.
For other T20 platforms, I may blindly add USB support as you suggested,
is that okay?
--
nvpublic
Re: [U-Boot] [PATCH 12/12] imx: mx5: Remove legacy iomux support
Dear Marek Vasut, On Friday, May 3, 2013 4:38:43 AM, Marek Vasut wrote: Dear Benoît Thébaudeau, Legacy iomux support is no longer needed now that all boards have been converted to iomux-v3. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Yes, good move Reviewed-by: Marek Vasut ma...@denx.de How do you plan to handle the conversion to iomux-v3 of the not-yet-applied m53evk: - You rebase your series on mine? - I rebase my series on yours? - I convert m53evk, then I send you the file so that you can refactor your series and trivially rebase it on mine? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regression from v2013.04-rc3 with sdcard detection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/02/2013 10:27 PM, Jaehoon Chung wrote: On 05/03/2013 02:53 AM, Stephen Warren wrote: On 04/21/2013 11:29 AM, Nicolas Chauvet wrote: Hi, I'm experiencing a regression from v2013.04-rc3 that I found related to the following commit: 64f4a6192f0670de2d9af98900b750a3e7bf8ce6 1741c64d642a95c4bb88a2b03e96c6dc7ed5fe62 With v2013.04 release, when trying to boot from sdcard, I have: Card did not respond to voltage select while detecting the sdcard as mmc 1 Well, i didn't think it is related with that commit. Those patches is just checking revision. And That message is produced that card didn't complete the power-up processing. As Stephen said, which card do you use? If you give more information to us, it is helpful. Finally, git bisect can be very helpful here, so long as you have a point in mainline where everything worked. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRg6sQAAoJENk4IS6UOR1WvrUP/1q+cVYz2VUysXzZVNKN6Eqo vlsl4ESNTX74Xxw1r+uu1aUZShhnSdA4xZK7n/OCUHG+izLQpd4J0sik8UuY1JO5 aI4Ng7jn8r/nflBe7x60uQ0zFfMNQ5an5fOMRyW4XKtNLIHLl8l4epoYdYT+6M4B G1yuE6a166nycW00jCjKBLRNd69/iz/qhIxMa0Pjy/4eqzS1QkssWPbK2k0jAoQo M0sxq71uaRai7s1ytyydjaQCljH/vNMbYFRe8xO5hh4g/a3XyASdIm6nkeNlumXu f1ZLja2c6qMMSEqGBks9ieJXKrkY/P+lhbOaKSFvzwHMdujskFIIodP34FRsyZG6 J9CVjwr5tafnq8x+5P/+kDnre0NzwxP8zhDvMa3YsxMvMAcM9FHZatmnEiSZ8Xgr MRcVQ2gYYQ+44OZQhP9g4pZyDJmnNeQhgdaUhKJT4VOMDoSG0UEPUACJENtFH3Mf gH0HxcHra1DzolKZjdIaiu7YrYGR61Nk1T+VV+nD7kxL7NmObN7v3B8222ebfuid n8LDGwZyqwkB8o1QOeKGWDnK8VWjescHz6pjDhRuQewEsKnQe6X34JxgFSg/Pq4u 3S96myV6xgI56c1ztAsVsQYCiFcwUjwxS+hbfDr/rvZtfrWUZxkqgegWodvuDIXt YKrIFdXuA+PvTE/XhO64 =KatA -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] EXYNOS: SPI: Support SPI_PREAMBLE mode
[the original patch removed]
So, I spent some more time debugging a system which requires this
patch: a system, where on a SPI interface a response to a command
could come way later then the command data transmission completes.
The original patch was trying to address many corner cases, but come
to think of it, in this situation the slave does not care about extra
data sent on the transmit interface, as otherwise there is no clock
and no data could be transferred from the slave.
Then, for this SPI interface we do not need to set the counter of
clocks, and do not need to keep adding more clocks if the data has not
been received yet, the clocks could be just free running. And then the
patch becomes much simpler, what do you think:
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index c697db8..fff8310 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -211,10 +211,10 @@ static void spi_get_fifo_levels(struct exynos_spi *regs,
*/
static void spi_request_bytes(struct exynos_spi *regs, int count)
{
- assert(count count (1 16));
setbits_le32(regs-ch_cfg, SPI_CH_RST);
clrbits_le32(regs-ch_cfg, SPI_CH_RST);
- writel(count | SPI_PACKET_CNT_EN, regs-pkt_cnt);
+ if (count)
+ writel(count | SPI_PACKET_CNT_EN, regs-pkt_cnt);
}
static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
@@ -225,14 +225,20 @@ static void spi_rx_tx(struct exynos_spi_slave
*spi_slave, int todo,
const uchar *txp = *doutp;
int rx_lvl, tx_lvl;
uint out_bytes, in_bytes;
-
+ int hunting;
+
+ if (spi_slave-free_running_mode) {
+ spi_request_bytes(regs, 0);
+ hunting = 1;
+ } else {
+ hunting = 0;
+ spi_request_bytes(regs, todo);
+ }
out_bytes = in_bytes = todo;
- /*
-* If there's something to send, do a software reset and set a
-* transaction size.
-*/
- spi_request_bytes(regs, todo);
+ /* Software reset the channel. */
+ setbits_le32(regs-ch_cfg, SPI_CH_RST);
+ clrbits_le32(regs-ch_cfg, SPI_CH_RST);
/*
* Bytes are transmitted/received in pairs. Wait to receive all the
@@ -243,13 +249,23 @@ static void spi_rx_tx(struct exynos_spi_slave
*spi_slave, int todo,
/* Keep the fifos full/empty. */
spi_get_fifo_levels(regs, rx_lvl, tx_lvl);
- if (tx_lvl spi_slave-fifo_size out_bytes) {
- temp = txp ? *txp++ : 0xff;
+ if (tx_lvl spi_slave-fifo_size) {
+ if (txp out_bytes) {
+ temp = *txp++;
+ out_bytes--;
+ } else {
+ temp = 0xff;
+ }
writel(temp, regs-tx_data);
- out_bytes--;
}
if (rx_lvl 0 in_bytes) {
temp = readl(regs-rx_data);
+ if (hunting) {
+ if ((temp 0xff) != PREAMBLE_VALUE)
+ continue;
+ else
+ hunting = 0;
+ }
if (rxp)
*rxp++ = temp;
in_bytes--;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot source code for MPC8641D MPC8548E
Hi all I require uboot source code for board MPC8641D MPC8548E. Kindly provide me link for these PPC board Thanks u -- View this message in context: http://u-boot.10912.n7.nabble.com/uboot-source-code-for-MPC8641D-MPC8548E-tp153881.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Regarding tdm3730
Respected Sir/Mam,
I am new on linux and BSP. We have purchased one processors board whihc is
technexion tdm3730 Blizzardpack.
We have install Cross Compiler(CodeSourcery C++ Lite 2010.09-50) for the
same from below link :
https://sourcery.mentor.com/sgpp/lite/arm/portal/release1600
Now i have install another file which is given on technexion website from
below link :
http://www.technexion.com/index.php/support/download-center/arm-cpu-modules/tdm-3730
And follow the steps for making binaries for MLO,uboot.bin,UImage as given
in attached document.
but i am facing problem when i entered into uboot bin folder and then type
command :
make distclean make tdm3730_config make -j 2D
then last command exit with error127 which is as below:
awk '(NF $1 !~ /^#/) { print $1 : $1 _config; $(MAKE) }' boards.cfg
.boards.depend
Configuring for tdm3730 board...
make: /home/lumium/CodeSourcery/Sourcery_G++_Lite/bin:gcc: Command not found
/bin/sh: /home/lumium/CodeSourcery/Sourcery_G++_Lite/bin:gcc: No such file
or directory
dirname: missing operand
Try `dirname --help' for more information.
Generating include/autoconf.mk
/bin/sh: line 3: /home/lumium/CodeSourcery/Sourcery_G++_Lite/bin:gcc: No
such file or directory
/bin/sh: /home/lumium/CodeSourcery/Sourcery_G++_Lite/bin:gcc: No such file
or directory
dirname: missing operand
Try `dirname --help' for more information.
Generating include/autoconf.mk.dep
/bin/sh: line 3: /home/lumium/CodeSourcery/Sourcery_G++_Lite/bin:gcc: No
such file or directory
make: /home/lumium/CodeSourcery/Sourcery_G++_Lite/bin:gcc: Command not found
make: *** No rule to make target `2D'. Stop.
I have made changes i Makefile of UBoot folder that ia as below
1.) Write Export ARCH=arm
2.) CROSS_COMPILE=/*Path to tool-chain:/bin:*/
3.) export CROSS_COMPILE
Now Please let me tel where i made mistake and getting this error. Please
help me out in this matter.
Thanks Regards,
Nagesh Pathak
--
*Thanks Regards,*
Nagesh Pathak
Ahmedabad,Gujrat
+91-9624810308
email id : nagesh.p...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: default image: use ih_size for checking data size
Common image usage is uImage + appended rootfs, so the the uImage data
is only part of the total image. So read out and use the header's
ih_size field instead of the total file size.
To prevent reading over the end of the buffer, check that the image file
is big enough to contain the data before calculating its checksum.
Before:
~# mkimage -l dir665_fw_100NA.bin
mkimage: ERROR: dir665_fw_100NA/dir665_fw_100NA.bin has corrupted data!
After:
~# mkimage -l dir665_fw_100NA.bin
Image Name: Linux Kernel Image
Created: Fri Feb 12 03:38:36 2010
Image Type: ARM Linux Kernel Image (lzma compressed)
Data Size:1107781 Bytes = 1081.82 kB = 1.06 MB
Load Address: 8000
Entry Point: 8000
Signed-off-by: Jonas Gorski j...@openwrt.org
---
tools/default_image.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/default_image.c b/tools/default_image.c
index e9d0729..db20e53 100644
--- a/tools/default_image.c
+++ b/tools/default_image.c
@@ -86,10 +86,11 @@ static int image_verify_header(unsigned char *ptr, int
image_size,
}
data = (const unsigned char *)ptr + sizeof(image_header_t);
- len = image_size - sizeof(image_header_t) ;
+ len = be32_to_cpu(hdr-ih_size);
checksum = be32_to_cpu(hdr-ih_dcrc);
- if (crc32(0, data, len) != checksum) {
+ if ((image_size - sizeof(image_header_t)) len ||
+ crc32(0, data, len) != checksum) {
fprintf(stderr,
%s: ERROR: \%s\ has corrupted data!\n,
params-cmdname, params-imagefile);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: Tegra: FDT: Add USB support for T20/T30/T114
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Friday, May 03, 2013 12:40 AM
To: Jim Lin
Cc: u-boot@lists.denx.de; ma...@denx.de; Stephen Warren; Tom Warren;
Venu Byravarasu
Subject: Re: [U-Boot] [PATCH 1/3] ARM: Tegra: FDT: Add USB support for
T20/T30/T114
On 04/29/2013 03:21 AM, Jim Lin wrote:
Add DT node for USB function.
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
+/* This table has USB timing parameters for each Oscillator frequency we
+ * support. There are four sets of values:
+ *
The same comment applies to all 3 tegra*.dtsi files. For the Tegra20
case, please make sure that what you add here is identical to what has
been proposed for the final kernel USB bindings. Ask Venu (now CC'd) for
a pointer to that.
Plz see attached file for finalized Tegra20 DT bindings.
+ usb@7d00 {
+ compatible = nvidia,tegra30-ehci, nvidia,tegra114-ehci;
+ reg = 0x7d00 0x4000;
+ interrupts = 52 ;
There shouldn't be spaces after or before .
The bindings here don't match the kernel. Please make sure they do.
This patch only touches 2 board files: Cardhu and Dalmore. Will USB
support on other boards continue to work without any DT changes?
Existing functionality can't be broken. I'd expect to see a bunch more
DT files edited here.
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
0001-ARM-tegra-finalize-USB-EHCI-and-PHY-bindings.patch
Description: 0001-ARM-tegra-finalize-USB-EHCI-and-PHY-bindings.patch
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: mx5: Remove legacy iomux support
Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 4:38:43 AM, Marek Vasut wrote: Dear Benoît Thébaudeau, Legacy iomux support is no longer needed now that all boards have been converted to iomux-v3. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Yes, good move Reviewed-by: Marek Vasut ma...@denx.de How do you plan to handle the conversion to iomux-v3 of the not-yet-applied m53evk: - You rebase your series on mine? - I rebase my series on yours? Did you not send this stuff after m53evk? So let's let Stefano merge it all in sequence (poor Stefano though, patches seem to be piling up). - I convert m53evk, then I send you the file so that you can refactor your series and trivially rebase it on mine? I can convert it, but being lazy as hell, of course the idea of you doing all the work seems very tempting ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: mx5: Remove legacy iomux support
Dear Marek Vasut, On Friday, May 3, 2013 2:42:04 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 4:38:43 AM, Marek Vasut wrote: Dear Benoît Thébaudeau, Legacy iomux support is no longer needed now that all boards have been converted to iomux-v3. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Yes, good move Reviewed-by: Marek Vasut ma...@denx.de How do you plan to handle the conversion to iomux-v3 of the not-yet-applied m53evk: - You rebase your series on mine? - I rebase my series on yours? Did you not send this stuff after m53evk? Correct. So let's let Stefano merge it all in sequence We can do that, but this will add another conversion patch that would not be needed the other way around, for something not yet applied. (poor Stefano though, patches seem to be piling up). True. - I convert m53evk, then I send you the file so that you can refactor your series and trivially rebase it on mine? I can convert it, but being lazy as hell, of course the idea of you doing all the work seems very tempting ;-) After having done all other boards, one more should be quick. ;) So I will: - Extract m53evk.c from your series. - Convert it to iomux-v3. - Send it to you. Then you will: - Update and resend your series with this file. Then Stefano will: - Apply my mx25/35/5x series. - Apply your converted m53evk series. Does it sound like a good plan to you? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: mx5: Remove legacy iomux support
Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 2:42:04 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 4:38:43 AM, Marek Vasut wrote: Dear Benoît Thébaudeau, Legacy iomux support is no longer needed now that all boards have been converted to iomux-v3. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Yes, good move Reviewed-by: Marek Vasut ma...@denx.de How do you plan to handle the conversion to iomux-v3 of the not-yet-applied m53evk: - You rebase your series on mine? - I rebase my series on yours? Did you not send this stuff after m53evk? Correct. So let's let Stefano merge it all in sequence We can do that, but this will add another conversion patch that would not be needed the other way around, for something not yet applied. (poor Stefano though, patches seem to be piling up). True. - I convert m53evk, then I send you the file so that you can refactor your series and trivially rebase it on mine? I can convert it, but being lazy as hell, of course the idea of you doing all the work seems very tempting ;-) After having done all other boards, one more should be quick. ;) So I will: - Extract m53evk.c from your series. - Convert it to iomux-v3. - Send it to you. Then you will: - Update and resend your series with this file. Then Stefano will: - Apply my mx25/35/5x series. - Apply your converted m53evk series. Hm, I will still argument with the fact that yours was sent later and for me, this will mean another round of testing. If we swap them, I will have a good bisect point right before your series too. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: mx5: Remove legacy iomux support
Dear Marek Vasut, On Friday, May 3, 2013 3:18:33 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 2:42:04 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 4:38:43 AM, Marek Vasut wrote: Dear Benoît Thébaudeau, Legacy iomux support is no longer needed now that all boards have been converted to iomux-v3. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Yes, good move Reviewed-by: Marek Vasut ma...@denx.de How do you plan to handle the conversion to iomux-v3 of the not-yet-applied m53evk: - You rebase your series on mine? - I rebase my series on yours? Did you not send this stuff after m53evk? Correct. So let's let Stefano merge it all in sequence We can do that, but this will add another conversion patch that would not be needed the other way around, for something not yet applied. (poor Stefano though, patches seem to be piling up). True. - I convert m53evk, then I send you the file so that you can refactor your series and trivially rebase it on mine? I can convert it, but being lazy as hell, of course the idea of you doing all the work seems very tempting ;-) After having done all other boards, one more should be quick. ;) So I will: - Extract m53evk.c from your series. - Convert it to iomux-v3. - Send it to you. Then you will: - Update and resend your series with this file. Then Stefano will: - Apply my mx25/35/5x series. - Apply your converted m53evk series. Hm, I will still argument with the fact that yours was sent later and for me, this will mean another round of testing. If we swap them, I will have a good bisect point right before your series too. OK, then I will just send a standalone patch converting m53evk to iomux-v3, and I will tell Stefano where to insert it in my mx5x iomux series, or he can also choose to merge it to your series as a fixup patch, depending on the order he prefers to apply things. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] P1022DS: Set CONFIG_SPL_MAX_SIZE directly
With the u-boot-with-spl.bin rule calling $(OBJCOPY) with CONFIG_SPL_PAD_TO, and CONFIG_SPL_PAD_TO defaulting to CONFIG_SPL_MAX_SIZE we cannot use math here, so set it to 4096 rather than 4 * 1024. Signed-off-by: Tom Rini tr...@ti.com --- include/configs/P1022DS.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h index b282e7b..8b13b10 100644 --- a/include/configs/P1022DS.h +++ b/include/configs/P1022DS.h @@ -47,7 +47,7 @@ #define CONFIG_SYS_TEXT_BASE 0x00201000 #define CONFIG_SPL_TEXT_BASE 0xf000 -#define CONFIG_SPL_MAX_SIZE(4 * 1024) +#define CONFIG_SPL_MAX_SIZE4096 #define CONFIG_SPL_RELOC_TEXT_BASE 0x0010 #define CONFIG_SPL_RELOC_STACK 0x0010 #define CONFIG_SYS_NAND_U_BOOT_SIZE((512 10) + CONFIG_SPL_MAX_SIZE) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
On Thu, May 02, 2013 at 06:15:46PM -0500, Andy Fleming wrote: The following changes since commit 63216de13488e8bc81afb53d0f5177142ee34ceb: omap5_uevm: Enable redundant MMC environment (2013-05-01 16:41:10 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to 9e186857c7f99600808b8ecb2fc0fa2adeddebaa: powerpc/85xx: set USB2 default mode to 'device' for (super)hydra boards (2013-05-02 16:57:34 -0500) Apologies for the long absense. I got buried in large amounts of work. This is not all of the outstanding 85xx patches, but I intend to now switch and apply a bunch of my MMC backlog. Cristian Sovaiala (1): powerpc/mpc85xx: Changed LIODN offset values dongsheng.w...@freescale.com (1): powerpc/mpc85xx: add setting of clock-frequency for mpic node Horst Kronstorfer (1): mpc85xx: Fix a compiler warning when CONFIG_WATCHDOG is turned on Jeffrey Ladouceur (1): powerpc/mpc85xx: Add revision properties in portal device tree node 'pme' Jiang Bin (1): board/freescale/common/cds_pci_ft.c: Fix rotate wrong cells in interrupt-map property Liu Gang (2): powerpc/b4: Fix the wrong register offset of B4 PCIE module powerpc/b4860qds: Add the tlb entries for SRIO interfaces Matthew McClintock (1): powerpc/p1022ds: Add support for NAND and NAND boot using SPL Poonam Aggrwal (1): doc/ramboot.mpc85xx: Documented the RAMBOOT for MPC85xx Prabhakar Kushwaha (1): powerpc/mpc85xx:IFC Errata A003399 is not valid for BSC913x Shaohui Xie (1): powerpc/85xx: set USB2 default mode to 'device' for (super)hydra boards Shengzhou Liu (3): powerpc/b4860: Adding workaround errata A-005871 powerpc/p1010rdb: Change flexcan compatible string powerpc/p1010rdb: add readme document for p1010rdb Tang Yuantian (1): powerpc/mpc85xx: set clock-frequency for T4/B4 clockgen node Timur Tabi (1): powerpc/85xx: add SerDes bank 4 lanes Xu Jiucheng (1): powerpc/p1_p2_rdb_pc: Add a pin to reset the DDR chip for P1021RDB-PC Xulei (1): powerpc/85xx: Add workaround for errata USB-14 (enable on P204x/P3041/P50x0) York Sun (1): powerpc/mpc85xx: Extend workaround for erratum DDR_A003 to other SoCs Zang Roy-R61911 (1): fman/mEMAC: set SETSP bit in IF_MODE regisgter for RGMII speed Zhicheng Fan (1): qoriq/p1_p2_rdb_pc: USB device-tree fixups for P1020 arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 + arch/powerpc/cpu/mpc85xx/cpu.c| 18 ++- arch/powerpc/cpu/mpc85xx/cpu_init.c | 14 ++ arch/powerpc/cpu/mpc85xx/fdt.c|7 + arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c |4 + arch/powerpc/cpu/mpc85xx/p2041_ids.c | 20 +-- arch/powerpc/cpu/mpc85xx/p3041_ids.c | 20 +-- arch/powerpc/cpu/mpc85xx/p5020_ids.c | 20 +-- arch/powerpc/cpu/mpc85xx/portals.c| 20 ++- arch/powerpc/include/asm/config_mpc85xx.h | 12 +- arch/powerpc/include/asm/fsl_memac.h |4 + arch/powerpc/include/asm/immap_85xx.h | 12 +- board/freescale/b4860qds/tlb.c| 19 ++- board/freescale/common/Makefile |6 + board/freescale/common/cds_pci_ft.c | 26 +++- board/freescale/p1010rdb/p1010rdb.c |2 +- board/freescale/p1022ds/Makefile | 14 ++ board/freescale/p1022ds/law.c |1 + board/freescale/p1022ds/spl_minimal.c | 129 board/freescale/p1022ds/tlb.c | 20 ++- board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 66 +++- board/freescale/p1_p2_rdb_pc/spl_minimal.c| 15 ++ boards.cfg|2 + doc/README.p1010rdb | 199 + doc/README.ramboot-ppc85xx| 102 + drivers/net/fm/memac.c| 17 +++ include/configs/P1022DS.h | 132 ++-- include/configs/corenet_ds.h |1 + 28 files changed, 833 insertions(+), 72 deletions(-) create mode 100644 board/freescale/p1022ds/spl_minimal.c create mode 100644 doc/README.p1010rdb create mode 100644 doc/README.ramboot-ppc85xx With the patch I just sent to fix P1022DS as well, applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regression from v2013.04-rc3 with sdcard detection
Thx for the answear on this topic. I will answear when back from vacation. The card was advertised as class 10 sdcard. I know I can see others properties with some uboot *info tool I ve also tested with the release version with theses patches reverted. Nicolas (kwizart) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: mx5: Remove legacy iomux support
Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 3:18:33 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 2:42:04 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 4:38:43 AM, Marek Vasut wrote: Dear Benoît Thébaudeau, Legacy iomux support is no longer needed now that all boards have been converted to iomux-v3. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Yes, good move Reviewed-by: Marek Vasut ma...@denx.de How do you plan to handle the conversion to iomux-v3 of the not-yet-applied m53evk: - You rebase your series on mine? - I rebase my series on yours? Did you not send this stuff after m53evk? Correct. So let's let Stefano merge it all in sequence We can do that, but this will add another conversion patch that would not be needed the other way around, for something not yet applied. (poor Stefano though, patches seem to be piling up). True. - I convert m53evk, then I send you the file so that you can refactor your series and trivially rebase it on mine? I can convert it, but being lazy as hell, of course the idea of you doing all the work seems very tempting ;-) After having done all other boards, one more should be quick. ;) So I will: - Extract m53evk.c from your series. - Convert it to iomux-v3. - Send it to you. Then you will: - Update and resend your series with this file. Then Stefano will: - Apply my mx25/35/5x series. - Apply your converted m53evk series. Hm, I will still argument with the fact that yours was sent later and for me, this will mean another round of testing. If we swap them, I will have a good bisect point right before your series too. OK, then I will just send a standalone patch converting m53evk to iomux-v3, and I will tell Stefano where to insert it in my mx5x iomux series, or he can also choose to merge it to your series as a fixup patch, depending on the order he prefers to apply things. You can also just send a V2 of this single patch, no ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question: issues for usb keyboard work with OHCI HCD
Dear Bo Shen,
Hi All,
Now, I test usb host support with Atmel boards, for example,
at91sam9x5ek board.
When test OHCI USB host with usb keyboard. I meet the following issue.
---8---
U-Boot 2013.04-dirty (May 03 2013 - 11:00:34)
CPU: AT91SAM9G35
Crystal frequency: 12 MHz
CPU clock: 400 MHz
Master clock : 133.333 MHz
DRAM: 128 MiB
WARNING: Caches not enabled
NAND: 256 MiB
MMC: mci: 0
In:serial
Out: serial
Err: serial
Net: macb0
Hit any key to stop autoboot: 0
U-Boot usb start
(Re)start USB...
USB0: scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
U-Boot setenv stdin usbkbd
U-Boot ERROR: sohci_submit_job: ENOMEM
ERROR: sohci_submit_job failed
... ...
(repeat to print these two error line)
So the USB subsystem is leaking memory? Or do you only have too small MALLOC
area?
---8---
After dig the usb ohci-hcd.c driver, I found every time it call
submit_int_msg --
submit_common_msg -- sohci_submit_job, it will allocate memory for td
(just call td_alloc),
however nowhere free the td. So, after allocate 64 times (#define NUM_TD
64),
all the ptd[i].usb_dev is not NULL. So, it will report: ENOMEM.
I don't know why in sohci_return_job it call td_submit_job again?
---8---
static inline int sohci_return_job(struct ohci *hc, urb_priv_t *urb)
{
struct ohci_regs *regs = hc-regs;
switch (usb_pipetype(urb-pipe)) {
case PIPE_INTERRUPT:
/* implicitly requeued */
if (urb-dev-irq_handle
(urb-dev-irq_act_len = urb-actual_length)) {
ohci_writel(OHCI_INTR_WDH, regs-intrenable);
ohci_readl(regs-intrenable); /* PCI posting flush */
urb-dev-irq_handle(urb-dev);
ohci_writel(OHCI_INTR_WDH, regs-intrdisable);
ohci_readl(regs-intrdisable); /* PCI posting flush */
}
urb-actual_length = 0;
td_submit_job(
urb-dev,
urb-pipe,
urb-transfer_buffer,
urb-transfer_buffer_length,
NULL,
urb,
urb-interval);
break
---8---
Add where should we free the allocated td to fix the issue?
Thanks.
Best Regards,
Bo Shen
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: mx5: Remove legacy iomux support
Dear Marek Vasut, On Friday, May 3, 2013 3:39:39 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 3:18:33 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 2:42:04 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 4:38:43 AM, Marek Vasut wrote: Dear Benoît Thébaudeau, Legacy iomux support is no longer needed now that all boards have been converted to iomux-v3. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Yes, good move Reviewed-by: Marek Vasut ma...@denx.de How do you plan to handle the conversion to iomux-v3 of the not-yet-applied m53evk: - You rebase your series on mine? - I rebase my series on yours? Did you not send this stuff after m53evk? Correct. So let's let Stefano merge it all in sequence We can do that, but this will add another conversion patch that would not be needed the other way around, for something not yet applied. (poor Stefano though, patches seem to be piling up). True. - I convert m53evk, then I send you the file so that you can refactor your series and trivially rebase it on mine? I can convert it, but being lazy as hell, of course the idea of you doing all the work seems very tempting ;-) After having done all other boards, one more should be quick. ;) So I will: - Extract m53evk.c from your series. - Convert it to iomux-v3. - Send it to you. Then you will: - Update and resend your series with this file. Then Stefano will: - Apply my mx25/35/5x series. - Apply your converted m53evk series. Hm, I will still argument with the fact that yours was sent later and for me, this will mean another round of testing. If we swap them, I will have a good bisect point right before your series too. OK, then I will just send a standalone patch converting m53evk to iomux-v3, and I will tell Stefano where to insert it in my mx5x iomux series, or he can also choose to merge it to your series as a fixup patch, depending on the order he prefers to apply things. You can also just send a V2 of this single patch, no ? But there is no V1!? Or I could just send a V3 concatenating all my iomux series (there are dependencies among those series) and rebasing them on top of yours in order to make things easier and clearer for Stefano. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: mx5: Remove legacy iomux support
Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 3:39:39 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 3:18:33 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 2:42:04 PM, Marek Vasut wrote: Dear Benoît Thébaudeau, Dear Marek Vasut, On Friday, May 3, 2013 4:38:43 AM, Marek Vasut wrote: Dear Benoît Thébaudeau, Legacy iomux support is no longer needed now that all boards have been converted to iomux-v3. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Yes, good move Reviewed-by: Marek Vasut ma...@denx.de How do you plan to handle the conversion to iomux-v3 of the not-yet-applied m53evk: - You rebase your series on mine? - I rebase my series on yours? Did you not send this stuff after m53evk? Correct. So let's let Stefano merge it all in sequence We can do that, but this will add another conversion patch that would not be needed the other way around, for something not yet applied. (poor Stefano though, patches seem to be piling up). True. - I convert m53evk, then I send you the file so that you can refactor your series and trivially rebase it on mine? I can convert it, but being lazy as hell, of course the idea of you doing all the work seems very tempting ;-) After having done all other boards, one more should be quick. ;) So I will: - Extract m53evk.c from your series. - Convert it to iomux-v3. - Send it to you. Then you will: - Update and resend your series with this file. Then Stefano will: - Apply my mx25/35/5x series. - Apply your converted m53evk series. Hm, I will still argument with the fact that yours was sent later and for me, this will mean another round of testing. If we swap them, I will have a good bisect point right before your series too. OK, then I will just send a standalone patch converting m53evk to iomux-v3, and I will tell Stefano where to insert it in my mx5x iomux series, or he can also choose to merge it to your series as a fixup patch, depending on the order he prefers to apply things. You can also just send a V2 of this single patch, no ? But there is no V1!? Or I could just send a V3 concatenating all my iomux series (there are dependencies among those series) and rebasing them on top of yours in order to make things easier and clearer for Stefano. Bah, I didn't know that. Ok, if you're up to fixing up M53EVK, send a patch that does it and let Stefano (or me?) amend it to the M53EVK patch. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/7] mx23: Make DDR initialization stable
Prior to this series running 'memtester' utility in Linux on a mx23evk always resulted in many errors during stress testing, if the kernel is loaded via U-boot. Running the same test and loading the kernel via FSL bootlets resulted on zero errors. Adjust U-boot so that it can also pass the 'memtester' stress test. After this series was applied, no more DDR errors were observed on a mx23evk. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/7] mx23: Fix pad voltage selection bit
From: Fabio Estevam fabio.este...@freescale.com On mx23 the pad voltage selection bit needs to be always '0', since '1' is a reserved value. For example: Pin 108, EMI_A06 pin voltage selection: 0= 1.8V (mDDR) or 2.5V (DDR1); 1= reserved. Fix the pad voltage definitions for the mx23 case. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Marek Vasut ma...@denx.de --- Changes since v3: - Add Marek's ack Changes since v2: - Only place PAD_3V3 inside the if/else block Changes since v1: - Newly introduced arch/arm/include/asm/arch-mxs/iomux.h |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/arch-mxs/iomux.h b/arch/arm/include/asm/arch-mxs/iomux.h index 4288715..f46895e 100644 --- a/arch/arm/include/asm/arch-mxs/iomux.h +++ b/arch/arm/include/asm/arch-mxs/iomux.h @@ -71,7 +71,11 @@ typedef u32 iomux_cfg_t; #define PAD_16MA 3 #define PAD_1V80 +#if defined CONFIG_MX28 #define PAD_3V31 +#else +#define PAD_3V30 +#endif #define PAD_NOPULL 0 #define PAD_PULLUP 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/7] mx23evk: Fix DDR pin iomux settings
From: Fabio Estevam fabio.este...@freescale.com
Change MUX_CONFIG_EMI to use the same drive strength as the bootlets code from
Freescale, which results in much better stability.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v3:
- None
Changes since v2:
- Only change the drive strength
Changes since v1:
- Only adjust MUX_CONFIG_EMI
board/freescale/mx23evk/spl_boot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx23evk/spl_boot.c
b/board/freescale/mx23evk/spl_boot.c
index b6f4e7e..fd6b3d9 100644
--- a/board/freescale/mx23evk/spl_boot.c
+++ b/board/freescale/mx23evk/spl_boot.c
@@ -26,7 +26,7 @@
#include asm/arch/sys_proto.h
#defineMUX_CONFIG_SSP1 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
-#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
/* DUART */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/7] mx23_olinuxino: Fix DDR pin iomux settings
From: Fabio Estevam fabio.este...@freescale.com
Change MUX_CONFIG_EMI to use the same drive strength as the bootlets code from
Freescale, which results in much better stability.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v3:
- None
Changes since v2:
- Only change the drive strength
Changes since v1:
- Only adjust MUX_CONFIG_EMI
board/olimex/mx23_olinuxino/spl_boot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c
b/board/olimex/mx23_olinuxino/spl_boot.c
index a96c293..e55947f 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -29,7 +29,7 @@
#include asm/arch/imx-regs.h
#include asm/arch/sys_proto.h
-#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP)
#defineMUX_CONFIG_SSP (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/7] mxs: spl_mem_init: Fix comment about start bit
From: Fabio Estevam fabio.este...@freescale.com Start bit is part of HW_DRAM_CTL8 register, so fix the comment. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v3: - None Changes since v2: - None Changes since v1: - Newly introduced as the previous patch is now splitted. arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 4950490..300da0a 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -267,7 +267,7 @@ static void mx23_mem_init(void) initialize_dram_values(); - /* Set START bit in DRAM_CTL16 */ + /* Set START bit in DRAM_CTL8 */ setbits_le32(MXS_DRAM_BASE + 0x20, 1 16); clrbits_le32(MXS_DRAM_BASE + 0x40, 1 17); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 6/7] mxs: spl_mem_init: Skip the initialization of some DRAM_CTL registers
From: Fabio Estevam fabio.este...@freescale.com
HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
FSL bootlets code.
mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as reserved.
HW_DRAM_CTL8 is setup as the last element.
So skip the initialization of these DRAM_CTL registers.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v3:
- Use continue
Changes since v2:
- None
Changes since v1:
- To avoid polluting the mx28 case, separate the function definition in mx23 and
for mx28.
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index df25535..e599f31 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -110,6 +110,7 @@ __weak void mxs_adjust_memory_params(uint32_t *dram_vals)
{
}
+#ifdef CONFIG_MX28
static void initialize_dram_values(void)
{
int i;
@@ -118,15 +119,27 @@ static void initialize_dram_values(void)
for (i = 0; i ARRAY_SIZE(dram_vals); i++)
writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+}
+#else
+static void initialize_dram_values(void)
+{
+ int i;
+
+ mxs_adjust_memory_params(dram_vals);
+
+ for (i = 0; i ARRAY_SIZE(dram_vals); i++) {
+ if ((i == 8 || i == 27 || i == 28 || i == 35))
+ continue;
+ writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+ }
-#ifdef CONFIG_MX23
/*
* Enable tRAS lockout in HW_DRAM_CTL08 ; it must be the last
* element to be set
*/
writel((1 24), MXS_DRAM_BASE + (4 * 8));
-#endif
}
+#endif
static void mxs_mem_init_clock(void)
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 7/7] mxs: spl_mem_init: Change EMI port priority
From: Fabio Estevam fabio.este...@freescale.com FSL bootlets code set the PORT_PRIORITY_ORDER field of register HW_EMI_CTRL as 0x2, which means: PORT0231 = 0x02 Priority Order: AXI0, AHB2, AHB3, AHB1 Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v3: - None Changes since v2: - None Changes since v1: - None arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index e599f31..d932950 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -287,7 +287,7 @@ static void mx23_mem_init(void) early_delay(2); /* Adjust EMI port priority. */ - clrsetbits_le32(0x8002, 0x1f 16, 0x8); + clrsetbits_le32(0x8002, 0x1f 16, 0x2); early_delay(2); setbits_le32(MXS_DRAM_BASE + 0x40, 1 19); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/7] mxs: spl_mem_init: Remove erroneous DDR setting
From: Fabio Estevam fabio.este...@freescale.com On mx23 there is no 'DRAM init complete' in register HW_DRAM_CTL18. Remove this erroneous setting. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v3: - None Changes since v2: - None Changes since v1: - Newly introduced as the previous patch is now splitted. arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |4 1 file changed, 4 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 300da0a..df25535 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -279,10 +279,6 @@ static void mx23_mem_init(void) setbits_le32(MXS_DRAM_BASE + 0x40, 1 19); setbits_le32(MXS_DRAM_BASE + 0x40, 1 11); - - /* Wait for bit 10 (DRAM init complete) in DRAM_CTL18 */ - while (!(readl(MXS_DRAM_BASE + 0x48) (1 10))) - ; } #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] mpc85xx: move generic corenet to cpu/mpc85xxx
This allows to use this code on non Freescale QorIQ boards. If I am
right, there are currently only Freescale boards with a QorIQ Soc that
is supported by u-boot, that's why this code was located there.
Some other code parts that currently are located in the board/freescale
directory could be moved but this is a first patch to discuss trigger
the discussion.
It was tested on P2041rdb_SPIFLASH.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
arch/powerpc/cpu/mpc85xx/Makefile| 10 --
.../powerpc/cpu/mpc85xx}/p_corenet/Makefile | 0
.../powerpc/cpu/mpc85xx}/p_corenet/law.c | 0
.../powerpc/cpu/mpc85xx}/p_corenet/pci.c | 0
.../powerpc/cpu/mpc85xx}/p_corenet/tlb.c | 20 ++--
board/freescale/common/Makefile | 15 ++-
6 files changed, 20 insertions(+), 25 deletions(-)
rename {board/freescale/common = arch/powerpc/cpu/mpc85xx}/p_corenet/Makefile
(100%)
rename {board/freescale/common = arch/powerpc/cpu/mpc85xx}/p_corenet/law.c
(100%)
rename {board/freescale/common = arch/powerpc/cpu/mpc85xx}/p_corenet/pci.c
(100%)
rename {board/freescale/common = arch/powerpc/cpu/mpc85xx}/p_corenet/tlb.c
(92%)
diff --git a/arch/powerpc/cpu/mpc85xx/Makefile
b/arch/powerpc/cpu/mpc85xx/Makefile
index 6776c85..0b76ff5 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -141,6 +141,8 @@ COBJS-$(CONFIG_PPC_B4420) += b4860_serdes.o
COBJS-$(CONFIG_PPC_B4860) += b4860_serdes.o
COBJS-$(CONFIG_BSC9132) += bsc9132_serdes.o
+SUBLIB-$(CONFIG_FSL_CORENET) += p_corenet/libp_corenet.o
+
COBJS-y+= cpu.o
COBJS-y+= cpu_init.o
COBJS-y+= cpu_init_early.o
@@ -158,12 +160,16 @@ COBJS = $(COBJS-y)
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
+SUBLIB := $(addprefix $(obj),$(SUBLIB-y))
START := $(addprefix $(obj),$(START))
all: $(obj).depend $(START) $(LIB)
-$(LIB):$(OBJS)
- $(call cmd_link_o_target, $(OBJS))
+$(LIB):$(obj).depend $(OBJS) $(SUBLIB)
+ $(call cmd_link_o_target, $(OBJS) $(SUBLIB))
+
+$(SUBLIB): $(obj).depend
+ $(MAKE) -C $(dir $(subst $(obj),,$@))
#
diff --git a/board/freescale/common/p_corenet/Makefile
b/arch/powerpc/cpu/mpc85xx/p_corenet/Makefile
similarity index 100%
rename from board/freescale/common/p_corenet/Makefile
rename to arch/powerpc/cpu/mpc85xx/p_corenet/Makefile
diff --git a/board/freescale/common/p_corenet/law.c
b/arch/powerpc/cpu/mpc85xx/p_corenet/law.c
similarity index 100%
rename from board/freescale/common/p_corenet/law.c
rename to arch/powerpc/cpu/mpc85xx/p_corenet/law.c
diff --git a/board/freescale/common/p_corenet/pci.c
b/arch/powerpc/cpu/mpc85xx/p_corenet/pci.c
similarity index 100%
rename from board/freescale/common/p_corenet/pci.c
rename to arch/powerpc/cpu/mpc85xx/p_corenet/pci.c
diff --git a/board/freescale/common/p_corenet/tlb.c
b/arch/powerpc/cpu/mpc85xx/p_corenet/tlb.c
similarity index 92%
rename from board/freescale/common/p_corenet/tlb.c
rename to arch/powerpc/cpu/mpc85xx/p_corenet/tlb.c
index e5cf208..e6204e1 100644
--- a/board/freescale/common/p_corenet/tlb.c
+++ b/arch/powerpc/cpu/mpc85xx/p_corenet/tlb.c
@@ -64,17 +64,17 @@ struct fsl_e_tlb_entry tlb_table[] = {
* SRAM is at 0xfff0, it covered the 0xf000.
*/
SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L3_ADDR, CONFIG_SYS_INIT_L3_ADDR,
- MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
- 0, 0, BOOKE_PAGESZ_1M, 1),
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 0, BOOKE_PAGESZ_1M, 1),
#elif defined(CONFIG_SRIO_PCIE_BOOT_SLAVE)
/*
* SRIO_PCIE_BOOT-SLAVE. When slave boot, the address of the
* space is at 0xfff0, it covered the 0xf000.
*/
SET_TLB_ENTRY(1, CONFIG_SYS_SRIO_PCIE_BOOT_SLAVE_ADDR,
- CONFIG_SYS_SRIO_PCIE_BOOT_SLAVE_ADDR_PHYS,
- MAS3_SX|MAS3_SW|MAS3_SR, MAS2_W|MAS2_G,
- 0, 0, BOOKE_PAGESZ_1M, 1),
+ CONFIG_SYS_SRIO_PCIE_BOOT_SLAVE_ADDR_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_W|MAS2_G,
+ 0, 0, BOOKE_PAGESZ_1M, 1),
#else
SET_TLB_ENTRY(1, 0xf000, 0xf000,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
@@ -144,8 +144,8 @@ struct fsl_e_tlb_entry tlb_table[] = {
* in cpu_init_f, so we use entry 16 for nand.
*/
SET_TLB_ENTRY(1, CONFIG_SYS_NAND_BASE, CONFIG_SYS_NAND_BASE_PHYS,
- MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
- 0, 16, BOOKE_PAGESZ_1M, 1),
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 16, BOOKE_PAGESZ_1M, 1),
#endif
#ifdef
Re: [U-Boot] [PATCH v4 1/7] mx23: Fix pad voltage selection bit
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com On mx23 the pad voltage selection bit needs to be always '0', since '1' is a reserved value. For example: Pin 108, EMI_A06 pin voltage selection: 0= 1.8V (mDDR) or 2.5V (DDR1); 1= reserved. Fix the pad voltage definitions for the mx23 case. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Marek Vasut ma...@denx.de --- Changes since v3: - Add Marek's ack Changes since v2: - Only place PAD_3V3 inside the if/else block Changes since v1: - Newly introduced arch/arm/include/asm/arch-mxs/iomux.h |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/arch-mxs/iomux.h b/arch/arm/include/asm/arch-mxs/iomux.h index 4288715..f46895e 100644 --- a/arch/arm/include/asm/arch-mxs/iomux.h +++ b/arch/arm/include/asm/arch-mxs/iomux.h @@ -71,7 +71,11 @@ typedef u32 iomux_cfg_t; #define PAD_16MA 3 #define PAD_1V8 0 +#if defined CONFIG_MX28 Uh, #if defined(CONFIG_MX28) ? #define PAD_3V3 1 +#else +#define PAD_3V3 0 +#endif #define PAD_NOPULL 0 #define PAD_PULLUP 1 Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/7] mxs: spl_mem_init: Skip the initialization of some DRAM_CTL registers
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
FSL bootlets code.
mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as reserved.
HW_DRAM_CTL8 is setup as the last element.
So skip the initialization of these DRAM_CTL registers.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v3:
- Use continue
Changes since v2:
- None
Changes since v1:
- To avoid polluting the mx28 case, separate the function definition in
mx23 and for mx28.
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index df25535..e599f31 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -110,6 +110,7 @@ __weak void mxs_adjust_memory_params(uint32_t
*dram_vals) {
}
+#ifdef CONFIG_MX28
static void initialize_dram_values(void)
{
int i;
@@ -118,15 +119,27 @@ static void initialize_dram_values(void)
for (i = 0; i ARRAY_SIZE(dram_vals); i++)
writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+}
+#else
+static void initialize_dram_values(void)
+{
+ int i;
+
+ mxs_adjust_memory_params(dram_vals);
+
+ for (i = 0; i ARRAY_SIZE(dram_vals); i++) {
I dunno if I should be bitching some more, but you have double (()) below. Some
comment just here won't hurt, but whatever.
+ if ((i == 8 || i == 27 || i == 28 || i == 35))
+ continue;
+ writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+ }
-#ifdef CONFIG_MX23
/*
* Enable tRAS lockout in HW_DRAM_CTL08 ; it must be the last
* element to be set
*/
writel((1 24), MXS_DRAM_BASE + (4 * 8));
-#endif
}
+#endif
static void mxs_mem_init_clock(void)
{
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/7] mx23_olinuxino: Fix DDR pin iomux settings
From: Fabio Estevam fabio.este...@freescale.com
Change MUX_CONFIG_EMI to use the same drive strength as the bootlets code from
Freescale, which results in much better stability.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v4:
- None
Changes since v3:
- None
Changes since v2:
- Only change the drive strength
Changes since v1:
- Only adjust MUX_CONFIG_EMI
board/olimex/mx23_olinuxino/spl_boot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c
b/board/olimex/mx23_olinuxino/spl_boot.c
index a96c293..e55947f 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -29,7 +29,7 @@
#include asm/arch/imx-regs.h
#include asm/arch/sys_proto.h
-#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP)
#defineMUX_CONFIG_SSP (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/7] mx23: Make DDR initialization stable
Prior to this series running 'memtester' utility in Linux on a mx23evk always resulted in many errors during stress testing, if the kernel is loaded via U-boot. Running the same test and loading the kernel via FSL bootlets resulted on zero errors. Adjust U-boot so that it can also pass the 'memtester' stress test. After this series was applied, no more DDR errors were observed on a mx23evk. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/7] mx23: Fix pad voltage selection bit
From: Fabio Estevam fabio.este...@freescale.com On mx23 the pad voltage selection bit needs to be always '0', since '1' is a reserved value. For example: Pin 108, EMI_A06 pin voltage selection: 0= 1.8V (mDDR) or 2.5V (DDR1); 1= reserved. Fix the pad voltage definitions for the mx23 case. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Marek Vasut ma...@denx.de --- Changes since v4: - Enclose CONFIG_MX28 with parenthesis Changes since v3: - Add Marek's ack Changes since v2: - Only place PAD_3V3 inside the if/else block Changes since v1: - Newly introduced arch/arm/include/asm/arch-mxs/iomux.h |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/arch-mxs/iomux.h b/arch/arm/include/asm/arch-mxs/iomux.h index 4288715..f46895e 100644 --- a/arch/arm/include/asm/arch-mxs/iomux.h +++ b/arch/arm/include/asm/arch-mxs/iomux.h @@ -71,7 +71,11 @@ typedef u32 iomux_cfg_t; #define PAD_16MA 3 #define PAD_1V80 +#if defined(CONFIG_MX28) #define PAD_3V31 +#else +#define PAD_3V30 +#endif #define PAD_NOPULL 0 #define PAD_PULLUP 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/7] mx23evk: Fix DDR pin iomux settings
From: Fabio Estevam fabio.este...@freescale.com
Change MUX_CONFIG_EMI to use the same drive strength as the bootlets code from
Freescale, which results in much better stability.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v4:
- None
Changes since v3:
- None
Changes since v2:
- Only change the drive strength
Changes since v1:
- Only adjust MUX_CONFIG_EMI
board/freescale/mx23evk/spl_boot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx23evk/spl_boot.c
b/board/freescale/mx23evk/spl_boot.c
index b6f4e7e..fd6b3d9 100644
--- a/board/freescale/mx23evk/spl_boot.c
+++ b/board/freescale/mx23evk/spl_boot.c
@@ -26,7 +26,7 @@
#include asm/arch/sys_proto.h
#defineMUX_CONFIG_SSP1 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
-#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP)
const iomux_cfg_t iomux_setup[] = {
/* DUART */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 4/7] mxs: spl_mem_init: Fix comment about start bit
From: Fabio Estevam fabio.este...@freescale.com Start bit is part of HW_DRAM_CTL8 register, so fix the comment. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v4: - None Changes since v3: - None Changes since v2: - None Changes since v1: - Newly introduced as the previous patch is now splitted. arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 4950490..300da0a 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -267,7 +267,7 @@ static void mx23_mem_init(void) initialize_dram_values(); - /* Set START bit in DRAM_CTL16 */ + /* Set START bit in DRAM_CTL8 */ setbits_le32(MXS_DRAM_BASE + 0x20, 1 16); clrbits_le32(MXS_DRAM_BASE + 0x40, 1 17); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 6/7] mxs: spl_mem_init: Skip the initialization of some DRAM_CTL registers
From: Fabio Estevam fabio.este...@freescale.com
HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
FSL bootlets code.
mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as reserved.
HW_DRAM_CTL8 is setup as the last element.
So skip the initialization of these DRAM_CTL registers.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v4:
- Remove double parenthesis
Changes since v3:
- Use continue
Changes since v2:
- None
Changes since v1:
- To avoid polluting the mx28 case, separate the function definition in mx23 and
for mx28.
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index df25535..e599f31 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -110,6 +110,7 @@ __weak void mxs_adjust_memory_params(uint32_t *dram_vals)
{
}
+#ifdef CONFIG_MX28
static void initialize_dram_values(void)
{
int i;
@@ -118,15 +119,27 @@ static void initialize_dram_values(void)
for (i = 0; i ARRAY_SIZE(dram_vals); i++)
writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+}
+#else
+static void initialize_dram_values(void)
+{
+ int i;
+
+ mxs_adjust_memory_params(dram_vals);
+
+ for (i = 0; i ARRAY_SIZE(dram_vals); i++) {
+ if (i == 8 || i == 27 || i == 28 || i == 35)
+ continue;
+ writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+ }
-#ifdef CONFIG_MX23
/*
* Enable tRAS lockout in HW_DRAM_CTL08 ; it must be the last
* element to be set
*/
writel((1 24), MXS_DRAM_BASE + (4 * 8));
-#endif
}
+#endif
static void mxs_mem_init_clock(void)
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 5/7] mxs: spl_mem_init: Remove erroneous DDR setting
From: Fabio Estevam fabio.este...@freescale.com On mx23 there is no 'DRAM init complete' in register HW_DRAM_CTL18. Remove this erroneous setting. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v4: - None Changes since v3: - None Changes since v2: - None Changes since v1: - Newly introduced as the previous patch is now splitted. arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |4 1 file changed, 4 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 300da0a..df25535 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -279,10 +279,6 @@ static void mx23_mem_init(void) setbits_le32(MXS_DRAM_BASE + 0x40, 1 19); setbits_le32(MXS_DRAM_BASE + 0x40, 1 11); - - /* Wait for bit 10 (DRAM init complete) in DRAM_CTL18 */ - while (!(readl(MXS_DRAM_BASE + 0x48) (1 10))) - ; } #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 7/7] mxs: spl_mem_init: Change EMI port priority
From: Fabio Estevam fabio.este...@freescale.com FSL bootlets code set the PORT_PRIORITY_ORDER field of register HW_EMI_CTRL as 0x2, which means: PORT0231 = 0x02 Priority Order: AXI0, AHB2, AHB3, AHB1 Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v4: - None Changes since v3: - None Changes since v2: - None Changes since v1: - None arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index e599f31..d932950 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -287,7 +287,7 @@ static void mx23_mem_init(void) early_delay(2); /* Adjust EMI port priority. */ - clrsetbits_le32(0x8002, 0x1f 16, 0x8); + clrsetbits_le32(0x8002, 0x1f 16, 0x2); early_delay(2); setbits_le32(MXS_DRAM_BASE + 0x40, 1 19); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: Tegra: FDT: Add USB support for T20/T30/T114
On 05/03/2013 05:07 AM, Jim Lin wrote:
On Fri, 2013-05-03 at 03:10 +0800, Stephen Warren wrote:
On 04/29/2013 03:21 AM, Jim Lin wrote:
Add DT node for USB function.
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
+/* This table has USB timing parameters for each Oscillator frequency we
+ * support. There are four sets of values:
...
+ usbparams@3 {
+ compatible = nvidia,usbparams;
+ osc-frequency = 2600;
+ params = 0x3c0 0x1a 0x00 0xc 2 0x04 0x66 0x09 0xfe 0xfde8
0xb;
+ };
None of the above should be present; this is SoC-specific information
and should be part of the USB driver itself. There's no benefit to
putting the information into DT just to parse it back out into the same
tables that the driver could have contained in the first place.
Parameters are not completely same for T20, T30, and T114.
Putting over dt file is for expanding on future chips.
The driver itself is going to need to change anything in all likelihood,
so there's no point attempting to put the parameters somewhere else to
avoid changing the driver.
Even ignoring all that, the USB DT binding for Tegra is already defined,
and does not include this information, so it must be in the driver.
...
The bindings here don't match the kernel. Please make sure they do.
This patch only touches 2 board files: Cardhu and Dalmore. Will USB
support on other boards continue to work without any DT changes?
Existing functionality can't be broken. I'd expect to see a bunch more
DT files edited here.
For T20, I only have Seaboard and Harmony platforms.
For other T20 platforms, I may blindly add USB support as you suggested,
is that okay?
Yes, please update all Tegra boards so that nothing breaks. For boards
you don't have, others can perform the testing once you've posted the
patches.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: Tegra: USB: Add driver support for Tegra30/Tegra114
On 05/03/2013 04:53 AM, Jim Lin wrote: On Fri, 2013-05-03 at 03:29 +0800, Stephen Warren wrote: On 04/29/2013 03:21 AM, Jim Lin wrote: Tegra30 and Tegra114 are compatible except 1. T30 takes 55 ms to finish Port Reset. T114 takes 50 ms. Is that 55-vs-50 some aspect of the HW specification itself, or the overall result of multiple separate delays? I ask because the statement that one piece of HW differs from another only in a delay, especially where that delay is enormous in HW terms, seem very unusual. 50 ms comes from USB 2.0 specification for root port. 55 ms comes from T30 Technical Reference Manual. OK, I see this value is indeed in the TRM, so I guess the code is OK. Overall result of multiple separate delays. That doesn't seem true though; the TRM simply documents a single 55ms delay, not a set of delays that add up to 55ms. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/7] mx23: Make DDR initialization stable
Dear Fabio Estevam, Prior to this series running 'memtester' utility in Linux on a mx23evk always resulted in many errors during stress testing, if the kernel is loaded via U-boot. Running the same test and loading the kernel via FSL bootlets resulted on zero errors. Adjust U-boot so that it can also pass the 'memtester' stress test. After this series was applied, no more DDR errors were observed on a mx23evk. Whole series Acked-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Tegra: USB: EHCI: add Tegra30 compatible support
On 04/29/2013 03:21 AM, Jim Lin wrote: Tegra114 USB EHCI is compatible with Tegra30 USB EHCI except: 1. Port Reset - Tegra30 takes 55ms, Tegra114 takes 50 ms to finish. 2. PLL parameters. Jim Lin (3): ARM: Tegra: FDT: Add USB support for T20/T30/T114 ARM: Tegra: USB: Add driver support for Tegra30/Tegra114 Tegra: Config: Enable Tegra30/Tegra114 USB function The series, Tested-by: Stephen Warren swar...@nvidia.com On both Cardhu (Tegra30) and Dalmore (Tegra114). :-) :-) Now, I can netboot with upstream U-Boot on all my boards. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: default image: use ih_size for checking data size
Dear Jonas Gorski, In message 1367581025-26740-1-git-send-email-j...@openwrt.org you wrote: Common image usage is uImage + appended rootfs, so the the uImage data No, this is not at all common usage. Actually this something you should never do. is only part of the total image. So read out and use the header's ih_size field instead of the total file size. To prevent reading over the end of the buffer, check that the image file is big enough to contain the data before calculating its checksum. Before: ~# mkimage -l dir665_fw_100NA.bin mkimage: ERROR: dir665_fw_100NA/dir665_fw_100NA.bin has corrupted data! Sorry, I don't know how you create your image files, but you must be doing something fundamentally wrong. If mkimage reports a bug here, it is probably right. If the actual payload size is different from the content of the ih_size field, then your image _is_ broken. NAK. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The aim of science is not to open the door to everlasting wisdom but to set a limit on everlasting error. - Bertolt Brecht ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] arm: mx5: Add support for DENX M53EVK
Dear Marek Vasut,
On Thursday, April 25, 2013 10:16:03 PM, Marek Vasut wrote:
Add basic support for the DENX M53EVK board. Currently supported is:
MMC (incl. booting)
NAND (incl. booting)
Ethernet, I2C, USB, SATA, RTC.
Signed-off-by: Marek Vasut ma...@denx.de
[...]
diff --git a/board/denx/m53evk/m53evk.c b/board/denx/m53evk/m53evk.c
new file mode 100644
index 000..3289f28
--- /dev/null
+++ b/board/denx/m53evk/m53evk.c
@@ -0,0 +1,408 @@
[...]
+#ifdef CONFIG_USB_EHCI_MX5
+int board_ehci_hcd_init(int port)
+{
+ if (port == 0) {
+ /* USB OTG PWRON */
+ mxc_request_iomux(MX53_PIN_GPIO_4, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_pad(MX53_PIN_GPIO_4,
+ PAD_CTL_PKE_ENABLE |
+ PAD_CTL_100K_PD |
+ PAD_CTL_DRV_HIGH
+ );
+ gpio_direction_output(IOMUX_TO_GPIO(MX53_PIN_GPIO_4), 0);
+
+ /* USB OTG Over Current */
+ mxc_request_iomux(MX53_PIN_GPIO_18, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_input(MX53_USBOH3_IPP_IND_OTG_OC_SELECT_INPUT, 1);
It looks like there is something wrong here: The last line connects OTG.OC to
EIM_D21.ALT6, but the line before sets GPIO_18 as GPIO7[13] instead of setting
EIM_D21 as OTG.OC.
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] arm: mx5: Add support for DENX M53EVK
On Friday, May 3, 2013 4:59:13 PM, Benoît Thébaudeau wrote:
Dear Marek Vasut,
On Thursday, April 25, 2013 10:16:03 PM, Marek Vasut wrote:
Add basic support for the DENX M53EVK board. Currently supported is:
MMC (incl. booting)
NAND (incl. booting)
Ethernet, I2C, USB, SATA, RTC.
Signed-off-by: Marek Vasut ma...@denx.de
[...]
diff --git a/board/denx/m53evk/m53evk.c b/board/denx/m53evk/m53evk.c
new file mode 100644
index 000..3289f28
--- /dev/null
+++ b/board/denx/m53evk/m53evk.c
@@ -0,0 +1,408 @@
[...]
+#ifdef CONFIG_USB_EHCI_MX5
+int board_ehci_hcd_init(int port)
+{
+ if (port == 0) {
+ /* USB OTG PWRON */
+ mxc_request_iomux(MX53_PIN_GPIO_4, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_pad(MX53_PIN_GPIO_4,
+ PAD_CTL_PKE_ENABLE |
+ PAD_CTL_100K_PD |
+ PAD_CTL_DRV_HIGH
And here you set PKE without PUE, which means that PAD_CTL_100K_PD will have no
effect on the pad, i.e. the keeper will be enabled, not a 100-k PD.
+ );
+ gpio_direction_output(IOMUX_TO_GPIO(MX53_PIN_GPIO_4), 0);
+
+ /* USB OTG Over Current */
+ mxc_request_iomux(MX53_PIN_GPIO_18, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_input(MX53_USBOH3_IPP_IND_OTG_OC_SELECT_INPUT, 1);
It looks like there is something wrong here: The last line connects OTG.OC to
EIM_D21.ALT6, but the line before sets GPIO_18 as GPIO7[13] instead of
setting
EIM_D21 as OTG.OC.
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: default image: use ih_size for checking data size
On Fri, 03 May 2013 17:04:44 +0200
Wolfgang Denk w...@denx.de wrote:
Dear Jonas Gorski,
In message 1367581025-26740-1-git-send-email-j...@openwrt.org you
wrote:
Common image usage is uImage + appended rootfs, so the the uImage
data
No, this is not at all common usage. Actually this something you
should never do.
is only part of the total image. So read out and use the header's
ih_size field instead of the total file size.
To prevent reading over the end of the buffer, check that the image
file is big enough to contain the data before calculating its
checksum.
Before:
~# mkimage -l dir665_fw_100NA.bin
mkimage: ERROR: dir665_fw_100NA/dir665_fw_100NA.bin has corrupted
data!
Sorry, I don't know how you create your image files, but you must be
doing something fundamentally wrong. If mkimage reports a bug here,
it is probably right. If the actual payload size is different from
the content of the ih_size field, then your image _is_ broken.
That what else for is the ih_size field then except to say what the
actual datasize is? mkuimage also sets this fields to the
correct size.
And this isn't from me, but this is how most firmware images are
created for devices using U-Boot, i.e. uImage packed kernel + appended
rootfs. Also U-Boot itself only cares for the first ih_size bytes of the
image and not for any garbage that might be behind it:
int image_check_dcrc(const image_header_t *hdr)
{
...
ulong len = image_get_data_size(hdr);
...
ulong dcrc = crc32_wd(...,len,...);
...
}
static inline uint32_t image_get_data_size(const image_header_t *hdr)
{
return image_get_size(hdr); /* == hdr-ih_size */
}
It checks the crc of the first ih_size bytes after the image_header -
and my change changes mkimage to mirror that behaviour.
It still reports data errors if the checksum is wrong for the data
actually specified by the image header, but now it actually respects
the length of the data field.
One might even argue that it is now *more* correct, because I can
can easily construct you an image that will pass the old mkimage, but
will be rejected by U-Boot, by creating a different length payload
that has the same crc32 as expected by the header.
Best regards
Jonas Gorski
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx23: Add a README file
From: Fabio Estevam fabio.este...@freescale.com
Provide instructions on how to build U-boot and flash the binary into an SD card
for a mx23 based platform.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
doc/README.mx23_common | 145
1 file changed, 145 insertions(+)
create mode 100644 doc/README.mx23_common
diff --git a/doc/README.mx23_common b/doc/README.mx23_common
new file mode 100644
index 000..dcf0ba4
--- /dev/null
+++ b/doc/README.mx23_common
@@ -0,0 +1,145 @@
+Booting U-boot on a MX23 processor
+==
+
+This document describes the MX23 U-Boot port. This document mostly
+covers topics related to making the module/board bootable.
+
+Terminology
+---
+
+The dollar symbol ($) introduces a snipped of shell code. This shall be typed
+into the unix command prompt in U-Boot source code root directory.
+
+The (=) introduces a snipped of code that should by typed into U-Boot command
+prompt
+
+Contents
+
+
+1) Prerequisites
+2) Compiling U-Boot for a MX23 based board
+3) Installation of U-Boot for a MX23 based board to SD card
+
+1) Prerequisites
+
+
+To make a MX23 based board bootable, some tools are necessary. The first one
+is the elftosb tool distributed by Freescale Semiconductor. The other one
+is the mxsboot tool found in U-Boot source tree.
+
+Firstly, obtain the elftosb archive from the following location:
+
+ ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz
+
+We use a $VER variable here to denote the current version. At the time of
+writing of this document, that is 10.12.01. To obtain the file from command
+line, use:
+
+ $ VER=10.12.01
+ $ wget ftp://ftp.denx.de/pub/tools/elftosb-${VER}.tar.gz
+
+Extract the file:
+
+ $ tar xzf elftosb-${VER}.tar.gz
+
+Compile the file. We need to manually tell the linker to use also libm:
+
+ $ cd elftosb-${VER}/
+ $ make LIBS=-lstdc++ -lm elftosb
+
+Optionally, remove debugging symbols from elftosb:
+
+ $ strip bld/linux/elftosb
+
+Finally, install the elftosb binary. The install target is missing, so just
+copy the binary by hand:
+
+ $ sudo cp bld/linux/elftosb /usr/local/bin/
+
+Make sure the elftosb binary can be found in your $PATH, in this case this
+means /usr/local/bin/ has to be in your $PATH.
+
+2) Compiling U-Boot for a MX23 based board
+---
+
+Compiling the U-Boot for a MX23 board is straightforward and done as compiling
U-Boot
+for any other ARM device. For cross-compiler setup, please refer to ELDK5.0
+documentation. First, clean up the source code:
+
+ $ make mrproper
+
+Next, configure U-Boot for a MX23 based board
+
+ $ make mx23_based_board_name_config
+
+Examples:
+
+1. For building U-boot for Freescale MX23EVK board:
+
+ $ make mx23evk_config
+
+2. For building U-boot for Olimex MX23 Olinuxino board:
+
+ $ make mx23_olinuxino_config
+
+Lastly, compile U-Boot and prepare a BootStream. The BootStream is a
special
+type of file, which the i.MX23 CPU can boot. This is handled by the following
+command:
+
+ $ make u-boot.sb
+
+HINT: To speed-up the build process, you can add -jN, where N is number of
+ compiler instances that'll run in parallel.
+
+The code produces u-boot.sb file. This file needs to be augmented with a
+proper header to allow successful boot from SD or NAND. Adding the header is
+discussed in the following chapters.
+
+3) Installation of U-Boot for a MX23 based board to SD card
+---
+
+To boot a MX23 based board from a SD connected to SSP1 or SSP2, set the boot
+mode DIP switches according to i.MX23 manual section 35.1.2 (Table 35-3).
+
+An SD card the i.MX23 CPU can use to boot U-Boot must contain a DOS partition
+table, which in turn carries a partition of special type and which contains a
+special header. The rest of partitions in the DOS partition table can be used
+by the user.
+
+To prepare such partition, use your favourite partitioning tool. The partition
+must have the following parameters:
+
+ * Start sector .. sector 2048
+ * Partition size at least 1024 kb
+ * Partition type 0x53 (sometimes OnTrack DM6 Aux3)
+
+For example in Linux fdisk, the sequence for a clear card follows. Be sure to
+run fdisk with the option -u=sectors to set units to sectors:
+
+ * o . create a clear partition table
+ * n . create new partition
+ * p . primary partition
+ * 1 . first partition
+ * 2048 .. first sector is 2048
+ * +1M ... make the partition 1Mb big
+ * t 1 ... change first partition ID
+ * 53 change the ID to 0x53 (OnTrack DM6 Aux3)
+ * create other partitions
+ *
Re: [U-Boot] [PATCH] tools: default image: use ih_size for checking data size
Dear Jonas Gorski, In message 20130503174205.0070@unknown you wrote: Sorry, I don't know how you create your image files, but you must be doing something fundamentally wrong. If mkimage reports a bug here, it is probably right. If the actual payload size is different from the content of the ih_size field, then your image _is_ broken. That what else for is the ih_size field then except to say what the actual datasize is? mkuimage also sets this fields to the correct size. It's exactly for this very purpose, and allows for consistency checking. You run into errors, becuase your images are not correct. For plain legacy image format (i. e. we are not talking about multi-file image format here), header size (= 64 bytes) plus the content of the ih_size field will give the total file size of the image. If this condition is not met, then your image is broken. And this isn't from me, but this is how most firmware images are Define most. created for devices using U-Boot, i.e. uImage packed kernel + appended rootfs. Also U-Boot itself only cares for the first ih_size bytes of the image and not for any garbage that might be behind it: Yes, because in U-Boot we have no notion of files and thus no indication where an image ends. Otherwise such a check would be there. It checks the crc of the first ih_size bytes after the image_header - and my change changes mkimage to mirror that behaviour. But this is wrong. It still reports data errors if the checksum is wrong for the data actually specified by the image header, but now it actually respects the length of the data field. Let me repeat: a valid image will have sizeof(struct image_header) plus ih_size == file size. If this condition is not true, then your image is broken. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ...this does not mean that some of us should not want, in a rather dispassionate sort of way, to put a bullet through csh's head. - Larry Wall in 1992aug6.221512.5...@netlabs.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx23: Add a README file
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
Provide instructions on how to build U-boot and flash the binary into an SD
card for a mx23 based platform.
Can most of this not be shared with MX28 ?
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
doc/README.mx23_common | 145
1 file changed, 145
insertions(+)
create mode 100644 doc/README.mx23_common
diff --git a/doc/README.mx23_common b/doc/README.mx23_common
new file mode 100644
index 000..dcf0ba4
--- /dev/null
+++ b/doc/README.mx23_common
@@ -0,0 +1,145 @@
+Booting U-boot on a MX23 processor
+==
+
+This document describes the MX23 U-Boot port. This document mostly
+covers topics related to making the module/board bootable.
+
+Terminology
+---
+
+The dollar symbol ($) introduces a snipped of shell code. This shall be
typed +into the unix command prompt in U-Boot source code root directory.
+
+The (=) introduces a snipped of code that should by typed into U-Boot
command +prompt
+
+Contents
+
+
+1) Prerequisites
+2) Compiling U-Boot for a MX23 based board
+3) Installation of U-Boot for a MX23 based board to SD card
+
+1) Prerequisites
+
+
+To make a MX23 based board bootable, some tools are necessary. The first
one +is the elftosb tool distributed by Freescale Semiconductor. The
other one +is the mxsboot tool found in U-Boot source tree.
+
+Firstly, obtain the elftosb archive from the following location:
+
+ ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz
+
+We use a $VER variable here to denote the current version. At the time of
+writing of this document, that is 10.12.01. To obtain the file from
command +line, use:
+
+ $ VER=10.12.01
+ $ wget ftp://ftp.denx.de/pub/tools/elftosb-${VER}.tar.gz
+
+Extract the file:
+
+ $ tar xzf elftosb-${VER}.tar.gz
+
+Compile the file. We need to manually tell the linker to use also libm:
+
+ $ cd elftosb-${VER}/
+ $ make LIBS=-lstdc++ -lm elftosb
+
+Optionally, remove debugging symbols from elftosb:
+
+ $ strip bld/linux/elftosb
+
+Finally, install the elftosb binary. The install target is missing, so
just +copy the binary by hand:
+
+ $ sudo cp bld/linux/elftosb /usr/local/bin/
+
+Make sure the elftosb binary can be found in your $PATH, in this case
this +means /usr/local/bin/ has to be in your $PATH.
+
+2) Compiling U-Boot for a MX23 based board
+---
+
+Compiling the U-Boot for a MX23 board is straightforward and done as
compiling U-Boot +for any other ARM device. For cross-compiler setup,
please refer to ELDK5.0 +documentation. First, clean up the source code:
+
+ $ make mrproper
+
+Next, configure U-Boot for a MX23 based board
+
+ $ make mx23_based_board_name_config
+
+Examples:
+
+1. For building U-boot for Freescale MX23EVK board:
+
+ $ make mx23evk_config
+
+2. For building U-boot for Olimex MX23 Olinuxino board:
+
+ $ make mx23_olinuxino_config
+
+Lastly, compile U-Boot and prepare a BootStream. The BootStream is a
special +type of file, which the i.MX23 CPU can boot. This is handled by
the following +command:
+
+ $ make u-boot.sb
+
+HINT: To speed-up the build process, you can add -jN, where N is number
of + compiler instances that'll run in parallel.
+
+The code produces u-boot.sb file. This file needs to be augmented with a
+proper header to allow successful boot from SD or NAND. Adding the header
is +discussed in the following chapters.
+
+3) Installation of U-Boot for a MX23 based board to SD card
+---
+
+To boot a MX23 based board from a SD connected to SSP1 or SSP2, set the
boot +mode DIP switches according to i.MX23 manual section 35.1.2 (Table
35-3). +
+An SD card the i.MX23 CPU can use to boot U-Boot must contain a DOS
partition +table, which in turn carries a partition of special type and
which contains a +special header. The rest of partitions in the DOS
partition table can be used +by the user.
+
+To prepare such partition, use your favourite partitioning tool. The
partition +must have the following parameters:
+
+ * Start sector .. sector 2048
+ * Partition size at least 1024 kb
+ * Partition type 0x53 (sometimes OnTrack DM6 Aux3)
+
+For example in Linux fdisk, the sequence for a clear card follows. Be sure
to +run fdisk with the option -u=sectors to set units to sectors:
+
+ * o . create a clear partition table
+ * n . create new partition
+ * p . primary partition
+ * 1 . first partition
+ * 2048 .. first sector is 2048
+ * +1M ... make the partition 1Mb big
+ * t 1
Re: [U-Boot] [PATCH 04/12] imx: mx51_efikamx/sb: Convert to iomux-v3
On Friday, May 3, 2013 5:58:24 PM, Matt Sealey wrote: I had a patch queued which did exactly this, but I am fine with someone else doing it ;) Tested works exactly the same. Signed-off-by: Matt Sealey m...@genesi-usa.com You probably mean Tested-by. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx23: Add a README file
On Fri, May 3, 2013 at 12:55 PM, Marek Vasut ma...@denx.de wrote: Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com Provide instructions on how to build U-boot and flash the binary into an SD card for a mx23 based platform. Can most of this not be shared with MX28 ? Maybe to provide a README.mxs and reference it in the board specific docs. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/12] imx: mx51_efikamx/sb: Convert to iomux-v3
I had a patch queued which did exactly this, but I am fine with
someone else doing it ;)
Tested works exactly the same.
Signed-off-by: Matt Sealey m...@genesi-usa.com
On Thu, May 2, 2013 at 3:52 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
There is no change of behavior, except for older silicon revisions for which
support is removed.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
board/genesi/mx51_efikamx/efikamx-usb.c | 122
+--
1 file changed, 69 insertions(+), 53 deletions(-)
diff --git a/board/genesi/mx51_efikamx/efikamx-usb.c
b/board/genesi/mx51_efikamx/efikamx-usb.c
index cf020c3..cabad70 100644
--- a/board/genesi/mx51_efikamx/efikamx-usb.c
+++ b/board/genesi/mx51_efikamx/efikamx-usb.c
@@ -26,8 +26,7 @@
#include usb.h
#include asm/io.h
#include asm/arch/imx-regs.h
-#include asm/arch/mx5x_pins.h
-#include asm/arch/iomux.h
+#include asm/arch/iomux-mx51.h
#include asm/gpio.h
#include usb/ehci-fsl.h
#include usb/ulpi.h
@@ -35,40 +34,57 @@
#include ../../../drivers/usb/host/ehci.h
-/* USB pin configuration */
-#define USB_PAD_CONFIG (PAD_CTL_PKE_ENABLE | PAD_CTL_SRE_FAST | \
- PAD_CTL_DRV_HIGH | PAD_CTL_100K_PU | \
- PAD_CTL_HYS_ENABLE | PAD_CTL_PUE_PULL)
-
/*
* Configure the USB H1 and USB H2 IOMUX
*/
void setup_iomux_usb(void)
{
- setup_iomux_usb_h1();
-
- if (machine_is_efikasb())
- setup_iomux_usb_h2();
-
- /* USB PHY reset */
- mxc_request_iomux(MX51_PIN_EIM_D27, IOMUX_CONFIG_ALT1);
- mxc_iomux_set_pad(MX51_PIN_EIM_D27, PAD_CTL_PKE_ENABLE |
- PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH);
-
- /* USB HUB reset */
- mxc_request_iomux(MX51_PIN_GPIO1_5, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX51_PIN_GPIO1_5, PAD_CTL_PKE_ENABLE |
- PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH);
-
- /* WIFI EN (act low) */
- mxc_request_iomux(MX51_PIN_EIM_A22, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_EIM_A22, 0);
- /* WIFI RESET */
- mxc_request_iomux(MX51_PIN_EIM_A16, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_EIM_A16, 0);
- /* BT EN (act low) */
- mxc_request_iomux(MX51_PIN_EIM_A17, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_EIM_A17, 0);
+ static const iomux_v3_cfg_t usb_h1_pads[] = {
+ MX51_PAD_USBH1_CLK__USBH1_CLK,
+ MX51_PAD_USBH1_DIR__USBH1_DIR,
+ MX51_PAD_USBH1_STP__USBH1_STP,
+ MX51_PAD_USBH1_NXT__USBH1_NXT,
+ MX51_PAD_USBH1_DATA0__USBH1_DATA0,
+ MX51_PAD_USBH1_DATA1__USBH1_DATA1,
+ MX51_PAD_USBH1_DATA2__USBH1_DATA2,
+ MX51_PAD_USBH1_DATA3__USBH1_DATA3,
+ MX51_PAD_USBH1_DATA4__USBH1_DATA4,
+ MX51_PAD_USBH1_DATA5__USBH1_DATA5,
+ MX51_PAD_USBH1_DATA6__USBH1_DATA6,
+ MX51_PAD_USBH1_DATA7__USBH1_DATA7,
+ };
+
+ static const iomux_v3_cfg_t usb_pads[] = {
+ MX51_PAD_EIM_D27__GPIO2_9, /* USB PHY reset */
+ MX51_PAD_GPIO1_5__GPIO1_5, /* USB HUB reset */
+ NEW_PAD_CTRL(MX51_PAD_EIM_A22__GPIO2_16, 0), /* WIFI /EN */
+ NEW_PAD_CTRL(MX51_PAD_EIM_A16__GPIO2_10, 0), /* WIFI RESET */
+ NEW_PAD_CTRL(MX51_PAD_EIM_A17__GPIO2_11, 0), /* BT /EN */
+ };
+
+ imx_iomux_v3_setup_multiple_pads(usb_h1_pads,
ARRAY_SIZE(usb_h1_pads));
+
+ if (machine_is_efikasb()) {
+ static const iomux_v3_cfg_t usb_h2_pads[] = {
+ MX51_PAD_EIM_A24__USBH2_CLK,
+ MX51_PAD_EIM_A25__USBH2_DIR,
+ MX51_PAD_EIM_A26__USBH2_STP,
+ MX51_PAD_EIM_A27__USBH2_NXT,
+ MX51_PAD_EIM_D16__USBH2_DATA0,
+ MX51_PAD_EIM_D17__USBH2_DATA1,
+ MX51_PAD_EIM_D18__USBH2_DATA2,
+ MX51_PAD_EIM_D19__USBH2_DATA3,
+ MX51_PAD_EIM_D20__USBH2_DATA4,
+ MX51_PAD_EIM_D21__USBH2_DATA5,
+ MX51_PAD_EIM_D22__USBH2_DATA6,
+ MX51_PAD_EIM_D23__USBH2_DATA7,
+ };
+
+ imx_iomux_v3_setup_multiple_pads(usb_h2_pads,
+ARRAY_SIZE(usb_h2_pads));
+ }
+
+ imx_iomux_v3_setup_multiple_pads(usb_pads, ARRAY_SIZE(usb_pads));
}
/*
@@ -77,18 +93,18 @@ void setup_iomux_usb(void)
static void efika_usb_enable_devices(void)
{
/* Enable Bluetooth */
- gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_A17), 0);
+ gpio_direction_output(IMX_GPIO_NR(2, 11), 0);
udelay(1);
- gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_EIM_A17), 1);
+
Re: [U-Boot] [PATCH] tools: default image: use ih_size for checking data size
On Fri, 03 May 2013 17:54:25 +0200 Wolfgang Denk w...@denx.de wrote: Dear Jonas Gorski, In message 20130503174205.0070@unknown you wrote: Sorry, I don't know how you create your image files, but you must be doing something fundamentally wrong. If mkimage reports a bug here, it is probably right. If the actual payload size is different from the content of the ih_size field, then your image _is_ broken. That what else for is the ih_size field then except to say what the actual datasize is? mkuimage also sets this fields to the correct size. It's exactly for this very purpose, and allows for consistency checking. You run into errors, becuase your images are not correct. For plain legacy image format (i. e. we are not talking about multi-file image format here), header size (= 64 bytes) plus the content of the ih_size field will give the total file size of the image. If this condition is not met, then your image is broken. And this isn't from me, but this is how most firmware images are Define most. Most images I have seen for kirkwood, ar71xx, ralink, and I'm sure there are more. created for devices using U-Boot, i.e. uImage packed kernel + appended rootfs. Also U-Boot itself only cares for the first ih_size bytes of the image and not for any garbage that might be behind it: Yes, because in U-Boot we have no notion of files and thus no indication where an image ends. Otherwise such a check would be there. It checks the crc of the first ih_size bytes after the image_header - and my change changes mkimage to mirror that behaviour. But this is wrong. But that's what U-Boot does. The quoted code is taken straight from git. My impression was that if U-Boot accepts this image, then mkimage should, too. It still reports data errors if the checksum is wrong for the data actually specified by the image header, but now it actually respects the length of the data field. Let me repeat: a valid image will have sizeof(struct image_header) plus ih_size == file size. If this condition is not true, then your image is broken. Okay, after a bit of IRC discussion the following compromise: If the header is correct, and the crc is correct for the ih_size data, then assume everything is fine, but print out a warning if the file length does not match the header lengh + ih_size. My typical use case would be looking at vendor images or flashdumps and check if they have a valid uimage header. With this patch I can do it easily with the imagefile/flashdump, without it I would need to parse the header first manually, find the ih_size field, truncate the file to the expected size, and then hope the header is valid. Best regards, Jonas Gorski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] arm: mx5: Add support for DENX M53EVK
Dear Marek Vasut,
On Friday, May 3, 2013 4:59:13 PM, Benoît Thébaudeau wrote:
Dear Marek Vasut,
On Thursday, April 25, 2013 10:16:03 PM, Marek Vasut wrote:
Add basic support for the DENX M53EVK board. Currently supported is:
MMC (incl. booting)
NAND (incl. booting)
Ethernet, I2C, USB, SATA, RTC.
Signed-off-by: Marek Vasut ma...@denx.de
[...]
diff --git a/board/denx/m53evk/m53evk.c b/board/denx/m53evk/m53evk.c
new file mode 100644
index 000..3289f28
--- /dev/null
+++ b/board/denx/m53evk/m53evk.c
@@ -0,0 +1,408 @@
[...]
+#ifdef CONFIG_USB_EHCI_MX5
+int board_ehci_hcd_init(int port)
+{
+ if (port == 0) {
+ /* USB OTG PWRON */
+ mxc_request_iomux(MX53_PIN_GPIO_4, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_pad(MX53_PIN_GPIO_4,
+ PAD_CTL_PKE_ENABLE |
+ PAD_CTL_100K_PD |
+ PAD_CTL_DRV_HIGH
+ );
+ gpio_direction_output(IOMUX_TO_GPIO(MX53_PIN_GPIO_4), 0);
+
+ /* USB OTG Over Current */
+ mxc_request_iomux(MX53_PIN_GPIO_18, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_input(MX53_USBOH3_IPP_IND_OTG_OC_SELECT_INPUT, 1);
It looks like there is something wrong here: The last line connects OTG.OC to
EIM_D21.ALT6, but the line before sets GPIO_18 as GPIO7[13] instead of
setting
EIM_D21 as OTG.OC.
According to http://www.denx-cs.de/doku/?q=m53pinout , USB_OTG_OC is on ball D7
(i.e. GPIO_18), and ball V3 (i.e. EIM_D21) is not on the SoM connector.
So can you clarify what's going on with this signal? Is it handled by software
as a GPIO, and EIM_D21 is just tied high or low on the SoM to make the hardware
controller not complain about a false OC detection?
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] README: mx28_common: Keep the text within 80 columns
From: Fabio Estevam fabio.este...@freescale.com In order to improve readability keep the text within 80 columns. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- doc/README.mx28_common | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/README.mx28_common b/doc/README.mx28_common index 8bacaf8..6618908 100644 --- a/doc/README.mx28_common +++ b/doc/README.mx28_common @@ -63,9 +63,9 @@ means /usr/local/bin/ has to be in your $PATH. 2) Compiling U-Boot for a MX28 based board --- -Compiling the U-Boot for a MX28 board is straightforward and done as compiling U-Boot -for any other ARM device. For cross-compiler setup, please refer to ELDK5.0 -documentation. First, clean up the source code: +Compiling the U-Boot for a MX28 board is straightforward and done as compiling +U-Boot for any other ARM device. For cross-compiler setup, please refer to +ELDK5.0 documentation. First, clean up the source code: $ make mrproper @@ -150,8 +150,8 @@ NOTE: If the user needs to adjust the start sector, the mxsboot tool contains 4) Installation of U-Boot into NAND flash - -To boot a MX28 based board from NAND, set the boot mode DIP switches according to i.MX28 -manual chapter 12.2.1 (Table 12-2), PORT=GPMI, NAND 1.8 V. +To boot a MX28 based board from NAND, set the boot mode DIP switches according +to i.MX28 manual chapter 12.2.1 (Table 12-2), PORT=GPMI, NAND 1.8 V. There are two possibilities when preparing an image writable to NAND flash. -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] README: mx28_common: Do not hardcode the SSP port
From: Fabio Estevam fabio.este...@freescale.com MX28 can boot from SSP0 or SSP1, so it is better not to hardcode the SSP port in the instructions. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- doc/README.mx28_common |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/doc/README.mx28_common b/doc/README.mx28_common index 6618908..bd12cab 100644 --- a/doc/README.mx28_common +++ b/doc/README.mx28_common @@ -100,9 +100,7 @@ discussed in the following chapters. --- To boot a MX28 based board from SD, set the boot mode DIP switches according -to i.MX28 manual chapter 12.2.1 (Table 12-2), PORT=SSP0, SD/MMC master on -SSP0, 3.3V. - +to i.MX28 manual chapter 12.2.1 (Table 12-2). An SD card the i.MX28 CPU can use to boot U-Boot must contain a DOS partition table, which in turn carries a partition of special type and which contains a -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] README: mx28_common: Fix structure of sentence
From: Fabio Estevam fabio.este...@freescale.com Re-structure the sentence a bit so that it can clearer. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- doc/README.mx28_common |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/doc/README.mx28_common b/doc/README.mx28_common index bd12cab..c7a6839 100644 --- a/doc/README.mx28_common +++ b/doc/README.mx28_common @@ -102,10 +102,9 @@ discussed in the following chapters. To boot a MX28 based board from SD, set the boot mode DIP switches according to i.MX28 manual chapter 12.2.1 (Table 12-2). -An SD card the i.MX28 CPU can use to boot U-Boot must contain a DOS partition -table, which in turn carries a partition of special type and which contains a -special header. The rest of partitions in the DOS partition table can be used -by the user. +The SD card used to boot U-Boot must contain a DOS partition table, which in +turn carries a partition of special type and which contains a special header. +The rest of partitions in the DOS partition table can be used by the user. To prepare such partition, use your favourite partitioning tool. The partition must have the following parameters: -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] README: mxs: Introduce README.mxs
From: Fabio Estevam fabio.este...@freescale.com
Create a README.mxs file that contains instructions on how to use U-boot for
both MX23 and MX28.
As boot from NAND has only been tested on mx28, make it clear that it only
applies to MX28.
While at it, do some small cleanups for the sake of consistency:
- Use MX28 instead of i.MX28
- Use section instead of chapter when referring to specific parts of the
reference manual chapters.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
doc/README.m28 |4 +--
doc/README.mx28evk |3 +-
doc/{README.mx28_common = README.mxs} | 62 +++-
3 files changed, 40 insertions(+), 29 deletions(-)
rename doc/{README.mx28_common = README.mxs} (80%)
diff --git a/doc/README.m28 b/doc/README.m28
index 2a92226..cb3ae20 100644
--- a/doc/README.m28
+++ b/doc/README.m28
@@ -9,5 +9,5 @@ arch/arm/include/asm/arch-mxs/ - Header files for the
Freescale i.MX28
board/denx/m28evk/ - M28EVK board specific files
include/configs/m28evk.h - M28EVK configuration file
-Follow the instructions from doc/README.mx28_common to generate a bootable SD
-card or to boot from NAND flash.
+Follow the instructions from doc/README.mxs to generate a bootable SD card or
to
+boot from NAND flash.
diff --git a/doc/README.mx28evk b/doc/README.mx28evk
index 76db474..524f3fc 100644
--- a/doc/README.mx28evk
+++ b/doc/README.mx28evk
@@ -41,7 +41,6 @@ Note: The mx28evk board does not come with a NAND flash
populated from the
factory. It comes with an empty slot (U23), which allows the insertion of a
48-pin TSOP flash device.
-Follow the instructions from doc/README.mx28_common to generate a bootable SD
-card.
+Follow the instructions from doc/README.mxs to generate a bootable SD card.
Insert the SD card in slot 0, power up the board and U-boot will boot.
diff --git a/doc/README.mx28_common b/doc/README.mxs
similarity index 80%
rename from doc/README.mx28_common
rename to doc/README.mxs
index c7a6839..6d0929a 100644
--- a/doc/README.mx28_common
+++ b/doc/README.mxs
@@ -1,12 +1,15 @@
-Booting U-boot on a MX28 processor
-==
+Booting U-boot on a MXS processor
+=
-This document describes the MX28 U-Boot port. This document mostly
-covers topics related to making the module/board bootable.
+This document describes the MXS U-Boot port. This document mostly covers topics
+related to making the module/board bootable.
Terminology
---
+The term MXS refers to a family of Freescale SoCs that is composed by MX23
+and MX28.
+
The dollar symbol ($) introduces a snipped of shell code. This shall be typed
into the unix command prompt in U-Boot source code root directory.
@@ -17,16 +20,16 @@ Contents
1) Prerequisites
-2) Compiling U-Boot for a MX28 based board
-3) Installation of U-Boot for a MX28 based board to SD card
-4) Installation of U-Boot into NAND flash
+2) Compiling U-Boot for a MXS based board
+3) Installation of U-Boot for a MXS based board to SD card
+4) Installation of U-Boot into NAND flash on a MX28 based board
1) Prerequisites
-To make a MX28 based board bootable, some tools are necessary. The first one
-is the elftosb tool distributed by Freescale Semiconductor. The other one
-is the mxsboot tool found in U-Boot source tree.
+To make a MXS based board bootable, some tools are necessary. The first one is
+the elftosb tool distributed by Freescale Semiconductor. The other one is the
+mxsboot tool found in U-Boot source tree.
Firstly, obtain the elftosb archive from the following location:
@@ -60,18 +63,18 @@ copy the binary by hand:
Make sure the elftosb binary can be found in your $PATH, in this case this
means /usr/local/bin/ has to be in your $PATH.
-2) Compiling U-Boot for a MX28 based board
+2) Compiling U-Boot for a MXS based board
+-
-Compiling the U-Boot for a MX28 board is straightforward and done as compiling
+Compiling the U-Boot for a MXS board is straightforward and done as compiling
U-Boot for any other ARM device. For cross-compiler setup, please refer to
ELDK5.0 documentation. First, clean up the source code:
$ make mrproper
-Next, configure U-Boot for a MX28 based board
+Next, configure U-Boot for a MXS based board
- $ make mx28_based_board_name_config
+ $ make mxs_based_board_name_config
Examples:
@@ -83,8 +86,16 @@ Examples:
$ make mx28evk_config
+3. For building U-boot for Freescale MX23EVK board:
+
+ $ make mx23evk_config
+
+4. For building U-boot for Olimex MX23 Olinuxino board:
+
+ $ make mx23_olinuxino_config
+
Lastly, compile U-Boot and prepare a BootStream. The BootStream is a
special
-type of file, which the i.MX28 CPU can boot. This is handled by the following
+type of file, which MXS CPUs can
[U-Boot] [PATCH 6/6] m28evk: Move README file inside board directory
From: Fabio Estevam fabio.este...@freescale.com Board specific READMEs should be located inside the respective board directory. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- doc/README.m28 = board/denx/m28evk/README |0 1 file changed, 0 insertions(+), 0 deletions(-) rename doc/README.m28 = board/denx/m28evk/README (100%) diff --git a/doc/README.m28 b/board/denx/m28evk/README similarity index 100% rename from doc/README.m28 rename to board/denx/m28evk/README -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] mx28evk: Move README file inside board directory
From: Fabio Estevam fabio.este...@freescale.com Board specific READMEs should be located inside the respective board directory. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- .../freescale/mx28evk/README |0 1 file changed, 0 insertions(+), 0 deletions(-) rename doc/README.mx28evk = board/freescale/mx28evk/README (100%) diff --git a/doc/README.mx28evk b/board/freescale/mx28evk/README similarity index 100% rename from doc/README.mx28evk rename to board/freescale/mx28evk/README -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] itest: Add bitwise and operator
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
common/cmd_itest.c|4
doc/README.commands.itest | 10 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/common/cmd_itest.c b/common/cmd_itest.c
index 2c8e5d0..0629b09 100644
--- a/common/cmd_itest.c
+++ b/common/cmd_itest.c
@@ -38,6 +38,7 @@
#define GT 3
#define LE 4
#define GE 5
+#define AND6
struct op_tbl_s {
char*op;/* operator string */
@@ -60,6 +61,8 @@ static const op_tbl_t op_table [] = {
{ = , GE },
{ -le, LE },
{ = , LE },
+ { -and, AND },
+ { , AND },
};
static long evalexp(char *s, int w)
@@ -126,6 +129,7 @@ static int arithcomp (char *s, char *t, int op, int w)
case GT: return (l r);
case LE: return (l = r);
case GE: return (l = r);
+ case AND: return (l r);
}
return (0);
}
diff --git a/doc/README.commands.itest b/doc/README.commands.itest
index 5e0fe86..0058155 100644
--- a/doc/README.commands.itest
+++ b/doc/README.commands.itest
@@ -2,7 +2,7 @@ A slow day today so here is a revised itest command with
provisional
support for comparing strings as well :-))
Now table driven to allow the operators
--eq, -ne, -lt, -gt, -le, -ge, ==, !=, , , , =, =
+-eq, -ne, -lt, -gt, -le, -ge, -and, ==, !=, , , , =, =,
Uses the expected command modifier for integer compares of width 1, 2 or
4 bytes of .b, .w, .l and the new modifer of .s for a string compare.
@@ -14,3 +14,11 @@ if itest.l *4 == 12345678 then;
if itest.w *4 != 1234 then;
if itest.b *4 = 12 then;
if itest.s *4 -eq hello then;
+
+Note that (-and) operator only operates on integers and
+that the '' will need to be quoted.
+
+e.g.:
+ if itest.l 0x80 '' *0x020D8044 then; ...
+or
+ if itest.l 0x80 -and *0x020D8044 then; ...
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] itest: Add bitwise and operator
Dear Eric Nelson, In message 1367606863-14846-1-git-send-email-eric.nel...@boundarydevices.com you wrote: Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- common/cmd_itest.c|4 doc/README.commands.itest | 10 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/common/cmd_itest.c b/common/cmd_itest.c index 2c8e5d0..0629b09 100644 --- a/common/cmd_itest.c +++ b/common/cmd_itest.c @@ -38,6 +38,7 @@ #define GT 3 #define LE 4 #define GE 5 +#define AND 6 It does not make much sense to me to add AND, when you not also add OR (and eventually XOR). Also, now the help message is no longer correct - it says: 189 U_BOOT_CMD( 190 itest, 4, 0, do_itest, 191 return true/false on integer compare, 192 [.b, .w, .l, .s] [*]value1 op [*]value2 193 ); but we no longer compare... Hm, re-reading this I think this is the wrong approach. This stuff does not belong into the itest command which really is for comparing, and NOT for operations on the arguments. If you need operations, then please use setexpr - which already has all of this, and more. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Pardon me for breathing, which I never do anyway so I don't know why I bother to say it, oh God, I'm so depressed. Here's another of those self-satisfied doors. Life! Don't talk to me about life. - Marvin the Paranoid Android ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: default image: use ih_size for checking data size
Dear Jonas Gorski, In message 20130503183128.0900@unknown you wrote: And this isn't from me, but this is how most firmware images are Define most. Most images I have seen for kirkwood, ar71xx, ralink, and I'm sure there are more. Maybe these do - but these are a tiny, virtually invisible minority of the platforms supported in mainline. Yes, because in U-Boot we have no notion of files and thus no indication where an image ends. Otherwise such a check would be there. It checks the crc of the first ih_size bytes after the image_header - and my change changes mkimage to mirror that behaviour. But this is wrong. But that's what U-Boot does. The quoted code is taken straight from git. My impression was that if U-Boot accepts this image, then mkimage should, too. I explained this before: in U-Boot we have no way to figure out the total size (or file size) as there is no such concept as files. For U-Boot, an image is only identified by it's start address in memory, but we have no length information available, so how could we check it? Okay, after a bit of IRC discussion the following compromise: If the header is correct, and the crc is correct for the ih_size data, then assume everything is fine, but print out a warning if the file length does not match the header lengh + ih_size. No, this was not exactly what we discussed. I wrote: | I suggest you change mkimage such that it will display the (valid) | image data, but then bail out with a NNN bytes excess data present | error message. Note that mkimage must return an error code (EFAILURE) | in this case. So no warning, but an error, please. And only for excess lenght. If the length is too short, we are really in trouble, especially if the CRC still matches. This should never happen. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If there was anything that depressed him more than his own cynicism, it was that quite often it still wasn't as cynical as real life. - Terry Pratchett, _Guards! Guards!_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] itest: Add bitwise and operator
Hi Wolfgang, On 05/03/2013 12:08 PM, Wolfgang Denk wrote: Dear Eric Nelson, In message 1367606863-14846-1-git-send-email-eric.nel...@boundarydevices.com you wrote: Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- common/cmd_itest.c|4 doc/README.commands.itest | 10 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/common/cmd_itest.c b/common/cmd_itest.c index 2c8e5d0..0629b09 100644 --- a/common/cmd_itest.c +++ b/common/cmd_itest.c @@ -38,6 +38,7 @@ #define GT3 #define LE4 #define GE5 +#define AND6 It does not make much sense to me to add AND, when you not also add OR (and eventually XOR). I only needed to test a bit. Also, now the help message is no longer correct - it says: 189 U_BOOT_CMD( 190 itest, 4, 0, do_itest, 191 return true/false on integer compare, 192 [.b, .w, .l, .s] [*]value1 op [*]value2 193 ); but we no longer compare... Hm, re-reading this I think this is the wrong approach. This stuff does not belong into the itest command which really is for comparing, and NOT for operations on the arguments. If you need operations, then please use setexpr - which already has all of this, and more. As always, thanks for the guidance. I hadn't noticed that setexpr supported indirection. In case this helps someone else, I was looking for a way to detect Android recovery mode, which is flagged by bit seven in the SRC_GPR10 register (address 0x020d8044). And setexpr can be used like so: U-Boot md.l 0x020d8044 020d8044: 0080 U-Boot setexpr rval *0x020D8044 \ 0x80 U-Boot print rval rval=80 U-Boot setexpr rval *0x020D8044 \ 0x40 U-Boot print rval rval=0 Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] FPGA cleanup + zynq support
On Fri, May 03, 2013 at 09:14:07AM +0200, Michal Simek wrote:
Fpga code is pretty old and none has tried to clean it up.
My attempt is related to new code I want to push to mainline
which is add support for checking bitstream and if bitstream
is valid for the selected device.
For this I need to do cleanup code and move code
from cmd_fpga.c to fpga.c in driver folder.
Zynq driver:
Depends on previous zynq patches sent some days ago.
Tested by:
set fload tftp \${addr} fpga.bin\;fpga info 0\;fpga load 0 \${addr}
\${filesize}
set floadb tftp \${addr} download.bit\;fpga info 0\;fpga loadb 0 \${addr}
\${filesize}
set addr 1000
run fload
run floadb
set addr 1001
run fload
run floadb
set addr 1002
run fload
run floadb
set addr 1003
run fload
run floadb
Thanks for your comments,
Michal
Changes in v3:
For the series:
Reviewed-by: Tom Rini tr...@ti.com
Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] README: mxs: Introduce README.mxs
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
Create a README.mxs file that contains instructions on how to use U-boot
for both MX23 and MX28.
As boot from NAND has only been tested on mx28, make it clear that it only
applies to MX28.
While at it, do some small cleanups for the sake of consistency:
- Use MX28 instead of i.MX28
- Use section instead of chapter when referring to specific parts of
the reference manual chapters.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
doc/README.m28 |4 +--
doc/README.mx28evk |3 +-
doc/{README.mx28_common = README.mxs} | 62
+++- 3 files changed, 40 insertions(+), 29
deletions(-)
rename doc/{README.mx28_common = README.mxs} (80%)
diff --git a/doc/README.m28 b/doc/README.m28
index 2a92226..cb3ae20 100644
--- a/doc/README.m28
+++ b/doc/README.m28
@@ -9,5 +9,5 @@ arch/arm/include/asm/arch-mxs/- Header files for the
Freescale i.MX28 board/denx/m28evk/ - M28EVK board specific files
include/configs/m28evk.h - M28EVK configuration file
-Follow the instructions from doc/README.mx28_common to generate a bootable
SD -card or to boot from NAND flash.
+Follow the instructions from doc/README.mxs to generate a bootable SD card
or to +boot from NAND flash.
diff --git a/doc/README.mx28evk b/doc/README.mx28evk
index 76db474..524f3fc 100644
--- a/doc/README.mx28evk
+++ b/doc/README.mx28evk
@@ -41,7 +41,6 @@ Note: The mx28evk board does not come with a NAND flash
populated from the factory. It comes with an empty slot (U23), which
allows the insertion of a 48-pin TSOP flash device.
-Follow the instructions from doc/README.mx28_common to generate a bootable
SD -card.
+Follow the instructions from doc/README.mxs to generate a bootable SD
card.
Insert the SD card in slot 0, power up the board and U-boot will boot.
diff --git a/doc/README.mx28_common b/doc/README.mxs
similarity index 80%
rename from doc/README.mx28_common
rename to doc/README.mxs
index c7a6839..6d0929a 100644
--- a/doc/README.mx28_common
+++ b/doc/README.mxs
@@ -1,12 +1,15 @@
-Booting U-boot on a MX28 processor
-==
+Booting U-boot on a MXS processor
i.MX23 / i.MX28 instead of MXS ? MXS is no processor, maybe processor family?
[...]
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] README: mx28_common: Do not hardcode the SSP port
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com MX28 can boot from SSP0 or SSP1, so it is better not to hardcode the SSP port in the instructions. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- doc/README.mx28_common |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/doc/README.mx28_common b/doc/README.mx28_common index 6618908..bd12cab 100644 --- a/doc/README.mx28_common +++ b/doc/README.mx28_common @@ -100,9 +100,7 @@ discussed in the following chapters. --- To boot a MX28 based board from SD, set the boot mode DIP switches according -to i.MX28 manual chapter 12.2.1 (Table 12-2), PORT=SSP0, SD/MMC master on -SSP0, 3.3V. - +to i.MX28 manual chapter 12.2.1 (Table 12-2). Make sure to leave the 3V3 thing there. PORT=SSPn would be a better solution here too. An SD card the i.MX28 CPU can use to boot U-Boot must contain a DOS partition table, which in turn carries a partition of special type and which contains a Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] m28evk: Move README file inside board directory
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com Board specific READMEs should be located inside the respective board directory. Where did you find this rule? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] arm: mx5: Add support for DENX M53EVK
Dear Benoît Thébaudeau,
Dear Marek Vasut,
On Friday, May 3, 2013 4:59:13 PM, Benoît Thébaudeau wrote:
Dear Marek Vasut,
On Thursday, April 25, 2013 10:16:03 PM, Marek Vasut wrote:
Add basic support for the DENX M53EVK board. Currently supported is:
MMC (incl. booting)
NAND (incl. booting)
Ethernet, I2C, USB, SATA, RTC.
Signed-off-by: Marek Vasut ma...@denx.de
[...]
diff --git a/board/denx/m53evk/m53evk.c b/board/denx/m53evk/m53evk.c
new file mode 100644
index 000..3289f28
--- /dev/null
+++ b/board/denx/m53evk/m53evk.c
@@ -0,0 +1,408 @@
[...]
+#ifdef CONFIG_USB_EHCI_MX5
+int board_ehci_hcd_init(int port)
+{
+ if (port == 0) {
+ /* USB OTG PWRON */
+ mxc_request_iomux(MX53_PIN_GPIO_4, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_pad(MX53_PIN_GPIO_4,
+ PAD_CTL_PKE_ENABLE |
+ PAD_CTL_100K_PD |
+ PAD_CTL_DRV_HIGH
+ );
+ gpio_direction_output(IOMUX_TO_GPIO(MX53_PIN_GPIO_4), 0);
+
+ /* USB OTG Over Current */
+ mxc_request_iomux(MX53_PIN_GPIO_18, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_input(MX53_USBOH3_IPP_IND_OTG_OC_SELECT_INPUT, 1);
It looks like there is something wrong here: The last line connects
OTG.OC to EIM_D21.ALT6, but the line before sets GPIO_18 as GPIO7[13]
instead of setting
EIM_D21 as OTG.OC.
According to http://www.denx-cs.de/doku/?q=m53pinout , USB_OTG_OC is on
ball D7 (i.e. GPIO_18), and ball V3 (i.e. EIM_D21) is not on the SoM
connector.
So can you clarify what's going on with this signal? Is it handled by
software as a GPIO, and EIM_D21 is just tied high or low on the SoM to
make the hardware controller not complain about a false OC detection?
Yes, the OTG OC is handled by GPIO.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] arm: mx5: Add support for DENX M53EVK
Dear Marek Vasut,
On Friday, May 3, 2013 9:56:40 PM, Marek Vasut wrote:
Dear Benoît Thébaudeau,
Dear Marek Vasut,
On Friday, May 3, 2013 4:59:13 PM, Benoît Thébaudeau wrote:
Dear Marek Vasut,
On Thursday, April 25, 2013 10:16:03 PM, Marek Vasut wrote:
Add basic support for the DENX M53EVK board. Currently supported is:
MMC (incl. booting)
NAND (incl. booting)
Ethernet, I2C, USB, SATA, RTC.
Signed-off-by: Marek Vasut ma...@denx.de
[...]
diff --git a/board/denx/m53evk/m53evk.c b/board/denx/m53evk/m53evk.c
new file mode 100644
index 000..3289f28
--- /dev/null
+++ b/board/denx/m53evk/m53evk.c
@@ -0,0 +1,408 @@
[...]
+#ifdef CONFIG_USB_EHCI_MX5
+int board_ehci_hcd_init(int port)
+{
+ if (port == 0) {
+ /* USB OTG PWRON */
+ mxc_request_iomux(MX53_PIN_GPIO_4, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_pad(MX53_PIN_GPIO_4,
+ PAD_CTL_PKE_ENABLE |
+ PAD_CTL_100K_PD |
+ PAD_CTL_DRV_HIGH
+ );
+ gpio_direction_output(IOMUX_TO_GPIO(MX53_PIN_GPIO_4),
0);
+
+ /* USB OTG Over Current */
+ mxc_request_iomux(MX53_PIN_GPIO_18, IOMUX_CONFIG_ALT1);
+
mxc_iomux_set_input(MX53_USBOH3_IPP_IND_OTG_OC_SELECT_INPUT, 1);
It looks like there is something wrong here: The last line connects
OTG.OC to EIM_D21.ALT6, but the line before sets GPIO_18 as GPIO7[13]
instead of setting
EIM_D21 as OTG.OC.
According to http://www.denx-cs.de/doku/?q=m53pinout , USB_OTG_OC is on
ball D7 (i.e. GPIO_18), and ball V3 (i.e. EIM_D21) is not on the SoM
connector.
So can you clarify what's going on with this signal? Is it handled by
software as a GPIO, and EIM_D21 is just tied high or low on the SoM to
make the hardware controller not complain about a false OC detection?
Yes, the OTG OC is handled by GPIO.
So should mxc_iomux_set_input(MX53_USBOH3_IPP_IND_OTG_OC_SELECT_INPUT, 1); be
dropped or not?
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] arm: mx5: Add support for DENX M53EVK
Dear Benoît Thébaudeau,
Dear Marek Vasut,
On Friday, May 3, 2013 9:56:40 PM, Marek Vasut wrote:
Dear Benoît Thébaudeau,
Dear Marek Vasut,
On Friday, May 3, 2013 4:59:13 PM, Benoît Thébaudeau wrote:
Dear Marek Vasut,
On Thursday, April 25, 2013 10:16:03 PM, Marek Vasut wrote:
Add basic support for the DENX M53EVK board. Currently supported
is: MMC (incl. booting)
NAND (incl. booting)
Ethernet, I2C, USB, SATA, RTC.
Signed-off-by: Marek Vasut ma...@denx.de
[...]
diff --git a/board/denx/m53evk/m53evk.c
b/board/denx/m53evk/m53evk.c new file mode 100644
index 000..3289f28
--- /dev/null
+++ b/board/denx/m53evk/m53evk.c
@@ -0,0 +1,408 @@
[...]
+#ifdef CONFIG_USB_EHCI_MX5
+int board_ehci_hcd_init(int port)
+{
+ if (port == 0) {
+ /* USB OTG PWRON */
+ mxc_request_iomux(MX53_PIN_GPIO_4, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_pad(MX53_PIN_GPIO_4,
+ PAD_CTL_PKE_ENABLE |
+ PAD_CTL_100K_PD |
+ PAD_CTL_DRV_HIGH
+ );
+ gpio_direction_output(IOMUX_TO_GPIO(MX53_PIN_GPIO_4),
0);
+
+ /* USB OTG Over Current */
+ mxc_request_iomux(MX53_PIN_GPIO_18, IOMUX_CONFIG_ALT1);
+
mxc_iomux_set_input(MX53_USBOH3_IPP_IND_OTG_OC_SELECT_INPUT, 1);
It looks like there is something wrong here: The last line connects
OTG.OC to EIM_D21.ALT6, but the line before sets GPIO_18 as GPIO7[13]
instead of setting
EIM_D21 as OTG.OC.
According to http://www.denx-cs.de/doku/?q=m53pinout , USB_OTG_OC is on
ball D7 (i.e. GPIO_18), and ball V3 (i.e. EIM_D21) is not on the SoM
connector.
So can you clarify what's going on with this signal? Is it handled by
software as a GPIO, and EIM_D21 is just tied high or low on the SoM to
make the hardware controller not complain about a false OC detection?
Yes, the OTG OC is handled by GPIO.
So should mxc_iomux_set_input(MX53_USBOH3_IPP_IND_OTG_OC_SELECT_INPUT,
1); be dropped or not?
Yes.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] m28evk: Move README file inside board directory
On Fri, May 3, 2013 at 4:54 PM, Marek Vasut ma...@denx.de wrote: Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com Board specific READMEs should be located inside the respective board directory. Where did you find this rule? Here: commit 702e6014f15b307f144fa03ecaf83a8446c6802a Author: Wolfgang Denk w...@denx.de Date: Sun Apr 29 23:57:39 2012 + doc: cleanup - move board READMEs into respective board directories Also drop a few files referring to no longer / not yet supported boards. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Stefan Roese s...@denx.de Cc: Kim Phillips kim.phill...@freescale.com Cc: Andy Fleming aflem...@gmail.com Cc: Jason Jin jason@freescale.com Cc: Stefano Babic sba...@denx.de Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com Acked-by: Stefano Babic sba...@denx.de Acked-by: Daniel Schwierzeck daniel.schwierz...@googlemail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 02/25] imx: mx25pdk: Convert to iomux-v3
There is no change of behavior, even if some pad control values could probably
be simplified.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3: None
Changes in v2: None
board/freescale/mx25pdk/mx25pdk.c | 128 ++---
1 file changed, 75 insertions(+), 53 deletions(-)
diff --git a/board/freescale/mx25pdk/mx25pdk.c
b/board/freescale/mx25pdk/mx25pdk.c
index d73e27e..421afea 100644
--- a/board/freescale/mx25pdk/mx25pdk.c
+++ b/board/freescale/mx25pdk/mx25pdk.c
@@ -21,8 +21,7 @@
#include asm/io.h
#include asm/gpio.h
#include asm/arch/imx-regs.h
-#include asm/arch/imx25-pinmux.h
-#include asm/arch/sys_proto.h
+#include asm/arch/iomux-mx25.h
#include asm/arch/clock.h
#include mmc.h
#include fsl_esdhc.h
@@ -43,29 +42,42 @@ struct fsl_esdhc_cfg esdhc_cfg[1] = {
};
#endif
+/*
+ * FIXME: need to revisit this
+ * The original code enabled PUE and 100-k pull-down without PKE, so the right
+ * value here is likely:
+ * 0 for no pull
+ * or:
+ * PAD_CTL_PUS_100K_DOWN for 100-k pull-down
+ */
+#define FEC_OUT_PAD_CTRL 0
+
+#define I2C_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PUS_100K_UP | \
+PAD_CTL_ODE)
+
static void mx25pdk_fec_init(void)
{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- u32 gpio_mux_mode = MX25_PIN_MUX_MODE(5);
- u32 gpio_mux_mode0_sion = MX25_PIN_MUX_MODE(0) | MX25_PIN_MUX_SION;
-
- /* FEC pin init is generic */
- mx25_fec_init_pins();
-
- muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
- padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
- /*
-* Set up FEC_RESET_B and FEC_ENABLE_B
-*
-* FEC_RESET_B: gpio2_3 is ALT 5 mode of pin D12
-* FEC_ENABLE_B: gpio4_8 is ALT 5 mode of pin A17
-*/
- writel(gpio_mux_mode, muxctl-pad_d12);
- writel(gpio_mux_mode, muxctl-pad_a17);
-
- writel(0x0, padctl-pad_d12);
- writel(0x0, padctl-pad_a17);
+ static const iomux_v3_cfg_t fec_pads[] = {
+ MX25_PAD_FEC_TX_CLK__FEC_TX_CLK,
+ MX25_PAD_FEC_RX_DV__FEC_RX_DV,
+ MX25_PAD_FEC_RDATA0__FEC_RDATA0,
+ NEW_PAD_CTRL(MX25_PAD_FEC_TDATA0__FEC_TDATA0, FEC_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_FEC_TX_EN__FEC_TX_EN, FEC_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_FEC_MDC__FEC_MDC, FEC_OUT_PAD_CTRL),
+ MX25_PAD_FEC_MDIO__FEC_MDIO,
+ MX25_PAD_FEC_RDATA1__FEC_RDATA1,
+ NEW_PAD_CTRL(MX25_PAD_FEC_TDATA1__FEC_TDATA1, FEC_OUT_PAD_CTRL),
+
+ NEW_PAD_CTRL(MX25_PAD_D12__GPIO_4_8, 0), /* FEC_RESET_B */
+ NEW_PAD_CTRL(MX25_PAD_A17__GPIO_2_3, 0), /* FEC_ENABLE_B */
+ };
+
+ static const iomux_v3_cfg_t i2c_pads[] = {
+ NEW_PAD_CTRL(MX25_PAD_I2C1_CLK__I2C1_CLK, I2C_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_I2C1_DAT__I2C1_DAT, I2C_PAD_CTRL),
+ };
+
+ imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));
/* Assert RESET and ENABLE low */
gpio_direction_output(FEC_RESET_B, 0);
@@ -78,10 +90,7 @@ static void mx25pdk_fec_init(void)
gpio_set_value(FEC_ENABLE_B, 1);
/* Setup I2C pins so that PMIC can turn on PHY supply */
- writel(gpio_mux_mode0_sion, muxctl-pad_i2c1_clk);
- writel(gpio_mux_mode0_sion, muxctl-pad_i2c1_dat);
- writel(0x1E8, padctl-pad_i2c1_clk);
- writel(0x1E8, padctl-pad_i2c1_dat);
+ imx_iomux_v3_setup_multiple_pads(i2c_pads, ARRAY_SIZE(i2c_pads));
}
int dram_init(void)
@@ -92,9 +101,35 @@ int dram_init(void)
return 0;
}
+/*
+ * Set up input pins with hysteresis and 100-k pull-ups
+ */
+#define UART1_IN_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PUS_100K_UP)
+/*
+ * FIXME: need to revisit this
+ * The original code enabled PUE and 100-k pull-down without PKE, so the right
+ * value here is likely:
+ * 0 for no pull
+ * or:
+ * PAD_CTL_PUS_100K_DOWN for 100-k pull-down
+ */
+#define UART1_OUT_PAD_CTRL 0
+
+static void mx25pdk_uart1_init(void)
+{
+ static const iomux_v3_cfg_t uart1_pads[] = {
+ NEW_PAD_CTRL(MX25_PAD_UART1_RXD__UART1_RXD, UART1_IN_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_UART1_TXD__UART1_TXD, UART1_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_UART1_RTS__UART1_RTS, UART1_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_UART1_CTS__UART1_CTS, UART1_IN_PAD_CTRL),
+ };
+
+ imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
+}
+
int board_early_init_f(void)
{
- mx25_uart1_init_pins();
+ mx25pdk_uart1_init();
return 0;
}
@@ -131,21 +166,8 @@ int board_late_init(void)
#ifdef CONFIG_FSL_ESDHC
int board_mmc_getcd(struct mmc *mmc)
{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- u32 gpio_mux_mode = MX25_PIN_MUX_MODE(5);
-
- /*
-
[U-Boot] [PATCH v3 03/25] imx: mx25pdk: Fix GPIO assignments
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com --- Changes in v3: None Changes in v2: None board/freescale/mx25pdk/mx25pdk.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/freescale/mx25pdk/mx25pdk.c b/board/freescale/mx25pdk/mx25pdk.c index 421afea..5e6047f 100644 --- a/board/freescale/mx25pdk/mx25pdk.c +++ b/board/freescale/mx25pdk/mx25pdk.c @@ -30,8 +30,8 @@ #include fsl_pmic.h #include mc34704.h -#define FEC_RESET_BIMX_GPIO_NR(2, 3) -#define FEC_ENABLE_B IMX_GPIO_NR(4, 8) +#define FEC_RESET_BIMX_GPIO_NR(4, 8) +#define FEC_ENABLE_B IMX_GPIO_NR(2, 3) #define CARD_DETECTIMX_GPIO_NR(2, 1) DECLARE_GLOBAL_DATA_PTR; -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 01/25] imx: iomux-v3: Add iomux-mx25.h
Allow usage of the imx-common/iomux-v3.h framework by including pad settings for
the i.MX25. The content of the file is taken from Linux kernel at commit
267dd34, plus the required changes to make it work in U-Boot.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3: None
Changes in v2:
- Fix arch/arm/imx-common/Makefile COBJS-y for mx5/6.
arch/arm/imx-common/Makefile|5 +-
arch/arm/include/asm/arch-mx25/imx-regs.h |1 +
arch/arm/include/asm/arch-mx25/iomux-mx25.h | 545 +++
3 files changed, 550 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/arch-mx25/iomux-mx25.h
diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
index 1166488..a33c193 100644
--- a/arch/arm/imx-common/Makefile
+++ b/arch/arm/imx-common/Makefile
@@ -27,8 +27,11 @@ include $(TOPDIR)/config.mk
LIB = $(obj)libimx-common.o
+ifeq ($(SOC),$(filter $(SOC),mx25 mx5 mx6))
+COBJS-y= iomux-v3.o
+endif
ifeq ($(SOC),$(filter $(SOC),mx5 mx6))
-COBJS-y= iomux-v3.o timer.o cpu.o speed.o
+COBJS-y+= timer.o cpu.o speed.o
COBJS-$(CONFIG_I2C_MXC) += i2c-mxv7.o
endif
ifeq ($(SOC),$(filter $(SOC),mx6 mxs))
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 206ac76..46f59d7 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -200,6 +200,7 @@ struct aips_regs {
#define IMX_CSPI1_BASE (0x43FA4000)
#define IMX_KPP_BASE (0x43FA8000)
#define IMX_IOPADMUX_BASE (0x43FAC000)
+#define IOMUXC_BASE_ADDR IMX_IOPADMUX_BASE
#define IMX_IOPADCTL_BASE (0x43FAC22C)
#define IMX_IOPADGRPCTL_BASE (0x43FAC418)
#define IMX_IOPADINPUTSEL_BASE (0x43FAC460)
diff --git a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
new file mode 100644
index 000..c0f5c61
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
@@ -0,0 +1,545 @@
+/*
+ * (C) Copyright 2013 ADVANSEE
+ * Benoît Thébaudeau benoit.thebaud...@advansee.com
+ *
+ * Based on mainline Linux i.MX iomux-mx25.h file:
+ * Copyright (C) 2009 by Lothar Wassmann l...@karo-electronics.de
+ *
+ * Based on Linux arch/arm/mach-mx25/mx25_pins.h:
+ * Copyright 2008 Freescale Semiconductor, Inc. All Rights Reserved.
+ * and Linux arch/arm/plat-mxc/include/mach/iomux-mx35.h:
+ * Copyright (C) 2009 by Jan Weitzel Phytec Messtechnik GmbH
armli...@phytec.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __IOMUX_MX25_H__
+#define __IOMUX_MX25_H__
+
+#include asm/imx-common/iomux-v3.h
+
+/* Pad control groupings */
+#define MX25_KPP_ROW_PAD_CTRL PAD_CTL_PUS_100K_UP
+#define MX25_KPP_COL_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_ODE)
+
+/*
+ * The naming convention for the pad modes is MX25_PAD_padname__padmode
+ * If padname or padmode refers to a GPIO, it is named GPIO_unit_num
+ * See also iomux-v3.h
+ */
+
+/* PADMUXALT
INPSE PATH PADCTRL */
+enum {
+ MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008, 0x00,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008, 0x05,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A13__A13 = IOMUX_PAD(0x22C, 0x00c, 0x00,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A13__GPIO_4_1 = IOMUX_PAD(0x22C, 0x00c, 0x05,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A14__A14 = IOMUX_PAD(0x230, 0x010, 0x10,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A14__GPIO_2_0 = IOMUX_PAD(0x230, 0x010, 0x15,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A15__A15 = IOMUX_PAD(0x234, 0x014, 0x10,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A15__GPIO_2_1 = IOMUX_PAD(0x234, 0x014, 0x15,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A16__A16 = IOMUX_PAD(0x000, 0x018, 0x10,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A16__GPIO_2_2 = IOMUX_PAD(0x000, 0x018, 0x15,
0, 0, NO_PAD_CTRL),
+
+ MX25_PAD_A17__A17 = IOMUX_PAD(0x238, 0x01c, 0x10,
0, 0,
[U-Boot] [PATCH v3 09/25] imx: mx35pdk: Fix WDOG_RST iomux function
The signal connected from this pin to the PMIC is WDOG_B, i.e. ALT0 mode, not
ALT1 (which even corresponds to nothing).
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3: None
Changes in v2: None
board/freescale/mx35pdk/mx35pdk.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx35pdk/mx35pdk.c
b/board/freescale/mx35pdk/mx35pdk.c
index b7f474e..9993d7b 100644
--- a/board/freescale/mx35pdk/mx35pdk.c
+++ b/board/freescale/mx35pdk/mx35pdk.c
@@ -263,7 +263,7 @@ int board_late_init(void)
if (pmic_detect()) {
p = pmic_get(FSL_PMIC);
mxc_request_iomux(MX35_PIN_WATCHDOG_RST, MUX_CONFIG_SION |
- MUX_CONFIG_ALT1);
+ MUX_CONFIG_FUNC);
pmic_reg_read(p, REG_SETTING_0, pmic_val);
pmic_reg_write(p, REG_SETTING_0,
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 06/25] imx: mx25: Remove legacy iomux support
Legacy iomux support is no longer needed now that all boards have been converted
to iomux-v3.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3: None
Changes in v2: None
arch/arm/cpu/arm926ejs/mx25/generic.c | 117 ---
arch/arm/include/asm/arch-mx25/imx25-pinmux.h | 421 -
arch/arm/include/asm/arch-mx25/sys_proto.h| 32 --
3 files changed, 570 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-mx25/imx25-pinmux.h
delete mode 100644 arch/arm/include/asm/arch-mx25/sys_proto.h
diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index 679273b..7cbbe65 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -27,7 +27,6 @@
#include netdev.h
#include asm/io.h
#include asm/arch/imx-regs.h
-#include asm/arch/imx25-pinmux.h
#include asm/arch/clock.h
#ifdef CONFIG_FSL_ESDHC
@@ -248,123 +247,7 @@ int cpu_mmc_init(bd_t *bis)
}
#endif
-#ifdef CONFIG_MXC_UART
-void mx25_uart1_init_pins(void)
-{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- u32 inpadctl;
- u32 outpadctl;
- u32 muxmode0;
-
- muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
- padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
- muxmode0 = MX25_PIN_MUX_MODE(0);
- /*
-* set up input pins with hysteresis and 100K pull-ups
-*/
- inpadctl = MX25_PIN_PAD_CTL_HYS
- | MX25_PIN_PAD_CTL_PKE
- | MX25_PIN_PAD_CTL_PUE | MX25_PIN_PAD_CTL_100K_PU;
-
- /*
-* set up output pins with 100K pull-downs
-* FIXME: need to revisit this
-* PUE is ignored if PKE is not set
-* so the right value here is likely
-*0x0 for no pull up/down
-* or
-*0xc0 for 100k pull down
-*/
- outpadctl = MX25_PIN_PAD_CTL_PUE | MX25_PIN_PAD_CTL_100K_PD;
-
- /* UART1 */
- /* rxd */
- writel(muxmode0, muxctl-pad_uart1_rxd);
- writel(inpadctl, padctl-pad_uart1_rxd);
-
- /* txd */
- writel(muxmode0, muxctl-pad_uart1_txd);
- writel(outpadctl, padctl-pad_uart1_txd);
-
- /* rts */
- writel(muxmode0, muxctl-pad_uart1_rts);
- writel(outpadctl, padctl-pad_uart1_rts);
-
- /* cts */
- writel(muxmode0, muxctl-pad_uart1_cts);
- writel(inpadctl, padctl-pad_uart1_cts);
-}
-#endif /* CONFIG_MXC_UART */
-
#ifdef CONFIG_FEC_MXC
-void mx25_fec_init_pins(void)
-{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- u32 inpadctl_100kpd;
- u32 inpadctl_22kpu;
- u32 outpadctl;
- u32 muxmode0;
-
- muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
- padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
- muxmode0 = MX25_PIN_MUX_MODE(0);
- inpadctl_100kpd = MX25_PIN_PAD_CTL_HYS
- | MX25_PIN_PAD_CTL_PKE
- | MX25_PIN_PAD_CTL_PUE | MX25_PIN_PAD_CTL_100K_PD;
- inpadctl_22kpu = MX25_PIN_PAD_CTL_HYS
- | MX25_PIN_PAD_CTL_PKE
- | MX25_PIN_PAD_CTL_PUE | MX25_PIN_PAD_CTL_22K_PU;
- /*
-* set up output pins with 100K pull-downs
-* FIXME: need to revisit this
-* PUE is ignored if PKE is not set
-* so the right value here is likely
-*0x0 for no pull
-* or
-*0xc0 for 100k pull down
-*/
- outpadctl = MX25_PIN_PAD_CTL_PUE | MX25_PIN_PAD_CTL_100K_PD;
-
- /* FEC_TX_CLK */
- writel(muxmode0, muxctl-pad_fec_tx_clk);
- writel(inpadctl_100kpd, padctl-pad_fec_tx_clk);
-
- /* FEC_RX_DV */
- writel(muxmode0, muxctl-pad_fec_rx_dv);
- writel(inpadctl_100kpd, padctl-pad_fec_rx_dv);
-
- /* FEC_RDATA0 */
- writel(muxmode0, muxctl-pad_fec_rdata0);
- writel(inpadctl_100kpd, padctl-pad_fec_rdata0);
-
- /* FEC_TDATA0 */
- writel(muxmode0, muxctl-pad_fec_tdata0);
- writel(outpadctl, padctl-pad_fec_tdata0);
-
- /* FEC_TX_EN */
- writel(muxmode0, muxctl-pad_fec_tx_en);
- writel(outpadctl, padctl-pad_fec_tx_en);
-
- /* FEC_MDC */
- writel(muxmode0, muxctl-pad_fec_mdc);
- writel(outpadctl, padctl-pad_fec_mdc);
-
- /* FEC_MDIO */
- writel(muxmode0, muxctl-pad_fec_mdio);
- writel(inpadctl_22kpu, padctl-pad_fec_mdio);
-
- /* FEC_RDATA1 */
- writel(muxmode0, muxctl-pad_fec_rdata1);
- writel(inpadctl_100kpd, padctl-pad_fec_rdata1);
-
- /* FEC_TDATA1 */
- writel(muxmode0, muxctl-pad_fec_tdata1);
- writel(outpadctl, padctl-pad_fec_tdata1);
-
-}
-
void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
{
int i;
diff --git a/arch/arm/include/asm/arch-mx25/imx25-pinmux.h
b/arch/arm/include/asm/arch-mx25/imx25-pinmux.h
deleted file mode 100644
index a4c658b..000
---
[U-Boot] [PATCH v3 13/25] imx: iomux-mx51: Fix MX51_PAD_EIM_CS2__GPIO2_27
In ALT1 mode, EIM_CS2 is GPIO2[27], not ESDHC1.CD. Hence, rename
MX51_PAD_EIM_CS2__SD1_CD to MX51_PAD_EIM_CS2__GPIO2_27.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3: None
Changes in v2: None
arch/arm/include/asm/arch-mx5/iomux-mx51.h |2 +-
board/genesi/mx51_efikamx/efikamx.c|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/iomux-mx51.h
b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
index 328c188..323e118 100644
--- a/arch/arm/include/asm/arch-mx5/iomux-mx51.h
+++ b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
@@ -61,7 +61,7 @@ enum {
MX51_PAD_EIM_A26__USBH2_STP = IOMUX_PAD(0x458, 0x0c4, 2,
__NA_, 0, NO_PAD_CTRL),
MX51_PAD_EIM_A27__USBH2_NXT = IOMUX_PAD(0x45c, 0x0c8, 2,
__NA_, 0, NO_PAD_CTRL),
MX51_PAD_EIM_CS0__GPIO2_25 = IOMUX_PAD(0x474, 0x0e0, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
- MX51_PAD_EIM_CS2__SD1_CD= IOMUX_PAD(0x47c, 0x0e8, 1,
__NA_, 0, MX51_ESDHC_PAD_CTRL),
+ MX51_PAD_EIM_CS2__GPIO2_27 = IOMUX_PAD(0x47c, 0x0e8, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
MX51_PAD_EIM_CS3__GPIO2_28 = IOMUX_PAD(0x480, 0x0ec, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
MX51_PAD_EIM_CS4__GPIO2_29 = IOMUX_PAD(0x484, 0x0f0, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
MX51_PAD_NANDF_WE_B__PATA_DIOW = IOMUX_PAD(0x4e4, 0x108, 1,
__NA_, 0, NO_PAD_CTRL),
diff --git a/board/genesi/mx51_efikamx/efikamx.c
b/board/genesi/mx51_efikamx/efikamx.c
index 69d41db..13582a2 100644
--- a/board/genesi/mx51_efikamx/efikamx.c
+++ b/board/genesi/mx51_efikamx/efikamx.c
@@ -293,7 +293,7 @@ static iomux_v3_cfg_t const efikamx_sdhc1_pads[] = {
static iomux_v3_cfg_t const efikamx_sdhc1_cd_pads[] = {
MX51_PAD_GPIO1_0__SD1_CD,
- MX51_PAD_EIM_CS2__SD1_CD,
+ NEW_PAD_CTRL(MX51_PAD_EIM_CS2__GPIO2_27, MX51_ESDHC_PAD_CTRL),
};
#define EFIKAMX_SDHC1_CD IMX_GPIO_NR(1, 0)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 10/25] imx: mx35pdk: Convert to iomux-v3
There is no change of behavior.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3: None
Changes in v2: None
board/freescale/mx35pdk/mx35pdk.c | 173 -
1 file changed, 74 insertions(+), 99 deletions(-)
diff --git a/board/freescale/mx35pdk/mx35pdk.c
b/board/freescale/mx35pdk/mx35pdk.c
index 9993d7b..12e84d7 100644
--- a/board/freescale/mx35pdk/mx35pdk.c
+++ b/board/freescale/mx35pdk/mx35pdk.c
@@ -28,8 +28,7 @@
#include asm/arch/imx-regs.h
#include asm/arch/crm_regs.h
#include asm/arch/clock.h
-#include asm/arch/mx35_pins.h
-#include asm/arch/iomux.h
+#include asm/arch/iomux-mx35.h
#include i2c.h
#include power/pmic.h
#include fsl_pmic.h
@@ -73,114 +72,88 @@ void dram_init_banksize(void)
gd-bd-bi_dram[1].size = PHYS_SDRAM_2_SIZE;
}
+#define I2C_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PUS_100K_DOWN | PAD_CTL_ODE)
+
static void setup_iomux_i2c(void)
{
- int pad;
+ static const iomux_v3_cfg_t i2c1_pads[] = {
+ NEW_PAD_CTRL(MX35_PAD_I2C1_CLK__I2C1_SCL, I2C_PAD_CTRL),
+ NEW_PAD_CTRL(MX35_PAD_I2C1_DAT__I2C1_SDA, I2C_PAD_CTRL),
+ };
/* setup pins for I2C1 */
- mxc_request_iomux(MX35_PIN_I2C1_CLK, MUX_CONFIG_SION);
- mxc_request_iomux(MX35_PIN_I2C1_DAT, MUX_CONFIG_SION);
-
- pad = (PAD_CTL_HYS_SCHMITZ | PAD_CTL_PKE_ENABLE \
- | PAD_CTL_PUE_PUD | PAD_CTL_ODE_OpenDrain);
-
- mxc_iomux_set_pad(MX35_PIN_I2C1_CLK, pad);
- mxc_iomux_set_pad(MX35_PIN_I2C1_DAT, pad);
+ imx_iomux_v3_setup_multiple_pads(i2c1_pads, ARRAY_SIZE(i2c1_pads));
}
static void setup_iomux_spi(void)
{
- mxc_request_iomux(MX35_PIN_CSPI1_MOSI, MUX_CONFIG_SION);
- mxc_request_iomux(MX35_PIN_CSPI1_MISO, MUX_CONFIG_SION);
- mxc_request_iomux(MX35_PIN_CSPI1_SS0, MUX_CONFIG_SION);
- mxc_request_iomux(MX35_PIN_CSPI1_SS1, MUX_CONFIG_SION);
- mxc_request_iomux(MX35_PIN_CSPI1_SCLK, MUX_CONFIG_SION);
+ static const iomux_v3_cfg_t spi_pads[] = {
+ MX35_PAD_CSPI1_MOSI__CSPI1_MOSI,
+ MX35_PAD_CSPI1_MISO__CSPI1_MISO,
+ MX35_PAD_CSPI1_SS0__CSPI1_SS0,
+ MX35_PAD_CSPI1_SS1__CSPI1_SS1,
+ MX35_PAD_CSPI1_SCLK__CSPI1_SCLK,
+ };
+
+ imx_iomux_v3_setup_multiple_pads(spi_pads, ARRAY_SIZE(spi_pads));
}
+#define USBOTG_IN_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PUS_100K_DOWN | \
+PAD_CTL_DSE_LOW | PAD_CTL_SRE_SLOW)
+#define USBOTG_OUT_PAD_CTRL(PAD_CTL_DSE_LOW | PAD_CTL_SRE_SLOW)
+
static void setup_iomux_usbotg(void)
{
- int in_pad, out_pad;
+ static const iomux_v3_cfg_t usbotg_pads[] = {
+ NEW_PAD_CTRL(MX35_PAD_USBOTG_PWR__USB_TOP_USBOTG_PWR,
+ USBOTG_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX35_PAD_USBOTG_OC__USB_TOP_USBOTG_OC,
+ USBOTG_IN_PAD_CTRL),
+ };
/* Set up pins for USBOTG. */
- mxc_request_iomux(MX35_PIN_USBOTG_PWR,
- MUX_CONFIG_SION | MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_USBOTG_OC,
- MUX_CONFIG_SION | MUX_CONFIG_FUNC);
-
- in_pad = PAD_CTL_DRV_3_3V | PAD_CTL_HYS_SCHMITZ | PAD_CTL_PKE_ENABLE |
- PAD_CTL_PUE_PUD | PAD_CTL_100K_PD | PAD_CTL_ODE_CMOS |
- PAD_CTL_DRV_NORMAL | PAD_CTL_SRE_SLOW;
- out_pad = PAD_CTL_DRV_3_3V | PAD_CTL_HYS_CMOS | PAD_CTL_PKE_NONE |
- PAD_CTL_ODE_CMOS | PAD_CTL_DRV_NORMAL | PAD_CTL_SRE_SLOW;
-
- mxc_iomux_set_pad(MX35_PIN_USBOTG_PWR, out_pad);
- mxc_iomux_set_pad(MX35_PIN_USBOTG_OC, in_pad);
+ imx_iomux_v3_setup_multiple_pads(usbotg_pads, ARRAY_SIZE(usbotg_pads));
}
+#define FEC_PAD_CTRL (PAD_CTL_DSE_LOW | PAD_CTL_SRE_SLOW)
+
static void setup_iomux_fec(void)
{
- int pad;
+ static const iomux_v3_cfg_t fec_pads[] = {
+ NEW_PAD_CTRL(MX35_PAD_FEC_TX_CLK__FEC_TX_CLK, FEC_PAD_CTRL |
+ PAD_CTL_HYS | PAD_CTL_PUS_100K_DOWN),
+ NEW_PAD_CTRL(MX35_PAD_FEC_RX_CLK__FEC_RX_CLK, FEC_PAD_CTRL |
+ PAD_CTL_HYS | PAD_CTL_PUS_100K_DOWN),
+ NEW_PAD_CTRL(MX35_PAD_FEC_RX_DV__FEC_RX_DV, FEC_PAD_CTRL |
+ PAD_CTL_HYS | PAD_CTL_PUS_100K_DOWN),
+ NEW_PAD_CTRL(MX35_PAD_FEC_COL__FEC_COL, FEC_PAD_CTRL |
+ PAD_CTL_HYS | PAD_CTL_PUS_100K_DOWN),
+ NEW_PAD_CTRL(MX35_PAD_FEC_RDATA0__FEC_RDATA_0, FEC_PAD_CTRL |
+ PAD_CTL_HYS | PAD_CTL_PUS_100K_DOWN),
+ NEW_PAD_CTRL(MX35_PAD_FEC_TDATA0__FEC_TDATA_0, FEC_PAD_CTRL),
+ NEW_PAD_CTRL(MX35_PAD_FEC_TX_EN__FEC_TX_EN, FEC_PAD_CTRL),
+ NEW_PAD_CTRL(MX35_PAD_FEC_MDC__FEC_MDC, FEC_PAD_CTRL),
+
[U-Boot] [PATCH v3 11/25] imx: woodburn: Convert to iomux-v3
There is no change of behavior.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3: None
Changes in v2: None
board/woodburn/woodburn.c | 69 -
1 file changed, 37 insertions(+), 32 deletions(-)
diff --git a/board/woodburn/woodburn.c b/board/woodburn/woodburn.c
index 7c36af0..3f2e6b5 100644
--- a/board/woodburn/woodburn.c
+++ b/board/woodburn/woodburn.c
@@ -28,8 +28,7 @@
#include asm/arch/imx-regs.h
#include asm/arch/crm_regs.h
#include asm/arch/clock.h
-#include asm/arch/mx35_pins.h
-#include asm/arch/iomux.h
+#include asm/arch/iomux-mx35.h
#include i2c.h
#include power/pmic.h
#include fsl_pmic.h
@@ -74,25 +73,29 @@ static void board_setup_sdram(void)
static void setup_iomux_fec(void)
{
+ static const iomux_v3_cfg_t fec_pads[] = {
+ MX35_PAD_FEC_TX_CLK__FEC_TX_CLK,
+ MX35_PAD_FEC_RX_CLK__FEC_RX_CLK,
+ MX35_PAD_FEC_RX_DV__FEC_RX_DV,
+ MX35_PAD_FEC_COL__FEC_COL,
+ MX35_PAD_FEC_RDATA0__FEC_RDATA_0,
+ MX35_PAD_FEC_TDATA0__FEC_TDATA_0,
+ MX35_PAD_FEC_TX_EN__FEC_TX_EN,
+ MX35_PAD_FEC_MDC__FEC_MDC,
+ MX35_PAD_FEC_MDIO__FEC_MDIO,
+ MX35_PAD_FEC_TX_ERR__FEC_TX_ERR,
+ MX35_PAD_FEC_RX_ERR__FEC_RX_ERR,
+ MX35_PAD_FEC_CRS__FEC_CRS,
+ MX35_PAD_FEC_RDATA1__FEC_RDATA_1,
+ MX35_PAD_FEC_TDATA1__FEC_TDATA_1,
+ MX35_PAD_FEC_RDATA2__FEC_RDATA_2,
+ MX35_PAD_FEC_TDATA2__FEC_TDATA_2,
+ MX35_PAD_FEC_RDATA3__FEC_RDATA_3,
+ MX35_PAD_FEC_TDATA3__FEC_TDATA_3,
+ };
+
/* setup pins for FEC */
- mxc_request_iomux(MX35_PIN_FEC_TX_CLK, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_RX_CLK, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_RX_DV, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_COL, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_RDATA0, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_TDATA0, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_TX_EN, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_MDC, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_MDIO, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_TX_ERR, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_RX_ERR, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_CRS, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_RDATA1, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_TDATA1, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_RDATA2, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_TDATA2, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_RDATA3, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_FEC_TDATA3, MUX_CONFIG_FUNC);
+ imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));
}
int woodburn_init(void)
@@ -130,9 +133,9 @@ int woodburn_init(void)
setup_iomux_fec();
/* setup GPIO1_4 FEC_ENABLE signal */
- mxc_request_iomux(MX35_PIN_SCKR, MUX_CONFIG_ALT5);
+ imx_iomux_v3_setup_pad(MX35_PAD_SCKR__GPIO1_4);
gpio_direction_output(4, 1);
- mxc_request_iomux(MX35_PIN_HCKT, MUX_CONFIG_ALT5);
+ imx_iomux_v3_setup_pad(MX35_PAD_HCKT__GPIO1_9);
gpio_direction_output(9, 1);
return 0;
@@ -228,22 +231,24 @@ struct fsl_esdhc_cfg esdhc_cfg = {MMC_SDHC1_BASE_ADDR};
int board_mmc_init(bd_t *bis)
{
+ static const iomux_v3_cfg_t sdhc1_pads[] = {
+ MX35_PAD_SD1_CMD__ESDHC1_CMD,
+ MX35_PAD_SD1_CLK__ESDHC1_CLK,
+ MX35_PAD_SD1_DATA0__ESDHC1_DAT0,
+ MX35_PAD_SD1_DATA1__ESDHC1_DAT1,
+ MX35_PAD_SD1_DATA2__ESDHC1_DAT2,
+ MX35_PAD_SD1_DATA3__ESDHC1_DAT3,
+ };
+
/* configure pins for SDHC1 only */
- mxc_request_iomux(MX35_PIN_SD1_CMD, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_SD1_CLK, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_SD1_DATA0, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_SD1_DATA1, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_SD1_DATA2, MUX_CONFIG_FUNC);
- mxc_request_iomux(MX35_PIN_SD1_DATA3, MUX_CONFIG_FUNC);
+ imx_iomux_v3_setup_multiple_pads(sdhc1_pads, ARRAY_SIZE(sdhc1_pads));
/* MMC Card Detect on GPIO1_7 */
- mxc_request_iomux(MX35_PIN_SCKT, MUX_CONFIG_ALT5);
- mxc_iomux_set_input(MUX_IN_GPIO1_IN_7, 0x1);
+ imx_iomux_v3_setup_pad(MX35_PAD_SCKT__GPIO1_7);
gpio_direction_input(GPIO_MMC_CD);
/* MMC Write Protection on GPIO1_8 */
- mxc_request_iomux(MX35_PIN_FST, MUX_CONFIG_ALT5);
- mxc_iomux_set_input(MUX_IN_GPIO1_IN_8, 0x1);
+ imx_iomux_v3_setup_pad(MX35_PAD_FST__GPIO1_8);
gpio_direction_input(GPIO_MMC_WP);
esdhc_cfg.sdhc_clk = mxc_get_clock(MXC_ESDHC1_CLK);
--
[U-Boot] [PATCH v3 14/25] imx: iomux-v3: Add missing definitions to iomux-mx51.h
Add missing definitions that are required by future changes.
By the way, make some cosmetic cleanup.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3: None
Changes in v2: None
arch/arm/include/asm/arch-mx5/iomux-mx51.h | 151 +++-
1 file changed, 124 insertions(+), 27 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/iomux-mx51.h
b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
index 323e118..70aaa37 100644
--- a/arch/arm/include/asm/arch-mx5/iomux-mx51.h
+++ b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
@@ -22,7 +22,7 @@
#include asm/imx-common/iomux-v3.h
/* Pad control groupings */
-#define MX51_UART_PAD_CTRL (PAD_CTL_PUE | PAD_CTL_DSE_HIGH | \
+#define MX51_UART_PAD_CTRL (PAD_CTL_PUS_100K_DOWN | PAD_CTL_DSE_HIGH | \
PAD_CTL_HYS | PAD_CTL_SRE_FAST)
#define MX51_I2C_PAD_CTRL (PAD_CTL_SRE_FAST | PAD_CTL_ODE | \
PAD_CTL_DSE_HIGH | PAD_CTL_PUS_100K_UP | \
@@ -30,7 +30,7 @@
#define MX51_ESDHC_PAD_CTRL(PAD_CTL_SRE_FAST | PAD_CTL_ODE | \
PAD_CTL_DSE_HIGH | PAD_CTL_PUS_100K_UP | \
PAD_CTL_HYS)
-#define MX51_USBH1_PAD_CTRL(PAD_CTL_SRE_FAST | PAD_CTL_DSE_HIGH | \
+#define MX51_USBH_PAD_CTRL (PAD_CTL_SRE_FAST | PAD_CTL_DSE_HIGH | \
PAD_CTL_PUS_100K_UP | PAD_CTL_HYS)
#define MX51_ECSPI_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_HYS | \
PAD_CTL_DSE_HIGH | PAD_CTL_SRE_FAST)
@@ -38,32 +38,67 @@
PAD_CTL_SRE_FAST | PAD_CTL_DVS)
#define MX51_GPIO_PAD_CTRL (PAD_CTL_DSE_HIGH | PAD_CTL_PKE |
PAD_CTL_SRE_FAST)
+#define MX51_PAD_CTRL_2(PAD_CTL_PKE | PAD_CTL_HYS)
+#define MX51_PAD_CTRL_4(PAD_CTL_PKE | PAD_CTL_DVS |
PAD_CTL_HYS)
+#define MX51_PAD_CTRL_5(PAD_CTL_DVS | PAD_CTL_DSE_HIGH)
+
/*
* The naming convention for the pad modes is MX51_PAD_padname__padmode
* If padname or padmode refers to a GPIO, it is named GPIOunit_num
* See also iomux-v3.h
*/
-/* PADMUX
ALT INPSE PATH PADCTRL */
+/* PADMUX ALT
INPSE PATH PADCTRL */
enum {
- MX51_PAD_EIM_D16__USBH2_DATA0 = IOMUX_PAD(0x3f0, 0x05c, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D17__USBH2_DATA1 = IOMUX_PAD(0x3f4, 0x060, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D18__USBH2_DATA2 = IOMUX_PAD(0x3f8, 0x064, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D19__USBH2_DATA3 = IOMUX_PAD(0x3fc, 0x068, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D20__USBH2_DATA4 = IOMUX_PAD(0x400, 0x06c, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D21__USBH2_DATA5 = IOMUX_PAD(0x404, 0x070, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D22__USBH2_DATA6 = IOMUX_PAD(0x408, 0x074, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_D23__USBH2_DATA7 = IOMUX_PAD(0x40c, 0x078, 2,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_EIM_D16__USBH2_DATA0 = IOMUX_PAD(0x3f0, 0x05c, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D17__GPIO2_1 = IOMUX_PAD(0x3f4, 0x060, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD_EIM_D17__USBH2_DATA1 = IOMUX_PAD(0x3f4, 0x060, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D18__USBH2_DATA2 = IOMUX_PAD(0x3f8, 0x064, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D19__USBH2_DATA3 = IOMUX_PAD(0x3fc, 0x068, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D20__USBH2_DATA4 = IOMUX_PAD(0x400, 0x06c, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D21__GPIO2_5 = IOMUX_PAD(0x404, 0x070, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD_EIM_D21__USBH2_DATA5 = IOMUX_PAD(0x404, 0x070, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D22__USBH2_DATA6 = IOMUX_PAD(0x408, 0x074, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D23__USBH2_DATA7 = IOMUX_PAD(0x40c, 0x078, 2,
__NA_, 0, MX51_USBH_PAD_CTRL),
+ MX51_PAD_EIM_D25__UART3_RXD = IOMUX_PAD(0x414, 0x080, 3,
0x9f4, 0, MX51_UART_PAD_CTRL),
+ MX51_PAD_EIM_D26__UART3_TXD = IOMUX_PAD(0x418, 0x084, 3,
__NA_, 0, MX51_UART_PAD_CTRL),
MX51_PAD_EIM_D27__GPIO2_9 = IOMUX_PAD(0x41c, 0x088, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
- MX51_PAD_EIM_A24__USBH2_CLK = IOMUX_PAD(0x450, 0x0bc, 2,
__NA_, 0, NO_PAD_CTRL),
- MX51_PAD_EIM_A25__USBH2_DIR = IOMUX_PAD(0x454, 0x0c0, 2,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_EIM_A16__GPIO2_10 = IOMUX_PAD(0x430, 0x09c, 1,
__NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD_EIM_A17__GPIO2_11 = IOMUX_PAD(0x434, 0x0a0, 1,
__NA_, 0,
[U-Boot] [PATCH v3 04/25] imx: tx25: Convert to iomux-v3
There is no change of behavior, even if some pad control values could probably
be simplified.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3: None
Changes in v2: None
board/karo/tx25/tx25.c | 107 ++--
1 file changed, 68 insertions(+), 39 deletions(-)
diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c
index 85719a0..2952eba 100644
--- a/board/karo/tx25/tx25.c
+++ b/board/karo/tx25/tx25.c
@@ -27,9 +27,8 @@
#include common.h
#include asm/io.h
#include asm/arch/imx-regs.h
-#include asm/arch/imx25-pinmux.h
+#include asm/arch/iomux-mx25.h
#include asm/gpio.h
-#include asm/arch/sys_proto.h
DECLARE_GLOBAL_DATA_PTR;
@@ -42,36 +41,44 @@ void board_init_f(ulong bootflag)
#endif
#ifdef CONFIG_FEC_MXC
+/*
+ * FIXME: need to revisit this
+ * The original code enabled PUE and 100-k pull-down without PKE, so the right
+ * value here is likely:
+ * 0 for no pull
+ * or:
+ * PAD_CTL_PUS_100K_DOWN for 100-k pull-down
+ */
+#define FEC_OUT_PAD_CTRL 0
+
#define GPIO_FEC_RESET_B IMX_GPIO_NR(4, 7)
#define GPIO_FEC_ENABLE_B IMX_GPIO_NR(4, 9)
void tx25_fec_init(void)
{
- struct iomuxc_mux_ctl *muxctl;
- struct iomuxc_pad_ctl *padctl;
- u32 gpio_mux_mode = MX25_PIN_MUX_MODE(5);
- u32 saved_rdata0_mode, saved_rdata1_mode, saved_rx_dv_mode;
+ static const iomux_v3_cfg_t fec_pads[] = {
+ MX25_PAD_FEC_TX_CLK__FEC_TX_CLK,
+ MX25_PAD_FEC_RX_DV__FEC_RX_DV,
+ MX25_PAD_FEC_RDATA0__FEC_RDATA0,
+ NEW_PAD_CTRL(MX25_PAD_FEC_TDATA0__FEC_TDATA0, FEC_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_FEC_TX_EN__FEC_TX_EN, FEC_OUT_PAD_CTRL),
+ NEW_PAD_CTRL(MX25_PAD_FEC_MDC__FEC_MDC, FEC_OUT_PAD_CTRL),
+ MX25_PAD_FEC_MDIO__FEC_MDIO,
+ MX25_PAD_FEC_RDATA1__FEC_RDATA1,
+ NEW_PAD_CTRL(MX25_PAD_FEC_TDATA1__FEC_TDATA1, FEC_OUT_PAD_CTRL),
+
+ NEW_PAD_CTRL(MX25_PAD_D13__GPIO_4_7, 0), /* FEC_RESET_B */
+ NEW_PAD_CTRL(MX25_PAD_D11__GPIO_4_9, 0), /* FEC_ENABLE_B */
+ };
+
+ static const iomux_v3_cfg_t fec_cfg_pads[] = {
+ MX25_PAD_FEC_RDATA0__GPIO_3_10,
+ MX25_PAD_FEC_RDATA1__GPIO_3_11,
+ MX25_PAD_FEC_RX_DV__GPIO_3_12,
+ };
debug(tx25_fec_init\n);
- /*
-* fec pin init is generic
-*/
- mx25_fec_init_pins();
-
- /*
-* Set up the FEC_RESET_B and FEC_ENABLE GPIO pins.
-*
-* FEC_RESET_B: gpio4[7] is ALT 5 mode of pin D13
-* FEC_ENABLE_B: gpio4[9] is ALT 5 mode of pin D11
-*/
- muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
- padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
-
- writel(gpio_mux_mode, muxctl-pad_d13);
- writel(gpio_mux_mode, muxctl-pad_d11);
-
- writel(0x0, padctl-pad_d13);
- writel(0x0, padctl-pad_d11);
+ imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));
/* drop PHY power and assert reset (low) */
gpio_direction_output(GPIO_FEC_RESET_B, 0);
@@ -99,15 +106,10 @@ void tx25_fec_init(void)
* RMII mode is selected by FEC_RX_DV which is GPIO 3_12 in mux mode
*/
/*
-* save three current mux modes and set each to gpio mode
+* set each mux mode to gpio mode
*/
- saved_rdata0_mode = readl(muxctl-pad_fec_rdata0);
- saved_rdata1_mode = readl(muxctl-pad_fec_rdata1);
- saved_rx_dv_mode = readl(muxctl-pad_fec_rx_dv);
-
- writel(gpio_mux_mode, muxctl-pad_fec_rdata0);
- writel(gpio_mux_mode, muxctl-pad_fec_rdata1);
- writel(gpio_mux_mode, muxctl-pad_fec_rx_dv);
+ imx_iomux_v3_setup_multiple_pads(fec_cfg_pads,
+ ARRAY_SIZE(fec_cfg_pads));
/*
* set each to 1 and make each an output
@@ -128,19 +130,46 @@ void tx25_fec_init(void)
/*
* set FEC pins back
*/
- writel(saved_rdata0_mode, muxctl-pad_fec_rdata0);
- writel(saved_rdata1_mode, muxctl-pad_fec_rdata1);
- writel(saved_rx_dv_mode, muxctl-pad_fec_rx_dv);
+ imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));
}
#else
#define tx25_fec_init()
#endif
-int board_init()
-{
#ifdef CONFIG_MXC_UART
- mx25_uart1_init_pins();
+/*
+ * Set up input pins with hysteresis and 100-k pull-ups
+ */
+#define UART1_IN_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PUS_100K_UP)
+/*
+ * FIXME: need to revisit this
+ * The original code enabled PUE and 100-k pull-down without PKE, so the right
+ * value here is likely:
+ * 0 for no pull
+ * or:
+ * PAD_CTL_PUS_100K_DOWN for 100-k pull-down
+ */
+#define UART1_OUT_PAD_CTRL 0
+
+static void tx25_uart1_init(void)
+{
+ static const iomux_v3_cfg_t uart1_pads[] = {
+ NEW_PAD_CTRL(MX25_PAD_UART1_RXD__UART1_RXD,
[U-Boot] [PATCH v3 15/25] imx: mx51evk: Convert to iomux-v3
There is no change of behavior, except for older silicon revisions for which
support is removed.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v3: None
Changes in v2: None
board/freescale/mx51evk/mx51evk.c | 348 +++
board/freescale/mx51evk/mx51evk_video.c | 22 +-
2 files changed, 131 insertions(+), 239 deletions(-)
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 54c16b1..369da6d 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -24,8 +24,7 @@
#include asm/io.h
#include asm/gpio.h
#include asm/arch/imx-regs.h
-#include asm/arch/mx5x_pins.h
-#include asm/arch/iomux.h
+#include asm/arch/iomux-mx51.h
#include asm/errno.h
#include asm/arch/sys_proto.h
#include asm/arch/crm_regs.h
@@ -64,160 +63,103 @@ u32 get_board_rev(void)
return rev;
}
+#define UART_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PUS_100K_DOWN | PAD_CTL_DSE_HIGH)
+
static void setup_iomux_uart(void)
{
- unsigned int pad = PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE |
- PAD_CTL_PUE_PULL | PAD_CTL_DRV_HIGH;
-
- mxc_request_iomux(MX51_PIN_UART1_RXD, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX51_PIN_UART1_RXD, pad | PAD_CTL_SRE_FAST);
- mxc_request_iomux(MX51_PIN_UART1_TXD, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX51_PIN_UART1_TXD, pad | PAD_CTL_SRE_FAST);
- mxc_request_iomux(MX51_PIN_UART1_RTS, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX51_PIN_UART1_RTS, pad);
- mxc_request_iomux(MX51_PIN_UART1_CTS, IOMUX_CONFIG_ALT0);
- mxc_iomux_set_pad(MX51_PIN_UART1_CTS, pad);
+ static const iomux_v3_cfg_t uart_pads[] = {
+ MX51_PAD_UART1_RXD__UART1_RXD,
+ MX51_PAD_UART1_TXD__UART1_TXD,
+ NEW_PAD_CTRL(MX51_PAD_UART1_RTS__UART1_RTS, UART_PAD_CTRL),
+ NEW_PAD_CTRL(MX51_PAD_UART1_CTS__UART1_CTS, UART_PAD_CTRL),
+ };
+
+ imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads));
}
static void setup_iomux_fec(void)
{
- /*FEC_MDIO*/
- mxc_request_iomux(MX51_PIN_EIM_EB2 , IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_EB2 , 0x1FD);
-
- /*FEC_MDC*/
- mxc_request_iomux(MX51_PIN_NANDF_CS3, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS3, 0x2004);
-
- /* FEC RDATA[3] */
- mxc_request_iomux(MX51_PIN_EIM_CS3, IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_CS3, 0x180);
-
- /* FEC RDATA[2] */
- mxc_request_iomux(MX51_PIN_EIM_CS2, IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_CS2, 0x180);
-
- /* FEC RDATA[1] */
- mxc_request_iomux(MX51_PIN_EIM_EB3, IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_EB3, 0x180);
-
- /* FEC RDATA[0] */
- mxc_request_iomux(MX51_PIN_NANDF_D9, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_D9, 0x2180);
-
- /* FEC TDATA[3] */
- mxc_request_iomux(MX51_PIN_NANDF_CS6, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS6, 0x2004);
-
- /* FEC TDATA[2] */
- mxc_request_iomux(MX51_PIN_NANDF_CS5, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS5, 0x2004);
-
- /* FEC TDATA[1] */
- mxc_request_iomux(MX51_PIN_NANDF_CS4, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS4, 0x2004);
-
- /* FEC TDATA[0] */
- mxc_request_iomux(MX51_PIN_NANDF_D8, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_D8, 0x2004);
-
- /* FEC TX_EN */
- mxc_request_iomux(MX51_PIN_NANDF_CS7, IOMUX_CONFIG_ALT1);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS7, 0x2004);
-
- /* FEC TX_ER */
- mxc_request_iomux(MX51_PIN_NANDF_CS2, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS2, 0x2004);
-
- /* FEC TX_CLK */
- mxc_request_iomux(MX51_PIN_NANDF_RDY_INT, IOMUX_CONFIG_ALT1);
- mxc_iomux_set_pad(MX51_PIN_NANDF_RDY_INT, 0x2180);
-
- /* FEC TX_COL */
- mxc_request_iomux(MX51_PIN_NANDF_RB2, IOMUX_CONFIG_ALT1);
- mxc_iomux_set_pad(MX51_PIN_NANDF_RB2, 0x2180);
-
- /* FEC RX_CLK */
- mxc_request_iomux(MX51_PIN_NANDF_RB3, IOMUX_CONFIG_ALT1);
- mxc_iomux_set_pad(MX51_PIN_NANDF_RB3, 0x2180);
-
- /* FEC RX_CRS */
- mxc_request_iomux(MX51_PIN_EIM_CS5, IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_CS5, 0x180);
-
- /* FEC RX_ER */
- mxc_request_iomux(MX51_PIN_EIM_CS4, IOMUX_CONFIG_ALT3);
- mxc_iomux_set_pad(MX51_PIN_EIM_CS4, 0x180);
-
- /* FEC RX_DV */
- mxc_request_iomux(MX51_PIN_NANDF_D11, IOMUX_CONFIG_ALT2);
- mxc_iomux_set_pad(MX51_PIN_NANDF_D11, 0x2180);
+ static const iomux_v3_cfg_t fec_pads[] = {
+ NEW_PAD_CTRL(MX51_PAD_EIM_EB2__FEC_MDIO, PAD_CTL_HYS |
+ PAD_CTL_PUS_22K_UP | PAD_CTL_ODE |
+ PAD_CTL_DSE_HIGH |
