Hi,
I'm trying to port BSP 33.0 to a custom S32G274A board.
And I need to control the GPIO output to drive an external circuit at power on.
So I added in the s32_plat_config_pinctrl function of arm-trusted-firmware_2.5/plat/nxp/s32/s32_pinctrl.c:
#define SIUL2_MSCR_S32_G1_OPEN_DRAIN_GPIO_OUT \
(SIUL2_MSCR_S32_G1_OBE_EN \
|SIUL2_MSCR_S32_G1_ODE_EN \
|SIUL2_MSCR_MUX_MODE_ALT0)
void s32_plat_config_pinctrl(void)
{
linflex_config_pinctrl(S32_LINFLEX_MODULE);
sdhc_config_pinctrl();
/* PJ05: (open drain output gpio) */
mmio_write_32(SIUL2_0_MSCRn(149), SIUL2_MSCR_S32_G1_OPEN_DRAIN_GPIO_OUT);
mmio_write_32(SIUL2_0_MSCRn(663), 0x0);
/* PA06: (open drain output gpio) */
mmio_write_32(SIUL2_0_MSCRn(6), SIUL2_MSCR_S32_G1_OPEN_DRAIN_GPIO_OUT);
mmio_write_32(SIUL2_0_MSCRn(667), 0x0);
/* PJ07: (open drain output gpio) */
mmio_write_32(SIUL2_0_MSCRn(151), SIUL2_MSCR_S32_G1_OPEN_DRAIN_GPIO_OUT);
mmio_write_32(SIUL2_0_MSCRn(655), 0x0);
}
But how to drive the GPIO pin to output HI/LO?
Best regards
Peter
Hi,
We don't seem to reproduce the behavior you are seeing. Instead of the code you did under "fdts/s32gxxxa-rdb.dtsi", we just add the following:
&pfe {
status = "okay";
};
+&gpio {
+ LED-hog{
+ gpio-hog;
+ gpios = <119 0>;
+ output-low;
+ line-name = "PA_06_LED";
+ };
+};
/* IO Expander */
&i2c0 {
Since PH_07 (GPIO 119) under RDB2 is configured to work under the PFE2 interface, we do not have anything humanly visible to confirm the change. Still, we did use the same code with the difference of selecting "gpios=<6 0>" and we did see the LED turn ON (as seen under the "line-name" property).
On both configurations, we could log into Linux no problem.
Please, let us know.
Hi Daniel,
I think it may be an error caused by defined too many GPIO-HOG.
Because when I define only one PH07 no error occurs.
It seems that I need to operate GPIO actions in u-boot's board_late_init()
Do you have any example or good suggestions on GPIO and IOMUX operation under u-boot?
Thanks,
Peter
Hi,
Thanks for your feedback.
There is no documentation on this regard. The only information is the one provided inside the "doc" folder under the uboot path. Aside from that, nothing else. We do apologize.
Still, if you have questions on why your implementation is not working, we might be able to continue helping.
Please, let us know.
Hi Daniel,
The BSP33.0 uses the release/bsp33.0-2020.04 branch version
https://github.com/nxp-auto-linux/u-boot/tree/release/bsp33.0-2020.04
I found that the GPIO number of PH07 in this version is not 119 but 109.
#define SIUL2_0_BASE_ADDR 0x4009C000
#define SIUL2_1_BASE_ADDR 0x44010000
#define SIUL2_0_MSCR_BASE (SIUL2_0_BASE_ADDR + 0x00000240)
#define SIUL2_1_MSCR_BASE (SIUL2_1_BASE_ADDR + 0x00000400)
/* gpio output (open drain) */
#define SIUL2_MSCR_GPIO_OUT_OD (SIUL2_MSCR_S32_G1_MUX_ID_0 | \
SIUL2_MSCR_S32_G1_ODE | SIUL2_MSCR_S32_G1_OBE)
static inline void *s32g2_mscr_reg(void __iomem *base_addr, unsigned int offset)
{
uintptr_t addr;
addr = (uintptr_t)base_addr + offset * 4;
return (void *)addr;
}
/* MSCR 0-101 */
#define SIUL2_0_MSCRn(i) s32g2_mscr_reg((void __iomem *)SIUL2_0_MSCR_BASE, i)
/* MSCR 112-190 */
#define SIUL2_1_MSCRn(i) s32g2_mscr_reg((void __iomem *)SIUL2_1_MSCR_BASE, (i-112))
static inline unsigned s32g2_pad_to_gpio(unsigned pad)
{
if ((pad >=0) && (pad <= 101)) {
/* PAD 0-101 --> GPIO 0-101 */
return pad;
} else if ((pad >=112) && (pad <= 122)) {
/* PAD 112-122 --> GPIO 102-112 */
return (pad-10);
} else if ((pad >=144) && (pad <= 190)) {
/* PAD 144-190 --> GPIO 113-159 */
return (pad-31);
}
return 200;
}
#define S32G2_GPIO(i) s32g2_pad_to_gpio(i)
...
int board_late_init(void)
{
...
/* PH07 */
writel(SIUL2_MSCR_GPIO_OUT_OD, SIUL2_0_MSCRn(119));
gpio_request(S32G2_GPIO(119), "PH07");
gpio_direction_output(S32G2_GPIO(119), 0);
}
If the PH07 pin is not set in U-BOOT, the kernel can boot normally.
But as long as the PH07 pin is set in U-BOOT, it will cause a kernel panic
U-Boot 2020.04+g9cdfca686e (Jun 10 2022 - 11:46:41 +0000)
CPU: NXP S32G274A rev. 2.0
Model: NXP S32G274A-RDB2
DRAM: 3.5 GiB
MMC: FSL_SDHC: 0
Loading Environment from MMC... OK
Using external clock for PCIe0, CRNS
Configuring PCIe0 as RootComplex(x2)
Using external clock for PCIe1, CRNS
Frequency 100Mhz configured for PCIe1
Configuring PCIe1 as RootComplexSGMII(x2) [XPCS0 1G, XPCS1 1G]
ERROR: Invalid XPCS config on PCIe1
XPCS1 power-up failed
Setting PCI Device and Vendor IDs to 0x4002:0x1957
PCIe0: Link up! X1, Gen2
Device 'pcie@44100000': seq 1 is in use by 'pci_0:0.0'
Setting PCI Device and Vendor IDs to 0x4002:0x1957
PCIe1: Link up! X1, Gen3
BusDevFun VendorId DeviceId Device Class Sub-Class
______________________________________________________________________
pcie@40400000 RootComplex
| `-- 00:00.00 0x1957 0x4002 Bridge device 0x04
| |-- 01:00.000x1b4b 0x2b43 Network controller 0x00
| `-- 01:00.010x1b4b 0x2b44 Network controller 0x00
pcie@44100000 RootComplex
| `-- 02:00.00 0x1957 0x4002 Bridge device 0x04
| `-- 03:00.000x1344 0x6001 Mass storage controller 0x08
In: serial@401c8000
Out: serial@401c8000
Err: serial@401c8000
Board revision: RDB2/GLDBOX Revision D
Net: EQOS phy: rgmii @ 3Warning: eth_eqos (eth0) using random MAC address - 62:91:7d:20:50:f3
eth0: eth_eqosSerDes 0 was not initialized
Emac 2 not initialized
Invalid sgmii configuration for emac index 2Hit any key to stop autoboot: 0
SerDes 0 was not initialized
Emac 2 not initialized
Invalid sgmii configuration for emac index 2
switch to partitions #0, OK
mmc0 is current device
13824008 bytes read in 610 ms (21.6 MiB/s)
Booting from mmc ...
44079 bytes read in 18 ms (2.3 MiB/s)
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Using Device Tree in place at 0000000083000000, end 000000008300dc2e
Invalid PCIe1 lanes config
Failed to set mode for PCIe1
Invalid SerDes1 mode
Failed to set mode for SerDes1
SerDes 0 was not initialized
Emac 2 not initialized
Invalid sgmii configuration for emac index 2
DT: Disabling PFEStarting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 5.10.109-rt65+g0bace7fde5f5 (oe-user@oe-host) (aarch64-fsl-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35.1) #1 SMP PREEMPT Fri Jun 24 15:01:08 UTC 2022
[ 0.000000] Machine model: NXP S32G274A-RDB2
[ 0.000000] earlycon: linflex0 at MMIO 0x00000000401c8000 (options '115200n8')
[ 0.000000] printk: bootconsole [linflex0] enabled
[ 0.000000] SError Interrupt on CPU0, code 0xbf000002 -- SError
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.109-rt65+g0bace7fde5f5 #1
[ 0.000000] Hardware name: NXP S32G274A-RDB2 (DT)
[ 0.000000] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[ 0.000000] pc : setup_arch+0x164/0x58c
[ 0.000000] lr : setup_arch+0x15c/0x58c
[ 0.000000] sp : ffffffc010c93ef0
[ 0.000000] x29: ffffffc010c93ef0 x28: 0000000080b40018
[ 0.000000] x27: 00000000ffaa27f0 x26: 0000000000000000
[ 0.000000] x25: 00000000ffb2f400 x24: 00000000ffdf1298
[ 0.000000] x23: ffffffc010d33000 x22: ffffffc010c9e380
[ 0.000000] x21: fffffffefe600094 x20: ffffffc010ce7088
[ 0.000000] x19: ffffffc010000000 x18: 0000000000000030
[ 0.000000] x17: 0000000000001800 x16: 0000000000000000
[ 0.000000] x15: ffffffc010c9e7e8 x14: ffffffffffffffff
[ 0.000000] x13: 0000000000000000 x12: 0000000000000028
[ 0.000000] x11: 0000000000000015 x10: 0101010101010101
[ 0.000000] x9 : 3334ff6b6e6e6f5e x8 : 7f7f7f7f7f7f7f7f
[ 0.000000] x7 : 736d647164676e62 x6 : 000006161d090b74
[ 0.000000] x5 : 740b091d16060000 x4 : 0000000000000000
[ 0.000000] x3 : ce6ded8ca0000000 x2 : 000000000000000c
[ 0.000000] x1 : 0000000000000000 x0 : 0000000000000080
[ 0.000000] Kernel panic - not syncing:
[ 0.000000] Asynchronous SError Interrupt
[ 0.000000] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
What could be the reason for this?
Thanks,
Peter
Hi,
We cannot replicate the exact issue you are seeing on your setup.
We have configured both PA06 and PH07 on our board under BSP33.0 as follows:
arm-trusted-firmware\fdts\s32gxxxa-rdb.dtsi
When we see the status under u-boot, we have the following:
What we are seeing is that you are setting PH07 under SIUL2_0, which is incorrect, since PH07 corresponds to SIUL2_1. As for the number, it is the assigned logical number, but referring to PH07 as 119 should be the correct way.
Please, let us know.
Hi Daniel,
Good jobs!
When I set setting PH07 under SIUL2_1 it does alleviate the kernel panic issue.
But when setting both PJ07(#151) and PH07(#119) with gpio-hog.
I found that the <pinctrl_offset> value returned by s32cc_get_pinctrl_offset() is the same (=119).
Is this caused by the lack of adding <range->gpio_offset> in s32cc_gpio_get_xlate()?
diff --git a/drivers/gpio/gpio-s32cc.c b/drivers/gpio/gpio-s32cc.c
index 4863c1af..966e87f2 100644
--- a/drivers/gpio/gpio-s32cc.c
+++ b/drivers/gpio/gpio-s32cc.c
@@ -203,8 +205,9 @@ static int s32cc_gpio_get_xlate(struct udevice *dev, struct gpio_desc *desc,
range = &priv->valid_ranges[i];
range_begin = range->pinctrl_offset;
range_end = range_begin + range->cnt;
if (args->args[0] >= range_begin && args->args[0] < range_end) {
- desc->offset += args->args[0] - range_begin;
+ desc->offset = args->args[0] - range_begin + range->gpio_offset;
break;
}
}
Thanks,
Peter
Hi,
We may not understand the comment "found that the <pinctrl_offset> value returned by s32cc_get_pinctrl_offset() is the same (=119).". For both PJ07 and PH07 it returns the same value?
How and when are you calling the function?
Please, let us know.
Hi Daniel,
If you debug both PH07 and PJ07 in s32gxxxa-rdb.dtsi, you will get probe error message.
But debugging one of the GPIOs alone and tracking the <pinctrl_offset> value returned by s32cc_get_pinctrl_offset() in s32cc_gpio_direction_output() will get the same result (=119)
u-boot_2020.4/drivers/gpio/gpio-s32cc.c
@@ -124,6 +129,7 @@ static int s32cc_gpio_direction_output(struct udevice *dev, unsigned int offset,
int ret;
ret = s32cc_get_pinctrl_offset(priv, offset, &pinctrl_offset);
+ printf(":%s: offset=%d, pinctrl=%d (ret=%d)\n", __func__, offset, pinctrl_offset, ret);
if (ret)
return ret;
I think the reason for the probe error is that the last <desc->offset> values generated by the two GPIOs when calling s32cc_gpio_get_xlate() are the same as 7.
PJ07: desc->offset = 151 - 144 = 7
PH07: desc->offset = 119 - 112 = 7
Thanks,
Peter
Hi,
Thanks for your feedback.
It does indeed seem to be a bug under the driver. We could replicate the issue you were seeing.
It does seems that since PH07 and PJ07 have the same offset (but on different ranges) the PJ07 (gpio 151) hog was being put under the PH07 address (gpio 119), shown below:
Where PJ07 should be under "siul2-gpio118", instead of "siul2-gpio17".
By applying the patch under the xlate function that you have provided we can see both PH07 and PJ07 under the correct address, as shown below:
Also, after the patch, there was no probe error message.
Please, let us know.
Hi Daniel,
Thanks for your reply
Please let me know if there is a follow-up update on this part of the patch
Peter
Hi,
Since the development team is dedicated to the newer releases, could be a time for when the update is provided under the BSP33.0 version.
Still, we will provide this information to the development team.
Please, let us know.
Hi Daniel,
Thanks for your reply
Peter
Hi,
We may not understand the overall scope of your application, but you can set/clear a GPIO directly from the uboot terminal, if it is feasible under your application flow. You can set/clear a GPIO (i.e. PA_06) doing the following command:
As for the code method, you need to write to the needed GPDOn register (or PGPDOn, if you want to). Below will be the code method (with GPDOn) for clearing PA_06 (since LED_BLUE is connected under RDB2, we can see the result as the LED turning ON):
#define SIUL2_0_GPDO_BASE (SIUL2_0_BASE_ADDR + 0x00001300)
#define SIUL2_0_GPDO_6_BASE (SIUL2_0_GPDO_BASE + 0x00000005)
#define SIUL2_MSCR_S32_G1_SRE_7 (7 << 14)
#define SIUL2_MSCR_S32G_G2_PORT_CTRL_OBE_P_P \
(SIUL2_MSCR_S32_G1_SRE_7 | \
SIUL2_MSCR_S32_G1_OBE_EN)
#define SIUL2_MSCR_S32G_G2_PORT_CTRL_OBE_O_D \
(SIUL2_MSCR_S32_G1_SRE_7 | \
SIUL2_MSCR_S32_G1_OBE_EN | \
SIUL2_MSCR_S32_G1_ODE_EN)
void gpio_config_pinctrl(void){
/* PA06 pad: GPIO[6] GPO */
mmio_write_32(SIUL2_0_MSCRn(6), SIUL2_MSCR_S32G_G2_PORT_CTRL_OBE_P_P);
}
void gpio_set_state(int lvl){
mmio_write_8(SIUL2_0_GPDO_6_BASE, lvl ? 0x1 : 0x0);
}
void s32_plat_config_pinctrl(void)
{
linflex_config_pinctrl(S32_LINFLEX_MODULE);
sdhc_config_pinctrl();
gpio_config_pinctrl();
gpio_set_state(0);
}
Since we only modified ATF, once we enter Linux itself we lose control over the GPIO, since the BSP configures the same pin with a different function. Beware of this.
Please, let us know.
Hi Daniel,
Thanks for your reply.
I also tried to define the PH07 pin using gpio-hog
u-boot_2020.4/configs/s32g274ardb2_defconfig
--- a/configs/s32g274ardb2_defconfig
+++ b/configs/s32g274ardb2_defconfig
@@ -2,3 +2,4 @@ CONFIG_ARM=y
CONFIG_ARCH_S32G2=y
# CONFIG_SPI_FLASH_BAR is not set
CONFIG_SD_BOOT=y
+CONFIG_GPIO_HOG=y
arm-trusted-firmware_2.5/fdts/s32gxxxa-rdb.dtsi
--- a/fdts/s32gxxxa-rdb.dtsi
+++ b/fdts/s32gxxxa-rdb.dtsi
+/* GPIO1 */
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl1_gpio_hog>;
+
+ /* PH07 */
+ PH07 {
+ gpio-hog;
+ gpios = <119 0>;
+ output-low;
+ line-name = "PV4_EN";
+ };
+};
+ pinctrl1_gpio_hog: pinctrl1_gpio_hog {
+ fsl,pins = <PH07_MSCR_S32G SIUL2_MSCR_GPIO>;
+ };
but get the error
U-Boot 2020.04+g9cdfca686e (Jun 10 2022 - 11:46:41 +0000)
CPU: NXP S32G274A rev. 2.0
Model: NXP S32G274A-RDB2
DRAM: 3.5 GiB
MMC: FSL_SDHC: 0
Loading Environment from MMC... OK
Using external clock for PCIe0, CRNS
Configuring PCIe0 as RootComplex(x2)
Using external clock for PCIe1, CRNS
Frequency 125Mhz configured for PCIe1
Configuring PCIe1 as SGMII(x2) [XPCS0 2.5G, XPCS1 OFF]
Setting PCI Device and Vendor IDs to 0x4002:0x1957
PCIe0: Failed to get link up
Pcie0: LINK_DBG_1: 0x00000000, LINK_DBG_2: 0x00000800 (expected 0x000000d1)
DEBUG_R0: 0x0043f300, DEBUG_R1: 0x08200000
PCI: Failed autoconfig bar 20
PCI: Failed autoconfig bar 24
PCIe1: Not configuring PCIe, PHY not configured
In: serial@401c8000
Out: serial@401c8000
Err: serial@401c8000
Failed to probe device PV4_EN err: -16
initcall sequence 00000000ffb2a408 failed at call 00000000ffad43e4 (err=-16)
### ERROR ### Please RESET the board ###
I try to replace PJ05 or PJ11, it can be started normally, but PH07 will have an error.
Is there a special for the PH07 pins?
Thanks,
Peter