[U-Boot] CAN framework in U-Boot
Hi Wolfgang G. and list, I was looking to do some basic tests on a C_CAN module inside our SOC at u-boot level, till the Linux OS is up and working to test basic CAN features. I couldn't figure out if CAN framework is supported in u-boot and would really appreciate if someone can help me out regarding the same. I could see the sja1000 header present inside 'include/sja1000.h', and some old patches from Wolfgang G. (see [1]), but couldn't figure out if these patches were accepted into u-boot. Any help will be much appreaciated. [1]. http://article.gmane.org/gmane.comp.boot-loaders.u-boot/70864 Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/45] Verified boot implementation based on FIT
Hi Tom, On Thu, Apr 25, 2013 at 11:51 AM, Simon Glass s...@chromium.org wrote: Hi Tom, On Tue, Apr 23, 2013 at 7:50 AM, Tom Rini tr...@ti.com wrote: On Mon, Apr 22, 2013 at 06:44:53PM -0500, Kim Phillips wrote: On Sat, 20 Apr 2013 16:03:20 -0700 Simon Glass s...@chromium.org wrote: On Mon, Apr 1, 2013 at 5:13 PM, Kim Phillips kim.phill...@freescale.com wrote: On Mon, 18 Mar 2013 16:51:20 -0700 Simon Glass s...@chromium.org wrote: I have received a number of off-list comments - please do copy the list when replying so that everyone can see your comments. I don't have time to fully review 45 patches, let alone the subject matter (e.g., no support for RSA in h/w, eh? ;), but I did notice some things that bugged me: Re: [PATCH v2 04/45] libfdt: Add fdt_next_subnode() to permit easy subnode iteration: - Where's our libfdt maintainer? libfdt patches should be submitted to the dtc project first. It appears [PATCH v2 40/45] libfdt: Add fdt_find_regions() also suffers from this problem. The fdt_next_subnode() is a pretty trivial change. I will submit it to the dtc project. Ideally we'd apply the patch directly from how it was applied to the upstream dtc project. And importantly, that's how we try and work this area in general. Get it upstream into dtc, mirror the change. So lets get all of the fdt related stuff there and pull it back down. Yes - the major patch was sent back around the same time as the verified boot series, along with an fdtgrep tool. I sent the fdt_next_subnode() patch earlier today. OK this was accepted to dtc upstream in modified form. I will update the series for U-Boot. In case you want an update on the overall work, I have now split things into: sandbox - http://patchwork.ozlabs.org/bundle/sjg/sandbox/ and I sent a pull request if you want this image1 - Allow images to work on sandbox, sent, needs this libfdt patch replaced image2 - Introduce a common image_setup_linux() function, to send image3 - image: Reduce code duplication and refactor, to send vboot - Verified boot implementation based on FIT, final series, to send I will do image1 in the next few days, and the rest hopefully next week. I think it makes sense having vboot last. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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 ag...@denx.de Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Stefano Babic sba...@denx.de --- 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 +# Refer doc/README.kwbimage for more details about how-to
[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 michal.si...@xilinx.com
---
Changes in v2:
- Fix compilation warnings
drivers/fpga/fpga.c | 216
1 file changed, 98 insertions(+), 118 deletions(-)
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 26d2443..ddebd49 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -22,122 +22,99 @@
*
*/
-/*
- * Generic FPGA support
- */
+/* Generic FPGA support */
#include common.h /* core U-Boot definitions */
#include xilinx.h /* xilinx specific definitions */
#include altera.h /* altera specific definitions */
#include lattice.h
-#if 0
-#define FPGA_DEBUG /* define FPGA_DEBUG to get debug messages */
-#endif
-
/* Local definitions */
#ifndef CONFIG_MAX_FPGA_DEVICES
#define CONFIG_MAX_FPGA_DEVICES5
#endif
-/* Enable/Disable debug console messages */
-#ifdef FPGA_DEBUG
-#definePRINTF(fmt,args...) printf (fmt ,##args)
-#else
-#definePRINTF(fmt,args...)
-#endif
-
/* Local static data */
static int next_desc = FPGA_INVALID_DEVICE;
static fpga_desc desc_table[CONFIG_MAX_FPGA_DEVICES];
-/* Local static functions */
-static __attribute__((__const__)) fpga_desc * __attribute__((__const__))
fpga_get_desc( int devnum );
-static __attribute__((__const__)) fpga_desc * __attribute__((__const__))
fpga_validate(int devnum, const void *buf,
-size_t bsize, char *fn );
-static int fpga_dev_info( int devnum );
-
-
-/* - */
-
-/* fpga_no_sup
+/*
+ * fpga_no_sup
* 'no support' message function
*/
-static void fpga_no_sup( char *fn, char *msg )
+static void fpga_no_sup(char *fn, char *msg)
{
- if ( fn msg ) {
- printf( %s: No support for %s.\n, fn, msg);
- } else if ( msg ) {
- printf( No support for %s.\n, msg);
- } else {
- printf( No FPGA suport!\n);
- }
+ if (fn msg)
+ printf(%s: No support for %s.\n, fn, msg);
+ else if (msg)
+ printf(No support for %s.\n, msg);
+ else
+ printf(No FPGA suport!\n);
}
/* fpga_get_desc
* map a device number to a descriptor
*/
-static __attribute__((__const__)) fpga_desc * __attribute__((__const__))
fpga_get_desc( int devnum )
+static const fpga_desc *const fpga_get_desc(int devnum)
{
- fpga_desc *desc = (fpga_desc * )NULL;
+ fpga_desc *desc = (fpga_desc *)NULL;
- if (( devnum = 0 ) (devnum next_desc )) {
+ if ((devnum = 0) (devnum next_desc)) {
desc = desc_table[devnum];
- PRINTF( %s: found fpga descriptor #%d @ 0x%p\n,
- __FUNCTION__, devnum, desc );
+ debug(%s: found fpga descriptor #%d @ 0x%p\n,
+ __func__, devnum, desc);
}
return desc;
}
-
-/* fpga_validate
+/*
+ * fpga_validate
* generic parameter checking code
*/
-static __attribute__((__const__)) fpga_desc * __attribute__((__const__))
fpga_validate(int devnum, const void *buf,
-size_t bsize, char *fn )
+static const fpga_desc *const fpga_validate(int devnum, const void *buf,
+size_t bsize, char *fn)
{
- fpga_desc * desc = fpga_get_desc( devnum );
+ const fpga_desc *desc = fpga_get_desc(devnum);
- if ( !desc ) {
- printf( %s: Invalid device number %d\n, fn, devnum );
- }
+ if (!desc)
+ printf(%s: Invalid device number %d\n, fn, devnum);
- if ( !buf ) {
- printf( %s: Null buffer.\n, fn );
+ if (!buf) {
+ printf(%s: Null buffer.\n, fn);
return (fpga_desc * const)NULL;
}
return desc;
}
-
-/* fpga_dev_info
+/*
+ * fpga_dev_info
* generic multiplexing code
*/
-static int fpga_dev_info( int devnum )
+static int fpga_dev_info(int devnum)
{
- int ret_val = FPGA_FAIL; /* assume failure */
- const fpga_desc * const desc = fpga_get_desc( devnum );
+ int ret_val = FPGA_FAIL; /* assume failure */
+ const fpga_desc * const desc = fpga_get_desc(devnum);
- if ( desc ) {
- PRINTF( %s: Device Descriptor @ 0x%p\n,
- __FUNCTION__, desc-devdesc );
+ if (desc) {
+ debug(%s: Device Descriptor @ 0x%p\n,
+ __func__, desc-devdesc);
- switch ( desc-devtype ) {
+ switch (desc-devtype) {
case fpga_xilinx:
#if defined(CONFIG_FPGA_XILINX)
- printf( Xilinx Device\nDescriptor @ 0x%p\n, desc );
- ret_val = xilinx_info( desc-devdesc );
+ printf(Xilinx Device\nDescriptor @ 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 michal.si...@xilinx.com --- 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 michal.si...@xilinx.com
---
Changes in v2: None
I had to shorten some debug messages and divide them
to two parts to pass checkpatch.
---
common/cmd_fpga.c | 213 +++---
1 file changed, 107 insertions(+), 106 deletions(-)
diff --git a/common/cmd_fpga.c b/common/cmd_fpga.c
index 1834246..f3579bb 100644
--- a/common/cmd_fpga.c
+++ b/common/cmd_fpga.c
@@ -34,7 +34,7 @@
#include malloc.h
/* Local functions */
-static int fpga_get_op (char *opstr);
+static int fpga_get_op(char *opstr);
/* Local defines */
#define FPGA_NONE -1
@@ -45,7 +45,7 @@ static int fpga_get_op (char *opstr);
#define FPGA_LOADMK 4
/* Convert bitstream data and load into the fpga */
-int fpga_loadbitstream(unsigned long dev, char* fpgadata, size_t size)
+int fpga_loadbitstream(unsigned long dev, char *fpgadata, size_t size)
{
#if defined(CONFIG_FPGA_XILINX)
unsigned int length;
@@ -58,38 +58,36 @@ int fpga_loadbitstream(unsigned long dev, char* fpgadata,
size_t size)
dataptr = (unsigned char *)fpgadata;
/* skip the first bytes of the bitsteam, their meaning is unknown */
- length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
- dataptr+=length;
+ length = (*dataptr 8) + *(dataptr + 1);
+ dataptr += 2;
+ dataptr += length;
/* get design name (identifier, length, string) */
- length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
+ length = (*dataptr 8) + *(dataptr + 1);
+ dataptr += 2;
if (*dataptr++ != 0x61) {
- debug(%s: Design name identifier not recognized
- in bitstream\n,
- __func__);
+ debug(%s: Design name id not recognized in bitstream\n,
+ __func__);
return FPGA_FAIL;
}
- length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
- for(i=0;ilength;i++)
+ length = (*dataptr 8) + *(dataptr + 1);
+ dataptr += 2;
+ for (i = 0; i length; i++)
buffer[i] = *dataptr++;
printf( design filename = \%s\\n, buffer);
/* get part number (identifier, length, string) */
if (*dataptr++ != 0x62) {
- printf(%s: Part number identifier not recognized
- in bitstream\n,
- __func__);
+ printf(%s: Part number id not recognized in bitstream\n,
+ __func__);
return FPGA_FAIL;
}
- length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
- for(i=0;ilength;i++)
+ length = (*dataptr 8) + *(dataptr + 1);
+ dataptr += 2;
+ for (i = 0; i length; i++)
buffer[i] = *dataptr++;
printf( part number = \%s\\n, buffer);
@@ -101,35 +99,35 @@ int fpga_loadbitstream(unsigned long dev, char* fpgadata,
size_t size)
}
length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
- for(i=0;ilength;i++)
+ dataptr += 2;
+ for (i = 0; i length; i++)
buffer[i] = *dataptr++;
printf( date = \%s\\n, buffer);
/* get time (identifier, length, string) */
if (*dataptr++ != 0x64) {
printf(%s: Time identifier not recognized in bitstream\n,
- __func__);
+ __func__);
return FPGA_FAIL;
}
length = (*dataptr 8) + *(dataptr+1);
- dataptr+=2;
- for(i=0;ilength;i++)
+ dataptr += 2;
+ for (i = 0; i length; i++)
buffer[i] = *dataptr++;
printf( time = \%s\\n, buffer);
/* get fpga data length (identifier, length) */
if (*dataptr++ != 0x65) {
- printf(%s: Data length identifier not recognized in
bitstream\n,
- __func__);
+ printf(%s: Data length id not recognized in bitstream\n,
+ __func__);
return FPGA_FAIL;
}
- swapsize = ((unsigned int) *dataptr 24) +
- ((unsigned int) *(dataptr+1) 16) +
- ((unsigned int) *(dataptr+2) 8 ) +
- ((unsigned int) *(dataptr+3) ) ;
- dataptr+=4;
+ swapsize = ((unsigned int) *dataptr 24) +
+ ((unsigned int) *(dataptr + 1) 16) +
+ ((unsigned int) *(dataptr + 2) 8) +
+ ((unsigned int) *(dataptr + 3));
+ dataptr += 4;
printf( bytes in bitstream = %d\n, swapsize);
rc = fpga_load(dev, dataptr, swapsize);
@@ -148,81 +146,81 @@ int fpga_loadbitstream(unsigned long dev, char* fpgadata,
size_t size)
* If there is no data addr field, the fpgadata environment variable is used.
* The info command requires no data address field.
*/
-int do_fpga (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
+int do_fpga(cmd_tbl_t
[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 michal.si...@xilinx.com
---
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 michal.si...@xilinx.com
---
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 op device number data addr datasize
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__);
+ return
[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 joe.hershber...@ni.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
Changes in v2:
- Fix bugs reported by Tom Rini
- Fix checkpatch warnings (fpga)
- Fix comments (fpga)
- Do not use CamelCase for XilinxZynq (fpga)
- Move to fpga series and extend this driver
This patch was the part of zynq series but I have decided
to extend it with partial bitstream support, loadb support
and create separate patchset just for fpga patches.
The origin patch was reviewed by Tom Rini.
---
arch/arm/cpu/armv7/zynq/slcr.c | 35 +++
arch/arm/include/asm/arch-zynq/hardware.h | 10 +-
arch/arm/include/asm/arch-zynq/sys_proto.h | 3 +
board/xilinx/zynq/board.c | 37 +++
drivers/fpga/Makefile | 1 +
drivers/fpga/xilinx.c | 37 +++
drivers/fpga/zynqpl.c | 355 +
include/configs/zynq.h | 6 +
include/xilinx.h | 4 +
include/zynqpl.h | 59 +
10 files changed, 545 insertions(+), 2 deletions(-)
create mode 100644 drivers/fpga/zynqpl.c
create mode 100644 include/zynqpl.h
diff --git a/arch/arm/cpu/armv7/zynq/slcr.c b/arch/arm/cpu/armv7/zynq/slcr.c
index 5a8674a..52048c6 100644
--- a/arch/arm/cpu/armv7/zynq/slcr.c
+++ b/arch/arm/cpu/armv7/zynq/slcr.c
@@ -28,6 +28,9 @@
#define SLCR_LOCK_MAGIC0x767B
#define SLCR_UNLOCK_MAGIC 0xDF0D
+#define SLCR_IDCODE_MASK 0x1F000
+#define SLCR_IDCODE_SHIFT 12
+
static int slcr_lock = 1; /* 1 means locked, 0 means unlocked */
void zynq_slcr_lock(void)
@@ -87,3 +90,35 @@ void zynq_slcr_gem_clk_setup(u32 gem_id, u32 rclk, u32 clk)
out:
zynq_slcr_lock();
}
+
+void zynq_slcr_devcfg_disable(void)
+{
+ zynq_slcr_unlock();
+
+ /* Disable AXI interface */
+ writel(0x, slcr_base-fpga_rst_ctrl);
+
+ /* Set Level Shifters DT618760 */
+ writel(0xA, slcr_base-lvl_shftr_en);
+
+ zynq_slcr_lock();
+}
+
+void zynq_slcr_devcfg_enable(void)
+{
+ zynq_slcr_unlock();
+
+ /* Set Level Shifters DT618760 */
+ writel(0xF, slcr_base-lvl_shftr_en);
+
+ /* Disable AXI interface */
+ writel(0x0, slcr_base-fpga_rst_ctrl);
+
+ zynq_slcr_lock();
+}
+
+u32 zynq_slcr_get_idcode(void)
+{
+ return (readl(slcr_base-pss_idcode) SLCR_IDCODE_MASK)
+ SLCR_IDCODE_SHIFT;
+}
diff --git a/arch/arm/include/asm/arch-zynq/hardware.h
b/arch/arm/include/asm/arch-zynq/hardware.h
index 6af892a..8b8a91a 100644
--- a/arch/arm/include/asm/arch-zynq/hardware.h
+++ b/arch/arm/include/asm/arch-zynq/hardware.h
@@ -53,11 +53,17 @@ struct slcr_regs {
u32 boot_mode; /* 0x25c */
u32 reserved4[116];
u32 trust_zone; /* 0x430 */ /* FIXME */
- u32 reserved5[115];
+ u32 reserved5_1[63];
+ u32 pss_idcode; /* 0x530 */
+ u32 reserved5_2[51];
u32 ddr_urgent; /* 0x600 */
u32 reserved6[6];
u32 ddr_urgent_sel; /* 0x61c */
- u32 reserved7[188];
+ u32 reserved7[56];
+ u32 mio_pin[54]; /* 0x700 - 0x7D4 */
+ u32 reserved8[74];
+ u32 lvl_shftr_en; /* 0x900 */
+ u32 reserved9[3];
u32 ocm_cfg; /* 0x910 */
};
diff --git a/arch/arm/include/asm/arch-zynq/sys_proto.h
b/arch/arm/include/asm/arch-zynq/sys_proto.h
index af9e7f8..2317121 100644
--- a/arch/arm/include/asm/arch-zynq/sys_proto.h
+++ b/arch/arm/include/asm/arch-zynq/sys_proto.h
@@ -27,6 +27,9 @@ extern void zynq_slcr_lock(void);
extern void zynq_slcr_unlock(void);
extern void zynq_slcr_cpu_reset(void);
extern void zynq_slcr_gem_clk_setup(u32 gem_id, u32 rclk, u32 clk);
+extern void zynq_slcr_devcfg_disable(void);
+extern void zynq_slcr_devcfg_enable(void);
+extern u32 zynq_slcr_get_idcode(void);
/* Driver extern functions */
extern int zynq_sdhci_init(u32 regbase);
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 1589d21..b02c364 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -22,15 +22,52 @@
#include common.h
#include netdev.h
+#include zynqpl.h
#include asm/arch/hardware.h
#include asm/arch/sys_proto.h
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_FPGA
+Xilinx_desc fpga;
+
+/* It can be done differently */
+Xilinx_desc fpga010 = XILINX_XC7Z010_DESC(0x10);
+Xilinx_desc fpga020 = XILINX_XC7Z020_DESC(0x20);
+Xilinx_desc fpga030 = XILINX_XC7Z030_DESC(0x30);
+Xilinx_desc fpga045 = XILINX_XC7Z045_DESC(0x45);
+#endif
+
int board_init(void)
{
+#ifdef CONFIG_FPGA
+ u32 idcode;
+
+ idcode = zynq_slcr_get_idcode();
+
+ switch (idcode) {
+ case XILINX_ZYNQ_7010:
+
[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 michal.si...@xilinx.com --- Changes in v2: None common/cmd_fpga.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/common/cmd_fpga.c b/common/cmd_fpga.c index aa14ceb..5e1d037 100644 --- a/common/cmd_fpga.c +++ b/common/cmd_fpga.c @@ -27,9 +27,6 @@ */ #include common.h #include command.h -#if defined(CONFIG_CMD_NET) -#include net.h -#endif #include fpga.h #include malloc.h -- 1.8.2.1 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 michal.si...@xilinx.com
---
Changes in v2:
- Use asm-generic/gpio.h file
- Add gpio_set_value()
- Check return value from gpio_get_controller
GPIO support for Microblaze
I want to also write gpio support for Zynq
and this driver should be also used for arm zynq.
Currently we have support just for only gpio controller
but not for various of them.
That's why I would like to get some input from you
if possible to add dynamic gpio allocation which
could be also helpful for OF support.
Output from my gpio status on Microblaze is below.
Thanks,
Michal
U-Boot gpio status
gpio_info: reset/4000 (0-0)
GPIO_0: reset_pin is an INPUT value = 0
gpio_info: led/4004 (1-5)
GPIO_1: UNKNOWN is an INPUT value = 0
GPIO_2: UNKNOWN is an OUTPUT value = 1
GPIO_3: UNKNOWN is an INPUT value = 0
GPIO_4: UNKNOWN is an INPUT value = 0
GPIO_5: UNKNOWN is an OUTPUT value = 0
---
arch/microblaze/include/asm/gpio.h | 40 +--
.../xilinx/microblaze-generic/microblaze-generic.c | 17 +-
drivers/gpio/Makefile | 1 +
drivers/gpio/xilinx_gpio.c | 364 +
include/configs/microblaze-generic.h | 3 +-
5 files changed, 386 insertions(+), 39 deletions(-)
create mode 100644 drivers/gpio/xilinx_gpio.c
diff --git a/arch/microblaze/include/asm/gpio.h
b/arch/microblaze/include/asm/gpio.h
index 883f4d4..f5cad56 100644
--- a/arch/microblaze/include/asm/gpio.h
+++ b/arch/microblaze/include/asm/gpio.h
@@ -1,41 +1,15 @@
#ifndef _ASM_MICROBLAZE_GPIO_H_
#define _ASM_MICROBLAZE_GPIO_H_
-#include asm/io.h
+#include asm-generic/gpio.h
-static inline int gpio_request(unsigned gpio, const char *label)
-{
- return 0;
-}
+/* Allocation functions */
+extern int gpio_alloc_dual(u32 baseaddr, const char *name, u32 gpio_no0,
+ u32 gpio_no1);
+extern int gpio_alloc(u32 baseaddr, const char *name, u32 gpio_no);
-static inline int gpio_free(unsigned gpio)
-{
- return 0;
-}
+#define gpio_status() gpio_info()
+extern void gpio_info(void);
-static inline int gpio_direction_input(unsigned gpio)
-{
- return 0;
-}
-
-static inline int gpio_direction_output(unsigned gpio, int value)
-{
- return 0;
-}
-
-static inline int gpio_get_value(unsigned gpio)
-{
- return 0;
-}
-
-static inline int gpio_set_value(unsigned gpio, int value)
-{
- return 0;
-}
-
-static inline int gpio_is_valid(int number)
-{
- return 0;
-}
#endif
diff --git a/board/xilinx/microblaze-generic/microblaze-generic.c
b/board/xilinx/microblaze-generic/microblaze-generic.c
index befbb3a..2f5f20e 100644
--- a/board/xilinx/microblaze-generic/microblaze-generic.c
+++ b/board/xilinx/microblaze-generic/microblaze-generic.c
@@ -31,12 +31,17 @@
#include asm/processor.h
#include asm/microblaze_intc.h
#include asm/asm.h
+#include asm/gpio.h
+
+#ifdef CONFIG_XILINX_GPIO
+static int reset_pin = -1;
+#endif
int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
-#ifdef CONFIG_SYS_GPIO_0
- *((unsigned long *)(CONFIG_SYS_GPIO_0_ADDR)) =
- ++(*((unsigned long *)(CONFIG_SYS_GPIO_0_ADDR)));
+#ifdef CONFIG_XILINX_GPIO
+ if (reset_pin != -1)
+ gpio_direction_output(reset_pin, 1);
#endif
#ifdef CONFIG_XILINX_TB_WATCHDOG
@@ -52,8 +57,10 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
int gpio_init (void)
{
-#ifdef CONFIG_SYS_GPIO_0
- *((unsigned long *)(CONFIG_SYS_GPIO_0_ADDR)) = 0x;
+#ifdef CONFIG_XILINX_GPIO
+ reset_pin = gpio_alloc(CONFIG_SYS_GPIO_0_ADDR, reset, 1);
+ if (reset_pin != -1)
+ gpio_request(reset_pin, reset_pin);
#endif
return 0;
}
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 9df1e26..830e8e6 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -47,6 +47,7 @@ COBJS-$(CONFIG_OMAP_GPIO) += omap_gpio.o
COBJS-$(CONFIG_DB8500_GPIO)+= db8500_gpio.o
COBJS-$(CONFIG_BCM2835_GPIO) += bcm2835_gpio.o
COBJS-$(CONFIG_S3C2440_GPIO) += s3c2440_gpio.o
+COBJS-$(CONFIG_XILINX_GPIO)+= xilinx_gpio.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
new file mode 100644
index
[U-Boot] [PATCH v3] fs/ext4: Support device block sizes != 512 bytes
From: Egbert Eich e...@suse.com
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 e...@suse.com
---
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 config.h
#include ext4fs.h
#include ext_common.h
+#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
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 michal.si...@xilinx.com [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 michal.si...@xilinx.com [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 tr...@ti.com 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 ji...@nvidia.com --- 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 tr...@ti.com 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 ji...@nvidia.com --- 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 h...@denx.de wrote: Hello Naveen, On 26.04.2013 05:08, Naveen Krishna Ch wrote: On 14 April 2013 22:48, Heiko Schocher h...@denx.de wrote: Hello Naveen Krishna, On 13.04.2013 06:42, Naveen Krishna Ch wrote: On 6 April 2013 07:07, Naveen Krishna Chatradhi naveenkrishna...@gmail.com 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 Chatradhich.nav...@samsung.com Signed-off-by: R. Chandrasekarrc.se...@samsung.com Reviewed-by: Vadim Bendeburyvben...@google.com Reviewed-by: Simon Glasss...@google.com --- 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 Schocherh...@denx.de Acked-by: Heiko Schocher h...@denx.de 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 tr...@ti.com 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 ji...@nvidia.com --- 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 ma...@denx.de:
Dear Kuo-Jung Su,
2013/4/26 Marek Vasut ma...@denx.de:
Dear Kuo-Jung Su,
From: Kuo-Jung Su dant...@faraday-tech.com
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 stefan.kristians...@saunalahti.fi
---
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 stefan.kristians...@saunalahti.fi
---
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 s...@chromium.org wrote: Hi Tom, On Mon, Apr 22, 2013 at 8:18 AM, Tom Rini tr...@ti.com 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 tr...@ti.com 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 fabio.este...@freescale.com
Provide a mxs_pinctrl_regs structure for mx23.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
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 asm/imx-common/regs-common.h
#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 fabio.este...@freescale.com
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 fabio.este...@freescale.com
---
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)
[U-Boot] [PATCH 3/9] mx23evk: Fix DDR pin iomux settings
From: Fabio Estevam fabio.este...@freescale.com
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 fabio.este...@freescale.com
---
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 asm/arch/sys_proto.h
#defineMUX_CONFIG_SSP1 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
-#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_16MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI MXS_PAD_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 fabio.este...@freescale.com
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 fabio.este...@freescale.com
---
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 asm/arch/sys_proto.h
#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 fabio.este...@freescale.com Disable the internal pad keepers to match the code from FSL bootlets and provide better stability. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- 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 fabio.este...@freescale.com 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 fabio.este...@freescale.com --- 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 fabio.este...@freescale.com
HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
FSL bootlets code.
mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as reserved.
HW_DRAM_CTL8 is setup as the last element.
So skip the initialization of these DRAM_CTL registers.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
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 fabio.este...@freescale.com Disable the internal pad keepers to match the code from FSL bootlets and provide better stability. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- 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 fabio.este...@freescale.com FSL bootlets code set the PORT_PRIORITY_ORDER field of register HW_EMI_CTRL as 0x2, which means: PORT0231 = 0x02 Priority Order: AXI0, AHB2, AHB3, AHB1 Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- 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 ma...@denx.de 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 tr...@ti.com 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 ji...@nvidia.com --- 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 twarren.nvi...@gmail.com wrote: On Wed, May 1, 2013 at 12:33 PM, Marek Vasut ma...@denx.de 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 tr...@ti.com 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 ji...@nvidia.com --- 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 fabio.este...@freescale.com 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 fabio.este...@freescale.com 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 fabio.este...@freescale.com Provide a mxs_pinctrl_regs structure for mx23. Signed-off-by: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com
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 fabio.este...@freescale.com
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 asm/arch/sys_proto.h
#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 fabio.este...@freescale.com 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 fabio.este...@freescale.com 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 fabio.este...@freescale.com 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 fabio.este...@freescale.com --- 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 fabio.este...@freescale.com
HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
FSL bootlets code.
mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as reserved.
HW_DRAM_CTL8 is setup as the last element.
So skip the initialization of these DRAM_CTL registers.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
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 ma...@denx.de wrote: Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com 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 ma...@denx.de wrote: Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com Provide a mxs_pinctrl_regs structure for mx23. Signed-off-by: Fabio Estevam fabio.este...@freescale.com 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 ma...@denx.de 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 ma...@denx.de 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 ma...@denx.de 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 ma...@denx.de wrote: Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com 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 ma...@denx.de wrote: Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com Provide a mxs_pinctrl_regs structure for mx23. Signed-off-by: Fabio Estevam fabio.este...@freescale.com 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 ma...@denx.de 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 ma...@denx.de 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 ma...@denx.de 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 ma...@denx.de 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 ma...@denx.de 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 ma...@denx.de:
Dear Kuo-Jung Su,
2013/4/30 Marek Vasut ma...@denx.de:
Dear Kuo-Jung Su,
2013/4/26 Marek Vasut ma...@denx.de:
Dear Kuo-Jung Su,
From: Kuo-Jung Su dant...@faraday-tech.com
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 ma...@denx.de 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 ma...@denx.de 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 dongsheng.w...@freescale.com --- 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 dave...@freescale.com * Jerry Huang chang-ming.hu...@freescale.com * * See file CREDITS for list of people who contributed to this * project. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as * published by the Free Software Foundation; either version 2 of * the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, * MA 02111-1307 USA */ #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
[U-Boot] [PATCH v1] bfin: Move gpio support for bf54x and bf60x into the generic driver folder.
From: Sonic Zhang sonic.zh...@analog.com
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 sonic.zh...@analog.com
---
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)
{
@@
