GPMC NOR boot on VAYU EVM

Prasad,

Prasad said:

1) Boot VAYU EVM with MLO (with pinmux and GPMC NOR init and read support) and uboot (with GPMC read/write support) from SD card.
2) At uboot, flash the above MLO and uboot to the NOR Flash.
3) Configure the SYSBOOT switches to NOR Boot.
4) Reset the Board.

With the above changes can I test NOR boot on VAYU EVM?

Yes, you can make this test.

Note that in DM814x (which is the catalog version of the automotive Jacinto5 DRA65x device), the u-boot for NOR has no MLO, only u-boot.bin (u-boot.img) is needed. U-boot min (MLO) is not required here as the NOR is XIP and hence the complete u-boot binary can be placed in the NOR flash. The u-boot.bin for NOR is built with ti8148_evm_config_nor, while the u-boot for MMC/SD is built with ti8148_evm_config_sd. So, when you build your u-boot for MMC/SD, you should also port it for NOR. See the below wiki page for more info:

We might have similar requirements in J6 NOR u-boot, as in J5 NOR u-boot, but this is officially not supported and tested.

Prasad said:

Should I change the configuration header in MLO?

If the ROM Code settings (clock configuration and GPMC registers values) are not good for NOR/XIP boot, you should program these settings through CH. Note that CH is optional and mainly use to configure the system for faster and more flexible booting. The ROM Code default settings can be tuned with CH.

Regards,
Pavel

Hi,

is the support planned for future releases?

Can you at least share, if something exists, preliminary patches or considerations in order to add such capability?

Thanks

Francesco Valla said:

is the support planned for future releases?

I am not aware of such plans.

Francesco Valla said:

Can you at least share, if something exists, preliminary patches

The latest patches are available at the below GIT repository

But I can not find NOR/XIP patches there.

Francesco Valla said:

or considerations in order to add such capability?

The considerations are already provided in this e2e thread. You might reuse the approach used in DM814x and AM335x devices, which support NOR.

Regards,
Pavel

Hi,

I finally managed to boot with u-boot 2016.05 from NOR, relocating the code to SRAM just after saving the boot parameters.

However, such solution does NOT exploits the speed boost offered by XIP execution, and this is a critical point in our implementation, that needs to boot in the shortest time possible.

During my debugging sessions, I identified two issues that prevents u-boot from booting in XIP mode:

1) IO isolation mode seems to work propery only from SRAM. In particular, an exception is fired when returning control on ISOCLKIN to hardware (@arch/arm/cpu/amv7/omap5/dra7xx_iodelay.c)

clrsetbits_le32((*prcm)->prm_io_pmctrl, PMCTRL_ISOCLK_OVERRIDE_MASK, PMCTRL_ISOCLK_NOT_OVERRIDE_CTRL);

if (!wait_on_value(PMCTRL_ISOCLK_STATUS_MASK,   0 << PMCTRL_ISOCLK_STATUS_SHIFT,   (u32 *)(*prcm)->prm_io_pmctrl, LDELAY)) <= HERE

return ERR_DEISOLATE_IO << isolate;

TRM in fact reports:

While the IOs are Isolated, code must execute only from internal RAM and the isolated IO interfaces should not be actively used.

So how can XIP and IO isolation be used together?

2) Trying to enter HYP mode (through the appropriate SMC instruction) also raises an exception, well before any isolation step (@arch/arm/cpu/armv7/omap-common/lowlevel_init.S)

ENTRY(switch_to_hypervisor)

/*
 * Switch to hypervisor mode
 */
	adr	r0, save_sp
	str	sp, [r0]
	adr	r1, restore_from_hyp
	ldr	r0, =0x102
	b	omap_smc1

[..]

ENTRY(omap_smc1)
	push	{r4-r12, lr}	@ save registers - ROM code may pollute
				@ our registers
	mov	r12, r0		@ Service
	mov	r0, r1		@ Argument

	dsb
	dmb
	smc	0		@ SMC #0 to enter monitor mode <= HERE
				@ call ROM Code API for the service requested
	pop	{r4-r12, pc}
ENDPROC(omap_smc1)

This is NOT documented in the TRM, or simply I didnt't find it?

Is this step mandatory for LPAE mode on Linux kernel?

Regards,

Ffrancesco Valla

Francesco Valla said:

So how can XIP and IO isolation be used together?

I do not think this is possible. GPMC pins are not accessible during IO isolation, thus no code can be executed from NOR/XIP attached to GPMC.

All pinmux or IODelay configurations (with the exception of MMC) need to occur in isolation mode. However, as described in the "Isolation Requirements" section of the DRA7x TRM: "when the IOs are isolated, code must execute only from internal RAM." This is because isolation mode impacts all IOs and the DDR will not be accessible. Therefore, isolation mode and pinmux configuration must be done at boot time (i.e. in the Linux MLO). Run-time pinmux changes in the kernel are not supported.

Regards,
Pavel

So we should assume that proper XIP boot from GPMC NOR is not possible?

Francesco Valla said:

So we should assume that proper XIP boot from GPMC NOR is not possible?

What makes you do such assumption?

Francesco Valla said:

Trying to enter HYP mode

Francesco Valla said:

This is NOT documented in the TRM, or simply I didnt't find it?

See DRA7x TRM, section 32.4.1 Hypervisor. As this belongs to the Cortex-A15 ARM code, more info should be available in the Cortex-A15 ARM TRM, available at arm.com


The below e2e threads also discuss hypervisor support:

Regards,
Pavel

Fabio Calabro said:

Automotive customer needs to use Linux and be responsive on CAN from Vehicle CPU (M4) within 50ms and full boot in 1.5 sec. Is this possible with 4-QSPI or eMMC. without doubt FastXIP with parallel NOR is the faster way to boot.
Can you provide some calculation and use cases covered with QSPI+eMMC boot.

We do not have calculations for DRA7x. These are planned for future releases of the PSDKLA:

You can get the latest DRA75x TI EVM and PSDKLA 3.1 and test/see boot time for QSPI and eMMC with the pre-built images.

See also the below wiki pages:

Fabio Calabro said:

If we can avoid IO isolation is something advise from you, so the question is: in what case it is mandatory?

In all the cases using IO isolation when pinmux is mandatory. I am just telling you for another option that is not recommended and at your own risk.

Regards,
Pavel