Hi Andrew, That's a good idea, I think it will fit. I can just loop until it passes, then load RAM from Flash. But I fear that it won't ever pass: I've added a many-second delay before the RAM load, and it fails. I think there may be something fundamental that I just don't understand about the way the RAM starts up, and it's different for the "bootloop" scenario versus the regular boot-up from flash. But I'll try it; wouldn't be a bad thing to have in there anyway. Rick
On Thu, Mar 20, 2014 at 1:06 PM, Andrew Martens <[email protected]> wrote: > Hi > > I know this must seem obvious, but is there space in your bootloader for a > routine to test the SDRAM? > > Cheers > Andrew > > > On 20/03/2014 21:52, Rick Raffanti wrote: > >> Hello Caspersphere, >> I have a problem unrelated to Casper IP, toolflow, hardware, or >> software. But I know this list is full of clever, generous people, so >> here goes. >> >> I have an SP601 development board. A dozen, in fact. The board has a >> Spartan6, a 16MB flash, and 128MB of DDR2. My design has a MicroBlaze >> and an executable which is too large to fit in the on-chip BRAM. So the >> idea is to have a bootloader program that does fit in the BRAM, which >> then loads the executable out of flash into DDR2, then vectors and >> you're off and running. >> >> I've implemented all this, and programmed the flash. And when I >> configure the FPGA with its configuration bitstream and a "bootloop" >> (this is a Xilinx SDK thing), then I load up the bootloader, everything >> works fine. When I power cycle the board, so that the config bitstream >> and bootloader executable are loaded up from flash, it works sometimes, >> on some boards. But on some boards, almost never. On some boards, >> almost always. >> >> I put in a checksum of the executable code- as the bytes are read from >> flash and written to RAM I do a checksum on the data read from flash, >> and a separate one on the data read back from RAM. The former is always >> the same, the latter varies. >> >> So I thought, Oh, the RAM must be in the process of calibration, and I >> put in a several-second delay before the flash read/RAM write. But no >> help. >> >> So, if you have any thoughts, I'd appreciate it. Xilinx tech support is >> not very helpful. >> >> Many thanks, >> >> Rick >> >
