The AM62x SK EVM uses an OSPI Flash chip by cypress. We use OSPI DTR mode read / writes to this chip which helps us support high speed ops. The driver support is already present in upstream u-boot and this series just aims to enable that support for AM62x SK EVM. 1. Now the board can completely boot up from R5 SPL to U-Boot prompt from the OSPI Flash. 2. OSPI Flash can now be used from the U-Boot stage as well.
A small catch though: Since we do DTR Read from OSPI Flash, one can't do an odd number of bytes read / write in DTR mode. However when we load the Image from Flash to the DDR/ RAM inorder to load the A53 SPL Stage, the generated DTB inside the FIT image is of an odd number of bytes. There is a strict check that prevents the read of odd number of bytes from the Flash. This causes the entire boot flow to freeze and hence I had to temporarily introduce a HACK in spl_spi.c. This hack essentially does the following: diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c index da6742416ed9..d147ac36f4ad 100644 --- a/common/spl/spl_spi.c +++ b/common/spl/spl_spi.c @@ -59,7 +59,11 @@ static ulong spl_spi_fit_read(struct spl_load_info *load, ulong sector, struct spi_flash *flash = load->dev; ulong ret; - ret = spi_flash_read(flash, sector, count, buf); + if (count%2 != 0) + ret = spi_flash_read(flash, sector, count+1, buf); + else + ret = spi_flash_read(flash, sector, count, buf); + printf("mylogs: %s#%d return = 0x%x\n", __func__, __LINE__, ret); if (!ret) return count; else wherein we make sure to pass an extra count if count is odd. This seems to atleast let me boot up the board, however this solution is far from ideal and hence I haven't included it in this patch. How to solve this odd byte issue is something that I need some inputs with, currently I have 2 ideas: 1. Force all the Images contained within the FIT to have an even number of bytes. This can be done using padding of bytes toward the end maybe. 2. Modify the driver OR the caller to ensure that even number of bytes are read from OSPI Flash and then disregard the additional byte. I am not entirely sure yet if the upstream linux kernel handles this odd byte exceptions cleanly however I do know that unlike in u-boot where we have strict checks in place in spi_mem_dtr_supports_op() to ensure that data bytes are even, the checks in kernel are more lenient. Perhaps I will need to deep dive into the MTD Stack in kernel to see how it is being done there, if atall it even is. I would appreciate any inputs that the U-Boot community has in this matter. But for now this patch series in itself has all the necessary configs and DT changes needed to boot from OSPI Flash. Dhruva Gole (2): arm: dts: Enable OSPI for AM62-SK configs: enable OSPI related configs in AM62x arch/arm/dts/k3-am625-r5-sk.dts | 5 ++ arch/arm/dts/k3-am625-sk-u-boot.dtsi | 24 +++++++++ arch/arm/dts/k3-am625-sk.dts | 77 ++++++++++++++++++++++++++++ configs/am62x_evm_a53_defconfig | 19 +++++++ configs/am62x_evm_r5_defconfig | 22 ++++++++ 5 files changed, 147 insertions(+) -- 2.25.1