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.
Hello team,
I received inquiries about Pinmux configuration. According to AM335x's TRM "9.3.1 CONTROL_MODULE Registers", those registers are defined as follows.
9E4h conf_emu0 9E8h conf_emu1 9F8h conf_rtc_pwronrstn 9FCh conf_pmic_power_en A00h conf_ext_wakeup
However, according to u-boot source code (u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h), the following structure is defined
struct pad_signals { int gpmc_ad0; : (ellipsis) int emu0; int emu1; int osc1_in; int osc1_out; int pmic_power_en; int rtc_porz; int rsvd2; int ext_wakeup; :(ellipsis) int vrefn; };
Therefore, customer thinks there is different offset between TRM definitions and source code definitions. Should customer swap source pmic_power_en and rsvd2 ? Can we have adivice/comments on this, please?
Best regards,
Miyazaki
Hey Miyazaki,
We are looking into this discrepancies between TRM and Uboot SW. We will get back to you with more information before the end of the week. Thank you for your patience!
Best regards,
Hello Miyazaki,
Sorry for the delay here. We are following up with SW team in order to better understand why the Source Code differs from TRM values. What does it mean for the customer to "swap source pmix_power_en and rsvd2"?
Best regards,
Hello Zackary,
Thanks for your help
Customer is considering that “int pmic_power_en;” is out of position (offset is wrong) if TRM is correct. Therefore, customer would like to know they should modify them as follows. Can we have your advice, please?
struct pad_signals { int gpmc_ad0; : int emu0; int emu1; int osc1_in; int osc1_out; int rsvd2; // <-- int rtc_porz; int pmic_power_en; // <-- int ext_wakeup; : int vrefn; };
Best regards,
Miyazaki
Hello Zackary,
Can I have your expert's comments on this, please?
Best regards,
Miyazaki
Hi Miyazaki-san,
I added testing code in the latest u-boot (SDK 6.3), and the captured offset in u-boot is listed in the table below.
There’s a swap as shown below (yellow/green highlighted).
It seems the mux definition in u-boot (u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h) has been there for a long time, but there’s no functional impact even with the in-correct offset of “PMIC_POWER_EN” since there’s no other signals being multiplexed internally with “PMIC_POWER_EN” anyway.
PINMUX pad register name |
PINMUX pad register offset |
|
Design/TRM |
u-boot |
|
RTC_XTALIN |
0x09EC |
0x09EC |
RTC_XTALOUT |
0x09F0 |
0x09F0 |
Reserved |
0x09F4 |
0x09FC |
RTC_PWRONRSTn |
0x09F8 |
0x09F8 |
PMIC_POWER_EN |
0x09FC |
0x09F4 |
EXT_WAKEUP |
0x0A00 |
0x0A00 |
I'll report the findings internally on future u-boot code update. At the same time, your proposed code change looks good to me.
Best,
-Hong
Hello Hong,
Thank you for your clarification. I shared your comments on this with customer.
I appreciate your help.
Best regards,
Miyazaki