Registering the Map Driver in Linux for S70GL02GS.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
SrWu_4394436
Level 3
Level 3
First like received First like given

Dear All,

We have interfaced NOR flash (part number :S70GL02GS) to processor is AM3352 via GPMC interface.

In old kernel V3.20, physmap_flash_driver is also being registered using platform_driver_register() and hence physmap_flash_probe() is being called.  This is done as below:

We have below MTD partiton table.  Member "name" platform_device is mapped to the "drivers/mtd/maps/physmap.c" structure.

In board specific file they have below

static struct physmap_flash_data norflash_data = {

.width = 2,

.parts = nor_partitions,

.nr_parts = ARRAY_SIZE(nor_partitions),

};

static struct platform_device norflash = {

.name = "physmap-flash",

.id = 0,

.dev = {

.platform_data = &norflash_data,

},

.num_resources = 1,

.resource = &norflash_resource,

};

static struct mtd_partition nor_partitions[] = {

{

.name = "uboot",

.offset = 0,

.size = 4 * SZ_128K,

},

}

In "drivers/mtd/maps/physmap.c"

static struct platform_device physmap_flash = {

        .name           = "physmap-flash",

        .id             = 0,

        .dev            = {

                .platform_data  = &physmap_flash_data,

        },

        .num_resources  = 1,

        .resource       = &physmap_flash_resource,

};

How to achieve the same functionality in New Kernel Version 4.14 using DTS functionality? Or In DTS file, how this mapping to be done for S70GL02GS?

I have tried below options:

&gpmc {

            compatible = "ti,am3352-gpmc";

            ti,hwmods = "gpmc";

            status = "okay";

            nor@0,0 {

                    reg = <0 0x00000000 0x10000000>;

linux,mtd-name = "physmap-flash.0";

linux,mtd-name = "physmap-flash";

            }

}

Till now your support has been great.  Thank you for that.  Please let me know if you have any input on this.

Regards

Srinivasa

0 Likes
26 Replies
GernotH_31
Employee
Employee
First like received

Hi Srinivasa,

the physmap driver needs a physical base address and memory window size. These parameters can be passed either via the device tree, or compiled directly into the driver. To compile it directly into the driver you can configure the parameters in the kernel configuration menu  (physmap section). That might be the easiest way.

Of course, your board driver needs to set up the pads of the processor (SoC), clocks, ... appropriately for it to work.

You probably will have to instrument the code (adding printk statements) and also attache a logic analyzer to further debug the situation.

Best regards,

Gernot

0 Likes

Hi Gernot,

Our physmap driver is gpmc driver,  driver probe function "gpmc_probe()" is also being called.  This is our pysmap driver whcih is registered as below:

static struct platform_driver gpmc_driver = {

        .probe          = gpmc_probe,

        .remove         = gpmc_remove,

        .driver         = {

                .name   = DEVICE_NAME,

                .of_match_table = of_match_ptr(gpmc_dt_ids),

                .pm     = &gpmc_pm_ops,

        },

};

static __init int gpmc_init(void)

{

        printk("\n\n\nSrini debug @ line %d in function %s in file %s\n\n\n",__LINE__, __FUNCTION__, __FILE__);

        return platform_driver_register(&gpmc_driver);

}

Here base address and memory window size is being allocated using gpmc_mem_init() function.  I am suspecting it is taking from bootloader because DTS file is being parsed after gpmc_mem_init().

Next Suggestion

Since my base address is 0x10000000 and flash size is 256 MB (0x10000000), I have tried below option,

but it is ending up in Kernel panic.  Debugging on it...

If you find any fault below, please let me know.

pastedImage_14.png

Of course board driver has all ther parameters (like clock and other information set..).

I have made sure that there are no errors in GPMC driver (using prink statments) and Kernel log is free of any errors.

I have posted my queries on TI e2e forum

https://e2e.ti.com/support/processors/f/791/p/834972/3122926#3122926

AM3352: NOR flash issues in kernel - Processors forum - Processors - TI E2E support forums

Regards

Srinivasa

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Gernot,

As per your input/suggestions, I have enabled below options in kernel configurations.  Now I am able to enter physmap_flash_probe() and below statement is printed.

[    1.560353] physmap platform flash device: 10000000 at 10000000

CONFIG_MTD_PHYSMAP_COMPAT=y

CONFIG_MTD_PHYSMAP_START=0x10000000

CONFIG_MTD_PHYSMAP_LEN=0x10000000

CONFIG_MTD_PHYSMAP_BANKWIDTH=2

However, I have kernel panic on this upon query to CFI chip. Please find the kernel logs attached.

I understand it may not be related to flash issue, it has to do with Kernel.

Please let me know if you have any suggestions on resoving kernel panic.

Regards

Srinivasa

0 Likes

Hi Srinivasa,

the kernel crashes in physmap_flash_probe() when it calls cfi_probe(). cfi_qry_presetn() checks for a (2nd?) device and this read access causes the situation. Probably that memory has not been correctly mapped.

You will have to add more debugging hints, print the arguments of the functions, e.g. for cfi_probe_chip(). Also check at what virtual address the physmap driver is mapping the flash to. Then understand the code and see what is wrong.

Best regards,

Gernot

0 Likes

Hi Gernot,

Just a clarification:

With 128 Mbytes flash (1 die) detected by Kernel, I should be able to erase/write/read on 128 MB flash without any dependency on second die.

Is my understanding correct?

Regards

Srinivasa

0 Likes

Hi Srinivasa,

yes, that is correct! If you have our S70GL02GS patch installed and if you provide only a 128 MB address window then the kernel will detect just 1 die and that should work fine.

Best regards,

Gernot

0 Likes

Hi Gernot,

Thanks.  We are in touch with TI team.  Once I make progress will update on ths forum.

Regards

Srinivasa

0 Likes

Hi Gernot,

We have made some progress on this.

Problem statment:

We are able to detect only 1 die in the Linux version 4.14.79.

We are able to write only one sector.

We were debugging the CFI driver and control was reaching "cfi_probe_chip()" in "drivers/mtd/chips/cfi_probe.c".  In the below for loop,

We found that it was able to detect two chips upon disabled the alias check which is meant to be a safeguard against mis-configuration.

TI team suggested to keep it *enabled* and asked us investigate the data structures and call sequences that happen during probe.

Continuing further we noticed that disabling below function before alias check and having alias check enabled is making 2 chips detected!!!

I feel this should give us some hint.  Any input from will be great!!!

// cfi_qry_mode_off(start, map, cfi);

        /* Check each previous chip to see if it's an alias */

        for (i=0; i < (base >> cfi->chipshift); i++) {

                unsigned long start;

                if(!test_bit(i, chip_map)) {

                        /* Skip location; no valid chip at this address */

                        continue;

                }

                start = i << cfi->chipshift;

                /* This chip should be in read mode if it's one

                  we've already touched. */

                if (cfi_qry_present(map, start, cfi)) {

                        /* Eep. This chip also had the QRY marker.

                        * Is it an alias for the new one? */

/* Disabling this will make 2 chips detected */

                        cfi_qry_mode_off(start, map, cfi); 

#if(1)

                        /* If the QRY marker goes away, it's an alias */

                        if (!cfi_qry_present(map, start, cfi)) {

                                xip_allowed(base, map);

                                printk(KERN_DEBUG "%s: Found an alias at 0x%x for the chip at 0x%lx\n",

                                      map->name, base, start);

                                printk("%s: Found an alias at 0x%x for the chip at 0x%lx\n",

                                      map->name, base, start);

        printk("\n\n\nSrini debug @ line %d in function %s in file %s\n\n\n",__LINE__, __FUNCTION__, __FILE__);

                                return 0;

                        }

#endif

                        /* Yes, it's actually got QRY for data. Most

                        * unfortunate. Stick the new chip in read mode

                        * too and if it's the same, assume it's an alias. */

                        /* FIXME: Use other modes to do a proper check */

                        cfi_qry_mode_off(base, map, cfi);

                        if (cfi_qry_present(map, base, cfi)) {

                                xip_allowed(base, map);

                                printk(KERN_DEBUG "%s: Found an alias at 0x%x for the chip at 0x%lx\n",

                                      map->name, base, start);

                                printk("%s: Found an alias at 0x%x for the chip at 0x%lx\n",

                                      map->name, base, start);

                                printk("\n\n\nSrini debug @ line %d in function %s in file %s\n\n\n",__LINE__, __FUNCTION__, __FILE__);

                                return 0;

                        }

                }

        }

We have posted the same on TI E2E forum.

http://e2e.ti.com/support/processors/f/791/p/834972/3129906#pi320966=5

  1. What is the purpose of cfi_qry_mode_off()?
  2. Since same command is working in old kernel, I am suspecting some delay might be causing the issue.  Any comment on this?
  3. Please reivew cfi_qry_mode_off() and give any inputs/hits

Regards

Srinivasa

Hi Srinivasa,

cfi_qry_mode_on() enters CFI mode and cfi_qry_mode_off() exits CFI mode. The CFI signature is used to probe and detect devices.

Detecting aliases does not help much, in this situation.

Best regards,

Gernot

0 Likes

Hi,

Please refer to below link:

http://e2e.ti.com/support/processors/f/791/p/834972/3229453#3229453

Still we have not got solution for S70GL02GS NOR flash.  I am still looking on how to setup two different devices (one for each die) using device tree.

Or

Do you have any chip like S70GL02GS with a single die architecture?

Regards

Srinivasa

0 Likes

Hi Srinivasa,

Unfortunately we do not have a 2Gb part with single die. The single die devices come in lesser density.

Let us know if you need any help in part selection.

Best regards,

Apurva

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Srinivasa,

We don’t have a working example for your use case. However, you can find an example in kernel document (Documentation/devicetree/bindings/mtd/mtd-physmap.txt). The example from line 67 has two "reg" tuples that represent different devices mapped to consecutive address.

Thanks,

Takahiro

0 Likes
lock attach
Attachments are accessible only for community members.

Hi,

Updated dts file with two "reg" tuples as below:

        reg = <0 0x00000000 0x08000000

              0 0x08000000 0x10000000>;

Refer line line 25 & 26.  Upon bootup we have kernel panic.

Please find kernel log & gpmc nodeattached.

Regards

Srinivasa

0 Likes
lock attach
Attachments are accessible only for community members.

Just for reference I have attached kernel log with single tuple which is as below:

reg = <0 0x00000000 0x10000000>;

In this case, kernel is booting but we have below problems:

  1. We can detect only one die ie. 128 Mbytes.
  2. Writes more than one sector size 128 Kbytes fails.

Regards

Srinivasa

0 Likes

Hi Srinivasa,

I setup my Linux environment for v4.14 and tested the two 'reg' tuples case.

With the dts properties below, I could probe one Flash chip (I used the GL256S in hand) as two different chips.

In my case, the Flash chip is mapped at 0x60000000 and the #address-cells and #size-cells of parent node are 1.

     flash@0 {

          compatible = "cfi-flash";

          reg = < 0x60000000 0x01000000

                      0x61000000 0x01000000>;

          bank-width = <2>;

          #address-cells = <1>;

          #size-cells = <1>;

          partition@0 {

               label = "test-part0";

               reg = <0 0x01000000>;

          };

          partition@1 {

               label = "test-part1";

               reg = <0x01000000 0x01000000>;

          };

     };

The kernel log told that the chip was probed twice (16MB per each) then concatenated to one (32MB):

     60000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002201

     NOR chip too large to fit in mapping. Attempting to cope...

     Amd/Fujitsu Extended Query Table at 0x0040

       Amd/Fujitsu Extended Query version 1.5.

     number of CFI chips: 1

     Reducing visibility of 32768KiB chip to 16384KiB

     60000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002201

     NOR chip too large to fit in mapping. Attempting to cope...

     Amd/Fujitsu Extended Query Table at 0x0040

       Amd/Fujitsu Extended Query version 1.5.

     number of CFI chips: 1

     Reducing visibility of 32768KiB chip to 16384KiB

     Concatenating MTD devices:

     (0): "60000000.flash"

     (1): "60000000.flash"

     into device "60000000.flash"

     2 ofpart partitions found on MTD device 60000000.flash

     Creating 2 MTD partitions on "60000000.flash":

     0x000000000000-0x000001000000 : "test-part0"

     0x000001000000-0x000002000000 : "test-part1"

The physmap probe is done in the of_flash_probe() in the physmap_of_core.c. So, enabling debug print or adding printk into that would help to know the actual address mapped to Flash.

Thanks,

Takahiro

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Takahiro,

Thanks for your input.

Our Kernel version is also v4.14 and my dts file is as bleow: (I have attached complete gpmc node in the same forum dated Feb 6, 2020 3:52 AM.

nor@0,0 {

/*                  reg = <0 0x00000000 0x10000000>;  */

                      reg = <0 0x00000000 0x08000000

                                  0 0x08000000 0x10000000>;

compatible = "cfi-flash";            

linux,mtd-name = "physmap-flash.0";

bank-width = <2>;

device-width = <2>;

#address-cells = <1>;

#size-cells = <1>;

Please review our dts file and If you find any errors in our gpmc node, let us know.

Comparing our gmpc node with yours, I have below comments/findings with respect to multiple ”reg” tuples.

Kernel documentation states “- reg : Address range(s) of the mtd chip(s)”

<chip_select start_address end_address>

Considering this & our chip is S70GL02GS and we have only one chip select 0,  I have divided the reg tuples as below:

reg = <0 0x00000000 0x08000000    /* This is for first die */

            0 0x08000000 0x10000000>;  /* This is for second die */

Since we are using same chip select 0 for both die, first parameter is 0 for complete address range.

In my case, it is mapped to 0x00000000 in u-boot and I am considering that it is carry forwarded to Kernel.

Your dts file has reg tuples as below:

reg = < 0x60000000 0x01000000

0x61000000 0x01000000>;

Questions:

How come you have only two parameters for reg?

Documentation/devicetree/bindings/mtd/mtd-physmap.txt also has an example like mine.  Why did you remove first parameter?

As per your example, I tried to modify my dts file as below: (Removed the first parameter 0 in both reg tuples).

reg = <0x00000000 0x08000000    /* This is for first die */

            0x08000000 0x10000000>;  /* This is for second die */

I have below warning message for compilation of dts file.

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x-evmsk.dtb

  CHK scripts/mod/devicetable-offsets.h

  DTC arch/arm/boot/dts/am335x-evmsk.dtb

arch/arm/boot/dts/am335x-evmsk.dtb: Warning (reg_format): "reg" property in /ocp/gpmc@50000000/nor@0,0 has invalid length (16 bytes) (#address-cells == 2, #size-cells == 1)

However, dtb file was generated and NOR flash was not detected and I have below error:

[    1.518919] omap-gpmc 50000000.gpmc: GPMC revision 6.0

[    1.525547] gpmc_read_settings_dt: page/burst-length set but not used!

[    1.533776] of-flash 18000000.nor: Malformed reg property on /ocp/gpmc@50000000/nor@0,0

[    1.542006] of-flash: probe of 18000000.nor failed with error -22

Please find complete log file attached.

Another important point you have mentioned “In my case, the Flash chip is mapped at 0x60000000”.

How is flash mapped to 0x60000000 and where is it mapped (Kernel or u-boot)?

Regards

Srinivasa

0 Likes

Hello Srinivasa,

Sorry for not mentioning that my system is not TI SoC based one.

As you know the DTS depends on the hardware platform so my example cannot be applied to your system directly.

The number of cells in my 'reg' come from the #address-cells and #size-cells of parent node.

In my dts, both are '1' so the reg has two cells. In your GPMC node (=Flash's parent node), #address-cells=2 and  #size-cells=1 so there should be three parameters.

Thanks,

Takahiro

0 Likes

Hi Takahiro,

Earlier in your post dated “Feb 14, 2020 12:57 AM”, you mentioned

“I could probe one Flash chip (I used the GL256S in hand) as two different chips.”

From the below datasheet, we understand that GL256S is S29GL256S and does not have two die architecture whereas we are using NOR flash S70GL02GS which is a dual die stack of two S29GL01GS die.

We can detect single die of S70GL02GS but unable to detect second dies.

As mentioned in datasheet of S70GL02GS (Chapter 5, Second Die Access), we use single chip select (CS#) signal to access both dies.

It would be great if you can provide DTS example for the same part S70GL02GS.

This will help to co-ordinate with our TI counterpart on getting further inputs.

Regards

Srinivasa

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Srinivasa,

I enabled the S70GL02GS on my test platform. Please see what I did below and make sure you are doing the equivalent steps for your hardware.

My test platform is Xilinx Zynq-7000 SoC based.

  1. Fetch Linux kernel source from Xilinx git, then checkout the 'xilinx-v2018.3' tag which based on Linux 4.14
  2. Apply default kernel configuration by 'make xilinx_zynq_defconfig'
    • I did not make additional changes to the kernel configuration
    • See 'config' file in attachment for reference
  3. Apply two patches (mentioned in TI forum) below
    • mtd: cfi: Support early CFI fixups
    • mtd: cfi: Add early fixup for S70GL02GS
  4. Build kernel
  5. Create device tree files
    • I reused the 'zynq_zed.dts' because my hardware is similar with Zynq Zed board
    • I created two device tree files for test. Please see device tree files in attachment. I added the 'flash@60000000' node (line 38~).
      • devicetree_1.dts: single 'reg' tuple case (I think TI is doing this way)
      • devicetree_2.dts: double 'reg' tuple case (like I did for GL256S in previous post)
  6. Boot Linux kernel
    • I tested two devicetree cases. Although the probing paths were different, both could detect and probe as expected.
    • Please see kernel boot logs for both cases in attachment (line 122~)
      • kernel_boot_1.txt: single 'reg' tuple case. Probe once,  two chips are detected per one probe
      • kernel_boot_2.txt: double 'reg' tuple case: Probe twice, one chip is detected per one probe
  7. Quick tests with mtd_debug
    • I confirmed read/write/erase on the first and last sector in two dies.
    • Both singe and double 'reg' tuple cases were OK

The conclusion is that the MTD driver in the Linux 4.14 (+ patches) works with S70GL02GS, regardless of single or double 'reg' tuples in the dts.

Hope this helps for further analysis.

Best Regards,

Takahiro

0 Likes

Hi Takahiro,

Please find observations below:

I had difficulty in making numbering correct on the webpage, so it is not matching with yours

Please consider the text highlighted with Yellow and Purple.

  1. Fetch Linux kernel source from Xilinx git, then checkout the 'xilinx-v2018.3' tag which based on Linux 4.14

     ok, our kernel is also 4.14

  1. Apply default kernel configuration by 'make xilinx_zynq_defconfig'
      • I did not make additional changes to the kernel configuration
      • See 'config' file in attachment for reference

I have performed quick comparison of Xilinx and TI Kernel configuration and here the summary with respect to MTD configurations.

TI/Our existing Kernel configuration

CONFIG_MTD=y

CONFIG_MTD_CMDLINE_PARTS=y

CONFIG_MTD_OF_PARTS=y

CONFIG_MTD_BLKDEVS=y

CONFIG_MTD_BLOCK=y

CONFIG_MTD_OOPS=y                                   TI ONLY

CONFIG_MTD_CFI=y

CONFIG_MTD_GEN_PROBE=y

CONFIG_MTD_CFI_ADV_OPTIONS=y                        TI ONLY

CONFIG_MTD_CFI_NOSWAP=y                   TI ONLY

CONFIG_MTD_MAP_BANK_WIDTH_1=y

CONFIG_MTD_MAP_BANK_WIDTH_2=y

CONFIG_MTD_MAP_BANK_WIDTH_4=y

CONFIG_MTD_CFI_I1=y

CONFIG_MTD_CFI_I2=y

CONFIG_MTD_CFI_AMDSTD=y

CONFIG_MTD_CFI_STAA=y                                          TI ONLY

CONFIG_MTD_CFI_UTIL=y

CONFIG_MTD_RAM=y                                    TI ONLY

CONFIG_MTD_ROM=y                                    TI ONLY

CONFIG_MTD_PHYSMAP=y                                          TI ONLY

CONFIG_MTD_PHYSMAP_OF=y

CONFIG_MTD_BLOCK2MTD=y                                    TI ONLY

CONFIG_MTD_UBI=y

CONFIG_MTD_UBI_WL_THRESHOLD=409`           TI ONLY

CONFIG_MTD_UBI_BEB_LIMIT=1                              TI ONLY

XILINX Kernel configuration

CONFIG_MTD=y

CONFIG_MTD_CMDLINE_PARTS=y

CONFIG_MTD_OF_PARTS=y

CONFIG_MTD_BLKDEVS=y

CONFIG_MTD_BLOCK=y

CONFIG_MTD_CFI=y

CONFIG_MTD_GEN_PROBE=y

CONFIG_MTD_MAP_BANK_WIDTH_1=y

CONFIG_MTD_MAP_BANK_WIDTH_2=y

CONFIG_MTD_MAP_BANK_WIDTH_4=y

CONFIG_MTD_CFI_I1=y

CONFIG_MTD_CFI_I2=y

CONFIG_MTD_CFI_AMDSTD=y

CONFIG_MTD_CFI_UTIL=y

CONFIG_MTD_PHYSMAP=y

CONFIG_MTD_PHYSMAP_OF=y

CONFIG_MTD_NAND_ECC=y                                                        XILIX ONLY

CONFIG_MTD_NAND=y

CONFIG_MTD_NAND_PL35X=y                                                  XILINX ONLY

CONFIG_MTD_SPI_NOR=y                                                            XILINX ONLY

CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y                       XILINX ONLY

We have dreived at above configurations based on working kernel.  I am surprised why you don't have below one, because without this we had problem of NOR flash becoming READ_ONLY.

CONFIG_MTD_RAM=y                                    TI ONLY

Since it is parallel NOR flash, why CONFIG_MTD_SPI_NOR is enabled?

  1. Apply two patches (mentioned in TI forum) below
      • mtd: cfi: Support early CFI fixups
      • mtd: cfi: Add early fixup for S70GL02GS

We are applying only one patch (linux-3.14.27-s70gl02gs.patch).  

From below link

https://community.cypress.com/thread/48218

Dated Aug 7, 2019 3:10 PM

Which is the one we are missing ?

  1. Build kernel
  2. Ok.

  1. Create device tree files
  • I reused the 'zynq_zed.dts' because my hardware is similar with Zynq Zed board
  • I created two device tree files for test. Please see device tree files in attachment. I added the 'flash@60000000' node (line 38~).
  • devicetree_1.dts: single 'reg' tuple case (I think TI is doing this way)
  • devicetree_2.dts: double 'reg' tuple case (like I did for GL256S in previous post)

From Xilinx Single tuple

      flash@60000000 {

                  compatible = "cfi-flash";

                  reg = <0x60000000 0x08000000

0x68000000 0x08000000>;

                  bank-width = <2>;

                  device-width = <2>;

                  #address-cells = <1>;

                  #size-cells = <1>;

                  fs@0 {

                              label = "fs0";

                              reg = <0 0x10000000>;

                  };

      };

From TI Single Tuple

      nor@0,0 {

              reg = <0 0x00000000 0x10000000>;

                compatible = "cfi-flash"; 

                linux,mtd-name = "physmap-flash.0";

               

                bank-width = <2>;

                  device-width = <2>;

                #address-cells = <1>;

                #size-cells = <1>;

Everything is same except for first parameter in reg = < > i.e) the base address.  Since it is hardware specific I will verify it from our end also.

  1. Boot Linux kernel
    • I tested two devicetree cases. Although the probing paths were different, both could detect and probe as expected.
    • Please see kernel boot logs for both cases in attachment (line 122~)

Please Print line number, function and file where below prints are coming out.

Bad S70GL02GS CFI data; adjust to detect 2 chips

  1. 60000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x004801
  2. 60000000.flash: Found 1 x16 devices at 0x8000000 in 16-bit bank

Amd/Fujitsu Extended Query Table at 0x0040

  • kernel_boot_1.txt: single 'reg' tuple case. Probe once,  two chips are detected per one probe
  • kernel_boot_2.txt: double 'reg' tuple case: Probe twice, one chip is detected per one probe
  1. Quick tests with mtd_debug
    • I confirmed read/write/erase on the first and last sector in two dies.

Please try  writing to two or more consecutive sectors and let us know the observations.

Pleae let me know if you need anything more from our end.

Regards

Srinivasa

0 Likes

Hi Srinivasa,

CONFIG_MTD_SPI_NOR: The Xilinx SoC supports SPI NOR. If there is no SPI NOR Flash entry in devicetree, the driver is not activated.

The two patches TI mentioned seem to have the same effect with the Cypress patch you apply. However, I recommend to follow TI's instruction because they confirmed that works with their SoC.

I confirmed entire Flash can be accessed (Read/Program/Erase).

Thanks,

Takahiro

0 Likes

Hi,

I am little surprised on the configuration side.  I will not try to work on configuration side because my configuration is matching with our old kernel.

I need more input from your side on below point. Since parsing of dts file for gpmc_node is done in “drivers/memory/omap-gpmc.c” in TI board, I want to see what is happening on Xilinx source tree.


Please Print line number, function and file where below prints are coming out.

Bad S70GL02GS CFI data; adjust to detect 2 chips

  1. 60000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x004801
  2. 60000000.flash: Found 1 x16 devices at 0x8000000 in 16-bit bank

Amd/Fujitsu Extended Query Table at 0x0040

Regards

Srinivasa

0 Likes

Hi Srinivasa,

Sorry for missing the answer on that point in my previous response.

The "Bad S70GL02GS CFI data; adjust to detect 2 chips" is from the patch, "mtd: cfi: Add early fixup for S70GL02GS".

Another one is from drivers/mtd/chips/cfi_probe.c, cfi_chip_setup(), line#283.

Thanks,

Takahiro

0 Likes

Hi

Please let me know where (i.e filename/function) gpmc_node is parsed in Xilinx source tree.

Regards

Srinivasa

0 Likes

Hi Srinivasa,

The GPMC is specific in TI's SoC. There is no gpmc_node in my DTS for Xilinx SoC. The flash node in my DTS is parsed in physmap-core.c, physmap_flash_probe().

Thanks,

Takahiro

0 Likes

Hi Takahiro,

Thanks for your input.  TI's kernel tree will never execute physmap_flash_probe() in physmap-core.c.  Everything happens in “drivers/memory/omap-gpmc.c”.

This we have noticed and raised this question with TI in below link (Oct 4, 2019 9:46 AM)

http://e2e.ti.com/support/processors/f/791/t/834972#pi320966=2

This might be a hint which we need to look at it.

Regards

Srinivasa

0 Likes