Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support

2010-10-25 Thread Ghorai, Sukumar 


 -Original Message-
 From: Steve Sakoman [mailto:sako...@gmail.com]
 Sent: Monday, October 25, 2010 11:00 PM
 To: Ghorai, Sukumar
 Cc: John Rigby; u-boot@lists.denx.de; Alagu Sankar; Andy Fleming
 Subject: Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support
 
 On Sat, Oct 23, 2010 at 8:14 AM, Ghorai, Sukumar s-gho...@ti.com wrote:
 
 
  -Original Message-
  From: u-boot-boun...@lists.denx.de [mailto:u-boot-
 boun...@lists.denx.de]
  On Behalf Of Steve Sakoman
  Sent: Friday, October 15, 2010 3:14 AM
  To: John Rigby
  Cc: u-boot@lists.denx.de; Alagu Sankar; Andy Fleming
  Subject: Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support
 
  On Mon, Oct 4, 2010 at 1:32 PM, John Rigby jcri...@gmail.com wrote:
   Alagu,
  
   This never made it into Andy's tree nor upstream.  Could you submit a
   new patch to current upstream with the config option removed as Andy
   said he did back in May?  Maybe we can get it commited via some other
   maintainer.  Steve Sakoman seems to have done some MMC work lately.
 
  I've done some testing with this patch on OMAP3 and OMAP4, in the
  always enabled version.
 
  I compared the old legacy mmc driver vs the new generic mmc driver vs
  new generic mmc driver with multiblock read support added.
 
  The good news is that the generic mmc driver for OMAP is almost twice
  as fast as the old legacy driver.  These patches should be in the next
  u-boot-ti pull request and so will be in mainline shortly.
 
  The bad news is that multiblock reads seem to make no difference :-(
 
  For reading a 45MB file from an ext3 partition using ext2load I get:
 
  legacy:              62 seconds
  generic:             35 seconds
  generic w/ multi: 35 seconds
 
  I'm happy to resubmit the multi-block read patch because it does seem
  to work properly and may even yield improvements on other
  architectures.
 
  Would you like me to do that?
 
  [Ghorai]
  would you please try with additional change?
 
 Yes! That is much better!
 
 Now multiblock reads are faster :-)
 
 The results (including the old legacy mmc driver for reference):
 
 legacy:  62 seconds
 generic: 35 seconds
 generic w/ multi: 9 seconds
 
 I will add my Acked-by and Tested-by and submit the final patch to
 the list later today.
[Ghorai] please add
Tested-by: Sukumar Ghorai s-gho...@ti.com

And will submit a separate patch as mentioned below.

 
 Steve
 
 
  $git diff drivers/mmc/omap_hsmmc.c
 
  diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
  index f8b9840..7f3f968 100644
  --- a/drivers/mmc/omap_hsmmc.c
  +++ b/drivers/mmc/omap_hsmmc.c
  @@ -401,6 +401,7 @@ int omap_mmc_init(int dev_index)
 
         mmc-f_min = 40;
         mmc-f_max = 5200;
  +       mmc-b_max = 0x;
 
         mmc_register(mmc);
 
 
  Steve
  ___
  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 v2] mmc: omap: timeout counter fix

2010-10-25 Thread Ghorai, Sukumar 


 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
 On Behalf Of Wolfgang Denk
 Sent: Tuesday, October 26, 2010 10:06 AM
 To: Menon, Nishanth
 Cc: u-boot
 Subject: Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix
 
 Dear Nishanth Menon,
 
 In message 1288054924-24989-1-git-send-email...@ti.com you wrote:
  Having a loop with a counter is no timing guarentee for timing
  accuracy or compiler optimizations. For e.g. the same loop counter
  which runs when the MPU is running at 600MHz will timeout in around
  half the time when running at 1GHz. or the example where GCC 4.5
  compiles with different optimization compared to GCC 4.4.
  use a udelay(10) to ensure we have a predictable delay.
  use an emperical number - 10 uSec ~= 1sec for a worst case timeout.
 
 Hm... 10 usec = 0.1 sec only... Guess you mean
 
 100,000 x 10 usec = 1 sec ?
 
 
 Best regards,
 
 Wolfgang Denk


[..snip..]
[Menon, Nishanth] - overall, at least the segments I saw had no reason to hit 
the registers so hard (alright we dont have much else to do.. but still).. I am 
very open to options from Sukumar(original author) as well..

[Ghorai] I am agreeing with the part where it's looks while(1) loop. And can 
add retry counter too. otherwise I feel I will increase the boot time. 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix

2010-10-25 Thread Ghorai, Sukumar 


 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
 On Behalf Of Wolfgang Denk
 Sent: Tuesday, October 26, 2010 10:59 AM
 To: Reinhard Meyer
 Cc: Menon, Nishanth; u-boot
 Subject: Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix
 
 Dear Reinhard Meyer,
 
 In message 4cc62b6c.30...@emk-elektronik.de you wrote:
 
  In such cases I prefer to use:
 
  uint64_t etime;
  ...
  etime = get_ticks() + get_tbclk(); /* 1 second */
  do {
  whatever;
  udelay (xx);
  } while (condition  get_ticks() = etime);
 
  That is far more accurate than calling udelay() 10 times.
 
 It may be more accuratre, but it may also be HORRIBLY WRONG!!
 
 Do NOT do that!! NEVER implement such a delay loop as
 
   end = time() + delay;
   while (time()  end)
   ...
 
 It fails in case the timer wraps around.
 
 Assume 32 bit counters, start time = 0xFFF0, delay = 0x20. It
 will compute end = 0x10, the while codition is immediately false, and
 you don't have any delay at all, which most probably generates a
 false error condition.
 
 
 Correct implementation of a timeout like that should always look like
 that:
 
   start = time();
   while ((time() - start)  delay)
   ...
 
 This works much better (assuming unsigned arithmetics).
[Ghorai] Thanks.. This is the best approach. 
Otherwise udelay() will increase the boot time. 

 
 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
 Ein weiser Herrscher kann in einem großen Land  mehr  Gutes  bewirken
 als  in  einem kleinen - ein dummer Herrscher aber auch viel mehr Un-
 fug. Da weise Herrscher seltener sind als dumme, war ich schon  immer
 gegen große Reiche skeptisch.   - Herbert Rosendorfer
 ___
 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 3/4] MMC Multi-block Support

2010-10-23 Thread Ghorai, Sukumar 


 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
 On Behalf Of Steve Sakoman
 Sent: Friday, October 15, 2010 3:14 AM
 To: John Rigby
 Cc: u-boot@lists.denx.de; Alagu Sankar; Andy Fleming
 Subject: Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support
 
 On Mon, Oct 4, 2010 at 1:32 PM, John Rigby jcri...@gmail.com wrote:
  Alagu,
 
  This never made it into Andy's tree nor upstream.  Could you submit a
  new patch to current upstream with the config option removed as Andy
  said he did back in May?  Maybe we can get it commited via some other
  maintainer.  Steve Sakoman seems to have done some MMC work lately.
 
 I've done some testing with this patch on OMAP3 and OMAP4, in the
 always enabled version.
 
 I compared the old legacy mmc driver vs the new generic mmc driver vs
 new generic mmc driver with multiblock read support added.
 
 The good news is that the generic mmc driver for OMAP is almost twice
 as fast as the old legacy driver.  These patches should be in the next
 u-boot-ti pull request and so will be in mainline shortly.
 
 The bad news is that multiblock reads seem to make no difference :-(
 
 For reading a 45MB file from an ext3 partition using ext2load I get:
 
 legacy:  62 seconds
 generic: 35 seconds
 generic w/ multi: 35 seconds
 
 I'm happy to resubmit the multi-block read patch because it does seem
 to work properly and may even yield improvements on other
 architectures.
 
 Would you like me to do that?
[Ghorai]
would you please try with additional change?
$git diff drivers/mmc/omap_hsmmc.c

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index f8b9840..7f3f968 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -401,6 +401,7 @@ int omap_mmc_init(int dev_index)

mmc-f_min = 40;
mmc-f_max = 5200;
+   mmc-b_max = 0x;

mmc_register(mmc);

 
 Steve
 ___
 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] Testing Data Cache for armv7 (beagleboard)

2010-10-13 Thread Ghorai, Sukumar 
 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
 On Behalf Of chris c
 Sent: Tuesday, October 12, 2010 6:55 AM
 To: u-boot@lists.denx.de
 Subject: Re: [U-Boot] Testing Data Cache for armv7 (beagleboard)
 
 Thanks for the replies.  I didn't realize that the MMC module was
 operating
 in 1-bit mode inside U-boot.  I'll concentrate on looking at that.  Has
 anybody done any work to try and get 4-bit mode working for OMAP3 in
 U-boot?

[Ghorai] can you give a test using this patch series? This uses the generic 
mmc/sd driver for beagle board. And mmc/sd card will work at 4-bit, 48Mhz.
http://www.mail-archive.com/u-boot@lists.denx.de/msg38690.html

 
 Thanks,
 Chris
 
 On Thu, Oct 7, 2010 at 1:04 PM, Wolfgang Denk w...@denx.de wrote:
 
  Dear chris c,
 
  In message
 aanlkti=usueyf4yuuvwrrlu80bmrfprf+btheix2b...@mail.gmail.comusuEyf4YuUVW
 rrlu80bmrfprf%2bbtheix2b...@mail.gmail.com
  you wrote:
  
   I was comparing time just by timing it manually.  How did you
 instrument
   u-boot to display the time?
 
  That's no instrumentation of U-Boot, but just timestamping the output
  on the serial console. See for example
  ftp://ftp.denx.de/pub/tools/time_log
 
   As for the small versus large file, I did the same test for 1MB of
 data
   using nand read and saw a x4 performance advantage.  I also did a test
 on
   mmc with 100 MB file and saw no performance increase.  Looks like file
  size
   doesn't matter.
  
   So does that mean that MMC file loading will not benefit from dcache
   enabled?  Can anybody explain this?
 
  It depends on where the time is actually spent. If you have a slow
  (say, bit-banging) MMC driver and a low-performance CPU then the
  transfer from MMC might simply not depend as much on caches. It is
  wrong to check just a simple use case. Try a number of different
  operations, like umcompressing a large image in RAM or from NOR to
  RAM, or downloading over the net, or ...
 
  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
  Remember, Information is not knowledge;  Knowledge  is  not  Wisdom;
  Wisdom is not truth; Truth is not beauty; Beauty is not love; Love is
  not music; Music is the best.  - Frank Zappa
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2 V3] mmc: add boundary check for mmc operation

2010-10-12 Thread Ghorai, Sukumar 


 -Original Message-
 From: Wolfgang Denk [mailto:w...@denx.de]
 Sent: Wednesday, October 13, 2010 12:51 AM
 To: Andy Fleming; Ghorai, Sukumar
 Cc: Lei Wen; Lei Wen; u-boot@lists.denx.de; sshtyl...@mvista.com
 Subject: Re: [U-Boot] [PATCH 1/2 V3] mmc: add boundary check for mmc
 operation
 
 Dear Andy,
 
 In message 2a3dcf3da181ad40bde86a3150b27b6b0316062...@dbde02.ent.ti.com
 Sukumar Ghorai wrote:
 ...
  I found the problem. It's a eMMC size calculation is wrong and here is
 the
  fix I am sending as a patch too in my next email.
 
  From: Sukumar Ghorai s-gho...@ti.com
  Date: Mon, 20 Sep 2010 18:29:29 +0530
  Subject: [PATCH 1/3] fix for eMMC capacity calculation
 
capacity of the eMMC device available in ext-CSD register only
 
  Signed-off-by: Sukumar Ghorai s-gho...@ti.com
  ---
  drivers/mmc/mmc.c |   11 +++
   1 files changed, 11 insertions(+), 0 deletions(-)
 
 Is this patch on your queue?
[Ghorai] 
This has been submitted by Steve Sakoman sometime back.
http://www.mail-archive.com/u-boot@lists.denx.de/msg38692.html

 
 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
 Here's a fish hangs in the net like a poor man's right in  the  law.
 'Twill hardly come out. - Shakespeare, Pericles, Act II, Scene 1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2 V3] mmc: add boundary check for mmc operation

2010-09-20 Thread Ghorai, Sukumar 


 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
 On Behalf Of Wolfgang Denk
 Sent: Sunday, September 19, 2010 3:17 AM
 To: Lei Wen
 Cc: u-boot@lists.denx.de; sshtyl...@mvista.com
 Subject: Re: [U-Boot] [PATCH 1/2 V3] mmc: add boundary check for mmc
 operation
 
 Dear Lei Wen,
 
 In message 1284386848-4670-1-git-send-email-lei...@marvell.com you
 wrote:
 
  Signed-off-by: Lei Wen lei...@marvell.com
  ---
  V2:
  Change log:
  change the puts to printf to better formating.
 
   drivers/mmc/mmc.c |   10 ++
   1 files changed, 10 insertions(+), 0 deletions(-)
 
 Applied, thanks.

[Ghorai] I was using the latest mmc/sd core for OMAP 4 and getting the 
following error. 
OMAP4430 SDP # mmc rescan 1
MMC: block number 0x1 exceeds max(0x0)OMAP4430 SDP #

Please let me know what I am missing.

 
 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
 Intel's new motto: United we stand. Divided we fall!
 ___
 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 1/2 V3] mmc: add boundary check for mmc operation

2010-09-20 Thread Ghorai, Sukumar 


 -Original Message-
 From: Lei Wen [mailto:adrian.w...@gmail.com]
 Sent: Monday, September 20, 2010 6:29 PM
 To: Ghorai, Sukumar
 Cc: Wolfgang Denk; Lei Wen; u-boot@lists.denx.de; sshtyl...@mvista.com
 Subject: Re: [U-Boot] [PATCH 1/2 V3] mmc: add boundary check for mmc
 operation
 
 Hi Ghorai,
 
 
  [Ghorai] I was using the latest mmc/sd core for OMAP 4 and getting the
 following error.
  OMAP4430 SDP # mmc rescan 1
  MMC: block number 0x1 exceeds max(0x0)OMAP4430 SDP #
 
  Please let me know what I am missing.
[Ghorai] Thanks. 
I found the problem. It's a eMMC size calculation is wrong and here is the fix 
I am sending as a patch too in my next email.

From: Sukumar Ghorai s-gho...@ti.com
Date: Mon, 20 Sep 2010 18:29:29 +0530
Subject: [PATCH 1/3] fix for eMMC capacity calculation

  capacity of the eMMC device available in ext-CSD register only

Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
drivers/mmc/mmc.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 80cd9bf..c543d83 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -627,6 +627,7 @@ int mmc_startup(struct mmc *mmc)
uint mult, freq;
u64 cmult, csize;
struct mmc_cmd cmd;
+   char ext_csd[512];
 
/* Put the Card in Identify Mode */
cmd.cmdidx = MMC_CMD_ALL_SEND_CID;
@@ -742,6 +743,16 @@ int mmc_startup(struct mmc *mmc)
if (err)
return err;
 
+   if (!IS_SD(mmc)  (mmc-version = MMC_VERSION_4)) {
+   /* check  ext_csd version and capacity */
+   err = mmc_send_ext_csd(mmc, ext_csd);
+   if (!err  (ext_csd[192] = 2)) {
+   mmc-capacity = ext_csd[212]  0 | ext_csd[213]  8 |
+   ext_csd[214]  16 | ext_csd[215]  24;
+   mmc-capacity *= 512;
+   }
+   }
+
if (IS_SD(mmc))
err = sd_change_freq(mmc);
else
-- 
1.7.0.4
 
 
 I also test the latest code, and don't find the issue you report...
 What would happen when you type mmcinfo 1? Seems your mmc card is
 not init properly.
 
 Best regards,
 Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] status of patch to store environment to mmc/sd

2010-09-16 Thread Ghorai, Sukumar 


 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
 On Behalf Of Wolfgang Denk
 Sent: Friday, September 10, 2010 4:43 PM
 To: Amit Kucheria
 Cc: u-boot@lists.denx.de; r65...@freescale.com
 Subject: Re: [U-Boot] status of patch to store environment to mmc/sd
 
 Dear Amit Kucheria,
 
 In message aanlkti=pekhk5qwxm_ja5bm1a9=2qskfqvy-h2nw2...@mail.gmail.com
 you wrote:
 
   It is not related to a specific storage. We could have a filesystem
 even
   on other storages (SPI-Flash, NAND, HD...) and reading from file
   should IMHO hide the underlying storage media.
 
  Reading from filesystems brings up the obvious question - which
  filesystems should we support?
 
 Well, reading from file system in only one part of the issue - you
 also need write support or you cannot implement saveenv.  And at the
 moment YAFFS is the only file system with write support, IIRC.
 
  And it is definitely a separate patch. The feature that this patch is
  enabling can exist independent of filesystem support.

[Ghorai] This patch is very important for the platform where we don't have any 
other storage device; e.g. omap4 development platforms does not have any 
NAND/NOR to save the env. And need to use this patch. 

 
 Indeed.
 
 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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot