[U-Boot] Very slow fatload on bcm2835

[U-Boot] Very slow fatload on bcm2835

[Jakub Kicinski]

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!

[U-Boot] Very slow fatload on bcm2835

[Stephen Warren]

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.

[U-Boot] Very slow fatload on bcm2835

[Michal Marek]

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

[U-Boot] Very slow fatload on bcm2835

[Marek Vasut]

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>

[U-Boot] Very slow fatload on bcm2835

[Jeroen Hofstee]

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

[U-Boot] Very slow fatload on bcm2835

[Marek Vasut]

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

[U-Boot] Very slow fatload on bcm2835

[Stephen Warren]

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!