On Fri, Mar 20, 2015 at 3:54 PM, Daniel Mack zonque@gmail.com wrote:
Hi,
On 03/20/2015 12:24 PM, Yegor Yefremov wrote:
I've also put printf() into omap_nand_read_prefetch8() just to make sure it is called - it was called.
Does it fall back to polled mode because the engine is busy maybe? See the comment in the code that deals with the return value of __read_prefetch_aligned(). Not that I'd be aware of such an issue, but maybe you need to enable to enable some module or clock?
I've seen this fallback comment and added printf to ret < 0 case and in __read_prefetch_aligned(). I had no cases, where fallback was invoked.
I've also a suspicion, that some clocks settings are missing. Will have to compare register values with Linux ones.
Further ideas?
It's been a while, but when I worked on cutting down the boot times of a custom AM335x board months ago, these were the steps that I took:
- I tweaked the NAND timing values in the DTS, and then looked at the
GPMC timing values Linux calculated from that and copied it over to U-Boot. This gave a NAND read speed-up of ~20-30% in comparison to the defaults U-Boot ships with.
- Implementing the GPMC prefetch operations boosted the speed by of raw
NAND reads by approximately factor 2.
- The NAND bad block table scan was reduced to the first 64 blocks,
because this is all I cared for from U-Boot anyway, and Linux will do the same anyway at a later point. This brought down the scan process from ~2s to some milliseconds.
- In the SPL code, the CPU was put in GHz mode as early as possible.
That improved load times again, and also reduced the time spent in the kernel decompressor.
Do you mean am33xx_spl_board_init()? In theory it reads ID and sets desired MPU/Core voltage. But I'll look at this once again.
I Linux I had ti,nand-xfer-type = "polled";. After replacing it with ti,nand-xfer-type = "prefetch-polled"; I now get
# dd if=/dev/mtdblock5 of=/dev/null bs=2M count=8 8+0 records in 8+0 records out 16777216 bytes (17 MB) copied, 2.58744 s, 6.5 MB/s
instead of:
# dd if=/dev/mtdblock5 of=/dev/null bs=2M count=8 8+0 records in 8+0 records out 16777216 bytes (17 MB) copied, 6.05157 s, 2.8 MB/s
Do I see it right, that DMA support is not implemented in am33xx.dtsi?
Right, I just double-checked with the DTS we were using. It had no specific "ti,nand-xfer-type" setting, so it should default to "prefetch-polled". So it seems DMA is not in place for this board and the gpmc-nand driver. Sorry for the confusion.
Daniel