All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] Very slow fatload on bcm2835
@ 2015-06-11 18:35 Jakub Kicinski
  2015-06-16  4:01 ` Stephen Warren
  0 siblings, 1 reply; 7+ messages in thread
From: Jakub Kicinski @ 2015-06-11 18:35 UTC (permalink / raw)
  To: u-boot

Hello!

I'm using latest git source of U-Boot on Raspberry Pi Compute Module 
and performance of fatload is quite bad.  Does anyone have any clue
about what can be wrong?  Is it the lack of cache?

Sample boot log:

U-Boot 2015.07-rc2-dirty (Jun 11 2015 - 17:03:17 +0200)
                                                       
DRAM:  412 MiB
WARNING: Caches not enabled
RPI Compute Module         
MMC:   bcm2835_sdhci: 0
reading uboot.env      
In:    serial    
Out:   lcd   
Err:   lcd
Net:   Net Initialization Skipped
No ethernet found.               
Hit any key to stop autoboot:  0 
Booting normal system...         
switch to partitions #0, OK
mmc0(part 0) is current device
reading zImage                
4003816 bytes read in 48930 ms (79.1 KiB/s)


Thanks!

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Very slow fatload on bcm2835
  2015-06-11 18:35 [U-Boot] Very slow fatload on bcm2835 Jakub Kicinski
@ 2015-06-16  4:01 ` Stephen Warren
  2015-06-16  9:19   ` Michal Marek
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Warren @ 2015-06-16  4:01 UTC (permalink / raw)
  To: u-boot

On 06/11/2015 12:35 PM, Jakub Kicinski wrote:
> Hello!
> 
> I'm using latest git source of U-Boot on Raspberry Pi Compute Module 
> and performance of fatload is quite bad.  Does anyone have any clue
> about what can be wrong?  Is it the lack of cache?
> 
> Sample boot log:
...
> reading zImage                
> 4003816 bytes read in 48930 ms (79.1 KiB/s)

I see this too. I bisected it to:
33fe2fb8df01 ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver

Marek, this is the second symptom I bisected to this patch. Something
seems quite wrong with it. Did changing to the other timer function
change the timer tick rate or something? FWIW, "sleep 10" at the shell
prompt appears to run for the correct amount of time, so I guess it's
not that.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Very slow fatload on bcm2835
  2015-06-16  4:01 ` Stephen Warren
@ 2015-06-16  9:19   ` Michal Marek
  2015-06-17 10:43     ` Marek Vasut
  0 siblings, 1 reply; 7+ messages in thread
From: Michal Marek @ 2015-06-16  9:19 UTC (permalink / raw)
  To: u-boot

On 2015-06-16 06:01, Stephen Warren wrote:
> On 06/11/2015 12:35 PM, Jakub Kicinski wrote:
>> Hello!
>>
>> I'm using latest git source of U-Boot on Raspberry Pi Compute Module 
>> and performance of fatload is quite bad.  Does anyone have any clue
>> about what can be wrong?  Is it the lack of cache?
>>
>> Sample boot log:
> ...
>> reading zImage                
>> 4003816 bytes read in 48930 ms (79.1 KiB/s)
> 
> I see this too. I bisected it to:
> 33fe2fb8df01 ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver
> 
> Marek, this is the second symptom I bisected to this patch. Something
> seems quite wrong with it. Did changing to the other timer function
> change the timer tick rate or something? FWIW, "sleep 10" at the shell
> prompt appears to run for the correct amount of time, so I guess it's
> not that.

I think you meant Marek Va?ut. I'm Marek by last name :).

Michal

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Very slow fatload on bcm2835
  2015-06-16  9:19   ` Michal Marek
@ 2015-06-17 10:43     ` Marek Vasut
  2015-06-17 13:44       ` Jeroen Hofstee
  2015-06-18  1:55       ` Stephen Warren
  0 siblings, 2 replies; 7+ messages in thread
From: Marek Vasut @ 2015-06-17 10:43 UTC (permalink / raw)
  To: u-boot

On Tuesday, June 16, 2015 at 11:19:11 AM, Michal Marek wrote:
> On 2015-06-16 06:01, Stephen Warren wrote:
> > On 06/11/2015 12:35 PM, Jakub Kicinski wrote:
> >> Hello!

Hi/Ahoj :)

> >> I'm using latest git source of U-Boot on Raspberry Pi Compute Module
> >> and performance of fatload is quite bad.  Does anyone have any clue
> >> about what can be wrong?  Is it the lack of cache?
> > 
> >> Sample boot log:
> > ...
> > 
> >> reading zImage
> >> 4003816 bytes read in 48930 ms (79.1 KiB/s)
> > 
> > I see this too. I bisected it to:
> > 33fe2fb8df01 ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver
> > 
> > Marek, this is the second symptom I bisected to this patch. Something
> > seems quite wrong with it. Did changing to the other timer function
> > change the timer tick rate or something? FWIW, "sleep 10" at the shell
> > prompt appears to run for the correct amount of time, so I guess it's
> > not that.

Hmmmm, get_timer() returns msecs, not usecs. I wonder what I was smoking.
Can you try with the attached diff please (I only compile-tested it) ?

> I think you meant Marek Va?ut. I'm Marek by last name :).

We're both Czech though ;-)

Best regards,
Marek Vasut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdmmc.diff
Type: text/x-patch
Size: 706 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150617/32c063a7/attachment.bin>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Very slow fatload on bcm2835
  2015-06-17 10:43     ` Marek Vasut
@ 2015-06-17 13:44       ` Jeroen Hofstee
  2015-06-18 12:34         ` Marek Vasut
  2015-06-18  1:55       ` Stephen Warren
  1 sibling, 1 reply; 7+ messages in thread
From: Jeroen Hofstee @ 2015-06-17 13:44 UTC (permalink / raw)
  To: u-boot

Hello Marek,

-    while (get_timer(bcm_host->last_write) < bcm_host->twoticks_delay)
+    while (timer_get_us() < bcm_host->last_write + 
bcm_host->twoticks_delay)
          ;

Can this counter / the right side of the comparison not overflow?

Regards,
Jeroen

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Very slow fatload on bcm2835
  2015-06-17 10:43     ` Marek Vasut
  2015-06-17 13:44       ` Jeroen Hofstee
@ 2015-06-18  1:55       ` Stephen Warren
  1 sibling, 0 replies; 7+ messages in thread
From: Stephen Warren @ 2015-06-18  1:55 UTC (permalink / raw)
  To: u-boot

On 06/17/2015 04:43 AM, Marek Vasut wrote:
> On Tuesday, June 16, 2015 at 11:19:11 AM, Michal Marek wrote:
>> On 2015-06-16 06:01, Stephen Warren wrote:
>>> On 06/11/2015 12:35 PM, Jakub Kicinski wrote:
>>>> Hello!
> 
> Hi/Ahoj :)
> 
>>>> I'm using latest git source of U-Boot on Raspberry Pi Compute Module
>>>> and performance of fatload is quite bad.  Does anyone have any clue
>>>> about what can be wrong?  Is it the lack of cache?
>>>
>>>> Sample boot log:
>>> ...
>>>
>>>> reading zImage
>>>> 4003816 bytes read in 48930 ms (79.1 KiB/s)
>>>
>>> I see this too. I bisected it to:
>>> 33fe2fb8df01 ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver
>>>
>>> Marek, this is the second symptom I bisected to this patch. Something
>>> seems quite wrong with it. Did changing to the other timer function
>>> change the timer tick rate or something? FWIW, "sleep 10" at the shell
>>> prompt appears to run for the correct amount of time, so I guess it's
>>> not that.
> 
> Hmmmm, get_timer() returns msecs, not usecs. I wonder what I was smoking.
> Can you try with the attached diff please (I only compile-tested it) ?

Thanks for the quick fix; it works great.
Tested-by: Stephen Warren <swarren@wwwdotorg.org>

>> I think you meant Marek Va?ut. I'm Marek by last name :).
> 
> We're both Czech though ;-)

Oops. Must check my auto-completes more thoroughly!

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Very slow fatload on bcm2835
  2015-06-17 13:44       ` Jeroen Hofstee
@ 2015-06-18 12:34         ` Marek Vasut
  0 siblings, 0 replies; 7+ messages in thread
From: Marek Vasut @ 2015-06-18 12:34 UTC (permalink / raw)
  To: u-boot

On Wednesday, June 17, 2015 at 03:44:41 PM, Jeroen Hofstee wrote:
> Hello Marek,
> 
> -    while (get_timer(bcm_host->last_write) < bcm_host->twoticks_delay)
> +    while (timer_get_us() < bcm_host->last_write +
> bcm_host->twoticks_delay)
>           ;
> 
> Can this counter / the right side of the comparison not overflow?

Yes it can -- what do you suggest to make it overflow-safe in this
particular case ?

Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-06-18 12:34 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-11 18:35 [U-Boot] Very slow fatload on bcm2835 Jakub Kicinski
2015-06-16  4:01 ` Stephen Warren
2015-06-16  9:19   ` Michal Marek
2015-06-17 10:43     ` Marek Vasut
2015-06-17 13:44       ` Jeroen Hofstee
2015-06-18 12:34         ` Marek Vasut
2015-06-18  1:55       ` Stephen Warren

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.