Dear Sergey Lapin,
In message 20111213165113.GA27964@build.ihdev.net you wrote:
So we could have only 64MB as one piece; Due to u-boot reloaction code we need to have u-boot in first 64MB also. ...
Why would that be the case?
If we specify memory size as 128MB (gd->ram_size) u-boot reloacates itself to unused part of first memory bank instead of the end of second bank, which actually makes it fail badly.
You are not supposed to "specify" RAM sizes. You should use get_ram_size() to auto-detect the installed size, and do this separately for each bank of memory.
I'm not sure if the relocation code on ARM makes any assumptions that the memory is contiguous, but it should be relatively easy to fix so that it always relocates to the end of the last (highest) bank of memory.
If I were in this situation, I'd probably run this under Linux.
Well, we already running production using u-boot. And on production devices we have no (fast) network access. We boot u-boot from mmc, which flashes images on the same card and then boots device. I can't see how faster we can be with Linux, which will add several more seconds to boot.
Linx MMC drivers and file system code will probably be way faster than what we have in U-Boot, and you can inteleave reading from MMC with writing to NAND - actually you can do it fully in parallel uner Linux (using for example "buffer" or similar tools).
Until you really measure it you should not make assumptions which way is faster.
Best regards,
Wolfgang Denk