Re: [U-Boot] Pull request - microblaze
On 04/30/2013 05:44 PM, Tom Rini wrote: > On Tue, Apr 30, 2013 at 11:26:44AM +0200, Michal Simek wrote: > >> Hi Tom, >> >> please pull these microblaze changes to your tree. >> 2 of that patches was reviewed by you. >> >> Thanks, >> Michal >> >> The following changes since commit d10f68ae47b67acab8b110b5c605dde4197a1820: >> >> Prepare v2013.04 (2013-04-19 10:25:43 -0400) >> >> are available in the git repository at: >> >> git://www.denx.de/git/u-boot-microblaze.git microblaze >> >> for you to fetch changes up to 0f21f98dd4d6bff72df4eeaca4163779896cb336: >> >> watchdog: Add support for Xilinx Microblaze watchdog (2013-04-30 11:22:43 >> +0200) >> >> >> Michal Simek (4): >> microblaze: Fix reset function >> microblaze: Enable netconsole >> microblaze: Disable all cpu features before reset >> watchdog: Add support for Xilinx Microblaze watchdog >> >> arch/microblaze/include/asm/processor.h | 4 +++ >> arch/microblaze/lib/board.c | 3 ++ >> board/xilinx/microblaze-generic/microblaze-generic.c | 11 -- >> board/xilinx/microblaze-generic/xparameters.h| 4 +++ >> doc/README.watchdog | 3 ++ >> drivers/watchdog/Makefile| 1 + >> drivers/watchdog/xilinx_tb_wdt.c | 87 >> ++ >> include/configs/microblaze-generic.h | 17 - >> 8 files changed, 126 insertions(+), 4 deletions(-) >> create mode 100644 drivers/watchdog/xilinx_tb_wdt.c > > Applied to u-boot/master, thanks! Have you pushed it to git.denx.de? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - zynq
On 04/30/2013 04:50 PM, Tom Rini wrote: > On Tue, Apr 30, 2013 at 11:49:33AM +0200, Michal Simek wrote: > >> Hi Tom and Albert, >> >> please pull this patchset related to arm zynq to your tree. >> I haven't got any ACK for gem and platform changes but the whole patchset >> was reviewed by Tom. >> Also not all patches are ARM core specific but they are affecting >> zynq platform that's why I think it can go directly to Tom tree. >> >> Please let me know if you have any problem with it. I can create more >> branches with specific patches which should go through specific trees. >> >> I have removed fpga related patch because I have some others pending fpga >> patches and I will group them together. >> >> Thanks, >> Michal >> >> >> The following changes since commit d10f68ae47b67acab8b110b5c605dde4197a1820: >> >> Prepare v2013.04 (2013-04-19 10:25:43 -0400) >> >> are available in the git repository at: >> >> git://www.denx.de/git/u-boot-microblaze.git zynq >> >> for you to fetch changes up to 8934f7846501070a5b01c1fab5db27559e9d70d1: >> >> i2c: zynq: Add support for Xilinx Zynq (2013-04-30 11:39:28 +0200) >> >> >> David Andrey (3): >> arm: zynq: U-Boot udelay < 1000 FIX >> net: gem: Pass phy address to init >> net: gem: Preserve clk on emio interface >> >> Michal Simek (11): >> arm: zynq: Rename XPSS_ prefix to ZYNQ_ for hardcoded SoC addresses >> zynq: Move scutimer baseaddr to hardware.h >> net: phy: Define Marvell 88e1518 phy >> net: gem: Remove WRAP bit from TX buffer description >> net: gem: Simplify return path in zynq_gem_recv >> net: gem: Do not initialize BDs again >> net: gem: Fix gem driver on 1Gbps LAN >> zynq: Move macros to hardware.h >> net: gem: Add support for phy autodetection >> mmc: Add support for Xilinx Zynq sdhci controller >> i2c: zynq: Add support for Xilinx Zynq >> >> arch/arm/cpu/armv7/zynq/slcr.c | 26 >> arch/arm/cpu/armv7/zynq/timer.c| 49 --- >> arch/arm/include/asm/arch-zynq/hardware.h | 26 +--- >> arch/arm/include/asm/arch-zynq/sys_proto.h | 4 ++ >> board/xilinx/zynq/board.c | 29 - >> drivers/i2c/Makefile | 1 + >> drivers/i2c/zynq_i2c.c | 306 >> + >> drivers/mmc/Makefile | 1 + >> drivers/mmc/zynq_sdhci.c | 40 >> drivers/net/phy/marvell.c | 11 >> drivers/net/zynq_gem.c | 199 >> +- >> include/configs/zynq.h | 33 -- >> include/netdev.h | 2 +- >> 13 files changed, 644 insertions(+), 83 deletions(-) >> create mode 100644 drivers/i2c/zynq_i2c.c >> create mode 100644 drivers/mmc/zynq_sdhci.c > > Unless Albert really doesn't want this, I'm fine going through his tree > as it's all ARM related. Albert: any comment? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix references to the documentation files
On 30/04/2013 23:15, Anatolij Gustschin wrote: > Many boot image configuration files refer to the > appropriate documentation file, but these references > contain typos in the directory and file name. Fix > them. Also fix reference to doc/README.SPL file. > > Signed-off-by: Anatolij Gustschin > Cc: Prafulla Wadaskar > Cc: Stefano Babic > --- > board/LaCie/net2big_v2/kwbimage.cfg |2 +- > board/LaCie/netspace_v2/kwbimage-is2.cfg |2 +- > board/LaCie/netspace_v2/kwbimage-ns2l.cfg|2 +- > board/LaCie/netspace_v2/kwbimage.cfg |2 +- > board/LaCie/wireless_space/kwbimage.cfg |2 +- > board/Marvell/dreamplug/kwbimage.cfg |2 +- > board/Marvell/guruplug/kwbimage.cfg |2 +- > board/Marvell/mv88f6281gtw_ge/kwbimage.cfg |2 +- > board/Marvell/openrd/kwbimage.cfg|2 +- > board/Marvell/rd6281a/kwbimage.cfg |2 +- > board/Seagate/dockstar/kwbimage.cfg |2 +- > board/boundary/nitrogen6x/nitrogen6dl.cfg|2 +- > board/boundary/nitrogen6x/nitrogen6dl2g.cfg |2 +- > board/boundary/nitrogen6x/nitrogen6q.cfg |2 +- > board/boundary/nitrogen6x/nitrogen6q2g.cfg |2 +- > board/boundary/nitrogen6x/nitrogen6s.cfg |2 +- > board/boundary/nitrogen6x/nitrogen6s1g.cfg |2 +- > board/buffalo/lsxl/kwbimage-lschl.cfg|2 +- > board/buffalo/lsxl/kwbimage-lsxhl.cfg|2 +- > board/cloudengines/pogo_e02/kwbimage.cfg |2 +- > board/d-link/dns325/kwbimage.cfg |2 +- > board/esg/ima3-mx53/imximage.cfg |2 +- > board/freescale/corenet_ds/pbi.cfg |2 +- > board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |2 +- > board/freescale/mx25pdk/imximage.cfg |2 +- > board/freescale/mx51evk/imximage.cfg |2 +- > board/freescale/mx53ard/imximage_dd3.cfg |2 +- > board/freescale/mx53evk/imximage.cfg |2 +- > board/freescale/mx53loco/imximage.cfg|2 +- > board/freescale/mx53smd/imximage.cfg |2 +- > board/freescale/mx6qarm2/imximage.cfg|2 +- > board/freescale/mx6qsabreauto/imximage.cfg |2 +- > board/genesi/mx51_efikamx/imximage_mx.cfg|2 +- > board/genesi/mx51_efikamx/imximage_sb.cfg|2 +- > board/iomega/iconnect/kwbimage.cfg |2 +- > board/karo/tk71/kwbimage.cfg |2 +- > board/keymile/km_arm/kwbimage-memphis.cfg|2 +- > board/keymile/km_arm/kwbimage.cfg|2 +- > board/keymile/km_arm/kwbimage_128M16_1.cfg |2 +- > board/keymile/km_arm/kwbimage_256M8_1.cfg|2 +- > board/raidsonic/ib62x0/kwbimage.cfg |2 +- > board/ttcontrol/vision2/imximage_hynix.cfg |2 +- > doc/SPL/README.am335x-network|2 +- > 43 files changed, 43 insertions(+), 43 deletions(-) > > diff --git a/board/LaCie/net2big_v2/kwbimage.cfg > b/board/LaCie/net2big_v2/kwbimage.cfg > index 8d9f153..d3904d3 100644 > --- a/board/LaCie/net2big_v2/kwbimage.cfg > +++ b/board/LaCie/net2big_v2/kwbimage.cfg > @@ -19,7 +19,7 @@ > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > # GNU General Public License for more details. > # > -# Refer docs/README.kwimage for more details about how-to configure > +# Refer doc/README.kwbimage for more details about how-to configure > # and create kirkwood boot image > # > > diff --git a/board/LaCie/netspace_v2/kwbimage-is2.cfg > b/board/LaCie/netspace_v2/kwbimage-is2.cfg > index 590720a..93b803c 100644 > --- a/board/LaCie/netspace_v2/kwbimage-is2.cfg > +++ b/board/LaCie/netspace_v2/kwbimage-is2.cfg > @@ -19,7 +19,7 @@ > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > # GNU General Public License for more details. > # > -# Refer docs/README.kwimage for more details about how-to configure > +# Refer doc/README.kwbimage for more details about how-to configure > # and create kirkwood boot image > # > > diff --git a/board/LaCie/netspace_v2/kwbimage-ns2l.cfg > b/board/LaCie/netspace_v2/kwbimage-ns2l.cfg > index d008eb0..0a8a514 100644 > --- a/board/LaCie/netspace_v2/kwbimage-ns2l.cfg > +++ b/board/LaCie/netspace_v2/kwbimage-ns2l.cfg > @@ -19,7 +19,7 @@ > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > # GNU General Public License for more details. > # > -# Refer docs/README.kwimage for more details about how-to configure > +# Refer doc/README.kwbimage for more details about how-to configure > # and create kirkwood boot image > # > > diff --git a/board/LaCie/netspace_v2/kwbimage.cfg > b/board/LaCie/netspace_v2/kwbimage.cfg > index 7e53649..0cf4682 100644 > --- a/board/LaCie/netspace_v2/kwbimage.cfg > +++ b/board/LaCie/netspace_v2/kwbimage.cfg > @@ -19,7 +19,7 @@ > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > # GNU General Public License for more details. > # > -# Refer docs/README.kwimage for more details about how-to configure > +# Re
[U-Boot] [PATCH v2 0/7] 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 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 (7):
fpga: Clean coding style
fpga: Fix debug message compilation error
cmd: fpga: Clean coding style
cmd: fpga: Move fpga_loadbitstream to fpga.c
cmd: fpga: Do not include net.h
fpga: zynq: Add support for loading bitstream
fpga: Check device name against bitstream name
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| 330 +--
drivers/fpga/xilinx.c | 39
drivers/fpga/zynqpl.c | 355 +
include/configs/zynq.h | 6 +
include/fpga.h | 1 +
include/xilinx.h | 5 +
include/zynqpl.h | 59 +
13 files changed, 840 insertions(+), 295 deletions(-)
create mode 100644 drivers/fpga/zynqpl.c
create mode 100644 include/zynqpl.h
--
1.8.2.1
pgpTiaVVSxhpP.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] fpga: Clean coding style
No functional changes.
Signed-off-by: Michal Simek
---
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 /* core U-Boot definitions */
#include /* xilinx specific definitions */
#include /* altera specific definitions */
#include
-#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 @ 0x%p\n", desc);
+
[U-Boot] [PATCH v2 2/7] 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
---
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
pgpOwwRMBNxTn.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/7] cmd: fpga: Clean coding style
No functional changes.
Signed-off-by: Michal Simek
---
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
/* 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;i*/
- data_size = simple_strtoul (argv[4], NULL, 16);
+ data_size = simple_strtoul(argv[4], NULL, 16);
case 4: /* fpga*/
#if defined(CONFIG_FIT)
- if (fit_parse_subimage (argv[3], (ulong)fpga_data,
- &fit_addr, &fit_uname)) {
+ if (fit_parse_subimage(argv[3], (ulong)fpga_data,
+ &fit_addr, &fit_uname)) {
fpga_data = (void *)fit_addr;
- debug("* fpga: subimage '%s' from FIT image "
- "at 0x%08lx\n",
- fit_uname, fit_addr);
+ debug("* fpga: subimage '%s' from FIT image ",
+ fit_uname);
+ debug("at 0x%08lx\n", fit_addr);
} else
#endif
{
- fpga_data = (void *) simple_strtoul (argv[3], NULL, 16);
+ fpga_data = (void *)simple_strtoul(argv[3], NULL, 16);
debug("* fpga: cmdline image address = 0x%08lx\n",
- (ulong)fpga_data);
+ (ulong)fpga_data);
}
- debug("%s: fpga_data = 0x%x\n", __func__, (uint) fpga_data);
+ debug("%s: fpga_data = 0x%x\n", __func__, (uint)fpga_data);
case 3: /* fpga */
- dev = (int) simple_strtoul (argv[2], NULL, 16);
+ dev = (int)simple_strtoul(argv[2], NULL, 16);
debug("%s: device = %d\n", __func__, dev);
/* FIXME - this is a really weak test */
- if ((argc == 3) && (dev > fpga_count ())) { /* must be
buffer ptr */
+ if ((argc == 3) && (dev > fpga_count())) {
+ /* must be buffer ptr */
debug("%s: Assuming buffer pointer in arg 3\n",
- __func__);
+ __func__);
#if defined(CONFIG_FIT)
- if (fit_parse_subimage (argv[2], (ulong)fpga_data,
- &fit_addr, &fit_uname)) {
+ if (fit_parse_subimage(argv[2], (ulong)fpga_data,
+ &fit_addr, &fit_uname)) {
fpga_data = (void *)fit_addr;
- debug("* fpga: subimage '%s' from FIT image "
- "at 0x%08lx\n",
- fit_uname, fit_addr);
+ debug("* fpga: subimage '%s' from FIT image ",
+ fit_uname);
+ debug("at 0x%08lx\n", fit_addr);
} else
#endif
{
- fpga_data = (void *) dev;
- debug("* fpga: cmdline image address = "
[U-Boot] [PATCH v2 7/7] fpga: Check device name against bitstream name
Ensure that wrong bitstream won't be loaded
to current device.
Signed-off-by: Michal Simek
---
Changes in v2:
- New patch in this series
drivers/fpga/fpga.c | 20
drivers/fpga/xilinx.c | 2 ++
include/xilinx.h | 1 +
include/zynqpl.h | 8
4 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index b74c84f..5ba8cf0 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -197,8 +197,14 @@ int fpga_loadbitstream(unsigned long dev, char *fpgadata,
size_t size)
unsigned char *dataptr;
unsigned int i;
int rc;
+ const fpga_desc *desc;
+ Xilinx_desc *xdesc;
dataptr = (unsigned char *)fpgadata;
+ /* Find out fpga_description */
+ desc = fpga_validate(dev, 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);
@@ -232,6 +238,20 @@ int fpga_loadbitstream(unsigned long dev, 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__, dev, xdesc->name, buffer);
+ 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) */
diff --git a/drivers/fpga/xilinx.c b/drivers/fpga/xilinx.c
index fe324ab..bd740c2 100644
--- a/drivers/fpga/xilinx.c
+++ b/drivers/fpga/xilinx.c
@@ -220,6 +220,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/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, "7z020" }
#define XILINX_XC7Z030_DESC(cookie) \
-{ xilinx_zynq, devcfg, XILINX_XC7Z030_SIZE, NULL, cookie }
+{ xilinx_zynq, devcfg, XILINX_XC7Z030_SIZE, NULL, cookie, "7z030" }
#define XILINX_XC7Z045_DESC(cookie) \
-{ xilinx_zynq, devcfg, XILINX_XC7Z045_SIZE, NULL, cookie }
+{ xilinx_zynq, devcfg, XILINX_XC7Z045_SIZE, NULL, cookie, "7z045" }
#endif /* _ZYNQPL_H_ */
--
1.8.2.1
pgppLAojCDRxW.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] 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
---
Changes in v2: None
common/cmd_fpga.c | 94 -
drivers/fpga/fpga.c | 94 +
include/fpga.h | 1 +
3 files changed, 95 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
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 43bdf4f..b74c84f 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -187,6 +187,100 @@ int fpga_add(fpga_type devtype, void *desc)
return devnum;
}
+/* 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__);
+ retu
[U-Boot] [PATCH v2 6/7] 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
Signed-off-by: Michal Simek
---
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
#include
+#include
#include
#include
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 XILINX_ZYNQ_7010:
+ fpga = fpga010;
+ break;
+ case XILINX_ZYNQ_7020:
+
[U-Boot] [PATCH v2 5/7] cmd: fpga: Do not include net.h
There is no reason to include net.h header in fpga code. Signed-off-by: Michal Simek --- 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 #include -#if defined(CONFIG_CMD_NET) -#include -#endif #include #include -- 1.8.2.1 pgpQIlyXBORXq.pgp Description: PGP signature ___ 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
---
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
+#include
-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
#include
#include
+#include
+
+#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 000..37fb0c5
--- /dev/null
+++ b/drivers/gpio/xilinx_gpio.c
@@ -0,0 +1,364 @@
+/*
+ * Copyright (
[U-Boot] [PATCH v3] fs/ext4: Support device block sizes != 512 bytes
From: Egbert Eich
The 512 byte block size was hard coded in the ext4 file systems.
Large harddisks today support bigger block sizes typically 4096
bytes.
This patch removes this limitation.
Signed-off-by: Egbert Eich
---
Changes for v2:
- Coding style fixes.
Changes for v3:
- Build fixes. Builds on sandbox now.
fs/ext4/dev.c | 62 --
fs/ext4/ext4_common.c | 42 ++
fs/ext4/ext4_common.h | 2 +-
fs/ext4/ext4_journal.c | 6 ++---
fs/ext4/ext4_write.c | 32 ++
fs/ext4/ext4fs.c | 14 +++-
include/ext4fs.h | 1 +
include/ext_common.h | 12 +++---
8 files changed, 95 insertions(+), 76 deletions(-)
diff --git a/fs/ext4/dev.c b/fs/ext4/dev.c
index 464a67d..3e993cc 100644
--- a/fs/ext4/dev.c
+++ b/fs/ext4/dev.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include "ext4_common.h"
unsigned long part_offset;
@@ -48,37 +49,41 @@ static disk_partition_t *part_info;
void ext4fs_set_blk_dev(block_dev_desc_t *rbdd, disk_partition_t *info)
{
+ assert(rbdd->blksz == (1 << rbdd->log2blksz));
ext4fs_block_dev_desc = rbdd;
part_info = info;
part_offset = info->start;
- get_fs()->total_sect = (info->size * info->blksz) / SECTOR_SIZE;
+ get_fs()->total_sect = (info->size * info->blksz) >>
+ get_fs()->dev_desc->log2blksz;
get_fs()->dev_desc = rbdd;
}
int ext4fs_devread(int sector, int byte_offset, int byte_len, char *buf)
{
- ALLOC_CACHE_ALIGN_BUFFER(char, sec_buf, SECTOR_SIZE);
unsigned block_len;
+ int log2blksz = ext4fs_block_dev_desc->log2blksz;
+ ALLOC_CACHE_ALIGN_BUFFER(char, sec_buf, (ext4fs_block_dev_desc ?
+ext4fs_block_dev_desc->blksz :
+0));
+ if (ext4fs_block_dev_desc == NULL) {
+ printf("** Invalid Block Device Descriptor (NULL)\n");
+ return 0;
+ }
/* Check partition boundaries */
- if ((sector < 0)
- || ((sector + ((byte_offset + byte_len - 1) >> SECTOR_BITS)) >=
- part_info->size)) {
+ if ((sector < 0) ||
+ ((sector + ((byte_offset + byte_len - 1) >> log2blksz))
+>= part_info->size)) {
printf("%s read outside partition %d\n", __func__, sector);
return 0;
}
/* Get the read to the beginning of a partition */
- sector += byte_offset >> SECTOR_BITS;
- byte_offset &= SECTOR_SIZE - 1;
+ sector += byte_offset >> log2blksz;
+ byte_offset &= ext4fs_block_dev_desc->blksz - 1;
debug(" <%d, %d, %d>\n", sector, byte_offset, byte_len);
- if (ext4fs_block_dev_desc == NULL) {
- printf("** Invalid Block Device Descriptor (NULL)\n");
- return 0;
- }
-
if (byte_offset != 0) {
/* read first part which isn't aligned with start of sector */
if (ext4fs_block_dev_desc->
@@ -89,9 +94,12 @@ int ext4fs_devread(int sector, int byte_offset, int
byte_len, char *buf)
return 0;
}
memcpy(buf, sec_buf + byte_offset,
- min(SECTOR_SIZE - byte_offset, byte_len));
- buf += min(SECTOR_SIZE - byte_offset, byte_len);
- byte_len -= min(SECTOR_SIZE - byte_offset, byte_len);
+ min(ext4fs_block_dev_desc->blksz
+ - byte_offset, byte_len));
+ buf += min(ext4fs_block_dev_desc->blksz
+ - byte_offset, byte_len);
+ byte_len -= min(ext4fs_block_dev_desc->blksz
+ - byte_offset, byte_len);
sector++;
}
@@ -99,12 +107,12 @@ int ext4fs_devread(int sector, int byte_offset, int
byte_len, char *buf)
return 1;
/* read sector aligned part */
- block_len = byte_len & ~(SECTOR_SIZE - 1);
+ block_len = byte_len & ~(ext4fs_block_dev_desc->blksz - 1);
if (block_len == 0) {
- ALLOC_CACHE_ALIGN_BUFFER(u8, p, SECTOR_SIZE);
+ ALLOC_CACHE_ALIGN_BUFFER(u8, p, ext4fs_block_dev_desc->blksz);
- block_len = SECTOR_SIZE;
+ block_len = ext4fs_block_dev_desc->blksz;
ext4fs_block_dev_desc->block_read(ext4fs_block_dev_desc->dev,
part_info->start + sector,
1, (unsigned long *)p);
@@ -114,16 +122,16 @@ int ext4fs_devread(int sector, int byte_offset, int
byte_len, char *buf)
if (ext4fs_blo
Re: [U-Boot] u-boot UBI support
On Tue, Apr 30, 2013 at 01:54:41PM -0700, Paul B. Henson wrote: > On 4/29/2013 1:57 AM, Sascha Silbe wrote: > >>MX28EVK U-Boot > ubifsmount recovery > >> > >>UBIFS error (pid 0): ubifs_get_sb: cannot open "recovery", error -22 > >>UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume > >>'recovery' errno=-22! > > > >Try increasing CONFIG_SYS_MALLOC_LEN, e.g. to 4MiB. That fixed it for me > >on a different board. > > It actually turned out to be something a lot simpler. Unlike Linux, > u-boot only allows one active ubi partition. However, because it > uses the code from Linux, when trying to access a file system you > still need to specify which ubi partition it's on, which was neither > intuitive nor obvious until I dug through the code. > > When I specified "ubifsmount ubi0:recovery", it worked perfectly. > > Thanks? Would you mind patching doc/README.ubi ? 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] Pull request - microblaze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/01/2013 03:45 AM, Michal Simek wrote: > On 04/30/2013 05:44 PM, Tom Rini wrote: >> On Tue, Apr 30, 2013 at 11:26:44AM +0200, Michal Simek wrote: >> >>> Hi Tom, >>> >>> please pull these microblaze changes to your tree. 2 of that >>> patches was reviewed by you. >>> >>> Thanks, Michal >>> >>> The following changes since commit >>> d10f68ae47b67acab8b110b5c605dde4197a1820: >>> >>> Prepare v2013.04 (2013-04-19 10:25:43 -0400) >>> >>> are available in the git repository at: >>> >>> git://www.denx.de/git/u-boot-microblaze.git microblaze >>> >>> for you to fetch changes up to >>> 0f21f98dd4d6bff72df4eeaca4163779896cb336: >>> >>> watchdog: Add support for Xilinx Microblaze watchdog >>> (2013-04-30 11:22:43 +0200) >>> >>> >>> >>> Michal Simek (4): >>> microblaze: Fix reset function microblaze: Enable netconsole >>> microblaze: Disable all cpu features before reset watchdog: Add >>> support for Xilinx Microblaze watchdog >>> >>> arch/microblaze/include/asm/processor.h | 4 +++ >>> arch/microblaze/lib/board.c | 3 ++ >>> board/xilinx/microblaze-generic/microblaze-generic.c | 11 >>> -- board/xilinx/microblaze-generic/xparameters.h| >>> 4 +++ doc/README.watchdog | 3 >>> ++ drivers/watchdog/Makefile| 1 + >>> drivers/watchdog/xilinx_tb_wdt.c | 87 >>> ++ >>> include/configs/microblaze-generic.h | 17 >>> - 8 files changed, 126 insertions(+), 4 deletions(-) >>> create mode 100644 drivers/watchdog/xilinx_tb_wdt.c >> >> Applied to u-boot/master, thanks! > > Have you pushed it to git.denx.de? Blah, some bad timing on my part, should show up soon now. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRgSlWAAoJENk4IS6UOR1WnY4P/1HW92hitv0Kx/mVvYTlsvqr 1jFw/UBi5FWlPVnTlha4nG187cuR5hU86Og2Yzf0WLqVKAyaRTJZgoAOsd51d185 Zcd9z+x1hIH8SjwoH6lS/7YdBv51zAcSSkv1XNHWibpMt432s8VxhlLzQDoz+hC/ bLZmjYxURjUdRY4FRj0osw8UIAdGSCs/XZsxXEKmepHDNy7Q+JNkTiB9jVzwQ3eE H0RHVgrh0jaImmXBLF74exiJ3w2tEjIdBOlvGFok5N/od4SpMEPFJUba+XMta1j2 0hsGeQ1v7hNAvK96/GNos+ygtOy7keBWW4e4w49cfONu1BuCcNvoxZZEsA7rwP10 1yhtlVRiB3khj9wCWHho7XWqDHe/w6E1DtgEUfMErJRy4RqHbLYjIux1ujGhbetk JBzBcq9Svl21i+tlRfWsfv29EdbCG7J3QkePuWLdoaqMOsur+QoSqMLKzG3NprMl CHj6/sDtFQCliBwbj/oXzda7nZH+6IAFlsi33RZKIO+c5BXlucPK36DAVrHpXCUy g6MnS5cJAzdhHXo15LC55Vy9aGk+1ofwsKJuSbriHJjDQEuhLd+5NPiWRpiWSDkh KcZOT6ecBz+W1o8ExEdMfvNEy48T56llfblKql7oylZgZR+9irRqy7ybgyos9qTZ 5PVd2OsZrWJVz87mNfO6 =T0Sb -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] cmd: fpga: Move fpga_loadbitstream to fpga.c
On Wed, May 01, 2013 at 10:59:20AM +0200, Michal Simek wrote:
> 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
[snip]
> +++ b/drivers/fpga/fpga.c
[snip]
> +#else
> + printf("Bitstream support only for Xilinx devices\n");
> + return FPGA_FAIL;
> +#endif
How about we re-work this as a __weak fpga_loadbitstream in
drivers/fpga/fpga.c that just says "Bitstream support not implemented
for this FPGA device", return FPGA_FAIL, and move the xilinx one into
drivers/fpga/xilinx.c ?
--
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 v2 0/7] FPGA cleanup + zynq support
On Wed, May 01, 2013 at 10:59:16AM +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. Aside from my comments to 4/7, everything else looks good and a step forward. Looking at 7/7 however, it seems like: - None of CONFIG_SYS_XILINX_IF_* are used - CONFIG_SYS_... model definitions... aren't used, now that CONFIG_FPGA isn't a bitfield anymore, and are only used by configs that still act like it is. So we could just clean up and remove those parts of the header, yes? -- 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 v2 4/7] cmd: fpga: Move fpga_loadbitstream to fpga.c
On 05/01/2013 05:03 PM, Tom Rini wrote:
> On Wed, May 01, 2013 at 10:59:20AM +0200, Michal Simek wrote:
>
>> 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
> [snip]
>> +++ b/drivers/fpga/fpga.c
> [snip]
>> +#else
>> +printf("Bitstream support only for Xilinx devices\n");
>> +return FPGA_FAIL;
>> +#endif
>
> How about we re-work this as a __weak fpga_loadbitstream in
> drivers/fpga/fpga.c that just says "Bitstream support not implemented
> for this FPGA device", return FPGA_FAIL, and move the xilinx one into
> drivers/fpga/xilinx.c ?
yep. Make sense to do it because at least from this code altera or lattice
don't support bitstream loading.
It will be more problematic if there is a board on the market
with different fpgas.
I even not sure if other fpga vendors have bitstream with any header
which should be used by this command.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] FPGA cleanup + zynq support
On 05/01/2013 05:14 PM, Tom Rini wrote: > On Wed, May 01, 2013 at 10:59:16AM +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. > > Aside from my comments to 4/7, everything else looks good and a step > forward. ok > Looking at 7/7 however, it seems like: > - None of CONFIG_SYS_XILINX_IF_* are used > - CONFIG_SYS_... model definitions... aren't used, now that CONFIG_FPGA > isn't a bitfield anymore, and are only used by configs that still act > like it is. > > So we could just clean up and remove those parts of the header, yes? yep, you are right. I will create one more patch which remove these values. (It should be done in 2008). Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital 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
Tom, On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini wrote: > On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote: > > > Marek, > > > > > -Original Message- > > > From: Marek Vasut [mailto:ma...@denx.de] > > > Sent: Monday, April 29, 2013 4:47 PM > > > To: Jim Lin > > > Cc: u-boot@lists.denx.de; Tom Warren; Stephen Warren > > > Subject: Re: [PATCH 2/3] ARM: Tegra: USB: Add driver support for > > > Tegra30/Tegra114 > > > > > > Dear Jim Lin, > > > > > > > Tegra30 and Tegra114 are compatible except 1. T30 takes 55 ms to > > > > finish Port Reset. T114 takes > > > >50 ms. > > > > 2. PLL parameters > > > > > > > > Tested on Tegra20 Harmony/Seaboard, Tegra30 Cardhu, and Tegra114 > > > > Dalmore platforms. All works well. > > > > > > > > Signed-off-by: Jim Lin > > > > --- > > > > arch/arm/include/asm/arch-tegra/clk_rst.h | 10 + > > > > arch/arm/include/asm/arch-tegra/usb.h | 249 -- > > > > arch/arm/include/asm/arch-tegra114/tegra.h |1 + > > > > arch/arm/include/asm/arch-tegra114/usb.h | 287 > > > + > > > > arch/arm/include/asm/arch-tegra20/usb.h| 279 > > > + > > > > arch/arm/include/asm/arch-tegra30/usb.h| 294 > > > ++ > > > > > > Do we now have three copies of the same stuff ? > > > > When only T20 was supported (for USB), there was a common > > (arch-tegra/usb.h) header. That's been moved to arch-tegra20/usb.h, > > and (unfortunately) there are 2 new usb.h files due to the HW > > differences in the registers between T20 and T30/T114. I don't see > > any easy way to have a common usb.h file for Tegra w/o adding ugly > > #ifdefs to the USB register space struct(s). > > Just how different are they? Are all of the related defines and masks > different too? Do we have conflicts? Moved registers? Just conflicting > values? A quick peek shows '30' and '114' are pretty similar, except > for masks. Maybe splitting the struct up so you can discard some of the > reserved gaps, run-time checking to see if we can or cannot use a > particular part of the struct? > This is really Jim's patchset (and his specialty), but here's what I know about Tegra USB regs: T20 had a gap in the registers @ offset 0x130. T30 (and T114) moved the offset of the command/status/interrupt regs down to fill in this gap, which dragged all the subsequent registers back 16 bytes. The two SoCs 'families' sync up again at offset 0x400 and are pretty much equal from there on out to 0x840. The defines are probably 90% the same, with some weirdness for the first USB controller (USB1) and its PTS/STS bits that differs in offset from the other 2 controllers (again, no clue why the HW guys would do this). So we could have the 3 different USB headers in the arch-tegraXX area contain the register structs, and have a common arch-tegra/usb.h that has the #defines that are the same, and is included in the arch-tegraxx/usb.h files. That would reduce this down somewhat, without the ugliness of #ifdefs in the structs. What do you think? Tom > > -- > Tom > ___ 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 Wed, May 01, 2013 at 09:16:45AM -0700, Tom Warren wrote: > Tom, > > > On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini wrote: > > > On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote: > > > > > Marek, > > > > > > > -Original Message- > > > > From: Marek Vasut [mailto:ma...@denx.de] > > > > Sent: Monday, April 29, 2013 4:47 PM > > > > To: Jim Lin > > > > Cc: u-boot@lists.denx.de; Tom Warren; Stephen Warren > > > > Subject: Re: [PATCH 2/3] ARM: Tegra: USB: Add driver support for > > > > Tegra30/Tegra114 > > > > > > > > Dear Jim Lin, > > > > > > > > > Tegra30 and Tegra114 are compatible except 1. T30 takes 55 ms to > > > > > finish Port Reset. T114 takes > > > > >50 ms. > > > > > 2. PLL parameters > > > > > > > > > > Tested on Tegra20 Harmony/Seaboard, Tegra30 Cardhu, and Tegra114 > > > > > Dalmore platforms. All works well. > > > > > > > > > > Signed-off-by: Jim Lin > > > > > --- > > > > > arch/arm/include/asm/arch-tegra/clk_rst.h | 10 + > > > > > arch/arm/include/asm/arch-tegra/usb.h | 249 -- > > > > > arch/arm/include/asm/arch-tegra114/tegra.h |1 + > > > > > arch/arm/include/asm/arch-tegra114/usb.h | 287 > > > > + > > > > > arch/arm/include/asm/arch-tegra20/usb.h| 279 > > > > + > > > > > arch/arm/include/asm/arch-tegra30/usb.h| 294 > > > > ++ > > > > > > > > Do we now have three copies of the same stuff ? > > > > > > When only T20 was supported (for USB), there was a common > > > (arch-tegra/usb.h) header. That's been moved to arch-tegra20/usb.h, > > > and (unfortunately) there are 2 new usb.h files due to the HW > > > differences in the registers between T20 and T30/T114. I don't see > > > any easy way to have a common usb.h file for Tegra w/o adding ugly > > > #ifdefs to the USB register space struct(s). > > > > Just how different are they? Are all of the related defines and masks > > different too? Do we have conflicts? Moved registers? Just conflicting > > values? A quick peek shows '30' and '114' are pretty similar, except > > for masks. Maybe splitting the struct up so you can discard some of the > > reserved gaps, run-time checking to see if we can or cannot use a > > particular part of the struct? > > > > This is really Jim's patchset (and his specialty), but here's what I know > about Tegra USB regs: > > T20 had a gap in the registers @ offset 0x130. T30 (and T114) moved the > offset of the command/status/interrupt regs down to fill in this gap, which > dragged all the subsequent registers back 16 bytes. The two SoCs 'families' > sync up again at offset 0x400 and are pretty much equal from there on out > to 0x840. > > The defines are probably 90% the same, with some weirdness for the first > USB controller (USB1) and its PTS/STS bits that differs in offset from the > other 2 controllers (again, no clue why the HW guys would do this). > > So we could have the 3 different USB headers in the arch-tegraXX area > contain the register structs, and have a common arch-tegra/usb.h that has > the #defines that are the same, and is included in the arch-tegraxx/usb.h > files. That would reduce this down somewhat, without the ugliness of > #ifdefs in the structs. > > What do you think? Sounds like the best we can do then. It's probable that trying to define USB_REGMAP_GAPSIZE1/2 or whatever to do it on the fly would just be uglier still. 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 v4] i2c: s3c24xx: add hsi2c controller support
Hello Heiko, On 29 April 2013 21:14, Heiko Schocher wrote: > Hello Naveen, > > On 26.04.2013 05:08, Naveen Krishna Ch wrote: >> On 14 April 2013 22:48, Heiko Schocher wrote: >>> Hello Naveen Krishna, >>> >>> >>> On 13.04.2013 06:42, Naveen Krishna Ch wrote: On 6 April 2013 07:07, Naveen Krishna Chatradhi wrote: > > Add support for hsi2c controller available on exynos5420. > > Note: driver currently supports only fast speed mode 100kbps > > Change-Id: I02555b1dc8f4ac21c50aa5158179768563c92f43 > Signed-off-by: Naveen Krishna Chatradhi > Signed-off-by: R. Chandrasekar > Reviewed-by: Vadim Bendebury > Reviewed-by: Simon Glass > --- > Changes since v3: > > 1. Implemented get_timer instead of while and udelay for master busy > function > 2. Use reg base address from device tree > 3. Split the timing function to check for the errors > 4. Implemented reset function for to recover from failure cases > 5. Implemented a comat string for hsi2c to distingush the channels > 6. Minor cosmotic changes > > Note: FIFOs will be implemented in subsequent patches > > drivers/i2c/s3c24x0_i2c.c | 494 > + > drivers/i2c/s3c24x0_i2c.h | 36 > 2 files changed, 486 insertions(+), 44 deletions(-) >>> >>> [...] >>> > -- > 1.7.9.5 Hello all i got it review by Simon and Vadim. Any updates on this driver please >>> >>> >>> As this patch in patchwork is in the responsibilty of Minkyu Kang (why?, >>> added to cc): >>> >>> Reviewed-by: Heiko Schocher >>> Acked-by: Heiko Schocher >> Hello Minkyu Kang, >> >> This patch was Acked and reviewed a while ago. >> Can you please update on this. > > Tom Rini wrote: >>> Naveen Krishna Ch (1): >>> i2c: s3c24xx: add hsi2c controller support >>> >>> drivers/i2c/s3c24x0_i2c.c | 494 >>> + >>> drivers/i2c/s3c24x0_i2c.h | 36 ++ >>> post/drivers/i2c.c| 2 + >>> 3 Dateien ge?ndert, 488 Zeilen hinzugef?gt(+), 44 Zeilen entfernt(-) >> >> NAK. MAKEALL -a arm: >> - SUMMARY >> Boards compiled: 306 >> Boards with errors: 3 ( snow VCMA9 smdk5250 ) >> -- >> >> And the problem is: >> s3c24x0_i2c.c: In function 'board_i2c_init': >> s3c24x0_i2c.c:945:3: error: 'COMPAT_SAMSUNG_EXYNOS5_I2C' undeclared >> (first use in this function) > > Please fix, thanks! I've submitted a patch to u-boot@lists.denx.de as soon as i saw the build error. "fdtdec: Add compatible string for High speed i2c" http://www.mail-archive.com/u-boot@lists.denx.de/msg112143.html which should fix. Can you please confirm the same. Thanks > > bye, > Heiko > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- Shine bright, (: Nav :) ___ 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
Dear Tom Rini, > On Wed, May 01, 2013 at 09:16:45AM -0700, Tom Warren wrote: > > Tom, > > > > On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini wrote: > > > On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote: > > > > Marek, > > > > > > > > > -Original Message- > > > > > From: Marek Vasut [mailto:ma...@denx.de] > > > > > Sent: Monday, April 29, 2013 4:47 PM > > > > > To: Jim Lin > > > > > Cc: u-boot@lists.denx.de; Tom Warren; Stephen Warren > > > > > Subject: Re: [PATCH 2/3] ARM: Tegra: USB: Add driver support for > > > > > Tegra30/Tegra114 > > > > > > > > > > Dear Jim Lin, > > > > > > > > > > > Tegra30 and Tegra114 are compatible except 1. T30 takes 55 ms to > > > > > > finish Port Reset. T114 takes > > > > > > > > > > > >50 ms. > > > > > > > > > > > > 2. PLL parameters > > > > > > > > > > > > Tested on Tegra20 Harmony/Seaboard, Tegra30 Cardhu, and Tegra114 > > > > > > Dalmore platforms. All works well. > > > > > > > > > > > > Signed-off-by: Jim Lin > > > > > > --- > > > > > > > > > > > > arch/arm/include/asm/arch-tegra/clk_rst.h | 10 + > > > > > > arch/arm/include/asm/arch-tegra/usb.h | 249 > > > > > > -- arch/arm/include/asm/arch-tegra114/tegra.h | > > > > > > 1 + > > > > > > arch/arm/include/asm/arch-tegra114/usb.h | 287 > > > > > > > > > > + > > > > > > > > > > > arch/arm/include/asm/arch-tegra20/usb.h| 279 > > > > > > > > > > + > > > > > > > > > > > arch/arm/include/asm/arch-tegra30/usb.h| 294 > > > > > > > > > > ++ > > > > > > > > > > Do we now have three copies of the same stuff ? > > > > > > > > When only T20 was supported (for USB), there was a common > > > > (arch-tegra/usb.h) header. That's been moved to arch-tegra20/usb.h, > > > > and (unfortunately) there are 2 new usb.h files due to the HW > > > > differences in the registers between T20 and T30/T114. I don't see > > > > any easy way to have a common usb.h file for Tegra w/o adding ugly > > > > #ifdefs to the USB register space struct(s). > > > > > > Just how different are they? Are all of the related defines and masks > > > different too? Do we have conflicts? Moved registers? Just > > > conflicting values? A quick peek shows '30' and '114' are pretty > > > similar, except for masks. Maybe splitting the struct up so you can > > > discard some of the reserved gaps, run-time checking to see if we can > > > or cannot use a particular part of the struct? > > > > This is really Jim's patchset (and his specialty), but here's what I know > > about Tegra USB regs: > > > > T20 had a gap in the registers @ offset 0x130. T30 (and T114) moved the > > offset of the command/status/interrupt regs down to fill in this gap, > > which dragged all the subsequent registers back 16 bytes. The two SoCs > > 'families' sync up again at offset 0x400 and are pretty much equal from > > there on out to 0x840. > > > > The defines are probably 90% the same, with some weirdness for the first > > USB controller (USB1) and its PTS/STS bits that differs in offset from > > the other 2 controllers (again, no clue why the HW guys would do this). > > > > So we could have the 3 different USB headers in the arch-tegraXX area > > contain the register structs, and have a common arch-tegra/usb.h that has > > the #defines that are the same, and is included in the arch-tegraxx/usb.h > > files. That would reduce this down somewhat, without the ugliness of > > #ifdefs in the structs. > > > > What do you think? > > Sounds like the best we can do then. It's probable that trying to > define USB_REGMAP_GAPSIZE1/2 or whatever to do it on the fly would just > be uglier still. Thanks! This is a problem with the struct-based access indeed. I agree with Tom it'd be worth to at least try distilling the common part into header shared between those three CPUs. btw you're also adding some kernel-doc-alike annotations to functions, why don't you follow kerneldoc style altogether? 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 08/11] usb: ehci: add Faraday USB 2.0 EHCI support
Dear Kuo-Jung Su,
> 2013/4/30 Marek Vasut :
> > Dear Kuo-Jung Su,
> >
> >> 2013/4/26 Marek Vasut :
> >> > Dear Kuo-Jung Su,
> >> >
> >> >> From: Kuo-Jung Su
> >> >>
> >> >> This patch add supports to both Faraday FUSBH200 and FOTG210,
> >> >> these controllers slightly differ from standard EHCI specification.
> >> >
> >> > How do they differ?
> >>
> >> 1. The reserved registers (0x1C - 0x3F) and CONFIGFLAG (0x40) register
> >>
> >> are not only un-implemented, but also removed from its register
> >> address space, which means we have to update the 'struct ehci_hcor'
> >> of ehci.h
> >>
> >> 2. FUSBH200/FOTG210 doesn't properly follow the ECHI for ISOC
> >> implementations. (It should be a hardware bug, but no one wants to fix
> >> it.)
> >>
> >> I'll add these description to commit log at next patch.
> >
> > Mhmmm ... maybe you can add some hooks into ehci-hcd driver instead of
> > poluting it with ifdefs ? Weak-aliased functions would probably work
> > best to contain your weird stuff in your driver only.
>
> Did you mean 'Not poluting ehci.h with ifdefs' ?
>
> It looks to me that the best way is to leave ehci.h untouched, and
> update the ehci_submit_root() as following:
>
> ehci_submit_root()
> {
> ..
> #ifdef CONFIG_USB_EHCI_FARADAY
> status_reg = (uint32_t *)((uint8_t *)&ctrl->hcor + 0x30);
> #else
> status_reg = (uint32_t *)&ctrl->hcor->or_portsc[
> le16_to_cpu(req->index) - 1];
> #endif
> ..
> }
> --
>
> Would it be acceptable in this way?
>
> If it's not, I'll make this patch as a separate patch with some hooks
> into ehci-hcd.
What about defining a
__weak uint32_t get_status_register()
{
...
}
function and override it's implementation in your driver?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] Loader script updates for OpenRISC
This set of patches does:
Fix a bug in the openrisc-generic u-boot.lds linker script
that would cause an error due to that no memory region was
specified for u_boot_lists.
And then move the above mentioned file into arch/openrisc/cpu/
to unify the linker script for all openrisc boards (we only have
one board).
Stefan Kristiansson (2):
openrisc: specify a memory region for u_boot_lists
openrisc: move board linker script(s) to a common in cpu/
arch/openrisc/config.mk | 2 ++
{board/openrisc/openrisc-generic => arch/openrisc/cpu}/u-boot.lds | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
rename {board/openrisc/openrisc-generic => arch/openrisc/cpu}/u-boot.lds (98%)
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] openrisc: specify a memory region for u_boot_lists
Since there are two memory areas defined, vectors and ram,
the linker will error when neither of them are specified for a
section.
Signed-off-by: Stefan Kristiansson
---
board/openrisc/openrisc-generic/u-boot.lds | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/openrisc/openrisc-generic/u-boot.lds
b/board/openrisc/openrisc-generic/u-boot.lds
index 9024f30..d9bb7b7 100644
--- a/board/openrisc/openrisc-generic/u-boot.lds
+++ b/board/openrisc/openrisc-generic/u-boot.lds
@@ -30,7 +30,7 @@ SECTIONS
. = ALIGN(4);
.u_boot_list : {
KEEP(*(SORT(.u_boot_list*)));
-}
+} > ram
.rodata : {
*(.rodata);
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] openrisc: move board linker script(s) to a common in cpu/
Unifies the openrisc boards linker scripts into a common one.
Signed-off-by: Stefan Kristiansson
---
arch/openrisc/config.mk | 2 ++
{board/openrisc/openrisc-generic => arch/openrisc/cpu}/u-boot.lds | 0
2 files changed, 2 insertions(+)
rename {board/openrisc/openrisc-generic => arch/openrisc/cpu}/u-boot.lds (100%)
diff --git a/arch/openrisc/config.mk b/arch/openrisc/config.mk
index 521e73a..01c0f77 100644
--- a/arch/openrisc/config.mk
+++ b/arch/openrisc/config.mk
@@ -25,3 +25,5 @@ CROSS_COMPILE ?= or32-elf-
PLATFORM_CPPFLAGS += -DCONFIG_OPENRISC -D__OR1K__ -ffixed-r10
CONFIG_STANDALONE_LOAD_ADDR ?= 0x4
+
+LDSCRIPT ?= $(SRCTREE)/$(CPUDIR)/u-boot.lds
diff --git a/board/openrisc/openrisc-generic/u-boot.lds
b/arch/openrisc/cpu/u-boot.lds
similarity index 100%
rename from board/openrisc/openrisc-generic/u-boot.lds
rename to arch/openrisc/cpu/u-boot.lds
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/17] sandbox: Generic board support and other improvements
On Fri, Apr 26, 2013 at 06:10:15AM -0700, Simon Glass wrote: > Hi Tom, > > On Mon, Apr 22, 2013 at 9:08 AM, Simon Glass wrote: > > Hi Tom, > > > > On Mon, Apr 22, 2013 at 8:18 AM, Tom Rini wrote: > >> On Sat, Apr 20, 2013 at 11:42:35AM -0700, Simon Glass wrote: > >> > >>> This series adds generic board support to sandbox and switches to use this > >>> always. > >>> > >>> With sandbox it was noticed that turning CONFIG_SYS_GENERIC_BOARD off > >>> can cause a build failure if a previous autoconf.mk exists which indicates > >>> that generic board is not supported, so a patch is provided to fix this. > >>> > >>> It is useful to convert a pointer into an 'address' in the sandbox RAM > >>> buffer - the opposite of map_sysmem(). This is added in this series and > >>> used in several places. > >>> > >>> With sandbox it is easier to read a file from the host than to use the > >>> CONFIG_OF_SEPARATE option, since this option requires knowledge of the > >>> executable image structure which is not really appropriate on the host > >>> system. A new CONFIG_OF_HOSTFILE provides this. > >>> > >>> A few related FDT changes are included in this series also. > >>> > >>> The -c option is enhanced to support passing entire scripts to sandbox. > >>> This is useful when writing non-trivial test code. > >>> > >>> Most of these patches were previously submitted as part of the verified > >>> boot effort. This series collects the independent sandbox-related patches > >>> together to make it easier to review. THe whole series is marked as > >>> version 3 for this reason. > >> > >> For the series, > >> Reviewed-by: Tom Rini > >> > >> And I'd say 3/4/5 should be squashed into one patch, but it's your arch > >> so I'l defer if you think it adds bisect value or similar to do it in > >> that manner. > > > > I did that so that it could be kind-of an example of how this can be > > done for an arch, given that I am not planning to convert the rest. By > > removing the dead code in a separate step it seemed a bit clearer to > > me. > > > > But it's fine either way - I will squash it and resend. > > > I have put this series in patchwork as: > > http://patchwork.ozlabs.org/bundle/sjg/sandbox/ This has now been applied to u-boot/master, thanks! > and below is a pull request if you want to take that instead. > > I did not go through and add your Reviewed-by to each patch. Am I > supposed to do that? No, that pain is supposed to help spur us into improving patchwork or the new tool we talked about back at LSM. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/9] 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 2/9] mx23: regs-pinctrl.h: Add pinctrl support for mx23
From: Fabio Estevam
Provide a mxs_pinctrl_regs structure for mx23.
Signed-off-by: Fabio Estevam
---
arch/arm/include/asm/arch-mxs/regs-pinctrl.h | 68 ++
1 file changed, 68 insertions(+)
diff --git a/arch/arm/include/asm/arch-mxs/regs-pinctrl.h
b/arch/arm/include/asm/arch-mxs/regs-pinctrl.h
index c3a8700..fe7e910 100644
--- a/arch/arm/include/asm/arch-mxs/regs-pinctrl.h
+++ b/arch/arm/include/asm/arch-mxs/regs-pinctrl.h
@@ -29,6 +29,7 @@
#include
#ifndef__ASSEMBLY__
+#if defined(CONFIG_MX28)
struct mxs_pinctrl_regs {
mxs_reg_32(ctrl)/* 0x0 */
@@ -154,6 +155,73 @@ struct mxs_pinctrl_regs {
mxs_reg_32(emi_ds_ctrl) /* 0x1b80 */
};
+#elif defined(CONFIG_MX23)
+struct mxs_pinctrl_regs {
+ mxs_reg_32(ctrl)/* 0x0 */
+ int reserved1[0x3c];
+ mxs_reg_32(muxsel0) /* 0x100 */
+ mxs_reg_32(muxsel1) /* 0x110 */
+ mxs_reg_32(muxsel2) /* 0x120 */
+ mxs_reg_32(muxsel3) /* 0x130 */
+ mxs_reg_32(muxsel4) /* 0x140 */
+ mxs_reg_32(muxsel5) /* 0x150 */
+ mxs_reg_32(muxsel6) /* 0x160 */
+ mxs_reg_32(muxsel7) /* 0x170 */
+ int reserved2[0x20];
+ mxs_reg_32(drive0) /* 0x200 */
+ mxs_reg_32(drive1) /* 0x210 */
+ mxs_reg_32(drive2) /* 0x220 */
+ mxs_reg_32(drive3) /* 0x230 */
+ mxs_reg_32(drive4) /* 0x240 */
+ mxs_reg_32(drive5) /* 0x250 */
+ mxs_reg_32(drive6) /* 0x260 */
+ mxs_reg_32(drive7) /* 0x270 */
+ mxs_reg_32(drive8) /* 0x280 */
+ mxs_reg_32(drive9) /* 0x290 */
+ mxs_reg_32(drive10) /* 0x2a0 */
+ mxs_reg_32(drive11) /* 0x2b0 */
+ mxs_reg_32(drive12) /* 0x2c0 */
+ mxs_reg_32(drive13) /* 0x2d0 */
+ mxs_reg_32(drive14) /* 0x2e0 */
+ int reserved3[0x44];
+ mxs_reg_32(pull0) /* 0x400 */
+ mxs_reg_32(pull1) /* 0x410 */
+ mxs_reg_32(pull2) /* 0x420 */
+ mxs_reg_32(pull3) /* 0x430 */
+ int reserved4[0x30];
+ mxs_reg_32(dout0) /* 0x500 */
+ mxs_reg_32(dout1) /* 0x510 */
+ mxs_reg_32(dout2) /* 0x520 */
+ int reserved5[0x34];
+ mxs_reg_32(din0)/* 0x600 */
+ mxs_reg_32(din1)/* 0x610 */
+ mxs_reg_32(din2)/* 0x620 */
+ int reserved6[0x34];
+ mxs_reg_32(doe0)/* 0x700 */
+ mxs_reg_32(doe1)/* 0x710 */
+ mxs_reg_32(doe2)/* 0x720 */
+ int reserved7[0x34];
+ mxs_reg_32(pin2irq0)/* 0x800 */
+ mxs_reg_32(pin2irq1)/* 0x810 */
+ mxs_reg_32(pin2irq2)/* 0x820 */
+ int reserved8[0x34];
+ mxs_reg_32(irqen0) /* 0x900 */
+ mxs_reg_32(irqen1) /* 0x910 */
+ mxs_reg_32(irqen2) /* 0x920 */
+ int reserved9[0x34];
+ mxs_reg_32(irqlevel0) /* 0xa00 */
+ mxs_reg_32(irqlevel1) /* 0xa10 */
+ mxs_reg_32(irqlevel2) /* 0xa20 */
+ int reserved10[0x34];
+ mxs_reg_32(irqpol0) /* 0xb00 */
+ mxs_reg_32(irqpol1) /* 0xb10 */
+ mxs_reg_32(irqpol2) /* 0xb20 */
+ int reserved11[0x34];
+ mxs_reg_32(irqstat0)/* 0xc00 */
+ mxs_reg_32(irqstat1)/* 0xc10 */
+ mxs_reg_32(irqstat2)/* 0xc20 */
+};
+#endif
#endif
#definePINCTRL_CTRL_SFTRST (1 << 31)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] mxs: Make the names of the elements of mxs_pinctrl_regs shorter
From: Fabio Estevam
Currently when accessing an element of mxs_pinctrl_regs structure we do:
&pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set
The 'hw_pinctrl' prefix is a redundant information as we already know that we
are
accessing a pinctrl register.
Signed-off-by: Fabio Estevam
---
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c|2 +-
arch/arm/include/asm/arch-mxs/regs-pinctrl.h | 168 +-
2 files changed, 85 insertions(+), 85 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index 4950490..1c509d6 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -294,7 +294,7 @@ static void mx28_mem_init(void)
/* Set DDR2 mode */
writel(PINCTRL_EMI_DS_CTRL_DDR_MODE_DDR2,
- &pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set);
+ &pinctrl_regs->emi_ds_ctrl_set);
/*
* Configure the DRAM registers
diff --git a/arch/arm/include/asm/arch-mxs/regs-pinctrl.h
b/arch/arm/include/asm/arch-mxs/regs-pinctrl.h
index 191093b..c3a8700 100644
--- a/arch/arm/include/asm/arch-mxs/regs-pinctrl.h
+++ b/arch/arm/include/asm/arch-mxs/regs-pinctrl.h
@@ -30,129 +30,129 @@
#ifndef__ASSEMBLY__
struct mxs_pinctrl_regs {
- mxs_reg_32(hw_pinctrl_ctrl) /* 0x0 */
+ mxs_reg_32(ctrl)/* 0x0 */
uint32_treserved1[60];
- mxs_reg_32(hw_pinctrl_muxsel0) /* 0x100 */
- mxs_reg_32(hw_pinctrl_muxsel1) /* 0x110 */
- mxs_reg_32(hw_pinctrl_muxsel2) /* 0x120 */
- mxs_reg_32(hw_pinctrl_muxsel3) /* 0x130 */
- mxs_reg_32(hw_pinctrl_muxsel4) /* 0x140 */
- mxs_reg_32(hw_pinctrl_muxsel5) /* 0x150 */
- mxs_reg_32(hw_pinctrl_muxsel6) /* 0x160 */
- mxs_reg_32(hw_pinctrl_muxsel7) /* 0x170 */
- mxs_reg_32(hw_pinctrl_muxsel8) /* 0x180 */
- mxs_reg_32(hw_pinctrl_muxsel9) /* 0x190 */
- mxs_reg_32(hw_pinctrl_muxsel10) /* 0x1a0 */
- mxs_reg_32(hw_pinctrl_muxsel11) /* 0x1b0 */
- mxs_reg_32(hw_pinctrl_muxsel12) /* 0x1c0 */
- mxs_reg_32(hw_pinctrl_muxsel13) /* 0x1d0 */
+ mxs_reg_32(muxsel0) /* 0x100 */
+ mxs_reg_32(muxsel1) /* 0x110 */
+ mxs_reg_32(muxsel2) /* 0x120 */
+ mxs_reg_32(muxsel3) /* 0x130 */
+ mxs_reg_32(muxsel4) /* 0x140 */
+ mxs_reg_32(muxsel5) /* 0x150 */
+ mxs_reg_32(muxsel6) /* 0x160 */
+ mxs_reg_32(muxsel7) /* 0x170 */
+ mxs_reg_32(muxsel8) /* 0x180 */
+ mxs_reg_32(muxsel9) /* 0x190 */
+ mxs_reg_32(muxsel10)/* 0x1a0 */
+ mxs_reg_32(muxsel11)/* 0x1b0 */
+ mxs_reg_32(muxsel12)/* 0x1c0 */
+ mxs_reg_32(muxsel13)/* 0x1d0 */
uint32_treserved2[72];
- mxs_reg_32(hw_pinctrl_drive0) /* 0x300 */
- mxs_reg_32(hw_pinctrl_drive1) /* 0x310 */
- mxs_reg_32(hw_pinctrl_drive2) /* 0x320 */
- mxs_reg_32(hw_pinctrl_drive3) /* 0x330 */
- mxs_reg_32(hw_pinctrl_drive4) /* 0x340 */
- mxs_reg_32(hw_pinctrl_drive5) /* 0x350 */
- mxs_reg_32(hw_pinctrl_drive6) /* 0x360 */
- mxs_reg_32(hw_pinctrl_drive7) /* 0x370 */
- mxs_reg_32(hw_pinctrl_drive8) /* 0x380 */
- mxs_reg_32(hw_pinctrl_drive9) /* 0x390 */
- mxs_reg_32(hw_pinctrl_drive10) /* 0x3a0 */
- mxs_reg_32(hw_pinctrl_drive11) /* 0x3b0 */
- mxs_reg_32(hw_pinctrl_drive12) /* 0x3c0 */
- mxs_reg_32(hw_pinctrl_drive13) /* 0x3d0 */
- mxs_reg_32(hw_pinctrl_drive14) /* 0x3e0 */
- mxs_reg_32(hw_pinctrl_drive15) /* 0x3f0 */
- mxs_reg_32(hw_pinctrl_drive16) /* 0x400 */
- mxs_reg_32(hw_pinctrl_drive17) /* 0x410 */
- mxs_reg_32(hw_pinctrl_drive18) /* 0x420 */
- mxs_reg_32(hw_pinctrl_drive19) /* 0x430 */
+ mxs_reg_32(drive0) /* 0x300 */
+ mxs_reg_32(drive1) /* 0x310 */
+ mxs_reg_32(drive2) /* 0x320 */
+ mxs_reg_32(drive3) /* 0x330 */
+ mxs_reg_32(drive4) /* 0x340 */
+ mxs_reg_32(drive5) /* 0x350 */
+ mxs_reg_32(drive6) /* 0x360 */
+ mxs_reg_32(drive7) /* 0x370 */
+ mxs_reg_32(drive8) /* 0x380 */
+ mxs_reg_32(drive9) /* 0x390 */
+ mxs_reg_32(drive10) /* 0x3a0 */
+ mxs_reg_32(drive11) /* 0x3b0 */
+ mxs_reg_32(drive12) /* 0x3c0 */
+ mxs_reg_32(drive13) /* 0x3d0 */
+ mxs_reg_32(drive14
[U-Boot] [PATCH 3/9] mx23evk: Fix DDR pin iomux settings
From: Fabio Estevam
Registers HW_PINCTRL_DRIVE9, HW_PINCTRL_DRIVE10, HW_PINCTRL_DRIVE11,
HW_PINCTRL_DRIVE12, HW_PINCTRL_DRIVE13 and HW_PINCTRL_DRIVE14 control the drive
strength and the voltage selection for the DDR pins.
The reset values of the voltage selection pins are '1', which is marked as
'reserved' in the mx23 reference manual.
Clear these bits for proper operation of DDR.
Also change MUX_CONFIG_EMI, which results in better stability and match the
bootlets code from Freescale.
Signed-off-by: Fabio Estevam
---
board/freescale/mx23evk/spl_boot.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/board/freescale/mx23evk/spl_boot.c
b/board/freescale/mx23evk/spl_boot.c
index b6f4e7e..035a29c 100644
--- a/board/freescale/mx23evk/spl_boot.c
+++ b/board/freescale/mx23evk/spl_boot.c
@@ -26,7 +26,7 @@
#include
#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_12MA
const iomux_cfg_t iomux_setup[] = {
/* DUART */
@@ -110,5 +110,15 @@ void mxs_adjust_memory_params(uint32_t *dram_vals)
void board_init_ll(void)
{
+ struct mxs_pinctrl_regs *pinctrl =
+ (struct mxs_pinctrl_regs *)MXS_PINCTRL_BASE;
+ /* Clear the voltage bits for EMI pins as the reset value is invalid */
+ writel(0, &pinctrl->drive9);
+ writel(0, &pinctrl->drive10);
+ writel(0, &pinctrl->drive11);
+ writel(0, &pinctrl->drive12);
+ writel(0, &pinctrl->drive13);
+ writel(0, &pinctrl->drive14);
+ writel(0, &pinctrl->drive9);
mxs_common_spl_init(iomux_setup, ARRAY_SIZE(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 4/9] mx23_olinuxino: Fix DDR pin iomux settings
From: Fabio Estevam
Registers HW_PINCTRL_DRIVE9, HW_PINCTRL_DRIVE10, HW_PINCTRL_DRIVE11,
HW_PINCTRL_DRIVE12, HW_PINCTRL_DRIVE13 and HW_PINCTRL_DRIVE14 control the drive
strength and the voltage selection for the DDR pins.
The reset values of the voltage selection pins are '1', which is marked as
'reserved' in the mx23 reference manual.
Clear these bits for proper operation of DDR.
Also change MUX_CONFIG_EMI, which results in better stability and match the
bootlets code from Freescale.
Signed-off-by: Fabio Estevam
---
board/olimex/mx23_olinuxino/spl_boot.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c
b/board/olimex/mx23_olinuxino/spl_boot.c
index a96c293..5a43677 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -30,7 +30,7 @@
#include
#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
-#defineMUX_CONFIG_SSP (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_SSP MXS_PAD_12MA
const iomux_cfg_t iomux_setup[] = {
/* DUART */
@@ -103,5 +103,16 @@ const iomux_cfg_t iomux_setup[] = {
void board_init_ll(void)
{
+ struct mxs_pinctrl_regs *pinctrl =
+ (struct mxs_pinctrl_regs *)MXS_PINCTRL_BASE;
+
+ /* Clear the voltage bits for EMI pins as the reset value is invalid */
+ writel(0, &pinctrl->drive9);
+ writel(0, &pinctrl->drive10);
+ writel(0, &pinctrl->drive11);
+ writel(0, &pinctrl->drive12);
+ writel(0, &pinctrl->drive13);
+ writel(0, &pinctrl->drive14);
+ writel(0, &pinctrl->drive9);
mxs_common_spl_init(iomux_setup, ARRAY_SIZE(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 5/9] mx23evk: Disable the internal pad keepers
From: Fabio Estevam Disable the internal pad keepers to match the code from FSL bootlets and provide better stability. Signed-off-by: Fabio Estevam --- board/freescale/mx23evk/spl_boot.c |4 1 file changed, 4 insertions(+) diff --git a/board/freescale/mx23evk/spl_boot.c b/board/freescale/mx23evk/spl_boot.c index 035a29c..143aaed 100644 --- a/board/freescale/mx23evk/spl_boot.c +++ b/board/freescale/mx23evk/spl_boot.c @@ -120,5 +120,9 @@ void board_init_ll(void) writel(0, &pinctrl->drive13); writel(0, &pinctrl->drive14); writel(0, &pinctrl->drive9); + + /* Disable the internal pad keepers */ + writel(0x3, &pinctrl->pull3); + mxs_common_spl_init(iomux_setup, ARRAY_SIZE(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 7/9] mxs: spl_mem_init: Remove unneeded DRAM configurations
From: Fabio Estevam There is no need to write to DRAM_CTL8 register prior to nitialize_dram_values(). Fix a comment related to writing to DRAM_CTL8. Also, DRAM_CTL18 register on mx23 does not contain DRAM init complete bit, so remove this setting as this is also not done by FSL bootlets code. Signed-off-by: Fabio Estevam --- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 1c509d6..cde883d 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -262,12 +262,9 @@ static void mx23_mem_init(void) * Configure the DRAM registers */ - /* Clear START and SREFRESH bit from DRAM_CTL8 */ - clrbits_le32(MXS_DRAM_BASE + 0x20, (1 << 16) | (1 << 8)); - 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); @@ -279,10 +276,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 8/9] mxs: spl_mem_init: Skip the initialization of some DRAM_CTL registers
From: Fabio Estevam
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
---
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index cde883d..f500851 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -116,9 +116,12 @@ static void initialize_dram_values(void)
mxs_adjust_memory_params(dram_vals);
- for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
- writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
-
+ for (i = 0; i < ARRAY_SIZE(dram_vals); i++) {
+#ifdef CONFIG_MX23
+ if (!(i == 8 || i == 27 || i == 28 || i == 35))
+#endif
+ writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+ }
#ifdef CONFIG_MX23
/*
* Enable tRAS lockout in HW_DRAM_CTL08 ; it must be the last
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] mx23_olinuxino: Disable the internal pad keepers
From: Fabio Estevam Disable the internal pad keepers to match the code from FSL bootlets and provide better stability. Signed-off-by: Fabio Estevam --- board/olimex/mx23_olinuxino/spl_boot.c |4 1 file changed, 4 insertions(+) diff --git a/board/olimex/mx23_olinuxino/spl_boot.c b/board/olimex/mx23_olinuxino/spl_boot.c index 5a43677..65a9f41 100644 --- a/board/olimex/mx23_olinuxino/spl_boot.c +++ b/board/olimex/mx23_olinuxino/spl_boot.c @@ -114,5 +114,9 @@ void board_init_ll(void) writel(0, &pinctrl->drive13); writel(0, &pinctrl->drive14); writel(0, &pinctrl->drive9); + + /* Disable the internal pad keepers */ + writel(0x3, &pinctrl->pull3); + mxs_common_spl_init(iomux_setup, ARRAY_SIZE(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 9/9] mxs: spl_mem_init: Change EMI port priority
From: Fabio Estevam 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 --- 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 f500851..68b9587 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -274,7 +274,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 2/3] ARM: Tegra: USB: Add driver support for Tegra30/Tegra114
On Wed, May 1, 2013 at 12:33 PM, Marek Vasut wrote: > Dear Tom Rini, > > > On Wed, May 01, 2013 at 09:16:45AM -0700, Tom Warren wrote: > > > Tom, > > > > > > On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini wrote: > > > > On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote: > > > > > Marek, > > > > > > > > > > > -Original Message- > > > > > > From: Marek Vasut [mailto:ma...@denx.de] > > > > > > Sent: Monday, April 29, 2013 4:47 PM > > > > > > To: Jim Lin > > > > > > Cc: u-boot@lists.denx.de; Tom Warren; Stephen Warren > > > > > > Subject: Re: [PATCH 2/3] ARM: Tegra: USB: Add driver support for > > > > > > Tegra30/Tegra114 > > > > > > > > > > > > Dear Jim Lin, > > > > > > > > > > > > > Tegra30 and Tegra114 are compatible except 1. T30 takes 55 ms > to > > > > > > > finish Port Reset. T114 takes > > > > > > > > > > > > > >50 ms. > > > > > > > > > > > > > > 2. PLL parameters > > > > > > > > > > > > > > Tested on Tegra20 Harmony/Seaboard, Tegra30 Cardhu, and > Tegra114 > > > > > > > Dalmore platforms. All works well. > > > > > > > > > > > > > > Signed-off-by: Jim Lin > > > > > > > --- > > > > > > > > > > > > > > arch/arm/include/asm/arch-tegra/clk_rst.h | 10 + > > > > > > > arch/arm/include/asm/arch-tegra/usb.h | 249 > > > > > > > -- arch/arm/include/asm/arch-tegra114/tegra.h > | > > > > > > > 1 + > > > > > > > arch/arm/include/asm/arch-tegra114/usb.h | 287 > > > > > > > > > > > > + > > > > > > > > > > > > > arch/arm/include/asm/arch-tegra20/usb.h| 279 > > > > > > > > > > > > + > > > > > > > > > > > > > arch/arm/include/asm/arch-tegra30/usb.h| 294 > > > > > > > > > > > > ++ > > > > > > > > > > > > Do we now have three copies of the same stuff ? > > > > > > > > > > When only T20 was supported (for USB), there was a common > > > > > (arch-tegra/usb.h) header. That's been moved to arch-tegra20/usb.h, > > > > > and (unfortunately) there are 2 new usb.h files due to the HW > > > > > differences in the registers between T20 and T30/T114. I don't see > > > > > any easy way to have a common usb.h file for Tegra w/o adding ugly > > > > > #ifdefs to the USB register space struct(s). > > > > > > > > Just how different are they? Are all of the related defines and > masks > > > > different too? Do we have conflicts? Moved registers? Just > > > > conflicting values? A quick peek shows '30' and '114' are pretty > > > > similar, except for masks. Maybe splitting the struct up so you can > > > > discard some of the reserved gaps, run-time checking to see if we can > > > > or cannot use a particular part of the struct? > > > > > > This is really Jim's patchset (and his specialty), but here's what I > know > > > about Tegra USB regs: > > > > > > T20 had a gap in the registers @ offset 0x130. T30 (and T114) moved the > > > offset of the command/status/interrupt regs down to fill in this gap, > > > which dragged all the subsequent registers back 16 bytes. The two SoCs > > > 'families' sync up again at offset 0x400 and are pretty much equal from > > > there on out to 0x840. > > > > > > The defines are probably 90% the same, with some weirdness for the > first > > > USB controller (USB1) and its PTS/STS bits that differs in offset from > > > the other 2 controllers (again, no clue why the HW guys would do this). > > > > > > So we could have the 3 different USB headers in the arch-tegraXX area > > > contain the register structs, and have a common arch-tegra/usb.h that > has > > > the #defines that are the same, and is included in the > arch-tegraxx/usb.h > > > files. That would reduce this down somewhat, without the ugliness of > > > #ifdefs in the structs. > > > > > > What do you think? > > > > Sounds like the best we can do then. It's probable that trying to > > define USB_REGMAP_GAPSIZE1/2 or whatever to do it on the fly would just > > be uglier still. Thanks! > > This is a problem with the struct-based access indeed. I agree with Tom > it'd be > worth to at least try distilling the common part into header shared between > those three CPUs. > > btw you're also adding some kernel-doc-alike annotations to functions, why > don't > you follow kerneldoc style altogether? > I'll let Jim answer that. > > Best regards, > Marek Vasut > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: Tegra: USB: Add driver support for Tegra30/Tegra114
Adding Jim back into the conversation since he got dropped a couple of emails back. On Wed, May 1, 2013 at 4:20 PM, Tom Warren wrote: > > > > On Wed, May 1, 2013 at 12:33 PM, Marek Vasut wrote: > >> Dear Tom Rini, >> >> > On Wed, May 01, 2013 at 09:16:45AM -0700, Tom Warren wrote: >> > > Tom, >> > > >> > > On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini wrote: >> > > > On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote: >> > > > > Marek, >> > > > > >> > > > > > -Original Message- >> > > > > > From: Marek Vasut [mailto:ma...@denx.de] >> > > > > > Sent: Monday, April 29, 2013 4:47 PM >> > > > > > To: Jim Lin >> > > > > > Cc: u-boot@lists.denx.de; Tom Warren; Stephen Warren >> > > > > > Subject: Re: [PATCH 2/3] ARM: Tegra: USB: Add driver support for >> > > > > > Tegra30/Tegra114 >> > > > > > >> > > > > > Dear Jim Lin, >> > > > > > >> > > > > > > Tegra30 and Tegra114 are compatible except 1. T30 takes 55 ms >> to >> > > > > > > finish Port Reset. T114 takes >> > > > > > > >> > > > > > >50 ms. >> > > > > > > >> > > > > > > 2. PLL parameters >> > > > > > > >> > > > > > > Tested on Tegra20 Harmony/Seaboard, Tegra30 Cardhu, and >> Tegra114 >> > > > > > > Dalmore platforms. All works well. >> > > > > > > >> > > > > > > Signed-off-by: Jim Lin >> > > > > > > --- >> > > > > > > >> > > > > > > arch/arm/include/asm/arch-tegra/clk_rst.h | 10 + >> > > > > > > arch/arm/include/asm/arch-tegra/usb.h | 249 >> > > > > > > -- >> arch/arm/include/asm/arch-tegra114/tegra.h | >> > > > > > > 1 + >> > > > > > > arch/arm/include/asm/arch-tegra114/usb.h | 287 >> > > > > > >> > > > > > + >> > > > > > >> > > > > > > arch/arm/include/asm/arch-tegra20/usb.h| 279 >> > > > > > >> > > > > > + >> > > > > > >> > > > > > > arch/arm/include/asm/arch-tegra30/usb.h| 294 >> > > > > > >> > > > > > ++ >> > > > > > >> > > > > > Do we now have three copies of the same stuff ? >> > > > > >> > > > > When only T20 was supported (for USB), there was a common >> > > > > (arch-tegra/usb.h) header. That's been moved to >> arch-tegra20/usb.h, >> > > > > and (unfortunately) there are 2 new usb.h files due to the HW >> > > > > differences in the registers between T20 and T30/T114. I don't >> see >> > > > > any easy way to have a common usb.h file for Tegra w/o adding ugly >> > > > > #ifdefs to the USB register space struct(s). >> > > > >> > > > Just how different are they? Are all of the related defines and >> masks >> > > > different too? Do we have conflicts? Moved registers? Just >> > > > conflicting values? A quick peek shows '30' and '114' are pretty >> > > > similar, except for masks. Maybe splitting the struct up so you can >> > > > discard some of the reserved gaps, run-time checking to see if we >> can >> > > > or cannot use a particular part of the struct? >> > > >> > > This is really Jim's patchset (and his specialty), but here's what I >> know >> > > about Tegra USB regs: >> > > >> > > T20 had a gap in the registers @ offset 0x130. T30 (and T114) moved >> the >> > > offset of the command/status/interrupt regs down to fill in this gap, >> > > which dragged all the subsequent registers back 16 bytes. The two SoCs >> > > 'families' sync up again at offset 0x400 and are pretty much equal >> from >> > > there on out to 0x840. >> > > >> > > The defines are probably 90% the same, with some weirdness for the >> first >> > > USB controller (USB1) and its PTS/STS bits that differs in offset from >> > > the other 2 controllers (again, no clue why the HW guys would do >> this). >> > > >> > > So we could have the 3 different USB headers in the arch-tegraXX area >> > > contain the register structs, and have a common arch-tegra/usb.h that >> has >> > > the #defines that are the same, and is included in the >> arch-tegraxx/usb.h >> > > files. That would reduce this down somewhat, without the ugliness of >> > > #ifdefs in the structs. >> > > >> > > What do you think? >> > >> > Sounds like the best we can do then. It's probable that trying to >> > define USB_REGMAP_GAPSIZE1/2 or whatever to do it on the fly would just >> > be uglier still. Thanks! >> >> This is a problem with the struct-based access indeed. I agree with Tom >> it'd be >> worth to at least try distilling the common part into header shared >> between >> those three CPUs. >> >> btw you're also adding some kernel-doc-alike annotations to functions, >> why don't >> you follow kerneldoc style altogether? >> > > I'll let Jim answer that. > > >> >> 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 1/9] mxs: Make the names of the elements of mxs_pinctrl_regs shorter
Dear Fabio Estevam, > From: Fabio Estevam > > Currently when accessing an element of mxs_pinctrl_regs structure we do: > > &pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set > > The 'hw_pinctrl' prefix is a redundant information as we already know that > we are accessing a pinctrl register. > > Signed-off-by: Fabio Estevam Now this single file is inconsistent with the rest of the register header files. 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/9] mx23: regs-pinctrl.h: Add pinctrl support for mx23
Dear Fabio Estevam, > From: Fabio Estevam > > Provide a mxs_pinctrl_regs structure for mx23. > > Signed-off-by: Fabio Estevam So the pinctrl structure was always wrong on mx23? Otavio? 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 3/9] mx23evk: Fix DDR pin iomux settings
Dear Fabio Estevam,
> From: Fabio Estevam
>
> Registers HW_PINCTRL_DRIVE9, HW_PINCTRL_DRIVE10, HW_PINCTRL_DRIVE11,
> HW_PINCTRL_DRIVE12, HW_PINCTRL_DRIVE13 and HW_PINCTRL_DRIVE14 control the
> drive strength and the voltage selection for the DDR pins.
>
> The reset values of the voltage selection pins are '1', which is marked as
> 'reserved' in the mx23 reference manual.
>
> Clear these bits for proper operation of DDR.
>
> Also change MUX_CONFIG_EMI, which results in better stability and match the
> bootlets code from Freescale.
>
> Signed-off-by: Fabio Estevam
Uh, should the pinctrl/iomux stuff not set these up properly?
> ---
> board/freescale/mx23evk/spl_boot.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/board/freescale/mx23evk/spl_boot.c
> b/board/freescale/mx23evk/spl_boot.c index b6f4e7e..035a29c 100644
> --- a/board/freescale/mx23evk/spl_boot.c
> +++ b/board/freescale/mx23evk/spl_boot.c
> @@ -26,7 +26,7 @@
> #include
>
> #define MUX_CONFIG_SSP1 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
> -#define MUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
> +#define MUX_CONFIG_EMI MXS_PAD_12MA
>
> const iomux_cfg_t iomux_setup[] = {
> /* DUART */
> @@ -110,5 +110,15 @@ void mxs_adjust_memory_params(uint32_t *dram_vals)
>
> void board_init_ll(void)
> {
> + struct mxs_pinctrl_regs *pinctrl =
> + (struct mxs_pinctrl_regs *)MXS_PINCTRL_BASE;
> + /* Clear the voltage bits for EMI pins as the reset value is invalid */
> + writel(0, &pinctrl->drive9);
> + writel(0, &pinctrl->drive10);
> + writel(0, &pinctrl->drive11);
> + writel(0, &pinctrl->drive12);
> + writel(0, &pinctrl->drive13);
> + writel(0, &pinctrl->drive14);
> + writel(0, &pinctrl->drive9);
> mxs_common_spl_init(iomux_setup, ARRAY_SIZE(iomux_setup));
> }
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 4/9] mx23_olinuxino: Fix DDR pin iomux settings
Dear Fabio Estevam, > From: Fabio Estevam > > Registers HW_PINCTRL_DRIVE9, HW_PINCTRL_DRIVE10, HW_PINCTRL_DRIVE11, > HW_PINCTRL_DRIVE12, HW_PINCTRL_DRIVE13 and HW_PINCTRL_DRIVE14 control the > drive strength and the voltage selection for the DDR pins. > > The reset values of the voltage selection pins are '1', which is marked as > 'reserved' in the mx23 reference manual. > > Clear these bits for proper operation of DDR. > > Also change MUX_CONFIG_EMI, which results in better stability and match the > bootlets code from Freescale. > > Signed-off-by: Fabio Estevam Lost of duplicated code here. 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 7/9] mxs: spl_mem_init: Remove unneeded DRAM configurations
Dear Fabio Estevam, > From: Fabio Estevam > > There is no need to write to DRAM_CTL8 register prior to > nitialize_dram_values(). > > Fix a comment related to writing to DRAM_CTL8. > > Also, DRAM_CTL18 register on mx23 does not contain DRAM init complete bit, > so remove this setting as this is also not done by FSL bootlets code. > > Signed-off-by: Fabio Estevam > --- > arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |9 + > 1 file changed, 1 insertion(+), 8 deletions(-) > > diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c > b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 1c509d6..cde883d 100644 > --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c > +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c > @@ -262,12 +262,9 @@ static void mx23_mem_init(void) >* Configure the DRAM registers >*/ > > - /* Clear START and SREFRESH bit from DRAM_CTL8 */ > - clrbits_le32(MXS_DRAM_BASE + 0x20, (1 << 16) | (1 << 8)); > - Do you not need to stop the DRAM if it's already running? Like after a software reset? > 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); > @@ -279,10 +276,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 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 8/9] mxs: spl_mem_init: Skip the initialization of some DRAM_CTL registers
Dear Fabio Estevam,
> From: Fabio Estevam
>
> 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
> ---
> arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index cde883d..f500851 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> @@ -116,9 +116,12 @@ static void initialize_dram_values(void)
>
> mxs_adjust_memory_params(dram_vals);
>
> - for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
> - writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
> -
> + for (i = 0; i < ARRAY_SIZE(dram_vals); i++) {
> +#ifdef CONFIG_MX23
> + if (!(i == 8 || i == 27 || i == 28 || i == 35))
Stick a "continue" keyword here so it's contained instead of such a semi-
complete "if" clause please.
> +#endif
> + writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
> + }
> #ifdef CONFIG_MX23
> /*
>* Enable tRAS lockout in HW_DRAM_CTL08 ; it must be the last
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 1/9] mxs: Make the names of the elements of mxs_pinctrl_regs shorter
On Wed, May 1, 2013 at 8:26 PM, Marek Vasut wrote: > Dear Fabio Estevam, > >> From: Fabio Estevam >> >> Currently when accessing an element of mxs_pinctrl_regs structure we do: >> >> &pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set >> >> The 'hw_pinctrl' prefix is a redundant information as we already know that >> we are accessing a pinctrl register. >> >> Signed-off-by: Fabio Estevam > > Now this single file is inconsistent with the rest of the register header > files. I can change the other header files as well. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] mx23: regs-pinctrl.h: Add pinctrl support for mx23
On Wed, May 1, 2013 at 8:27 PM, Marek Vasut wrote: > Dear Fabio Estevam, > >> From: Fabio Estevam >> >> Provide a mxs_pinctrl_regs structure for mx23. >> >> Signed-off-by: Fabio Estevam > > So the pinctrl structure was always wrong on mx23? Otavio? pinctrl structure was never used on mx23 in U-boot. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] mx23_olinuxino: Fix DDR pin iomux settings
On Wed, May 1, 2013 at 8:28 PM, Marek Vasut wrote: > Lost of duplicated code here. What do you suggest? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] mxs: spl_mem_init: Remove unneeded DRAM configurations
On Wed, May 1, 2013 at 8:29 PM, Marek Vasut wrote: > Do you not need to stop the DRAM if it's already running? Like after a > software > reset? I don't think this is needed. FSL bootlets code does not do this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] mx23evk: Fix DDR pin iomux settings
On Wed, May 1, 2013 at 8:28 PM, Marek Vasut wrote: > Uh, should the pinctrl/iomux stuff not set these up properly? This is mx23 and EMI pins specific, so I think it is OK to do it in the board file. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] mxs: Make the names of the elements of mxs_pinctrl_regs shorter
Dear Fabio Estevam, > On Wed, May 1, 2013 at 8:26 PM, Marek Vasut wrote: > > Dear Fabio Estevam, > > > >> From: Fabio Estevam > >> > >> Currently when accessing an element of mxs_pinctrl_regs structure we do: > >> > >> &pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set > >> > >> The 'hw_pinctrl' prefix is a redundant information as we already know > >> that we are accessing a pinctrl register. > >> > >> Signed-off-by: Fabio Estevam > > > > Now this single file is inconsistent with the rest of the register header > > files. > > I can change the other header files as well. Yes, but a separate patchset can do that. Let's keep it consistent please. 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/9] mx23: regs-pinctrl.h: Add pinctrl support for mx23
Dear Fabio Estevam, > On Wed, May 1, 2013 at 8:27 PM, Marek Vasut wrote: > > Dear Fabio Estevam, > > > >> From: Fabio Estevam > >> > >> Provide a mxs_pinctrl_regs structure for mx23. > >> > >> Signed-off-by: Fabio Estevam > > > > So the pinctrl structure was always wrong on mx23? Otavio? > > pinctrl structure was never used on mx23 in U-boot. How come? Doesn't the board/...mx23.../spl_boot.c use that? Or iomux.c in FSL's parlance. 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 3/9] mx23evk: Fix DDR pin iomux settings
Dear Fabio Estevam, > On Wed, May 1, 2013 at 8:28 PM, Marek Vasut wrote: > > Uh, should the pinctrl/iomux stuff not set these up properly? > > This is mx23 and EMI pins specific, so I think it is OK to do it in > the board file. Yes, but should the iomux_setup[] configure that already? 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 4/9] mx23_olinuxino: Fix DDR pin iomux settings
Dear Fabio Estevam, > On Wed, May 1, 2013 at 8:28 PM, Marek Vasut wrote: > > Lost of duplicated code here. > > What do you suggest? Stuff it into common init sequence, but only if it really is necessary to wipe those registers and iomux_setup[] table doesn't do it for some reason. But then, if iomux_setup[] table doesn't configure them, there's a deeper problem. 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 7/9] mxs: spl_mem_init: Remove unneeded DRAM configurations
Dear Fabio Estevam, > On Wed, May 1, 2013 at 8:29 PM, Marek Vasut wrote: > > Do you not need to stop the DRAM if it's already running? Like after a > > software reset? > > I don't think this is needed. FSL bootlets code does not do this. You'll end up messing with configuration registers on already-running RAM. That doesn't really make sense and I suspect it can result in some weird behavior. 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 7/9] mxs: spl_mem_init: Remove unneeded DRAM configurations
On Wed, May 1, 2013 at 9:15 PM, Marek Vasut wrote: > You'll end up messing with configuration registers on already-running RAM. > That HW_DRAM_CTL08, bit 16 (START) is 0 (inactive) after a reset, so no need to turn off the RAM. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] mx23: regs-pinctrl.h: Add pinctrl support for mx23
On Wed, May 1, 2013 at 9:13 PM, Marek Vasut wrote:
> How come? Doesn't the board/...mx23.../spl_boot.c use that? Or iomux.c in
> FSL's
> parlance.
I meant mxs_pinctrl_regs structure is only referenced for mx28 currently:
#ifdef CONFIG_MX28
static void mx28_mem_init(void)
{
struct mxs_pinctrl_regs *pinctrl_regs =
(struct mxs_pinctrl_regs *)MXS_PINCTRL_BASE;
/* Set DDR2 mode */
writel(PINCTRL_EMI_DS_CTRL_DDR_MODE_DDR2,
&pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/11] usb: ehci: add Faraday USB 2.0 EHCI support
2013/5/2 Marek Vasut :
> Dear Kuo-Jung Su,
>
>> 2013/4/30 Marek Vasut :
>> > Dear Kuo-Jung Su,
>> >
>> >> 2013/4/26 Marek Vasut :
>> >> > Dear Kuo-Jung Su,
>> >> >
>> >> >> From: Kuo-Jung Su
>> >> >>
>> >> >> This patch add supports to both Faraday FUSBH200 and FOTG210,
>> >> >> these controllers slightly differ from standard EHCI specification.
>> >> >
>> >> > How do they differ?
>> >>
>> >> 1. The reserved registers (0x1C - 0x3F) and CONFIGFLAG (0x40) register
>> >>
>> >> are not only un-implemented, but also removed from its register
>> >> address space, which means we have to update the 'struct ehci_hcor'
>> >> of ehci.h
>> >>
>> >> 2. FUSBH200/FOTG210 doesn't properly follow the ECHI for ISOC
>> >> implementations. (It should be a hardware bug, but no one wants to fix
>> >> it.)
>> >>
>> >> I'll add these description to commit log at next patch.
>> >
>> > Mhmmm ... maybe you can add some hooks into ehci-hcd driver instead of
>> > poluting it with ifdefs ? Weak-aliased functions would probably work
>> > best to contain your weird stuff in your driver only.
>>
>> Did you mean 'Not poluting ehci.h with ifdefs' ?
>>
>> It looks to me that the best way is to leave ehci.h untouched, and
>> update the ehci_submit_root() as following:
>>
>> ehci_submit_root()
>> {
>> ..
>> #ifdef CONFIG_USB_EHCI_FARADAY
>> status_reg = (uint32_t *)((uint8_t *)&ctrl->hcor + 0x30);
>> #else
>> status_reg = (uint32_t *)&ctrl->hcor->or_portsc[
>> le16_to_cpu(req->index) - 1];
>> #endif
>> ..
>> }
>> --
>>
>> Would it be acceptable in this way?
>>
>> If it's not, I'll make this patch as a separate patch with some hooks
>> into ehci-hcd.
>
> What about defining a
>
> __weak uint32_t get_status_register()
> {
> ...
> }
>
> function and override it's implementation in your driver?
>
That's a great idea, I'll update it in this way at next version.
Thanks
> Best regards,
> Marek Vasut
--
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 2/9] mx23: regs-pinctrl.h: Add pinctrl support for mx23
Dear Fabio Estevam,
> On Wed, May 1, 2013 at 9:13 PM, Marek Vasut wrote:
> > How come? Doesn't the board/...mx23.../spl_boot.c use that? Or iomux.c in
> > FSL's parlance.
>
> I meant mxs_pinctrl_regs structure is only referenced for mx28 currently:
>
> #ifdef CONFIG_MX28
> static void mx28_mem_init(void)
> {
> struct mxs_pinctrl_regs *pinctrl_regs =
> (struct mxs_pinctrl_regs *)MXS_PINCTRL_BASE;
>
> /* Set DDR2 mode */
> writel(PINCTRL_EMI_DS_CTRL_DDR_MODE_DDR2,
> &pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set);
Ah! Good point, sorry for the prodding then.
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 4/9] mx23_olinuxino: Fix DDR pin iomux settings
On Wed, May 1, 2013 at 9:14 PM, Marek Vasut wrote: > Stuff it into common init sequence, but only if it really is necessary to wipe > those registers and iomux_setup[] table doesn't do it for some reason. > > But then, if iomux_setup[] table doesn't configure them, there's a deeper > problem. Right, I managed to fix this as you suggested (via iomux_setup). Will send it in v2. Thanks for reviewing it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot for cavium octeon 2 MIPS SOC
Hi to all. Someone has experience in initialization DDR3 RAM 32bit width mode for this processor? Thanks -- View this message in context: http://u-boot.10912.n7.nabble.com/uboot-for-cavium-octeon-2-MIPS-SOC-tp153711.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
Re: [U-Boot] [PATCH] powerpc/mpc85xx: add setting of clock-frequency for mpic node
Hi Andy, Could you please apply this patch? http://patchwork.ozlabs.org/patch/217104/ Thanks. - dongsheng > -Original Message- > From: Wang Dongsheng-B40534 > Sent: Monday, March 11, 2013 5:31 PM > To: Fleming Andy-AFLEMING > Cc: 'u-boot@lists.denx.de' > Subject: RE: [PATCH] powerpc/mpc85xx: add setting of clock-frequency for > mpic node > > Hi Andy, > > Could you please apply this patch? > > - dongsheng > > > -Original Message- > > From: Wang Dongsheng-B40534 > > Sent: Tuesday, March 05, 2013 10:14 AM > > To: 'york...@freescale.com' > > Cc: Fleming Andy-AFLEMING; 'u-boot@lists.denx.de' > > Subject: RE: [PATCH] powerpc/mpc85xx: add setting of clock-frequency > > for mpic node > > > > Hi york, > > > > Could you ack this patch? > > > > Thanks. > > > > > -Original Message- > > > From: Wang Dongsheng-B40534 > > > Sent: Monday, February 25, 2013 2:22 PM > > > To: Fleming Andy-AFLEMING > > > Cc: u-boot@lists.denx.de > > > Subject: RE: [PATCH] powerpc/mpc85xx: add setting of clock-frequency > > > for mpic node > > > > > > Hi Andy, > > > > > > Could you ack this patch? > > > > > > Thanks. > > > > > > > -Original Message- > > > > From: Wang Dongsheng-B40534 > > > > Sent: Thursday, January 31, 2013 12:52 PM > > > > To: u-boot@lists.denx.de > > > > Cc: Wang Dongsheng-B40534 > > > > Subject: [PATCH] powerpc/mpc85xx: add setting of clock-frequency > > > > for > > > mpic > > > > node > > > > > > > > Set the device tree property associated with the mpic source > > > > frequency. The frequency is used for mpic timer. > > > > > > > > Signed-off-by: Wang Dongsheng > > > > --- > > > > arch/powerpc/cpu/mpc85xx/fdt.c |5 + > > > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c > > > > b/arch/powerpc/cpu/mpc85xx/fdt.c index 3a268aa..f07d1cf 100644 > > > > --- a/arch/powerpc/cpu/mpc85xx/fdt.c > > > > +++ b/arch/powerpc/cpu/mpc85xx/fdt.c > > > > @@ -663,6 +663,11 @@ void ft_cpu_setup(void *blob, bd_t *bd) > > > > #ifdef CONFIG_FSL_CORENET > > > > do_fixup_by_compat_u32(blob, "fsl,qoriq-clockgen-1.0", > > > > "clock-frequency", CONFIG_SYS_CLK_FREQ, 1); > > > > + do_fixup_by_compat_u32(blob, "fsl,mpic", > > > > + "clock-frequency", get_bus_freq(0)/2, 1); #else > > > > + do_fixup_by_compat_u32(blob, "fsl,mpic", > > > > + "clock-frequency", get_bus_freq(0), 1); > > > > #endif > > > > > > > > fdt_fixup_memory(blob, (u64)bd->bi_memstart, > > > > (u64)bd->bi_memsize); > > > > -- > > > > 1.7.5.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] questions about dp83848 on mpc8315e board
Hello, I'm using customized mpc8315e board with a PHY called DP83848 , I have changed tsec file to support DP83848, and link's status led is blinkging after cable is connected to PC. But when I set the ip etc and to ping a PC , I got this error: > ping 192.168.2.157 Trying eTSEC0 startup_tsec mii_parse_dp83848_bmsr:priv->duplexity:1,priv->speed:100Speed: 100, full duplex Using eTSEC0 device eTSEC0: tsec: tx error eTSEC0: tsec: tx buffers full ping failed; host 192.168.2.157 is not alive I'm using MII interface connecting MPC8315e and DP83848, what could be the possible reason for this ? Below is my MPC8315ERDB.h file. /* * Copyright (C) 2007, 2009 Freescale Semiconductor, Inc. * * Dave Liu * Jerry Huang * * 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 __CONFIG_H #define __CONFIG_H /* * High Level Configuration Options */ #define CONFIG_E3001 /* E300 family */ #define CONFIG_MPC83XX1 /* MPC83xx family */ #define CONFIG_MPC831X1 /* MPC831x CPU family */ #define CONFIG_MPC83151 /* MPC8315 CPU specific */ #define CONFIG_MPC8315ERDB1 /* MPC8315ERDB board specific */ /* * System Clock Setup */ #define CONFIG_83XX_CLKIN6667 /* in Hz */ #define CONFIG_SYS_CLK_FREQCONFIG_83XX_CLKIN #ifdef CONFIG_PCISLAVE #define CONFIG_PCI #define CONFIG_83XX_PCICLK6667 /* in Hz */ #endif /* CONFIG_PCISLAVE */ /* * The 8315 silicon has three speed grade, they are * A: CORE/CSB = 400MHz/133MHz * B: CORE/CSB = 333MHz/133MHz * C: CORE/CSB = 266MHz/133MHz * Hardware Reset Configuration Word * if CLKIN is 66.66MHz, then * CSB = 133MHz, DDRC = 266MHz, LBC = 133MHz * We choose the A type silicon as default, so the core is 400Mhz. */ #define CONFIG_SYS_FREQ_400MHz1 #define CONFIG_SYS_FREQ_333MHz2 #define CONFIG_SYS_FREQ_266MHz3 #ifndef CONFIG_CORE_FREQ #define CONFIG_CORE_FREQCONFIG_SYS_FREQ_400MHz #endif #if (CONFIG_CORE_FREQ == CONFIG_SYS_FREQ_266MHz) #define CONFIG_SYS_HRCW_LOW (\ HRCWL_LCL_BUS_TO_SCB_CLK_1X1 |\ HRCWL_DDR_TO_SCB_CLK_2X1 |\ HRCWL_SVCOD_DIV_2 |\ HRCWL_CSB_TO_CLKIN_2X1 |\ HRCWL_CORE_TO_CSB_2X1) #elif (CONFIG_CORE_FREQ == CONFIG_SYS_FREQ_333MHz) #define CONFIG_SYS_HRCW_LOW (\ HRCWL_LCL_BUS_TO_SCB_CLK_1X1 |\ HRCWL_DDR_TO_SCB_CLK_2X1 |\ HRCWL_SVCOD_DIV_2 |\ HRCWL_CSB_TO_CLKIN_2X1 |\ HRCWL_CORE_TO_CSB_2_5X1) #else #define CONFIG_SYS_HRCW_LOW (\ HRCWL_LCL_BUS_TO_SCB_CLK_1X1 |\ HRCWL_DDR_TO_SCB_CLK_2X1 |\ HRCWL_SVCOD_DIV_2 |\ HRCWL_CSB_TO_CLKIN_2X1 |\ HRCWL_CORE_TO_CSB_3X1) #endif #ifdef CONFIG_NAND_SPL #ifdef CONFIG_PCISLAVE #define CONFIG_SYS_HRCW_HIGH (\ HRCWH_PCI_AGENT |\ HRCWH_PCI_ARBITER_DISABLE |\ HRCWH_CORE_ENABLE |\ HRCWH_FROM_0XFFF00100 |\ HRCWH_BOOTSEQ_DISABLE |\ HRCWH_SW_WATCHDOG_DISABLE |\ HRCWH_ROM_LOC_NAND_SP_8BIT |\ HRCWH_RL_EXT_NAND |\ HRCWH_TSEC1M_IN_RGMII |\ HRCWH_TSEC2M_IN_RGMII |\ HRCWH_BIG_ENDIAN |\ HRCWH_LALE_NORMAL) #else #define CONFIG_SYS_HRCW_HIGH (\ HRCWH_PCI_HOST |\ HRCWH_PCI_ARBITER_ENABLE |\ HRCWH_CORE_ENABLE |\ HRCWH_FROM_0XFFF00100 |\ HRCWH_BOOTSEQ_DISABLE |\ HRCWH_SW_WATCHDOG_DISABLE |\ HRCWH_ROM_LOC_NAND_SP_8BIT |\ HRCWH_RL_EXT_NAND |\ HRCWH_TSEC1M_IN_RGMII |\ HRCWH_TSEC2M_IN_RGMII |\ HRCWH_BIG_ENDIAN |\ HRCWH_LALE_NORMAL) #endif #else #ifdef CONFIG_PCISLAVE #define CONFIG_SYS_HRCW_HIGH (\ HRCWH_PCI_AGENT |\ HRCWH_PCI1_ARBITER_DISABLE |\ HRCWH_CORE_ENABLE |\ HRCWH_FROM_0X0100 |\ HRCWH_BOOTSEQ_DISABLE |\ HRCWH_SW_WATCHDOG_DISABLE |\ HRCWH_ROM_LOC_LOCAL_16BIT |\ HRCWH_RL_EXT_LEGACY |\ HRCWH_TSEC1M_IN_RGMII |\ HRCWH_TSEC2M_IN_RGMII |\ HRCWH_BIG_ENDIAN |\ HRCWH_LALE_NORMAL) #else #define CONFIG_SYS_HRCW_HIGH (\ HRCWH_PCI_HOST |\ HRCWH_PCI1_ARBITER_ENABLE |\ HRCWH_CORE_ENABLE |\ HRCWH_FROM_0X0100 |\ HRCWH_BOOTSEQ_DISABLE |\ HRCWH_SW_WATCHDOG_DISABLE |\ HRCWH_ROM_LOC_LOCAL_16BIT |\ HRCWH_RL_EXT_LEGACY |\ HRCWH_TSEC1M_IN_RGMII |\ HRCWH_TSEC2M_IN_RGMII |\ HRCWH_BIG_ENDIAN |\ HRCWH_LALE_NORMAL) #endif #endif /* * System IO Config */ #define CONFIG_SYS_SICRH0x #define CONFIG_SYS_SICRL0x /* 3.3V, no delay */ #define CONFIG_BOARD_EARLY_INIT_F /* call board_pre_init */ /* * IMMR new address */ #define CONFIG_SYS_IMMR0xE000 /* * Arbiter Setup */ #define CONFIG_SYS_ACR_PIPE_DEP3 /* Arbiter pipeline depth is 4 */ #define CONFIG_SYS_ACR_RPTCNT3 /* Arbiter repeat count is
[U-Boot] [PATCH v1] bfin: Move gpio support for bf54x and bf60x into the generic driver folder.
From: Sonic Zhang
The gpio spec for bf54x and bf60x differ a lot from the old gpio driver for
bf5xx.
A lot of machine macros are used to accomodate both code in one gpio driver.
This patch split the old gpio driver and move new gpio2 support to the generic
gpio driver folder.
- To enable gpio2 driver, macro CONFIG_ADI_GPIO2 should be defined in the
board's
config header file.
- The gpio2 driver supports bf54x, bf60x and future ADI processors, while the
older gpio driver supports bf50x, bf51x, bf52x, bf53x and bf561.
- All blackfin specific gpio function names are replaced by the generic gpio
APIs.
Signed-off-by: Sonic Zhang
---
arch/blackfin/cpu/Makefile |2 +-
arch/blackfin/cpu/gpio.c| 145 ++--
arch/blackfin/include/asm/gpio.h| 62 +
arch/blackfin/include/asm/portmux.h |5 -
drivers/gpio/Makefile |1 +
drivers/gpio/adi_gpio2.c| 440 +++
include/configs/bf548-ezkit.h |2 +
include/configs/bf609-ezkit.h |2 +
include/configs/bfin_adi_common.h |4 +-
9 files changed, 479 insertions(+), 184 deletions(-)
create mode 100644 drivers/gpio/adi_gpio2.c
diff --git a/arch/blackfin/cpu/Makefile b/arch/blackfin/cpu/Makefile
index 929fc8b..1421cb2 100644
--- a/arch/blackfin/cpu/Makefile
+++ b/arch/blackfin/cpu/Makefile
@@ -18,7 +18,7 @@ CEXTRA := initcode.o
SEXTRA := start.o
SOBJS:= interrupt.o cache.o
COBJS-y += cpu.o
-COBJS-y += gpio.o
+COBJS-$(CONFIG_ADI_GPIO1) += gpio.o
COBJS-y += interrupts.o
COBJS-$(CONFIG_JTAG_CONSOLE) += jtag-console.o
COBJS-y += os_log.o
diff --git a/arch/blackfin/cpu/gpio.c b/arch/blackfin/cpu/gpio.c
index f684be5..f74a0b7 100644
--- a/arch/blackfin/cpu/gpio.c
+++ b/arch/blackfin/cpu/gpio.c
@@ -1,5 +1,6 @@
/*
- * GPIO Abstraction Layer
+ * ADI GPIO1 Abstraction Layer
+ * Support BF50x, BF51x, BF52x, BF53x and BF561 only.
*
* Copyright 2006-2010 Analog Devices Inc.
*
@@ -55,25 +56,6 @@ static struct gpio_port_t * const gpio_array[] = {
(struct gpio_port_t *) FIO0_FLAG_D,
(struct gpio_port_t *) FIO1_FLAG_D,
(struct gpio_port_t *) FIO2_FLAG_D,
-#elif defined(CONFIG_BF54x)
- (struct gpio_port_t *)PORTA_FER,
- (struct gpio_port_t *)PORTB_FER,
- (struct gpio_port_t *)PORTC_FER,
- (struct gpio_port_t *)PORTD_FER,
- (struct gpio_port_t *)PORTE_FER,
- (struct gpio_port_t *)PORTF_FER,
- (struct gpio_port_t *)PORTG_FER,
- (struct gpio_port_t *)PORTH_FER,
- (struct gpio_port_t *)PORTI_FER,
- (struct gpio_port_t *)PORTJ_FER,
-#elif defined(CONFIG_BF60x)
- (struct gpio_port_t *)PORTA_FER,
- (struct gpio_port_t *)PORTB_FER,
- (struct gpio_port_t *)PORTC_FER,
- (struct gpio_port_t *)PORTD_FER,
- (struct gpio_port_t *)PORTE_FER,
- (struct gpio_port_t *)PORTF_FER,
- (struct gpio_port_t *)PORTG_FER,
#else
# error no gpio arrays defined
#endif
@@ -174,12 +156,6 @@ DECLARE_RESERVED_MAP(peri, gpio_bank(MAX_RESOURCES));
inline int check_gpio(unsigned gpio)
{
-#if defined(CONFIG_BF54x)
- if (gpio == GPIO_PB15 || gpio == GPIO_PC14 || gpio == GPIO_PC15
- || gpio == GPIO_PH14 || gpio == GPIO_PH15
- || gpio == GPIO_PJ14 || gpio == GPIO_PJ15)
- return -EINVAL;
-#endif
if (gpio >= MAX_BLACKFIN_GPIOS)
return -EINVAL;
return 0;
@@ -218,18 +194,6 @@ static void port_setup(unsigned gpio, unsigned short usage)
else
*port_fer[gpio_bank(gpio)] |= gpio_bit(gpio);
SSYNC();
-#elif defined(CONFIG_BF54x)
- if (usage == GPIO_USAGE)
- gpio_array[gpio_bank(gpio)]->port_fer &= ~gpio_bit(gpio);
- else
- gpio_array[gpio_bank(gpio)]->port_fer |= gpio_bit(gpio);
- SSYNC();
-#elif defined(CONFIG_BF60x)
- if (usage == GPIO_USAGE)
- gpio_array[gpio_bank(gpio)]->port_fer_clear = gpio_bit(gpio);
- else
- gpio_array[gpio_bank(gpio)]->port_fer_set = gpio_bit(gpio);
- SSYNC();
#endif
}
@@ -304,30 +268,6 @@ static void portmux_setup(unsigned short per)
}
}
}
-#elif defined(CONFIG_BF54x) || defined(CONFIG_BF60x)
-inline void portmux_setup(unsigned short per)
-{
- u32 pmux;
- u16 ident = P_IDENT(per);
- u16 function = P_FUNCT2MUX(per);
-
- pmux = gpio_array[gpio_bank(ident)]->port_mux;
-
- pmux &= ~(0x3 << (2 * gpio_sub_n(ident)));
- pmux |= (function & 0x3) << (2 * gpio_sub_n(ident));
-
- gpio_array[gpio_bank(ident)]->port_mux = pmux;
-}
-
-inline u16 get_portmux(unsigned short per)
-{
- u32 pmux;
- u16 ident = P_IDENT(per);
-
- pmux = gpio_array[gpio_bank(ident)]->port_mux;
-
- return (pmux >> (2 * gpio_sub_n(ident)) & 0x3);
-}
#elif defined(CONFIG_BF52x) || defined(CONFIG_BF51x)
inline void portmux_setup(unsigned short per)
{
@@ -344,7 +284,6 @@ inline void por
[U-Boot] R: Beginner question: need help about LVDS channels for i.MX6Q SabreSD Board
Hi Fabio, Sorry for not replying sooner. I want to enable two LVDS channels because I noticed that the kernel does not "seem" to initialize properly them if they are not initialized before by the bootloader. I'm also trying to understand the reason for this behavior. Igor Hi Igor, On Fri, Apr 26, 2013 at 12:17 PM, Igor Ferrara wrote: > Hi, > I have a Freescale SabreSD board with an i.MX6 quad-core processor. > I'm using u-boot-2009.08 (released with Freescale's LTIB) This list is about the official U-boot project, not the 2009.08 port from FSL. > I would like to enable both LVDS channels. In mainline U-boot there is support for one LVDS panel in mx6qsabrelite board. You can use it as reference and add LVDS panel support in mx6qsabresd. Please send us the patches. > In the "lcd_enable" func (file: / > board/freescale/mx6q_sabresd/mx6q_sabresd.c) I properly changed some > registers following the advice of Freescale but I could not enable the > second channel: > https://community.freescale.com/docs/DOC-93617 > Furthermore, the "ipuv3_fb_init" func is used to initialize a single > Display Interface. > Can you give me some advice to enable both channels? What is exactly your use case? Do you really need dual display support in U-boot? Can't you just boot fast and use the dual display support that kernel already provides? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
