TMDSEVM572X: SATA boot + QNX 6.5 SP1

Hi Evgeny,

Please be aware that the SATA driver and BSP are owned by QNX, and this question is best directed to their support teams.   

The BSP link above for DRA74x does not appear to align to align with the board under test TMDSEVM572x.  Deltas between the DRA74x EVM and AM57x EVMs would need to be addressed, this is one possible cause of failure.

The cpsie is enabling interrupts, so another theory would be that when enabled, an incoming interrupt / handling is causing the issue. 

The user guide which is available with the DRA742x BSP, does not show SATA boot mode as supported, meaning this was not likely tested or supported by the BSP. 

As a modified Uboot is being used to boot from SATA,  another theory would be that the changes in Uboot have changed the state of the system enough to effect the QNX startup.   

Regards,

kb

Thanks for the reply!

KB said:

Please be aware that the SATA driver and BSP are owned by QNX, and this question is best directed to their support teams. 

Yes, I already wrote to QNX support a pair of weeks ago. So far no answer.

KB said:

The user guide which is available with the DRA742x BSP, does not show SATA boot mode as supported, meaning this was not likely tested or supported by the BSP. 

Yes, the BSP does not support booting from SATA. But this means that IPL does not implement booting from SATA. That is why I do not use IPL, but use u-boot.
There is a SATA initialization in the startup code, and there is a SATA driver in the BSP. The SATA driver works fine after booting QNX from SD/eMMC.

KB said:

As a modified Uboot is being used to boot from SATA,  another theory would be that the changes in Uboot have changed the state of the system enough to effect the QNX startup.   

In u-boot I just enabled SATA by default in DTS and added SATA in DTS for SPL. I also added some options to the build configuration so that SPL would look for u-boot on SATA.
This was written in the response of the TI support service.
There was no need to change the code of u-boot because almost all the changes from the patches are already present in u-boot.
If I load the same u-boot image from the eMMC, QNX boots and works fine.
But if I run the command "scsi scan" at the u-boot command line before starting the startup, the startup hangs.

KB said:

The BSP link above for DRA74x does not appear to align to align with the board under test TMDSEVM572x.  Deltas between the DRA74x EVM and AM57x EVMs would need to be addressed, this is one possible cause of failure.

The cpsie is enabling interrupts, so another theory would be that when enabled, an incoming interrupt / handling is causing the issue. 

I think u-boot does not use interrupts to work with SATA.
The "cpsie a" instruction is the first instruction at the startup entry point, so the BSP code has not yet had time to affect the state of the MPU in any way.
What can "scsi scan" do that makes the "cpsie a" instruction hang?
How do I get the MPU back to normal?
I have already tried stopping the SATA controller and SATA PHY from the u-boot command line, but this has not had the desired result.

Regards,
Evgeny Rogozhkin

Evgeny Rogozhkin said:

Yes, the BSP does not support booting from SATA. But this means that IPL does not implement booting from SATA. That is why I do not use IPL, but use u-boot.
There is a SATA initialization in the startup code, and there is a SATA driver in the BSP. The SATA driver works fine after booting QNX from SD/eMMC

The QNX "startup" portion of the BSP is on a boot sequence that has not been validated.  Neither TI nor QNX would have tested with a SATA block initialized whether it was from IPL or Uboot.   

In the two scenarios where issue is being seen (Uboot boots from SATA, SCSI scan on SATA), assumption is that SATA IP block has undergone some sort of initialization at Uboot level.   This may be the difference that "startup" is running into. 

One thought is to try a register dump of the SATA block at Uboot level, before and after scsi scan, to see if there any deltas.   

Another possibility is looking into resetting the SATA block at uboot level, before jumping to QNX IFS.

Regards,

kb

KB said:

One thought is to try a register dump of the SATA block at Uboot level, before and after scsi scan, to see if there any deltas.   

Another possibility is looking into resetting the SATA block at uboot level, before jumping to QNX IFS.

Both of these options I have already done.
Resetting the SATA controller and SATA PHY does not give the desired result.
After resetting the SATA registers are almost back to their original state, the differences are minimal and, in my opinion, should not affect the further boot process.

KB said:

The cpsie is enabling interrupts, so another theory would be that when enabled, an incoming interrupt / handling is causing the issue. 

Perhaps the interrupts are not used by the SATA module itself, but by some other code in use. I will try to explore this direction.

Regards,
Evgeny Rogozhkin

Hello!

I found out that after running "scsi scan" the ISR register==0x100. ISR contains pending interrupt states. Before executing the command ISR==0.
It seems that after "cpsie a" the processor immediately tries to run a pending interrupt handler. But the base address of interrupt vector is not set (HVBAR==0).
This is implicitly confirmed by the fact that in the debugger I see that after "cpsie a" control is passed to address 0x0000000C (baseaddr (HVBAR==0) + prefetch abort offset (0xc)).
It seems to be necessary to reset the pending interrupts. I don't know how to do it yet.

Regards,
Evgeny Rogozhkin

I found that the number of SATA devices is not configurable in the DTS. It is read from the SATA controller register (SATA_CAP).
Instead of the previous patch, you can use the following option:

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
old mode 100644
new mode 100755
index 2ef21ec508..b7f03d30b8
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1173,7 +1173,7 @@ int ahci_probe_scsi(struct udevice *ahci_dev, ulong base)
 	uc_plat = dev_get_uclass_plat(dev);
 	uc_plat->base = base;
 	uc_plat->max_lun = 1;
-	uc_plat->max_id = 2;
+	uc_plat->max_id = 1;
 
 	uc_priv = dev_get_uclass_priv(ahci_dev);
 	ret = ahci_init_one(uc_priv, dev);

Regards,
Evgeny Rogozhkin

Thanks for the update Evgeny, are you able to boot to QNX prompt with that change in place?

Regards,

kb

Hello!

The problem with the hanging startup is solved. Now "scsi scan" does not interfere with booting.
But it is still not possible to boot QNX.
Now I get an error when I run the SATA driver from the boot script. Exploring this new problem.

Regards,
Evgeny Rogozhkin