On 02/12/2014 11:45 AM, Andreas Bießmann wrote:
Hi Helmut,
On 02/12/2014 10:56 AM, Helmut Raiger wrote:
I understand the first two points, but why do you store the kernel again with 1bit HW-ECC ? The second U-Boot is able to check with 4bit BCH and your NAND requires 4bit.
This is mainly due to performance requirements. Using 4bit BCH increases overhead and makes DMA (currently not used in the kernel driver) a lot slower. We thought we might slip through with 1bit HW-ECC, but we will test this (hopefully not in the field this time ;-) )
If your HW requires 4Bit it is highly recommended to do so. You will run your HW out of specs in other case and I think it is hard to qualify that 4Bit required ECC runs with 1Bit ECC and UBIFS as you stated in a previous mail.
You guys are right. I'm just cornered, as performance is a big issue aswell. We'll try to qualify the NAND in proper climate and some UBIFS supervision to gain more insight. Its just that teh application software guys suggested to improve the kernel driver to use DMA to increase overall performance.
why another u-boot should be any different?!
Just thinking ... have you checked the global data pointer? Is it possible that the global data of the first u-boot influences the global data of the second one?
The global data pointer is setup right before the newly set stack pointer in arch/arm/lib/crt0.S, so it should be reset anyway.
And answering Stefano's question. The RAM setup is only in the SPL which is skipped when I jump to the second u-boot.
But you just inspired me! There are probably interrupts running for some time when the second u-boot starts and the relocation might destroy part of the interrupt entry points ....
Thx for asking the right questions. I'll have to check this.
Helmut
-- Scanned by MailScanner.