|
ut Michal My problem seems to be a timing issue. I am not sure how the differences between EDK 9.1 and 10.1 change the design but I can boot successfully with new FS-boot out of Bram if I load it from the SDK after I previously load the FS-boot from the PreBuilt. The new U-Boot and Kernel were flashed using the pre-built FS-boot but using the config and images from the new build. The "Hardware design" is loaded by the respective FS-boots. The software in FS-boot has not been changed. Another thing I have noticed is that the 6.0 Microblaze uses 10 bram blocks to implement two 8K cache blocks where the &.1 Microblaze uses the 10 bram blocks to implement two 4K cache blocks. Something strange there. I think the problem is caused by the Xilinx IP's. Thanks Hubert Michal Simek wrote: Hi Hubert, FS-boot is in bram - then looks at specific place in flash where is stored kernel image or u-boot image (only relocable format is acceptable) -> if success just jump on specific address. Memory map and specific address is counted by BSP.(Size of memory could be doubled but this shouldn't be a problem -> uncached shadow case). If you have doubled size memory size, please set correct value in main_memory_size in BSP(EDK-> software setting) In your case seems your flash starts at 0x21000000. Firsts sectors are used by U-BOOT and then is space for linux kernel - (image.ub - created by mkimage tool). Because you U-BOOT is set "only" by ub.config.img which set your U-BOOT variable there is one default choice which is called bootcmd. Please write pri in U-BOOT. you should see it. There could be written something like bootm 0x210c0000 and variable bootdelay should be set to 5. This means that after U-BOOT startup you will wait 5 seconds and then if you don't interrupt it, you will run bootcmd command. BOOTM command just look to your specific address (0x210c0000 in your case) and look at magic sequence which have every mkimage formats. If is found, just follow U-BOOT code and copy and jump code to ram. If not U-BOOT announce "Bad Header Checksum" error because U-BOOT seems to counted crc of image and of course is bad. Correct crc value is in image header. This concept is prepared for platform where u-boot run prepared image in flash. If you want to use different values you can just change them. For testing is good to set booting from tftp server setenv bootcmd tftp 0x27080000 image.ub\;bootm saveenv For disabling 5 sec delay setenv bootdelay 0 saveenv U-BOOT is more powerful than fs-boot especially for testing. On u-boot mailing list you can find some discuss about how is possible to do more sophisticated booting strategy or how to safely upgrade kernel image on your running platform. On the other hand fs-boot is in bram and if is smaller and faster for kernel running. This shorten kernel reboot. There is a lot of issues which every booting strategy brings. I hope you have better look how this work and why. Regards, Michal Simek Hubert Bahr wrote: ___________________________ microblaze-uclinux mailing list microblaze-uclinux@xxxxxxxxxxxxxx Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/ |