- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Labels:
-
Parallel NOR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Srinivasa,
Yes, I'm sure. Please refer to the datasheet. The Address (A26-A0) and Data (DQ15-DQ0) are independent (not multiplexed).
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you very much Gernot.
Let me loot at it. Will post it here once I found some solution for it.
Regards
Srinivasa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Srinivasa,
Do you have any additional question? Please let me know.
Thank you
Regards,
Bushra
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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