BootROM process from SD card breaks DDR #5
Labels
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: M-Labs/artiq-zynq#5
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
Copy the
boot.bin
from thezc706-sd
derivation to a SD card, set the switches to SD card boot, reset/powercycle the ZC706, and this happens:Same szl ELF binary works fine via JTAG.
boot.bin
files created using the official Vivado bootgen are also affected by this bug.I've seen random memory corruption like this before when not doing
xilinx_ps7_init
in openocd before running with JTAG. I guess we are missing some initialization...I have a hunch that
ddr.memtest()
will fail in this scenario. Could you please run one?I'm back to comparing register values with a few ps7_init.* files.
Indeed, it breaks when booting from SD:
And works when booting from JTAG:
I think all the init code should be moved to
szl
, the OpenOCD side should just ensure the bare minimum, i.e. that the core runs and that the OCM is correctly configured.NB: this can be worked around by using the FSBL:
Core1 is not working with the FSBL however, and also FSBL is ugly.
Core1 from FSBL should work now, will test tomorrow.
Update: It works!
BootROM process from SD card corrupts LZMA datato BootROM process from SD card breaks DDRThe issue still occurs after
0c48dd934e
This makes SDRAM work with SZL, on both boards:
I guess we can now bisect the list of registers in ps7_init, and find out which one(s) are necessary to make the SDRAM work.
Run
report_differences
and check the results?AFAIK Astro already did that without success, so bisecting the register writes while checking if the memtest still passes seems like the way to go.
This is the minimal set of init data required to boot properly, i.e. successfully decompressing the lzma buffer. Removing anyone would cause the RAM to fail. Not sure if this is sufficient to ensure no memory corruption, as I've only boot the board and have not yet tried to run kernel on it.
@astro
Note comments in ps7_init. Those are DDRC registers, e.g.
Awesome, thank you!
f0697c3ec3a40736aabb8ab7d7cf57e8ee52978f adds these to our DDR initialization.
f0697c3ec3 does not work.
Still memory corrupted:
Confirmed that this seems sufficient to fix the SDRAM. But having only these writes seems to break (I guess) the PS/PL interface; the firmware freezes right before
INFO(runtime): detected gateware: Simple
(it does not print it).Adding the "ps7_post_config_3_0" operations makes the PS/PL interface work.
Or just call
slcr.init_postload_fpga()
:)Looks resolved now.