02-06-2015 07:03 AM
I have succeed in booting linux-3.17 from 32M-qspi flash on Zedboard . I got a qspi partition in devicetree like this:
/dev/mtd0:0x0- 0x100000 qspi-fsbl-uboot
/dev/mtd1:0x100000- 0x600000 qspi-linux-kernel
/dev/mtd2:0x600000- 0x620000 qspi-devicetree
/dev/mtd3:0x620000- 0x1000000 qspi-rootfs-jffs2
Now I'm trying to upgrade uboot/ kernel /devicetree in-the -field in linux by command:
zynq > flashcp <upgrade_file> /dev/mtdX
zynq > reboot
But sometimes(not all the time) system hangs at "Restarting system..." I have to restart the system by asserting an external reset signal like PS_RST.
I tried to use printk in kernel source to find out where linux ends. I found that linux ends at
zynq_slcr_write(1, SLCR_PS_RST_CTRL_OFFSET); in Linux/arch/arm/mach-zynq/slcr.c
I also tried to use xmd to read REBOOT_STATUS( mrd_phys 0xF8000258) and got an error code 0x00000002 which means "successful jtag handoff" (UG585 table6-12)
I have no ideas about this issue as it occurs randomly. Someone point that bugs exists in Bootrom when accessing 32MB QSPI. But all my booting images are placed in low-16MB address.
Does anyone know why?
Thanks in advance for any ideas.
02-06-2015 11:15 AM
With the 3.17 kernel the kernel crashes (the QSPI driver causes invalid access) when I use flashcp to flash a large rootfs. It always happens around the 16M crossing spot. It then also destroys the lower regions, so the board won't boot after that.
Strangely, if I use flash_erase to wipe the flash and then write it with "dd", the crash doesn't occur, it only happens with flashcp.
So I can confirm there's something funky with the QSPI flash driver in 3.17 and up, but I haven't been able to pinpoint it. I already forwarded the logs to the engineers.
Maybe you're seeing a different effect of the same bug.
02-06-2015 01:11 PM
Might this be the dualstack U_PAGE bug? https://github.com/Xilinx/linux-xlnx/issues/8
It seems it was fixed, then some other changes reverted the fix, and it was fixed again:
It's a mis-placed closing "}", the write() call should be outside of the conditional, otherwise it only writes the page register in one direction and not the other.