AM6442: Falcon boot on SK-AM64B - Flash speed.

Ingo Roda

Part Number: AM6442
Other Parts Discussed in Thread: SK-AM64B

Hi all,

I am currently working with the SK-AM64B evaluation board. The goal of my work is to achieve a minimal boot time using the assembled octal flash.

I have implemented "Falcon Boot" according to "https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1205638/faq-am625-how-to-boot-from-r5-u-boot-spl-directly-into-the-linux-kernel-skipping-a53-spl-and-a53-u-boot-falcon-mode". The R5-SPL then boots a minimal TI Linux RT Kernel with a initramfs.

On the evaluation board I have selected the xSPI boot mode. From what I have measured, it seems that the fit image, which contains the ATF, OPTEE, Kernel, DT and initramfs, is loaded in xSPI flash operation mode 8D-8D-8D @ 25MHz. After booting to the rootfs, the flash clock and DQS signal are working at 166MHz.

So, now the question. When ist the flash mode switched? Is it possible to have the same clock speed in R5 SPL when the fit image is loaded?

over 1 year ago

0 Bin Liu over 1 year ago

TI__Guru**** 167301 points

Hi Ingo,

Have you written the phy calibration pattern as documented below? It should put the OSPI in 166MHz when transferring data in U-Noot.

https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_00_00_03/exports/docs/linux/Foundational_Components/U-Boot/UG-QSPI.html

0 Ingo Roda over 1 year ago in reply to Bin Liu

Prodigy 30 points

I expected the calibration pattern to be there, since I am working on a TI eval board and have never erased the entire flash since I got the board. Nevertheless I just wrote the phy pattern (again) to the flash as described in the mentioned link. No change, still 25 MHz.

But again, I am using Falcon Boot, so only the R5 SPL. Does that make any difference regarding the phy calibration?

And also, I turned on debugging for the cadence_qspi driver. During boot I see the message "Unable to find RX high". Maybe that helps.

I also booted into the console of the the standard u-boot from SDK 09_00_00_03 and read the flash, also just 25 MHz.

0 Bin Liu over 1 year ago in reply to Ingo Roda

TI__Guru**** 167301 points

Hi Ingo,

Ingo Roda said:
I expected the calibration pattern to be there, since I am working on a TI eval board and have never erased the entire flash since I got the board.

The OSPI flash is not programmed out of the factory, so the calibration pattern is not on it.

Ingo Roda said:
But again, I am using Falcon Boot, so only the R5 SPL. Does that make any difference regarding the phy calibration?

I don't think so. R5 SPL switch to high speed mode in reading data when the phy calibration pattern is found.

Ingo Roda said:
And also, I turned on debugging for the cadence_qspi driver. During boot I see the message "Unable to find RX high". Maybe that helps.

The message seems indicating the phy calibration failed.

Can you please provide the console log showing the exact OSPI flashing process?

0 Ingo Roda over 1 year ago in reply to Bin Liu

Prodigy 30 points

As I found out today, sometimes the phy calibration works, sometimes not. After turning off and on the device the calibration sometimes works, sometimes not.

What do you mean with "OSPI flashing process"? The commands I type in order to program the flash or the debug output of the calibration?

0 Bin Liu over 1 year ago in reply to Ingo Roda

TI__Guru**** 167301 points

Hi Ingo,

Ingo Roda said:
As I found out today, sometimes the phy calibration works, sometimes not.

It is strange. Is it possible that you can debug the phy calibration routine in u-boot to understand where exactly the failure is?

Ingo Roda said:
What do you mean with "OSPI flashing process"?

Yes, the commands you type to program the flash. But I don't think it matters now since you mentioned the phy calibration works sometimes.

0 Ingo Roda over 1 year ago in reply to Bin Liu

Prodigy 30 points

Yes, I will try that.

0 Ingo Roda over 1 year ago in reply to Ingo Roda

Prodigy 30 points

It seems that the combination of re-flashing the calibration pattern and removing the measurement lines/cables, that we added for measuring the clock and DQS signal, solved the issue. Thanks for the help.

0 Bin Liu over 1 year ago in reply to Ingo Roda

TI__Guru**** 167301 points

Hi Ingo,

Glad the issue is resolved. Thanks for the update.

Processors

Processors forum

AM6442: Falcon boot on SK-AM64B - Flash speed.