Re: [U-Boot] Nios2: bootm command bugs (lead to Kernel guzip "crc error" or "ran out of input data") and cfi_flash timeout error
Dear Renato Andreola, In message <49de1434.2070...@imagos.it> you wrote: > I've tested u-boot 2009/03 with the last nios2 uClinux kernel and I've > found 2 bugs (or things that can be changed to improve performance). Can you please submit proper patches? Please use git tools (git-format-patch and git-send-email) to create and send the patches, and make sure to include a useful commit message; also, don't forget your Signed-off-by: message. Please see http://www.denx.de/wiki/U-Boot/Patches for instructions. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Anarchy may not be the best form of government, but it's better than no government at all. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Nios2: bootm command bugs (lead to Kernel guzip "crc error" or "ran out of input data") and cfi_flash timeout error
I've tested u-boot 2009/03 with the last nios2 uClinux kernel and I've found 2 bugs (or things that can be changed to improve performance). => CFI "bug" The first bug is related to the Common Flash Interface handling code: the write/clear/etc.. timeout is calculated assuming a 1kHz timer tick freq. and the expression used to scale the timeout leads to an incorrect timeou in case the tick frequency (integer) is less than 1kHz (e.g. 999Hz due to rounding like in our case with 83.3Mhz clock). The integer division used in the cfi_flash.c routine can be improved like this: 662,663c662,665 < #if CONFIG_SYS_HZ != 1000 < tout *= CONFIG_SYS_HZ/1000; --- > #if CONFIG_SYS_HZ != 1000 > unsigned long long ull; > ull = tout*CONFIG_SYS_HZ + CONFIG_SYS_HZ/2; > tout = ull/1000; /* Compute: tout *= CONFIG_SYS_HZ/1000; */ The new expression uses a long and an integer round trick to function properly even in case of CONFIG_SYS_HZ = 999. => Kernel decompression bug The u-boot copies (sometime and in my test board!) the kernel image from somewhere to the execution address specified into the image header. After the copy, and some more work, the Nios2 bootm() procedure jumps to the entry point. The problem is that the bootm() procedure does not flush the data cache before jumping to the newly copied code, so the execution of the kernel head.S routine (that invalidates the cache and calls guzip) finds some invalid data into the dram memory (some data cache lines have been lost). The following code diff (just to flush data cache) fixes the problem in lib_nios2/bootm.c: 26a27 > #include 34c35,36 < --- > flush_dcache (0,CONFIG_SYS_DCACHE_SIZE ); > flush_icache (0,CONFIG_SYS_ICACHE_SIZE); Renato ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
