AM6442: Linux SDK QSPI flash layout and u-boot UG updates

All,

booting up Linux on the AM64xx board it shows this:

[ 2.154203] Creating 7 MTD partitions on "fc40000.spi.0":
[ 2.159603] 0x000000000000-0x000000080000 : "ospi.tiboot3"
[ 2.166348] 0x000000080000-0x000000280000 : "ospi.tispl"
[ 2.172903] 0x000000280000-0x000000680000 : "ospi.u-boot"
[ 2.179506] 0x000000680000-0x0000006c0000 : "ospi.env"
[ 2.185822] 0x0000006c0000-0x000000700000 : "ospi.env.backup"
[ 2.192758] 0x000000800000-0x000003fc0000 : "ospi.rootfs"
[ 2.199281] 0x000003fc0000-0x000004000000 : "ospi.phypattern"

So I am assuming the QSPI flashing will be just like on the AM654x, except we are now building the sysfw into the tiboot3.bin (SPL R5), so the tiboot3.bin will be bigger and the sysfw does not have to be flashed seperately.

Please correct me if the assumption is wrong.

Regards,

--Gunter

All,

I flashed the prebuilt binaries from Linux SDK 8.0, that is tiboot3.bin, tispl.bin, u-boot.img into the QSPI flash of the AM64xx EVM, using u-boot commands as described in

https://software-dl.ti.com/processor-sdk-linux/esd/docs/08_00_00_21/linux/Foundational_Components/U-Boot/UG-QSPI.html

Then using the SW2 and SW3 switch settings for QSPI boot

SW2[1:8] = 11010000

SW3[1:8] = 00000000

But nothing is coming out of the Console UART.

Is there something I am missing?

Is the QSPI boot switch setting correct?

Thanks!

--Gunter

Here is the exact sequence from u-boot command line

=> sf probe
WARN: Unable to get temperature. Assuming room temperature
SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
=> tftp $loadaddr tiboot3.bin
link up on port 1, speed 1000, full duplex
Using ethernet@8000000 device
TFTP from server 192.168.1.20; our IP address is 192.168.1.28
Filename 'tiboot3.bin'.
Load address: 0x82000000
Loading: #################################################################
############
3.2 MiB/s
done
Bytes transferred = 390826 (5f6aa hex)
=> sf update $loadaddr 0x0 $filesize
device 0 offset 0x0, size 0x5f6aa
390826 bytes written, 0 bytes skipped in 2.744s, speed 145688 B/s
=> tftp $loadaddr tispl.bin
link up on port 1, speed 1000, full duplex
Using ethernet@8000000 device
TFTP from server 192.168.1.20; our IP address is 192.168.1.28
Filename 'tispl.bin'.
Load address: 0x82000000
Loading: #################################################################
#################################################################
########
3.3 MiB/s
done
Bytes transferred = 704484 (abfe4 hex)
=> sf update $loadaddr 0x80000 $filesize
device 0 offset 0x80000, size 0xabfe4
704484 bytes written, 0 bytes skipped in 4.105s, speed 175606 B/s
=> tftp $loadaddr u-boot.img
link up on port 1, speed 1000, full duplex
Using ethernet@8000000 device
TFTP from server 192.168.1.20; our IP address is 192.168.1.28
Filename 'u-boot.img'.
Load address: 0x82000000
Loading: #################################################################
#################################################################
################################
3.2 MiB/s
done
Bytes transferred = 824412 (c945c hex)
=> sf update $loadaddr 0x280000 $filesize
device 0 offset 0x280000, size 0xc945c
824412 bytes written, 0 bytes skipped in 5.355s, speed 157558 B/s
=>

(For this test I am actually using SDK 7.3 u-boot and binaries, as I had seen some u-boot ethernet issues in SDK 8.0 ...)

Still there is no output on the console when trying to boot from QSPI.

Regards,

--Gunter

Hi Gunter,
Have we tried SW2[1:8] = 11011000?
Best,
-Hong

Hi Hong,

yes I tried that switch setting as well, and there is no console output. 

Can you test it on your side?

Thanks,

--Gunter

Hi Gunter,
Yes, I tested OSPI flashing/booting on AM64x GP EVM.
e2e.ti.com/.../3769546
Best,
-Hong

Great, Hong that you tested this and I need to carefully read through your post.

Was your suggested Switch setting the correct one to use for OSPI/QSPI boot?

I tried to go back and reflash the board as I did not completely trust the Flash content anymore, but booting with SDCARD to u-boot and trying to probe the flash I am getting this:

=> sf probe
unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 0:0 (error -2)

This may not be easy to recover from, never saw this before. Did I break the flash somehow? Maybe erase something for JEDEC? How can I recover from this?

Thanks!

--Gunter

Hi Hong,

due to the AM64x GP EVM Flash issue above, I have moved to the AM64x SK EVM. With this I can duplicate exactly what you are seeing, that is we can do a SPI boot with the OSPI and boot up to a u-boot prompt.

The switch setting is reversed on the SK Starter Kit, as you can see here https://www.ti.com/lit/ug/spruiy9a/spruiy9a.pdf on page 18.

The working SPI bootmode is

SW3[1:8] = 00000000    SW2[1:8] = 00011011

The primary bootmode is SPI (not OSPI)

The backup bootmode is NONE.

BTW, the OSPI bootmode is not coming up with nothing on the console.

This is what I am getting:

U-Boot SPL 2020.01-ge995ed0ec1 (May 28 2021 - 16:20:13 +0000)
EEPROM not available at 80, trying to read at 81
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.1.1--v2021.01a (Terrific Lla')
SPL initial stack usage: 13396 bytes
Trying to boot from SPI
WARN: Unable to get temperature. Assuming room temperature
Starting ATF on ARM64 core...

NOTICE: BL31: v2.4(release):2021.00.003-dirty
NOTICE: BL31: Built : 14:41:43, May 28 2021

U-Boot SPL 2020.01-ge995ed0ec1 (May 28 2021 - 14:48:57 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.1.1--v2021.01a (Terrific Lla')
Trying to boot from SPI
WARN: Unable to get temperature. Assuming room temperature

U-Boot 2020.01-ge995ed0ec1 (May 28 2021 - 14:48:57 +0000)

SoC: AM64X SR1.0
Model: Texas Instruments AM642 SK
Board: AM64-SKEVM rev E2
DRAM: 2 GiB
MMC: sdhci@fa00000: 1
Loading Environment from FAT... In: serial@2800000
Out: serial@2800000
Err: serial@2800000
Net:
Warning: ethernet@8000000 using MAC address from ROM
eth0: ethernet@8000000
Hit any key to stop autoboot: 0
=>

Regards,

--Gunter

Hi Hong,

therefore we need to figure out why we can boot the OSPI Flash only in "SPI bootmode", but not in "OSPI bootmode".

Regards,

--Gunter