SK-AM62: Change the Flash Boot Mode from Octal SPI to 1S-1S-1S mode

Part Number: SK-AM62

Tool/software:

Hi Team,

I want to change the flash mode from Octal to 1S-1S-1S mode after the image is loaded from flash and before the kernal is started. 

I need this because, my driver (VxWorks VxBus XSPI Flash Driver) is expecting the flash to be in 1S-1S-1S mode for attaching. Since the Uboot is putting flash in Octal mode, the driver is not attaching.

Can you please suggest me how to do the changes and where it can be done?

Thanks and Regards,

Hamsa Lakshaman

  • Hi Team, Any Update on this?

  • Hi Hamsa,

    this got assigned to me. I'm currently on international business travel working at a customer site and not able to look into this further; will comment once I'm back in the office next week.

    Regards, Andreas

  • Hi ,

    This is a high priority issue and we are looking for a solution ASAP. Is it possible to reassign with someone who is available to help immediately?

    Thanks and Regards,

    Hamsa L

  • Hi Team,

    This is a high priority issue which is affecting our testing, Please help us resolve the issue ASAP.

    Please assign someone who is available immediately to help us.

    Thanks and Regards,

    Hamsa L

  • Hi Team,

    Any Update on this?

    Thanks and Regards,

    Hamsa Lakshmanan

  • I want to change the flash mode from Octal to 1S-1S-1S mode after the image is loaded from flash and before the kernal is started. 

    Try switching U-Boot to use 1-bit mode from the get-go, by updating the device tree section of your @ospi0 definitions (https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/arch/arm/dts/k3-am625-sk.dts?h=ti-u-boot-2024.04#n239) from 

    		spi-tx-bus-width = <8>;
    		spi-rx-bus-width = <8>;

    to

    		spi-tx-bus-width = <1>;
    		spi-rx-bus-width = <1>;

    Regards, Andreas

  • Hi ,

    I have tried the above by changing 

    spi-tx-bus-width = <8>;
    		spi-rx-bus-width = <8>;

    to

    		spi-tx-bus-width = <1>;
    		spi-rx-bus-width = <1>;

    If i do the above changes, the Uboot is failing to probe the flash and i am getting the following error:

    As I walked through the uboot code flow, i understand that the uboot is expecting the flash (s28HS) to be in octal mode for Read/Write operations and while probing, the flash is initialised to Octal mode. Code snippet as follows:

    My VxWorks Flash Driver is expecting the flash to be in 1S-1S-1S mode when it tries to attach. Hence, i want to put back the flash in 1S-1S-1S mode before the kernel image is booted (VxWorks Image).

    Kindly help me in this issue.

    Thanks and Regards, 

    Hamsa L

  • Let me try this out on my end and report back here.

    Regards, Andreas

  • Hi Hamsa,

    If i do the above changes, the Uboot is failing to probe the flash and i am getting the following error:

    first, I'm able to re-create the issue you are seeing.

    Before spending any effort looking at potential fixes, can you please confirm on your end that the "left-over state" of the OSPI peripheral module and/or OSPI flash device is really responsible for your VxWorks "attach" issues? For this you can boot U-Boot over UART for testing purposes (or SD card boot, since you are using the SK-AM62 board), so U-Boot (and ROM) never touch the OSPI peripheral. And then, see if you can start VxWorks.

    Regards, Andreas

  • Hi Andreas,

    We have tested with DFU method and UART method of flashing where we have loaded the images to RAM and booted the VxWorks image from RAM. In this scenario, VxWorks is able to attach the Flash Driver (vxbXspiFlash) and do the flash operations.

    Here, when the images are loaded into RAM, the uboot is not accessing the Flash. Hence the flash driver is attached when VxWorks image is loaded.

    Attaching some snaps for confirmation

    Boot commands used FYI:

     

    UART Bootmode, we are able to see the flash driver is attached as following:




    Thanks and Regards,
    Hamsa L
  • Hi Andreas,

    Any Update on this?

    Thanks in Advance

    Hamsa

  • Hi Andreas,

    Any Update on this?

  • Thanks for confirming the working scenario, that's a good starting point. I'm working on another urgent support case right now but I should be ablet to make time looking at this more closely early next week to see how we can potentially "downgrade" the ROM / U-Boot OSPI loading process.

    Regards, Andreas

  • Hi Andreas,

    Any Update on this? 

  • Hi,

    Any Update on this?

  • Hi, 

    Sorry I have marked resolved by mistake.

    Please take this query on priority as it is blocking our development. Request you to please look into this query.

  • Hi Andreas,

    Can u please look into this?

  • Hi Hamsa,

    thanks for your patience. I was finally able to free up some time and experiment with this, and got a working example that shows 1s-1s-1s boot on the SK-AM62B board. You should be able to adopt this solution per your needs / flash chip. Note that it is important to set the boot mode to 'SPI', so that 1-bit data access is used from the beginning.

    Here's the patch that enables this...

    a0797059@jiji:~/git/u-boot (ti-u-boot-2024.04)
    $ git show
    commit a6e74b25685504b1b12a9dbf761157b4852e2e1e (HEAD -> ti-u-boot-2024.04)
    Author: Andreas Dannenberg <dannenberg@ti.com>
    Date:   Thu Jan 30 16:49:04 2025 -0600
    
        ti: sk-am62b: Perform boot from OSPI using a single data line only
    
        Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
    
    diff --git a/arch/arm/dts/k3-am625-sk.dts b/arch/arm/dts/k3-am625-sk.dts
    index 5ca722aec43..5b8f632bbb1 100644
    --- a/arch/arm/dts/k3-am625-sk.dts
    +++ b/arch/arm/dts/k3-am625-sk.dts
    @@ -246,15 +246,14 @@
                    bootph-all;
                    compatible = "jedec,spi-nor";
                    reg = <0x0>;
    -               spi-tx-bus-width = <8>;
    -               spi-rx-bus-width = <8>;
    +               spi-tx-bus-width = <1>;
    +               spi-rx-bus-width = <1>;
                    spi-max-frequency = <25000000>;
                    cdns,tshsl-ns = <60>;
                    cdns,tsd2d-ns = <60>;
                    cdns,tchsh-ns = <60>;
                    cdns,tslch-ns = <60>;
                    cdns,read-delay = <4>;
    -               cdns,phy-mode;
    
                    partitions {
                            bootph-all;
    diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
    index 4e83b8c94c9..48cc58a1078 100644
    --- a/drivers/mtd/spi/spi-nor-ids.c
    +++ b/drivers/mtd/spi/spi-nor-ids.c
    @@ -382,7 +382,7 @@ const struct flash_info spi_nor_ids[] = {
     #ifdef CONFIG_SPI_FLASH_S28HX_T
            { INFO("s28hl512t",  0x345a1a,      0, 256 * 1024, 256, SPI_NOR_OCTAL_DTR_READ) },
            { INFO("s28hl01gt",  0x345a1b,      0, 256 * 1024, 512, SPI_NOR_OCTAL_DTR_READ) },
    -       { INFO("s28hs512t",  0x345b1a,      0, 256 * 1024, 256, SPI_NOR_OCTAL_DTR_READ) },
    +       { INFO("s28hs512t",  0x345b1a,      0, 256 * 1024, 256, 0) },
            { INFO("s28hs01gt",  0x345b1b,      0, 256 * 1024, 512, SPI_NOR_OCTAL_DTR_READ) },
            { INFO("s28hs02gt",  0x345b1c,      0, 256 * 1024, 1024, SPI_NOR_OCTAL_DTR_READ) },
     #endif
    

    ...and here is the associated boot log...

    # Manually set boot mode to SPI by programming CTRLMMR_MAIN_DEVSTAT
    => mw.l 0x43000030 0x1b
    => reset
    resetting ...
    
    U-Boot SPL 2024.04-00001-ga6e74b25685 (Jan 30 2025 - 16:50:13 -0600)
    SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
    SPL initial stack usage: 13392 bytes
    Trying to boot from SPI
    Authentication passed
    Authentication passed
    Authentication passed
    Authentication passed
    Authentication passed
    Starting ATF on ARM64 core...
    
    NOTICE:  BL31: v2.11.0(release):v2.11.0-906-g58b25570c9-dirty
    NOTICE:  BL31: Built : 04:20:32, Nov  1 2024
    
    U-Boot SPL 2024.04-00001-ga6e74b25685 (Jan 30 2025 - 16:50:22 -0600)
    SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
    SPL initial stack usage: 1904 bytes
    Trying to boot from SPI
    Authentication passed
    Authentication passed
    
    
    U-Boot 2024.04-00001-ga6e74b25685 (Jan 30 2025 - 16:50:22 -0600)
    
    SoC:   AM62X SR1.0 HS-FS
    Model: Texas Instruments AM625 SK
    EEPROM not available at 0x50, trying to read at 0x51
    Reading on-board EEPROM at 0x51 failed -121
    DRAM:  2 GiB
    Core:  81 devices, 31 uclasses, devicetree: separate
    MMC:   mmc@fa10000: 0, mmc@fa00000: 1
    Loading Environment from nowhere... OK
    In:    serial
    Out:   serial
    Err:   serial
    EEPROM not available at 0x50, trying to read at 0x51
    Net:   eth0: ethernet@8000000port@1
    Hit any key to stop autoboot:  0
    =>

    Regards, Andreas

  • Hi Andreas,

    I have tried the changes shared by you. I am booting from OSPI boot mode which is the preferred mode we want to operate in.

    I am getting the following error.

    Please suggest.

    Thanks and Regards,

    Hamsa L

  • I see you are using an older SDK baseline (9.2). My changes were developed & tested on top of U-Boot from our current SDK v10.1. Can you try to apply them to that U-Boot  and re-create what I did you you have a known-good baseline. If you must use the older SDK then back-porting changes could be step #2.

    Regards, Andreas

  • Hi Andreas,

    We are indeed using SDK 9.2 as u mentioned. That is because, the latest version is not compatible for booting VxWorks images. Hence we are required to use the 9.2 version only. 

    Kindly help us with the steps for changes in 9.2 version.

    Thanks and Regards,

    Hamsa Lakshmanan

  • That is because, the latest version is not compatible for booting VxWorks images.

    Please provide detailed background why this is not compatible.

    Regards, Andreas

  • Hi Andreas,

    please refer the below thread

    AM625: AM62 - Processors forum - Processors - TI E2E support forums

    Thanks and Regards

    Hamsa Lakshmanan

  • Hi Andreas,

    Please refer the below image. The VxWorks BSP supports this uboot version only .

    Thanks and Regards,

    Hamsa L