topic Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2]) in Layerscape

[LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

macpijan — Wed, 26 Jun 2019 08:34:49 GMT

Hello. We have an LS1046A based board. We are during the bring up process
and are validating the GPIO lines we need. We faced unexpected behavior
on one of the lines.

One of the GPIO (GPIO4[2]) cannot be set to OUT HIGHT despite writing to the
DIR / DATA registers.

This is the U-Boot code we use for this test:

```
/* GPIO4[2,3,10,11] */
val4 = (1 << 29) | (1 << 28) | (1 << 21) | (1 << 20);

read4 = in_be32(&pgpio4->gpdir);
printf("gpio4->gpdir before: 0x%x\n", read4);
setbits_be32(&pgpio4->gpdir, val4);
read4 = in_be32(&pgpio4->gpdir);
printf("gpio4->gpdir after: 0x%x\n\n", read4);

read4 = in_be32(&pgpio4->gpdat);
printf("gpio4->gpdat before: 0x%x\n", read4);
setbits_be32(&pgpio4->gpdat, val4);
read4 = in_be32(&pgpio4->gpdat);
printf("gpio4->gpdat after: 0x%x\n\n\n", read4);
```

This is U-Boot output:

```
gpio4->gpdir before: 0x0
gpio4->gpdir after: 0x30300000

gpio4->gpdat before: 0x0
gpio4->gpdat after: 0x10300000
```

As you can see, the GPDAT bit for GPIO4[2] is not being set.
I believe the pinmux for those pins is correctly set within the RCW. Both GPIO4[2,3]
are muxed to GPIO by the same single bit RCW[I2C_EXT] = 010.
So if the setting was incorrect, I would expect both GPIO4[2,3] to not operate.

We had similar issue for the GPIO2[26,27] and it turned out that we cannot have
them muxed to GPIO while having the QSPI_A_DAT3 enabled at the same time.
I could not find a similar issue for the GPIO4[2] in the reference manual.
Escpecially that muxing it is tied with the GPIO4[3], which works correctly.

Are there any other mechanism that would prevent this GPIO from operating? Thanks.

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

ufedor — Wed, 26 Jun 2019 12:37:13 GMT

> Are there any other mechanism that would prevent this GPIO from operating?

No.

Please provide additional information:

1) the GPIO4 connection schematics

2) how many boards were tested?

3) use U-Boot and capture dump of all GPIO4 CCSR registers after the test completion.

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

macpijan — Mon, 02 Nov 2020 14:29:51 GMT

We figured out that we can control this GPIO line when the SD card is NOT inserted in the SD slot.
This GPIO can be muxed to SDHC_CD via [IIC2_EXT], but it is NOT.

The CD signal from the SD card connector is NOT connected in any way to the SoC.

The behavior is the same both in U-Boot and when controlling the GPIOs via PBL commands
(no external software is running on the CPU, only the PreBootloader).

The GPIO4[2] is connected only to the LED, as shown on the schematic below.

Output from U-Boot test:

gpio4 registers dump before:  gpio4->gpodr: 0x0 gpio4->gpier: 0xc0000 gpio4->gpimr: 0x0 gpio4->gpicr: 0x0 gpio4->gpibe: 0x0   gpio4 registers dump after:  gpio4->gpodr: 0x0 gpio4->gpier: 0x103c0000 gpio4->gpimr: 0x0 gpio4->gpicr: 0x0 gpio4->gpibe: 0x0

Dump with card inserted:
=> md.w 0x2330000
02330000: 3030 0000 0000 0000 3010 0000 3c10 0000 00.......0...<..
02330010: 0000 0000 0000 0000 0000 0000 0000 0000 ................

Dump afte card removal:
=> md.w 0x2330000
02330000: 3030 0000 0000 0000 3030 0000 3c30 0000 00......00..0<..
02330010: 0000 0000 0000 0000 0000 0000 0000 0000 ................

We probably may need to change this GPIO to a different line.

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

ufedor — Wed, 03 Jul 2019 05:07:08 GMT

> We figured out that we can control this GPIO line when the SD card is NOT inserted in the SD slot.

Please use U-Boot and capture dumps of SCFG and DCFG CCSR registers for two cases:

1) when SD card is not inserted

2) when SD card is inserted

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

macpijan — Wed, 03 Jul 2019 15:16:41 GMT

3mdeb

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

ufedor — Wed, 03 Jul 2019 16:04:36 GMT

How many boards were tested?

Can you replicate the issue on the LS1046ARDB?

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

macpijan — Thu, 04 Jul 2019 07:18:09 GMT

Tested on two boards.

Does it make sense to test on the LS1046ARDB?
I would need to reconfigure the RCW to configure the IIC2_SCL to GPIO4_2, not to SDHC_CD.
Moreover, the card detect signal from SD connector is physically connected to this pin,
so I'm not sure whether it is possible to reproduce that. Am I missing something?

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

ufedor — Thu, 04 Jul 2019 08:22:07 GMT

> We figured out that we can control this GPIO line when the SD card is NOT inserted in the SD slot.

GPIO4_2 multiplexing is performed only during POR according to the RCW data.

Please use a digital scope and check external level of the K3 pin when the SD card is inserted/removed.

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

macpijan — Mon, 08 Jul 2019 11:34:45 GMT

SD card inserted:
- K3 is LOW (no matter whether we are driving this pin od not)

SD card not inserted:
- K3 is HIGH when we set it to HIGH
- K3 is LOW when we set it to LOW or do not configure it as GPIO

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

ufedor — Mon, 08 Jul 2019 13:30:29 GMT

Is it required to have U-Boot running so SD card insertion will affect the K3 behaviour?

Please use a debugger to check the GPIO pin behaviour when SD card is inserted/removed.

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

macpijan — Tue, 09 Jul 2019 10:02:32 GMT

No, it is not required to have the U-Boot running. We have already confirmed this behavior without U-Boot running - using only the RCW and PBL commands to configure the GPIO, as explained in the original post.

Re: [LS1046A] Cannot change state of one of the GPIO lines (GPIO4[2])

ufedor — Tue, 09 Jul 2019 10:28:48 GMT

In the original post it is several times mentioned that U-Boot is running.

I've meant performing a test with core stopped (execution is paused in debug mode).