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.

AM3357: SPI NOR not recognized

Part Number: AM3357

Hello.

I have AM335x based board, and i'm doing linux bringup on it.

Until now I was able to bringup u-boot and run LInux from, while rootfs is sitting on pendrive. It sucessfully run.

For summary:

*  u-boot-spl and u-boot is on SPI FLASH, and board correctly start from it.

* Kernel, dtree, rootfs are on attached pendrive.

Now I'm trying to develop device tree, and run devices. 

The problem I see, is that with following devicetree:

/=================================================

// SPDX-License-Identifier: GPL-2.0-only
/*
* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
*/
/dts-v1/;

#include "am33xx.dtsi"
#include <dt-bindings/interrupt-controller/irq.h>

/

{
model = "Trumpf CMPC30";
compatible = "ti,am335x-evm", "ti,am33xx";

memory@80000000 {
device_type = "memory";
reg = <0x80000000 0x10000000>; /* 256 MB */
};

chosen {
stdout-path = &uart0;
};


leds_base {
pinctrl-names = "default";
pinctrl-0 = <&leds_cmpc30>;

compatible = "gpio-leds";

led0 {
label = "cmpc30:green:sysup";
gpios = <&gpio3 18 GPIO_ACTIVE_LOW>; /* gpio1_21 */
linux,default-trigger = "heartbeat";
default-state = "off";
};

led1 {
label = "cmpc30:red:c";
gpios = <&gpio2 22 GPIO_ACTIVE_LOW>; /* gpio2_0 */
default-state = "off";
};
led2 {
label = "cmpc30:yellow:d";
gpios = <&gpio2 23 GPIO_ACTIVE_LOW>; /* gpio1_21 */
default-state = "off";
};

led3 {
label = "cmpc30:green:e";
gpios = <&gpio2 24 GPIO_ACTIVE_LOW>; /* gpio2_0 */
default-state = "off";
};

led4 {
label = "cmpc30:green:f";
gpios = <&gpio2 25 GPIO_ACTIVE_LOW>; /* gpio2_0 */
default-state = "off";
};

};


};



&am33xx_pinmux {
pinctrl-names = "default";

uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
AM33XX_PADCONF(AM335X_PIN_UART0_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_UART0_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
>;
};


spi0_pins: pinmux_spi0_pins {
pinctrl-single,pins = <
AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_SPI0_D1, PIN_OUTPUT_PULLUP, MUX_MODE0)

>;
};

leds_cmpc30: pinmux_leds_cmpc30 {
pinctrl-single,pins = <
AM33XX_PADCONF(AM335X_PIN_MCASP0_ACLKR, PIN_OUTPUT, MUX_MODE7) /* UP_LED1 */
AM33XX_PADCONF(AM335X_PIN_LCD_VSYNC, PIN_OUTPUT, MUX_MODE7) /* GPMC_A23 */
AM33XX_PADCONF(AM335X_PIN_LCD_HSYNC, PIN_OUTPUT, MUX_MODE7) /* GPMC_A24 */
AM33XX_PADCONF(AM335X_PIN_LCD_PCLK, PIN_OUTPUT, MUX_MODE7) /* GPMC_A25 */
AM33XX_PADCONF(AM335X_PIN_LCD_AC_BIAS_EN, PIN_OUTPUT, MUX_MODE7) /* GPMC_A26 */

>;
};

};


&spi0 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins>;
cs-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>,
<&gpio0 6 GPIO_ACTIVE_HIGH>;
spi_nor: flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "spansion,s25fl128s0", "jedec,spi-nor";
spi-rx-bus-width = <1>;
spi-tx-bus-width = <1>;
spi-max-frequency = <6000000>;
reg = <0>;
m25p,fast-read;
partition@0 {
label = "u-boot-spl";
reg = <0x0 0x80000>;
read-only;
};
partition@1 {
label = "u-boot";
reg = <0x80000 0x100000>;
read-only;
};
partition@2 {
label = "u-boot-env";
reg = <0x180000 0x20000>;
read-only;
};
partition@3 {
label = "misc";
reg = <0x1A0000 0x660000>;
};
};

};


&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins>;

status = "okay";
};

&usb {
status = "okay";
};

&usb_ctrl_mod {
status = "okay";
};

&usb0_phy {
status = "okay";
};

&usb1_phy {
status = "okay";
};

&usb0 {
status = "okay";
};

&usb1 {
status = "okay";
dr_mode = "host";
};

&cppi41dma {
status = "okay";
};



&sham {
status = "okay";
};

&aes {
status = "okay";
};

//==================================================
I see following output in dmesg:

[ 1.299326] spi-nor spi0.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff

However, u-boot is able to probe this flash, perform flashing, and run from it.

My kernel comes from yocto, and it is:

branch ti-linux-5.4.y

commit 6f3bf13d53820fc12432d7052744be2ee046fc92 (HEAD -> ti-linux-5.4.y)
Merge: d2f658ed506d d5ef1ab82339
Author: LCPD Auto Merger <lcpd_integration@list.ti.com>
Date: Fri Apr 3 10:50:48 2020 -0500

and comes from https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/

Basing on fact that AM335x is able to run from SPI Flash I assume that there is no HW issue in flash connection.

Could you please help me with proper configuration of device tree so I can enable SPI flash ?

  • Hi ,

    Can you share the kernel device tree being used ? Can you confirm the SPI NOR part number ?

  • Hello.

    Device used is S25FL128S.

    Not sure what you mean by :

    Can you share the kernel device tree being used

    it is message body already, do you want me to send DTB instead ?

  • Hi Grzegorz,

    I thought it is otherway.

    1. Can you please share the uboot dts changes that you have done ?

    2. Do you have 2 slaves in SPI0 and chip selects of those slaves connected to gpio0_5 and gpio0_6 ? I see those pins already assigned to chip select of SPI0, so I believe below entry is not required

    cs-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>,
    <&gpio0 6 GPIO_ACTIVE_HIGH>;
    3. Have you probed the SPI lines ?
  • Hello, 

    Thank you for your help.

    I have made some changes to Kernel dt. 

    After changes to kernel dt, kernel probing message has changed:

    [ 1.298865] spi-nor spi0.0: unrecognized JEDEC id bytes: 00 00 00 00 00 00

    On second CS, there was another flash. But I removed it, to be sure that im talking to only one device. So, CS1 is connected to S25FL128S, and CS2 is not connected to any device.

    I have attached Oscilloscope, below I put screenshots of probing flash by kernel, during kernel startup.

    What is interesting from my point of view is that it looks like there is perfect communication between CPU and FLASH,

    1. Master sends RDID 9Fh

    2. Flash response with values exactly as in drivers/mtd/spi_nor/spi_nor.c:

    { "s25fl128s1", INFO6(0x012018, 0x4d0180, 64 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },

    on the bottom I paste also full dmesg. 

     

  • Grzegorz Heldt said:
    commit 6f3bf13d53820fc12432d7052744be2ee046fc92 (HEAD -> ti-linux-5.4.y)
    Merge: d2f658ed506d d5ef1ab82339
    Author: LCPD Auto Merger <lcpd_integration@list.ti.com>
    Date: Fri Apr 3 10:50:48 2020 -0500

    Looks like you are using our staging tree that is used to base our next iteration of SDKs on (v7.x+). While this may not necessarily be an issue especially for a device where support is rather mature like AM335x we only recommend and support the use of the current TI Linux SDK.

    http://www.ti.com/tool/PROCESSOR-SDK-AM335X

    These SDKs are regression-tested for a large variety of features. If you are building some kind of production system that's probably something you would want to take advantage of (beyond the SPI-related concern discussed here).

    Regards, Andreas

  • Thank you for your message.

    This is kernel version that comes from yocto

            https://git.yoctoproject.org/git/meta-ti

    on zeus branch, which I believe should be stable release, and maintained by TI ?.
     

    As im not user of SDK's and Composer studio, could you please provide a stable revision of kernel i should use ? which branch/ tag ?

  • Hi ,

    1. Just to understand, what was the change in kernel dt that made FF FF FF to 00 00 00 ? Is it removing cs-gpios ?

    2. SPI Mode seems to be 0 CPOL=0 CPHA=0. I believe would be seeing similar signals in uboot.

    Just to confirm, in the scope you see chip select to go low for all the transactions and once transaction is complete, it goes high ?

    Just to confirm:

    Yellow = chip select

    Blue/Cyan = MOSI

    Dark Blue = clock

    Purple = MISO

    I am checking the logs and dts you have shared and will revert back

  • Hello 

    Thank you for your support.

    1. It looks like the change was due to removing cs-gpios, however it I don't understand why.

    2. I will do same screenshots from u-boot sf probe, I put them below.

    You have recognised you have correctly. CS stays low for whole probe.

    During kernel startup, before the screenshots I've attached to previous post, there is also some period of CS low, but during this period there is no clock at all, so I omitted it.

  • Hello.

    I get partial success.

    I realised that actually SPI0 pinmuxes are already done by sitara bootloader.

    So I commented out SPI0 pinmux definitions. It gaves me following dmesg output:

    [ 1.299547] spi-nor spi0.0: s25fl128s1 (16384 Kbytes)
    [ 1.304763] 4 fixed-partitions partitions found on MTD device spi0.0
    [ 1.311333] Creating 4 MTD partitions on "spi0.0":
    [ 1.316183] 0x000000000000-0x000000080000 : "u-boot-spl"
    [ 1.328985] 0x000000080000-0x000000180000 : "u-boot"
    [ 1.348871] 0x000000180000-0x0000001a0000 : "u-boot-env"
    [ 1.368814] 0x0000001a0000-0x000000800000 : "misc"

    I'm attaching such dts to this post. 

    However i still don't understand what's wrong with previous dts. I would prefer to have SPI pinmux correctly defined in my dts.

    spi_flash_OK_commented_pinmux_am335x-cmpc30.zip

  • Hi ,

    Good that you could make progress.

    Infact pinmux being wrong is the only theory I could make. That too on MISO(I believe it is SPI_D0), because command in MOSI goes out. Ofcourse clock is there for the reply in MISO and chip select is proper, if not set correctly then there won't be any communication from the slave(Flash also responding). So it all boils down to MISO(SPI_D0) either pinmux or direction in SPI register could be wrong. Now that you have commented out pinmux, it points even further to pinmux. But what could be the issue in the pinmux, I need to check ?

    I understand SPI_D0 to be MISO and SPI_D1 to be MOSI. Is this understanding correct ? Because if SPI_D1 is MISO and SPI_D0 is MOSI, then you would need to add "ti,pindir-d0-out-d1-in" in the device tree in kernel.

    Can you also try below pinmux, which I see in many other SPI configs in other device trees in kernel source:

    AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_INPUT_PULLUP, MUX_MODE0)
    AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_INPUT_PULLUP, MUX_MODE0)
    AM33XX_PADCONF(AM335X_PIN_SPI0_D1, PIN_INPUT_PULLUP, MUX_MODE0)
    AM33XX_PADCONF(AM335X_PIN_SPI0_CS0, PIN_INPUT_PULLUP, MUX_MODE0)
    AM33XX_PADCONF(AM335X_PIN_SPI0_CS1, PIN_INPUT_PULLUP, MUX_MODE0)

    You can also devmem2(If not already available in target, then you can cross compile  source : https://github.com/hackndev/tools/blob/master/devmem2.c) and dump the pinmux registers in userspace as below.

    Below is for pinmux values of conf_spi0_sclk

    # devmem2 0x44E10950

    Below is for pinmux values of conf_spi0_d0

    # devmem2 0x44E10954

    Below is for pinmux values of conf_spi0_d1

    # devmem2 0x44E10958

    Below is for pinmux values of conf_spi0_CS0

    # devmem2 0x44E1095C

    Below is for pinmux values of conf_spi0_CS1

    # devmem2 0x44E10960

    You can also check the values of above registers in uboot. Stop autoboot and try below commands and compare it with kernel:

    # md 44E10960

  • Provided dts fragment resolved my issue.

    Actually I tried such pinmux earlier, how ever it doesn't work for me. Now I found that i wasn't working together with:

    cs-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
    Correct way is one of:
    AM33XX_PADCONF(AM335X_PIN_SPI0_CS0, PIN_INPUT_PULLUP, MUX_MODE0)
    ...
    or 
    AM33XX_PADCONF(AM335X_PIN_SPI0_CS0, PIN_INPUT_PULLUP, MUX_MODE7)
    together with 
    cs-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
    Thank you for your help.
  • Hi ,

    Glad to know that you solved the issue. All the best to you!