Linux support for S70GL02GS

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

cross mob
Anonymous
Not applicable

Hi,

I am looking for the Linux patch to support the S70GL02GS Flash.  According to this KB article (S70GL02GS Support Under Linux - KBA218976 ), you have to create a Support Case to receive the patch.  I have done so, but I have only received automated replies so far.

I am also interested in how to specify the S70GL02GS in the Device Tree Source (.dts) file that Linux parses when it is loaded.  For a typical CFI-compatible 2Mbit, 128Mx16 NOR Flash, I would expect its entry to look something like this:

  norflash@0,0 {

   #address-cells = <0x1>;

   #size-cells = <0x1>;

   compatible = "cfi-flash";

   reg = <0x0 0x0 0x10000000>;

   bank-width = <0x2>;

   device-width = <0x1>;

But the S70GL02GS is actually two 1Mbit NOR Flash die (S29GL01GS) in the same package.  So there is one external chip select, but internally there are two address-mapped regions that have independent protected sectors and control/status registers.  Perhaps there would be two "reg" declarations to account for the two sets of control registers, one at byte offset 0x8000000?

0 Likes
1 Solution

Hello Mike,

A special attention must be given when handling the dual-die S70GL02GS device. The reason for this is that the commands must be addressed to every die separately (specially the unlock commands: 0x555/0xaa & 0x2AA/0x55) otherwise the commands may not work.

That's why this chip needs to be treated as two separate devices although they're sitting under the same CS#.

So probing the device should be done in two steps, that's why the need for two device entries in the device tree.

These two devices will be located in two consecutive mapped addresses and you will have to run your probing function on these two mapped addresses, of 1Gb each.

You can then chose to use the mtd-concat feature to concatenate your two mtd devices and make them look like one.

Unfortunately, I don't have any linux based example for this chip.

I hope it's clear enough now. Thanks!

Best regards,

Bacem

----

Bacem Daassi

Cypress Semiconductor Corp.

Customer Application Engineering

View solution in original post

4 Replies
BushraH_91
Moderator
Moderator
Moderator
750 replies posted 50 likes received 250 solutions authored

Hello Mike,

Thank you for contacting Cypress Community Forum. We are currently reviewing you request and will get back to you as soon as we find the resolution.

Thank you

Regards,

Bushra

0 Likes

Hello Mike,

Please find below a link to the requested patch:

https://cycorp-my.sharepoint.com/:u:/g/personal/bacd_cypress_com/Ed3Q4oL_J8VIl9Dj_LB-VQUB5m20mLGY3hd...

This is a dual die stack device so your comment is absolutely correct. You should have two separate entries in your device tree, one per die.

Best regards,

Bacem

----

Bacem Daassi

Cypress Semiconductor Corp.

Customer Application Engineering

0 Likes
Anonymous
Not applicable

I am curious as to why you would expect to see two entries in the Device Tree Source file for this flash.

The Linux patch appears to modify the reported device size for the S70GL02GS.  It does not appear to have any effect if the device queried is a S29GL01GS Flash.  If I create two distinct entries in the .dts file, representing individual S29GL01GS dies, it seems like the queried device size will be too large.  With the patch and two entries in the .dts, the S70GL02GS size will be reported twice.

Do you have any examples of the S70GL02GS specified as a cfi-compatible device in an embedded Linux .dts file?  If this Linux patch exists, it must have been used somewhere.  If not, do you have an example of S29GL01GS Flashes at consecutive addresses in a .dts file to model the S70GL02GS?

0 Likes

Hello Mike,

A special attention must be given when handling the dual-die S70GL02GS device. The reason for this is that the commands must be addressed to every die separately (specially the unlock commands: 0x555/0xaa & 0x2AA/0x55) otherwise the commands may not work.

That's why this chip needs to be treated as two separate devices although they're sitting under the same CS#.

So probing the device should be done in two steps, that's why the need for two device entries in the device tree.

These two devices will be located in two consecutive mapped addresses and you will have to run your probing function on these two mapped addresses, of 1Gb each.

You can then chose to use the mtd-concat feature to concatenate your two mtd devices and make them look like one.

Unfortunately, I don't have any linux based example for this chip.

I hope it's clear enough now. Thanks!

Best regards,

Bacem

----

Bacem Daassi

Cypress Semiconductor Corp.

Customer Application Engineering