• State TI Thinks Resolved
  • Locked Locked
  • Replies 68 replies
  • Answers 2 answers
  • Subscribers 102 subscribers
  • Views 4245 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM3352: NOR flash issues in kernel

Srinivasa Wunnimani1
Intellectual 600 points
Part Number: AM3352
Other Parts Discussed in Thread: SN74CBTLV16212, AM3359, SYSCONFIG

Hi,

We are trying to port from U-boot V2013.10 to V2018.01 and Kernel from V3.2 to V4.14.

Hardware remains the same.

TI SDK Used: V05.03.00.07.confg_dts_old_and_new_kernel_log.zip

Hardware Info:

Processor is AM3352 and it is interfaced to parallel NOR flash from Cypress (part number :S70GL02GS) via GPMC CS0.

Cypress guys provided an excellent support and here is the full discussion from the bootloader till the kernel problem. (First part of the discussion is on U-boot and next is on Kernel).

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

 We have successfully ported u-boot and all features are working at the u-boot level.

 NOR flash info from u-boot:

=> 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

 Other commands erase and cp are working at u-boot level.

Problem Statement:  We have problem in bringing the NOR flash up in kernel. 

 

Old Kernel (3.2.0): All below commands did not work as expected. No concept of dts here and we have .config file.

        cat /proc/partitions

        ls -la /dev/mtd*

        mtdinfo

        mount

        mtd_debug info /dev/mtd0

My modifications in new Kernel

  • Applied the patch provided by Cypress team.
  • Updated the DTS per hardware (I have attached GPMC changes).
  • In new kernel, I have enabled all MTD related configuration except for enabling CONFIG_MTD_CHAR (because this option is not available in new kernel). 

Observation 1:

Since CONFIG_MTD_CHAR is not available in new kernel and to understand the importance of CONFIG_MTD_CHAR, I have disabled this configuration in the old kernel and tested:

Below commands are not working.

       cat /proc/partitions

        ls -la /dev/mtd*

        mtdinfo

        mount

        mtd_debug info /dev/mtd0

     CONFIG_MTD_CHAR is a must parameter.    

Observation 2:

In old kernel mtdchar.c is being compiled based on CONFIG_MTD_CHAR. 

In the new kernel drivers/mtd/mtdchar.c is being compiled even though we don’t have CONFIG_MTD_CHAR enabled, it is taken care if CONFIG_MTD is enabled.

Additional changes:

Since code was not entering "drivers/mtd/chips/cfi_probe.c", I have enabled MTD_PHYSMAP_OF and tested.

I have attached kernel configuration of old and new kernel.

Please find attached kernel log file for old kernel (working) and new kernel (not working).

Can you please let me know what is that I am missing?

If you need any more input from my side please let me know.

Regards

Srinivasa

  • 0
    Intellectual 600 points

    Hi,

    I have very interesting observation and little progress on this.

    I have enabled only “CONFIG_MTD_OF_PARTS” in the kernel configuration under location:

    Prompt: OpenFirmware partitioning information support

                    Location:

                                    -> Device Drivers

    -> Memory Technology Device (MTD) support (MTD [=y])

    I can see partitions during kernel boot as below:

    [   2.994890]

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

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

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

    [   3.032845] 0x000000080000-0x0000000a0000 : "uboot-env"

    [   3.040386] 0x0000000a0000-0x0000005a0000 : "Current kernel"

    [   3.048175] 0x0000005a0000-0x000000aa0000 : "Backup kernel"

    [   3.055885] 0x000000aa0000-0x000000fa0000 : "Failsafe kernel"

    [   3.063597] 0x000000fa0000-0x000010000000 : "File System"

    [   3.071011]

    [   3.071011]

    Please refer the attached file Kernel log “NOR_FLASH_MOUNTED_AS_ROM_kernel_log.txt”

    Problem:

    It has mouted NOR flash as MTD_ROM as shown 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

    In the old Kernel (which is working fine) it is mounted as below:

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

    mtd.type = MTD_NORFLASH

    mtd.flags = MTD_CAP_NORFLASH

    mtd.size = 524288 (512K)

    mtd.erasesize = 131072 (128K)

    mtd.writesize = 1

    mtd.oobsize = 0

    regions = 0

    Now I feel DTS file is fine.   I need to work only on Kernel configuration. Is my understanding correct? 

    How to make it to (MTD_NORFLASH/ MTD_CAP_NORFLASH)? What changes I must do in the configuration?

    I have attached kernel log and update configuration file of new kernelNOR_FLASH_mounted_as_ROM.zip

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    TI__Mastermind 43735 points

    Hello Srinivasa,

    I am wondering if Uboot is detecting the type correctly because you could compare the Cypress patches to ensure the same logic is applied in Kernel.

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 600 points

    Hi,

    As explained before, we had a problem of NOR flash being mounted as “MTD_ROM”.  This is  resolved now.

    Fix:   On powerup, kernel was not able to detect the NOR FLASH because it was failing in the probe function.  Since the hardware is good, my suspect was on GPMC.  Updated GPMC config registers similar to old kernel (or U-boot) and later cfi_flash_probe function was success.

    Now kernel is able to detect the NOR FLASH and all the partitions are mounted as MTD_NORFLASH (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:~#

     

    Next question:  During flash write operation, it is able to write only one sector completely and later the system hangs.  I need to a 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.

     06_Sep_2019.zip

    If you can give any hint on this will be of great help.

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    Intellectual 600 points

    Hi,

    Any input on this please.

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    Intellectual 600 points

    Hi Krunal,

    Sorry, missed your message.

    I once again verified u-boot.  In u-boot only 128 MB is being detected.  S70GL02GS part as two chips, 128 MB each (256 MB total).

    In Old kernel during bootup message states "number of CFI chips: 2" but in new kernel, "number of CFI chips: 1"

    Since old u-boot is configured for 128 MB, in the old kernel, they have reconfigured the GPMC by writing 0x50 to GPMC_CONFIG7_0 (0x5000_0078) as below in file arch/arm/mach-omap2/board.c.

    void __iomem *io = ioremap(0x50000078, 4);

    writel(0, io);

    writel(0x50, io);

    Old kernel is able to access complete 256 MBytes of flash.

    Since we don't have board specific functionally in new kernel (because of DTS file). I am trying to write 0x50 to GPMC_CONFIG7_0 in dts file as below:

    reg = <0x50000078 0x00000050>; /* Adding this is causing Kernel panic*/

    My understanding: In dts file, since status = “okay”; which indicates that the device is operational and it is causing Kernel panic.

    If I comment “Status = okay”, GPMC is never enabled and flash is not detected.

    Trial 1:

    Since u-boot is configured for 128 MB, tried configuring u-boot for 256 MB by writing 0x50 to GPMC_CONFIG7_0 (0x50000078)

    New uboot (V2018.01) is not coming up!!!.

    Old uboot (V2013.10), is having below error and it keeps rebooting.

    Flash: data abort

    MAYBE you should read doc/README.arm-unaligned-accesses

    pc : [<8f7770b0>] lr : [<8f776c48>]
    sp : 8f637e38 ip : 00000000 fp : 8f79207c
    r10: 8081487c r9 : 8f637f38 r8 : 00000000
    r7 : 0000140c r6 : 8ffbaa48 r5 : 00000000 r4 : 08000000
    r3 : 0000f0f0 r2 : 000000f0 r1 : 8ffbaa48 r0 : 00000001
    Flags: Nzcv IRQs off FIQs on Mode SVC_32
    Resetting CPU ...

     

    Trial 2:

    As suggested in below link (which has similar problem but it is for NAND), tried various options but did not workout.

    https://e2e.ti.com/support/processors/f/791/t/783310

     

    Trial 3:

    Similar to old kernel tried to write 0x50 to GPMC_CONFIG7_0, but this is causing kernel pannic.

     

    Question: 

    1. How do I configure gpmc register GPMC_CONFIG7_0 (0x50000078) to 0x50 in the new kernel?
    2. As we mentioned in the previous discussion, still i have problem of writing only one sector.  I thought of making it to 256 MB and look at my sector write problem (may be this may get resolved if my flash is detected for 256 MB).

    Attached log for kernel boot log for below scenarios.

    1. Writing 0x50 to reg GPMC_CONFIG7_0 (Kernel_panic.txt)

    2. Writing 0x50 to reg GPMC_CONFIG7_0 is commented.  (Kernel_booting.txt)

    3. "Status = Okay" commented.(status_okay_ommented.txt)

    4. dts node of gpmc.

    Regards

    Srinivasa

    nor_flash_issue.zip

  • 0 in reply to Srinivasa Wunnimani1
    Intellectual 600 points

    From the old kernel board specific file, here are few inputs:

    #define NOR_BASE 0x10000000
    #define SZ_256M 0x10000000
    #define IORESOURCE_MEM 0x00000200  (defined in include/linux/ioport.h)

    static struct resource norflash_resource = {
    .start = NOR_BASE,
    .end = NOR_BASE + SZ_256M - 1,
    .flags = IORESOURCE_MEM,
    };

    Update from DTS file from my end as below (changed the base address from 0x08000000 to 0x10000000), but still kernel panic.

    ranges = <0 0 0x10000000 0x0FFFFFFF>;

    Question:
    How do we take care of IORESOURCE_MEM flag in new kernel?


    Regards
    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    Intellectual 600 points

    Hi,

    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,
    },
    }

    Please find "platform_device" information added.

    Regards
    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    TI__Mastermind 43735 points

    Hello Srinivasa,

    I am wondering if you could please refer to the following documents to ensure required properties are configured correctly: <kernel_dir>/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
    <kernel_dir>/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 600 points

    Hi Krunal,

    Probe function in platform driver is not being called.  Below is the output of old and new kernel.

    Old kernel:

    Platform driver init function "physmap_init" is being called followed by physical map probe function "physmap_flash_probe" successfully as below:

    [    4.703106] Srini debug @ line 239 in function physmap_init in file drivers/mtd/maps/physmap.c

    [    4.703113]

    [    4.719892] Srini debug @ line 92 in function physmap_flash_probe in file drivers/mtd/maps/physmap.c

    [    4.719903]

    [    4.737156] physmap platform flash device: 10000000 at 10000000

     

    New Kernel:

    Platform driver init function "physmap_init" is being called but physical map probe function "physmap_flash_probe" is not being called!!!

    [    2.017770] Srini debug @ line 251 in function physmap_init in file drivers/mtd/maps/physmap.c

    [    2.017770]

    [    2.017770]

    [    2.034215] Value of err is 0

     

    Result:

                    GMPC is not able to see full external memory available and gpmc_mem_init() function fails to get memory configuration information.

     

    Verified:

                    CONFIG_MTD_PHYSMAP is enabled in both old and new kernel.   Even though init function "physmap_init" is being called, I am not sure why physical map probe function "physmap_flash_probe()" is not being called?

     


    | Symbol: MTD_PHYSMAP [=y] |
    | Type : tristate |
    | Prompt: Flash device in physical memory map |
    | Location: |
    | -> Device Drivers |
    | -> Memory Technology Device (MTD) support (MTD [=y]) |
    | (1) -> Mapping drivers for chip access |
    | Defined at drivers/mtd/maps/Kconfig:11 |
    | Depends on: MTD [=y] && HAS_IOMEM [=y] && (MTD_CFI [=y] || MTD_JEDECPROBE [=n] || MTD_ROM [=y] || MTD_LPDDR [=n]) |

    | Selected by: MACH_XCEP [=n] && ARCH_PXA [=n]

    In configuration, I have taken care of

    "MTD [=y] && HAS_IOMEM [=y] && (MTD_CFI [=y] || MTD_JEDECPROBE [=n] || MTD_ROM [=y] || MTD_LPDDR [=n]) "

    However MACH_XCEP and ARCH_PXA is not found in old and new kernel.

    I have attached dts, old and new kernel log files. 

     

    Any input/suggestion will be helpful.

     

    Regards

    Srinivasa

    24_Sep_2019.zip

  • 0 in reply to Srinivasa Wunnimani1
    Intellectual 600 points

    Hi ,

    Further exploring on why physmap_flash_probe() is not being called, here is my observation.

     Old Kernel:

                    gpmc_driver is being registered using module_platform_driver(gpmc_driver) and hence not being called in old kernel.

                    physmap_flash_driver is also being registered using platform_driver_register() and hence physmap_flash_probe() is being called.

     New Kernel:

                    gpmc_driver is being registered using platform_driver_register(), __init int gpmc_init is being invoked, followed by gpmc_probe is being called.

                    physmap_flash_driver is also being registered using platform_driver_register(),  __init physmap_init() is being called but not   physmap_flash_probe()

     

    Question:  Why gpmc_probe() is taken precedence over physmap_flash_probe() in new kernel?

     

     Since gpmc driver is being used as probe function, started debugging gpmc_probe() from file drivers/memory/omap-gpmc.c

     Here we have below problems

    1. With GPMC_CONFIG7_0 register:
    1. At power-up GPMC_CONFIG7_0 was 0x848
    2. During  gpmc_mem_init in gpmc_probe GPMC_CONFIG7_0  is 0xf40 (This value makes memory as 16 MB!!!).
    3. Later dts file is parsed and GPMC_CONFIG7_0 is 0x50.
    • Unable to insert memory because of resource busy.
    1. Tried by CONFIG_MTD_PHYSMAP in configuration, still the same problem.

     

    Please find new_kernel_log attached.

    New_kernel_log.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    =>
    => fatload mmc 0:1 0x88000000 am335x-evmsk.dtb
    35338 bytes read in 8 ms (4.2 MiB/s)
    => setenv bootargs console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
    => fatload mmc 0:1 0x82000000 uImage
    3834432 bytes read in 530 ms (6.9 MiB/s)
    => bootm 0x82000000 - 0x88000000
    ## Booting kernel from Legacy Image at 82000000 ...
    Image Name: Linux-4.14.79-ge669d52447
    Created: 2019-09-25 7:44:11 UTC
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 3834368 Bytes = 3.7 MiB
    Load Address: 82000000
    Entry Point: 82000000
    Verifying Checksum ... OK
    ## Flattened Device Tree blob at 88000000
    Booting using the fdt blob at 0x88000000
    Loading Kernel Image ... OK
    Loading Device Tree to 8df33000, end 8df3ea09 ... OK
    Starting kernel ...
    Srini machid : 3589
    Srini r2 : 8df33000
    Jumping to 82000000
    Bye bye u-boot :(
    [ 0.000000] Booting Linux on physical CPU 0x0
    [ 0.000000] Linux version 4.14.79-ge669d52447 (pcadmin@pcadmin-OptiPlex-790) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)9
    [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
    [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
    [ 0.000000] OF: fdt: Machine model: TI AM335x EVM-SK
    [ 0.000000] Memory policy: Data cache writeback
    [ 0.000000] efi: Getting EFI parameters from FDT:
    [ 0.000000] efi: UEFI not found.
    [ 0.000000] cma: Reserved 48 MiB at 0x8a800000
    [ 0.000000] CPU: All CPU(s) started in SVC mode.
    [ 0.000000] AM335X ES2.1 (neon)
    [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 64960
    [ 0.000000] Kernel command line: console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
    [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
    [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
    [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
    [ 0.000000] Memory: 197296K/262144K available (8192K kernel code, 315K rwdata, 2460K rodata, 1024K init, 267K bss, 15696K reserve)
    [ 0.000000] Virtual kernel memory layout:
    [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
    [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
    [ 0.000000] vmalloc : 0xd0800000 - 0xff800000 ( 752 MB)
    [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
    [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
    [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
    [ 0.000000] .text : 0xc0008000 - 0xc0900000 (9184 kB)
    [ 0.000000] .init : 0xc0c00000 - 0xc0d00000 (1024 kB)
    [ 0.000000] .data : 0xc0d00000 - 0xc0d4ed40 ( 316 kB)
    [ 0.000000] .bss : 0xc0d4ed40 - 0xc0d91bec ( 268 kB)
    [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
    [ 0.000000] Preemptible hierarchical RCU implementation.
    [ 0.000000] Tasks RCU enabled.
    [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
    [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
    [ 0.000000] GPMC_REVISION = 60
    [ 0.000000] GPMC_SYSCONFIG = 8
    [ 0.000000] GPMC_SYSSTATUS = 1
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     

    Any input/suggestion will be helpful.

     

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    Intellectual 600 points

    Hi All,

    We are using Kernel V4.14 (From TI SDK 5.03.00.07)

    Please provide your input to below questions. It will be helpful for further debugging.

    1. Which is the platform driver used for CFI NOR flash in Kernel V4.14?
    2. Does the Kernel depend on Bootloader in GPMC driver for memory initialization?
    3. Do we need to reconfigure GPMC in Kernel or does it continue/take if from Bootloader?

     

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    TI__Mastermind 43735 points

    Hello Srinivasa,

    1. Our EVMs do not really support parallel NOR boot but please feel free to refer to the following document as a reference to setup parallel nor. Also, could you please share where you are copying kernel from (are you doing XIP?)?

    2/3. Both Uboot and Kernel use different DTS files. For example, if you navigate to the <u_boot_dir>/arch/arm/dts/am335x-evm.dts, it will define all the peripherals needed for Uboot to execute. Similarly, if you navigate to the <kernel_dir>/arch/arm/boot/dts/am335x-evm.dts, Kernel defines all the peripherals needed for successful Linux boot.

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 600 points

    Hi Krunal,

    My partitons are being created and I am using flashcp command to copy the file to partitons.

    flashcp -v uImage /dev/mtd2.

    In gpmc driver, under gpmc_probe function:

    First gpmc_mem_init is done.

    and parsing of dts file is done in gpmc_probe_dt_children() later.

    Now for gpmc_mem_init() the input is only from bootloader.   I am not sure how what is done before gpmc_probe() is being called.  

    So I want to know if Kernel depends on Bootloader? 

    Regards

    Srinivasa

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    TI__Mastermind 43735 points

    Hello Srinivasa,

    Kernel inherits the changes made in Uboot but Kernel will initialize various components based on the properties defined in the DT files. In the omap-gpmc driver, before the function "gpmc_mem_init" is called, the function "gpmc_probe_dt" is executed to extract a couple of properties from the DT files.

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 600 points

    Hi Krunal,

    http://processors.wiki.ti.com/index.php/AM335x_General_Purpose_EVM_HW_User_Guide#NOR_Flash_Memory

    From the above link, TI has GP daughter board which has NOR flash Numonyx pn#M29W128GL (which is parallel NOR) interfaced to GPMC.

    However, it states “boot from NOR is currently not supported on EVM”.

    It not "boot from NOR", does TI have tried to write the u-boot and uImage to NOR flash?

    What are the features currently TI supports for GP daughter board with NOR flash (Numonyx pn#M29W128GL)?

    http://processors.wiki.ti.com/index.php/AM335x_General_Purpose_EVM_HW_User_Guide#SPI_Flash_Memory

    Same link has a section for SPI flash memory.

    Which is the platform driver used for SPI flash in Kernel V4.14?

     

    I am finding hard to find schematics and other details of GP daughter board (Numonyx pn#M29W128GL & Winbond W25Q64CV) on the net. Please share the details.

     

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    TI__Mastermind 43735 points

    Hello Srinivasa,

    Please refer to the "Design files" section on the following page: http://www.ti.com/tool/TMDXEVM3358#technicaldocuments and the zip files contains all the schematics. 

    Unfortunately, TI does not support booting from NOR flash and SPI flash. The supported features are listed on the following page: http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_U-Boot.html#supported-features-in-u-boot. In the past, SPI flash was used for booting the board to the Uboot prompt. The flash is only 64Mb and it is not possible to load the filesystem+Kernel into a small memory. 

    Regards,
    Krunal 

  • 0 in reply to Krunal Bhargav34
    Intellectual 600 points

    Hi Krunal,

    In my previous post on Sep 25, 2019 4:21 PM, I have mentioned below statements:

    New Kernel:

    gpmc_driver is being registered using platform_driver_register(), __init int gpmc_init is being invoked, followed by _probe is being called.  

    physmap_flash_driver is also being registered using platform_driver_register(), __init physmap_init() is being called but not   physmap_flash_probe()

    Question: Why gpmc_probe() is taken precedence over physmap_flash_probe() in new kernel?

    Solution:

    In new kernel after enabling below options in kernel configurtions (of course which was not done in old kernel), now I am able to enter physmap_flash_probe(), able to below statment in Kernel log

    [    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. Find the kernel log attached.

    physmap_flash_probe() should be the right platform driver for this, I should fix this kernel panic to proceed further. 

    Looking for your opinion/suggestions on this please.

    Regards

    Srinivasa

    New_kernel_log_04_Oct_2019.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    U-Boot SPL 2018.01-00569-g7b4e473-dirty (Oct 04 2019 - 03:55:19)
    Trying to boot from MMC1
    *** Warning - bad CRC, using default environment
    U-Boot 2018.01-00569-g7b4e473-dirty (Oct 04 2019 - 03:55:19 +0530)
    CPU : AM335X-GP rev 2.1
    Model: TI AM335x EVM-SK
    DRAM: 256 MiB
    256 MiB
    OF: translating address: 0070e044
    OF: parent translation for: 00000000
    OF: one level translation: 0070e044
    OF: translating address: 00c00448
    OF: parent translation for: 00000000
    OF: one level translation: 00c00448
    OF: translating address: 00c01a48
    OF: parent translation for: 00000000
    OF: one level translation: 00c01a48
    OF: translating address: 00e01a48
    OF: parent translation for: 00000000
    OF: one level translation: 00e01a48
    OF: translating address: 0090e044
    OF: parent translation for: 00000000
    OF: one level translation: 0090e044
    Flash: OF: translating address: 00000448
    OF: parent translation for: 00000000
    OF: one level translation: 00000448
    device interface is 1
    found port 2 chip 2 port 16 bits chip 16 bits
    ERROR: too many flash sectors
    [CKR] flash_real_protect() - something tried to protect - but disregarded. Sector#: 0
    [CKR] flash_real_protect() - something tried to protect - but disregarded. Sector#: 1
    [CKR] flash_real_protect() - something tried to protect - but disregarded. Sector#: 2
    256 MiB
    Srini MMC: OF: translating address: 00000648
    OF: parent translation for: 00000000
    OF: one level translation: 00000648
    OMAP SD/MMC: 0
    *** Warning - bad CRC, using default environment
    Net: No ethernet found.
    TI-SDK U-Boot
    Hit any key to stop autoboot: 0
    =>
    =>
    => fatload mmc 0:1 0x88000000 am335x-evmsk.dtb
    35237 bytes read in 9 ms (3.7 MiB/s)
    => setenv bootargs console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
    => fatload mmc 0:1 0x82000000 uImage
    3838528 bytes read in 530 ms (6.9 MiB/s)
    => bootm 0x82000000 - 0x88000000
    ## Booting kernel from Legacy Image at 82000000 ...
    Image Name: Linux-4.14.79-ge669d52447
    Created: 2019-10-04 1:39:00 UTC
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 3838464 Bytes = 3.7 MiB
    Load Address: 82000000
    Entry Point: 82000000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Srinivasa Wunnimani1
    TI__Mastermind 43735 points

    Hello Srinivasa,

    Based on your kernel logs, I am observing two kernel panics and lets ensure they are not related to each other. The first panic is at the following location:

    [    0.122422] omap_hwmod: rtc: no dt node
[    0.122459] ------------[ cut here ]------------
[    0.122525] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2494 _init.constprop.20+0x1e0/0x4a4
[    0.122546] omap_hwmod: rtc: doesn't have mpu register target base
[    0.122565] Modules linked in:
[    0.122612] CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.79-ge669d52447 #1
[    0.122631] Hardware name: Generic AM33XX (Flattened Device Tree)
[    0.122650] Backtrace: 
[    0.122726] [<c010b6f0>] (dump_backtrace) from [<c010b9d4>] (show_stack+0x18/0x1c)
[    0.122760]  r7:00000009 r6:00000000 r5:c0a9891c r4:cf03fe20
[    0.122809] [<c010b9bc>] (show_stack) from [<c08251a8>] (dump_stack+0x24/0x28)
[    0.122857] [<c0825184>] (dump_stack) from [<c0128aa8>] (__warn+0xe8/0x100)
[    0.122896] [<c01289c0>] (__warn) from [<c0128b00>] (warn_slowpath_fmt+0x40/0x48)
[    0.122931]  r9:000000d5 r8:c0c3b820 r7:00000000 r6:c0d0ae84 r5:00000000 r4:c0a98bd0
[    0.122968] [<c0128ac4>] (warn_slowpath_fmt) from [<c0c0ac00>] (_init.constprop.20+0x1e0/0x4a4)
[    0.122993]  r3:c0acfb14 r2:c0a98bd0
[    0.123012]  r4:c0d0ae40
[    0.123047] [<c0c0aa20>] (_init.constprop.20) from [<c0c0b3f8>] (__omap_hwmod_setup_all+0x48/0x108)
[    0.123083]  r10:c0d4ef80 r9:000000d5 r8:c0c3b820 r7:c0d4ef80 r6:c0c0b3b0 r5:c0d07ee0
[    0.123103]  r4:c0d0ae40
[    0.123137] [<c0c0b3b0>] (__omap_hwmod_setup_all) from [<c0101974>] (do_one_initcall+0x4c/0x170)
[    0.123161]  r5:00000000 r4:ffffe000
[    0.123203] [<c0101928>] (do_one_initcall) from [<c0c00eb4>] (kernel_init_freeable+0x148/0x1e4)
[    0.123236]  r8:c0c3b820 r7:c0d4ef80 r6:00000003 r5:c0c4c3b4 r4:c0b666fc
[    0.123286] [<c0c00d6c>] (kernel_init_freeable) from [<c08381d8>] (kernel_init+0x10/0x114)
[    0.123322]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c08381c8
[    0.123341]  r4:00000000
[    0.123378] [<c08381c8>] (kernel_init) from [<c0107d28>] (ret_from_fork+0x14/0x2c)
[    0.123402]  r5:c08381c8 r4:00000000
[    0.123441] ---[ end trace 63ea1ca06bbd7840 ]---

    In order to fix the above issue, please refer to the following response from my colleague. Also, if we disable the gpmc/nor entry from the dts file, are you able to boot to kernel without any problems? Based on the kernel command line, I am assuming you are booting kernel from the SD card.

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 600 points

    Hi Krunal,

    I have disabled in "am33xx_l4_wkup__rtc entry" in "arch/arm/mach-omap2/omap_hwmod_33xx_data.c". RTC related error in kernel log "omap_hwmod: rtc: no dt node" is not found.


    I have disabled the gpmc/nor entry from the dts file by addeing below statement to nor child node. (dts file attached: nor_child_node_disabled.dts)
    status = "disabled";
    still we have Kernel panic problem.

    I have deleted the gpmc/nor entry from the dts file (dts file attached: nor_child_node_deleted.dts)
    still we have Kernel panic problem.

    Find the kernel log file attached.


    Yes, we are booting kernel from SD card.

    Regards
    Srinivasa

    10_Oct_2019.zip

  • 0 in reply to Srinivasa Wunnimani1
    Intellectual 600 points

    Hi,

    This thread has undergone a very long discussion.

    In my post on "8/30/2019 2:45:00 PM", we had problem of "NOR falsh is mounted as MTD_ROM". This was resolved by making GPMC config registers similar to old kernel (or U-boot) and later cfi_flash_probe function was success.
    Here we are able to boot the kernel without any problem.

    Still we had below problems:

    1. 256 MB NOR FLASH is being detected as 128 MB.
    2. We are unable to write more than one sector.


    Becasue of below reason, updated the kernel configuration.

    Old kernel:
    Platform driver init function "physmap_init" is being called followed by physical map probe function "physmap_flash_probe".

    New Kernel:
    Platform driver init function "physmap_init" is being called but physical map probe function "physmap_flash_probe" is not being called!!!

    After updting the Kernel configuration with below parameters, physmap_flash_probe() is being called.  

    New kernel configurtion is updated with below options:
    CONFIG_MTD_PHYSMAP_COMPAT=y

    CONFIG_MTD_PHYSMAP_START=0x10000000

    CONFIG_MTD_PHYSMAP_LEN=0x10000000

    CONFIG_MTD_PHYSMAP_BANKWIDTH=2


    Now I have kernel panic with above configuration enabled.


    I have attached the brief overview of our discussion in the attached spreadsheet.

    I  have printed GPMC and control registers (pin mux registers) at u-boot and at diffrent stages in kernel.  Please find the log attached.

    Note:  GPMC_CONFIG7_0 = 0x848.

    In u-boot we have NOR FLASH configured for 128 Mb and later in kernel we are trying to make it as 256 MB (ie. GPMC_CONFIG7_0 = 0x50).

    Atlease with this configuration, we expect erase/write should be fine.

    Question:

    Also, will you boot Kernel (XIP) from the NOR device and are you using a muxed or non-muxed flash device?

    Currently we are booting kernel from SD-card and trying to write u-boot and kernel to NOR flash.

    Flash is non-muxed whereas the interface logic has muxed based addressing.


    Regards
    Srinivasa

    Summary.xlsx

    4666.Kernel_log_1.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    U-Boot SPL 2018.01-00569-g7b4e473-dirty (Oct 10 2019 - 03:06:53)
    Trying to boot from MMC1
    *** Warning - bad CRC, using default environment
    U-Boot 2018.01-00569-g7b4e473-dirty (Oct 10 2019 - 03:06:53 +0530)
    CPU : AM335X-GP rev 2.1
    Model: TI AM335x EVM-SK
    DRAM: 256 MiB
    256 MiB
    OF: translating address: 0070e044
    OF: parent translation for: 00000000
    OF: one level translation: 0070e044
    OF: translating address: 00c00448
    OF: parent translation for: 00000000
    OF: one level translation: 00c00448
    OF: translating address: 00c01a48
    OF: parent translation for: 00000000
    OF: one level translation: 00c01a48
    OF: translating address: 00e01a48
    OF: parent translation for: 00000000
    OF: one level translation: 00e01a48
    OF: translating address: 0090e044
    OF: parent translation for: 00000000
    OF: one level translation: 0090e044
    Flash: OF: translating address: 00000448
    OF: parent translation for: 00000000
    OF: one level translation: 00000448
    device interface is 1
    found port 2 chip 2 port 16 bits chip 16 bits
    ERROR: too many flash sectors
    [CKR] flash_real_protect() - something tried to protect - but disregarded. Sector#: 0
    [CKR] flash_real_protect() - something tried to protect - but disregarded. Sector#: 1
    [CKR] flash_real_protect() - something tried to protect - but disregarded. Sector#: 2
    256 MiB
    Srini MMC: OF: translating address: 00000648
    OF: parent translation for: 00000000
    OF: one level translation: 00000648
    OMAP SD/MMC: 0
    *** Warning - bad CRC, using default environment
    Net: No ethernet found.
    TI-SDK U-Boot
    Hit any key to stop autoboot: 0
    =>
    =>
    => print_gpmc_regs
    GPMC_REVISION = 60
    GPMC_SYSCONFIG = 8
    GPMC_SYSSTATUS = 1
    GPMC_IRQSTATUS = 0
    GPMC_IRQENABLE = 0
    GPMC_TIMEOUT_CONTROL = 1ff0
    GPMC_ERR_ADDRESS = 0
    GPMC_ERR_TYPE = 0
    GPMC_CONFIG = 200
    GPMC_STATUS = 101
    GPMC_CONFIG1_0 = 1210
    GPMC_CONFIG2_0 = 101000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Srinivasa Wunnimani1
    TI__Mastermind 43735 points

    Hello Srinivasa,

    Thank you for summarizing the results in an excel file and we are currently reviewing the information you have shared. I will get back to you within 24 hours. 

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    TI__Mastermind 43735 points

    Hello Srinivasa,

    While reviewing the logs, we noticed that the GPMC_CONFIG7_0 register is set to the following value: 0x848. This translates into chip-select size of 128 Mbytes and the BASEADDRESS to 0x8000000 (bit for A27=1, all other Ax=0). Please update the CONFIG_MTD_PHYSMAP_START to 0x8000000 and the CONFIG_MTD_PHYSMAP_LEN to 0x8000000. 

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 600 points

    Hi Krunal,

    Thanks for your input.

    Experiment 1:

    I have updated the CONFIG_MTD_PHYSMAP_START and CONFIG_MTD_PHYSMAP_LEN as below:

    Modification 1 -> Configuration:
    CONFIG_MTD_PHYSMAP_COMPAT=y
    CONFIG_MTD_PHYSMAP_START=0x8000000
    CONFIG_MTD_PHYSMAP_LEN=0x8000000
    CONFIG_MTD_PHYSMAP_BANKWIDTH=2
    CONFIG_MTD_PHYSMAP_OF=y

    Also, updted the dts file of gpmc node and NOR child node accordingly as below:

    Modification 2 -> DTS:
    &gpmc {
    . . .

    /* <cs-number> 0 <physical address of mapping> <size> */
    ranges = <0 0 0x08000000 0x08000000>;

    nor@0,0 {
    /* reg = <0 0x00000000 0x10000000>; */
    reg = <0 0x00000000 0x08000000>;

    . . .

    }


    Modification 3 -> C Code:
    Since old kernel (version 3.2.0) is working file, I have made all *.C files in new kernel under "drivers/mtd/chips" same as old kernel. (except for some naming conventions) and introduced printk.

    Observations:

    1. Old kernel gpmc driver is never been called.
    2. We don't have kernel panic but partitions are not mounted!!!
    3. Code flow in all the C files under "drivers/mtd/chips/*.c" is same except that in old kernel it is probing twice to meet the 256 MB configuration as below:
    4. Code flow in "drivers/mtd/maps/physmap.c" is same for old and new kernel.
    5. There are no errors in GPMC driver.

    [ 6.042219] Srini debug @ line 386 in function genprobe_ident_chips in file drivers/mtd/chips/gen_probe.c
    [ 6.042227]
    [ 6.042230]
    [ 6.059930]
    [ 6.059933]
    [ 6.059935]
    [ 6.059938] Srini debug @ line 75 in function cfi_probe_chip in file drivers/mtd/chips/cfi_probe.c
    [ 6.059945]
    [ 6.059948]
    [ 6.077022] physmap-flash.0: Found 1 x16 devices at 0x8000000 in 16-bit bank
    [ 6.084384] CFI Success

    Please find the logs attached as below:


    Old Kernel: Old_Kernel_log.txt
    New Kernel: New_Kernel_log_with_CONFIG_MTD_PHYSMAP_COMPAT_enabled.txt
    DTS File: gmpc_node_dts.txt

    Experiment 2:
    Disabled CONFIG_MTD_PHYSMAP_COMPAT, recompiled the kernel, and tested.

    Observations:

    1. Partitions are mounted.

      1. root@am335x-evm:~# cat /proc/mtd
        dev: size erasesize name
        mtd0: 00080000 00020000 "uboot"
        mtd1: 00020000 00020000 "uboot-env"
        mtd2: 00500000 00020000 "Current kernel"
        mtd3: 00500000 00020000 "Backup kernel"
        mtd4: 00500000 00020000 "Failsafe kernel"

    2. Code flow in all the C files under "drivers/mtd/chips/*.c" is same except that in old kernel it is probing twice as mentioned above.
    3. Unable to write file larger than sector size (128 KB).
    4. There are no errors in GPMC driver.

    In summary, now I have verified modules:

    1. CFI Chip driver:
      1. Made "drivers/mtd/chips/*.c" same for old and new kernel
    2. GPMC driver:
      1. No errors observed.
    3. PHYMAP driver:
      1. drivers/mtd/maps/physmap.c flow is same as old kernel.

    Next suspect:

    From the kernel log it is noticed that GPMC configurations especially (GPMC_CONFIG7_0 = 0x848) is carry forwarded to kernel.

    In the old kernel, they are updating 0x50 (256 MB and base address of 0x10000000) to GPMC_CONFIG7_0 in the baord file and we don't have this option in new kernel.

    Next option I will be looking is to configure bootloader for 256 MB with base address of 0x10000000. I have tried this earlier, writing 0x50 to GPMC_CONFIG7_0 causes the system to hang and I have to do a pwoer cycle.

    Any suggestions/input please let us know.

    Regards
    Srinivasa

    11_Oct_2019.zip

  • 0 in reply to Srinivasa Wunnimani1
    TI__Mastermind 43735 points

    Hello Srinivasa,

    In the driver file, <u-boot>/arch/arm/mach-omap2/mem-common.c, there are two relevant CONFIG options that would need to be modified to describe NOR flash size and memory address: CONFIG_SYS_FLASH_SIZE and CONFIG_SYS_FLASH_BASE. The default values are defined in the am335x_evm.h file and please update the values based on your setup. 

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 600 points

    Hi Krunal,

    Thanks for your input. Now I am able to configure u-boot for 256 MB and NOR FLASH base address to 0x10000000.
    At u-boot, I am able to make GPMC_CONFIG7_0 to 0x50 and this is carry forwarded to Kernel.


    With u-boot being made as 256 MB and NOR FLASH base address to 0x10000000, I have carried few tests as per the spreadsheet attached. Overall, I have covered below blocks & it is made similar to old kernel:

    • CFI Driver (drivers/mtd/chips)
    • PHYAMAP driver code flow
    • GPMC configurations
    • GPMC driver (This is not being called in old kernel).
    • GPMC_CONFIG_7_0 is made as 0x50 from u-boot. (in old kernel, it is hard coded) and it is carry-forwarded to Kernel.

    Surprisingly none of the test cases is working. Towards this I have below questions:

    • Why kernel is not probing for 2 chips (256 MB)?
    • Why with 1 chip detected (128 MB), multiple sector write is not working?
    • What is the next block I should be looking at? / What is that I am missing?

    I have attached kernel logs for all test cases, dts and kernel configuration files. If you need anything from my end, let me know.

    Any suggestions/input, please let us know.

    Regards
    Srinivasa

    New_Kernel_Test_Summary_to_E2E.xlsx

    New_Kernel_results_15_Oct_2019.zip

  • 0 in reply to Srinivasa Wunnimani1
    TI__Mastermind 43735 points

    Hello Srinivasa,

    The flash chip according to the datasheet (https://www.cypress.com/file/177991/download) has a non-multiplexed memory interface, meaning 27 address lines and 16 data lines. However, the GPMC_CONFIG1_0 register is configured to 0x1210 in all of the logs provided. In the TRM, Table 7-59. GPMC_CONFIG1_0 Register Field Descriptions, it says bits 9 and 8 define the MUXADDDATA as follows:
    0h = Non-multiplexed attached device
    1h = AAD-multiplexed protocol device
    2h = Address and data multiplexed attached device
    3h = Reserved

    It appears the GPMC is configured for “Address and data multiplexed attached device” which would be incorrect, as it should be configured for “Non-multiplexed attached device” operation. I would try updating STNOR_GPMC_CONFIG1  in u-boot/arch/arm/include/asm/arch-am33xx/mem.h  accordingly by removing the 2. 

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 600 points

    Hi Krunal,

    We have a D latch (sn74cbtlv16212) between AM3352 and NOR flash and ALE signal connected to  D latch.

    From NOR flash point of view it is not multiplexed.  As far as processor is concerned it is multiplexed.  We discussed this in below link.

    https://community.cypress.com/thread/48218  (Aug 15, 2019 11:26 PM).

    In the old working kernel log, GPMC_CONFIG1_0 is also 0x1210.

    Please let me know your thought on this.

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    Intellectual 600 points

     Krunal,

    I have set my GPMC timing parameters in DTS file based on below approach:

    I have seen below statement in kernel log messages

    "enable GPMC debug to configure .dts timings for CS0"

    Towards this I have enabled below option:

    CONFIG_OMAP_GPMC_DEBUG=y

    Since NOR flash write is working at Bootloader level and gpmc parameters are carry forwared from bootlader to Kernel.  Based on the GPMC dump (kernel_log attached), I have added the same timings to my .dts file.
    Attachment: New_kernel_log_with_NOR_with_gpmc_dump.txt

    Next Step: 

    Since we don’t have any board which supports booting from NOR or SPI flash, I was trying to compare new Kernel with that of NAND flash (I am not sure if this is really correct).

    Towards this I have MitySOM-335x board with 256 MB NAND connected to AM3359 processor using GPMC.

    We have same kernel version from TI-SDK (V 05.03.00.07) up and running on this board. Here NAND write is working fine.
    Here the dts file is being provided by MitySOM team.

    As mentioned in approach 1, I did enable CONFIG_OMAP_GPMC_DEBUG=y and cross verfied the timings of GPMC dump with the DTS file provided by MitySOM. It is not matching and also they have other line items like "gpmc,sync-clk-ps = <0>;" added which are not present in GPMC dump.


    Attachment:
    New_kernel_log_with_NAND_with_gpmc_dump.txt
    am335x-mitysom-256M.dtsi (DTS file from MitySOM)

    Other observations:
    Only GPMC driver being called in approach 2.
    PHYSMAP driver from physmap.c is not being called.


    Inference:
    Considering this now I suspect the GPMC timings in DTS file.
    How do I cross verify all the timings in NOR dts file?
    How do I make sure that I have not missed any line items with respect to GPMC timings?

    Please let us know your input on this.

    Regards
    Srinivasa

    8446.16_Oct_2019.zip

  • 0 in reply to Srinivasa Wunnimani1
    TI__Mastermind 43735 points

    Hello Srinivasa,

    With regards to the DTS timing, I will get back to you within 24 hours. The "gpmc,sync-clk-ps" is defined in the following document and is only needed for synchronous mode. As mentioned in the past, the following documents give a reference for setting up GPMC-NOR: Document1 and Document2.

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 600 points

    Hi,

    I am using an excel sheet provided by TI team to calculate all the timing parameters for GPMC.

    It calculates all parameters for GPMC_CONFIG1_0 to GPMC_CONFIG6_0 (cs is 0).

    With below values, I was able to detect the CFI flash as 128 MB and qry command was passing.

    GPMC_CONFIG1_0 0x00001210
    GPMC_CONFIG2_0 0x00101000
    GPMC_CONFIG3_0 0x00030301
    GPMC_CONFIG4_0 0x10041004
    GPMC_CONFIG5_0 0x000c1010
    GPMC_CONFIG6_0 0x08070280


    In the excel sheet, I have updated "Reg Dump" with above values and from "Reg Parse" tab, I have updated all fields as per below page.

    git.ti.com/.../omap-gpmc.txt


    After, gpmc driver the values are being changed as below:


    [ 3.273921] GPMC_CONFIG1_0 = 601210
    [ 3.278219] GPMC_CONFIG2_0 = 20280
    [ 3.282462] GPMC_CONFIG3_0 = 10181
    [ 3.286675] GPMC_CONFIG4_0 = 2810281
    [ 3.291094] GPMC_CONFIG5_0 = 1020202
    [ 3.295482] GPMC_CONFIG6_0 = 10101c0

    Later CFI flash is not being detected because qry command fails. I have attached kernel log for refernce and dts file.

    I have used GPMC clk as 100 MHz because of below understanding:

    From Table 7.3.
    GPMC_FCLK = CORE_CLKOUTM4/2
    From Figure 8-10
    CORE_CLKOUTM4 = (200 MHz)

    Therefore GPMC_FCLK = (200 MHz/2) = 100 MHz.

    GPMC_CLK = GPMC_FCLK = 100 MHz(Becasue GPMC_CONFIG1_i[1-0] is 00).


    From the excel file, dts and kernel log, if you have any comments, please let us know.


    Regards
    Srinivasa

    21_Oct_2019.zip

  • 0 in reply to Srinivasa Wunnimani1
    TI__Guru 65377 points

    Hi Srinivasa,

    I've noticed there is no movement on this thread for about a month now.

    Can you please let us know where this stands, and if any progress has been made since your last post on 09/25. I'll be happy to give this another set of eyes in case you still have any issues.

    Thanks and Regards,
    Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 600 points

    Hi,

    This issue is not resloved & very much active and we are looking for your help. I think it is duplicated with below thread with the same name:

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

    If you can give any input on this will be great.

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    TI__Guru 65377 points

    Hi Srinivasa,

    Srinivasa Wunnimani1 said:
    This issue is not resolved & very much active and we are looking for your help.

    I spent some more time looking at the register values but have not found an explanation for what you are seeing but  it might be timing related. All the memory timing values are very different from what you had used in your older working system, presumably because to accommodate some clock tree setup differences(?). If we could somehow get the clock setup aligned with your older solution then all the memory related timing parameters should align too, or you could force them to be aligned by writing the register values directly.

    I also wonder if the time might have come where it might be a good idea to re-do the entire porting effort from scratch, possibly from a different starting point. It sounds like a lot of modifications were made to the Kernel tree throughout the effort getting this working including transplanting entire driver files, and frankly I am not convinced that such a large-scope change and effort should even be required to get access to a memory working. From my own past I recall sometimes you miss a detail porting changes or make modifications intentionally or unintentionally and that will introduce additional problems down the road, making things harder than they need to be.

    Nevertheless it's on top of my queue now to look at tomorrow, so I'll let you know if there is something else I find reviewing the data and the code.

    Srinivasa Wunnimani1 said:

    I think it is duplicated with below thread with the same name:

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

    This is actually the same thread, just another view of it. As you have noted yourself the thread has gotten very long and it now spans multiple pages . If you look at the number embedded in the URL '834972' this is what we refer to as Thread ID and it is the same this thread vs. the one you were referencing above.

    Thanks and Regards,
    Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 600 points

    Hi Andreas,

    Thank you very much for your time.

    All the memory timing values are very different from what you had used in your older working system, presumably because to accommodate some clock tree setup differences(?).

    First, we tried with the values same as working system but it was not working:

    Not working means we have two problems:

    1. Flash is detected as only 128 MB.
    2. We can write only one sector or data. Writing any file more than one sector size causes failure in verification.

     Our suspect was on the timing parameters which is being passed from DTS to the kernel. So, we started trying out with various options to accommodate some clock tree setup differences.

    If we could somehow get the clock setup aligned with your older solution then all the memory related timing parameters should align too, or you could force them to be aligned by writing the register values directly.

    Yes, we are aiming for this. Towards this we have done below steps but still we have the NOR flash write problem.

     We have made the values of GPMC registers same as old kernel at various all stages of booting.

    1. Bootloader.
    2. Start of Kernel.
    3. Beginning of gpmc driver.
    4. End of gpmc driver.
    5. After all drivers are inserted and just before file system is mounted.
    I also wonder if the time might have come where it might be a good idea to re-do the entire porting effort from scratch, possibly from a different starting point. It sounds like a lot of modifications were made to the Kernel tree throughout the effort getting this working including transplanting entire driver files, and frankly I am not convinced that such a large-scope change and effort should even be required to get access to a memory working. From my own past I recall sometimes you miss a detail porting changes or make modifications intentionally or unintentionally and that will introduce additional problems down the road, making things harder than they need to be.

    I completely agree with your suggestion. I have re-done the porting activity by installing new TI-SDK and followed below steps:

    Applied the patch provided by Cypress team:

    patch -p1 < linux-3.14.27-s70gl02gs.patch

    Deleted the RTC block from arch/arm/boot/dts/am33xx.dtsi file.

    rtc: rtc@44e3e000 {

    compatible = "ti,am3352-rtc", "ti,da830-rtc";

    reg = <0x44e3e000 0x1000>;

    interrupts = <75

    76>;

    ti,hwmods = "rtc";

    clocks = <&clkdiv32k_ick>;

    clock-names = "int-clk";

    };

     

    Edited arch/arm/mach-omap2/omap_hwmod_33xx_data.c and commented below line

    am33xx_l4_wkup__rtc entry from am33xx_hwmod_ocp_ifs array.

    Copy the latest configuration file to Linux folder and rename it as .config

    Build Kernel.

    Compile the DTS file.

    As mentioned above, I have added only debug statements to print all GPMC register and control registers related NOR flash interface at various all stages of booting.

    1. Booloader.
    2. Start of Kernel.
    3. Beginning of gpmc driver.
    4. End of gpmc driver.
    5. After all drivers are inserted and just before file system is mounted.

     I have enabled below debug statement in GPMC driver to make sure that it is using CS0 and my GPMC clock is 100 MHz.

     printk("GPMC CS%d CLK period is %lu ns (div %d)\n", cs, (div * gpmc_get_fclk_period()) / 1000, div);

     I have verified by creating a patch file and patch file contains only above-mentioned changes. (attached patch file for reference (“debug_changes.patch”).

     In summary:

    1. Chip select: 0
    2. GPMC Clock: 100 MHz.
    3. GPMC Configuration: Old and new is the same (except for GPMC idle configuration. This will not affect timings or other operation).

    Still we have NOR flash write problem as mentioned above. 

    If you have any other suggestion or any queries on the steps I have mentioned, please let me know. 

     

    Further questions:

    Recently we have received GPMC tool intended to assist debugging GPMC issues (“GPMC+tool.xlsm”) from TI team.

    In “How To” tab, they have suggested below point:

    7. Observe waveforms of the output signals and events for read and write cycles in the Waveform tab.

    There are no pins for below signals, how can we bring out below signals?

     

    • GPMC_FCLK (int)
    • GPMC_CLK
    • ADVn
    • ReadCycleTime
    • ReadAccessTime

     

    Attachments:

    1. New_Kernel_Log_V1.txt
    2. Old_Kernel_Log_V1.txt
    3. debug_changes.patch
    4. gpmc_node.dts
    5. GPMC_values_compare_old_with_new.xlsx
    6. GPMC+tool.xlsm

    30_Oct_2019.zip

  • 0 in reply to Srinivasa Wunnimani1
    TI__Guru 65377 points

    Hi Srinivasa,

    I appreciate the "fresh start" and new baseline of the issue you provided. I think it must be a bit frustrating thinking the solution should be quite close yet it is not working. Let me dig through your latest snapshot in detail and also see if there is opportunity to consult with others on the team for additional ideas. Please allow 2 days for this process.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    TI__Guru 65377 points

    Hi Srinivasa,

    As mentioned above, I have added only debug statements to print all GPMC register and control registers related NOR flash interface at various all stages of booting.

    1. Booloader.
    2. Start of Kernel.
    3. Beginning of gpmc driver.
    4. End of gpmc driver.
    5. After all drivers are inserted and just before file system is mounted.

    You have probably noticed this already but in your new setup the GPMC_SYSCONFIG register always has the SOFTRESET bit set. This bit is supposed to get reset to 0 by hardware according to the TRM, so I wonder why it is always set during all of the stages of your Kernel log (New_Kernel_Log.txt), with the first occurrence being at:

    [    2.042524] Srini debug @ line 2518 in function gpmc_probe in file drivers/memory/omap-gpmc.c

    I suspect there is no way the GPMC module can actually operate while SOFTRESET is set. Have you looked into this further why this bit stays at '1'? 

    I'm still digging through your materials.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 600 points

    Hi Andreas,

    All values in excel file "GPMC_values_compare_old_with_new" is in hexadecimal.  

    So GOMC_SYSCONFIG value is 0x11.

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    TI__Guru 65377 points

    Hi Srinivasa,

    oh right those were in hex, pls ignore my comment.

    Anyways, reviewing your changes and also some of the discussions you had with the folks from Cypress I noticed one anomaly that might be worth looking into further.

    Old (working) Kernel log:

    [    4.829487] physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x004801
[    4.840213] physmap-flash.0: Found 1 x16 devices at 0x8000000 in 16-bit bank

    New Kernel log:

    [    2.814887] physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x004801

    So I was looking at the Kernel's drivers/mtd/chips/cfi_probe.c function to see what is going on, and it seems like the function cfi_probe_chip() is not running to the end, which is where the second print with the old Kernel would have gotten emitted. It appears that normally cfi_probe_chip() would need to get called twice for this second print to happen (you can add debug prints to confirm this behavior with old and new Kernel and your HW). So there is something going on with the current DTS-based setup not triggering the same code flow as the old platform data-based setup.

    Then, the patch you got from Cypress forces the memory size to 128MB with this line...

    		cfi->cfiq->DevSize = 0x1B;

    ...to accommodate for the internal 2-die architecture of the Flash chip. So to get your full 256MB visible it does seem to rely on cfi_probe_chip() getting called twice.

    So we need to find a way to invoke cfi_probe_chip() twice. I have not looked into how to do that in the context of DTS (if it is even possible, since both dies would share the same CS signal), but one way to work this could be my modifying cfi_probe(). Rather than calling mtd_do_chip_probe() once, I would suggest try updating it to call mtd_do_chip_probe() twice, while in-between the two calls updating the "map" data for the two different memory regions. You could print the map data elements, and then figure out what parameters you need to update before calling mtd_do_chip_probe() again. You could also cross-check against the old Kernel which map data is passed there for the two calls to mtd_do_chip_probe().

    While you hopefully get a chance to experiment with this some more I'll look into if/how this can be accomplished with DTS on my end.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 600 points

    Hi Andreas,

    Function mtd_do_chip_probe() is being called once both in old and new kernel.

    mtd_do_chip_probe() calls genprobe_ident_chips() and there is for loop as shown below. This is location in old kernel it is probing the chip for the second time.

     

           for (i = 1; i < max_chips; i++) {

                   printk("Value of i is %d & i << cfi.chipshift is %d\n", i, i << cfi.chipshift);

                   cp->probe_chip(map, i << cfi.chipshift, chip_map, &cfi);

           }

     

    cp->probe_chip() is nothing but cfi_probe_chip() which is present in “drivers/mtd/chips/cfi_probe.c”

     

    I have added debug statements in genprobe_ident_chips() for both old and new kernel before and after for loop.  Values are as below:

    [   4.979006] Srini -> Value of cfi.numchips is 1

    [   4.986821] Srini -> Value of max_chips is 2

    [   4.991277] Srini -> Value of map->size is 268435456

    [   4.996451] Srini -> Value of mapsize is 4

    [   5.000728] Srini -> Value of chip_map is 1

    [   5.005088] Value of i is 1 & i << cfi.chipshift is 134217728

     

    I am noticing all above values are same in old and new kernel except for below variables.

    Value of map->set_vpp.

    Value of map->map_priv_1

    As per my understanding above variables should not affect CFI probe.

    I am not sure why “cfi_probe_chip()” is being called in old kernel but NOT in new kernel?  I have attached kernel logs and code for your analysis.

     

    Attachments:

    1. Old and new kernel log.
    2. Old and new kernel drivers/mtd/chips/gen_probe.c (where I have debug statements).
    3. DTS file

    Regards

    Srinivasa

    05_Nov_2019.zip

  • 0 in reply to Srinivasa Wunnimani1
    Intellectual 600 points

    Hi Andreas,

    Upon looking at cfi_probe_chip() function, I found that it was failing in below block:

    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;

    }

    I have commented the above block and now it is able to detect 2 chips and in partition 5, I am able to see 240M as below:

    root@am335x-evm:~# 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

    [   3.107323] number of CFI chips: 2

    I have attached new kernel log and file and cfi_probe.c from new kernel with my modifications for reference.

    Questions:

    Can we go ahead with this modification?

    Regards

    Srinivasa

    06_Nov_2019.zip

  • 0 in reply to Srinivasa Wunnimani1
    TI__Guru 65377 points

    Hi Srinivasa,

    well looks like we are making progress that's great. But what you have essentially done is having disabled the alias check which is meant to be a safeguard against mis-configuration. Now, the 2-die S70GL02GS is somewhat special as we know, so it is a bit difficult to say without a deep dive into the CFI/MTD code and framework if this is indeed a valid modification in this specific case. What you could do however is testing your change to see if you can go through several erase and re-write cycles of your entire 256MB of memory, each time populating different contents to see if the flash operates as expected. Also if I was to make this hack permanent I would probably remove the entire alias-checking for(;;) loop from cfi_probe_chip() rather than just a portion of it, and do that through using #ifdef/#endif preprocessor statements tied to a definition unique to your board.

    I also had a look at the current upstream Kernel and saw that official modifications were made for S70GL02GS using the below two patches:

    "mtd: cfi: Support early CFI fixups"
    https://github.com/torvalds/linux/commit/b1c97e2335f24dbdcc26cfdc882b8b5a0bad25c2#diff-99928f5adecf367549570fc3c88e0b64

    "mtd: cfi: Add early fixup for S70GL02GS"
    https://github.com/torvalds/linux/commit/0fe3ede7941dfcd6fd540fc2b086453d3ee8f236#diff-99928f5adecf367549570fc3c88e0b64

    Those patches combined do something very similar than the patch you received from Cypress, although there are slight differences in how cfi->cfiq is being modified. You could experiment with these two patches and using them instead of the Cypress patch if you see any issues and see if those result in a different behavior.

    I also found the below thread, where the support staff insists that the S70GL02GS needs to be treated as two separate devices from a software point of view using different DTS regions otherwise there could be issues with certain commands such as lock/unlock, however does not provide any Linux-based example. But since you had this working in the older Kernel to your satisfaction already that tells me that either you are using the flash chip in a way that doesn't expose any such specific limitations for what you are doing (that would be my guess), or that the Linux driver is able to handle the device just fine solely based on the changes made to cfi_probe.c by the patches under discussion.

    https://community.cypress.com/thread/34845?start=0&tstart=0

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 600 points

    Hi Andreas,

    Test Case 1:

    • Removed existing patch from Cypress
    • Applied above mentioned patches
    • Enabled alias check which is meant to be a safeguard against mis-configuration.


    Result: This is like our old problem definitions.

    • Flash is detected as only 128 MB.
    • We can write only one sector or data. Writing any file more than one sector size causes failure in verification.

    Test Case 2:

    • Removed existing patch from Cypress
    • Applied above mentioned patches
    • Disabled alias check which is meant to be a safeguard against mis-configuration.


    Result: This is like our latest fix towards 2 chip detection.

    • Flash is detected as 256 MB.
    • We can write only one sector or data. Writing any file more than one sector size causes failure in verification.

    Considering above two test cases new two patches behavior is same as old one patch. I have attached the kernel log file for both cases.

    https://community.cypress.com/thread/34845?start=0&tstart=0

    In the above link since they have not provided Linux example we cannot implement or modify anything as of now in the current kernel. Also, the same chip is working with the old kernel I don’t think we need to modify at the command level which is being discussed.

    Next step:

    If we can go ahead of fix by disabling alias check still we have problem of single sector write.

    Not working means we have two problems:

    1. Flash is detected as only 128 MB.
    2. We can write only one sector or data. Writing any file more than one sector size causes failure in verification.

    In both cases we can write only one sector. What would be your suggestion towards this for second problem.

    Which modules do I need to look up for this?

     

    Regards

    Srinivasa

     

    07_Nov_2019.zip

  • 0 in reply to Srinivasa Wunnimani1
    TI__Guru 65377 points

    Hi Srinivasa,

    the results of your test 1 and test 2 are what I expected after reviewing the new patch, as the effective differences looked very minor. But thanks for running those tests.

    Srinivasa Wunnimani1 said:

    If we can go ahead of fix by disabling alias check still we have problem of single sector write.

    Not working means we have two problems:

    1. Flash is detected as only 128 MB.
    2. We can write only one sector or data. Writing any file more than one sector size causes failure in verification.

    In both cases we can write only one sector. What would be your suggestion towards this for second problem.

    Which modules do I need to look up for this?

    I was thinking about this, in the old Kernel the alias check was still active (that code hasn't really changed for quite a while it seems), and you still had everything working: 256MB and multi-sector write. To me that means you probably want to find a way to probe the memory with the new Kernel in a way that still works with the alias check *enabled* (as it is probably a valid safeguard that should be left active), by investigating the data structures and call sequences that happen during probe. Once you know what those need to be then you can work backwards to see the best way how to provide those, whether it be through DTS updates or through probably some minor surgical change to the driver stack. So I'd start checking if you can "transplant" working data structures describing the flash device read out from the old Kernel during runtime into the new Kernel in a hard-coded fashion and get it working this way.

    I'm going to have tomorrow another closer look at the driver framework to see if there is something that spikes out.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 600 points

    Hi Andreas,

    Going back to my post on Nov 6, 2019 2:16 PM, I mentioned it was failing in the below alias check.

    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;

    }

    Another observation, I would like to bring to your notice:

    Before this block, we have below statement.

    // cfi_qry_mode_off(start, map, cfi);

    I have commented above statement with the alias check *enabled*. With this change, we are good, kernel prints "number of CFI chips: 2" and
    we have 256 MB flash detected!!!  I feel this should give us some hint.  

    Any comments/input from this?

    By investigating the data structures and call sequences that happen during probe.


    We have doen this considering two suspect scenarios:

    Suspect 1:
    As far as CFI drivers is concerneed, old and new kernel it is the same. Only the code is recorganized. In old Kernel, many functions are static and inline and are present in "include/linux/mtd/cfi.h", whereas in new kernel it is not static and iniline and all functions are present in "drivers/mtd/chips/cfi_util.c".

    To rule out this, we made complete CFI driver same as old by replacing old in the new kernel. (if you rememeber after your suggestion, we started from installation again), but we could not find any solution here.

     

    Suspect 2:

    Major difference between old and new kernel is in the map drivers.
    In old kernel, map driver is from "drivers/mtd/maps/physmap.c" and probe function called is "physmap_flash_probe()".

    In new kernel, map driver is from "drivers/memory/omap-gpmc.c" and probe function called is "gpmc_probe()".

    Please refer to my post from "Oct 4, 2019 9:46 AM", where I have attempted to make physmap_flash_probe() as my map driver but still no solution.

    We are not sure if anything going on in map drivers (suspect 2).


    Regards
    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    TI__Guru 65377 points

    Hi Srinivasa,

    Srinivasa Wunnimani1 said:

    I have commented above statement with the alias check *enabled*. With this change, we are good, kernel prints "number of CFI chips: 2" and
    we have 256 MB flash detected!!!  I feel this should give us some hint.  

    Any comments/input from this?

    Well this is still working around the "safeguard", albeit in a different way. As mentioned before the fact that it works with those checks on your old Kernel tells me this is probably not the place to dig further for now. This being said, these issues suggest that somehow the memory seems to get mapped differently in old vs new, and we need to find out how/why.

    Srinivasa Wunnimani1 said:

    Please refer to my post from "Oct 4, 2019 9:46 AM", where I have attempted to make physmap_flash_probe() as my map driver but still no solution.

    We are not sure if anything going on in map drivers (suspect 2).

    This aspect needs to be double checked further I think. You mentioned earlier that writing more than one sector of data fails.

    Is the memory area you are writing to completely erased?

    Can you try writing to a different memory area/mtd partition (one you know that's erased) to see if you can write more than one sector?

    I'm going to dig a bit deeper into the mapping driver to see if the behavior can be explained. I wonder if somehow your next sector (where the write fails) incorrectly gets mapped to the second die in the Flash chip which is not expecting this access and is not in the right state for a write/erase operation. According to the datasheet, section "Second Die Access",  the way the Cypress S70GL02GS device works is that it effectively uses the highest-numbered A26 address signal to select between die 1 and die 2 which will need to be comprehended in how the device is accessed during unlock/write.

    (Datasheet for reference: https://www.cypress.com/file/177991/download

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 600 points

    Hi Andreas,

    In the old kernel (Linux version 3.2.0), mapping driver is from “drivers/mtd/maps/physmap.c” and physmap_flash_probe() is being called().

    We are seeing below line in old kernel log:

    physmap platform flash device: 10000000 at 10000000

    Whereas in new kernel Linux version 4.14, map probe function is different.  Above mentioned fun physmap_flash_probe() is not being called but gpmc_probe() from drivers/memory/omap-gpmc.c is being called.

    Considering these two different implementations, I have tried introducing debug statements in GPMC driver, but I could not find any failure case which I can link to our problem.

    I am not sure how memory is getting mapped in old and new implementation.  Please let me the code implementation part where this is done.  I can add debug statement in old and new kernel for comparison and further debugging.

    I'm going to dig a bit deeper into the mapping driver to see if the behavior can be explained.

    Which part of the code (file/function) will you be looking at?  If you need any debug statements to be introduced, please let me know.

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    TI__Guru 65377 points

    Hi Srinivasa,

    I was looking today at some of the aspects regarding the Flash erase sector size (128KB) as well as how the two different Flash dies are mapped (to make sure they both get their unlock commands as needed) but then found this thread here:

    https://community.cypress.com/thread/48218?start=30&tstart=0

    In the provided ZIP file from Sept 6th there is a log in there named Not_Working_Kernel_log_and_flash_erase.txt with Kernel 4.14 that shows you successfully erasing all mtdX partitions which is a good step, as I think that validates a lot of the memory mapping and unlock/lock command handling aspects. Then, it also shows what looks like you attempting to write those mtdx partitions partially, but only what looks like the first 128KB each, just like you described earlier here on the E2E. I don't think I had seen those more complete logs before but there is something interesting about them like this...

    [   51.220005] MTD do_write_buffer(): WRITE 0x000bd600(0x0000d9c7)
[   51.226347] MTD do_write_buffer(): WRITE 0x000bd800(0x0000cbd5)
[   51.237365] MTD do_write_buffer(): WRITE 0x000bda00(0x0000eb74)
[   51.246407] MTD do_write_buffer(): WRITE 0x000bdc00(0x00006b4c)
[   51.255395] MTD do_write_buffer(): WRITE 0x000bde00(0x000061b1)
Writing data: 130k/3748k (3%)[   51.264685] 
[   51.264685] 
[   51.264685] 
[   51.264685] Srini debug @ line 1984 in function cfi_amdstd_write_buffers in file drivers/mtd/chips/cfi_cmdset_0002.c
[   51.264685] 
[   51.264685] 
[   51.289860] MTD do_write_buffer(): WRITE 0x000be000(0x0000ab6b)
[   51.296207] MTD do_write_buffer(): WRITE 0x000be200(0x0000df1c)
[   51.312934] MTD do_write_buffer(): WRITE 0x000be400(0x000002bc)
[   51.319295] MTD do_write_buffer(): WRITE 0x000be600(0x0000c401)
[   51.330111] MTD do_write_buffer(): WRITE 0x000be800(0x00003f79)
[   51.336470] MTD do_write_buffer(): WRITE 0x000bea00(0x00001329)
[   51.347888] MTD do_write_buffer(): WRITE 0x000bec00(0x000001c3)
[   51.357016] MTD do_write_buffer(): WRITE 0x000bee00(0x00009e60)
[   51.365974] MTD do_write_buffer(): WRITE 0x000bf000(0x00005dd6)
[   51.375012] MTD do_write_buffer(): WRITE 0x000bf200(0x00003909)
[   51.384082] MTD do_write_buffer(): WRITE 0x000bf400(0x0000fc85)
[   51.393076] MTD do_write_buffer(): WRITE 0x000bf600(0x000089ab)
[   51.402079] MTD do_write_buffer(): WRITE 0x000bf800(0x0000c25e)
[   51.408443] MTD do_write_buffer(): WRITE 0x000bfa00(0x00007733)
[   51.419340] MTD do_write_buffer(): WRITE 0x000bfc00(0x00004038)
[   51.428375] MTD do_write_buffer(): WRITE 0x000bfe00(0x000046e0)
[   51.437472] MTD do_write_buffer(): WRITE 0x000c0000(0x0000fa9f)
root@am335x-evm:~# 
root@am335x-evm:~#

    So what exactly happens after the debug prints belonging to the "Writing data: 130k/3748k (3%)[   51.264685]" step as in the above extract from your log? It seems like you just get back to the Linux prompt each time without any further prints, error messages, or anything at all?

    Then, what happens if you read back those ~130KB that got programmed into the different partitions? Did that data get programmed correctly?

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 600 points

    Hi Andreas,

    So what exactly happens after the debug prints belonging to the "Writing data: 130k/3748k (3%)[   51.264685]" step as in the above extract from your log? It seems like you just get back to the Linux prompt each time without any further prints, error messages, or anything at all?

    In the newly installed TI SDK, system hangs and I need to do a power cycle.  I understand your point in the above logs, what you are noticing was after our modifications.

    Then, what happens if you read back those ~130KB that got programmed into the different partitions? Did that data get programmed correctly?

    We are able to erase/write/read one sector on all partitions and we are writing a known data.

    We are just doing "cat /dev/mtdx" and we are able to see the data back.

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

    Regards

    Srinivasa

  • 0 in reply to Srinivasa Wunnimani1
    TI__Guru 65377 points

    Hi Srinivasa,

    Srinivasa Wunnimani1 said:

    In the newly installed TI SDK, system hangs and I need to do a power cycle.  I understand your point in the above logs, what you are noticing was after our modifications.

    So basically with your current setup after 128KB are written those commands just stopped and you return to prompt?

    If that's the case maybe something is wrong with your userspace utilities then, and not the Kernel level setup?

    Can you try and build the latest set of MTD utilities like 'flashcp' from the source available at: http://www.linux-mtd.infradead.org/source.html (http://git.infradead.org/mtd-utils.git/tree) and see if the behavior changes.

    I would also like you to try a different angle to see what results this gives us. As you know the Linux kernel including the various subsystems undergo constant changes and improvements, so I'd like to see what happens when you try booting your platform on the latest kernel, specifically the TI pre-integrated ti-linux-5.4.y tree (this will be the base for next year's SDK nevertheless you can use it already for experiments) available here:

    https://git.ti.com/gitweb?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-5.4.y

    Can you please clone this repo and check out the ti-linux-5.4.y branch.

    See that you can port over your device tree and defconfig files using the usual methods, and then build the Kernel. Note that this Kernel already has the equivalent of the patch you received from Cypress which we discussed earlier (so you won't need to apply this patch):

    0fe3ede7941 ("mtd: cfi: Add early fixup for S70GL02GS")
    https://git.ti.com/gitweb?p=ti-linux-kernel/ti-linux-kernel.git;a=commit;h=0fe3ede7941dfcd6fd540fc2b086453d3ee8f236

    But it also has other interesting changes which may or may not bring improvements for the issue you are seeing, like this one:

    37c673ade35 ("mtd: cfi_cmdset_0002: Use chip_good() to retry in do_write_oneword()")
    https://git.ti.com/gitweb?p=ti-linux-kernel/ti-linux-kernel.git;a=commit;h=37c673ade35c707d50583b5b25091ff8ebdeafd7

    Can you please experiment with this ti-linux-5.4.y branch and see how this changes the behavior and if any improvements can be seen. Note that you probably still need to apply the HACK you found disabling the alias check (but please try also without it).

    Thanks and Regards,
    Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 600 points

    Hi Andreas,

    Just an update.

    Upon executing below command and after writing one sector of data, system is not hanging.

    flashcp -v hello_200K.txt /dev/mtd2

    Since there are no kernel messages, terminal goes blank.  Above command is not even responding to "Ctrl + C".

    Just to prove above scenario, I removed the SD card while the system is up and running.  I could see the mmc error messages.

    Please find the logs attached. (New_kernel_log_20_Nov_2019.txt)

    Can you try and build the latest set of MTD utilities like 'flashcp' from the source available at: http://www.linux-mtd.infradead.org/source.html (http://git.infradead.org/mtd-utils.git/tree) and see if the behavior changes.

    That's a good thought and we have never done this before.   I did download the "mtd-utils-57b6d16.tar.gz"  from above link but haveing hard time in configuring the cross compiling for ARM architecture.

    If you have done this, please share the steps for the same.

    I am not tried this yet.  Tomorrow I am not working.  Will update you on friday on this.

    Regards

    Srinivasa

    New_kernel_log_20_Nov_2019.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    U-Boot SPL 2018.01-00569-g7b4e473-dirty (Nov 11 2019 - 06:30:02)
    Trying to boot from MMC1
    *** Warning - bad CRC, using default environment
    U-Boot 2018.01-00569-g7b4e473-dirty (Nov 11 2019 - 06:30:02 +0530)
    CPU : AM335X-GP rev 2.1
    Model: TI AM335x EVM-SK
    DRAM: 256 MiB
    256 MiB
    OF: translating address: 0070e044
    OF: parent translation for: 00000000
    OF: one level translation: 0070e044
    OF: translating address: 00c00448
    OF: parent translation for: 00000000
    OF: one level translation: 00c00448
    OF: translating address: 00c01a48
    OF: parent translation for: 00000000
    OF: one level translation: 00c01a48
    OF: translating address: 00e01a48
    OF: parent translation for: 00000000
    OF: one level translation: 00e01a48
    OF: translating address: 0090e044
    OF: parent translation for: 00000000
    OF: one level translation: 0090e044
    Flash: OF: translating address: 00000448
    OF: parent translation for: 00000000
    OF: one level translation: 00000448
    device interface is 1
    found port 2 chip 2 port 16 bits chip 16 bits
    ERROR: too many flash sectors
    [CKR] flash_real_protect() - something tried to protect - but disregarded. Sector#: 0
    [CKR] flash_real_protect() - something tried to protect - but disregarded. Sector#: 1
    [CKR] flash_real_protect() - something tried to protect - but disregarded. Sector#: 2
    256 MiB
    Srini MMC: OF: translating address: 00000648
    OF: parent translation for: 00000000
    OF: one level translation: 00000648
    OF: translating address: 00801d48
    OF: parent translation for: 00000000
    OF: one level translation: 00801d48
    OMAP SD/MMC: 0, OMAP SD/MMC: 1
    *** Warning - bad CRC, using default environment
    Net: No ethernet found.
    TI-SDK U-Boot
    Hit any key to stop autoboot: 0
    =>
    =>
    =>
    => fatload mmc 0:1 0x88000000 am335x-evmsk.dtb
    35335 bytes read in 8 ms (4.2 MiB/s)
    => setenv bootargs console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
    => fatload mmc 0:1 0x82000000 zImage
    3834368 bytes read in 526 ms (7 MiB/s)
    => bootz 0x82000000 - 0x88000000
    ## Flattened Device Tree blob at 88000000
    Booting using the fdt blob at 0x88000000
    Loading Device Tree to 8df31000, end 8df3ca06 ... OK
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

1 2