Very slow fatload on bcm2835

U-Boot Jakub Kicinski 5 participants 7 messages Jun 11, 2015 – Jun 18, 2015

Share & tools

Jakub Kicinski

author

2015-06-11 18:35 UTC #0 lore raw

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!

Stephen Warren

2015-06-16 04:01 UTC #1 lore raw

Quoted 7 lines · 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:

...

Quoted 2 lines

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.

Michal Marek

2015-06-16 09:19 UTC #2 lore raw

Quoted 12 lines · Stephen Warren

Quoted 7 lines · 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:
...
Quoted 2 lines
reading zImage
4003816 bytes read in 48930 ms (79.1 KiB/s)

Quoted 8 lines

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

Marek Vasut

2015-06-17 10:43 UTC #3 lore raw

Quoted 3 lines · Michal Marek

Quoted 2 lines · Stephen Warren
Quoted 1 line · Jakub Kicinski
Hello!

Hi/Ahoj :)

Quoted 10 lines

Quoted 10 lines
Quoted 5 lines
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:
...
Quoted 2 lines
reading zImage
4003816 bytes read in 48930 ms (79.1 KiB/s)

Quoted 8 lines

Quoted 8 lines
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) ?

Quoted 1 line

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>

Jeroen Hofstee

2015-06-17 13:44 UTC #4 lore raw

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

Marek Vasut

2015-06-18 12:34 UTC #5 lore raw

Quoted 8 lines · Jeroen Hofstee

Hello Marek,
(quoted diff) +1 -1
-    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

Stephen Warren

Tested-by

2015-06-18 01:55 UTC #6 lore raw

In reply to Marek Vasut

Quoted 20 lines · Marek Vasut

Quoted 3 lines · Michal Marek
Quoted 2 lines · Stephen Warren
Quoted 1 line · Jakub Kicinski
Hello!
Hi/Ahoj :)
Quoted 13 lines
Quoted 13 lines
Quoted 5 lines
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:
...
Quoted 2 lines
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

Quoted 8 lines

Quoted 5 lines
Quoted 5 lines
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 <[email protected]>

Quoted 3 lines

Quoted 1 line
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!