Unknown flash on Bank 1 - Size = 0x00000000 = 0 MB

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

Hi,

We are using S70GL02GS in our product.  With the old u-boot version U-Boot SPL 2013.10 (Aug 05 2019 - 23:00:56) we are able to bring up the board and everything is fine.

We are porting the code to newer version of u-boot(U-Boot SPL 2018.01-00569-g7b4e473842-dirty) and kernel (V4.12) and we are facing the problem in flash being recognized.

Error is “## Unknown flash on Bank 1 - Size = 0x00000000 = 0 MB”.

Upon debugging we are noticing that in Flash_init() function of file drivers/mtd/cfi_flash.c, it is not able to recognize the flash.

Any input on this? Please let us know.

Regards

Srinivasa

0 Likes
1 Solution

Hi Bushra/Gernot,

Thank you very much for your support.  

At power up, cfi probe function was failing.  Updted the GPMC registers similar to u-boot and probe function in kernel is passing now.

Kernel is able to detect the flash and display the Manufacture ID 0x000001 and chip ID 0x004801.

Appreciate your help again.

Regards

Srinivasa

View solution in original post

0 Likes
33 Replies
lock attach
Attachments are accessible only for community members.
BushraH_91
Moderator
Moderator
Moderator
750 replies posted 50 likes received 250 solutions authored

Hello Srinivasa,

The S70GL02GS has two dies and is a little bit special. For Linux, I am sending you the patch (refer to attachment).

For U-boot, we are still reviewing the issue. .

Thank you

Regards,

Bushra

0 Likes

Hi Bushra,

Thanks for the quick response.

Sorry, I am reiterating the same question again.

We have a hardware which is working with “u-boot version U-Boot SPL 2013.10” and everything is working fine with the part number “S70GL02GS”.

When you say “U-boot, we are still reviewing the issue”, means that U-boot version “u-boot (U-Boot SPL 2018.01” with part number S70GL02GS” is not working at your end also and you are looking at it.

I am little bit surprised.  Our thought process was since “S70GL02GS” is working with u-boot 2013.10, it should work with U-boot 2018.01.  If you have any challenges making S70GL02GS work with U-boot 2018.01, please let us know, we need to communicate with our customer also on this.

Regards

Srinivasa

0 Likes

Hello Srinivasa,

U-boot, we are still reviewing the issue”, means we were looking into your inquiry.

It is very strange that you see the issue after migrating newer version of u-boot because there are no major changes in the driver/mtd/cfi_flash.c.

Could you please enable debug() print in the u-boot to collect detailed information and send it to us?

Thank you

Regards,

Bushra

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

Hi Bushra,

Processor is trying to send commands via function "flash_write_cmd".  In this function, it generates address address based on the offset and the port width.  Next it generates in this function, it generates proper sized command based on the port and chip widths.

I have enabled below statement in function flash_write_cmd:

debug("fwc addr %p cmd %x %x 8bit x %d bit\n", addr, cmd, cword.w8, info->chipwidth << CFI_FLASH_SHIFT_WIDTH);

Address, cmd, and port width are not same in working u-boot and not working uboot!!!

Surprisingly sometimes in not working u-boot chipwidth is sometimes 32 bit!!!!

In the working code, it enters "flash_write_cmd" function for about 4110 times where as in Not working u-boot it enters 20 times and somewhere in between it fails and exits?

Why is generated Address, cmd, and chipwidth is not uniform in both cases?

Does the flash_info_t *info is being updated properly?

Please find the logs attached for working and not working code.

If you need any other info, please let me know.

Reply

0 Likes

Hi Srinivasa,

Thank you for providing the logs.

Please see the flash_detect_cfi() in the drivers/mtd/cfi_flash.c. The u-boot tries to detect the Flash by changing chipwidth and portwidth. Once the expected CFI "QRY" keywords are detected, the chipwidth and portwidth are determined (I think it is 16bit x 16bit in your system). In your Not_Working log, both chipwidth and portwidth reaches to 32-bit without detecting expected QRY keywords.

I assume that you are using the same hardware and just migrated the u-boot software between Working and Not Working. I would suggest to verify/compare your u-boot configurations (.config) between the Working and Not Working. The GPMC configuration looks same. How about the MMU and/or Cache configuration? I could see the "Caches not enabled" message in the Working log. If the cache is enabled in the Not Working and the Flash address is configured as cache-able region, the accesses to the Flash may not be performed correctly.

Thanks,

Takahiro

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

Hi Takahiro,

Yes, we are using same hardware and just migrated the u-boot software between Working and Not Working. Sure, we will verify/compare .config files.

I did not touch MMU and Cache related code.  My understanding says that it disabled in U-boot.

We have updated .dts file with respect to NOR flash.  Can you please review the only the NOR related changes and give your feedback?  Also, TI representative was suggesting getting all timing parameters from Cypress.  Please provide timing parameters that are in &gpmc node (line 287 to 371).

Regards

Srinivasa

0 Likes

Hi Srinivasa,

I assume the dts file you attached is the one for Not Working. Could you send the dts for Working one?

I'm confused about the pinmux settings from line#78. This looks like for Address and Data multiplexed memory. The GL-S family is Non-multiplexed memory. You need to assign all of A1 to A27, however, the dts only setting for A1 to A10, and A27.

Regarding the timing parameters, please find the AC Characteristics section in the datasheet:

https://www.cypress.com/file/177976/download

S70GL02GS is the dual die stack of S29GL01GS.

Thanks,

Takahiro

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

Hi Takahiro,

Yes, I have attached dts file of non-working board only.  We are migrating from U-boot (V2013) to U-boot (V2018).    We have working hardware with old version of U-boot (V2013) and in this version of U-boot we did not have .dts concept, so I don’t have dts file for working one.

By referring to old board’s mux.c, we have written new dts file.  I am attaching the C code of the old working code and from that it is clear that we are using multiplexed address and data lines.  From the code attached and as you mentioned we are using multiplexed Address Data 16-bit device.

Since old code is working fine, now I am surprised with your statement “The GL-S family is Non-multiplexed memory”.  Are you sure on this?

Next my question will be how come old code is working with multiplexed address and data line (A/D0 to A/D15)?

Regards

Srinivasa

0 Likes

Hi Srinivasa,

Yes, I'm sure. Please refer to the datasheet. The Address (A26-A0) and Data (DQ15-DQ0) are independent (not multiplexed).

pastedImage_0.png

In your old code, probably the multiplexed configuration is overwritten by non-multiplexed one at some point...

I think you can check actual pinmux register value by 'md' command in u-boot. And you may want to check the schematic to verify how the SoC and the Flash are connected.

Thanks,

Takahiro

0 Likes

Hi Takahiro,

Thanks for quick response.

Just verified with the schematics of our board.  We have below in our schematics:

  • AD0 – AD15 going directly from processor to NOR Flash.
  • ALE signal going to D-latch and which controls the selection of address/data to flash.
  • A16 – A26 going from processor to NOR flash via Isolation switch.
  • Control signals going directly from processor to NOR flash.

For sure, I don’t see separate lines (A26–A0) & (DQ15–DQ0) going from processor to NOR flash directly. 

From the schematics, it must be multiplexed address and data lines for our board.  I cannot share our schematics on the public forum.

Please confirm if there is any other version of this chip.

Regards

Srinivasa

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

Hi Takahiro,

From the NOR flash point of view, you are correct.  Address and data lines are NOT multiplexed.  From the processor point of view, address and data are multiplexed.  GPMC should take care of this.

Attaching the GPMC part of the processor

Regards

Srinivasa

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

Hi Takahiro,

I have made little progress on this.  Now I can get response to “QRY” keywords.  Next it’s trying to fetch vendor and it fails. Error message is “CFI: Unknown command set 0x1402”.

I have captured logs for both working and not working u-boot please find files attached.

Since dts file is on the processor side (AM335X) and we are clear there is multiplexing at processor end.  Now I am suspecting on the dts file because I have verified all other aspects and dts has become a kind of black box to me.

Considering this do you have any reference working dts file for us.   In the dts file, I am ok with the pin-muxing side (line 78 to 116).  Since you don't have schematics, you can ignore this.   I am attaching my dts file again.  I am not sure what  is going on at node & gpmc (line 225 to 276).  TI guys say, you have to get input from CYPRESS team.

We are operating in "16-Bit Address/Data-Multiplexed Memory" mode as explained in Section 7.1.2.2 of TRM. 

If you need any further input from me, please let me know.

Regards

Srinivasa

0 Likes

Hi Srinivasa,

I understand that you are using an external D-latch component between SoC and Flash, to interconnect the Addr/Data Multiplex (ADM) host and Addr/Data Parallel (ADP) memory.

In your NOT_WORKING log file, I could find (line#503):

     Value of qry.p_id : 5122

     Value of qry.p_adr : 5696

5122 = 0x1402 and 5696 = 0x1640. They look like address + data in the CFI table.

pastedImage_0.png

I think the host reads out the address that output from the host as data. I would suggest to verify the DTS configuration for the D-latch (CLK, timing, etc...).

Thanks,

Takahiro

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

Hi Takahiro,

Thank you very much on your input.

We changed #define STNOR_GPMC_`CONFIG1 from 0x00001200 to 0x00001210 and everything is working fine i.e) increased to 1h = x2 latencies.

We have Kernel versin 4.14 and as per my understanding goes, we need to do changes only in .dts file.  Since we don't have any board file in kernel ( as compared to older versions).  I have ported all NOR flash related changes from u-boot to kernel.  I am not seeing anything related to NOR flash in kernel.

On powerup, omap_hwmod.c file in Kernel scans for all nodes and gpmc is being displayed as below:

[    0.139039] Srini debug @ line 2494 in function _init in file arch/arm/mach-omap2/omap_hwmod.c

[    0.139068] hw name: gpmc

How to we know NOR flash is detected in kernel?

Is there anything additional changes (other than dts) we need to in kernel?

Please let us know your input on this.

I have attached kernel log for reference.

Regards

Srinivasa

0 Likes

Hi Takahiro,

As I understand for kernel we need to enable the right driver for the CFI flash in the dts file with the compatible field.  At the bootloader, we have below message for flash info:

Bank # 1: CFI conformant flash (16 x 16)  Size: 256 MB in 1024 Sectors

  AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E4801

Advanced Sector Protection (PPB) enabled

  Erase timeout: 2048 ms, write timeout: 1 ms

Buffer write timeout: 3 ms, buffer size: 512 bytes

At the bootloader code, we have below struct in drivers/mtd/cfi_flash.c

static const struct udevice_id cfi_flash_ids[] = {

        { .compatible = "cfi-flash" },

        { .compatible = "jedec-flash" },

        {}

};

U_BOOT_DRIVER(cfi_flash) = {

        .name   = "cfi_flash",

        .id     = UCLASS_MTD,

        .of_match = cfi_flash_ids,

        .probe = cfi_flash_probe,

};

In the kernel, we have “cfi-flash” string only in file drivers/mtd/maps/physmap_of_core.c.  To compile this driver I have enabled below configurations:

#

# RAM/ROM/Flash chip drivers

#

CONFIG_MTD_CFI=y

CONFIG_MTD_JEDECPROBE=y

CONFIG_MTD_MAP_BANK_WIDTH_1=y

CONFIG_MTD_MAP_BANK_WIDTH_2=y

CONFIG_MTD_MAP_BANK_WIDTH_4=y

# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set

# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set

# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set

CONFIG_MTD_CFI_I1=y

CONFIG_MTD_CFI_I2=y

# CONFIG_MTD_CFI_I4 is not set

# CONFIG_MTD_CFI_I8 is not set

# CONFIG_MTD_RAM is not set

# CONFIG_MTD_ROM is not set

# CONFIG_MTD_ABSENT is not set

Upon doing so still my driver file “physmap_of_core.c” is not getting compiled. 

How do I enable compilation of cfi_flash driver?

Regards

Srinivasa

0 Likes

Hi Takahiro,

I have enabled driver in kernel as below:

Device Drivers -->

     Memory Technology Device (MTD) support -->

          RAM/ROM/Flash chip drivers ->

               <*> Detect flash chips by Common Flash Interface (CFI) probe

Is this correct?  or do we need to update any other configuration towards this?

Regards

Srinivasa

0 Likes

Hi,

Under discussion “S70GL02GS Support Under Linux - KBA218976",  please provide us the patch as mentioned in below link;

https://community.cypress.com/docs/DOC-10503

My doubts are similar to below link

https://community.cypress.com/message/160286#160286

I could not download the patch mentioned by BacemD_61 dated “Jun 25, 2018 12:55 AM”.  The link has expired. 

Can you please share the dts file patch?

Do you have any examples of the S70GL02GS specified as a cfi-compatible device in an embedded Linux .dts file?

Regards

Srinivasa

0 Likes

Hi Srinivasa,

for S70GL02GS under Linux, you have to use the patch that Bushra has sent you attached to an earlier message.

It fixes some CFI geometry data that is wrong in that dual die device.

Afterwards, you should see probing messages of the driver (driver/chips/cfi_cmdset_0002.c) in the kernel log,

and a MTD should show up in /proc/mtd.

Thanks,

Gernot

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

Hi Gernot,

As per your suggestion, I have applied the patch provided by Bushra and it is entering the function “drivers/mtd/chips/cfi_probe.c” 

I have below observation:

Case 1:  Bank-Width = <2> was under nor child node as below:

&gpmc {

        status = "okay";

        pinctrl-names = "default";

        pinctrl-0 = <&nor_pins>;

        gpmc,num-waitpins = <1>;

        ranges = <0 0 0x08000000 0x10000000>;

        compatible = "cfi-flash";

        bank-width = <2>;

                nor@0,0x50000000 {

                    linux,mtd-name = "winbond,xxxxxxxx";

                    reg = <0 0 0x10000000>;

                    bank-width = <2>;

                        …

}

};

I had a kernel log “of-flash 50000000.gpmc: Can't get bank width from device tree”.  Though mtd was visible in /proc it was empty as below:

root@am335x-evm:~# cat /proc/mtd

dev:    size  erasesize name

root@am335x-evm:~#

Log file attached: mtd_mouted.txt

Case 2:  Bank-Width = <2> was updated as below:

Since kernel was not able to find the bank width I updated dts file as below (under & gpmc node)

&gpmc {

        status = "okay";

        pinctrl-names = "default";

        pinctrl-0 = <&nor_pins>;

        gpmc,num-waitpins = <1>;

        ranges = <0 0 0x08000000 0x10000000>;

        compatible = "cfi-flash";

        bank-width = <2>;

      nor@0,0x50000000 {

           

// bank-width = <2>;

}

Now I am facing kernel panic.  Please find attached log files attached for case 1 and case 2.

In u-boot we have port-width and chip width as 2 & 2 respectively.  Tried changing the bank width to 1 but still the same problem.

What should be the bank width in the Kernel dts file for S70GL02GS?

In which node do we need to specify the bank width (gpmc node or nor child node)?

Regards

Srinivasa

0 Likes

Hi Srinvasa,

yes, bankwidth should be 2 (i.e. 16 bits, or 2 bytes).

The details and pin setup depend on the board driver, in your case the gpmc driver from TI.

Best regards,

Gernot

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

Hi Memory Experts,

At bootloader prompt, I have below info:

=> fli

Bank # 1: CFI conformant flash (16 x 16)  Size: 256 MB in 1024 Sectors

  AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E4801

  Advanced Sector Protection (PPB) enabled

  Erase timeout: 2048 ms, write timeout: 1 ms

  Buffer write timeout: 3 ms, buffer size: 512 bytes

  Sector Start Addresses:

  08000000        08020000        08040000        08060000        08080000

  080A0000        080C0000        080E0000        08100000        08120000

.

.

.

  0FD00000        0FD20000        0FD40000        0FD60000        0FD80000

  0FDA0000        0FDC0000        0FDE0000        0FE00000        0FE20000

  0FE40000        0FE60000        0FE80000        0FEA0000        0FEC0000

  0FEE0000        0FF00000        0FF20000        0FF40000        0FF60000

  0FF80000        0FFA0000        0FFC0000        0FFE0000

At bootloader, I am able to execute below commands:

protect off all

erase all

erase 08000000 +510 (on any sector);

Good so fat at bootloader!!!

Kernel:

Now I am able to mount the Kernel partitions and below is the kernel log messages:

[    2.972194]

[    2.972194]

[    2.989999] 6 ofpart partitions found on MTD device SPX, SPX_partitions

[    2.996857] Creating 6 MTD partitions on "SPX, SPX_partitions":

[    3.002842] 0x000000000000-0x000000080000 : "uboot"

[    3.010141] 0x000000080000-0x000000120000 : "uboot-env"

[    3.017685] 0x0000000a0000-0x000000640000 : "Current kernel"

[    3.025473] 0x0000005a0000-0x000001040000 : "Backup kernel"

[    3.033040] 0x000000aa0000-0x000001a40000 : "Failsafe kernel"

[    3.040936] 0x000000fa0000-0x000010fa0000 : "File System"

[    3.046492] mtd: partition "File System" extends beyond the end of device "SPX, SPX_partitions" -- size truncated to 0xf060000

[    3.059901]

Able to see the partitions in the kernel as below:

root@am335x-evm:~#

root@am335x-evm:~# cat /proc/mtd

dev:    size  erasesize  name

mtd0: 00080000 10000000 "uboot"

mtd1: 000a0000 10000000 "uboot-env"

mtd2: 005a0000 10000000 "Current kernel"

mtd3: 00aa0000 10000000 "Backup kernel"

mtd4: 00fa0000 10000000 "Failsafe kernel"

mtd5: 0f060000 10000000 "File System"

root@am335x-evm:~#

root@am335x-evm:~# mtd_debug info /dev/mtd0

mtd.type = MTD_ROM

mtd.flags = MTD_CAP_ROM

mtd.size = 524288 (512K)

mtd.erasesize = 268435456 (256M)

mtd.writesize = 1

mtd.oobsize = 0

regions = 0

I am not able to perform erase/write on any mtd partitions, below is the error message

root@am335x-evm:~# flash_erase /dev/mtd1 0 0

flash_erase: error!: /dev/mtd1

            error 13 (Permission denied)

root@am335x-evm:~#

root@am335x-evm:~#

root@am335x-evm:~# flashcp -v uImage /dev/mtd2

While trying to open /dev/mtd2 for read/write access: Permission denied

root@am335x-evm:~#

root@am335x-evm:~#

My flash base is:

FLASH_BASE            (0x08000000)

DTS File with respect to FLASH is attached with kernel log messages.

What does below error indicates?  Can you please comment from my dts file.

mtd: partition "File System" extends beyond the end of device "SPX, SPX_partitions" -- size truncated to 0xf060000

Is abover error causing erase/write problems?

OR

Do I need to have partiton size in a multiple of 65536 (0x10000)?

OR

What is causing for flash erase/write problem?

Thank you very much for your support.

Regards

Srinivasa

0 Likes

Hi,

the dts partition entries specify start_offset and length. Not start_offset and end_offset.

So you have to correct these to get a layout that fits onto the available memory space.

Also partition start and end addresses need to be multiples of the flash sector size

(256 MB in your case).

Regarding the "permission denied" message, it looks like your user does not have the

right permissions. How is /dev/mtdx set from a permission point of view?

Best regards,

Gernot

0 Likes

Hi,

Thank you.  Corrected at my end.

Now all the 6 partitions are mounted and below error is not present.

mtd: partition "File System" extends beyond the end of device "SPX, SPX_partitions" -- size truncated to 0xf060000

Ok: 128 kB is my Sector size.  All start address are multiples of 128 KBytes.

Yes.  For "/dev/mtdx", permissions was not available as below:

root@am335x-evm:~# ls -la /dev/mtd*

crw-------    1 root     root       90,   0 Aug 14 14:55 /dev/mtd0

crw-------    1 root     root       90,   1 Aug 14 14:55 /dev/mtd0ro

crw-------    1 root     root       90,   2 Aug 14 14:55 /dev/mtd1

crw-------    1 root     root       90,   3 Aug 14 14:55 /dev/mtd1ro

crw-------    1 root     root       90,   4 Aug 14 14:55 /dev/mtd2

crw-------    1 root     root       90,   5 Aug 14 14:55 /dev/mtd2ro

crw-------    1 root     root       90,   6 Aug 14 14:55 /dev/mtd3

crw-------    1 root     root       90,   7 Aug 14 14:55 /dev/mtd3ro

crw-------    1 root     root       90,   8 Aug 14 14:55 /dev/mtd4

crw-------    1 root     root       90,   9 Aug 14 14:55 /dev/mtd4ro

crw-------    1 root     root       90,  10 Aug 14 14:55 /dev/mtd5

crw-------    1 root     root       90,  11 Aug 14 14:55 /dev/mtd5ro

brw-rw----    1 root     disk       31,   0 Aug 14 14:55 /dev/mtdblock0

brw-rw----    1 root     disk       31,   1 Aug 14 14:55 /dev/mtdblock1

brw-rw----    1 root     disk       31,   2 Aug 14 14:55 /dev/mtdblock2

brw-rw----    1 root     disk       31,   3 Aug 14 14:55 /dev/mtdblock3

brw-rw----    1 root     disk       31,   4 Aug 14 14:55 /dev/mtdblock4

brw-rw----    1 root     disk       31,   5 Aug 14 14:55 /dev/mtdblock5

root@am335x-evm:~#

root@am335x-evm:~#

Changed the permission and try to erase, still the same problem.

root@am335x-evm:~#

root@am335x-evm:~# chmod 777 /dev/mtd0

root@am335x-evm:~# chmod 777 /dev/mtd0ro

root@am335x-evm:~#

root@am335x-evm:~#

root@am335x-evm:~#

root@am335x-evm:~# ls -la /dev/mtd*

crwxrwxrwx    1 root     root       90,   0 Aug 14 14:55 /dev/mtd0

crwxrwxrwx    1 root     root       90,   1 Aug 14 14:55 /dev/mtd0ro

crw-------    1 root     root       90,   2 Aug 14 14:55 /dev/mtd1

crw-------    1 root     root       90,   3 Aug 14 14:55 /dev/mtd1ro

crw-------    1 root     root       90,   4 Aug 14 14:55 /dev/mtd2

crw-------    1 root     root       90,   5 Aug 14 14:55 /dev/mtd2ro

crw-------    1 root     root       90,   6 Aug 14 14:55 /dev/mtd3

crw-------    1 root     root       90,   7 Aug 14 14:55 /dev/mtd3ro

crw-------    1 root     root       90,   8 Aug 14 14:55 /dev/mtd4

crw-------    1 root     root       90,   9 Aug 14 14:55 /dev/mtd4ro

crw-------    1 root     root       90,  10 Aug 14 14:55 /dev/mtd5

crw-------    1 root     root       90,  11 Aug 14 14:55 /dev/mtd5ro

brw-rw----    1 root     disk       31,   0 Aug 14 14:55 /dev/mtdblock0

brw-rw----    1 root     disk       31,   1 Aug 14 14:55 /dev/mtdblock1

brw-rw----    1 root     disk       31,   2 Aug 14 14:55 /dev/mtdblock2

brw-rw----    1 root     disk       31,   3 Aug 14 14:55 /dev/mtdblock3

brw-rw----    1 root     disk       31,   4 Aug 14 14:55 /dev/mtdblock4

brw-rw----    1 root     disk       31,   5 Aug 14 14:55 /dev/mtdblock5

root@am335x-evm:~#

root@am335x-evm:~#

root@am335x-evm:~#

root@am335x-evm:~# flash_erase /dev/mtd1 0 0

flash_erase: error!: /dev/mtd1

             error 13 (Permission denied)

root@am335x-evm:~#

Anything towards the configuration to be changed.  Please let us know.

Regards

Srinivasa

0 Likes

Just a correct in the flash_command.

Previously I have tried mdt1, tried with mtd0, still the same result as below

root@am335x-evm:~# flash_erase /dev/mtd0 0 0

flash_erase: error!: /dev/mtd0

             error 13 (Permission denied)

root@am335x-evm:~#

root@am335x-evm:~#

Regards

Srinivasa

0 Likes

You have changed the permissions of mtd0

# chmod 777 /dev/mtd0

buy you were erasing mtd1 !

# flash_erase /dev/mtd1 0 0

Please try again erasing mtd0. Is the error still there in this case?

Anything in the syslog (/var/log/messages)

0 Likes

If it is still there then it might be related to SElinux or some other mechanism.

I don't think it is a flash problem.

Thanks, Gernot

0 Likes

Thank you very much Gernot.

Let me loot at it.  Will post it here once I found some solution for it.

Regards

Srinivasa

0 Likes

Hi Gernot,

We have old kernel working on the same hardware.  If I run the command "mtd_debug info /dev/mtd0" in the old kernel shows as below:

root@spx-vanguard:~# mtd_debug info /dev/mtd5

mtd.type = MTD_NORFLASH

mtd.flags = MTD_CAP_NORFLASH

mtd.size = 252051456 (240M)

mtd.erasesize = 131072 (128K)

mtd.writesize = 1

mtd.oobsize = 0

regions = 0

root@am335x-evm:~#

If I run the same command with the new kernel (4.14), it is displaying as below:

root@am335x-evm:~# mtd_debug info /dev/mtd0

mtd.type = MTD_ROM

mtd.flags = MTD_CAP_ROM

mtd.size = 524288 (512K)

mtd.erasesize = 268435456 (256M)

mtd.writesize = 1

mtd.oobsize = 0

regions = 0

root@am335x-evm:~#

Now it has become ''MTD_ROM".  I understand it is not related to flash.  Let us know if we need to change anything in dts file.

Regards

Srinivasa

0 Likes

Hi,

In Kernel configuration we have below  options:

config MTD_CFI_I1

        bool "Support 1-chip flash interleave" if MTD_CFI_GEOMETRY default y

        help

          If your flash chips are not interleaved - i.e. you only have one

          flash chip addressed by each bus cycle, then say 'Y'.

config MTD_CFI_I2

        bool "Support 2-chip flash interleave" if MTD_CFI_GEOMETRY default y

        help

          If your flash chips are interleaved in pairs - i.e. you have two

          flash chips addressed by each bus cycle, then say 'Y'.

config MTD_CFI_I4

        bool "Support 4-chip flash interleave" if MTD_CFI_GEOMETRY default n

        help

          If your flash chips are interleaved in fours - i.e. you have four

          flash chips addressed by each bus cycle, then say 'Y'.

config MTD_CFI_I8

        bool "Support 8-chip flash interleave" if MTD_CFI_GEOMETRY default n

        help

          If your flash chips are interleaved in eights - i.e. you have eight

          flash chips addressed by each bus cycle, then say 'Y'.

Which is the corret interleave options correct (1/2/4/8) for our flash chip S70GL02GS?

Regards

Srinivasa

0 Likes

Hi Srinivasa,

MTD_CFI_I1 is the right option for the S70GL02GS as there is no interleaving here (such as e.g. 2x16 to form a 32 bit bus).

The two internal dies are concatenated, so it is still a 16 bit bus.

But having the others enabled as well does not hurt. The driver is then just probing different ways to detect a device.

Best regards,

Gernot

0 Likes

Hello Srinivasa,

Do you have any additional question? Please let me know.

Thank you

Regards,

Bushra

0 Likes

Hi Bushra/Gernot,

Thank you very much for your support.  

At power up, cfi probe function was failing.  Updted the GPMC registers similar to u-boot and probe function in kernel is passing now.

Kernel is able to detect the flash and display the Manufacture ID 0x000001 and chip ID 0x004801.

Appreciate your help again.

Regards

Srinivasa

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

Hi Bushra/Gernot,

During flash write operation, it is able to write only one sector completely and later the system hangs.  I need to power cycle the board.

Since we have old working kernel, I have  compared the code flow.  Code  flow  is the same.  Please find logs of old and new kernel attached.

I understand this may not be a problem from the flash side, just though of getting any input from experts.

Any hint will be of great help.

Regards

Srinivasa

0 Likes