This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM5728: QSPI-4 boot issue

Part Number: AM5728
Other Parts Discussed in Thread: BEAGLEBOARD-X15, PMP

Tool/software: Linux

We are developing a product based on the AM5728 EVM.  We are trying to get u-boot to run from FLASH.  We are using an ISSI is25lq016 connected to the QSPI-4 of the processor.

The product boots from from SD card and we are using the same image to program the FLASH part.

We can get SPL to load and display, but it stops at that point.  I suspect we may be using the wrong location in FLASH for the main u-boot image.

Following the instructions at:

http://processors.wiki.ti.com/index.php/Linux_Core_U-Boot_User%27s_Guide#Booting_from_QSPI_from_u-boot

The following process is used to load the FLASH part:

sf probe

sf erase 0 0x200000

load mmc 0 0x82000000 /boot/MLO

sf write 0x82000000 0x00000 0x20000

load mmc 0 0x82000000 /boot/u-boot.img

sf write 0x82000000 0x40000 0xBA000

The part is successfully programmed and when we attempt to boot we see the SPL start:

U-Boot SPL 2017.01-00020-g986edbf-dirty (Oct 19 2017 - 15:22:08)
DRA752-GP ES2.0
Trying to boot from SPISF: Macronix/ISSI check SR Quad bit
SF: Macronix/ISSI SR Quad bit set
** Bad device mmc 0 **
Using default environment

but then nothing.

Here is a snap shot of the programming sequence:

=> sf probe
SF: Macronix/ISSI check SR Quad bit
SF: Macronix/ISSI SR Quad bit set
SF: Detected is25lq016 with page size 256 Bytes, erase size 64 KiB, total 2 MiB, mapped at 5c000000
=> sf erase 0 0x200000
SF: 2097152 bytes @ 0x0 Erased: OK
=> load mmc 0 0x82000000 /boot/MLO
105736 bytes read in 28 ms (3.6 MiB/s)
=> sf write 0x82000000 0x00000 0x20
device 0 offset 0x0, size 0x20
SF: 32 bytes @ 0x0 Written: OK
=> load mmc 0 0x82000000 /boot/u-boot.img
751784 bytes read in 62 ms (11.6 MiB/s)
=> sf write 0x82000000 0x40000 0xBA000
device 0 offset 0x40000, size 0xba000
SF: 761856 bytes @ 0x40000 Written: OK

MLO and u-boot.img are copies of the MLO and u-boot.img that we can boot successfully with on the SD card.

Successful SD card boot looks like:

U-Boot SPL 2017.01-00020-g986edbf-dirty (Oct 19 2017 - 15:22:08)
DRA752-GP ES2.0
Trying to boot from MMC1
** Unable to use mmc 0:1 for loading the env **
Using default environment

U-Boot 2017.01-00020-g986edbf-dirty (Oct 19 2017 - 15:22:08 -0400)

CPU : DRA752-GP ES2.0
Model: TI AM5728 BeagleBoard-X15
Board: AM572x EVM REV
DRAM: 2 GiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1

** Unable to use mmc 0:1 for loading the env **
Using default environment

Reset USB hubs
Setup USB hubs
Reset PCIe 1
FLASH status register: 0x00000040 ret: 0
FLASH JEDEC: 0x0040159d ret: 0
Display setup
SCSI: SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
Found 0 device(s).
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw
Press SPACE to abort autoboot in 2 seconds
=> 

Any suggestions would be greatly appreciated.  Thanks in advance!

  • The software team have been notified. They will respond here.
  • Thanks for the references, but they are not of much help.

    The core QSPI users guide is about the kernel, not u-boot so I didn't find anything useful there.

    The best I could fine in the help article seems to confirm that I have the setup I think is required, specifically the information from QSPI boot development mode appears to confirm that I'm flashing the part as required.

    I can only suspect based on what I'm reading is there is possibly a problem with my device tree. Specifically what does the error "** Bad device mmc 0 **" mean  reported by the SPL?  Here is my boot failure:

    U-Boot SPL 2017.01-00020-g986edbf-dirty (Oct 19 2017 - 15:22:08)
    DRA752-GP ES2.0
    Trying to boot from SPISF: Macronix/ISSI check SR Quad bit
    SF: Macronix/ISSI SR Quad bit set
    ** Bad device mmc 0 **
    Using default environment

    What sets up the "mmc" device for the SPL?  I'm confused by this as the MMC is associated with the SD card, not the QSPI.  Here is the device tree I'm using:

    &qspi {
    status = "okay";
    /* spi-max-frequency = <76800000>; */
    spi-max-frequency = <12000000>;
    /* spi-max-frequency = <1000000>; */
    is25lq016@0 {
    /* cgw compatible = "s25fl256s1", "spi-flash", "jedec,spi-nor"; */
    /* cgw part is is25q016 on production card */
    compatible = "issi,is25lq016", "spi-flash", "jedec,spi-nor";
    /* spi-max-frequency = <76800000>; */
          spi-max-frequency = <12000000>;
    /* spi-max-frequency = <1000000>; */
    /* We need mode 3 because we are missing rt clock line */  
    spi-cpol;
    spi-cpha;
    reg = <0>;
    spi-tx-bus-width = <1>; 
    spi-rx-bus-width = <4>;  
    #address-cells = <1>;
    #size-cells = <1>;
    /* MTD partition table.
    * The ROM checks the first four physical blocks
    * for a valid file to boot and the flash here is
    * 64KiB block size.
    */
    partition@0 {
    label = "QSPI.SPL";
    reg = <0x00000000 0x000040000>;
    };
    partition@1 {
    label = "QSPI.u-boot";
    reg = <0x00040000 0x00100000>;
    };
    partition@2 {
    label = "QSPI.u-boot-spl-os";
    reg = <0x00140000 0x00080000>;
    };
    partition@3 {
    label = "QSPI.u-boot-env";
    reg = <0x001c0000 0x00010000>;
    };
    partition@4 {
    label = "QSPI.u-boot-env.backup1";
    reg = <0x001d0000 0x0010000>;
    };
    partition@5 {
    label = "QSPI.kernel";
    reg = <0x001e0000 0x0800000>;
    };
    partition@6 {
    label = "QSPI.file-system";
    reg = <0x009e0000 0x01620000>;
    };
    };
    };
    The entry in spi_flash_ids.c:

    #ifdef CONFIG_SPI_FLASH_ISSI /* ISSI */
    {"is25lq08", INFO(0x9d4014, 0x0, 64 * 1024, 16, 0) },
    {"is25lq016", INFO(0x9d4015, 0x0, 64 * 1024, 32, 0) },
    {"is25lp032", INFO(0x9d6016, 0x0, 64 * 1024, 64, 0) },
    {"is25lp064", INFO(0x9d6017, 0x0, 64 * 1024, 128, 0) },
    {"is25lp128", INFO(0x9d6018, 0x0, 64 * 1024, 256, 0) },
    #endif

    I'm confident u-boot is located at the appropriate location based on what I've read, here again is the write command I use:

    => load mmc 0 0x82000000 /boot/u-boot.img
    751784 bytes read in 62 ms (11.6 MiB/s)
    => sf write 0x82000000 0x40000 0xBA000
    device 0 offset 0x40000, size 0xba000
    SF: 761856 bytes @ 0x40000 Written: OK

    Which corresponds to:

    partition@1 {
    label = "QSPI.u-boot";
    reg = <0x00040000 0x00100000>;
    };
    in the device tree.
    Any other suggestions?
  • Chris,

    According to the Linux Core U-Boot user guide, AM57x device support only SD and UART boot. You can try porting QSPI boot support in AM572x u-boot from the DRA75x/74x u-boot.

    Check also AM572x Silicon errata advisories:

    i851: QSPI Redundant SBL Feature Sector Size Mismatch With Flash
    i855: QSPI Mode0/1/2 Not Functional and Mode3 Limited to 48MHz
    i861: QSPI-4 Boot Mode Is Not Functional

    See also below e2e thread:

    e2e.ti.com/.../527255
  • So how does the TI AM5728 IDK work then?  Are you saying it can't support Linux u-boot?

    Refer to page 7 of the IDK schematics.  It has a S25FL256S connected for QSPI 4 operation.

    We are following this design, though we use a different memory part.  The SPL is coming up so we know that the initial boot does work.

    As for the erratta items:

    i861 only applies to Silicon rev 1.0, we are using 2.0.  Please refer to a previous discussion on this we had with TI last spring: https://e2e.ti.com/support/arm/sitara_arm/f/791/t/591831

    i855 we are following the restriction and it does work as the SPL comes up as well as we are able to FLASH and confirm data is succesful with the part.

    i851 we are not using the redundant SPL feature, we just have flashed a single SPL (MLO) and a single u-boot.img to the part.

  • Furthermore, here is a thread that claims to have a working AM5728 QSPI u-boot.

    e2e.ti.com/.../615123

    Likewise, the boot media configuration in u-boot make menuconfig has a selection for "Support for booting from QSPI"

    │ │ [ ] Support for booting from NAND flash │ │
    │ │ [ ] Support for booting from ONENAND │ │
    │ │ [*] Support for booting from QSPI flash │ │
    │ │ [ ] Support for booting from SATA │ │
    │ │ [*] Support for booting from SD/EMMC │ │
    │ │ [ ] Support for booting from SPI flash

    this is from ti-processor-sdk-linux-am57xx-evm-04.00.00.04. Why would this entry be here if it isn't supported?
  • A further discussion, in which you participated, also utilizing QSPI u-boot on the AM5728:

    e2e.ti.com/.../2158026

    To clarify, we are not trying to boot the kernel from QSPI, only u-boot. The kernel and rootfs are going to be booted from the SD.
  • Chris Welch66 said:

    So how does the TI AM5728 IDK work then?  Are you saying it can't support Linux u-boot?

    Refer to page 7 of the IDK schematics.  It has a S25FL256S connected for QSPI 4 operation.

    We are following this design, though we use a different memory part.  The SPL is coming up so we know that the initial boot does work.

    AM572x IDK has QSPI flash (S25FL256S), but by default it can be used only for data storage, not for booting.

    I am NOT saying that you can not boot from QSPI flash at all, I am saying that the default u-boot source do not support this and should be modified. You can take the DRA75x u-boot code base as reference, start with comparing QSPI support between am57xx_evm_defconfig and dra7xx_evm_defconfig files. Make sure you have QSPI_BOOT instead of ENV_IS_IN_MMC.

    Can you enable debug prints in QSPI u-boot driver (u-boot/drivers/spi/ti_qspi.c) and share the log. Please enable debug() messages in u-boot to get more prints and see how your flow goes:

    When booting MLO/SPL from QSPI, remove SD card first, thus you will be sure that you are really booting MLO/SPL from QSPI.

    Note also that MLO/SPL execute from internal OCMC RAM, while u-boot execute from external DDR3 memory. Have you verified your DDR3 memory is correct?

    Chris Welch66 said:
    only applies to Silicon rev 1.0, we are using 2.0.  Please refer to a previous discussion on this we had with TI last spring: https://e2e.ti.com/support/arm/sitara_arm/f/791/t/591831

    OK

    Chris Welch66 said:
    i855 we are following the restriction and it does work as the SPL comes up as well as we are able to FLASH and confirm data is succesful with the part.

    OK

    Chris Welch66 said:
    i851 we are not using the redundant SPL feature, we just have flashed a single SPL (MLO) and a single u-boot.img to the part.

    OK

    Regards,
    Pavel

  • To those who come to this looking at a similar problem:

    1) QSPI Linux boot does work and has been done.  Refer to the previous links I provided in this thread on Oct 27th you'll find other examples.  Use the u-boot configuration menu and you'll find a QSPI boot mode.  Ensure your SYS boot straps are setup for QSPI boot operation.  The PROM boot loader does work for both QSPI-1 and QSPI-4.

    2) The problem is QSPI-1 vs QSPI-4.  QSPI-1 works but QSPI-4 only partially works for u-boot loading. 

    The PROM boot QSPI-4 loader  works, which is why we get a successful MLO launch, however, the TI u-boot code, ti_qspi.c doesn't work for QSPI-4. When MLO loads the u-boot.img data it is garbage and fails.  You can diagnose this using the uboot sf commands.  We are following the TI AM5728 IDK EVM design for the QSPI-4 wiring except we use a different FLASH part.  The hardware is working because the PROM QSPI-4 loader successfully launches the MLO part of u-boot using QSPI-4.  So the problem is with the u-boot code.

    We have decided to stick with QSPI-1 as the boot time difference is minimal for us.

    3) Should you want to get QSPI-4 working, keep in mind the existing u-boot materials only support QSPI-1 for writing and QSPI-4 for reading.  This can be confusing.  You'll need to determine why ti_qspi.c doesn't work for QSPI-4 operation and you should be good to go.    The problem doesn't seem to be in the SF code as it works for QSPI-4 operation with other SPI drivers. There are two examples in the code.

  • For those wondering about Pavel stating that Linux QSPI loading u-boot is not supported, here is the u-boot patch that was released by TI providing the QSPI support along with the u-boot layout definitions:

    lists.denx.de/.../262257.html