Enabling KGDB for AM335x

[James B <jamesbrowning137%gmail.com@localhost>]

Hi all,

I'm not sure if this belongs in a PR or a project proposal, but after a few
weeks of tinkering I've finally gotten KGDB working using UART1 of my
BeagleBone Black. I'm wondering if we could upstream some changes to enable
KGDB capability on AM335x chips.

Here is a summary of changes I had to make to it get working:

1. Change my GENERIC.local according to netbsd.org/docs/kernel/kgdb.html
2. Add a couple small work arounds for some missing/conflicting symbol errors.
    I've opened a PR for this one:
gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=59419
3. Add kgdb_attach code to ti_com.c to connect UART1 to kgdb during consinit.
4. Add some statements to correctly mux the uart1 pins, since they are not set
   to uart by default, and the fdt_bus isn't setup yet.

Regarding number 3, after many headaches I finally found that my uart wasn't
coming up because I was using COM_TYPE_NORMAL (same as the console uses in
ti_com_console_consinit), but this seems incorrect. I found that the mode in
MDR1 is not being configured to 0x0 (uart 16x), but instead was still set to
0x7 (disabled). After changing the type to COM_TYPE_OMAP I found that it now
works.

As an aside, I wonder if the console (uart0) should also use
COM_TYPE_OMAP, but it
seems that it works with COM_TYPE_NORMAL, I suspect because the registers are
already configured by u-boot.

Below are my changes, but they are very specific to using UART1. I wonder
what a good way to make this more general would be? Perhaps instead of defining
the macros in ti_com.c, there could be new config options which allow the user
to define the mux register addresses/values? Maybe something like:

        options AM33X_KGDB_RMUX=0xdeadbeef, AM33X_KGDB_TMUX=0xdeadbef3
        options AM33X_KGDB_RMUX_VAL=0x30, AM33X_KGDB_TMUX_VAL=0x0

Finally, there is the issue of device trees. If you want to use KGDB, you have
to ensure it doesn't conflict with the pin mux settings of your board's device
tree, otherwise the pin mux driver will just overwrite the configuration that
gets set in consinit. Luckily for BBBlack, uart1 tx/rx aren't used, so
there's no
issue with muxing the pins early like described above.

===============================================================================

diff -r d708c4dcdd7d sys/arch/arm/ti/ti_com.c
--- a/sys/arch/arm/ti/ti_com.c Sun Apr 27 23:30:39 2025 +0000
+++ b/sys/arch/arm/ti/ti_com.c Tue May 13 12:08:07 2025 -0700
@@ -44,6 +44,15 @@

 #include <arch/arm/ti/ti_prcm.h>

+#if defined(KGDB) && defined(AM33_KGDB_UART1)
+#define AM33_CTRL_MOD 0x44E10000
+#define AM33_CTRL_LEN 0x2000
+#define UART1_RXD_MUX 0x980
+#define UART1_TXD_MUX 0x984
+
+extern struct bus_space armv7_generic_bs_tag;
+#endif
+
 static int ti_com_match(device_t, cfdata_t, void *);
 static void ti_com_attach(device_t, device_t, void *);

@@ -159,6 +168,19 @@

  if (comcnattach1(&regs, speed, uart_freq, COM_TYPE_NORMAL, flags))
  panic("Cannot initialize ti com console");
+
+#if defined(KGDB) && defined (AM33_KGDB_UART1)
+    bus_space_tag_t arm_bst = &armv7_generic_bs_tag;
+    bus_space_handle_t ctrl_bsh;
+
+    /* Need to mux the pins since fdt bus isn't up yet */
+    bus_space_map(arm_bst, AM33_CTRL_MOD, AM33_CTRL_LEN, 0, &ctrl_bsh);
+    bus_space_write_4(arm_bst, ctrl_bsh, UART1_RXD_MUX, 0x30);
+    bus_space_write_4(arm_bst, ctrl_bsh, UART1_TXD_MUX, 0);
+    com_init_regs_stride(&regs, bst, dummy_bsh, KGDB_DEVADDR, 2);
+    if (com_kgdb_attach1(&regs, KGDB_DEVRATE, uart_freq, COM_TYPE_OMAP, flags))
+      panic("Cannot initialize kgdb console");
+#endif
 }

 static const struct fdt_console ti_com_console = {