Re: [U-Boot] [PATCH] Add NanoBone board support

2013-04-18 Thread Hebbar, Gururaja
On Wed, Apr 17, 2013 at 23:12:51, Mark Jackson wrote:
 On 17/04/13 06:27, Hebbar, Gururaja wrote:
  Mark,
 
  On Tue, Apr 16, 2013 at 20:32:34, Mark Jackson wrote:
 
 snip
 
  diff --git a/MAINTAINERS b/MAINTAINERS
  index 1614b91..7778883 100644
  --- a/MAINTAINERS
  +++ b/MAINTAINERS
  @@ -710,6 +710,10 @@ Ilko Iliev il...@ronetix.at
 PM9263  AT91SAM9263
 PM9G45  ARM926EJS (AT91SAM9G45 SoC)
 
  +Mark Jackson m...@newflow.co.uk
 
  A small nit-pick, you sent the commit using email id as 
  mpfj-l...@mimc.co.uk
  But in the maintainer file, it shows as m...@newflow.co.uk.
 
  Is this valid/correct?
 
 Yes ... the newflow address is my official work one.
 
 But I have a separate email address for all my mailing lists which makes 
 sorting out my mailboxes *so* much easier.

AFAIK Email id in Maintainer file will be used for all communications. 

So I believe, you have enabled mail fwd from m...@newflow.co.uk to 
mpfj-l...@mimc.co.uk

 
 I trust this isn't an issue.
 
 Cheers
 Mark J.
 


Regards, 
Gururaja
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] crc32: Correct endianness of crc32 result

2013-04-18 Thread Albert ARIBAUD
Hi Simon,

On Wed, 17 Apr 2013 13:59:48 -0700, Simon Glass s...@chromium.org
wrote:

 Hi Albert,
 
 On Wed, Apr 17, 2013 at 12:23 PM, Albert ARIBAUD
 albert.u.b...@aribaud.net wrote:
  Hi Simon -- and sorry for the dupe.
 
  On Wed, 17 Apr 2013 11:28:07 -0700, Simon Glass s...@chromium.org
  wrote:
 
  I tried using:
 
  #ifdef USE_HOSTCC
 crc = htobe32(crc);
  #else
 crc = cpu_to_be32(crc);
  #endif
 memcpy(output, crc, sizeof(crc));
 
 
  This is one instruction (4 bytes, 16%) smaller, but I suspect quite a
  lot slower due to the overhead of a very small memcpy().
 
  43e2c1d8: e28d1008 add r1, sp, #8
  43e2c1dc: e3a02004 mov r2, #4
  43e2c1e0: e6bf0f30 rev r0, r0
  43e2c1e4: e5210004 str r0, [r1, #-4]!
  43e2c1e8: e1a4 mov r0, r4
  43e2c1ec: eb001af7 bl 43e32dd0 memcpy
 
  How about replacing the memcpy with an explicit put_unaligned(),
  similar to what was done in
 
  http://www.mail-archive.com/u-boot@lists.denx.de/msg109555.html
 
  with get_unaligned()? The code will be longer than above, but shorter
  than the above plus the memcpy(), and faster too -- actually, I'm
  surprised that the compiler does not unroll the memcpy() on its own,
  considering the size argument is a constant.
 
 Do you mean like this?
 
 #ifdef USE_HOSTCC
crc = htobe32(crc);
memcpy(output, crc, sizeof(crc));
 #else
crc = cpu_to_be32(crc);
put_unaligned(crc, (uint32_t *)output);
 #endif
 
 This produces the same code as my original patch. If this is
 acceptable then I will do that, although it doesn't really seem any
 better.

Wolfgang may not like it any more than put_unaligned_be32() as it
builds upon it (and the disk patch could have used the be32 version as
well). Personally, I think we should allow and use these...

... and work on optimizing their implementation for ARM; we should be
able to reduce such put()s and get()s to a few instructions. And to
avoid any misunderstanding, yes, I volunteer for the optimizing work. :)

 Regards,
 Simon
 
 [and sorry for my dup]

Actually I'm the culprit.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] PCIe card doesn't work

2013-04-18 Thread Albert ARIBAUD
Hi goldenshore,

On Thu, 18 Apr 2013 09:34:10 +0800 (CST), goldenshore
goldensh...@tom.com wrote:

 div

Please post here in text, not HTML.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 0/8] usb: ss: Some fixes and cleanup for USB super-speed support

2013-04-18 Thread Vivek Gautam
Hi Marek,


On Sun, Apr 14, 2013 at 11:43 PM, Marek Vasut ma...@denx.de wrote:
 Dear Vivek Gautam,

 Based on 'u-boot-usb' master branch.

 This patch-series includes majorly some clean-up, few fixes and
 then some basic super-speed usb infrastructure addition, to help
 put support for XHCI in near future.

 btw can you test your patches with MAKEALL -a arm? I get this:

 - SUMMARY 
 Boards compiled: 306
 Boards with errors: 65 ( qong mx35pdk gplugd at91sam9m10g45ek_nandflash 
 pogo_e02
 dns325 iconnect lschlv2 lsxhl d2net_v2 inetspace_v2 net2big_v2 
 netspace_lite_v2
 netspace_max_v2 netspace_v2 wireless_space dreamplug guruplug mv88f6281gtw_ge
 openrd_base openrd_client openrd_ultimate rd6281a sheevaplug ib62x0 dockstar
 tk71 zmx25 mx23_olinuxino apx4devkit mx23evk m28evk mx28evk sc_sps_1 edminiv2
 mx51_efikamx mx51_efikasb mx51evk mx53loco mx6qsabreauto mx6qsabrelite
 nitrogen6dl nitrogen6dl2g nitrogen6q nitrogen6q2g nitrogen6s nitrogen6s1g 
 cm_t35
 mt_ventoux omap3_beagle mcx twister omap4_panda snow smdk5250 harmony seaboard
 ventana whistler colibri_t20_iris plutux medcom-wide tec paz00 trimslice )
 --

Tried with MAKEALL
got following result

- SUMMARY 
Boards compiled: 306
Boards with errors: 1 ( omap3_evm )
Boards with warnings but no errors: 17 ( VCMA9 smdk2410 kzm9g balloon3
h2200 lubbock palmld palmtc polaris pxa255_idp trizepsiv
vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 xaeniax zipitz2
colibri_pxa270 )
--

There's something to do with Cross Compiler version ??
btw what environment are you compiling the source with.


-- 
Thanks  Regards
Vivek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 0/8] usb: ss: Some fixes and cleanup for USB super-speed support

2013-04-18 Thread Vivek Gautam
Hi,


On Sun, Apr 14, 2013 at 10:44 PM, Marek Vasut ma...@denx.de wrote:
 Dear Vivek Gautam,

 Based on 'u-boot-usb' master branch.

 This patch-series includes majorly some clean-up, few fixes and
 then some basic super-speed usb infrastructure addition, to help
 put support for XHCI in near future.

 Changes from v2:
  - Added a patch usb: common: Weed out USB_**_PRINTFs from usb framework
to replace USB_***_PRINTF with debug() so as to get rid of unnecessary
DEBUG macros in usb common framework and thereby rebasing other patches
on top of this so that no USB_PRINTF appears further.
  - Added a patch to reset only USB 2.0 ports, since USB 3.0 protocol ports
don't require a reset to happen to move to 'enabled' state.
  - Added a patch to move definition of 'min3()' out of ehci-hcd and putting
the same as macro definition in common header.
  - Using a 'switch-case' in portspeed() in cmd_usb.c

 Changes from v1:
  - Fixing the issue with 'ifno' as well as added 'if_desc'.
  - Instead of turning-on only powered-off hub ports, power-cycle all
the hub ports (aka: turning off and then turning on again power to
all the ports.
  - Fixing commenting style problem in
'usb: Update device class in usb device's descriptor'
  - Fixing typo in commit message for
'usb: hub: Fix enumration timeout'
  - Removing separate definition for 'struct usb_ep_desc'; thereby adding
'struct usb_ss_ep_comp_descriptor' to 'struct usb_interface' only.
As a result modifying the patch accordingly also dropping the patch
'usb: eth: Fix for updated usb interface descriptor structure'
  - Dropping the patch 'usb: hub: Increase device enumeration timeout for
 broken drives' for now (will come back with a solution at later point of
 time).

 Applied all but the last one, let's now base all subsequent patches on u-boot-
 usb/next please.

And i can't see these patches on u-boot-usb/next. Possibly you haven't
pushed out yet ??



-- 
Thanks  Regards
Vivek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] USB Device Identification -- non-removable USB NAND flash

2013-04-18 Thread Albert ARIBAUD
Hi Curt,

On Wed, 17 Apr 2013 21:33:29 -0700 (PDT), Curt Brune
c...@cumulusnetworks.com wrote:

 Hi - 
 
 Looking for suggestions on how to identify a particular USB mass storage 
 device on my platform.
 
 My platform has a P2020 SoC.  The SoC USB controller is connected to an on 
 board USB hub.  The hub has 3 connections as follows:
 
 +-+
 | |---[USB flash controller, fronting a 2GB NAND flash]
 | USB Hub |---[front panel USB connector]
 | |---[front panel USB connector]
 +-+
 
 My uImage is stored on the NAND in a raw partition. I have been using the 
 usbboot command just fine.  Something like this:
 
   uboot usbboot $loadaddr 0:0  bootm $loadaddr
 
 That boots from storage device 0, partition 0.  That works great.
 
 The problem is when I *also* have a USB memory stick plugged into one of the 
 front panel ports.  In that case my boot device no longer shows up as device 
 0, but rather 1.
 
 I'm guessing this problem is not unique.
 
 Is there a way to fix the device number for the non-removable flash to 
 always be 0?
 
 Alternatively is there a way to figure out at run time (in a script) what 
 device corresponds to my internal flash?
 
 I started hacking on common/usb.c and I see how I can make it work, but that 
 solution seemed wrong.  There's got to be a better way.
 
 Any suggestions are much appreciated.

Haven't tested this at all, but maybe first do a usb dev 1 and test
if it succeeded (probably requires enabling the HUSH parser), and if
it did, (try to) load from it; otherwise fall back to usb dev 0 and
(try to) load.

Testing could actually be blank a memory area, select usb dev 1 and
blindly load the boot image to the memory area, test image with
'iminfo', and decide if you go on or switch to dev 0.

 Cheers,
 Curt

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] phy ic isn't reset

2013-04-18 Thread Bo Shen

Hi Alex

On 4/18/2013 13:27, alex wrote:


At 2013-04-18 09:23:48,Bo Shen voice.s...@atmel.com wrote:

Hi Alex,

On 4/17/2013 18:29, alex wrote:

Hi:
   I work on one board based on at9g25evk board now. I find one issue
that phy IC isn't reset, so network can't work. Only the different
crystal with evk board is connected to PHY IC. I copy the phy-reset part
of at9260 to at9g25. It can work now. Please the maintainer of at9gx5
check this. The modification I do is as below:


As you mentioned, you use different crystal, please specify this in detail.


S3225A package, 50Mhz crystal oscillator. ocean comonents ltd. --- can work.

asem series:ASEM1-50.000MHZ-LC-T  can't work.




+
+#ifdef CONFIG_MACB
+int at91sam9x5ek_macb_hw_init(void)
+{
+struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+struct at91_port *pioa = (struct at91_port *)ATMEL_BASE_PIOA;
+   struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC;
+   unsigned long erstl;
+
+/* Enable EMAC clock */
+writel(1  ATMEL_ID_EMAC0, pmc-pcer);
+
+   erstl = readl(rstc-mr)  AT91_RSTC_MR_ERSTL_MASK;
+
+   /* Need to reset PHY - 500ms reset */
+   writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) |
+   AT91_RSTC_MR_URSTEN, rstc-mr);
+
+   writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, rstc-cr);
+
+   /* Wait for end hardware reset */
+   while (!(readl(rstc-sr)  AT91_RSTC_SR_NRSTL))
+   ;
+
+   /* Restore NRST value */
+   writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN,
+   rstc-mr);
+
+   at91_macb_hw_init();
+}
+#endif


On at91sam9g25ek, it don't need this patch. The network work properly.

Btw, please help provide the log information for why not ethernet
doesn't work.


 From at91sam9g25ek side, no any error. If you only plug network line , the 
network traffic led is always off, that is,DM9161AEP doesn't check this change.
Even if I add this patch, no any defect, right?


I won't suggest do like this, if you use reset controller, it will 
assert nRST pin. If one more device use nRST, it will also reset other 
device. if only PHY use nRST and no other consideration, I think it is OK.


Best Regards,
Bo Shen

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Add NanoBone board support

2013-04-18 Thread Mark Jackson
On 18/04/13 07:05, Hebbar, Gururaja wrote:
 On Wed, Apr 17, 2013 at 23:12:51, Mark Jackson wrote:
 On 17/04/13 06:27, Hebbar, Gururaja wrote:
 Mark,

 On Tue, Apr 16, 2013 at 20:32:34, Mark Jackson wrote:

 snip

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 1614b91..7778883 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -710,6 +710,10 @@ Ilko Iliev il...@ronetix.at
PM9263  AT91SAM9263
PM9G45  ARM926EJS (AT91SAM9G45 SoC)

 +Mark Jackson m...@newflow.co.uk

 A small nit-pick, you sent the commit using email id as 
 mpfj-l...@mimc.co.uk
 But in the maintainer file, it shows as m...@newflow.co.uk.

 Is this valid/correct?

 Yes ... the newflow address is my official work one.

 But I have a separate email address for all my mailing lists which makes 
 sorting out my mailboxes *so* much easier.
 
 AFAIK Email id in Maintainer file will be used for all communications. 
 
 So I believe, you have enabled mail fwd from m...@newflow.co.uk to 
 mpfj-l...@mimc.co.uk

I don't mind direct contact on my standard email address ... I just
have all my mailing list traffic sent to another email address.

I've actually now change to mpfj-list at newflow.co.uk, so does that
make things a bit clearer ?

Regards
Mark J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] ARM: OMAP5: Fix warm reset with USB cable connected

2013-04-18 Thread Lokesh Vutla
Warm reset on OMAP5 freezes when USB cable is connected.
Fix requires PRM_RSTTIME.RSTTIME1 to be programmed
with the time for which reset should be held low for the
voltages and the oscillator to reach stable state.

There are 3 parameters to be considered for calculating
the time, which are mostly board and PMIC dependent.
-1- Time taken by the Oscillator to shut + restart
-2- PMIC OTP times
-3- Voltage rail ramp times, which inturn depends on the
PMIC slew rate and value of the voltage ramp needed.

In order to keep the code in u-boot simple, have a way
for boards to specify a pre computed time directly using
the 'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC'
option. If boards fail to specify the time, use a default
as specified by 'CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC' instead.
Using the default value translates into some ~22ms and should work in
all cases.
However in order to avoid this large delay hiding other bugs,
its recommended that all boards look at their respective data
sheets and specify a pre computed and optimal value using
'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC'

In order to help future board additions to compute this
config option value, add a README at doc/README.omap-reset-time
which explains how to compute the value. Also update the toplevel
README with the additional option and pointers to
doc/README.omap-reset-time.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[rna...@ti.com: Updated changelog and added the README]
Signed-off-by: Rajendra Nayak rna...@ti.com
---
 README |4 
 arch/arm/cpu/armv7/omap-common/clocks-common.c |1 +
 arch/arm/cpu/armv7/omap-common/reset.c |4 
 arch/arm/cpu/armv7/omap5/hwinit.c  |   19 +++
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |2 ++
 arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
 arch/arm/include/asm/arch-omap5/clocks.h   |   10 ++
 arch/arm/include/asm/arch-omap5/sys_proto.h|   10 ++
 arch/arm/include/asm/omap_common.h |1 +
 doc/README.omap-reset-time |   20 
 include/configs/omap5_uevm.h   |1 +
 11 files changed, 73 insertions(+)
 create mode 100644 doc/README.omap-reset-time

diff --git a/README b/README
index 0bc0af5..4531891 100644
--- a/README
+++ b/README
@@ -3323,6 +3323,10 @@ Configuration Settings:
offset _bss_start_ofs from CONFIG_SYS_TEXT_BASE, rather than
directly. You should not need to touch this setting.
 
+- CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC (OMAP only)
+   This is set by OMAP boards for the max time that reset should
+   be asserted. See doc/README.omap-reset-time for details on how
+   the value can be calulated on a given board.
 
 The following definitions that deal with the placement and management
 of environment data (variable area); in general, we support the
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 2b955c7..99910cd 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -716,6 +716,7 @@ void prcm_init(void)
setup_non_essential_dplls();
enable_non_essential_clocks();
 #endif
+   setup_warmreset_time();
break;
default:
break;
diff --git a/arch/arm/cpu/armv7/omap-common/reset.c 
b/arch/arm/cpu/armv7/omap-common/reset.c
index 587bb47..57ea9d9 100644
--- a/arch/arm/cpu/armv7/omap-common/reset.c
+++ b/arch/arm/cpu/armv7/omap-common/reset.c
@@ -39,3 +39,7 @@ u32 __weak warm_reset(void)
 {
return (readl(PRM_RSTST)  PRM_RSTST_WARM_RESET_MASK);
 }
+
+void __weak setup_warmreset_time(void)
+{
+}
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 2f4b247..d29df78 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -363,3 +363,22 @@ u32 warm_reset(void)
 {
return readl((*prcm)-prm_rstst)  PRM_RSTST_WARM_RESET_MASK;
 }
+
+void setup_warmreset_time(void)
+{
+   u32 rst_time, rst_val;
+
+#ifndef CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC
+   rst_time = CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC;
+#else
+   rst_time = CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC;
+#endif
+   rst_time = usec_to_32k(rst_time)  RSTTIME1_SHIFT;
+
+   if (rst_time  RSTTIME1_MASK)
+   rst_time = RSTTIME1_MASK;
+
+   rst_val = readl((*prcm)-prm_rsttime)  ~RSTTIME1_MASK;
+   rst_val |= rst_time;
+   writel(rst_val, (*prcm)-prm_rsttime);
+}
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index b8a61fe..e9f6a32 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -729,6 +729,7 @@ struct prcm_regs const omap5_es2_prcm = {
.cm_wkupaon_io_srcomp_clkctrl = 0x4ae07998,
.prm_rstctrl = 

Re: [U-Boot] phy ic isn't reset

2013-04-18 Thread alex


At 2013-04-18 14:32:52,Bo Shen voice.s...@atmel.com wrote:
Hi Alex

On 4/18/2013 13:27, alex wrote:

 At 2013-04-18 09:23:48,Bo Shen voice.s...@atmel.com wrote:
Hi Alex,

On 4/17/2013 18:29, alex wrote:
 Hi:
I work on one board based on at9g25evk board now. I find one issue
 that phy IC isn't reset, so network can't work. Only the different
 crystal with evk board is connected to PHY IC. I copy the phy-reset part
 of at9260 to at9g25. It can work now. Please the maintainer of at9gx5
 check this. The modification I do is as below:

As you mentioned, you use different crystal, please specify this in detail.

 S3225A package, 50Mhz crystal oscillator. ocean comonents ltd. --- can work.

 asem series:ASEM1-50.000MHZ-LC-T  can't work.
More information.  asem crystal:  only plug the network line, and then powerup, 
it can work. 


 +
 +#ifdef CONFIG_MACB
 +int at91sam9x5ek_macb_hw_init(void)
 +{
 +struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
 +struct at91_port *pioa = (struct at91_port *)ATMEL_BASE_PIOA;
 +   struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC;
 +   unsigned long erstl;
 +
 +/* Enable EMAC clock */
 +writel(1  ATMEL_ID_EMAC0, pmc-pcer);
 +
 +   erstl = readl(rstc-mr)  AT91_RSTC_MR_ERSTL_MASK;
 +
 +   /* Need to reset PHY - 500ms reset */
 +   writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) |
 +   AT91_RSTC_MR_URSTEN, rstc-mr);
 +
 +   writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, rstc-cr);
 +
 +   /* Wait for end hardware reset */
 +   while (!(readl(rstc-sr)  AT91_RSTC_SR_NRSTL))
 +   ;
 +
 +   /* Restore NRST value */
 +   writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN,
 +   rstc-mr);
 +
 +   at91_macb_hw_init();
 +}
 +#endif

On at91sam9g25ek, it don't need this patch. The network work properly.

Btw, please help provide the log information for why not ethernet
doesn't work.

  From at91sam9g25ek side, no any error. If you only plug network line , the 
 network traffic led is always off, that is,DM9161AEP doesn't check this 
 change.
 Even if I add this patch, no any defect, right?

I won't suggest do like this, if you use reset controller, it will 
assert nRST pin. If one more device use nRST, it will also reset other 
device. if only PHY use nRST and no other consideration, I think it is OK.
On my board, only PHY use nRST.
Understand, and thanks for your reply.  

Best Regards,
Bo Shen

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] phy ic isn't reset

2013-04-18 Thread Andreas Bießmann
Dear Bo Shen,

On 04/18/2013 08:32 AM, Bo Shen wrote:
 Hi Alex
 
 On 4/18/2013 13:27, alex wrote:

 At 2013-04-18 09:23:48,Bo Shen voice.s...@atmel.com wrote:
 Hi Alex,

 On 4/17/2013 18:29, alex wrote:
 Hi:
I work on one board based on at9g25evk board now. I find one issue
 that phy IC isn't reset, so network can't work. Only the different
 crystal with evk board is connected to PHY IC. I copy the phy-reset
 part
 of at9260 to at9g25. It can work now. Please the maintainer of at9gx5
 check this. The modification I do is as below:

 As you mentioned, you use different crystal, please specify this in
 detail.

 S3225A package, 50Mhz crystal oscillator. ocean comonents ltd. ---
 can work.

 asem series:ASEM1-50.000MHZ-LC-T  can't work.


 +
 +#ifdef CONFIG_MACB
 +int at91sam9x5ek_macb_hw_init(void)
 +{
 +struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
 +struct at91_port *pioa = (struct at91_port *)ATMEL_BASE_PIOA;
 +   struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC;
 +   unsigned long erstl;
 +
 +/* Enable EMAC clock */
 +writel(1  ATMEL_ID_EMAC0, pmc-pcer);
 +
 +   erstl = readl(rstc-mr)  AT91_RSTC_MR_ERSTL_MASK;
 +
 +   /* Need to reset PHY - 500ms reset */
 +   writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) |
 +   AT91_RSTC_MR_URSTEN, rstc-mr);
 +
 +   writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, rstc-cr);
 +
 +   /* Wait for end hardware reset */
 +   while (!(readl(rstc-sr)  AT91_RSTC_SR_NRSTL))
 +   ;
 +
 +   /* Restore NRST value */
 +   writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN,
 +   rstc-mr);
 +
 +   at91_macb_hw_init();
 +}
 +#endif

 On at91sam9g25ek, it don't need this patch. The network work properly.

 Btw, please help provide the log information for why not ethernet
 doesn't work.

  From at91sam9g25ek side, no any error. If you only plug network line
 , the network traffic led is always off, that is,DM9161AEP doesn't
 check this change.
 Even if I add this patch, no any defect, right?
 
 I won't suggest do like this, if you use reset controller, it will
 assert nRST pin. If one more device use nRST, it will also reset other
 device. if only PHY use nRST and no other consideration, I think it is OK.

I would like to point out that older atmel eval kits use this trick
heavily. This is due to missing pullup/pulldown on the board, therefore
it is required to setup some gpio first and then issue a reset (again)
to the PHY cause it is misconfigured. Maybe this can also be esablished
with some (R)MII communication, but thats how it is implemented currently.

Regarding the crystal, what is the root cause of your issue? Does it not
oscillate or is your PHY 'mis-configured' in means of wrong initial
setup on configuration lines?
In both cases I recommend to find a HW solution for the final product.

Best regards

Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] phy ic isn't reset

2013-04-18 Thread Bo Shen

Hi Andreas,

On 4/18/2013 15:50, Andreas Bießmann wrote:

Dear Bo Shen,

On 04/18/2013 08:32 AM, Bo Shen wrote:

Hi Alex

On 4/18/2013 13:27, alex wrote:


At 2013-04-18 09:23:48,Bo Shen voice.s...@atmel.com wrote:

Hi Alex,

On 4/17/2013 18:29, alex wrote:

Hi:
I work on one board based on at9g25evk board now. I find one issue
that phy IC isn't reset, so network can't work. Only the different
crystal with evk board is connected to PHY IC. I copy the phy-reset
part
of at9260 to at9g25. It can work now. Please the maintainer of at9gx5
check this. The modification I do is as below:


As you mentioned, you use different crystal, please specify this in
detail.


S3225A package, 50Mhz crystal oscillator. ocean comonents ltd. ---
can work.

asem series:ASEM1-50.000MHZ-LC-T  can't work.




+
+#ifdef CONFIG_MACB
+int at91sam9x5ek_macb_hw_init(void)
+{
+struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+struct at91_port *pioa = (struct at91_port *)ATMEL_BASE_PIOA;
+   struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC;
+   unsigned long erstl;
+
+/* Enable EMAC clock */
+writel(1  ATMEL_ID_EMAC0, pmc-pcer);
+
+   erstl = readl(rstc-mr)  AT91_RSTC_MR_ERSTL_MASK;
+
+   /* Need to reset PHY - 500ms reset */
+   writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) |
+   AT91_RSTC_MR_URSTEN, rstc-mr);
+
+   writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, rstc-cr);
+
+   /* Wait for end hardware reset */
+   while (!(readl(rstc-sr)  AT91_RSTC_SR_NRSTL))
+   ;
+
+   /* Restore NRST value */
+   writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN,
+   rstc-mr);
+
+   at91_macb_hw_init();
+}
+#endif


On at91sam9g25ek, it don't need this patch. The network work properly.

Btw, please help provide the log information for why not ethernet
doesn't work.


  From at91sam9g25ek side, no any error. If you only plug network line
, the network traffic led is always off, that is,DM9161AEP doesn't
check this change.
Even if I add this patch, no any defect, right?


I won't suggest do like this, if you use reset controller, it will
assert nRST pin. If one more device use nRST, it will also reset other
device. if only PHY use nRST and no other consideration, I think it is OK.


I would like to point out that older atmel eval kits use this trick
heavily. This is due to missing pullup/pulldown on the board, therefore
it is required to setup some gpio first and then issue a reset (again)
to the PHY cause it is misconfigured. Maybe this can also be esablished
with some (R)MII communication, but thats how it is implemented currently.


Thanks for this information.


Regarding the crystal, what is the root cause of your issue? Does it not
oscillate or is your PHY 'mis-configured' in means of wrong initial
setup on configuration lines?
In both cases I recommend to find a HW solution for the final product.


Hi Alex,
  Please check your issue according to Andreas' suggestion. And try to 
fix it through HW solution.


Best Regards,
Bo Shen


Best regards

Andreas Bießmann



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] PCIe card doesn't work (wolfking2000)

2013-04-18 Thread wolfking
hi, all
  this mail is just a test.
  Previously I wrote mail in HTML style, and it is rejected by the server. Now
I try to write in plain text and test it if it can be accepted. pls don't reply 
this.
Sorry.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] PCIe card doesn't work (wolfking2000)

2013-04-18 Thread wolfking
hi, all
  this mail is just a test.
  Previously I wrote mail in HTML style, and it is rejected by the server. Now
I try to write in plain text and test it if it can be accepted. pls don't reply 
this.
Sorry.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 00/12] arm: add Faraday A36x SoC platform support

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

These patches introduce Faraday A36x SoC platform support.

Here are some public documents for your reference.

http://www.faraday-tech.com/html/documentation/index.html

There is also a A369 QEMU emulator available at my github account:

https://github.com/dantesu1218/qemu.git

Here is quick start for QEMU:

1. Download the QEMU source tree

$ git clone -b qemu-1.3.0 https://github.com/dantesu1218/qemu.git

2. Build  Install the QEMU:

$ ./configure --target-list=arm-softmmu
$ make
$ make install

3. Launch u-boot with QEMU:

$ qemu-system-arm -M a369 -m 512M -nographic -kernel ~/u-boot-devel/u-boot


Changes for v2:
   - Coding Style cleanup.
   - Use readl(), writel(), clrsetbits_le32() to replace REG() macros.
   - Use structure based hardware registers to replace the macro constants.
   - Replace BIT() with BIT_MASK().
   - echi-faraday: Remove debug codes.
   - ftmac110: Remove debug codes.
   - cache-cp15: Enable write buffer in write-through mode.

Kuo-Jung Su (12):
  mtd: spi: winbond: add W25PXX support
  net: ftgmac100: add MMU/D-cache support
  net: add Faraday FTMAC110 10/100Mbps ethernet support
  i2c: add Faraday FTI2C010 I2C controller support
  spi: add Faraday FTSPI010 SPI controller support
  mmc: add an alternative driver to Faraday FTSDC010
  mtd: nand: add Faraday FTNANDC021 NAND controller support
  mtd: spi: add FTSPI020 SPI Flash controller support
  usb: ehci: add Faraday USB 2.0 EHCI controller support
  usb: gadget: add Faraday FOTG210 USB gadget support
  arm: add MMU/d-cache support for Faraday cores
  arm: add Faraday A36x SoC platform support

 arch/arm/cpu/faraday/Makefile |   57 ++
 arch/arm/cpu/faraday/a360/Makefile|   49 ++
 arch/arm/cpu/faraday/a360/reset.c |   26 +
 arch/arm/cpu/faraday/a369/Makefile|   50 ++
 arch/arm/cpu/faraday/a369/cmd_fa606.c |   75 +++
 arch/arm/cpu/faraday/a369/reset.c |   26 +
 arch/arm/cpu/faraday/cmd_bootfa.c |  132 +
 arch/arm/cpu/faraday/config.mk|   33 ++
 arch/arm/cpu/faraday/cpu.c|  238 
 arch/arm/cpu/faraday/ftintc020.h  |   37 ++
 arch/arm/cpu/faraday/ftpwmtmr010.c|  156 +
 arch/arm/cpu/faraday/ftpwmtmr010.h|   41 ++
 arch/arm/cpu/faraday/fttmr010.c   |  159 +
 arch/arm/cpu/faraday/fwimage.h|   38 ++
 arch/arm/cpu/faraday/fwimage2.h   |   70 +++
 arch/arm/cpu/faraday/interrupts.c |  155 +
 arch/arm/cpu/faraday/start.S  |  523 
 arch/arm/cpu/u-boot.lds   |   11 +
 arch/arm/include/asm/arch-a360/hardware.h |   72 +++
 arch/arm/include/asm/arch-a369/hardware.h |   98 +++
 arch/arm/include/asm/dma-mapping.h|   56 +-
 arch/arm/include/asm/global_data.h|4 +
 arch/arm/include/asm/io.h |   84 ++-
 arch/arm/include/asm/mach-types.h |1 +
 arch/arm/lib/cache-cp15.c |   42 ++
 board/faraday/a360evb/Makefile|   49 ++
 board/faraday/a360evb/board.c |   67 +++
 board/faraday/a360evb/clk.c   |   52 ++
 board/faraday/a360evb/config.mk   |   33 ++
 board/faraday/a360evb/lowlevel_init.S |   33 ++
 board/faraday/a369evb/Makefile|   49 ++
 board/faraday/a369evb/board.c |  178 ++
 board/faraday/a369evb/clk.c   |   81 +++
 board/faraday/a369evb/config.mk   |   33 ++
 board/faraday/a369evb/lowlevel_init.S |  136 +
 boards.cfg|3 +
 common/cmd_boot.c |4 +
 common/usb_hub.c  |5 +
 drivers/i2c/Makefile  |1 +
 drivers/i2c/fti2c010.c|  363 
 drivers/i2c/fti2c010.h|   71 +++
 drivers/mmc/Makefile  |1 +
 drivers/mmc/ftsdc010_mci.c|  373 
 drivers/mtd/nand/Makefile |1 +
 drivers/mtd/nand/ftnandc021.c |  544 +
 drivers/mtd/nand/ftnandc021.h |  132 +
 drivers/mtd/spi/Makefile  |4 +
 drivers/mtd/spi/ftspi020.c|  691 +
 drivers/mtd/spi/ftspi020.h|  109 
 drivers/mtd/spi/winbond.c |   17 +-
 drivers/net/Makefile  |1 +
 drivers/net/ftgmac100.c   |   70 ++-
 drivers/net/ftmac110.c|  452 ++
 drivers/net/ftmac110.h|  159 +
 drivers/spi/Makefile  |1 +
 drivers/spi/ftssp010_spi.c|  337 +++
 drivers/spi/ftssp010_spi.h|   86 +++
 drivers/usb/gadget/Makefile   |1 +
 drivers/usb/gadget/fotg210.c  |  922 +
 drivers/usb/gadget/gadget_chips.h |8 +
 

[U-Boot] [PATCH v2 01/12] mtd: spi: winbond: add W25PXX support

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
 drivers/mtd/spi/winbond.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 2716209..2a27837 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -18,6 +18,21 @@ struct winbond_spi_flash_params {
 
 static const struct winbond_spi_flash_params winbond_spi_flash_table[] = {
{
+   .id = 0x2014,
+   .nr_blocks  = 16,
+   .name   = W25P80,
+   },
+   {
+   .id = 0x2015,
+   .nr_blocks  = 32,
+   .name   = W25P16,
+   },
+   {
+   .id = 0x2016,
+   .nr_blocks  = 64,
+   .name   = W25P32,
+   },
+   {
.id = 0x3013,
.nr_blocks  = 8,
.name   = W25X40,
@@ -104,7 +119,7 @@ struct spi_flash *spi_flash_probe_winbond(struct spi_slave 
*spi, u8 *idcode)
}
 
flash-page_size = 256;
-   flash-sector_size = 4096;
+   flash-sector_size = (idcode[1] == 0x20) ? 65536 : 4096;
flash-size = 4096 * 16 * params-nr_blocks;
 
return flash;
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 02/12] net: ftgmac100: add MMU/D-cache support

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Joe Hershberger joe.hershber...@gmail.com
---
 drivers/net/ftgmac100.c |   70 +--
 1 file changed, 49 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 69ba57d..2dbb328 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -27,11 +27,13 @@
 #include malloc.h
 #include net.h
 #include asm/io.h
+#include asm/dma-mapping.h
 #include linux/mii.h

 #include ftgmac100.h

 #define ETH_ZLEN   60
+#define CFG_XBUF_SIZE  1536

 /* RBSR - hw default init value is also 0x640 */
 #define RBSR_DEFAULT_VALUE 0x640
@@ -40,8 +42,10 @@
 #define PKTBUFSTX  4   /* must be power of 2 */

 struct ftgmac100_data {
-   struct ftgmac100_txdes txdes[PKTBUFSTX];
-   struct ftgmac100_rxdes rxdes[PKTBUFSRX];
+   ulong txdes_dma;
+   struct ftgmac100_txdes *txdes;
+   ulong rxdes_dma;
+   struct ftgmac100_rxdes *rxdes;
int tx_index;
int rx_index;
int phy_addr;
@@ -375,13 +379,34 @@ static int ftgmac100_init(struct eth_device *dev, bd_t 
*bd)
 {
struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)dev-iobase;
struct ftgmac100_data *priv = dev-priv;
-   struct ftgmac100_txdes *txdes = priv-txdes;
-   struct ftgmac100_rxdes *rxdes = priv-rxdes;
+   struct ftgmac100_txdes *txdes;
+   struct ftgmac100_rxdes *rxdes;
unsigned int maccr;
+   void *buf;
int i;

debug(%s()\n, __func__);

+   if (!priv-txdes) {
+   txdes = dma_alloc_coherent(
+   sizeof(*txdes) * PKTBUFSTX, priv-txdes_dma);
+   if (!txdes)
+   panic(ftgmac100: out of memory\n);
+   memset(txdes, 0, sizeof(*txdes) * PKTBUFSTX);
+   priv-txdes = txdes;
+   }
+   txdes = priv-txdes;
+
+   if (!priv-rxdes) {
+   rxdes = dma_alloc_coherent(
+   sizeof(*rxdes) * PKTBUFSRX, priv-rxdes_dma);
+   if (!rxdes)
+   panic(ftgmac100: out of memory\n);
+   memset(rxdes, 0, sizeof(*rxdes) * PKTBUFSRX);
+   priv-rxdes = rxdes;
+   }
+   rxdes = priv-rxdes;
+
/* set the ethernet address */
ftgmac100_set_mac_from_env(dev);

@@ -397,21 +422,31 @@ static int ftgmac100_init(struct eth_device *dev, bd_t 
*bd)

for (i = 0; i  PKTBUFSTX; i++) {
/* TXBUF_BADR */
-   txdes[i].txdes3 = 0;
+   if (!txdes[i].txdes2) {
+   buf = memalign(ARCH_DMA_MINALIGN, CFG_XBUF_SIZE);
+   if (!buf)
+   panic(ftgmac100: out of memory\n);
+   txdes[i].txdes3 = virt_to_phys(buf);
+   txdes[i].txdes2 = (uint)buf;
+   }
txdes[i].txdes1 = 0;
}

for (i = 0; i  PKTBUFSRX; i++) {
/* RXBUF_BADR */
-   rxdes[i].rxdes3 = (unsigned int)NetRxPackets[i];
+   if (!rxdes[i].rxdes2) {
+   buf = NetRxPackets[i];
+   rxdes[i].rxdes3 = virt_to_phys(buf);
+   rxdes[i].rxdes2 = (uint)buf;
+   }
rxdes[i].rxdes0 = ~FTGMAC100_RXDES0_RXPKT_RDY;
}

/* transmit ring */
-   writel((unsigned int)txdes, ftgmac100-txr_badr);
+   writel(priv-txdes_dma, ftgmac100-txr_badr);

/* receive ring */
-   writel((unsigned int)rxdes, ftgmac100-rxr_badr);
+   writel(priv-rxdes_dma, ftgmac100-rxr_badr);

/* poll receive descriptor automatically */
writel(FTGMAC100_APTC_RXPOLL_CNT(1), ftgmac100-aptc);
@@ -466,8 +501,11 @@ static int ftgmac100_recv(struct eth_device *dev)
debug(%s(): RX buffer %d, %x received\n,
   __func__, priv-rx_index, rxlen);

+   /* invalidate d-cache */
+   dma_map_single((void *)curr_des-rxdes2, rxlen, DMA_FROM_DEVICE);
+
/* pass the packet up to the protocol layers. */
-   NetReceive((void *)curr_des-rxdes3, rxlen);
+   NetReceive((void *)curr_des-rxdes2, rxlen);

/* release buffer to DMA */
curr_des-rxdes0 = ~FTGMAC100_RXDES0_RXPKT_RDY;
@@ -485,7 +523,6 @@ static int ftgmac100_send(struct eth_device *dev, void 
*packet, int length)
struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)dev-iobase;
struct ftgmac100_data *priv = dev-priv;
struct ftgmac100_txdes *curr_des = priv-txdes[priv-tx_index];
-   int start;

if (curr_des-txdes0  FTGMAC100_TXDES0_TXDMA_OWN) {
debug(%s(): no TX descriptor available\n, __func__);
@@ -496,8 +533,8 @@ static int ftgmac100_send(struct eth_device *dev, void 
*packet, int length)

length = (length  ETH_ZLEN) ? ETH_ZLEN : length;

-   /* initiate a transmit sequence */
-   

[U-Boot] [PATCH v2 03/12] net: add Faraday FTMAC110 10/100Mbps ethernet support

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

Faraday FTMAC110 10/100Mbps supports half-word data transfer for Linux.
However it has a weird DMA alignment issue:

(1) Tx DMA Buffer Address:
1 bytes aligned: Invalid
2 bytes aligned: O.K
4 bytes aligned: O.K

(2) Rx DMA Buffer Address:
1 bytes aligned: Invalid
2 bytes aligned: O.K
4 bytes aligned: Invalid!!!

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Joe Hershberger joe.hershber...@gmail.com
---
 drivers/net/Makefile   |1 +
 drivers/net/ftmac110.c |  452 
 drivers/net/ftmac110.h |  159 +
 include/netdev.h   |1 +
 4 files changed, 613 insertions(+)
 create mode 100644 drivers/net/ftmac110.c
 create mode 100644 drivers/net/ftmac110.h

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 786a656..0e23817 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -46,6 +46,7 @@ COBJS-$(CONFIG_ETHOC) += ethoc.o
 COBJS-$(CONFIG_FEC_MXC) += fec_mxc.o
 COBJS-$(CONFIG_FSLDMAFEC) += fsl_mcdmafec.o mcfmii.o
 COBJS-$(CONFIG_FTGMAC100) += ftgmac100.o
+COBJS-$(CONFIG_FTMAC110) += ftmac110.o
 COBJS-$(CONFIG_FTMAC100) += ftmac100.o
 COBJS-$(CONFIG_GRETH) += greth.o
 COBJS-$(CONFIG_INCA_IP_SWITCH) += inca-ip_sw.o
diff --git a/drivers/net/ftmac110.c b/drivers/net/ftmac110.c
new file mode 100644
index 000..f7b5385
--- /dev/null
+++ b/drivers/net/ftmac110.c
@@ -0,0 +1,452 @@
+/*
+ * Faraday 10/100Mbps Ethernet Controller
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su dant...@faraday-tech.com
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include common.h
+#include command.h
+#include malloc.h
+#include net.h
+#include asm/io.h
+#include asm/dma-mapping.h
+
+#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+#include miiphy.h
+#endif
+
+#include ftmac110.h
+
+#define CFG_RXDES_NUM  8
+#define CFG_TXDES_NUM  2
+#define CFG_XBUF_SIZE  1536
+
+/***/
+/*   FTMAC110 DMA design issue */
+/* Dante Su 2010.02.03 */
+/* */
+/* The DMA engine has a weird restriction that its Rx DMA engine   */
+/* accepts only 16-bits aligned address, 32-bits aligned is not*/
+/* acceptable. However this restriction does not apply to Tx DMA.  */
+/* Conclusion: */
+/* (1) Tx DMA Buffer Address:  */
+/* 1 bytes aligned: Invalid*/
+/* 2 bytes aligned: O.K*/
+/* 4 bytes aligned: O.K (- u-boot ZeroCopy is possible)   */
+/* (2) Rx DMA Buffer Address:  */
+/* 1 bytes aligned: Invalid*/
+/* 2 bytes aligned: O.K*/
+/* 4 bytes aligned: Invalid*/
+/***/
+
+struct ftmac110_chip {
+   void*regs;
+   uint32_t imr;
+   uint32_t maccr;
+   uint32_t lnkup;
+   uint32_t phy_addr;
+
+   struct ftmac110_rxd *rxd;
+   ulongrxd_dma;
+   uint32_t rxd_idx;
+
+   struct ftmac110_txd *txd;
+   ulongtxd_dma;
+   uint32_t txd_idx;
+};
+
+/* Register access macros */
+#define MAC_READ(r)le32_to_cpu(readl(r))
+#define MAC_WRITE(v, r)writel(cpu_to_le32(v), r)
+
+static char ftmac110_mac_addr[] = { 0x00, 0x41, 0x71, 0x00, 0x00, 0x52 };
+
+static int ftmac110_reset(struct eth_device *dev);
+
+static uint16_t mdio_read(struct eth_device *dev,
+   uint8_t phyaddr, uint8_t phyreg)
+{
+   struct ftmac110_chip *chip = dev-priv;
+   struct ftmac110_regs *regs = chip-regs;
+   uint32_t tmp;
+
+   tmp = PHYCR_READ
+   | (phyaddr  PHYCR_ADDR_SHIFT)
+   | (phyreg   PHYCR_REG_SHIFT)
+   | 0x3000;
+
+   MAC_WRITE(tmp, regs-phycr);
+
+   do {
+   tmp = MAC_READ(regs-phycr);
+   } while (tmp  PHYCR_READ);
+
+   return (uint16_t)(tmp  0x);
+}
+
+static void mdio_write(struct eth_device *dev,
+   uint8_t phyaddr, uint8_t phyreg, uint16_t phydata)
+{
+   struct ftmac110_chip *chip = dev-priv;
+   struct ftmac110_regs *regs = chip-regs;
+   unsigned int tmp;
+
+   tmp = PHYCR_WRITE
+   | (phyaddr  PHYCR_ADDR_SHIFT)
+   | (phyreg   PHYCR_REG_SHIFT)
+   | 0x3000;
+
+   MAC_WRITE(phydata, regs-phydr);
+   MAC_WRITE(tmp, regs-phycr);
+
+   do {
+   

[U-Boot] [PATCH v2 05/12] spi: add Faraday FTSPI010 SPI controller support

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

The Faraday FTSSP010 is a multi-function controller
which supports I2S/SPI/SSP/AC97/SPDIF.
This patch simpily implements the SPI mode only.
BTW the DMA and CS/Clock control logic has been
altered since revision 1.19.0. So this patch
would 1st detects the revision id of the underlying
chip, and then switch to the corresponding control
routines.

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
 drivers/spi/Makefile   |1 +
 drivers/spi/ftssp010_spi.c |  337 
 drivers/spi/ftssp010_spi.h |   86 +++
 3 files changed, 424 insertions(+)
 create mode 100644 drivers/spi/ftssp010_spi.c
 create mode 100644 drivers/spi/ftssp010_spi.h

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index d08609e..947d60e 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -38,6 +38,7 @@ COBJS-$(CONFIG_BFIN_SPI6XX) += bfin_spi6xx.o
 COBJS-$(CONFIG_CF_SPI) += cf_spi.o
 COBJS-$(CONFIG_CF_QSPI) += cf_qspi.o
 COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
+COBJS-$(CONFIG_FTSSP010_SPI) += ftssp010_spi.o
 COBJS-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
 COBJS-$(CONFIG_ICH_SPI) +=  ich.o
 COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
diff --git a/drivers/spi/ftssp010_spi.c b/drivers/spi/ftssp010_spi.c
new file mode 100644
index 000..4247c8c
--- /dev/null
+++ b/drivers/spi/ftssp010_spi.c
@@ -0,0 +1,337 @@
+/*
+ * Faraday Multi-function Controller - SPI Mode
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su dant...@faraday-tech.com
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include common.h
+#include asm/io.h
+#include spi.h
+#include malloc.h
+
+#include ftssp010_spi.h
+
+struct ftssp010_chip {
+   void*iobase;
+   uint32_t fifo;
+   uint32_t rev;
+   uint32_t div;
+   uint32_t mode;
+
+   struct {
+   uint32_t iobase;
+   uint32_t pin;
+   } gpio;
+};
+
+static struct ftssp010_chip chip_list[] = {
+#if defined(CONFIG_FTSSP010_BASE) || defined(CONFIG_FTSSP010_BASE0)
+   {
+   .iobase = (void *)CONFIG_FTSSP010_BASE,
+#ifdef CONFIG_FTSSP010_GPIO_BASE
+   .gpio = { CONFIG_FTSSP010_GPIO_BASE, CONFIG_FTSSP010_GPIO_PIN },
+#endif
+   },
+#endif
+#ifdef CONFIG_FTSSP010_BASE1
+   { .iobase = (void *)CONFIG_FTSSP010_BASE1, },
+#endif
+#ifdef CONFIG_FTSSP010_BASE2
+   { .iobase = (void *)CONFIG_FTSSP010_BASE2, },
+#endif
+#ifdef CONFIG_FTSSP010_BASE3
+   { .iobase = (void *)CONFIG_FTSSP010_BASE3, },
+#endif
+};
+
+/* Register access macros */
+#define SPI_READ(r)le32_to_cpu(readl(r))
+#define SPI_WRITE(v, r)writel(cpu_to_le32(v), r)
+#define SPI_SETBITS(m, r)  setbits_le32(r, m)
+#define SPI_CLRBITS(m, r)  clrbits_le32(r, m)
+
+#ifdef CONFIG_FTSSP010_GPIO_BASE
+#define SPI_GPIO_READ(p, r)\
+   le32_to_cpu(readl((p)-gpio.iobase + (r)))
+#define SPI_GPIO_WRITE(p, v, r)\
+   writel(cpu_to_le32(v), (p)-gpio.iobase + (r))
+#define SPI_GPIO_SETBITS(p, m, r)  \
+   setbits_le32((p)-gpio.iobase + (r), m)
+#define SPI_GPIO_CLRBITS(p, m, r)  \
+   clrbits_le32((p)-gpio.iobase + (r), m)
+#endif /* #ifdef CONFIG_FTSSP010_GPIO_BASE */
+
+static int ftssp010_spi_work_transfer_v1_19(struct ftssp010_chip *chip,
+   const void *tx_buf, void *rx_buf, int len, uint flags)
+{
+   struct ftssp010_regs *regs = chip-iobase;
+   const uint8_t *txb = tx_buf;
+   uint8_t   *rxb = rx_buf;
+
+   while (len  0) {
+   int i, depth = min(chip-fifo  2, len);
+   uint32_t xmsk = 0;
+
+   if (tx_buf) {
+   for (i = 0; i  depth; ++i) {
+   while (!(SPI_READ(regs-sr)  SR_TFNF))
+   ;
+   SPI_WRITE(*txb++, regs-dr);
+   }
+   xmsk |= CR2_TXEN | CR2_TXDOE;
+   if ((SPI_READ(regs-cr[2])  xmsk) != xmsk)
+   SPI_SETBITS(xmsk, regs-cr[2]);
+   }
+   if (rx_buf) {
+   xmsk |= CR2_RXEN;
+   if ((SPI_READ(regs-cr[2])  xmsk) != xmsk)
+   SPI_SETBITS(xmsk, regs-cr[2]);
+   for (i = 0; i  depth; ++i) {
+   while (!SR_RFVE(SPI_READ(regs-sr)))
+   ;
+   *rxb++ = (uint8_t)SPI_READ(regs-dr);
+   }
+   }
+
+   len -= depth;
+   }
+
+   return 0;
+}
+
+static int ftssp010_spi_work_transfer(struct ftssp010_chip *chip,
+   const void *tx_buf, void *rx_buf, int len, uint flags)
+{
+   struct ftssp010_regs *regs = chip-iobase;
+   const uint8_t *txb = 

[U-Boot] [PATCH v2 04/12] i2c: add Faraday FTI2C010 I2C controller support

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

Faraday FTI2C010 is a multi-function I2C controller
which supports both master and slave mode.
This patch simplily implements the master mode only.

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Heiko Schocher h...@denx.de
---
 drivers/i2c/Makefile   |1 +
 drivers/i2c/fti2c010.c |  363 
 drivers/i2c/fti2c010.h |   71 ++
 3 files changed, 435 insertions(+)
 create mode 100644 drivers/i2c/fti2c010.c
 create mode 100644 drivers/i2c/fti2c010.h

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 5dbdbe3..ed2b8c0 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -29,6 +29,7 @@ COBJS-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
 COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
 COBJS-$(CONFIG_DW_I2C) += designware_i2c.o
 COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o
+COBJS-$(CONFIG_FTI2C010) += fti2c010.o
 COBJS-$(CONFIG_I2C_MVTWSI) += mvtwsi.o
 COBJS-$(CONFIG_I2C_MV) += mv_i2c.o
 COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o
diff --git a/drivers/i2c/fti2c010.c b/drivers/i2c/fti2c010.c
new file mode 100644
index 000..dbcab0d
--- /dev/null
+++ b/drivers/i2c/fti2c010.c
@@ -0,0 +1,363 @@
+/*
+ * Faraday I2C Controller
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su dant...@faraday-tech.com
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include common.h
+#include asm/io.h
+#include i2c.h
+
+#include fti2c010.h
+
+#define I2C_RD1
+#define I2C_WR0
+
+struct fti2c010_chip {
+   void*regs;
+   uint32_t bus;
+   uint32_t speed;
+};
+
+#define I2C_READ(r)le32_to_cpu(readl(r))
+#define I2C_WRITE(v, r)writel(cpu_to_le32(v), r)
+
+#if defined(CONFIG_HARD_I2C)
+
+static struct fti2c010_chip fti2c010_info[] = {
+#ifdef CONFIG_I2C_MULTI_BUS
+# ifdef CONFIG_FTI2C010_BASE0
+   {
+   .bus   = 0,
+   .speed = 0,
+   .regs  = (void *)CONFIG_FTI2C010_BASE0,
+   },
+# endif
+# ifdef CONFIG_FTI2C010_BASE1
+   {
+   .bus   = 1,
+   .speed = 0,
+   .regs  = (void *)CONFIG_FTI2C010_BASE1,
+   },
+# endif
+# ifdef CONFIG_FTI2C010_BASE2
+   {
+   .bus   = 2,
+   .speed = 0,
+   .regs  = (void *)CONFIG_FTI2C010_BASE2,
+   },
+# endif
+# ifdef CONFIG_FTI2C010_BASE3
+   {
+   .bus   = 3,
+   .speed = 0,
+   .regs  = (void *)CONFIG_FTI2C010_BASE3,
+   },
+# endif
+#else/* #ifdef CONFIG_I2C_MULTI_BUS */
+   {
+   .bus   = 0,
+   .speed = 0,
+   .regs  = (void *)CONFIG_FTI2C010_BASE,
+   },
+#endif/* #ifdef CONFIG_I2C_MULTI_BUS */
+};
+
+static struct fti2c010_chip *priv = fti2c010_info;
+
+static int fti2c010_wait(uint32_t mask)
+{
+   int ret = -1;
+   uint32_t stat, t;
+   struct fti2c010_regs *regs = priv-regs;
+
+   for (t = get_timer(0); get_timer(t)  100; ) {
+   stat = I2C_READ(regs-sr);
+   if ((stat  mask) == mask) {
+   ret = 0;
+   break;
+   }
+   }
+
+   return ret;
+}
+
+/*
+ * u-boot I2C API
+ */
+
+/*
+ * Initialization, must be called once on start up, may be called
+ * repeatedly to change the speed and slave addresses.
+ */
+void i2c_init(int speed, int slaveaddr)
+{
+   if (speed || priv-speed == 0)
+   i2c_set_bus_speed(speed);
+}
+
+/*
+ * Probe the given I2C chip address.  Returns 0 if a chip responded,
+ * not 0 on failure.
+ */
+int i2c_probe(uchar chip)
+{
+   int rc;
+   struct fti2c010_regs *regs = priv-regs;
+
+   i2c_init(0, chip);
+
+   /* 1. Select slave device (7bits Address + 1bit R/W) */
+   I2C_WRITE((chip  1) + I2C_WR, regs-dr);
+   I2C_WRITE(CR_ENABLE | CR_TBEN | CR_START, regs-cr);
+   rc = fti2c010_wait(SR_DT);
+   if (rc)
+   return rc;
+
+   /* 2. Select device register */
+   I2C_WRITE(0, regs-dr);
+   I2C_WRITE(CR_ENABLE | CR_TBEN, regs-cr);
+   rc = fti2c010_wait(SR_DT);
+
+   return rc;
+}
+
+/*
+ * Read/Write interface:
+ *   chip:I2C chip address, range 0..127
+ *   addr:Memory (register) address within the chip
+ *   alen:Number of bytes to use for addr (typically 1, 2 for larger
+ *  memories, 0 for register type devices with only one
+ *  register)
+ *   buffer:  Where to read/write the data
+ *   len: How many bytes to read/write
+ *
+ *   Returns: 0 on success, not 0 on failure
+ */
+int i2c_read(uchar chip, uint addr, int alen, uchar *buf, int len)
+{
+   int rc, pos;
+   uchar paddr[4];
+   struct fti2c010_regs *regs = priv-regs;
+
+   i2c_init(0, chip);
+
+   paddr[0] = (addr  0)   0xFF;
+   paddr[1] = (addr  8)   0xFF;
+ 

[U-Boot] [PATCH v2 06/12] mmc: add an alternative driver to Faraday FTSDC010

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

Faraday FTSDC010 is a MMC/SD host controller.
Although there is already a driver in current u-boot release,
which is modified from eSHDC and contributed by Andes Tech.
Its performance is too terrible on Faraday A36x SoC platforms,
so I turn to implement this new version of driver which is
10+ times faster than the old one.

If the hardware platform is avaiable, you may modify the
'include/configs/a369_defaults.h' for performance evaluation.

Here is the code snapshot of the 'a369_defaults.h'

#if 1
#define CONFIG_FTSDC010_MCI1
#define CONFIG_FTSDC010_SDIO   1 /* The hardware core supports SDIO */
#else
#define CONFIG_FTSDC0101
#define CONFIG_FTSDC010_SDIO   1 /* The hardware core supports SDIO */
#define CONFIG_FTSDC010_NUMBER 1
#define CONFIG_SYS_CLK_FREQ13300 /* AHB clock */
#endif
#define CONFIG_MMC 1
#define CONFIG_CMD_MMC 1
#define CONFIG_GENERIC_MMC 1

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Andy Fleming aflem...@gmail.com
---
 drivers/mmc/Makefile   |1 +
 drivers/mmc/ftsdc010_mci.c |  373 
 include/faraday/ftsdc010.h |   16 +-
 include/faraday/mmc.h  |   16 ++
 4 files changed, 403 insertions(+), 3 deletions(-)
 create mode 100644 drivers/mmc/ftsdc010_mci.c
 create mode 100644 include/faraday/mmc.h

diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 1d6faa2..52908bd 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_BFIN_SDH) += bfin_sdh.o
 COBJS-$(CONFIG_DAVINCI_MMC) += davinci_mmc.o
 COBJS-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
 COBJS-$(CONFIG_FTSDC010) += ftsdc010_esdhc.o
+COBJS-$(CONFIG_FTSDC010_MCI) += ftsdc010_mci.o
 COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
 COBJS-$(CONFIG_GENERIC_ATMEL_MCI) += gen_atmel_mci.o
 COBJS-$(CONFIG_MMC_SPI) += mmc_spi.o
diff --git a/drivers/mmc/ftsdc010_mci.c b/drivers/mmc/ftsdc010_mci.c
new file mode 100644
index 000..52c5a71
--- /dev/null
+++ b/drivers/mmc/ftsdc010_mci.c
@@ -0,0 +1,373 @@
+/*
+ * Faraday MMC/SD Host Controller
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su dant...@faraday-tech.com
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include common.h
+#include malloc.h
+#include part.h
+#include mmc.h
+
+#include asm/io.h
+#include asm/errno.h
+#include asm/byteorder.h
+#include faraday/ftsdc010.h
+
+#define SD_READ(r) le32_to_cpu(readl(r))
+#define SD_WRITE(v, r) writel(cpu_to_le32(v), r)
+#define SD_SETBITS(m, r)   setbits_le32(r, m)
+#define SD_CLRBITS(m, r)   clrbits_le32(r, m)
+
+struct ftsdc010_chip {
+   void*iobase;
+   uint32_t wprot;   /* write protected (locked) */
+   uint32_t rate;/* actual SD clock in Hz */
+   uint32_t sclk;/* FTSDC010 source clock in Hz */
+   uint32_t fifo;/* fifo depth in bytes */
+   uint32_t acmd;
+};
+
+static inline int
+ftsdc010_send_cmd(struct mmc *mmc, struct mmc_cmd *mmc_cmd)
+{
+   struct ftsdc010_chip *chip = mmc-priv;
+   struct ftsdc010_mmc *regs = chip-iobase;
+   int ret = -TIMEOUT;
+   uint32_t ts, st;
+   uint32_t cmd   = FTSDC010_CMD_IDX(mmc_cmd-cmdidx);
+   uint32_t arg   = mmc_cmd-cmdarg;
+   uint32_t flags = mmc_cmd-resp_type;
+
+   cmd |= FTSDC010_CMD_CMD_EN;
+
+   if (chip-acmd) {
+   cmd |= FTSDC010_CMD_APP_CMD;
+   chip-acmd = 0;
+   }
+
+   if (flags  MMC_RSP_PRESENT)
+   cmd |= FTSDC010_CMD_NEED_RSP;
+
+   if (flags  MMC_RSP_136)
+   cmd |= FTSDC010_CMD_LONG_RSP;
+
+   SD_WRITE(FTSDC010_STATUS_RSP_MASK | FTSDC010_STATUS_CMD_SEND,
+   regs-clr);
+   SD_WRITE(arg, regs-argu);
+   SD_WRITE(cmd, regs-cmd);
+
+   if (!(flags  (MMC_RSP_PRESENT | MMC_RSP_136))) {
+   for (ts = get_timer(0); get_timer(ts)  100; ) {
+   if (SD_READ(regs-status)  FTSDC010_STATUS_CMD_SEND) {
+   SD_WRITE(FTSDC010_STATUS_CMD_SEND, regs-clr);
+   ret = 0;
+   break;
+   }
+   }
+   } else {
+   st = 0;
+   for (ts = get_timer(0); get_timer(ts)  100; ) {
+   st = SD_READ(regs-status);
+   SD_WRITE(st  FTSDC010_STATUS_RSP_MASK, regs-clr);
+   if (st  FTSDC010_STATUS_RSP_MASK)
+   break;
+   }
+   if (st  FTSDC010_STATUS_RSP_CRC_OK) {
+   if (flags  MMC_RSP_136) {
+   mmc_cmd-response[0] = SD_READ(regs-rsp3);
+   mmc_cmd-response[1] = SD_READ(regs-rsp2);
+   mmc_cmd-response[2] = SD_READ(regs-rsp1);
+ 

[U-Boot] [PATCH v2 07/12] mtd: nand: add Faraday FTNANDC021 NAND controller support

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

Faraday FTNANDC021 is a integrated NAND flash controller.
It use a build-in command table to abstract the underlying
NAND flash control logic.

For example:

Issuing a command 0x10 to FTNANDC021 would result in
a page write + a read status operation.

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Scott Wood scottw...@freescale.com
---
 drivers/mtd/nand/Makefile |1 +
 drivers/mtd/nand/ftnandc021.c |  544 +
 drivers/mtd/nand/ftnandc021.h |  132 ++
 include/faraday/nand.h|   16 ++
 4 files changed, 693 insertions(+)
 create mode 100644 drivers/mtd/nand/ftnandc021.c
 create mode 100644 drivers/mtd/nand/ftnandc021.h
 create mode 100644 include/faraday/nand.h

diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 35769c5..f6f89f0 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -63,6 +63,7 @@ COBJS-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
 COBJS-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_nand.o
 COBJS-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o
 COBJS-$(CONFIG_NAND_FSMC) += fsmc_nand.o
+COBJS-$(CONFIG_NAND_FTNANDC021) += ftnandc021.o
 COBJS-$(CONFIG_NAND_JZ4740) += jz4740_nand.o
 COBJS-$(CONFIG_NAND_KB9202) += kb9202_nand.o
 COBJS-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
diff --git a/drivers/mtd/nand/ftnandc021.c b/drivers/mtd/nand/ftnandc021.c
new file mode 100644
index 000..58863dc
--- /dev/null
+++ b/drivers/mtd/nand/ftnandc021.c
@@ -0,0 +1,544 @@
+/*
+ * Faraday NAND Flash Controller
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su dant...@faraday-tech.com
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/unaligned.h
+#include nand.h
+#include malloc.h
+
+#include ftnandc021.h
+
+/* common bitmask of nand flash status register */
+#define NAND_IOSTATUS_ERRORBIT_MASK(0)
+#define NAND_IOSTATUS_READYBIT_MASK(6)
+#define NAND_IOSTATUS_UNPROTCT BIT_MASK(7)
+
+struct ftnandc021_chip {
+   void*iobase;
+   uint32_t cmd;
+
+   uint32_t pgidx;
+
+   uint32_t off;
+   uint8_t  buf[256];
+
+   uint32_t adrc;  /* address cycle */
+   uint32_t pgsz;  /* page size */
+   uint32_t bksz;  /* block size */
+};
+
+/* Register access macros */
+#define NAND_READ(r)   le32_to_cpu(readl(r))
+#define NAND_WRITE(v, r)   writel(cpu_to_le32(v), r)
+#define NAND_SETBITS(m, r) setbits_le32(r, m)
+#define NAND_CLRBITS(m, r) clrbits_le32(r, m)
+
+static struct nand_ecclayout ftnandc021_oob_2k = {
+   .eccbytes = 24,
+   .eccpos = {
+   40, 41, 42, 43, 44, 45, 46, 47,
+   48, 49, 50, 51, 52, 53, 54, 55,
+   56, 57, 58, 59, 60, 61, 62, 63
+   },
+   .oobfree = {
+   {
+   .offset = 9,
+   .length = 3
+   }
+   }
+};
+
+static int
+ftnandc021_reset(struct nand_chip *chip)
+{
+   struct ftnandc021_chip *priv = chip-priv;
+   struct ftnandc021_regs *regs = priv-iobase;
+   uint32_t bk = 2;/* 64 pages */
+   uint32_t pg = 1;/* 2k */
+   uint32_t ac = 2;/* 5 */
+
+#ifdef CONFIG_FTNANDC021_ACTIMING_1
+   NAND_WRITE(CONFIG_FTNANDC021_ACTIMING_1, regs-atr[0]);
+#endif
+#ifdef CONFIG_FTNANDC021_ACTIMING_2
+   NAND_WRITE(CONFIG_FTNANDC021_ACTIMING_2, regs-atr[1]);
+#endif
+
+   NAND_WRITE(0, regs-ier);
+   NAND_WRITE(0, regs-pir);
+   NAND_WRITE(0xff, regs-bbiwr);
+   NAND_WRITE(0x, regs-lsnwr);
+   NAND_WRITE(0x, regs-crcwr);
+
+   if (chip-options  NAND_BUSWIDTH_16)
+   NAND_WRITE(FCR_SWCRC | FCR_IGNCRC | FCR_16BIT, regs-fcr);
+   else
+   NAND_WRITE(FCR_SWCRC | FCR_IGNCRC, regs-fcr);
+
+   /* chip reset */
+   NAND_WRITE(SRR_CHIP_RESET, regs-srr);
+
+   /* wait until chip ready */
+   while (NAND_READ(regs-srr)  SRR_CHIP_RESET)
+   ;
+
+   switch (priv-bksz / priv-pgsz) {
+   case 16:
+   bk = 0;
+   break;
+   case 32:
+   bk = 1;
+   break;
+   case 64:
+   bk = 2;
+   break;
+   case 128:
+   bk = 3;
+   break;
+   }
+
+   switch (priv-pgsz) {
+   case 512:
+   pg = 0;
+   break;
+   case 2048:
+   pg = 1;
+   break;
+   case 4096:
+   pg = 2;
+   break;
+   }
+
+   switch (priv-adrc) {
+   case 3:
+   ac = 0;
+   break;
+   case 4:
+   ac = 1;
+   break;
+   case 5:
+   ac = 2;
+   break;
+   }
+
+   NAND_WRITE(MCR_ME(0) | MCR_32GB | (bk  16) | (pg  8) | (ac  10),
+ 

[U-Boot] [PATCH v2 09/12] usb: ehci: add Faraday USB 2.0 EHCI support

2013-04-18 Thread 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.

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Marek Vasut ma...@denx.de
---
 common/usb_hub.c|5 ++
 drivers/usb/host/Makefile   |1 +
 drivers/usb/host/ehci-faraday.c |  139 +++
 drivers/usb/host/ehci-hcd.c |   11 
 drivers/usb/host/ehci.h |5 ++
 include/usb/fotg210.h   |   71 
 include/usb/fusbh200.h  |   28 
 7 files changed, 260 insertions(+)
 create mode 100644 drivers/usb/host/ehci-faraday.c
 create mode 100644 include/usb/fotg210.h
 create mode 100644 include/usb/fusbh200.h

diff --git a/common/usb_hub.c b/common/usb_hub.c
index b5eeb62..26d66b8 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -375,6 +375,11 @@ static int usb_hub_configure(struct usb_device *dev)
return -1;
}

+#ifdef CONFIG_USB_EHCI_FARADAY
+   /* Faraday USB 2.0 EHCI chips need a long long delay here */
+   mdelay(250);
+#endif
+
if (usb_get_hub_status(dev, buffer)  0) {
USB_HUB_PRINTF(usb_hub_configure: failed to get Status %lX\n,
dev-status);
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 87a5970..98f2a10 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -43,6 +43,7 @@ COBJS-$(CONFIG_USB_EHCI_FSL) += ehci-mpc512x.o
 else
 COBJS-$(CONFIG_USB_EHCI_FSL) += ehci-fsl.o
 endif
+COBJS-$(CONFIG_USB_EHCI_FARADAY) += ehci-faraday.o
 COBJS-$(CONFIG_USB_EHCI_EXYNOS) += ehci-exynos.o
 COBJS-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
 COBJS-$(CONFIG_USB_EHCI_MXS) += ehci-mxs.o
diff --git a/drivers/usb/host/ehci-faraday.c b/drivers/usb/host/ehci-faraday.c
new file mode 100644
index 000..804e058
--- /dev/null
+++ b/drivers/usb/host/ehci-faraday.c
@@ -0,0 +1,139 @@
+/*
+ * Faraday USB 2.0 EHCI Controller
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su dant...@faraday-tech.com
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include common.h
+#include asm/io.h
+#include usb.h
+#include usb/fusbh200.h
+#include usb/fotg210.h
+
+#include ehci.h
+
+union ehci_faraday_regs {
+   struct fusbh200_regs usb;
+   struct fotg210_regs  otg;
+};
+
+struct ehci_faraday_chip {
+   union ehci_faraday_regs *iobase;
+};
+
+static struct ehci_faraday_chip hcd_list[] = {
+#ifdef CONFIG_USB_EHCI_BASE
+   { .iobase = (union ehci_faraday_regs *)CONFIG_USB_EHCI_BASE, },
+#endif
+#ifdef CONFIG_USB_EHCI_BASE1
+   { .iobase = (union ehci_faraday_regs *)CONFIG_USB_EHCI_BASE1, },
+#endif
+#ifdef CONFIG_USB_EHCI_BASE2
+   { .iobase = (union ehci_faraday_regs *)CONFIG_USB_EHCI_BASE2, },
+#endif
+#ifdef CONFIG_USB_EHCI_BASE3
+   { .iobase = (union ehci_faraday_regs *)CONFIG_USB_EHCI_BASE3, },
+#endif
+};
+
+#define HCD_READ(r)le32_to_cpu(readl(r))
+#define HCD_WRITE(v, r)writel(cpu_to_le32(v), r)
+#define HCD_SETBITS(m, r)  setbits_le32(r, m)
+#define HCD_CLRBITS(m, r)  clrbits_le32(r, m)
+
+static inline int ehci_hci_fotg2xx(struct ehci_hccr *hccr)
+{
+   union ehci_faraday_regs *regs = (void *)hccr;
+   return !HCD_READ(regs-usb.easstr);
+}
+
+/*
+ * Create the appropriate control structures to manage
+ * a new EHCI host controller.
+ */
+int ehci_hcd_init(int index, struct ehci_hccr **ret_hccr,
+   struct ehci_hcor **ret_hcor)
+{
+   struct ehci_faraday_chip *hcd = hcd_list[index];
+   union ehci_faraday_regs *regs = hcd-iobase;
+   struct ehci_hccr *hccr;
+   struct ehci_hcor *hcor;
+
+   hccr = (struct ehci_hccr *)regs-usb.hccr;
+   hcor = (struct ehci_hcor *)regs-usb.hcor;
+
+   if (ehci_hci_fotg2xx(hccr)) {
+   /* A-device bus reset */
+   /* ... Power off A-device */
+   HCD_SETBITS(BIT_MASK(5), regs-otg.otgcsr);
+   /* ... Drop vbus and bus traffic */
+   HCD_CLRBITS(BIT_MASK(4), regs-otg.otgcsr);
+   mdelay(1);
+   /* ... Power on A-device */
+   HCD_CLRBITS(BIT_MASK(5), regs-otg.otgcsr);
+   /* ... Drive vbus and bus traffic */
+   HCD_SETBITS(BIT_MASK(4), regs-otg.otgcsr);
+   mdelay(1);
+   /* Disable OTG  device interrupts, interrupt=level-high */
+   HCD_WRITE(0x0b, regs-otg.imr);
+   /* Clear all interrupt status */
+   HCD_WRITE(0x07, regs-otg.isr);
+   } else {
+   /* Interrupt=level-high */
+   HCD_SETBITS(BIT_MASK(3), regs-usb.bmcsr);
+   /* VBUS on */
+   HCD_CLRBITS(BIT_MASK(4), regs-usb.bmcsr);
+   /* Disable all interrupts 

[U-Boot] [PATCH v2 10/12] usb: gadget: add Faraday FOTG210 USB gadget support

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

The Faraday FOTG210 is an OTG chip which could operate
as either an EHCI Host or a USB Device as a time.

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Marek Vasut ma...@denx.de
---
 drivers/usb/gadget/Makefile   |1 +
 drivers/usb/gadget/fotg210.c  |  922 +
 drivers/usb/gadget/gadget_chips.h |8 +
 3 files changed, 931 insertions(+)
 create mode 100644 drivers/usb/gadget/fotg210.c

diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index e545b6b..432cf17 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -35,6 +35,7 @@ endif
 # new USB gadget layer dependencies
 ifdef CONFIG_USB_GADGET
 COBJS-$(CONFIG_USB_GADGET_S3C_UDC_OTG) += s3c_udc_otg.o
+COBJS-$(CONFIG_USB_GADGET_FOTG210) += fotg210.o
 COBJS-$(CONFIG_USBDOWNLOAD_GADGET) += g_dnl.o
 COBJS-$(CONFIG_DFU_FUNCTION) += f_dfu.o
 endif
diff --git a/drivers/usb/gadget/fotg210.c b/drivers/usb/gadget/fotg210.c
new file mode 100644
index 000..d662387
--- /dev/null
+++ b/drivers/usb/gadget/fotg210.c
@@ -0,0 +1,922 @@
+/*
+ * Faraday USB 2.0 OTG Controller
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su dant...@faraday-tech.com
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include common.h
+#include command.h
+#include config.h
+#include net.h
+#include malloc.h
+#include asm/io.h
+#include asm/errno.h
+#include linux/types.h
+#include linux/usb/ch9.h
+#include linux/usb/gadget.h
+
+#include usb/fotg210.h
+
+#define CFG_NUM_ENDPOINTS  4
+#define CFG_EP0_MAX_PACKET_SIZE64
+#define CFG_EPX_MAX_PACKET_SIZE512
+
+struct fotg210_chip;
+
+struct fotg210_ep {
+   struct usb_ep ep;
+
+   uint32_t maxpacket:16;
+   uint32_t id:4;
+   uint32_t stopped:1;
+   uint32_t rsvd:11;
+
+   struct list_head  queue;
+   struct fotg210_chip  *chip;
+   const struct usb_endpoint_descriptor *desc;
+};
+
+struct fotg210_request {
+   struct usb_request req;
+   struct list_head   queue;
+   struct fotg210_ep *ep;
+};
+
+struct fotg210_chip {
+   struct usb_gadget gadget;
+   struct usb_gadget_driver *driver;
+   struct fotg210_regs  *iobase;
+   uint8_t   irq;
+   uint16_t  addr;
+   int   pullup;
+   enum usb_device_state state;
+   struct fotg210_ep ep[1 + CFG_NUM_ENDPOINTS];
+};
+
+#define USB_READ(r)le32_to_cpu(readl(r))
+#define USB_WRITE(v, r)writel(cpu_to_le32(v), r)
+#define USB_SETBITS(m, r)  setbits_le32(r, m)
+#define USB_CLRBITS(m, r)  clrbits_le32(r, m)
+
+static struct usb_endpoint_descriptor ep0_desc = {
+   .bLength = sizeof(struct usb_endpoint_descriptor),
+   .bDescriptorType  = USB_DT_ENDPOINT,
+   .bEndpointAddress = USB_DIR_IN,
+   .bmAttributes =USB_ENDPOINT_XFER_CONTROL,
+};
+
+static inline int
+fifo_to_ep(struct fotg210_chip *chip, int id, int in)
+{
+   return (id  0) ? 0 : ((id % 4) + 1);
+}
+
+static inline int
+ep_to_fifo(struct fotg210_chip *chip, int id)
+{
+   return (id = 0) ? -1 : ((id - 1) % 4);
+}
+
+static inline int
+ep_reset(struct fotg210_chip *chip, uint8_t ep_addr)
+{
+   int ep = ep_addr  USB_ENDPOINT_NUMBER_MASK;
+   struct fotg210_regs *regs = chip-iobase;
+
+   if (ep_addr  USB_DIR_IN) {
+   /* reset endpoint */
+   USB_SETBITS(BIT_MASK(12), regs-iep[ep - 1]);
+   mdelay(1);
+   USB_CLRBITS(BIT_MASK(12), regs-iep[ep - 1]);
+   /* clear endpoint stall */
+   USB_CLRBITS(BIT_MASK(11), regs-iep[ep - 1]);
+   } else {
+   /* reset endpoint */
+   USB_SETBITS(BIT_MASK(12), regs-oep[ep - 1]);
+   mdelay(1);
+   USB_CLRBITS(BIT_MASK(12), regs-oep[ep - 1]);
+   /* clear endpoint stall */
+   USB_CLRBITS(BIT_MASK(11), regs-oep[ep - 1]);
+   }
+
+   return 0;
+}
+
+static int fotg210_reset(struct fotg210_chip *chip)
+{
+   struct fotg210_regs *regs = chip-iobase;
+   uint32_t i;
+
+   chip-state = USB_STATE_POWERED;
+
+   /* chip enable */
+   USB_WRITE(BIT_MASK(5), regs-dev_ctrl);
+
+   /* device address reset */
+   chip-addr = 0;
+   USB_WRITE(chip-addr, regs-dev_addr);
+
+   /* set idle counter to 7ms */
+   USB_WRITE(7, regs-idle);
+
+   /* disable interrupts */
+   USB_WRITE(0x0f, regs-imr);
+   USB_WRITE(0x07, regs-gimr);
+   USB_WRITE(0x3f, regs-gimr0);
+   USB_WRITE(0xf00ff, regs-gimr1);
+   USB_WRITE(0x7ff, regs-gimr2);
+
+   /* clear interrupts */
+   USB_WRITE(0x07, regs-isr);
+   USB_WRITE(0x00, regs-gisr);
+   USB_WRITE(0x00, 

[U-Boot] [PATCH v2 08/12] mtd: spi: add FTSPI020 SPI Flash controller support

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

Faraday FTSPI020 is dedicated SPI bus designed for SPI Flashes.

It supports Fast-Read-Dual, Fast-Read-Dual-IO, Fast-Read-Quad
and Fast-Read-Quad-IO.

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
 drivers/mtd/spi/Makefile   |4 +
 drivers/mtd/spi/ftspi020.c |  691 
 drivers/mtd/spi/ftspi020.h |  109 +++
 3 files changed, 804 insertions(+)
 create mode 100644 drivers/mtd/spi/ftspi020.c
 create mode 100644 drivers/mtd/spi/ftspi020.h

diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 90f8392..ce60e1b 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -29,6 +29,9 @@ ifdef CONFIG_SPL_BUILD
 COBJS-$(CONFIG_SPL_SPI_LOAD)   += spi_spl_load.o
 endif
 
+ifeq ($(CONFIG_FTSPI020),y)
+COBJS-$(CONFIG_FTSPI020) += ftspi020.o
+else
 COBJS-$(CONFIG_SPI_FLASH)  += spi_flash.o
 COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
 COBJS-$(CONFIG_SPI_FLASH_EON)  += eon.o
@@ -39,6 +42,7 @@ COBJS-$(CONFIG_SPI_FLASH_STMICRO) += stmicro.o
 COBJS-$(CONFIG_SPI_FLASH_WINBOND)  += winbond.o
 COBJS-$(CONFIG_SPI_FRAM_RAMTRON)   += ramtron.o
 COBJS-$(CONFIG_SPI_M95XXX) += eeprom_m95xxx.o
+endif
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/mtd/spi/ftspi020.c b/drivers/mtd/spi/ftspi020.c
new file mode 100644
index 000..3d8a62a
--- /dev/null
+++ b/drivers/mtd/spi/ftspi020.c
@@ -0,0 +1,691 @@
+/*
+ * Faraday SPI Flash Controller
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su dant...@faraday-tech.com
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include common.h
+#include asm/io.h
+#include malloc.h
+#include spi.h
+#include spi_flash.h
+
+#include ftspi020.h
+
+#define CFG_SUPP_FASTRD 1
+#define CFG_SUPP_FASTRD_DUAL1 /* Support fast read dual(2x) */
+#define CFG_SUPP_FASTRD_QUAD0 /* Support fast read quad(4x) */
+#define CFG_SHOW_PROGRESS   1 /* print a '.' at the end of each action */
+
+/* Flash opcodes. */
+#define OPCODE_WREN 0x06 /* Write enable */
+#define OPCODE_RDSR 0x05 /* Read status register */
+#define OPCODE_WRSR 0x01 /* Write status register 1 byte */
+#define OPCODE_NORM_READ0x03 /* Read (low freq.) */
+#define OPCODE_NORM_READ4   0x13 /* Read (low freq., 4 bytes addr) */
+#define OPCODE_FAST_READ0x0b /* Read (high freq.) */
+#define OPCODE_FAST_READ4   0x0c /* Read (high freq., 4 bytes addr) */
+#define OPCODE_FAST_READ_DUAL   0x3b /* Read (high freq.) */
+#define OPCODE_FAST_READ4_DUAL  0x3c /* Read (high freq., 4 bytes addr) */
+#define OPCODE_FAST_READ_QUAD   0x6b /* Read (high freq.) */
+#define OPCODE_FAST_READ4_QUAD  0x6c /* Read (high freq. 4 bytes addr) */
+#define OPCODE_PP   0x02 /* Page program */
+#define OPCODE_PP4  0x12 /* Page program (4 bytes addr) */
+#define OPCODE_BE_4K0x20 /* Erase 4KiB block */
+#define OPCODE_BE_32K   0x52 /* Erase 32KiB block */
+#define OPCODE_CHIP_ERASE   0xc7 /* Erase whole flash chip */
+#define OPCODE_SE   0xd8 /* Sector erase */
+#define OPCODE_SE4  0xdc /* Sector erase (4 bytes addr) */
+#define OPCODE_RDID 0x9f /* Read JEDEC ID */
+
+/* Status Register bits. */
+#define SR_WIP  BIT_MASK(0) /* Write in progress */
+#define SR_WEL  BIT_MASK(1) /* Write enable latch */
+
+struct ftspi020_chip;
+
+struct spi_flash_param {
+   const char *name;
+   uint32_tid;
+   uint32_text_id;
+   uint32_tsz_sector;
+   uint32_tnr_sector;
+
+   uint32_tflags;
+#define SECT_4KBIT_MASK(0) /* OPCODE_BE_4K works uniformly */
+#if CFG_SUPP_FASTRD_DUAL
+# define FASTRD_DUAL   BIT_MASK(8)
+#else
+# define FASTRD_DUAL   0
+#endif
+#if CFG_SUPP_FASTRD_QUAD
+# define FASTRD_QUAD   BIT_MASK(9)
+#else
+# define FASTRD_QUAD   0
+#endif
+};
+
+/* spi_flash needs to be first so upper layers can free() it */
+struct spi_flash_info {
+   struct spi_flash flash;
+   struct ftspi020_chip *chip;
+   const struct spi_flash_param *param;
+
+   unsigned fastrd_dual:1;
+   unsigned fastrd_quad:1;
+};
+
+struct ftspi020_chip {
+   void *iobase;
+   uint32_t cs;
+   struct spi_slave *spi;
+   struct spi_flash_info *sfi;
+};
+
+/* Register access macros */
+#define SPI_READ(r)le32_to_cpu(readl(r))
+#define SPI_WRITE(v, r)writel(cpu_to_le32(v), r)
+#define SPI_SETBITS(m, r)  setbits_le32(r, m)
+#define SPI_CLRBITS(m, r)  clrbits_le32(r, m)
+
+static inline struct ftspi020_chip *
+flash_to_chip(struct spi_flash *flash)
+{
+   struct spi_flash_info *fl = (struct spi_flash_info *)flash;
+   return fl-chip;
+}
+
+static inline const struct spi_flash_param *

[U-Boot] [PATCH v2 11/12] arm: add MMU/d-cache support for Faraday cores

2013-04-18 Thread Kuo-Jung Su
From: Kuo-Jung Su dant...@faraday-tech.com

This patch would enable MMU for Faraday ARMv5TE cores.

Here is the abstract of this MMU design.

Assume SDRAM memory region starts at 0x1000, and its size = 0x80.

0x +---+
   |   |
   | UN-CACHED |
   |   |
   |   |
0x1000 +---+
   |  CACHED (SDRAM)   | - It's where data/bss/stack lived.
   |   |
   |   |
0x1080 +---+
   |   |
   |   |
   | UN-CACHED |
   |   |
   |   |
0xFF80 +---+
   | UN-CACHED (SDRAM) | - An un-cached shadow of the SDRAM.
   |   |dma_alloc_coherent() always returns
   |   |an address in this region.
0x +---+

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Albert Aribaud albert.u.b...@aribaud.net
---
 arch/arm/include/asm/dma-mapping.h |   56 ++--
 arch/arm/include/asm/global_data.h |4 ++
 arch/arm/include/asm/io.h  |   84 +++-
 arch/arm/lib/cache-cp15.c  |   42 ++
 common/cmd_boot.c  |4 ++
 5 files changed, 186 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index 5bbb0a0..53c4edf 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -3,6 +3,9 @@
  * Stelian Pop stel...@popies.net
  * Lead Tech Design www.leadtechdesign.com
  *
+ * (C) Copyright 2010
+ * Dante Su dant...@faraday-tech.com
+ *
  * See file CREDITS for list of people who contributed to this
  * project.
  *
@@ -24,22 +27,69 @@
 #ifndef __ASM_ARM_DMA_MAPPING_H
 #define __ASM_ARM_DMA_MAPPING_H

+#include asm/u-boot.h
+#include asm/global_data.h
+#include asm/io.h
+#include malloc.h
+
 enum dma_data_direction {
DMA_BIDIRECTIONAL   = 0,
DMA_TO_DEVICE   = 1,
DMA_FROM_DEVICE = 2,
 };

-static void *dma_alloc_coherent(size_t len, unsigned long *handle)
+static inline void *dma_alloc_coherent(size_t len, unsigned long *handle)
+{
+#if defined(CONFIG_FARADAY)  !defined(CONFIG_SYS_DCACHE_OFF)
+   DECLARE_GLOBAL_DATA_PTR;
+#endif
+   void *va = memalign(ARCH_DMA_MINALIGN, len);
+
+   if (va  handle)
+   *handle = virt_to_phys(va);
+
+#if defined(CONFIG_FARADAY)  !defined(CONFIG_SYS_DCACHE_OFF)
+   if (gd-arch.cpu_mmu) {
+   /* invalidate the buffer, convert to un-cached address */
+   if (va != NULL) {
+   invalidate_dcache_range((ulong)va, (ulong)va + len);
+   va = virt_to_uncached(va);
+   }
+   }
+#endif
+
+   return va;
+}
+
+static inline void dma_free_coherent(void *va)
 {
-   *handle = (unsigned long)malloc(len);
-   return (void *)*handle;
+   free(virt_to_cached(va));
 }

 static inline unsigned long dma_map_single(volatile void *vaddr, size_t len,
   enum dma_data_direction dir)
 {
+#if defined(CONFIG_FARADAY)  !defined(CONFIG_SYS_DCACHE_OFF)
+   DECLARE_GLOBAL_DATA_PTR;
+
+   if (gd-arch.cpu_mmu) {
+   switch (dir) {
+   case DMA_BIDIRECTIONAL:
+   case DMA_TO_DEVICE:
+   flush_dcache_range((ulong)vaddr,
+   (ulong)vaddr + len);
+   break;
+
+   case DMA_FROM_DEVICE:
+   invalidate_dcache_range((ulong)vaddr,
+   (ulong)vaddr + len);
+   break;
+   }
+   }
+   return virt_to_phys((void *)vaddr);
+#else
return (unsigned long)vaddr;
+#endif
 }

 static inline void dma_unmap_single(volatile void *vaddr, size_t len,
diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index 37ac0da..bd18ff7 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -38,6 +38,10 @@ struct arch_global_data {
unsigned long   pllb_rate_hz;
unsigned long   at91_pllb_usb_init;
 #endif
+#ifdef CONFIG_FARADAY
+   unsigned long   cpu_id;
+   unsigned long   cpu_mmu;/* has mmu */
+#endif
/* static data needed by most of timer.c on ARM platforms */
unsigned long timer_rate_hz;
unsigned long tbu;
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 1fbc531..17d8898 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -2,6 +2,7 @@
  *  linux/include/asm-arm/io.h
  *
  *  Copyright (C) 1996-2000 Russell King
+ *  Copyright (C) 2009-2010 Dante Su dant...@faraday-tech.com
  *
  * This 

Re: [U-Boot] [PATCH] crc32: Correct endianness of crc32 result

2013-04-18 Thread Wolfgang Denk
Dear Albert ARIBAUD,

In message 20130418082027.4b5ea191@lilith you wrote:
 
  #ifdef USE_HOSTCC
 crc = htobe32(crc);
 memcpy(output, crc, sizeof(crc));
  #else
 crc = cpu_to_be32(crc);
 put_unaligned(crc, (uint32_t *)output);
  #endif
  
  This produces the same code as my original patch. If this is
  acceptable then I will do that, although it doesn't really seem any
  better.
 
 Wolfgang may not like it any more than put_unaligned_be32() as it
 builds upon it (and the disk patch could have used the be32 version as

Indeed.

 well). Personally, I think we should allow and use these...
 
 ... and work on optimizing their implementation for ARM; we should be
 able to reduce such put()s and get()s to a few instructions. And to

OK - and what about the other architectures that suffer from the same
issues?

 avoid any misunderstanding, yes, I volunteer for the optimizing work. :)

I really dislike introducing such custom functions when we have
standard functions available that implement the same purposes.

Checking Linux code (as U-Boot is not representative here):

- find * -name '*.c' | wc -l
18362
- find * -name '*.c' | xargs fgrep -l put_unaligned | wc -l
136

i. e. just 0.75% of the source files actually use any of the
put_unaligned*() variants - it is a highly exotic function.

htobe32() is even worse - just a single source file in the whole Lnux
tree uses it (arch/um/drivers/cow_user.c).


Can we not stick to standard functions?  Instead of htobe32() we
should use htonl() which is available both in U-Boot and in the host
environment.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
While money can't buy happiness, it certainly lets  you  choose  your
own form of misery.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 00/12] arm: add Faraday A36x SoC platform support

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-1-git-send-email-dant...@gmail.com you wrote:
 
 These patches introduce Faraday A36x SoC platform support.

Please run all your patches through checkpatch and clean up thew
reported warnings and errors before you resubmit.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The algorithm to do that is extremely nasty. You might want  to  mug
someone with it.   - M. Devine, Computer Science 340
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 03/12] net: add Faraday FTMAC110 10/100Mbps ethernet support

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-4-git-send-email-dant...@gmail.com you wrote:
 
 +/***/
 +/*   FTMAC110 DMA design issue */
 +/* Dante Su 2010.02.03 */
 +/* */
 +/* The DMA engine has a weird restriction that its Rx DMA engine   */
 +/* accepts only 16-bits aligned address, 32-bits aligned is not*/
 +/* acceptable. However this restriction does not apply to Tx DMA.  */
 +/* Conclusion: */
 +/* (1) Tx DMA Buffer Address:  */
 +/* 1 bytes aligned: Invalid*/
 +/* 2 bytes aligned: O.K*/
 +/* 4 bytes aligned: O.K (- u-boot ZeroCopy is possible)   */
 +/* (2) Rx DMA Buffer Address:  */
 +/* 1 bytes aligned: Invalid*/
 +/* 2 bytes aligned: O.K*/
 +/* 4 bytes aligned: Invalid*/
 +/***/

Incorrect multi-line comment style. Please fix globally.

 +/* Register access macros */
 +#define MAC_READ(r)  le32_to_cpu(readl(r))
 +#define MAC_WRITE(v, r)  writel(cpu_to_le32(v), r)

Please drop these and use the real functions instead.

 +static char ftmac110_mac_addr[] = { 0x00, 0x41, 0x71, 0x00, 0x00, 0x52 };

NAK.  We do not allow static configuration of MAC addresses.

 + ulong ts;
 + uint32_t maccr;
 + uint16_t pa, tmp;

Are you sure using  uint16_t  gives more efficient code than a plain
int?

 + if (pa = 32) {
 + puts(ftmac110: phy device not found!\n);

make this a debug() ?

...
 + MAC_WRITE(0x1010, regs-itc);
 + MAC_WRITE(0x0001, regs-aptc);
 + MAC_WRITE(0x0390, regs-dblac);
 + MAC_WRITE(0x03FF, regs-isr);

What do these magic numbers mean?


 +struct ftmac110_rxd {
 + /* RXDES0 */
 +#ifdef __ARMEB__
 + uint32_t owner:1; /* BIT: 31 - 1:Hardware, 0: Software */
 + uint32_t rsvd3:1;
 + uint32_t frs:1;
 + uint32_t lrs:1;
 + uint32_t rsvd2:5;
 + uint32_t error:5;
 + uint32_t bcast:1;
 + uint32_t mcast:1;
 + uint32_t rsvd1:5;
 + uint32_t len:11;
 +#else
 + uint32_t len:11;
 + uint32_t rsvd1:5;
 + uint32_t mcast:1;
 + uint32_t bcast:1;
 + uint32_t error:5;
 + uint32_t rsvd2:5;
 + uint32_t lrs:1;
 + uint32_t frs:1;
 + uint32_t rsvd3:1;
 + uint32_t owner:1; /* BIT: 31 - 1:Hardware, 0: Software */
 +#endif

NAK.  Please do NOT use bit fields.  They are non-portable and
dangerous.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A year spent in artificial intelligence is enough to make one believe
in God.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 04/12] i2c: add Faraday FTI2C010 I2C controller support

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-5-git-send-email-dant...@gmail.com you wrote:
...
 +#define I2C_READ(r)  le32_to_cpu(readl(r))
 +#define I2C_WRITE(v, r)  writel(cpu_to_le32(v), r)

Please drop these macros and use the real functions instead.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Little known fact about Middle Earth:   The Hobbits had a very sophi-
sticated computer network!   It was a Tolkien Ring...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 05/12] spi: add Faraday FTSPI010 SPI controller support

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-6-git-send-email-dant...@gmail.com you wrote:
...
 +/* Register access macros */
 +#define SPI_READ(r)  le32_to_cpu(readl(r))
 +#define SPI_WRITE(v, r)  writel(cpu_to_le32(v), r)
 +#define SPI_SETBITS(m, r)setbits_le32(r, m)
 +#define SPI_CLRBITS(m, r)clrbits_le32(r, m)

Ad before: drop these.

 +#ifdef CONFIG_FTSSP010_GPIO_BASE
 +#define SPI_GPIO_READ(p, r)  \
 + le32_to_cpu(readl((p)-gpio.iobase + (r)))
 +#define SPI_GPIO_WRITE(p, v, r)  \
 + writel(cpu_to_le32(v), (p)-gpio.iobase + (r))
 +#define SPI_GPIO_SETBITS(p, m, r)\
 + setbits_le32((p)-gpio.iobase + (r), m)
 +#define SPI_GPIO_CLRBITS(p, m, r)\
 + clrbits_le32((p)-gpio.iobase + (r), m)
 +#endif /* #ifdef CONFIG_FTSSP010_GPIO_BASE */

We do not allos I/O accesses throug base addrss plus offset.
Please use proper C structs instead.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Sorry, but my karma just ran over your dogma.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 06/12] mmc: add an alternative driver to Faraday FTSDC010

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-7-git-send-email-dant...@gmail.com you wrote:
 From: Kuo-Jung Su dant...@faraday-tech.com
 
 Faraday FTSDC010 is a MMC/SD host controller.
 Although there is already a driver in current u-boot release,
 which is modified from eSHDC and contributed by Andes Tech.
 Its performance is too terrible on Faraday A36x SoC platforms,
 so I turn to implement this new version of driver which is
 10+ times faster than the old one.
 
 If the hardware platform is avaiable, you may modify the
 'include/configs/a369_defaults.h' for performance evaluation.

NAK.  Instead of adding another driver, please fix the problems of the
original one, or replace the old one with your new, better one.  We do
not want to have several drivers for the same piece of hardware.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The greatest warriors are the ones who fight for peace.
- Holly Near
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 0/8] usb: ss: Some fixes and cleanup for USB super-speed support

2013-04-18 Thread Vivek Gautam
On Thu, Apr 18, 2013 at 11:54 AM, Vivek Gautam
gautamvivek1...@gmail.com wrote:
 Hi Marek,


 On Sun, Apr 14, 2013 at 11:43 PM, Marek Vasut ma...@denx.de wrote:
 Dear Vivek Gautam,

 Based on 'u-boot-usb' master branch.

 This patch-series includes majorly some clean-up, few fixes and
 then some basic super-speed usb infrastructure addition, to help
 put support for XHCI in near future.

 btw can you test your patches with MAKEALL -a arm? I get this:

 - SUMMARY 
 Boards compiled: 306
 Boards with errors: 65 ( qong mx35pdk gplugd at91sam9m10g45ek_nandflash 
 pogo_e02
 dns325 iconnect lschlv2 lsxhl d2net_v2 inetspace_v2 net2big_v2 
 netspace_lite_v2
 netspace_max_v2 netspace_v2 wireless_space dreamplug guruplug mv88f6281gtw_ge
 openrd_base openrd_client openrd_ultimate rd6281a sheevaplug ib62x0 dockstar
 tk71 zmx25 mx23_olinuxino apx4devkit mx23evk m28evk mx28evk sc_sps_1 edminiv2
 mx51_efikamx mx51_efikasb mx51evk mx53loco mx6qsabreauto mx6qsabrelite
 nitrogen6dl nitrogen6dl2g nitrogen6q nitrogen6q2g nitrogen6s nitrogen6s1g 
 cm_t35
 mt_ventoux omap3_beagle mcx twister omap4_panda snow smdk5250 harmony 
 seaboard
 ventana whistler colibri_t20_iris plutux medcom-wide tec paz00 trimslice )
 --

 Tried with MAKEALL
 got following result

 - SUMMARY 
 Boards compiled: 306
 Boards with errors: 1 ( omap3_evm )
 Boards with warnings but no errors: 17 ( VCMA9 smdk2410 kzm9g balloon3
 h2200 lubbock palmld palmtc polaris pxa255_idp trizepsiv
 vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 xaeniax zipitz2
 colibri_pxa270 )
 --


**Without my patches i get following result

- SUMMARY 
Boards compiled: 306
Boards with warnings but no errors: 17 ( VCMA9 smdk2410 kzm9g balloon3
h2200 lubbock palmld palmtc polaris pxa255_idp trizepsiv
vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 xaeniax zipitz2
colibri_pxa270 )
--


 There's something to do with Cross Compiler version ??
 btw what environment are you compiling the source with.


-- 
Thanks  Regards
Vivek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 07/12] mtd: nand: add Faraday FTNANDC021 NAND controller support

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-8-git-send-email-dant...@gmail.com you wrote:
...
 +/* Register access macros */
 +#define NAND_READ(r) le32_to_cpu(readl(r))
 +#define NAND_WRITE(v, r) writel(cpu_to_le32(v), r)
 +#define NAND_SETBITS(m, r)   setbits_le32(r, m)
 +#define NAND_CLRBITS(m, r)   clrbits_le32(r, m)

As before: drop these.

 + /* wait until chip ready */
 + while (NAND_READ(regs-srr)  SRR_CHIP_RESET)
 + ;

Please add a timeout (and fix similar locations in the rest of the
code if there are such).

 + switch (priv-bksz / priv-pgsz) {
 + case 16:
 + bk = 0;
 + break;
 + case 32:
 + bk = 1;
 + break;
 + case 64:
 + bk = 2;
 + break;
 + case 128:
 + bk = 3;
 + break;
 + }

bk = ffs(priv-bksz / priv-pgsz) - 4;

?

 + switch (priv-adrc) {
 + case 3:
 + ac = 0;
 + break;
 + case 4:
 + ac = 1;
 + break;
 + case 5:
 + ac = 2;
 + break;
 + }

ac = priv-adrc - 3;

?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You're just jealous. What, of an overgrown puppy  with  a  single-
figure IQ?  - Terry Pratchett, _Moving Pictures_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 0/8] usb: ss: Some fixes and cleanup for USB super-speed support

2013-04-18 Thread Vivek Gautam
HI Marek,


On Thu, Apr 18, 2013 at 4:29 PM, Vivek Gautam gautamvivek1...@gmail.com wrote:
 On Thu, Apr 18, 2013 at 11:54 AM, Vivek Gautam
 gautamvivek1...@gmail.com wrote:
 Hi Marek,


 On Sun, Apr 14, 2013 at 11:43 PM, Marek Vasut ma...@denx.de wrote:
 Dear Vivek Gautam,

 Based on 'u-boot-usb' master branch.

 This patch-series includes majorly some clean-up, few fixes and
 then some basic super-speed usb infrastructure addition, to help
 put support for XHCI in near future.

 btw can you test your patches with MAKEALL -a arm? I get this:

 - SUMMARY 
 Boards compiled: 306
 Boards with errors: 65 ( qong mx35pdk gplugd at91sam9m10g45ek_nandflash 
 pogo_e02
 dns325 iconnect lschlv2 lsxhl d2net_v2 inetspace_v2 net2big_v2 
 netspace_lite_v2
 netspace_max_v2 netspace_v2 wireless_space dreamplug guruplug 
 mv88f6281gtw_ge
 openrd_base openrd_client openrd_ultimate rd6281a sheevaplug ib62x0 dockstar
 tk71 zmx25 mx23_olinuxino apx4devkit mx23evk m28evk mx28evk sc_sps_1 
 edminiv2
 mx51_efikamx mx51_efikasb mx51evk mx53loco mx6qsabreauto mx6qsabrelite
 nitrogen6dl nitrogen6dl2g nitrogen6q nitrogen6q2g nitrogen6s nitrogen6s1g 
 cm_t35
 mt_ventoux omap3_beagle mcx twister omap4_panda snow smdk5250 harmony 
 seaboard
 ventana whistler colibri_t20_iris plutux medcom-wide tec paz00 trimslice )
 --

 Tried with MAKEALL
 got following result

 - SUMMARY 
 Boards compiled: 306
 Boards with errors: 1 ( omap3_evm )
 Boards with warnings but no errors: 17 ( VCMA9 smdk2410 kzm9g balloon3
 h2200 lubbock palmld palmtc polaris pxa255_idp trizepsiv
 vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 xaeniax zipitz2
 colibri_pxa270 )
 --

I actually checked now just for omap3_evm configuration by trying out:
  make distclean
  make omap3_evm_config
  make

But strangely i didn't get any build errros for omap3_evm board on
explicitly compiling for it.
Any clue ?



 **Without my patches i get following result

 - SUMMARY 
 Boards compiled: 306
 Boards with warnings but no errors: 17 ( VCMA9 smdk2410 kzm9g balloon3
 h2200 lubbock palmld palmtc polaris pxa255_idp trizepsiv
 vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 xaeniax zipitz2
 colibri_pxa270 )
 --


 There's something to do with Cross Compiler version ??
 btw what environment are you compiling the source with.

I am using arm-2011.09 cross toolchain.



-- 
Thanks  Regards
Vivek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 08/12] mtd: spi: add FTSPI020 SPI Flash controller support

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-9-git-send-email-dant...@gmail.com you wrote:
...
 +/* Register access macros */
 +#define SPI_READ(r)  le32_to_cpu(readl(r))
 +#define SPI_WRITE(v, r)  writel(cpu_to_le32(v), r)
 +#define SPI_SETBITS(m, r)setbits_le32(r, m)
 +#define SPI_CLRBITS(m, r)clrbits_le32(r, m)

see before...

 + struct spi_flash_info *fl = (struct spi_flash_info *)flash;
 + return fl-chip;

Please always insert a blank line between declarations and code.

 +static const struct spi_flash_param sf_list[] = {
 +
 + /* Atmel -- some are (confusingly) marketed as DataFlash */
 + { at25fs010,  0x1f6601, 0, 32 * 1024,   4 },
 + { at25fs040,  0x1f6604, 0, 64 * 1024,   8 },
 +
 + { at25df041a, 0x1f4401, 0, 64 * 1024,   8 },
 + { at25df321a, 0x1f4701, 0, 64 * 1024,  64 },
 + { at25df641,  0x1f4800, 0, 64 * 1024, 128 },
...

should we not rather move this into a separate, global header file?

 + for (i = 0; i  ARRAY_SIZE(id32); ++i) {
 + /* wait until rx ready */
 + while (!(SPI_READ(regs-sr)  SR_RFR))
 + ;

See previous note about timeouts.  Please fix globally.

 + /* wait until command finish */
 + while (!(SPI_READ(regs-isr)  ISR_CMD))
 + ;

Ditto. etc. etc.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Ja, mach' nur einen Plan,sei nur ein grosses Licht
und mach' dann noch 'nen zweiten Plan,geh'n tun sie beide nicht.
 -- Bert Brecht, Dreigroschenoper
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 09/12] usb: ehci: add Faraday USB 2.0 EHCI support

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-10-git-send-email-dant...@gmail.com you wrote:
...
 +#define HCD_READ(r)  le32_to_cpu(readl(r))
 +#define HCD_WRITE(v, r)  writel(cpu_to_le32(v), r)
 +#define HCD_SETBITS(m, r)setbits_le32(r, m)
 +#define HCD_CLRBITS(m, r)clrbits_le32(r, m)

As before...


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I'm a programmer: I don't buy software, I write it.
  -- Tom Christiansen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 10/12] usb: gadget: add Faraday FOTG210 USB gadget support

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-11-git-send-email-dant...@gmail.com you wrote:
 From: Kuo-Jung Su dant...@faraday-tech.com
 
 The Faraday FOTG210 is an OTG chip which could operate
 as either an EHCI Host or a USB Device as a time.
...
 + uint32_t maxpacket:16;
 + uint32_t id:4;
 + uint32_t stopped:1;
 + uint32_t rsvd:11;

Please do NOT use bit fields.  Fix globally.

 +#define USB_READ(r)  le32_to_cpu(readl(r))
 +#define USB_WRITE(v, r)  writel(cpu_to_le32(v), r)
 +#define USB_SETBITS(m, r)setbits_le32(r, m)
 +#define USB_CLRBITS(m, r)clrbits_le32(r, m)

As before...


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
e-credibility: the non-guaranteeable likelihood that  the  electronic
data you're seeing is genuine rather than somebody's made-up crap.
- Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 11/12] arm: add MMU/d-cache support for Faraday cores

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-12-git-send-email-dant...@gmail.com you wrote:
...
 --- a/common/cmd_boot.c
 +++ b/common/cmd_boot.c
 @@ -50,6 +50,10 @@ static int do_go(cmd_tbl_t *cmdtp, int flag, int argc, 
 char * const argv[])
 
   printf (## Starting application at 0x%08lX ...\n, addr);
 
 +#if defined(__ARM__)  !defined(CONFIG_SYS_DCACHE_OFF)
 + cleanup_before_linux();
 +#endif
 +
   /*
* pass address parameter as argv[0] (aka command name),
* and all remaining args

Thios affects global code. Please submit as separate patch.

And why exactly is this ARM specific?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
My play was a complete success.  The audience was a failure.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 12/12] arm: add Faraday A36x SoC platform support

2013-04-18 Thread Wolfgang Denk
Dear Kuo-Jung Su,

In message 1366277139-29728-13-git-send-email-dant...@gmail.com you wrote:
...
 +#define CONFIG_FTMAC1101
 +#define CONFIG_ETHADDR 00:84:14:72:61:69 /* used by env_common.c */
 +#define CONFIG_NETMASK 255.255.255.0
 +#define CONFIG_IPADDR  10.0.0.123
 +#define CONFIG_SERVERIP10.0.0.128

NAK.  We don't allow static global network configurations like that.


 +#define CONFIG_FTGMAC100   1
 +#define CONFIG_PHY_MAX_ADDR32 /* used by Ratbert's ftgmac100 only */
 +#define CONFIG_FTGMAC100_EGIGA 1  /* used by Ratbert's ftgmac100 only */
 +#define CONFIG_ETHADDR 00:84:14:72:61:69 /* used by env_common.c */
 +#define CONFIG_NETMASK 255.255.255.0
 +#define CONFIG_IPADDR  10.0.0.123
 +#define CONFIG_SERVERIP10.0.0.128

NAK again.

Hm... this looks like a LOT of repeated code.  Can you please factor
out the common parts into a separate file?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Vulcans worship peace above all.
-- McCoy, Return to Tomorrow, stardate 4768.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] crc32: Correct endianness of crc32 result

2013-04-18 Thread Albert ARIBAUD
Hi Wolfgang,

On Thu, 18 Apr 2013 12:36:00 +0200, Wolfgang Denk w...@denx.de wrote:

 Dear Albert ARIBAUD,
 
 In message 20130418082027.4b5ea191@lilith you wrote:
  
   #ifdef USE_HOSTCC
  crc = htobe32(crc);
  memcpy(output, crc, sizeof(crc));
   #else
  crc = cpu_to_be32(crc);
  put_unaligned(crc, (uint32_t *)output);
   #endif
   
   This produces the same code as my original patch. If this is
   acceptable then I will do that, although it doesn't really seem any
   better.
  
  Wolfgang may not like it any more than put_unaligned_be32() as it
  builds upon it (and the disk patch could have used the be32 version as
 
 Indeed.
 
  well). Personally, I think we should allow and use these...
  
  ... and work on optimizing their implementation for ARM; we should be
  able to reduce such put()s and get()s to a few instructions. And to
 
 OK - and what about the other architectures that suffer from the same
 issues?

They should/could provide their own optimized versions, obviously.

  avoid any misunderstanding, yes, I volunteer for the optimizing work. :)
 
 I really dislike introducing such custom functions when we have
 standard functions available that implement the same purposes.

I understand the point; this is a classical opposition of generic vs
optimized.

 Checking Linux code (as U-Boot is not representative here):
 
   - find * -name '*.c' | wc -l
   18362
   - find * -name '*.c' | xargs fgrep -l put_unaligned | wc -l
   136
 
 i. e. just 0.75% of the source files actually use any of the
 put_unaligned*() variants - it is a highly exotic function.
 
 htobe32() is even worse - just a single source file in the whole Lnux
 tree uses it (arch/um/drivers/cow_user.c).
 
 
 Can we not stick to standard functions?  Instead of htobe32() we
 should use htonl() which is available both in U-Boot and in the host
 environment.

Note that there are two problems here: endianness conversion and
unaligned storage. We can indeed use htoln() instead of htobe32(), but
that only affects/solved endianness issues, not alignment ones, for
which there is no solution that is efficient across all ARM targets.

Note too that if the hash infrastructure mandated that the output
buffer be 4-byte-aligned, i.e. a u32* or similar, we would not even
have to worry about unalignment; such a constraint on the output
buffer makes all the more sense if we consider the fact that current
hash sizes are 4 (crc32), 20 (SHA1) and 32 (SHA256), all multiples of
4, and future hashes will most certainly not be less aligned.

So how about changing the element type of output in the definition of
hash_func_ws, adapting the corresponding implementations sha1_csum_wd,
sha256_csum_wd and crc32_wd_buf, and adapting the output argument
of the sole call to hash_func_ws, that is, the local u8
output[HASH_MAX_DIGEST_SIZE]; in hash.c? Then we'be done with
alignment.

Note finally that we *need* unaligned access macros/inline
functions/whatever, if only for exceptions laid out in
doc/README.arm-unaligned-accesses. If we avoid calling them too often,
we can live with generic.

 Best regards,
 
 Wolfgang Denk

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 0/8] usb: ss: Some fixes and cleanup for USB super-speed support

2013-04-18 Thread Marek Vasut
Dear Vivek Gautam,

 Hi,
 
 On Sun, Apr 14, 2013 at 10:44 PM, Marek Vasut ma...@denx.de wrote:
  Dear Vivek Gautam,
  
  Based on 'u-boot-usb' master branch.
  
  This patch-series includes majorly some clean-up, few fixes and
  then some basic super-speed usb infrastructure addition, to help
  put support for XHCI in near future.
  
  Changes from v2:
   - Added a patch usb: common: Weed out USB_**_PRINTFs from usb
   framework
   
 to replace USB_***_PRINTF with debug() so as to get rid of
 unnecessary DEBUG macros in usb common framework and thereby
 rebasing other patches on top of this so that no USB_PRINTF appears
 further.
   
   - Added a patch to reset only USB 2.0 ports, since USB 3.0 protocol
   ports
   
 don't require a reset to happen to move to 'enabled' state.
   
   - Added a patch to move definition of 'min3()' out of ehci-hcd and
   putting
   
 the same as macro definition in common header.
   
   - Using a 'switch-case' in portspeed() in cmd_usb.c
  
  Changes from v1:
   - Fixing the issue with 'ifno' as well as added 'if_desc'.
   - Instead of turning-on only powered-off hub ports, power-cycle all
   
 the hub ports (aka: turning off and then turning on again power to
 all the ports.
   
   - Fixing commenting style problem in
   
 'usb: Update device class in usb device's descriptor'
   
   - Fixing typo in commit message for
   
 'usb: hub: Fix enumration timeout'
   
   - Removing separate definition for 'struct usb_ep_desc'; thereby adding
   
 'struct usb_ss_ep_comp_descriptor' to 'struct usb_interface' only.
 As a result modifying the patch accordingly also dropping the patch
 'usb: eth: Fix for updated usb interface descriptor structure'
   
   - Dropping the patch 'usb: hub: Increase device enumeration timeout for
  
  broken drives' for now (will come back with a solution at later point of
  time).
  
  Applied all but the last one, let's now base all subsequent patches on
  u-boot- usb/next please.
 
 And i can't see these patches on u-boot-usb/next. Possibly you haven't
 pushed out yet ??

You're right, sorry! Fixed now

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 0/8] usb: ss: Some fixes and cleanup for USB super-speed support

2013-04-18 Thread Marek Vasut
Dear Vivek Gautam,

 HI Marek,
 
 On Thu, Apr 18, 2013 at 4:29 PM, Vivek Gautam gautamvivek1...@gmail.com 
wrote:
  On Thu, Apr 18, 2013 at 11:54 AM, Vivek Gautam
  
  gautamvivek1...@gmail.com wrote:
  Hi Marek,
  
  On Sun, Apr 14, 2013 at 11:43 PM, Marek Vasut ma...@denx.de wrote:
  Dear Vivek Gautam,
  
  Based on 'u-boot-usb' master branch.
  
  This patch-series includes majorly some clean-up, few fixes and
  then some basic super-speed usb infrastructure addition, to help
  put support for XHCI in near future.
  
  btw can you test your patches with MAKEALL -a arm? I get this:
  
  - SUMMARY 
  Boards compiled: 306
  Boards with errors: 65 ( qong mx35pdk gplugd at91sam9m10g45ek_nandflash
  pogo_e02 dns325 iconnect lschlv2 lsxhl d2net_v2 inetspace_v2
  net2big_v2 netspace_lite_v2 netspace_max_v2 netspace_v2 wireless_space
  dreamplug guruplug mv88f6281gtw_ge openrd_base openrd_client
  openrd_ultimate rd6281a sheevaplug ib62x0 dockstar tk71 zmx25
  mx23_olinuxino apx4devkit mx23evk m28evk mx28evk sc_sps_1 edminiv2
  mx51_efikamx mx51_efikasb mx51evk mx53loco mx6qsabreauto mx6qsabrelite
  nitrogen6dl nitrogen6dl2g nitrogen6q nitrogen6q2g nitrogen6s
  nitrogen6s1g cm_t35 mt_ventoux omap3_beagle mcx twister omap4_panda
  snow smdk5250 harmony seaboard ventana whistler colibri_t20_iris
  plutux medcom-wide tec paz00 trimslice )
  --
  
  Tried with MAKEALL
  got following result
  
  - SUMMARY 
  Boards compiled: 306
  Boards with errors: 1 ( omap3_evm )
  Boards with warnings but no errors: 17 ( VCMA9 smdk2410 kzm9g balloon3
  h2200 lubbock palmld palmtc polaris pxa255_idp trizepsiv
  vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 xaeniax zipitz2
  colibri_pxa270 )
  --
 
 I actually checked now just for omap3_evm configuration by trying out:
   make distclean
   make omap3_evm_config
   make
 
 But strangely i didn't get any build errros for omap3_evm board on
 explicitly compiling for it.
 Any clue ?
 
  **Without my patches i get following result
  
  - SUMMARY 
  Boards compiled: 306
  Boards with warnings but no errors: 17 ( VCMA9 smdk2410 kzm9g balloon3
  h2200 lubbock palmld palmtc polaris pxa255_idp trizepsiv
  vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 xaeniax zipitz2
  colibri_pxa270 )
  --
  
  There's something to do with Cross Compiler version ??
  btw what environment are you compiling the source with.
 
 I am using arm-2011.09 cross toolchain.

I use ELDK 5.3 and Debian 4.7.2-5 to do by builds. But now that I'm looking at 
it, it's this patch that caused it, sorry.

commit 28b31a5937b89528c40df24dd6c9122578880605
Author: Julius Werner jwer...@chromium.org
Date:   Thu Feb 28 18:08:40 2013 +

usb: Add new command to set USB 2.0 port test modes

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8464850..19d4352 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -630,7 +630,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long 
pipe, 
void *buffer,
printf(The request port(%d) is not configured\n, port - 1);
return -1;
}
-   status_reg = (uint32_t *)hcor-or_portsc[port - 1];
+   status_reg = (uint32_t *)ctrl-hcor-or_portsc[port - 1];
srclen = 0;
 
debug(req=%u (%#x), type=%u (%#x), value=%u, index=%u\n,

This change fixes is, right Julius ?

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 0/8] usb: ss: Some fixes and cleanup for USB super-speed support

2013-04-18 Thread Vivek Gautam
On Thu, Apr 18, 2013 at 6:08 PM, Marek Vasut ma...@denx.de wrote:
 Dear Vivek Gautam,

 Hi,

 On Sun, Apr 14, 2013 at 10:44 PM, Marek Vasut ma...@denx.de wrote:
  Dear Vivek Gautam,
 
  Based on 'u-boot-usb' master branch.
 
  This patch-series includes majorly some clean-up, few fixes and
  then some basic super-speed usb infrastructure addition, to help
  put support for XHCI in near future.
 
  Changes from v2:
   - Added a patch usb: common: Weed out USB_**_PRINTFs from usb
   framework
 
 to replace USB_***_PRINTF with debug() so as to get rid of
 unnecessary DEBUG macros in usb common framework and thereby
 rebasing other patches on top of this so that no USB_PRINTF appears
 further.
 
   - Added a patch to reset only USB 2.0 ports, since USB 3.0 protocol
   ports
 
 don't require a reset to happen to move to 'enabled' state.
 
   - Added a patch to move definition of 'min3()' out of ehci-hcd and
   putting
 
 the same as macro definition in common header.
 
   - Using a 'switch-case' in portspeed() in cmd_usb.c
 
  Changes from v1:
   - Fixing the issue with 'ifno' as well as added 'if_desc'.
   - Instead of turning-on only powered-off hub ports, power-cycle all
 
 the hub ports (aka: turning off and then turning on again power to
 all the ports.
 
   - Fixing commenting style problem in
 
 'usb: Update device class in usb device's descriptor'
 
   - Fixing typo in commit message for
 
 'usb: hub: Fix enumration timeout'
 
   - Removing separate definition for 'struct usb_ep_desc'; thereby adding
 
 'struct usb_ss_ep_comp_descriptor' to 'struct usb_interface' only.
 As a result modifying the patch accordingly also dropping the patch
 'usb: eth: Fix for updated usb interface descriptor structure'
 
   - Dropping the patch 'usb: hub: Increase device enumeration timeout for
 
  broken drives' for now (will come back with a solution at later point of
  time).
 
  Applied all but the last one, let's now base all subsequent patches on
  u-boot- usb/next please.

 And i can't see these patches on u-boot-usb/next. Possibly you haven't
 pushed out yet ??

 You're right, sorry! Fixed now

Thanks you so much !!

-- 
Thanks  Regards
Vivek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] status i2c uboot driver ST Microelectronics

2013-04-18 Thread Mathias LEBLANC
Hi Simon,

Yes i saw his reply and i work on it.
I tested the tpm driver on a beagleboard but it can be used to every motherboard

Regards,

Mathias Leblanc

From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
Sent: 18 April, 2013 04:22
To: Mathias LEBLANC
Cc: Shawn Nematbakhsh; U-Boot@lists.denx.de; Taylor Hutt; Che-Liang Chiou; 
Jean-Luc BLANC
Subject: Re: status i2c uboot driver ST Microelectronics

Hi,

On Mon, Apr 8, 2013 at 12:59 AM, Mathias LEBLANC 
mathias.lebl...@st.commailto:mathias.lebl...@st.com wrote:
Hello,

Do you know what the status of the test and the publication of the I2C uboot 
driver from STMicroelectronics?

Do you mean this?

http://patchwork.ozlabs.org/patch/234791/

I think it attracted some comments which need addressing in a new version. If 
you get that done in the next few weeks then you will hit the merge window.

What boards use this TPM?

Regards,
Simon


Thanks,

Best Regards,
Mathias Leblanc,


STMicroelectronics - Rousset
Smartcard - TPM Application
Application Engineer
*  04 42 68 80 26
* mathias.lebl...@st.commailto:%20robert.tal...@st.com


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4] palmtreo680: add utility that writes u-boot to flash

2013-04-18 Thread Marek Vasut
Dear Mike Dunn,

[...]

 + if (argc != 3) {
 + printf(usage: %s image file mtd dev node\n, argv[0]);

btw is this /dev/mtdX or /dev/mtdblockX ?

 + return -1;

errno.h didn't work? Like ... return -EINVAL or such ?

[...]

 + blockbuf = calloc(RELIABLE_BLOCKSIZE, 1);

calloc() semantics are misunderstood by so many :-(

[...]

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] crc32: Correct endianness of crc32 result

2013-04-18 Thread Wolfgang Denk
Dear Albert,

In message 20130418131810.38c916b8@lilith you wrote:
 
  OK - and what about the other architectures that suffer from the same
  issues?
 
 They should/could provide their own optimized versions, obviously.

Well, if this was a generally needed or even useful service, that
might make sense.  But it is highly exotic stuff...

  I really dislike introducing such custom functions when we have
  standard functions available that implement the same purposes.
 
 I understand the point; this is a classical opposition of generic vs
 optimized.

Not really.  It is more opposition against premature optimization at
the cost of non-standard code.

Is there any justification that we really need hightly optimized
versus generic code here?  Is this used anywhere in a place where
performance is critical?

  Can we not stick to standard functions?  Instead of htobe32() we
  should use htonl() which is available both in U-Boot and in the host
  environment.
 
 Note that there are two problems here: endianness conversion and
 unaligned storage. We can indeed use htoln() instead of htobe32(), but
 that only affects/solved endianness issues, not alignment ones, for
 which there is no solution that is efficient across all ARM targets.

Correct.  But the htobe32() approach was cobining this with the
generic memcpy(), too, so we would do the same with htoln().

 So how about changing the element type of output in the definition of
 hash_func_ws, adapting the corresponding implementations sha1_csum_wd,
 sha256_csum_wd and crc32_wd_buf, and adapting the output argument
 of the sole call to hash_func_ws, that is, the local u8
 output[HASH_MAX_DIGEST_SIZE]; in hash.c? Then we'be done with
 alignment.

OK, but that would be a totally different approach (which appears to
be a good one, here).

 Note finally that we *need* unaligned access macros/inline
 functions/whatever, if only for exceptions laid out in
 doc/README.arm-unaligned-accesses. If we avoid calling them too often,
 we can live with generic.

Agreed; the focus should always be on avoidance, though.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
\|/  \|/ \|/  \|/
 @~/ ,. \~@   @~/ ,. \~@
/_( \__/ )_\ /_( \__/ )_\
   \__U_/   \__U_/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx: Complete the pin definitions for the i.MX6DL / i.MX6Solo

2013-04-18 Thread Wolfgang Denk
Dear Pierre Aubert,

In message 1366286251-17552-1-git-send-email-p.aub...@staubli.com you wrote:
 Signed-off-by: Pierre Aubert p.aub...@staubli.com
 CC: Stefano Babic sba...@denx.de

What is the purpose of this patch?  Who needs the added definitions?

The new formatting is less readable than the old one.  We have an
agreement that in this special case we accept lines longer than 80
charcters, so please leave the formatting as is.

[It's basically imposible to see in your patch what you actually
added.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Never underestimate the power of human stupidity  when  it  comes  to
using technology they don't understand.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] imx: Add support for the SabreSD shipped with i.MX6DL

2013-04-18 Thread Pierre Aubert
The SabreSD platform is available with i.MX6Q or i.MX6DL. This patch adds the
support of the i.MX6DL. The config file and the board directory are renamed
to remove the reference to the MX6Q.


Signed-off-by: Pierre Aubert p.aub...@staubli.com
CC: Stefano Babic sba...@denx.de
---
 .../freescale/{mx6qsabresd = mx6sabresd}/Makefile |2 +-
 .../mx6qsabresd.c = mx6sabresd/mx6sabresd.c}  |   11 ++-
 boards.cfg |5 +++--
 include/configs/mx6qsabreauto.h|2 +-
 .../{mx6qsabre_common.h = mx6sabre_common.h}  |1 -
 include/configs/{mx6qsabresd.h = mx6sabresd.h}|2 +-
 6 files changed, 12 insertions(+), 11 deletions(-)
 rename board/freescale/{mx6qsabresd = mx6sabresd}/Makefile (98%)
 rename board/freescale/{mx6qsabresd/mx6qsabresd.c = mx6sabresd/mx6sabresd.c} 
(98%)
 rename include/configs/{mx6qsabre_common.h = mx6sabre_common.h} (99%)
 rename include/configs/{mx6qsabresd.h = mx6sabresd.h} (97%)

diff --git a/board/freescale/mx6qsabresd/Makefile 
b/board/freescale/mx6sabresd/Makefile
similarity index 98%
rename from board/freescale/mx6qsabresd/Makefile
rename to board/freescale/mx6sabresd/Makefile
index 5693772..ff3c94b 100644
--- a/board/freescale/mx6qsabresd/Makefile
+++ b/board/freescale/mx6sabresd/Makefile
@@ -23,7 +23,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(BOARD).o
 
-COBJS  := mx6qsabresd.o
+COBJS  := mx6sabresd.o
 
 SRCS   := $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS))
diff --git a/board/freescale/mx6qsabresd/mx6qsabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
similarity index 98%
rename from board/freescale/mx6qsabresd/mx6qsabresd.c
rename to board/freescale/mx6sabresd/mx6sabresd.c
index 0d7cb9e..dcefdab 100644
--- a/board/freescale/mx6qsabresd/mx6qsabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -17,12 +17,10 @@
  * GNU General Public License for more details.
  */
 
-#include common.h
-#include asm/io.h
 #include asm/arch/clock.h
 #include asm/arch/imx-regs.h
 #include asm/arch/iomux.h
-#include asm/arch/mx6q_pins.h
+#include asm/arch/mx6-pins.h
 #include asm/errno.h
 #include asm/gpio.h
 #include asm/imx-common/iomux-v3.h
@@ -291,7 +289,10 @@ int board_late_init(void)
 
 int checkboard(void)
 {
-   puts(Board: MX6Q-SabreSD\n);
-
+#ifdef CONFIG_MX6Q
+puts(Board: MX6Q-SabreSD\n);
+#else
+puts(Board: MX6DL-SabreSD\n);
+#endif
return 0;
 }
diff --git a/boards.cfg b/boards.cfg
index f785da8..c002cf7 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -256,9 +256,10 @@ mx53smd  arm armv7   
mx53smd freesca
 ima3-mx53arm armv7   ima3-mx53   esg   
 mx5ima3-mx53:IMX_CONFIG=board/esg/ima3-mx53/imximage.cfg
 vision2  arm armv7   vision2 
ttcontrol  mx5
vision2:IMX_CONFIG=board/ttcontrol/vision2/imximage_hynix.cfg
 mx6qarm2 arm armv7   mx6qarm2
freescale  mx6
mx6qarm2:IMX_CONFIG=board/freescale/mx6qarm2/imximage.cfg
-mx6qsabreautoarm armv7   mx6qsabreauto   
freescale  mx6
mx6qsabreauto:IMX_CONFIG=board/freescale/mx6qsabreauto/imximage.cfg
+mx6qsabreautoarm armv7   mx6qsabreauto   
freescale  mx6
mx6qsabreauto:IMX_CONFIG=board/freescale/mx6qsabreauto/imximage.cfg,MX6Q
 mx6qsabrelitearm armv7   mx6qsabrelite   
freescale  mx6
mx6qsabrelite:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
-mx6qsabresd  arm armv7   mx6qsabresd 
freescale  mx6
mx6qsabresd:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
+mx6qsabresd  arm armv7   mx6sabresd 
freescale  mx6 
mx6sabresd:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q
+mx6dlsabresd  arm armv7   mx6sabresd 
freescale  mx6
mx6sabresd:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL
 eco5pk   arm armv7   eco5pk  
8dtech omap3
 nitrogen6dl  arm armv7   nitrogen6x  
boundary   mx6
nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL,DDR_MB=1024
 nitrogen6dl2garm armv7   nitrogen6x  
boundary   mx6
nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl2g.cfg,MX6DL,DDR_MB=2048
diff --git a/include/configs/mx6qsabreauto.h b/include/configs/mx6qsabreauto.h
index 1583c11..099839a 100644
--- a/include/configs/mx6qsabreauto.h
+++ b/include/configs/mx6qsabreauto.h
@@ -30,7 +30,7 @@
 #define CONFIG_MXC_USB_PORTSC  (PORT_PTS_UTMI | PORT_PTS_PTW)
 #define CONFIG_MXC_USB_FLAGS   0
 
-#include mx6qsabre_common.h

Re: [U-Boot] [PATCH] imx: Complete the pin definitions for the i.MX6DL / i.MX6Solo

2013-04-18 Thread Pierre AUBERT

Hello Wolfgang,

Le 18/04/2013 16:41, Wolfgang Denk a écrit :

Dear Pierre Aubert,

In message 1366286251-17552-1-git-send-email-p.aub...@staubli.com you wrote:

Signed-off-by: Pierre Aubert p.aub...@staubli.com
CC: Stefano Babic sba...@denx.de

What is the purpose of this patch?  Who needs the added definitions?

These new definitions are useful for all boards based on i.MX6DL or
i.MX6Solo.
I just submitted a patch to support SabreSD equipped with i.MX6DL.
I missed the submission of two patches together.


The new formatting is less readable than the old one.  We have an
agreement that in this special case we accept lines longer than 80
charcters, so please leave the formatting as is.

That was my concern not exceed 80 characters.


[It's basically imposible to see in your patch what you actually
added.]

Ok, I will revert it.

Best regards
Pierre Aubert
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4] palmtreo680: add utility that writes u-boot to flash

2013-04-18 Thread Mike Dunn
On 04/18/2013 06:54 AM, Marek Vasut wrote:
 Dear Mike Dunn,
 
 [...]
 
 +if (argc != 3) {
 +printf(usage: %s image file mtd dev node\n, argv[0]);
 
 btw is this /dev/mtdX or /dev/mtdblockX ?


/dev/mtdx  You must have defined a partition that starts at the offset at which
you are placing the u-boot image, and of course is big enough to hold the image.


 
 +return -1;
 
 errno.h didn't work? Like ... return -EINVAL or such ?


'return -EINVAL' works, sure.  Are you suggesting that the utility should return
an intelligent error code at all failure exit points?  Like if the call to
calloc() fails, it should return -ENOMEM?  I could do that if you prefer.  I
didn't worry about it because I always print the reason for the failure to
stderr, usually by way of perror().  Sorry, I guess I didn't understand your
initial suggestion.


 
 [...]
 
 +blockbuf = calloc(RELIABLE_BLOCKSIZE, 1);
 
 calloc() semantics are misunderstood by so many :-(


calloc(RELIABLE_BLOCKSIZE, sizeof(char)) ?


Thanks,
Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx: mx6q_4x_mt41j128.cfg: Setup CCM_CCOSR register

2013-04-18 Thread Fabio Estevam
On Thu, Apr 18, 2013 at 2:27 AM, prem s prem...@gmail.com wrote:
 Hi all,

 I am working on IMX6Q-SabreLite Board.in that board we have sgtl5000
 codec.so I would like to add (sgtl5000) codec support in u-boot level.There
 is no code available in u-boot level for this codec.Can you please help me
 How to initialize this audio codec and how to test this one in UBOOT level.

 It will be very helpful if you send any u-boot level patch for this
 codec(sgtl5000).

I don't have plans to adding audio support into U-boot for imx.

Maybe you could try to use the OBDS code from Freescale, which
provides standalone code for setting up various peripherals and then
you can use it as a reference for adding audio support in U-boot.

Just curious: what is your requirement in terms of providing the user
with an audio response?

Would booting the kernel fast and providing the audio response in the
kernel meet your goal?

Regards,

Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4] palmtreo680: add utility that writes u-boot to flash

2013-04-18 Thread Marek Vasut
Dear Mike Dunn,

 On 04/18/2013 06:54 AM, Marek Vasut wrote:
  Dear Mike Dunn,
  
  [...]
  
  +  if (argc != 3) {
  +  printf(usage: %s image file mtd dev node\n, argv[0]);
  
  btw is this /dev/mtdX or /dev/mtdblockX ?
 
 /dev/mtdx  You must have defined a partition that starts at the offset at
 which you are placing the u-boot image, and of course is big enough to
 hold the image.
 
  +  return -1;
  
  errno.h didn't work? Like ... return -EINVAL or such ?
 
 'return -EINVAL' works, sure.  Are you suggesting that the utility should
 return an intelligent error code at all failure exit points?  Like if the
 call to calloc() fails, it should return -ENOMEM?  I could do that if you
 prefer.  I didn't worry about it because I always print the reason for the
 failure to stderr, usually by way of perror().  Sorry, I guess I didn't
 understand your initial suggestion.

I think it's more correct to return proper error code, maybe try getting 
opinion from the others.

  [...]
  
  +  blockbuf = calloc(RELIABLE_BLOCKSIZE, 1);
  
  calloc() semantics are misunderstood by so many :-(
 
 calloc(RELIABLE_BLOCKSIZE, sizeof(char)) ?

from malloc(3):

   void *calloc(size_t nmemb, size_t size);

[...]

The  calloc() function allocates memory for an array of nmemb elements of size
bytes each and returns a pointer to the allocated memory.  The memory is set to
zero.  If nmemb or size is 0, then calloc() returns either NULL, or  a  unique
pointer value that can later be successfully passed to free().

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] How do I use AM335x eth1 rather than eth0 ?

2013-04-18 Thread Bo Shen

Hi Mark,

On 04/12/2013 06:32 PM, Mark Jackson wrote:

We have a dual Ethernet board (based on the BeagelBone) but with both Ethernet 
ports connected.

I'm wanting to use eth1 (rather than eth0), so in my board.c file, I changed:-

static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs  = 0x208,
.sliver_reg_ofs = 0xd80,
.phy_id = 0,
},
{
.slave_reg_ofs  = 0x308,
.sliver_reg_ofs = 0xdc0,
.phy_id = 1,
},
};

... to ...

static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs  = 0x308,
.sliver_reg_ofs = 0xdc0,
.phy_id = 1,
},
{
.slave_reg_ofs  = 0x208,
.sliver_reg_ofs = 0xd80,
.phy_id = 0,
},
};

... assuming that eth0 would now be ignored (as only 1 slave is configured).

But (eg) dhcp still only responds on eth0 !?!

What else do I have to change ?


Have you try setenv ethprime eth1? Then reset board, and do dhcp.

Best Regards,
Bo Shen



Cheers
Mark J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/19] Remove unused code, add accurate timier and bootstage

2013-04-18 Thread вб
 On Wed, Apr 17, 2013 at 7:13 PM, Simon Glass s...@chromium.org wrote:

 This series removes unused x86 code based on advice from Graeme Russ. THis
 code was used for real mode which is no longer needed in U-Boot.

 A new more accurate timer is added, and this permits bootstage to be
 enabled and produce useful results on x86.


 Doug Anderson (2):
   bootstage: Copy bootstage strings post-relocation
   Call bootstage_relocate() after malloc is initted

 Simon Glass (17):
   x86: Remove unused bios/pci code
   x86: Remove unused portion of link script
   x86: Remove legacy board init code
   x86: Declare global_data pointer when it is used
   x86: Implement panic output for coreboot
   x86: Rationalise kernel booting logic and bootstage
   x86: Add TSC timer
   x86: Remove old broken timer implementation
   x86: Remove ISR timer
   x86: Re-enable PCAT timer 2 for beeping
   bootstage: Add stubs for new bootstage functions
   x86: Enable bootstage for coreboot
   bootstage: Allow marking a particular line of code
   x86: Fix warning in cmd_ximg.c when CONFIG_GZIP is not defined
   x86: config: Enable LZO for coreboot, remove zlib, gzip
   x86: Support adding coreboot timestanps to bootstage
   x86: Add coreboot timestamps

  arch/x86/cpu/Makefile  |   2 +-
  arch/x86/cpu/coreboot/coreboot.c   |  13 ++
  arch/x86/cpu/coreboot/timestamp.c  |  42 +++-
  arch/x86/cpu/cpu.c |   5 +
  arch/x86/cpu/interrupts.c  |   2 +
  arch/x86/cpu/timer.c   |  17 --
  arch/x86/cpu/u-boot.lds|  12 --
  arch/x86/include/asm/arch-coreboot/timestamp.h |   7 +
  arch/x86/include/asm/init_helpers.h|   9 -
  arch/x86/include/asm/init_wrappers.h   |  42 
  arch/x86/include/asm/pci.h |   4 -
  arch/x86/include/asm/u-boot-x86.h  |   4 +
  arch/x86/include/asm/u-boot.h  |  32 ---
  arch/x86/lib/Makefile  |  10 +-
  arch/x86/lib/bios.h| 170 ---
  arch/x86/lib/board.c   | 273 
 -
  arch/x86/lib/bootm.c   |   8 -
  arch/x86/lib/cmd_boot.c|   2 +
  arch/x86/lib/init_helpers.c|  98 -
  arch/x86/lib/init_wrappers.c   | 164 ---
  arch/x86/lib/pcat_timer.c  |  69 +--
  arch/x86/lib/pci.c | 188 -
  arch/x86/lib/physmem.c |   2 +
  arch/x86/lib/relocate.c|   2 +
  arch/x86/lib/timer.c   | 116 ---
  arch/x86/lib/tsc_timer.c   | 107 ++
  arch/x86/lib/zimage.c  |  11 +-
  common/board_r.c   |   1 +
  common/bootstage.c |  44 
  common/cmd_ximg.c  |   2 +
  include/bootstage.h|  54 +
  include/configs/coreboot.h |  18 +-
  32 files changed, 314 insertions(+), 1216 deletions(-)
  delete mode 100644 arch/x86/cpu/timer.c
  delete mode 100644 arch/x86/include/asm/init_wrappers.h
  delete mode 100644 arch/x86/lib/bios.h
  delete mode 100644 arch/x86/lib/board.c
  delete mode 100644 arch/x86/lib/init_wrappers.c
  delete mode 100644 arch/x86/lib/pci.c
  delete mode 100644 arch/x86/lib/timer.c
  create mode 100644 arch/x86/lib/tsc_timer.c

 --
 1.8.2.1


Simon, just out of curiosity: how was this tested, on what platforms,
what procedure was followed, etc.

--vb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [UBOOT PATCH 1/2] ARM:Panda:Fix device tree loading for the panda-es

2013-04-18 Thread Dan Murphy
Fix the device tree loading for panda(4430) and panda-es(4460)

Modify the board name if a 4460 panda or panda-es is detected
at run time.
In the findfdt add a check for the panda-es board name and load
the panda-es device tree blob.

Signed-off-by: Dan Murphy dmur...@ti.com
---
 board/ti/panda/panda.c |6 ++
 include/configs/omap4_common.h |4 +++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
index cab0598..2bbe392 100644
--- a/board/ti/panda/panda.c
+++ b/board/ti/panda/panda.c
@@ -82,6 +82,12 @@ int misc_init_r(void)
if (omap_revision() == OMAP4430_ES1_0)
return 0;
 
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+   if (omap_revision() = OMAP4460_ES1_0 ||
+   omap_revision() = OMAP4460_ES1_1)
+   setenv(board_name, strcat(CONFIG_SYS_BOARD, -es));
+#endif
+
gpio_direction_input(PANDA_ULPI_PHY_TYPE_GPIO);
phy_type = gpio_get_value(PANDA_ULPI_PHY_TYPE_GPIO);
 
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 1fd3097..68faeca 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -176,7 +176,9 @@
if test $board_name = sdp4430; then  \
setenv fdtfile omap4-sdp.dtb; fi;  \
if test $board_name = panda; then  \
-   setenv fdtfile omap4-panda-es.dtb; fi\0 \
+   setenv fdtfile omap4-panda.dtb; fi; \
+   if test $board_name = panda-es; then  \
+   setenv fdtfile omap4-panda-es.dtb; fi; \0 \
loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
 
 #define CONFIG_BOOTCOMMAND \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [UBOOT PATCH 2/2] ARM: Panda: Add flag to allow runtime enviroment varibale mods

2013-04-18 Thread Dan Murphy
Add the flag to allow runtime enviroment variable modifications.
This is being added so that the board-name can be modified at runtime
to indicate either a panda(4430) or a panda-es(4460)

Signed-off-by: Dan Murphy dmur...@ti.com
---
 include/configs/omap4_panda.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h
index eacb5f5..abf586b 100644
--- a/include/configs/omap4_panda.h
+++ b/include/configs/omap4_panda.h
@@ -66,4 +66,6 @@
 
 #define CONFIG_SYS_PROMPT  Panda # 
 
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+
 #endif /* __CONFIG_PANDA_H */
-- 
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] crc32: Correct endianness of crc32 result

2013-04-18 Thread Albert ARIBAUD
Hi Wolfgang,

On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk w...@denx.de wrote:

  So how about changing the element type of output in the definition of
  hash_func_ws, adapting the corresponding implementations sha1_csum_wd,
  sha256_csum_wd and crc32_wd_buf, and adapting the output argument
  of the sole call to hash_func_ws, that is, the local u8
  output[HASH_MAX_DIGEST_SIZE]; in hash.c? Then we'be done with
  alignment.
 
 OK, but that would be a totally different approach (which appears to
 be a good one, here).

Indeed; I would suggest splitting this change in two independent ones:

- fix the endianness issue: change the endianness of crc through the
  use of htonl() but leave the existing memcpy() in place as it is,
  even though it is not speed-optimized. That's what Simon's patch
  does if the HOSTCC part is ignored;

- fix the unalignment issue by changing parameter 'output' of function
  type 'hash_func_ws' from u8* to u32* and adjusting the rest of the
  code accordingly -- which would lead to replacing the crc32 final
  memcpy() with a single indirect assignment.

These two changes could be submitted either separately, or as a series.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] crc32: Correct endianness of crc32 result

2013-04-18 Thread Tom Rini
On Thu, Apr 18, 2013 at 06:39:29PM +0200, Albert ARIBAUD wrote:
 Hi Wolfgang,
 
 On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk w...@denx.de wrote:
 
   So how about changing the element type of output in the definition of
   hash_func_ws, adapting the corresponding implementations sha1_csum_wd,
   sha256_csum_wd and crc32_wd_buf, and adapting the output argument
   of the sole call to hash_func_ws, that is, the local u8
   output[HASH_MAX_DIGEST_SIZE]; in hash.c? Then we'be done with
   alignment.
  
  OK, but that would be a totally different approach (which appears to
  be a good one, here).
 
 Indeed; I would suggest splitting this change in two independent ones:
 
 - fix the endianness issue: change the endianness of crc through the
   use of htonl() but leave the existing memcpy() in place as it is,
   even though it is not speed-optimized. That's what Simon's patch
   does if the HOSTCC part is ignored;
 
 - fix the unalignment issue by changing parameter 'output' of function
   type 'hash_func_ws' from u8* to u32* and adjusting the rest of the
   code accordingly -- which would lead to replacing the crc32 final
   memcpy() with a single indirect assignment.
 
 These two changes could be submitted either separately, or as a series.

Now so that I'm clear, if we don't do anything about the unaligned issue
today, it's just slow, not an unaligned access that leads to abort,
right?  So part one today for release, part two next week after release.

-- 
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] [RFC] command/cache: Add flush_cache command

2013-04-18 Thread Scott Wood

On 04/03/2013 09:02:15 AM, Jim Chargin wrote:

I apologize for being so late with this question.

York Sun yorksun at freescale.com writes:


 When we need the copied code/data in the main memory, we can flush  
the

 cache now. It uses the existing function flush_cache. Syntax is

 flush_cache addr size

 The addr and size are given in hexadecimal. Like memory command,  
there is

 no sanity check for the parameters.


Are there symptoms for a specific system failure you can provide?


Generally you'd see code behaving in a way that is different than the  
instructions in memory (as seen by a load instruction) would suggest.   
Often it's obvious, such as an illegal instruction trap on on opcode  
that is valid, but it could be arbitrary depending on what the old  
contents of memory were (especially if there had been valid (but  
different) code there before).


My problem is that when a stand alone application, which is copied  
from NOR
flash to DDR, is started with the go command, it sometimes  
experiences a
program check (illegal instruction) after a block of 32 zero bytes  
appears in

memory.


Maybe the old contents of memory contained a dcbz?  Or somehow confused  
a legimate dcbz to target the wrong address.


I'm using a U-Boot for a custom Freescale P1022-based board,  
currently based on

the old 2010.12 U-Boot as patched by Freescale in their
SDK_V1_0_20110429_ltib.iso. Unfortunately, upgrading to a more recent  
version of
U-Boot is not possible at this time, no more recent version is  
available from
Freescale and I don't have the resources to verify all their patches  
apply

correctly to a release directly from DENX.


You can find the latest Freescale U-Boot at:
http://git.freescale.com/git/cgit.cgi/ppc/sdk/u-boot.git/
git://git.freescale.com/ppc/sdk/u-boot.git

...though there's a good chance that you would not need anything from  
the SDK if you run the latest upstream U-Boot.  You'd still need to  
apply your own patches for the custom board, of course.


(By the way, I would not leave the flush_dcache();  
invalidate_icache(); in
do_go(), I merely found that for demonstrating a possible solution,  
this change
easier than switching to a stand alone app that starts with bootm, or  
similar)


It seems reasonably likely that this is the cause of your problem; in  
any case, the flush is architecturally required.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] How do I use AM335x eth1 rather than eth0 ?

2013-04-18 Thread Wolfgang Denk
Dear Bo Shen,

In message 517015fc.20...@gmail.com you wrote:
 
  What else do I have to change ?
 
 Have you try setenv ethprime eth1? Then reset board, and do dhcp.

Before thje reset, doi also a saveenv to make the setting stick.

Or setenv ethact eth1 and retry then (without reset).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx: Add support for the SabreSD shipped with i.MX6DL

2013-04-18 Thread Wolfgang Denk
Dear Pierre Aubert,

In message 1366296086-22394-1-git-send-email-p.aub...@staubli.com you wrote:
 The SabreSD platform is available with i.MX6Q or i.MX6DL. This patch adds the
 support of the i.MX6DL. The config file and the board directory are renamed
 to remove the reference to the MX6Q.

Formal issues:

- entry to MAINTAINERS file missing
- there are 2 checkpatch warnings (please, no spaces at the start of
  a line) that need to be fixed.

  int checkboard(void)
  {
 - puts(Board: MX6Q-SabreSD\n);
 -
 +#ifdef CONFIG_MX6Q
 +puts(Board: MX6Q-SabreSD\n);
 +#else
 +puts(Board: MX6DL-SabreSD\n);
 +#endif

Can we please avoid such #ifdef's?  Here, we could for example refer
to the board name (CONFIG_SYS_BOARD if you like the name, or some
custom defined CONFIG_BOARD_NAME like other boards do).


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Tell the truth and run.  - Yugoslav proverb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx: Complete the pin definitions for the i.MX6DL / i.MX6Solo

2013-04-18 Thread Wolfgang Denk
Dear Pierre AUBERT,

In message 51700b80.2090...@staubli.com you wrote:
 
  What is the purpose of this patch?  Who needs the added definitions?
 These new definitions are useful for all boards based on i.MX6DL or
 i.MX6Solo.
 I just submitted a patch to support SabreSD equipped with i.MX6DL.
 I missed the submission of two patches together.

So your SabreSD patch depends on this one?

I just asked for some cleanup for that other patch, so when
resubmitting you can make this a series.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The only thing necessary for the triumph of evil is for good  men  to
do nothing.- Edmund Burke
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx: Add support for the SabreSD shipped with i.MX6DL

2013-04-18 Thread Fabio Estevam
Hi Pierre,

On Thu, Apr 18, 2013 at 11:41 AM, Pierre Aubert p.aub...@staubli.com wrote:

 diff --git a/boards.cfg b/boards.cfg
 index f785da8..c002cf7 100644
 --- a/boards.cfg
 +++ b/boards.cfg
 @@ -256,9 +256,10 @@ mx53smd  arm armv7   
 mx53smd freesca
  ima3-mx53arm armv7   ima3-mx53   esg 
mx5
 ima3-mx53:IMX_CONFIG=board/esg/ima3-mx53/imximage.cfg
  vision2  arm armv7   vision2 
 ttcontrol  mx5
 vision2:IMX_CONFIG=board/ttcontrol/vision2/imximage_hynix.cfg
  mx6qarm2 arm armv7   mx6qarm2
 freescale  mx6
 mx6qarm2:IMX_CONFIG=board/freescale/mx6qarm2/imximage.cfg
 -mx6qsabreautoarm armv7   mx6qsabreauto   
 freescale  mx6
 mx6qsabreauto:IMX_CONFIG=board/freescale/mx6qsabreauto/imximage.cfg
 +mx6qsabreautoarm armv7   mx6qsabreauto   
 freescale  mx6
 mx6qsabreauto:IMX_CONFIG=board/freescale/mx6qsabreauto/imximage.cfg,MX6Q

mx6qsabreauto changes should be done on a different patch.

Regards,

Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 0/8] usb: ss: Some fixes and cleanup for USB super-speed support

2013-04-18 Thread Julius Werner
Hi Marek,

I'm sorry, that must have slipped by when I ported the change from my
local fork. Your patch is correct, you just need to add the ctrl-
there.

On Thu, Apr 18, 2013 at 5:43 AM, Marek Vasut ma...@denx.de wrote:
 Dear Vivek Gautam,

 HI Marek,

 On Thu, Apr 18, 2013 at 4:29 PM, Vivek Gautam gautamvivek1...@gmail.com
 wrote:
  On Thu, Apr 18, 2013 at 11:54 AM, Vivek Gautam
 
  gautamvivek1...@gmail.com wrote:
  Hi Marek,
 
  On Sun, Apr 14, 2013 at 11:43 PM, Marek Vasut ma...@denx.de wrote:
  Dear Vivek Gautam,
 
  Based on 'u-boot-usb' master branch.
 
  This patch-series includes majorly some clean-up, few fixes and
  then some basic super-speed usb infrastructure addition, to help
  put support for XHCI in near future.
 
  btw can you test your patches with MAKEALL -a arm? I get this:
 
  - SUMMARY 
  Boards compiled: 306
  Boards with errors: 65 ( qong mx35pdk gplugd at91sam9m10g45ek_nandflash
  pogo_e02 dns325 iconnect lschlv2 lsxhl d2net_v2 inetspace_v2
  net2big_v2 netspace_lite_v2 netspace_max_v2 netspace_v2 wireless_space
  dreamplug guruplug mv88f6281gtw_ge openrd_base openrd_client
  openrd_ultimate rd6281a sheevaplug ib62x0 dockstar tk71 zmx25
  mx23_olinuxino apx4devkit mx23evk m28evk mx28evk sc_sps_1 edminiv2
  mx51_efikamx mx51_efikasb mx51evk mx53loco mx6qsabreauto mx6qsabrelite
  nitrogen6dl nitrogen6dl2g nitrogen6q nitrogen6q2g nitrogen6s
  nitrogen6s1g cm_t35 mt_ventoux omap3_beagle mcx twister omap4_panda
  snow smdk5250 harmony seaboard ventana whistler colibri_t20_iris
  plutux medcom-wide tec paz00 trimslice )
  --
 
  Tried with MAKEALL
  got following result
 
  - SUMMARY 
  Boards compiled: 306
  Boards with errors: 1 ( omap3_evm )
  Boards with warnings but no errors: 17 ( VCMA9 smdk2410 kzm9g balloon3
  h2200 lubbock palmld palmtc polaris pxa255_idp trizepsiv
  vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 xaeniax zipitz2
  colibri_pxa270 )
  --

 I actually checked now just for omap3_evm configuration by trying out:
   make distclean
   make omap3_evm_config
   make

 But strangely i didn't get any build errros for omap3_evm board on
 explicitly compiling for it.
 Any clue ?

  **Without my patches i get following result
 
  - SUMMARY 
  Boards compiled: 306
  Boards with warnings but no errors: 17 ( VCMA9 smdk2410 kzm9g balloon3
  h2200 lubbock palmld palmtc polaris pxa255_idp trizepsiv
  vpac270_nor_128 vpac270_nor_256 vpac270_ond_256 xaeniax zipitz2
  colibri_pxa270 )
  --
 
  There's something to do with Cross Compiler version ??
  btw what environment are you compiling the source with.

 I am using arm-2011.09 cross toolchain.

 I use ELDK 5.3 and Debian 4.7.2-5 to do by builds. But now that I'm looking at
 it, it's this patch that caused it, sorry.

 commit 28b31a5937b89528c40df24dd6c9122578880605
 Author: Julius Werner jwer...@chromium.org
 Date:   Thu Feb 28 18:08:40 2013 +

 usb: Add new command to set USB 2.0 port test modes

 diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
 index 8464850..19d4352 100644
 --- a/drivers/usb/host/ehci-hcd.c
 +++ b/drivers/usb/host/ehci-hcd.c
 @@ -630,7 +630,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long 
 pipe,
 void *buffer,
 printf(The request port(%d) is not configured\n, port - 1);
 return -1;
 }
 -   status_reg = (uint32_t *)hcor-or_portsc[port - 1];
 +   status_reg = (uint32_t *)ctrl-hcor-or_portsc[port - 1];
 srclen = 0;

 debug(req=%u (%#x), type=%u (%#x), value=%u, index=%u\n,

 This change fixes is, right Julius ?

 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] crc32: Correct endianness of crc32 result

2013-04-18 Thread Albert ARIBAUD
Hi Tom,

On Thu, 18 Apr 2013 12:58:54 -0400, Tom Rini tr...@ti.com wrote:

 On Thu, Apr 18, 2013 at 06:39:29PM +0200, Albert ARIBAUD wrote:
  Hi Wolfgang,
  
  On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk w...@denx.de wrote:
  
So how about changing the element type of output in the definition of
hash_func_ws, adapting the corresponding implementations sha1_csum_wd,
sha256_csum_wd and crc32_wd_buf, and adapting the output argument
of the sole call to hash_func_ws, that is, the local u8
output[HASH_MAX_DIGEST_SIZE]; in hash.c? Then we'be done with
alignment.
   
   OK, but that would be a totally different approach (which appears to
   be a good one, here).
  
  Indeed; I would suggest splitting this change in two independent ones:
  
  - fix the endianness issue: change the endianness of crc through the
use of htonl() but leave the existing memcpy() in place as it is,
even though it is not speed-optimized. That's what Simon's patch
does if the HOSTCC part is ignored;
  
  - fix the unalignment issue by changing parameter 'output' of function
type 'hash_func_ws' from u8* to u32* and adjusting the rest of the
code accordingly -- which would lead to replacing the crc32 final
memcpy() with a single indirect assignment.
  
  These two changes could be submitted either separately, or as a series.
 
 Now so that I'm clear, if we don't do anything about the unaligned issue
 today, it's just slow, not an unaligned access that leads to abort,
 right?  So part one today for release, part two next week after release.

Yes, the current code is just slower than it could be, but works, and
so would it with Simon's patch as long as it keeps the memcpy().

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] crc32: Correct endianness of crc32 result

2013-04-18 Thread Simon Glass
Hi,

On Thu, Apr 18, 2013 at 11:43 AM, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
 Hi Tom,

 On Thu, 18 Apr 2013 12:58:54 -0400, Tom Rini tr...@ti.com wrote:

 On Thu, Apr 18, 2013 at 06:39:29PM +0200, Albert ARIBAUD wrote:
  Hi Wolfgang,
 
  On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk w...@denx.de wrote:
 
So how about changing the element type of output in the definition of
hash_func_ws, adapting the corresponding implementations sha1_csum_wd,
sha256_csum_wd and crc32_wd_buf, and adapting the output argument
of the sole call to hash_func_ws, that is, the local u8
output[HASH_MAX_DIGEST_SIZE]; in hash.c? Then we'be done with
alignment.
  
   OK, but that would be a totally different approach (which appears to
   be a good one, here).
 
  Indeed; I would suggest splitting this change in two independent ones:
 
  - fix the endianness issue: change the endianness of crc through the
use of htonl() but leave the existing memcpy() in place as it is,
even though it is not speed-optimized. That's what Simon's patch
does if the HOSTCC part is ignored;
 
  - fix the unalignment issue by changing parameter 'output' of function
type 'hash_func_ws' from u8* to u32* and adjusting the rest of the
code accordingly -- which would lead to replacing the crc32 final
memcpy() with a single indirect assignment.
 
  These two changes could be submitted either separately, or as a series.

 Now so that I'm clear, if we don't do anything about the unaligned issue
 today, it's just slow, not an unaligned access that leads to abort,
 right?  So part one today for release, part two next week after release.

 Yes, the current code is just slower than it could be, but works, and
 so would it with Simon's patch as long as it keeps the memcpy().

Yes the alignment issue is manufactured IMO by the char * used for the
function signature and I did not feel comfortable declaring that it
must be word aligned. To be it seems that the type should be naturally
aligned. What do people think about that?

Anyway, that's why I ended up with this patch, which I felt was small
enough to be accepted as a bug fix for the release.

Albert's email exactly mirrors my thinking on this - and yes I would
be much more comfortable not having to create part 2 for the release.

Please let me know what I should do with this patch for now.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 11/12] arm: add MMU/d-cache support for Faraday cores

2013-04-18 Thread Albert ARIBAUD
Hi Kuo-Jung,

On Thu, 18 Apr 2013 17:25:38 +0800, Kuo-Jung Su dant...@gmail.com
wrote:

 From: Kuo-Jung Su dant...@faraday-tech.com
 
 This patch would enable MMU for Faraday ARMv5TE cores.
 
 Here is the abstract of this MMU design.
 
 Assume SDRAM memory region starts at 0x1000, and its size = 0x80.
 
 0x +---+
|   |
| UN-CACHED |
|   |
|   |
 0x1000 +---+
|  CACHED (SDRAM)   | - It's where data/bss/stack lived.
|   |
|   |
 0x1080 +---+
|   |
|   |
| UN-CACHED |
|   |
|   |
 0xFF80 +---+
| UN-CACHED (SDRAM) | - An un-cached shadow of the SDRAM.
|   |dma_alloc_coherent() always returns
|   |an address in this region.
 0x +---+

The ASCII map is great for explaining, but I find it a bit big for a
commit message. Can you summarize it as lines like

0x-0x0FFF  not cached
0x1000-0x107F  cached (SDRAM)
...

?

 Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
 CC: Albert Aribaud albert.u.b...@aribaud.net
 ---
  arch/arm/include/asm/dma-mapping.h |   56 ++--
  arch/arm/include/asm/global_data.h |4 ++
  arch/arm/include/asm/io.h  |   84 
 +++-
  arch/arm/lib/cache-cp15.c  |   42 ++
  common/cmd_boot.c  |4 ++
  5 files changed, 186 insertions(+), 4 deletions(-)
 
 diff --git a/arch/arm/include/asm/dma-mapping.h 
 b/arch/arm/include/asm/dma-mapping.h
 index 5bbb0a0..53c4edf 100644
 --- a/arch/arm/include/asm/dma-mapping.h
 +++ b/arch/arm/include/asm/dma-mapping.h
 @@ -3,6 +3,9 @@
   * Stelian Pop stel...@popies.net
   * Lead Tech Design www.leadtechdesign.com
   *
 + * (C) Copyright 2010
 + * Dante Su dant...@faraday-tech.com
 + *
   * See file CREDITS for list of people who contributed to this
   * project.
   *
 @@ -24,22 +27,69 @@
  #ifndef __ASM_ARM_DMA_MAPPING_H
  #define __ASM_ARM_DMA_MAPPING_H
 
 +#include asm/u-boot.h
 +#include asm/global_data.h
 +#include asm/io.h
 +#include malloc.h
 +
  enum dma_data_direction {
   DMA_BIDIRECTIONAL   = 0,
   DMA_TO_DEVICE   = 1,
   DMA_FROM_DEVICE = 2,
  };
 
 -static void *dma_alloc_coherent(size_t len, unsigned long *handle)
 +static inline void *dma_alloc_coherent(size_t len, unsigned long *handle)
 +{
 +#if defined(CONFIG_FARADAY)  !defined(CONFIG_SYS_DCACHE_OFF)
 + DECLARE_GLOBAL_DATA_PTR;

I'd rather have the global data ptr be declared outside any function,
and only once.

 +#endif
 + void *va = memalign(ARCH_DMA_MINALIGN, len);
 +
 + if (va  handle)
 + *handle = virt_to_phys(va);
 +
 +#if defined(CONFIG_FARADAY)  !defined(CONFIG_SYS_DCACHE_OFF)
 + if (gd-arch.cpu_mmu) {
 + /* invalidate the buffer, convert to un-cached address */
 + if (va != NULL) {
 + invalidate_dcache_range((ulong)va, (ulong)va + len);
 + va = virt_to_uncached(va);
 + }
 + }
 +#endif
 +
 + return va;
 +}
 +
 +static inline void dma_free_coherent(void *va)
  {
 - *handle = (unsigned long)malloc(len);
 - return (void *)*handle;
 + free(virt_to_cached(va));
  }

If I read this correctly, this code changes the semantics of
dma_alloc_coherent() for boards other than Faraday-based: before,
mempry was simply malloc()ed, now it would be memalign()ed then
virt_to_phys()ed. Why not simply keep the previous implementation under
a #else...#endif block?

  static inline unsigned long dma_map_single(volatile void *vaddr, size_t len,
  enum dma_data_direction dir)
  {
 +#if defined(CONFIG_FARADAY)  !defined(CONFIG_SYS_DCACHE_OFF)
 + DECLARE_GLOBAL_DATA_PTR;
 +
 + if (gd-arch.cpu_mmu) {
 + switch (dir) {
 + case DMA_BIDIRECTIONAL:
 + case DMA_TO_DEVICE:
 + flush_dcache_range((ulong)vaddr,
 + (ulong)vaddr + len);
 + break;
 +
 + case DMA_FROM_DEVICE:
 + invalidate_dcache_range((ulong)vaddr,
 + (ulong)vaddr + len);
 + break;
 + }
 + }
 + return virt_to_phys((void *)vaddr);
 +#else
   return (unsigned long)vaddr;
 +#endif
  }

Here we have such a #else/#endif, which makes sure non-Farady boards
are unaffected.

  static inline void dma_unmap_single(volatile void *vaddr, size_t len,
 diff --git a/arch/arm/include/asm/global_data.h 
 b/arch/arm/include/asm/global_data.h
 index 

Re: [U-Boot] [PATCH v3 0/8] usb: ss: Some fixes and cleanup for USB super-speed support

2013-04-18 Thread Marek Vasut
Hi Julius,

 Hi Marek,
 
 I'm sorry, that must have slipped by when I ported the change from my
 local fork. Your patch is correct, you just need to add the ctrl-
 there.

Well, next time please make sure to compile-test your patches at least before 
you send them.

The stuff is now pushed, Vivek.

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] crc32: Correct endianness of crc32 result

2013-04-18 Thread Tom Rini
On Thu, Apr 18, 2013 at 12:06:47PM -0700, Simon Glass wrote:
 Hi,
 
 On Thu, Apr 18, 2013 at 11:43 AM, Albert ARIBAUD
 albert.u.b...@aribaud.net wrote:
  Hi Tom,
 
  On Thu, 18 Apr 2013 12:58:54 -0400, Tom Rini tr...@ti.com wrote:
 
  On Thu, Apr 18, 2013 at 06:39:29PM +0200, Albert ARIBAUD wrote:
   Hi Wolfgang,
  
   On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk w...@denx.de wrote:
  
 So how about changing the element type of output in the definition of
 hash_func_ws, adapting the corresponding implementations 
 sha1_csum_wd,
 sha256_csum_wd and crc32_wd_buf, and adapting the output argument
 of the sole call to hash_func_ws, that is, the local u8
 output[HASH_MAX_DIGEST_SIZE]; in hash.c? Then we'be done with
 alignment.
   
OK, but that would be a totally different approach (which appears to
be a good one, here).
  
   Indeed; I would suggest splitting this change in two independent ones:
  
   - fix the endianness issue: change the endianness of crc through the
 use of htonl() but leave the existing memcpy() in place as it is,
 even though it is not speed-optimized. That's what Simon's patch
 does if the HOSTCC part is ignored;
  
   - fix the unalignment issue by changing parameter 'output' of function
 type 'hash_func_ws' from u8* to u32* and adjusting the rest of the
 code accordingly -- which would lead to replacing the crc32 final
 memcpy() with a single indirect assignment.
  
   These two changes could be submitted either separately, or as a series.
 
  Now so that I'm clear, if we don't do anything about the unaligned issue
  today, it's just slow, not an unaligned access that leads to abort,
  right?  So part one today for release, part two next week after release.
 
  Yes, the current code is just slower than it could be, but works, and
  so would it with Simon's patch as long as it keeps the memcpy().
 
 Yes the alignment issue is manufactured IMO by the char * used for the
 function signature and I did not feel comfortable declaring that it
 must be word aligned. To be it seems that the type should be naturally
 aligned. What do people think about that?
 
 Anyway, that's why I ended up with this patch, which I felt was small
 enough to be accepted as a bug fix for the release.
 
 Albert's email exactly mirrors my thinking on this - and yes I would
 be much more comfortable not having to create part 2 for the release.
 
 Please let me know what I should do with this patch for now.

Lets follow the outline Albert made above, two patches, #2 depends on #1
and #1 is now, #2 is next week.

-- 
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/5] consolidate hang()

2013-04-18 Thread Wolfgang Denk
Dear Andreas,

In message 1366196568-23008-1-git-send-email-andreas.de...@googlemail.com you 
wrote:

 Andreas Bießmann (5):
   microblaze: fix style in board.c
   nios2: fix style in board.c.
   mx31pdk: add CONFIG_SPL_LIBGENERIC_SUPPORT
   tx25: add CONFIG_SPL_LIBGENERIC_SUPPORT
   lib: consolidate hang()

Compile-tested for Power architecture.  No new warnings / errors
found.

Tested-by: Wolfgang Denk w...@denx.de
Acked-by: Wolfgang Denk w...@denx.de

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I have the simplest tastes.  I am always satisfied with the best.
   -- Oscar Wilde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 07/12] mtd: nand: add Faraday FTNANDC021 NAND controller support

2013-04-18 Thread Scott Wood

On 04/18/2013 04:25:34 AM, Kuo-Jung Su wrote:
diff --git a/drivers/mtd/nand/ftnandc021.c  
b/drivers/mtd/nand/ftnandc021.c

new file mode 100644
index 000..58863dc
--- /dev/null
+++ b/drivers/mtd/nand/ftnandc021.c
@@ -0,0 +1,544 @@
+/*
+ * Faraday NAND Flash Controller
+ *
+ * (C) Copyright 2010 Faraday Technology
+ * Dante Su dant...@faraday-tech.com
+ *
+ * This file is released under the terms of GPL v2 and any later  
version.
+ * See the file COPYING in the root directory of the source tree for  
details.

+ */
+
+#include common.h
+#include asm/io.h
+#include asm/unaligned.h
+#include nand.h
+#include malloc.h
+
+#include ftnandc021.h
+
+/* common bitmask of nand flash status register */
+#define NAND_IOSTATUS_ERRORBIT_MASK(0)
+#define NAND_IOSTATUS_READYBIT_MASK(6)
+#define NAND_IOSTATUS_UNPROTCT BIT_MASK(7)
+
+struct ftnandc021_chip {
+   void*iobase;


struct ftnandc021_regs __iomem *iobase;


+   uint32_t cmd;
+
+   uint32_t pgidx;
+
+   uint32_t off;
+   uint8_t  buf[256];
+
+   uint32_t adrc;  /* address cycle */
+   uint32_t pgsz;  /* page size */
+   uint32_t bksz;  /* block size */
+};
+
+/* Register access macros */
+#define NAND_READ(r)   le32_to_cpu(readl(r))
+#define NAND_WRITE(v, r)   writel(cpu_to_le32(v), r)
+#define NAND_SETBITS(m, r) setbits_le32(r, m)
+#define NAND_CLRBITS(m, r) clrbits_le32(r, m)


Do we really need these wrappers?  At least use inline functions (with  
lowercase names) rather than ALLCAPS MACROS, but I don't see the point  
once you get rid of the byteswapping, which is broken.  readl() reads a  
little-endian register and returns a CPU-ordered value, and then you  
pass that CPU ordered value to a function that wants to take a little  
endian value and swap it again.  Likewise with writel, in reverse.



+static struct nand_ecclayout ftnandc021_oob_2k = {
+   .eccbytes = 24,
+   .eccpos = {
+   40, 41, 42, 43, 44, 45, 46, 47,
+   48, 49, 50, 51, 52, 53, 54, 55,
+   56, 57, 58, 59, 60, 61, 62, 63
+   },
+   .oobfree = {
+   {
+   .offset = 9,
+   .length = 3
+   }
+   }
+};


This layout doesn't seem to match what the code does.  The code says
there is no ECC, and only writes to specific fixed bytes of the OOB
(which doesn't match 3 bytes at offset 9).


+static int
+ftnandc021_reset(struct nand_chip *chip)


We don't generally do the function name starts in column 0 thing in  
U-Boot.



+{
+   struct ftnandc021_chip *priv = chip-priv;
+   struct ftnandc021_regs *regs = priv-iobase;


struct ftnandc021_regs __iomem *regs

Here and elsewhere, for sparse checking.


+   uint32_t bk = 2;/* 64 pages */
+   uint32_t pg = 1;/* 2k */
+   uint32_t ac = 2;/* 5 */


When do you actually use these default values, other than when one of  
the

switch statements fail to match -- which seems like it would be an error
condition; even if you don't explicitly check for the error it doesn't
seem good to paper over it by providing common values that might work.


+#ifdef CONFIG_FTNANDC021_ACTIMING_1
+   NAND_WRITE(CONFIG_FTNANDC021_ACTIMING_1, regs-atr[0]);
+#endif
+#ifdef CONFIG_FTNANDC021_ACTIMING_2
+   NAND_WRITE(CONFIG_FTNANDC021_ACTIMING_2, regs-atr[1]);
+#endif


Use CONFIG_SYS_ for things which describe hardware rather than user  
preference.  Document all CONFIG symbols (including CONFIG_SYS symbols)  
in the README.



+   NAND_WRITE(0, regs-ier);
+   NAND_WRITE(0, regs-pir);
+   NAND_WRITE(0xff, regs-bbiwr);
+   NAND_WRITE(0x, regs-lsnwr);
+   NAND_WRITE(0x, regs-crcwr);
+
+   if (chip-options  NAND_BUSWIDTH_16)
+		NAND_WRITE(FCR_SWCRC | FCR_IGNCRC | FCR_16BIT,  
regs-fcr);

+   else
+   NAND_WRITE(FCR_SWCRC | FCR_IGNCRC, regs-fcr);
+
+   /* chip reset */
+   NAND_WRITE(SRR_CHIP_RESET, regs-srr);
+
+   /* wait until chip ready */
+   while (NAND_READ(regs-srr)  SRR_CHIP_RESET)
+   ;


Timeout?


+   switch (priv-adrc) {
+   case 3:
+   ac = 0;
+   break;
+   case 4:
+   ac = 1;
+   break;
+   case 5:
+   ac = 2;
+   break;
+   }


ac = priv-adrc - 3;


+static inline int
+ftnandc021_ckst(struct ftnandc021_chip *priv)
+{
+   struct ftnandc021_regs *regs = priv-iobase;
+   uint32_t st = NAND_READ(regs-idr[1]);
+
+   if (st  NAND_IOSTATUS_ERROR)
+   return -NAND_IOSTATUS_ERROR;
+
+   if (!(st  NAND_IOSTATUS_READY))
+   return -NAND_IOSTATUS_READY;
+
+   if (!(st  NAND_IOSTATUS_UNPROTCT))
+   return -NAND_IOSTATUS_UNPROTCT;
+
+   return 0;
+}


Why the negation of NAND_IOSTATUS_*?  These aren't standard error
codes...  you don't even use the return value at all that I see, other
than 

Re: [U-Boot] Pull request: u-boot-arm/master

2013-04-18 Thread Tom Rini
On Wed, Apr 17, 2013 at 06:37:06PM +0200, Albert ARIBAUD wrote:

 Hi Tom,
 
 The following changes since commit
 c4a4e2e20ca226948b62ed116df98f7a3932f2ac:
 
   ARMv7: start.S: stay in HYP mode if u-boot is entered in it
   (2013-04-15 18:30:59 +0200)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-arm master
 
 for you to fetch changes up to f2e8a87305a55652488af140adcf65b1e688f287:
 
   exynos: fdt: Add TMU node for snow (2013-04-17 10:00:44 +0900)
 
 Note: there is a trivial merge conflict for
 include/configs/exynos5250-dt.h:
 
 ++ HEAD
  +/* USB boot mode */
  +#define EXYNOS_COPY_USB_FNPTR_ADDR0x02020070
  +#define EXYNOS_USB_SECONDARY_BOOT 0xfeed0002
  +#define EXYNOS_IRAM_SECONDARY_BASE0x02020018
 ++===
 + /* TPM */
 + #define CONFIG_TPM
 + #define CONFIG_CMD_TPM
 + #define CONFIG_INFINEON_TPM_I2C
 + #define CONFIG_INFINEON_TPM_I2C_BUS 3
 + #define CONFIG_INFINEON_TPM_I2C_ADDR 0x20
 ++ u-boot/master
 
 
 Simon Glass (2):
   exynos: Correct use of 64-bit division
   exynos: fdt: Add TMU node for snow
 
 Stephen Warren (1):
   ARM: tegra: support T33 SKU of Tegra30
 
 Thierry Reding (4):
   Tegra: All Tamonten-derived boards use onboard NAND
   Tegra: Medcom-Wide: Enable NAND and boot script support
   Tegra: Plutux: Enable NAND and boot script support
   Tegra: TEC: Enable boot script support
 
 Tom Warren (7):
   Tegra: enable verify support for the crc32 command
   Tegra: Restore cp15 VBAR _start vector write for ARMv7
   Tegra: Configure L2 cache control reg properly.
   Tegra114: Initialize System Counter (TSC) with osc frequency
   Tegra: Fix MSELECT clock divisors for T30/T114.
   Tegra: Split tegra_get_chip_type() into soc  sku funcs
   Tegra: T30: Beaver board support.
 
 Vivek Gautam (1):
   Exynos5: Add support for USB download boot mode
 
  MAINTAINERS|1 +
  arch/arm/cpu/arm720t/tegra-common/cpu.c|   48 ---
  arch/arm/cpu/arm720t/tegra-common/cpu.h|4 +-
  arch/arm/cpu/arm720t/tegra114/cpu.c|   10 ++--
  arch/arm/cpu/arm720t/tegra30/cpu.c |4 +-
  arch/arm/cpu/armv7/s5p-common/timer.c  |7 ++-
  arch/arm/cpu/armv7/start.S |2 -
  arch/arm/cpu/tegra-common/Makefile |2 +-
  arch/arm/cpu/tegra-common/ap.c |   53 +++--
  arch/arm/cpu/tegra-common/cache.c  |   48 +++
  arch/arm/cpu/tegra-common/clock.c  |3 +
  arch/arm/cpu/tegra114-common/clock.c   |   22 +++
  arch/arm/cpu/tegra20-common/clock.c|4 ++
  arch/arm/cpu/tegra20-common/pmu.c  |4 +-
  arch/arm/cpu/tegra30-common/clock.c|4 ++
  arch/arm/include/asm/arch-tegra/ap.h   |   21 ++-
  arch/arm/include/asm/arch-tegra/clock.h|3 +
  arch/arm/include/asm/arch-tegra/tegra.h|1 +
  arch/arm/include/asm/arch-tegra114/sysctr.h|   35 +++
  arch/arm/include/asm/arch-tegra114/tegra.h |1 +
  board/avionic-design/dts/tegra20-tamonten.dtsi |   11 
  board/avionic-design/dts/tegra20-tec.dts   |   11 
  board/nvidia/common/emc.c  |2 +-
  board/nvidia/dts/tegra30-beaver.dts|   71
  ++ board/samsung/dts/exynos5250-snow.dts
  |   14 + board/samsung/smdk5250/spl_boot.c  |   40
  - boards.cfg |1 +
  include/configs/beaver.h   |   76
  
  include/configs/exynos5250-dt.h|5 ++
  include/configs/medcom-wide.h  |   21 ---
  include/configs/plutux.h   |   18 +++---
  include/configs/tec.h  |   10 +---
  include/configs/tegra-common.h |2 + 33 files
  changed, 467 insertions(+), 92 deletions(-) create mode 100644
  arch/arm/cpu/tegra-common/cache.c create mode 100644
  arch/arm/include/asm/arch-tegra114/sysctr.h create mode 100644
  board/nvidia/dts/tegra30-beaver.dts create mode 100644
  include/configs/beaver.h

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] patman: fix gitutil for decorations

2013-04-18 Thread Tom Rini
On Tue, Apr 16, 2013 at 03:12:40PM -0700, Simon Glass wrote:

 +Tom
 
 On Tue, Apr 16, 2013 at 8:48 AM, Simon Glass s...@chromium.org wrote:
  On Tue, Apr 16, 2013 at 2:52 AM, Andreas Bie?mann
  andreas.de...@googlemail.com wrote:
  The git config parameter log.decorate is quite useful when working with 
  git.
  Patman, however can not handle the decorated output when parsing the 
  commit.
  To prevent this use the '--no-decorate' switch for git-log.
 
  Signed-off-by: Andreas Bie?mann andreas.de...@googlemail.com
 
  Thanks.
 
  Acked-by: Simon Glass s...@chromium.org
 
 Tom can you please pick this fix up also? It could cause people some problems.

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2] crc32: Correct endianness of crc32 result

2013-04-18 Thread Simon Glass
When crc32 is handled by the hash library, it requires the data to be in
big-endian format, since it reads it byte-wise. Thus at present the 'crc32'
command reports incorrect data. For example, previously we might see:

Peach # crc32 4000 100
CRC32 for 4000 ... 40ff == 0d968558

but instead with the hash library we see:

Peach # crc32 4000 100
CRC32 for 4000 ... 40ff == 5885960d

Correct this.

Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Vadim Bendebury vben...@google.com
---
Changes in v2:
- Remove use of put_unaligned_be32()
- Use htonl() instead of htobe32()

 lib/crc32.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/crc32.c b/lib/crc32.c
index 76205da..9759212 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -8,7 +8,9 @@
  * For conditions of distribution and use, see copyright notice in zlib.h
  */
 
-#ifndef USE_HOSTCC
+#ifdef USE_HOSTCC
+#include arpa/inet.h
+#else
 #include common.h
 #endif
 #include compiler.h
@@ -256,5 +258,6 @@ void crc32_wd_buf(const unsigned char *input, unsigned int 
ilen,
uint32_t crc;
 
crc = crc32_wd(0, input, ilen, chunk_sz);
+   crc = htonl(crc);
memcpy(output, crc, sizeof(crc));
 }
-- 
1.8.2.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] uboot newbie question on booting ep405 board

2013-04-18 Thread David Li
Hi Wolfgang or others:

I am trying to build a new uboot image version 2013.01.01 in
buildroot. The buildroot make menuconfig asks for uboot board
name. I tried to give it EP405 but this failed the build as it
wasn't able to find such a configuration. How can I find out about the
right name for the board used by buildroot? I think my board is just a
generic ppc board and should have been supported long ago.

Thanks.

David


On Mon, Apr 15, 2013 at 10:55 AM, David Li w.david...@gmail.com wrote:
 Hi Wolfgang,

 Thanks for the suggestions. I think I will try to upgrade the u-boot
 to the latest version. buildroot can also build u-boot image. I 'll
 look into it.

 David


 On Sun, Apr 14, 2013 at 10:51 PM, Wolfgang Denk w...@denx.de wrote:
 Dear David Li,

 In message 
 CAADET=ejpeckxwsohp5+d7pijbbhgk1xumgtaadka-trrvr...@mail.gmail.com you 
 wrote:

 I am new to using uBoot and learning with a EP405 board.

 Which exact board is this?

 Basically I built the Linux uImage and device tree blob for EP 405.
 Both were downloaded on to RAM  - uImage at memory 0x20 and
 ep405.dtb at 0x400.

 Note that these addresses are way too low in any case.

 When I used bootm to boot the
 kernel, I always get Bad Magic Number like this:


 = bootm 0x200 - 0x400
 ## Booting image at 0200 ...
Image Name:   Linux-3.7.8
Image Type:   PowerPC Linux Kernel Image (gzip compressed)
Data Size:2571848 Bytes =  2.5 MB

 Even your compressed kernel is bigger than the 2 MB where you load it;
 when uncompressing, it will overwrite both the tail of the UImage
 itself, and the DTB.

 ## Loading RAMDisk Image at  ...
 Bad Magic Number

 Did you now wonder why it's talking about a ramdisk here?  You did not
 pass a ramdisk address (at least you did not mean to).

 U-Boot 1.2.0-gd35b508a-dirty (Sep 19 2007 - 14:13:23)

 What's wrong? Why it's loading ramdisk at 000? I built the kernel
 and initramfs together in the uImage.

 Your U-Boot is more than 6 years old; that is not only stone age, but
 even long before the introduction of device tree support.  You cannot
 use this ancient U-Boot version to boot a recent LInux kernel with
 device tree support.

 PLease update to a recent U-Boot version, or stick with Linux kernel
 versions of similar age, i. e. something like v2.6.19 or v.2.6.20
 (yes, this is old crap, but so is your version of U-Boot).

 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 We, the unwilling, led by the unknowing, are doing the impossible for
 the ungrateful. We have done so much, for so long, with so little, we
 are now qualified to do anything with nothing.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] mx51evk: Update environmet in order to allow booting a dt kernel

2013-04-18 Thread Fabio Estevam
From: Fabio Estevam fabio.este...@freescale.com

Update the environment as done in other imx boards to allow easy switching 
between booting a non-dt kernel and a dt kernel.

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 include/configs/mx51evk.h |   49 +
 1 file changed, 41 insertions(+), 8 deletions(-)

diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index cb3d938..594ff4b 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -149,32 +149,65 @@
 
 #define CONFIG_ETHPRIMEFEC0
 
-#define CONFIG_LOADADDR0x9080  /* loadaddr env var */
+#define CONFIG_LOADADDR0x9200  /* loadaddr env var */
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
script=boot.scr\0 \
uimage=uImage\0 \
+   fdt_file=imx51-babbage.dtb\0 \
+   fdt_addr=0x9100\0 \
+   boot_fdt=try\0 \
+   ip_dyn=yes\0 \
mmcdev=0\0 \
mmcpart=2\0 \
-   mmcroot=/dev/mmcblk0p3 rw\0 \
-   mmcrootfstype=ext3 rootwait\0 \
-   mmcargs=setenv bootargs console=ttymxc0,${baudrate}  \
-   root=${mmcroot}  \
-   rootfstype=${mmcrootfstype}\0 \
+   mmcroot=/dev/mmcblk0p3 rw rootwait\0 \
+   mmcargs=setenv bootargs console=ttymxc0,${baudrate} root=${mmcroot}\0\
loadbootscript= \
fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
bootscript=echo Running bootscript from mmc ...;  \
source\0 \
loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0 \
+   loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0 \
mmcboot=echo Booting from mmc ...;  \
run mmcargs;  \
-   bootm\0 \
+   if test ${boot_fdt} = yes || test ${boot_fdt} = try; then  \
+   if run loadfdt; then  \
+   bootm ${loadaddr} - ${fdt_addr};  \
+   else  \
+   if test ${boot_fdt} = try; then  \
+   bootm;  \
+   else  \
+   echo WARN: Cannot load the DT;  \
+   fi;  \
+   fi;  \
+   else  \
+   bootm;  \
+   fi;\0 \
netargs=setenv bootargs console=ttymxc0,${baudrate}  \
root=/dev/nfs  \
ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0 \
netboot=echo Booting from net ...;  \
run netargs;  \
-   dhcp ${uimage}; bootm\0 \
+   if test ${ip_dyn} = yes; then  \
+   setenv get_cmd dhcp;  \
+   else  \
+   setenv get_cmd tftp;  \
+   fi;  \
+   ${get_cmd} ${uimage};  \
+   if test ${boot_fdt} = yes ||  test ${boot_fdt} = try; then  \
+   if ${get_cmd} ${fdt_addr} ${fdt_file}; then  \
+   bootm ${loadaddr} - ${fdt_addr};  \
+   else  \
+   if test ${boot_fdt} = try; then  \
+   bootm;  \
+   else  \
+   echo ERROR: Cannot load the DT;  \
+   exit;  \
+   fi;  \
+   fi;  \
+   else  \
+   bootm;  \
+   fi;\0
 
 #define CONFIG_BOOTCOMMAND \
mmc dev ${mmcdev}; if mmc rescan; then  \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3 V5] EXYNOS5: Add gpio pin numbering feature

2013-04-18 Thread Minkyu Kang
Dear Rajeshwari,

On 17/04/13 13:49, Rajeshwari Birje wrote:
 Hi Minkyu Kang,
 
 Please do let me know if any comments on these patchset.
 

will progress after release.

 Regards,
 Rajeshwari Shinde
 

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] powerpc/BSC9132: Add IFC bank count

2013-04-18 Thread York Sun
BSC9132 has 3 IFC banks.

Signed-off-by: York Sun york...@freescale.com
---
 arch/powerpc/include/asm/config_mpc85xx.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index 72016d4..96a8d3d 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -520,6 +520,7 @@
 #define CONFIG_TSECV2
 #define CONFIG_SYS_FSL_SEC_COMPAT  4
 #define CONFIG_NUM_DDR_CONTROLLERS 2
+#define CONFIG_SYS_FSL_IFC_BANK_COUNT  3
 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
 #define CONFIG_NAND_FSL_IFC
 #define CONFIG_SYS_FSL_ERRATUM_IFC_A003399
-- 
1.7.9.5


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] uboot newbie question on booting ep405 board

2013-04-18 Thread Stefan Roese
Hi David,

On 19.04.2013 01:24, David Li wrote:
 I am trying to build a new uboot image version 2013.01.01 in
 buildroot. The buildroot make menuconfig asks for uboot board
 name. I tried to give it EP405 but this failed the build as it
 wasn't able to find such a configuration. How can I find out about the
 right name for the board used by buildroot? I think my board is just a
 generic ppc board and should have been supported long ago.

IIRC, then the EP405 board was has never been supported in mainline
U-Boot. From the Linux kernel (which seem to support it) I can see that
it is the Embedded Planet EP405 board. Is this correct?

I think you have 2 options:

a) Get the U-Boot sources from the board vendor and modify/port it to
the latest version.

b) Port U-Boot to the EP405 from scratch using some other 405 boards as
reference. That should no be that hard.

Hope this helps.

Thanks,
Stefan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 3/6] arm: imx: Fix u-boot-with-nand-spl.imx target

2013-04-18 Thread Marek Vasut
This target is currently concatenating u-boot SPL in imximage format
with u-boot.bin. The NAND SPL can load a raw binary, but the preffered
format with much less limitations is uImage format. Fix the target
so u-boot.bin is first converted into uImage format and only after
that is concatenated.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Scott Wood scottw...@freescale.com
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
---
 arch/arm/imx-common/Makefile | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
index 44b6822..ba31d3e 100644
--- a/arch/arm/imx-common/Makefile
+++ b/arch/arm/imx-common/Makefile
@@ -69,8 +69,11 @@ $(OBJTREE)/u-boot-with-nand-spl.imx: $(OBJTREE)/SPL 
$(OBJTREE)/u-boot.bin
-I binary -O binary $(OBJTREE)/spl/u-boot-nand-spl.imx \
$(OBJTREE)/spl/u-boot-nand-spl-pad.imx
rm $(OBJTREE)/spl/u-boot-nand-spl.imx
-   cat $(OBJTREE)/spl/u-boot-nand-spl-pad.imx $(OBJTREE)/u-boot.bin  $@
-   rm $(OBJTREE)/spl/u-boot-nand-spl-pad.imx
+   $(OBJTREE)/tools/mkimage -A arm -O U-Boot -a $(CONFIG_SYS_TEXT_BASE) \
+   -e $(CONFIG_SYS_TEXT_BASE) -C none -d $(OBJTREE)/u-boot.bin \
+   $(OBJTREE)/u-boot.uim
+   cat $(OBJTREE)/spl/u-boot-nand-spl-pad.imx $(OBJTREE)/u-boot.uim  $@
+   rm $(OBJTREE)/spl/u-boot-nand-spl-pad.imx $(OBJTREE)/u-boot.uim
 
 
 #
-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 2/6] nand: Add SPL_NAND support to mxc_nand_spl

2013-04-18 Thread Marek Vasut
Add support for generic NAND SPL via the SPL framework into the
mxc_nand_spl driver. This is basically just a simple rename and
publication of the already implemented functions. To avoid the
old function which are used with the nand_spl/ stuff getting in
the way of NAND SPL framework, the macro CONFIG_SPL_NAND_LEGACY
was introduced and two remaining legacy boards were adjusted.
These board need to be either fixed or removed in the long run,
but I don't have either.

Also make sure the requested payload is aligned to full pages,
otherwise this simple driver fails to load the last page.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Scott Wood scottw...@freescale.com
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
---
 drivers/mtd/nand/mxc_nand_spl.c | 13 ++---
 include/configs/mx31pdk.h   |  1 +
 include/configs/tx25.h  |  1 +
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/mxc_nand_spl.c b/drivers/mtd/nand/mxc_nand_spl.c
index 09f23c3..8ff03c9 100644
--- a/drivers/mtd/nand/mxc_nand_spl.c
+++ b/drivers/mtd/nand/mxc_nand_spl.c
@@ -290,7 +290,7 @@ static int is_badblock(int pagenumber)
return 0;
 }
 
-static int nand_load(unsigned int from, unsigned int size, unsigned char *buf)
+int nand_spl_load_image(uint32_t from, unsigned int size, void *buf)
 {
int i;
unsigned int page;
@@ -303,6 +303,7 @@ static int nand_load(unsigned int from, unsigned int size, 
unsigned char *buf)
page = from / CONFIG_SYS_NAND_PAGE_SIZE;
i = 0;
 
+   size = roundup(size, CONFIG_SYS_NAND_PAGE_SIZE);
while (i  size / CONFIG_SYS_NAND_PAGE_SIZE) {
if (nfc_read_page(page, buf)  0)
return -1;
@@ -332,6 +333,7 @@ static int nand_load(unsigned int from, unsigned int size, 
unsigned char *buf)
return 0;
 }
 
+#ifdef CONFIG_SPL_NAND_SUPPORT_LEGACY
 /*
  * The main entry for NAND booting. It's necessary that SDRAM is already
  * configured and available since this code loads the main U-Boot image
@@ -345,8 +347,9 @@ void nand_boot(void)
 * CONFIG_SYS_NAND_U_BOOT_OFFS and CONFIG_SYS_NAND_U_BOOT_SIZE must
 * be aligned to full pages
 */
-   if (!nand_load(CONFIG_SYS_NAND_U_BOOT_OFFS, CONFIG_SYS_NAND_U_BOOT_SIZE,
-  (uchar *)CONFIG_SYS_NAND_U_BOOT_DST)) {
+   if (!nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+   CONFIG_SYS_NAND_U_BOOT_SIZE,
+   (uchar *)CONFIG_SYS_NAND_U_BOOT_DST)) {
/* Copy from NAND successful, start U-boot */
uboot = (void *)CONFIG_SYS_NAND_U_BOOT_START;
uboot();
@@ -364,3 +367,7 @@ void hang(void)
/* Loop forever */
while (1) ;
 }
+#endif
+
+void nand_init(void) {}
+void nand_deselect(void) {}
diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
index 1754595..217552e 100644
--- a/include/configs/mx31pdk.h
+++ b/include/configs/mx31pdk.h
@@ -50,6 +50,7 @@
 #define CONFIG_SPL_LDSCRIPTarch/$(ARCH)/cpu/u-boot-spl.lds
 #define CONFIG_SPL_MAX_SIZE2048
 #define CONFIG_SPL_NAND_SUPPORT
+#define CONFIG_SPL_NAND_SUPPORT_LEGACY
 
 #define CONFIG_SPL_TEXT_BASE   0x87dc
 #define CONFIG_SYS_TEXT_BASE   0x87e0
diff --git a/include/configs/tx25.h b/include/configs/tx25.h
index e72f8f6..7c362d0 100644
--- a/include/configs/tx25.h
+++ b/include/configs/tx25.h
@@ -37,6 +37,7 @@
 #define CONFIG_SPL_LDSCRIPTarch/$(ARCH)/cpu/u-boot-spl.lds
 #define CONFIG_SPL_MAX_SIZE2048
 #define CONFIG_SPL_NAND_SUPPORT
+#define CONFIG_SPL_NAND_SUPPORT_LEGACY
 
 #define CONFIG_SPL_TEXT_BASE   0x810c
 #define CONFIG_SYS_TEXT_BASE   0x8120
-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 5/6] arm: mx5: Add NAND clock handling

2013-04-18 Thread Marek Vasut
Augment the MX5 clock code with function to enable and configure
NFC clock. This is necessary to get NFC working on MX5.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Scott Wood scottw...@freescale.com
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
---
 arch/arm/cpu/armv7/mx5/clock.c| 14 --
 arch/arm/include/asm/arch-mx5/clock.h |  1 +
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx5/clock.c b/arch/arm/cpu/armv7/mx5/clock.c
index 76c2c52..431756e 100644
--- a/arch/arm/cpu/armv7/mx5/clock.c
+++ b/arch/arm/cpu/armv7/mx5/clock.c
@@ -739,10 +739,11 @@ static int config_core_clk(u32 ref, u32 freq)
 static int config_nfc_clk(u32 nfc_clk)
 {
u32 parent_rate = get_emi_slow_clk();
-   u32 div = parent_rate / nfc_clk;
+   u32 div;
 
-   if (nfc_clk = 0)
+   if (nfc_clk == 0)
return -EINVAL;
+   div = parent_rate / nfc_clk;
if (div == 0)
div++;
if (parent_rate / div  NFC_CLK_MAX)
@@ -755,6 +756,15 @@ static int config_nfc_clk(u32 nfc_clk)
return 0;
 }
 
+void enable_nfc_clk(unsigned char enable)
+{
+   unsigned int cg = enable ? MXC_CCM_CCGR_CG_ON : MXC_CCM_CCGR_CG_OFF;
+
+   clrsetbits_le32(mxc_ccm-CCGR5,
+   MXC_CCM_CCGR5_EMI_ENFC(MXC_CCM_CCGR_CG_MASK),
+   MXC_CCM_CCGR5_EMI_ENFC(cg));
+}
+
 /* Config main_bus_clock for periphs */
 static int config_periph_clk(u32 ref, u32 freq)
 {
diff --git a/arch/arm/include/asm/arch-mx5/clock.h 
b/arch/arm/include/asm/arch-mx5/clock.h
index 9cdfb48..6910192 100644
--- a/arch/arm/include/asm/arch-mx5/clock.h
+++ b/arch/arm/include/asm/arch-mx5/clock.h
@@ -68,5 +68,6 @@ void set_usboh3_clk(void);
 void enable_usboh3_clk(unsigned char enable);
 void mxc_set_sata_internal_clock(void);
 int enable_i2c_clk(unsigned char enable, unsigned i2c_num);
+void enable_nfc_clk(unsigned char enable);
 
 #endif /* __ASM_ARCH_CLOCK_H */
-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 6/6] arm: mx5: Add support for DENX M53EVK

2013-04-18 Thread Marek Vasut
Add basic support for the DENX M53EVK board. Currently supported is
the MMC, Ethernet, I2C.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Scott Wood scottw...@freescale.com
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Wolfgang Denk w...@denx.de
---
 MAINTAINERS|   1 +
 board/denx/m53evk/Makefile |  40 
 board/denx/m53evk/imximage.cfg | 108 +++
 board/denx/m53evk/m53evk.c | 410 +
 boards.cfg |   1 +
 include/configs/m53evk.h   | 252 +
 6 files changed, 812 insertions(+)
 create mode 100644 board/denx/m53evk/Makefile
 create mode 100644 board/denx/m53evk/imximage.cfg
 create mode 100644 board/denx/m53evk/m53evk.c
 create mode 100644 include/configs/m53evk.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 643a5ac..e109be6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -954,6 +954,7 @@ Marek Vasut marek.va...@gmail.com
mx23_olinuxino  i.MX23
m28evk  i.MX28
sc_sps_1i.MX28
+   m53evk  i.MX53
 
 Hugo Villeneuve hugo.villene...@lyrtech.com
 
diff --git a/board/denx/m53evk/Makefile b/board/denx/m53evk/Makefile
new file mode 100644
index 000..bfb040a
--- /dev/null
+++ b/board/denx/m53evk/Makefile
@@ -0,0 +1,40 @@
+#
+# DENX M53EVK
+# Copyright (C) 2012-2013 Marek Vasut ma...@denx.de
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := m53evk.o
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/denx/m53evk/imximage.cfg b/board/denx/m53evk/imximage.cfg
new file mode 100644
index 000..3d60de0
--- /dev/null
+++ b/board/denx/m53evk/imximage.cfg
@@ -0,0 +1,108 @@
+/*
+ * DENX M53 DRAM init values
+ * Copyright (C) 2012-2013 Marek Vasut ma...@denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not write to the Free Software
+ * Foundation Inc. 51 Franklin Street Fifth Floor Boston,
+ * MA 02110-1301 USA
+ *
+ * Refer docs/README.imxmage for more details about how-to configure
+ * and create imximage boot image
+ *
+ * The syntax is taken as close as possible with the kwbimage
+ */
+/* image version */
+IMAGE_VERSION  2
+
+/*
+ * Boot Device : one of
+ * spi, sd, nand
+ */
+BOOT_FROM  nand
+
+/*
+ * Device Configuration Data (DCD)
+ *
+ * Each entry must have the format:
+ * Addr-type   AddressValue
+ *
+ * where:
+ * Addr-type register length (1,2 or 4 bytes)
+ * Address   absolute address of the register
+ * value value to be stored in the register
+ */
+DATA 4 0x53fa86f4 0x/* GRP_DDRMODE_CTL */
+DATA 4 0x53fa8714 0x/* GRP_DDRMODE */
+DATA 4 0x53fa86fc 0x/* GRP_DDRPKE */
+DATA 4 0x53fa8724 0x0400/* GRP_DDR_TYPE */
+
+DATA 4 0x53fa872c 0x0030/* GRP_B3DS */
+DATA 4 0x53fa8554 0x0030/* DRAM_DQM3 */
+DATA 4 0x53fa8558 0x00300040/* DRAM_SDQS3 */
+
+DATA 4 0x53fa8728 0x0030/* GRP_B2DS */
+DATA 4 0x53fa8560 0x0030/* DRAM_DQM2 */
+DATA 4 0x53fa8568 0x00300040/* DRAM_SDQS2 */
+
+DATA 4 0x53fa871c 0x0030/* GRP_B1DS */
+DATA 4 0x53fa8594 

[U-Boot] [PATCH 1/6] imx: Align the imximage header and payload to multiples of 4k

2013-04-18 Thread Marek Vasut
The MX53 ROM loads the data from NAND in multiples of pages and
supports maximum page size of 4k. Thus, align the image and header
to 4k to be safe from ROM bugs.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Scott Wood scottw...@freescale.com
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
---
 tools/imximage.c | 11 +++
 tools/imximage.h |  3 ++-
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/tools/imximage.c b/tools/imximage.c
index fa308c9..c018562 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -518,11 +518,14 @@ static void imximage_set_header(void *ptr, struct stat 
*sbuf, int ifd,
 
/*
 * ROM bug alert
-* mx53 only loads 512 byte multiples.
-* The remaining fraction of a block bytes would
-* not be loaded.
+*
+* MX53 only loads 512 byte multiples in case of SD boot.
+* MX53 only loads NAND page multiples in case of NAND boot and
+* supports up to 4096 byte large pages, thus align to 4096.
+*
+* The remaining fraction of a block bytes would not be loaded!
 */
-   *header_size_ptr = ROUND(sbuf-st_size + imxhdr-flash_offset, 512);
+   *header_size_ptr = ROUND(sbuf-st_size + imxhdr-flash_offset, 4096);
 }
 
 int imximage_check_params(struct mkimage_params *params)
diff --git a/tools/imximage.h b/tools/imximage.h
index 42b6090..dfd2e9e 100644
--- a/tools/imximage.h
+++ b/tools/imximage.h
@@ -151,13 +151,14 @@ typedef struct {
dcd_v2_t dcd_table;
 } imx_header_v2_t;
 
+/* The header must be aligned to 4k on MX53 for NAND boot */
 struct imx_header {
union {
imx_header_v1_t hdr_v1;
imx_header_v2_t hdr_v2;
} header;
uint32_t flash_offset;
-};
+} __attribute__((aligned(4096)));
 
 typedef void (*set_dcd_val_t)(struct imx_header *imxhdr,
char *name, int lineno,
-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 4/6] arm: mx5: Add SPL support code to MX5

2013-04-18 Thread Marek Vasut
Fix minor adjustments needed to get SPL framework building on MX5.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Scott Wood scottw...@freescale.com
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
---
 arch/arm/include/asm/arch-mx5/spl.h | 19 +++
 spl/Makefile|  4 
 2 files changed, 23 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-mx5/spl.h

diff --git a/arch/arm/include/asm/arch-mx5/spl.h 
b/arch/arm/include/asm/arch-mx5/spl.h
new file mode 100644
index 000..e0b6e3e
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx5/spl.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2013 Marek Vasut ma...@denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#ifndef __ASM_ARCH_SPL_H__
+#define __ASM_ARCH_SPL_H__
+
+#define BOOT_DEVICE_NONE   0
+#define BOOT_DEVICE_NAND   1
+
+#endif /* __ASM_ARCH_SPL_H__ */
diff --git a/spl/Makefile b/spl/Makefile
index b5a8de7..90f932a 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -88,6 +88,10 @@ ifneq 
($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(C
 LIBS-y += $(CPUDIR)/omap-common/libomap-common.o
 endif
 
+ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35))
+LIBS-y += arch/$(ARCH)/imx-common/libimx-common.o
+endif
+
 ifneq ($(CONFIG_TEGRA),)
 LIBS-y += arch/$(ARCH)/cpu/$(SOC)-common/lib$(SOC)-common.o
 LIBS-y += arch/$(ARCH)/cpu/tegra-common/libcputegra-common.o
-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 0/8] usb: ss: Some fixes and cleanup for USB super-speed support

2013-04-18 Thread Vivek Gautam
On Fri, Apr 19, 2013 at 12:45 AM, Marek Vasut ma...@denx.de wrote:
 Hi Julius,

 Hi Marek,

 I'm sorry, that must have slipped by when I ported the change from my
 local fork. Your patch is correct, you just need to add the ctrl-
 there.

 Well, next time please make sure to compile-test your patches at least before
 you send them.

 The stuff is now pushed, Vivek.

Thanks Marek.



-- 
Best Regards
Vivek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] mx51evk: Update environmet in order to allow booting a dt kernel

2013-04-18 Thread Wolfgang Denk
Dear Fabio Estevam,

In message 1366328263-8468-1-git-send-email-feste...@gmail.com you wrote:
 

There is a typo in the Subject:  s/environmet/environment/

 - mmcroot=/dev/mmcblk0p3 rw\0 \
 - mmcrootfstype=ext3 rootwait\0 \
 - mmcargs=setenv bootargs console=ttymxc0,${baudrate}  \
 - root=${mmcroot}  \
 - rootfstype=${mmcrootfstype}\0 \
 + mmcroot=/dev/mmcblk0p3 rw rootwait\0 \
 + mmcargs=setenv bootargs console=ttymxc0,${baudrate} root=${mmcroot}\0\

You are dropping the mmcrootfstype part here.  Is this intentional?
If yes, it appears to be an unrelated change that should be done in a
separate commit.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
When the bosses talk about improving  productivity,  they  are  never
talking about themselves.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx: Complete the pin definitions for the i.MX6DL / i.MX6Solo

2013-04-18 Thread Pierre AUBERT

Hello Wolfgang

Le 18/04/2013 19:38, Wolfgang Denk a écrit :

Dear Pierre AUBERT,

In message 51700b80.2090...@staubli.com you wrote:

What is the purpose of this patch?  Who needs the added definitions?

These new definitions are useful for all boards based on i.MX6DL or
i.MX6Solo.
I just submitted a patch to support SabreSD equipped with i.MX6DL.
I missed the submission of two patches together.

So your SabreSD patch depends on this one?

Yes

I just asked for some cleanup for that other patch, so when
resubmitting you can make this a series.

I will resubmit as a serie today.


Best regards,

Wolfgang Denk


Best regards
Pierre Aubert
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx: Add support for the SabreSD shipped with i.MX6DL

2013-04-18 Thread Pierre AUBERT

Hi Fabio,

I can split the patch if you wish, but in this case the compilation 
would be broken for the sabreauto if only one of the two patches is 
applied.


Best regards

Pierre Aubert

Le 18/04/2013 19:51, Fabio Estevam a écrit :

Hi Pierre,

On Thu, Apr 18, 2013 at 11:41 AM, Pierre Aubert p.aub...@staubli.com wrote:


diff --git a/boards.cfg b/boards.cfg
index f785da8..c002cf7 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -256,9 +256,10 @@ mx53smd  arm armv7   
mx53smd freesca
  ima3-mx53arm armv7   ima3-mx53   esg  
  mx5ima3-mx53:IMX_CONFIG=board/esg/ima3-mx53/imximage.cfg
  vision2  arm armv7   vision2 
ttcontrol  mx5
vision2:IMX_CONFIG=board/ttcontrol/vision2/imximage_hynix.cfg
  mx6qarm2 arm armv7   mx6qarm2
freescale  mx6
mx6qarm2:IMX_CONFIG=board/freescale/mx6qarm2/imximage.cfg
-mx6qsabreautoarm armv7   mx6qsabreauto   
freescale  mx6
mx6qsabreauto:IMX_CONFIG=board/freescale/mx6qsabreauto/imximage.cfg
+mx6qsabreautoarm armv7   mx6qsabreauto   
freescale  mx6
mx6qsabreauto:IMX_CONFIG=board/freescale/mx6qsabreauto/imximage.cfg,MX6Q

mx6qsabreauto changes should be done on a different patch.

Regards,

Fabio Estevam


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 6/6] arm: mx5: Add support for DENX M53EVK

2013-04-18 Thread Wolfgang Denk
Dear Marek Vasut,

In message 1366344655-8535-6-git-send-email-ma...@denx.de you wrote:
...
 +#define CONFIG_CMD_DHCP
 +#define CONFIG_CMD_EXT2
 +#define CONFIG_CMD_FAT
 +#define CONFIG_CMD_FAT

One CONFIG_CMD_FAT should be enough.

 +#define CONFIG_CMD_I2C
 +#define CONFIG_CMD_MII
 +#define CONFIG_CMD_MMC
 +#define CONFIG_CMD_NAND
 +#define CONFIG_CMD_NET
 +#define CONFIG_CMD_PING
 +#define CONFIG_CMD_SATA
 +#define CONFIG_CMD_USB

As CONFIG_CMD_DATE is not set, we should enable CONFIG_TIMESTAMP.

 +/*
 + * Ethernet on SOC (FEC)
 + */
 +#ifdef CONFIG_CMD_NET
 +#define CONFIG_FEC_MXC
 +#define CONFIG_ETHPRIME  FEC0

What would that be good for?  We have only a single network interface,
so please drop that.

 +#define CONFIG_ARP_TIMEOUT   200UL

Is this really needed?

 +#define CONFIG_CMDLINE_TAG
 +#define CONFIG_INITRD_TAG
 +#define CONFIG_SETUP_MEMORY_TAGS

I think we support only DT enabled kernels, so do we really need
these?


 +#define  CONFIG_BOOTFILE uImage

Please make this m53evk/uImage as usual.

Don't we need a DT file as well?

 +#define  CONFIG_BOOTARGS console=ttymxc1,115200
 +#define  CONFIG_BOOTCOMMAND  run bootcmd_net

Where is bootcmd_net defined?

I doubt that this is actually a working environment.

 +#define CONFIG_LOADADDR  0x7080
 +#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR

What do we need CONFIG_LOADADDR for?

 +/*
 + * The 0x1000 offset must be present, otherwise board won't boot.
 + * The value (IRAM_BASE_ADDR) must be spelled out, otherwise linker won't 
 link.
 + */
 +#define CONFIG_SPL_TEXT_BASE 0x70008000
 +#define CONFIG_SPL_PAD_TO0x8000
 +#define CONFIG_SPL_STACK 0x70004000
 +#define CONFIG_SPL_LIBCOMMON_SUPPORT
 +#define CONFIG_SPL_LIBGENERIC_SUPPORT
 +#define CONFIG_SPL_SERIAL_SUPPORT
 +#define CONFIG_SPL_GPIO_SUPPORT

The comment above does not relate to the definitions here.  Is it
misplaced, or not correct?



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Just Say No.   - Nancy Reagan
No.- Ronald Reagan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot