On Sep 2, 2023, at 2:31 AM, RVP <r...@sdf.org> wrote:
>
> On Thu, 31 Aug 2023, Brook Milligan wrote:
>
>> I have attached the test program below, and would appreciate more eyes on it
>> [...]
>>
>
> That looks OK apart from a few minor issues:
Thanks for the comments.
>
>> However, a write fails and hangs the board hard: no keyboard response, no
>> response to pings.
>>
>
> As the others have said, this looks like a kernel issue. Apropos which: from
> your `am335x-boneblack-comm_cape.dts' file:
>
> ```
> &am33xx_pinmux {
> bborg_comms_rs485_pins: pinmux_comms_rs485_pins {
> pinctrl-single,pins = <
> 0x074 (PIN_OUTPUT | MUX_MODE6) /* P9_13:
> gpmc_wpn.uart4_txd_mux2 */
> 0x070 (PIN_INPUT | MUX_MODE6) /* P9_11:
> gpmc_wait0.uart4_rxd_mux2 */
> >;
> };
> };
> ```
>
> Is that `RS-485' there correct? Shouldn't it be UART or RS-232 or something?
Those identifiers correspond to the previous definition, so the only criterion
is they match. In this case, the point of enabling uart4 is to use the comms
cape, which drives an RS-485 line, so the names are sensible.
> Following the links for the Comms cape from beagleboard.org, I landed here:
>
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Felinux.org%2FBeagleboard%3ABeagleBone_cape_interface_spec%23UART&data=05%7C01%7Cbrook%40biology.nmsu.edu%7C46d40788831f4b44749708dbab8f5566%7Ca3ec87a89fb84158ba8ff11bace1ebaa%7C1%7C0%7C638292404336120523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XATXK7U1cwSurE31gyO%2FcJNKset1PqzHk832b%2FTxsZY%3D&reserved=0
>
> where the `BONE-UART4.dts' has this:
>
> ```
> &ocp {
> P9_13_pinmux { pinctrl-0 = <&P9_13_uart_pin>; }; /* UART TX*/
> P9_11_pinmux { pinctrl-0 = <&P9_11_uart_pin>; }; /* UART RX*/
> };
>
> &bone_uart_4 {
> status = "okay";
> };
> ```
>
> There is also the `BB-UART4-00A0.dts' file here (where you got your .dts
> from):
>
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbeagleboard%2Fbb.org-overlays%2Fblob%2Fmaster%2Fsrc%2Farm%2FBB-UART4-00A0.dts&data=05%7C01%7Cbrook%40biology.nmsu.edu%7C46d40788831f4b44749708dbab8f5566%7Ca3ec87a89fb84158ba8ff11bace1ebaa%7C1%7C0%7C638292404336120523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c3U3fbh33%2B%2BThIqpzOiJhlDqWjoEz6ptm73PRcCI2UQ%3D&reserved=0
>
> with different contents:
>
> ```
> /*
> * Free up the pins used by the cape from the pinmux helpers.
> */
> &ocp {
> P9_13_pinmux { status = "disabled"; }; /* P9_13: uart4_txd */
> P9_11_pinmux { status = "disabled"; }; /* P9_11: uart4_rxd */
> };
>
> &am33xx_pinmux {
> bb_uart4_pins: pinmux_bb_uart4_pins {
> pinctrl-single,pins = <
> AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_OUTPUT, MUX_MODE6) /* P9_13
> gpmc_wpn.uart4_txd_mux2 */
> AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT, MUX_MODE6) /* P9_13
> gpmc_wait0.uart4_rxd_mux2 */
> >;
> };
> };
>
> &uart4 {
> /* sudo agetty 115200 ttyS4 */
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&bb_uart4_pins>;
> };
> ```
>
> No idea which is right (not an ARM-guy!). The folks on port-arm@ would know.
Part of the problem is that there are several different files out there as you
have found. However, I think on close inspection they all do the same. In any
case, two of them result in the same kernel hang.
Thanks for taking a look. I’ll continue this on port-arm@.
Cheers,
Brook
