Mity CPU Platforms » MitySOM-335x (ARM Cortex-A8 Based Products)

Hi,

Test case 1:
Tested on u-boot Version 2013.10 from mitysom (u-boot-mityarm-335x-6c6a700.tar.gz).
Probed GPIO 0_27 while running below command:

nand read.i 0x83000000 0x280000 0x500000

There is some activity on GPIO 0_27 as shown in attchment (gpio_0_27_chattering_uBoot_version 2013.10.jpg)

Test case 2:
Just updated NAND flash with u-boot from Version 2013.10 to 2018.01 and probled gpio_0_27.

This time the amplitude is more as shown in attachment (gpio_0_27_chattering_uBoot_version 2018.01.jpg)

Toggling/chattering is noticed for NAND write and erase also.

Considering above test cases, I have few questions:
Is there any parameter like frequency that we can set in u-boot towards NAND read/write/erase operations?

Regards
Srinivasa

Hi,

I have dumped the values of GPMC registers for u-boot V2013.10 and V2018 at u-boot prompt. Please find the files attached.

I am little confused with V2018:
GPMC_CONFIG7_0 = f48, which indicates it’s 16 MB flash but NAND memory detected is as below:

NAND: 256 MiB.

Please let us know if you have any input on this.

Regards
Srinivasa

Srinivasa,

We have not seen this before and I am reviewing your comments and logs.
Diff of GPMC registers

18,19c18,19
< GPMC_CONFIG7_0          = 48
< GPMC_NAND_COMMAND_0     = ffffff00
---
> GPMC_CONFIG7_0          = f48
> GPMC_NAND_COMMAND_0     = ffffff3f
21c21
< GPMC_NAND_DATA_0        = ffffffff
---
> GPMC_NAND_DATA_0        = 3f
68,70c68,70
< GPMC_ECC_CONFIG         = 11100
< GPMC_ECC_CONTROL        = 2
< GPMC_ECC_SIZE_CONFIG    = 81a000
---
> GPMC_ECC_CONFIG         = 1030
> GPMC_ECC_CONTROL        = 0
> GPMC_ECC_SIZE_CONFIG    = fffff000

If you manually set GPMC_CONFIG7_0 back to 48, does the activity on GPIO 0_27 stop?

Hi,

With u-boot V2013 frequency of pulses ~3.571 MHz and amplitude ~150 mV.
With u-boot V2018 frequency of pulses ~3.571 KHz and amplitude ~ 3.2 V.

Please find images attached.

Regards
Srinivasa

Hi,

Manually means, do you want me to change GPMC_CONFIG7_0 at u-boot prompt?

Regards
Srinivasa

You can use md to read memory locations and mw to write them. https://www.denx.de/wiki/publish/DULG/to-delete/UBootCmdGroupMemory.html

Hi,

I tried to change GPMC_CONFIG7_0 to 0x48 from 0xf48 as below. I was able to manual write it to GPMC with any error.

md.b 0x50000070 10
mw.b 0x50000078 48
mw.b 0x50000079 00

But after executing below read command, board reboots.
nand read.i 0x83000000 0x280000 0x500000

Please find screenshot attached.

However, going further without writing to 0x50000078 & 0x50000079, I executed below commands to see if other GPMC registers is causing the problem.

/* GPMC_NAND_COMMAND_0 */
mw.b 0x5000007c 00
mw.b 0x5000007d 00
mw.b 0x5000007e 00
mw.b 0x5000007f 00

/* GPMC_NAND_ADDRESS_0 */
mw.b 0x50000080 00
mw.b 0x50000081 00
mw.b 0x50000082 00
mw.b 0x50000083 00

/* GPMC_NAND_DATA_0 */
mw.b 0x50000084 00

/* GPMC_NAND_ECC_CONFIG */
mw.b 0x500001f4 00

/* GPMC_NAND_ECC_CONTROL */
mw.b 0x500001f8

/* GPMC_NAND_ECC_SIZE_CONFIG */
mw.b 0x500001fC

Still I have problem of GPIO0_27 toggling/chattering.

Questions:
u-boot says "NAND: 256 MiB" I am expecting this to be inline with GPMC_CONFIG7_0, Why this is not so?
Where (filename/function/line) do I change the GPMC_CONFIG7_0 to 0x48 from source code?

Regards
Srinivasa

Sorry for typo error:

I was able to manual write it to GPMC without any error.

Regards
Srinivasa

md.b 0x50000070 10
mw.b 0x50000078 48
mw.b 0x50000079 00

I would stick with using md.w and mw.w since all the registers are 32bit. It may or may not be okay to write the registers one byte at a time but I wouldn't trust it.

Try running mw.w 0x50000078 48 and seeing if it fixes your issue. If it doesn't then we need to look elsewhere. The next place I would look would be the pinmux, to make sure that pin is muxed to gpio and not to the gpmc.

Hi,

Thank you for your input.

Tried with below command, still same problem.
mw.w 0x50000078 48

As mentioned earlier, we have u-boot 2013.10 with less amplitude.
To make sure pinmux is okay, copied mux.c from board/cl/mityarm335x

to

u-boot 2018.01 (with large amplitude)
board/cl/mityarm335x/.

Able to build u-boot without any problems but still same problem.

Next step: Tried to copy som.c from u-boot 2013.10 to 2018.01 but there were compilation errors.

Regards
Srinivasa

Note the pinmux tables can be read from memory.

See "Table 9-10: CONTROL_MODULE REGISTERS" https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Software_FAQs#Useful-memory-locations

Pinmux start address: 0x44E1_0800

Sure, we will print CONTROL_MODULE_REGISTERS and update you on the same.

We want to update the source code and make GPMC registers same as old u-boot.
Towards this can you please let us know:
Where (filename/function/line) do I change the GPMC_CONFIG7_0 to 0x48 from source code?

Or

Which file I need to update to make GPMC registers same as old u-boot?

Regards
Srinivasa

The config7 register appears to be getting set in arch/arm/mach-omap2/mem-common.c

Hi,

I have updated arch/arm/mach-omap2/mem-common.c as below:

132 #if defined(CONFIG_NAND) || defined(CONFIG_CMD_NAND)
133 case MTD_DEV_TYPE_NAND:
134 gpmc_regs = gpmc_regs_nand;
135 base = CONFIG_SYS_NAND_BASE;
136 // size = GPMC_SIZE_16M;
137 size = GPMC_SIZE_256M;
138 break;
139 #endif

Trying to erase flash using nand erase.chip command.
System reboots.

=>
=> nand erase.chip

NAND erase.chip: device 0 whole chip
data abort
pc : [<8ff85212>] lr : [<fffffffc>]
reloc pc : [<8081e212>] lr : [<f0898ffc>]
sp : 8df46aa0 ip : 08000000 fp : 00000000
r10: 00000040 r9 : 8df46ed8 r8 : 8df48904
r7 : 8df48900 r6 : 00000001 r5 : 8df48900 r4 : 8ffd9a48
r3 : 8ffcad28 r2 : 00000000 r1 : 00000040 r0 : 00000040
Flags: Nzcv IRQs off FIQs on Mode SVC_32
Resetting CPU ...

resetting ...

U-Boot SPL 2018.01-g2659de8-dirty (Mar 23 2020 - 23:52:21)
Critical Link AM335X Dev Kit -- NAND Page size = 2048k booting from dev 8
Trying to boot from MMC1
reading u-boot.img
reading u-boot.img

U-Boot 2018.01-g2659de8-dirty (Mar 23 2020 - 23:52:21 +0530)

CPU : AM335X-GP rev 1.0
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

In: ns16550_serial
Out: ns16550_serial
Err: ns16550_serial
Net: Could not find PHY for cpsw: phy_mask 6
cpsw
Hit any key to stop autoboot: 0

Any input on this please let me know.

Regards
Srinivasa

Srinivasa Wunnimani wrote:

Hi,

I have updated arch/arm/mach-omap2/mem-common.c as below:

132 #if defined(CONFIG_NAND) || defined(CONFIG_CMD_NAND)
133 case MTD_DEV_TYPE_NAND:
134 gpmc_regs = gpmc_regs_nand;
135 base = CONFIG_SYS_NAND_BASE;
136 // size = GPMC_SIZE_16M;
137 size = GPMC_SIZE_256M;
138 break;
139 #endif

If things are crashing now, then this was probably not the correct change. If you double check the config7 register, did this change set it to the value we expect from v2013.10?

Sure, we will print CONTROL_MODULE_REGISTERS and update you on the same.

Could you post the pinmux differences between these two versions?

Hi,

If things are crashing now, then this was probably not the correct change. If you double check the config7 register, did this change set it to the value we expect from v2013.10?

In the entire u-boot the only C file (arch/arm/mach-omap2/mem-common.c) to have used macro this macro GPMC_SIZE_16M (other than board files) and I have modified it.

pcadmin@pcadmin-OptiPlex-790:~/mity_arm/gpio_toggle_test/u-boot-mityarm-335x$ grep -rn "GPMC_SIZE_16M" .
./arch/arm/mach-omap2/mem-common.c:129: GPMC_SIZE_16M)));
./arch/arm/mach-omap2/mem-common.c:136:// size = GPMC_SIZE_16M;
./arch/arm/include/asm/arch-omap5/mem.h:39:#define GPMC_SIZE_16M 0xF
./arch/arm/include/asm/arch-omap3/mem.h:386: * GPMC_SIZE_16M - 0xF
./arch/arm/include/asm/arch-omap3/mem.h:394:#define GPMC_SIZE_16M 0xF
./arch/arm/include/asm/arch-omap4/mem.h:39:#define GPMC_SIZE_16M 0xF
./arch/arm/include/asm/arch-am33xx/mem.h:39:#define GPMC_SIZE_16M 0xF

Yes, I got the change I was expecting. Now config7 is as expected as 0x48. I think there are some dependency registers to it. I am looking at it now.

To make sure pinmux is okay, copied board/cl/mityarm335x/mux.c from v2013.10 to our new u-boot v2018.01. Plese find mux.c attached.

Regards
Srinivasa

To make sure pinmux is okay, copied board/cl/mityarm335x/mux.c from v2013.10 to our new u-boot v2018.01. Please find mux.c attached.

I was hoping to have you dump the sysconfig pin mux registers for the 2013 and 2019 u-boots to make sure they are the same. Since something has changed that we didn't expect.

Hi,

I am little confused on sysconfig pin mux registers. Did you mean control module registers?
Anyways, I have captured control module register values for v2013.10 to our new u-boot v2018.01.
Please find logs attached.

Regards
Srinivasa

Hi

If things are crashing now, then this was probably not the correct change.

I have started debugging into gpmc_init() in u-boot 2013.10 Vs u-boot 2018.01.
Old u-boot 2013.10 in file “arch/arm/cpu/armv7/am33xx/mem.c”

void gpmc_init(void)
{
    .
    .
    .
base = PISMO1_NAND_BASE;
size = PISMO1_NAND_SIZE;
printf("Value of base and size is 0x%x & 0x%x\n", base, size);
enable_gpmc_cs_config(gpmc_config, &gpmc_cfg->cs[0], base, size);
}

New Vs u-boot 2018.01 code is as below:

void gpmc_init(void)
{

    .
    .
    .
set_gpmc_cs0(gpmc_cs0_flash);
}

set_gpmc_cs0(gpmc_cs0_flash)
{
    .
    .
    .
    #if defined(CONFIG_NAND) || defined(CONFIG_CMD_NAND)
        case MTD_DEV_TYPE_NAND:
                gpmc_regs = gpmc_regs_nand;
                base = CONFIG_SYS_NAND_BASE;
    //              size = GPMC_SIZE_16M;
                printf("\n\n\nSrini debug @ line %d in function %s in file %s\n\n\n",__LINE__, __func__, __FILE__);
                size = GPMC_SIZE_256M;  // Srini, causeing board reboot with nand erase.chip
                break;
    #endif

/* enable chip-select specific configurations */
printf("Value of base and size is 0x%x and 0x%x\n", base, size);
enable_gpmc_cs_config(gpmc_regs, &gpmc_cfg->cs[0], base, size);
}

Now I have made "size = GPMC_SIZE_256M",
Debug print value of base and size is 0x8000000 & 0x0 both in old and new u-boot.
Now I am pretty confident that "size = GPMC_SIZE_256M;" is correct.

> Now my suspect is on below registers
GPMC_ECC_CONFIG
GPMC_ECC_CONTROL
GPMC_ECC_SIZE_CONFIG

I am trying to find where (file and function) above registers are initialized/modified.
If you can let know that will be helpful.
Please find log of old u-boot and new u-boot where below values are printed.

printf("Value of base and size is 0x%x and 0x%x\n", base, size);

If you double check the config7 register, did this change set it to the value we expect from v2013.10?

Yes, CONFIG7 is updated to 0x48 which is now same as old u-boot.

Regards
Srinivasa

Forget to attach log files.

Please find log files attached.

Regards
Srinivasa

Srinivasa Wunnimani wrote:

Hi,

I am little confused on sysconfig pin mux registers. Did you mean control module registers?
Anyways, I have captured control module register values for v2013.10 to our new u-boot v2018.01.
Please find logs attached.

Regards
Srinivasa

Okay looks like the pinmux's match

Srinivasa Wunnimani wrote:

> Now my suspect is on below registers
GPMC_ECC_CONFIG
GPMC_ECC_CONTROL
GPMC_ECC_SIZE_CONFIG

I am trying to find where (file and function) above registers are initialized/modified.
If you can let know that will be helpful.
Please find log of old u-boot and new u-boot where below values are printed.

In order to find these registers, all I do is run "grep -iR " with the string I'm looking for in the u-boot source directory. Sometimes may need to poke around the code to figure out what terminology to use. And ignore the results for the code that isn't being used.

I don't believe the ECC algorithm could be generating activity on the wrong pins. So not sure why its registers would be causing issues.

Hi,

We have SOM board as per below link:

https://static6.arrow.com/aropdfconversion/bd95376e672d11c623e62dac62cb587c9bb1bc34/mitysom-335x-criticallink.pdf

If you have any evaluation board for the above mentioned SOM board, please perform below steps to simulate the problem:

1. Boot board from SD Card.
2. Flash NAND with below commands:

a. nand erase.chip
b. mmc rescan
c. fatload mmc 0 0x81000000 MLO
d. fatload mmc 0 0x81080000 u-boot.img
e. nand write 0x81000000 0x0 0x780000
f. saveenv

3. Reboot the board with NAND boot.
4. Perform NAND read with below command.

a. nand read.i 0x83000000 0x280000 0x500000

5. During NAND read, monitor GPIO 0_27 by probing.

This will help us to know if the issue is same across all hardware platform.

Regards
Srinivasa

Thanks for the instructions to reproduce the problem. That is helpful.

Unfortunately though with the current virus going around, I don't have access to an oscilloscope to check the gpio pin for noise.

Question:

Is boot from nand a requirement to reproduce this? I would expect it to behave the same when booted from SD card and reading from the NAND using your nand read command.