PROCESSOR-SDK-AM335X: Unable to boot via SPI NOR

Muktabh Anchlia said:

U-Boot SPL 2020.10-rc5-00029-g686882937c-dirty (Feb 07 2023 - 13:25:32 +0100)
Trying to boot from SPI
Invalid bus 0 (err=-19)
SPI probe failed.

It looks the MLO is loaded by RBL from SPI, and SPL starts to run, and somehow fails to probe SPI when trying to load the next stage u-boot/dtbs from SPI.
On AM335x EVM:
=> sf probe 0
SF: Detected w25q64cv with page size 256 Bytes, erase size 4 KiB, total 8 MiB

I'd think <am335x_evm_spiboot_defconfig> would be a good reference...
Best,
-Hong

Hi HOng,

we have tried to get our config as close to the evm_spi_defconfig, but tht has not resolved the issue unfortunately.

Hello,
Some general pointers:
- check u-boot tree on the same SPI device support.
- add "debug" in SPI driver in SPL/u-boot
- use JTAG debugger if accessible on your board.
Best,
-Hong

Hello Hong,

I added a bit more logging and updated by defconfig to match the evm_spi boot as much as I could. I see the following log now:

=> CCCCCCCC
<debug_uart>
spl_early_init
uclass_resolve_seq
uclass_find_device_by_seq
frs:0 bn:-1
uclass_find_device_by_seq
frs:0 bn:0
  - -1 -1 'root_driver'
  - not found
SPL malloc() before relocation used 0x6c bytes (0 KB)
>>SPL: board_init_r()
spl_init
uclass_resolve_seq
uclass_find_device_by_seq
frs:0 bn:0
  - 0 -1 'serial@44e09000'
  - not found

U-Boot SPL 2020.10-rc5-00029-g686882937c-dirty (Feb 08 2023 - 22:16:39 +0100)
Trying to boot from SPI
spl_load_image
spl_spi_load_image
spi_flash_probe
spi_flash_probe_bus_cs: bn:0, cs:0, m:3
uclass_get_device_by_seq
uclass_find_device_by_seq
frs:0 bn:0
  - not found
uclass_find_device_by_seq
frs:1 bn:0
  - not found
Invalid bus 0 (err=-19)
SPI probe failed.
 BUS   : 0
 CS    : 0
 SPEED : 24000000
 MODE  : 3
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Does this imply SPL is not reading the DTS properly and not finding any devices on SPI bus? I understand at this point, SPL is just parsing the DTS and trying to get the device list rather than probing the hardware.

Thanks

Hello,
Here is an early e2e for your reference, where <Spansion s25fl216k> was used.
e2e.ti.com/.../3762105
Best,
-Hong

Hi Hong,

I have gone through almost all posts on the forum to see something similar, but in most cases the problem is resolved after the correct config, which unfortunately hasn't worked for us.

Also, one thing we observed is that once ROM selected the NOR, the chip select line and other lines are never accessed. It seems SPL is not even trying to talk to the NOR. This ties in a bit to my above comment where I mentioned that may be SPL is not getting the device information correctly. Unfortunately, the SDK also does not have any DTS where SPI0 is being used to boot. Do you have a suggestion there?

Regards

Hello,
From your originl log, SPL is booted by RBL from SPI-NOR, right?
The e2e reference in my last reply was using <Spansion s25fl216k>.
I thought "compatible = "spansion,s25fl512s", "jedec,spi-nor";" is on your board?
Best,
-Hong

Hi Hong,

I made some progress. I had to add u-boot,dm-spl to the SPI0 and spi_nor@0 block for the above error to go away. But now I have a different error.

The u-boot version we are using is not as new as in the 8.3 SDK, but I understand boot from SPI is a supported feature from before that. So I don't want to upgrade u-boot for the time being.

If you have a working dts, that would be very helpful. I will keep debugging in the meantime.

Regards

Hi Hong,

After adding SPI MTD support in config, I can see the SPL probing the NOR now, but I get this error:

unrecognized JEDEC id bytes: ff, ff, ff
spi_get_bus_and_cs: Error -2 in device probe.
spi_get_bus_and_cs: Error path, created=0, device 'spiflash@0'
SPI probe failed.

It looks like I may be missing some hardware config to enable the NOR. In my board .c, I enable the following during SPL:

Is there anything else I should enable here?

Thanks and Regards

Hello,
It is good news on your progress on enabling SPI-NOR on your platform.
From your original log, SPL is booted by RBL from SPI-NOR, right?
=> pinmux on SPI-NOR on your board works?
Best,
-Hong

Hi Hong,

Yes, RBL boots via SPI-NOR, but SPL is not able to boot u-boot via SPI-NOR. I have set up the pinmux as I posted above. Do I need to do anything else? Is there a clock to be enabled specifically for SPI?

Regards

Hi Hong,

I changed the d0,d1 pin direction setting in my DTS and it fixed the issue. The pins were being swapped in SPL, so the command was sent to the NOR on its output line.

Now, I am getting this error:

U-Boot SPL 2020.10-rc5-00038-g171693d9c0-dirty (Feb 14 2023 - 15:43:23 +0100)

> > Trying to boot from SPI

> > No valid device tree binary found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb>

> > initcall sequence 8083e124 failed at call 80836db9 (err=-1)

> > ### ERROR ### Please RESET the board ###


Just to confirm, this error is from the SPL not finding the u-boot DTS correct? 

I used the following commands in u-boot to program the NOR when booted via NAND:

> sf probe 0; sf erase 0 +80000;tftp MLO.byteswap

> setenv filesize 0xMLOSize

> sf write ${loadaddr} 0 ${filesize}; tftp u-boot.img

> setenv filesize 0xubootimgSize

> sf write ${loadaddr} 0x20000 ${filesize}

As I understand, u-boot.img already has the DTB appended at the end. 
I use the CONFIG_OF_SEPARATE setting, and have set the SPL u-boot payload as u-boot.img and CONFIG_SYS_SPI_U_BOOT_OFFS=0x20000
in the .config file.

Why is it not finding the DTB?

Regards

Hello,
I'd recommend to add "DEBUG" print, or use JTAG debugger if accessible to sort it out...
Best,
-Hong

Hi Hong,

I was able to boot by setting the DTS to CONFIG_OF_EMBED rather than CONFIG_OF_SEPARATE. and disabling support for FIT image.  It works, but looks more like a hack as this option is not recommended.

Not sure why the default tools and settings are not providing a working config.

My NAND u-boot is using FIT image and CONFIG_OF_SEPARATE options and seems to be OK.

Regards

Muktabh