Re: segfault in libterminfo with ncurses with nethack
On Sat 02 Sep 2023 at 09:37:17 +0930, Brett Lymn wrote: > I do understand that the issue with pkgsrc needs a fix but the deeper > issue, in my mind, is that ncurses is needed at all. It would be > really good if when people make the decision that ncurses is required > that they raise a PR on the built in curses detailing why they needed > to do this. In the case of nethack, the place where the cursor is put on the screen is "wrong" with curses. I put it between quotes because I'm not really aware of rules that prescribe this (the talk about cursor positions in curses_cursor(3) might as well be about the virtual cursor location in each window). But for nethack the cursor should most of the time be placed on top of the player, or for some commands that ask the player to indicate a location on the map it should move around the map as directed by the player. I suppose "use nethack as a test program" isn't desirable; it's a rather complex program. I already made a simplistic test program with just initscr() and move() and that worked as expected. So of course nethack is doing something more complicated that I have yet to figure out... I hope to commit games/nethack* some time today. I intend to make it easy to switch between the two curses versions (but not a formal option). > Brett Lymn -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: segfault in libterminfo with ncurses with nethack
Date:Fri, 1 Sep 2023 23:32:03 + (UTC)
From:RVP
Message-ID:
| So, something like this:
|
| PREFER.curses= pkgsrc
| .include "../../mk/curses.buildlink3.mk"
| .if ! ${PREFER.curses:U} == "pkgsrc"
| .include "../../mk/termcap.buildlink3.mk"
| .endif
| .include "../../mk/bsd.pkg.mk"
Wouldn't it be better to just delete the include of the termcap
buildlink file entirely? That is unless the application is
actyally using termcap functionality directly itself. If the
only reason it is there is because the NetBSD curses requires it,
surely the curses buildlink file should be adding it, when it is
needed (and not otherwise).
kre
Re: segfault in libterminfo with ncurses with nethack
On Sun 03 Sep 2023 at 01:42:42 +0700, Robert Elz wrote:
> Wouldn't it be better to just delete the include of the termcap
> buildlink file entirely? That is unless the application is
> actyally using termcap functionality directly itself. If the
> only reason it is there is because the NetBSD curses requires it,
> surely the curses buildlink file should be adding it, when it is
> needed (and not otherwise).
Indeed, NetHack is using termcap directly for the original UI, which is
called "tty". It can be built with several of them compiled in at the
same time. There is even a Qt interface, but it's Qt 4 so I didn't
try very hard to get it linking (there were some multiple defined
symbols), but it's mostly available in the UI selection framework.
The current variant which I have committed reads (comments stripped)
USE_NCURSES=yes
.include "../../mk/curses.buildlink3.mk"
. if "${CURSES_TYPE}" != "ncurses"
.include "../../mk/termcap.buildlink3.mk"
. endif
[...]
I switched to USE_NCURSES because pkglint says not to set PREFER.curses
in the package.
Testing with the other curses can be done by defanging the line
"USE_NCURSES=yes". So far I haven't been able to create a smaller test
case.
> kre
-Olaf.
--
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
Re: segfault in libterminfo with ncurses with nethack
On Sat, Sep 02, 2023 at 01:53:27PM +0200, Rhialto wrote: > > I suppose "use nethack as a test program" isn't desirable; it's a rather > complex program. I already made a simplistic test program with just > initscr() and move() and that worked as expected. So of course nethack > is doing something more complicated that I have yet to figure out... > A simple test program would be ideal but if that is not possible then detailed instructions to guide someone who has no idea how to play nethack that reproduce the issue and a clear indication of what is wrong with the display would be helpful. > I hope to commit games/nethack* some time today. I intend to make it > easy to switch between the two curses versions (but not a formal option). > I wont be able to do anything in that timeframe, I am preparing to go AFK for a few days. Please just submit a PR and I will look at it when I have a chance. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Re: /dev/tty01 will not open on Beaglebone Black
On Sep 2, 2023, at 2:31 AM, RVP 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
Re: /dev/tty01 will not open on Beaglebone Black
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:
- If you want to turn off non-blocking, use the standard idiom instead of
fcntl(fd,F_SETFL,0):
int flg = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flg & ~O_NONBLOCK);
- Call cfmakeraw() _before_ changing settings (not after) because it modifies
some bits (eg. CS8, ~PARENB) itself (see: src/lib/libc/termios/cfmakeraw.c)
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?
Following the links for the Comms cape from beagleboard.org, I landed here:
https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec#UART
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://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-00A0.dts
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.
HTH,
-RVP
Using cross compiler created by build.sh
I am building software that targets an Arm board. When the OS is NetBSD, I can use the cross-compiler created by build.sh to build software for the board. However, I also need to build software for the same board but a different OS, e.g., Debian. Can I use the same compiler? Is pointing it to the appropriate headers/libraries with -I/-L sufficient? Are there other tricks? Thanks for your help. Cheers, Brook
