Hello,I have a very uncommon problem with Linux on the HPS (Cyclone V) and/or with two previous boot stages. At the moment I don’t have any other ideas to solve this other than listed below. I will briefly describe by problem. Aim: The aim is to boot the HPS with Linux from non standard devices (no NAND, QSPI,.. devices) where the FPGA is configured first and the preloader resides within the FPGA image. I’m using the SoCKit. At the moment the R/W access is done by a JTAG connection which transfers the data (U-Boot, DTB, uImage) into the RAM. Parameters: Quartus 14.1 with the included U-Boot source; Buildroot; Linux Kernel from rocketboards 3.10.37-ltsi socfpga -> up to date Implementation/bootflow:
Continued...problem: - Sometimes the system hangs with different tracelogs depending on which data was destroyed; the corrupt system comes from bit flips/more than two Bit errors within the RAM which normally means that the calibration should not be successful -> can be seen from memtester (userspace) - If the same kernel+DTB is copied to the existing SD-Card (replacing the uImage+ DTB on the SD-Card) in combination with the existing preloader and u-boot (old one from Quartus 13.01), everything works fine finding the bug: - I’ve tried many things but with no positive result: - Changed all addresses TEXT_BASE, FDT,… addresses as used with the SD-Card for the SoCKit Adresses: FDT -> 0x100 uImage -> 0x7FC0 kernel entry point: 0x8000 uboot -> 0x01000040 - I also used some other addresses (suitable addresses) -> did not solve the problem - Preloader RAM test with SDRAM_TEST_LONG (spl.c) -> no errors - Own function within the preloader which writes 0xFFFFFFFF and 0x00000000 to the full SDRAM address range + data check --> no errors - Test on the next bootstage (U-Boot) -> splitted some memory areas into two equal parts and filled them with the same data -> compared against each other to find at minimum one corrupt address with a flipped bit - No errors, even with high memory and more than 500MB - Checked data written by the JTAG interface by comparing the MD5 sums (1: after writing the images into RAM during the preloader stage; 2: transferred the same data during the U-Boot stage (manually halted) and checked against the original data for the case that U-Boot is doing something wrong and reconfigures the RAM controller which should not happen) --> no errors --> no overlapping of images within the RAM - Checked U-Boot settings; compared against SD-Card U-Boot settings which are relevant - Compared RAM-CTRL register values which the prealoder configures and the same registers from Linux -> no differences-> configuration is still valid - Compared old Preloader settings (RAM configuration in sdram_config.h) -> not the same as with the current handoff files even if the old project was the base for the current one - Tried to replace the settings with the old ones-> Preloader RAM check passed but the error are still there - Tried a different kernel from rocketboards (socfpga), version 3.16 -> same problem Conclusion: -- the Kernel seems not to be faulty, because it works with the SD-Card - Maybe there is a problem with U-Boot? Has anyone seen such a problem? Has anyone ideas what the problem could be? Thanks!