Mystery serial ports

MNT Reform
1

Well, not so mysterious. I know what they are :slight_smile:

So when I connect my Reform’s USB-C port to another machine, /dev/ttyACM0 and /dev/ttyACM1 come up, as described in the handbook. But nothing comes in or out of those ports at any baudrate - including the 1500000 bps baudrate mentioned for the RK3588 module I have.

The handbook hints at seeing kernel messages if a certain SD card is inserted. I haven’t looked further, but I’m guessing it’s a recovery image and the boot messages are redirected to the serial port in the kernel parameters, while it isn’t the case in the regular kernel. Correct?

Based on that assumption, I looked for serial ports on the Reform and sure enough, I found four /dev/ttyS ports, of which only one is connected (/dev/ttyS2). This matches what the kernel says at boot:

Jun 19 11:46:35 reform kernel: Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
Jun 19 11:46:35 reform kernel: feb50000.serial: ttyS2 at MMIO 0xfeb50000 (irq = 37, base_baud = 1500000) is a 16550A

So I figured that was the serial port whose other end my host computer sees as one of the ttyACM ports. I tried to send/receive stuff to it, again at different baudrates, but nothing comes across.

What am I doing wrong here? Do I need to enable or connect something inside the machine that isn’t connected by default?

2

Did you try rebooting with serial attached to see if you get output from u-boot? If the kernel is already booted, there’s no output, unless you enable the serial port as a console or spawn a tty there or echo other output there.

3

Yes. It’s a whole lot of nothing.

I tried spawning a getty too. Nothing too.

But generally speaking, I tried to send/receive stuff on both ends with tio at different baudrates, to no avail.

4

I’m still trying to make this work - particularly since I’m experiencing random crashes and CPU core stalls since the last update and I would like very much to capture kernel message on the serial port.

I shot this picture of SW4 without removing the CPU module:

reform_mobo_sw4
reform_mobo_sw4594×445 49.9 KB

All the switches seem to be on. That doesn’t look right, considering what the handbook says:

If you change to a Processor Module that uses serial port S2, you can activate this port using the 3rd and 4th DIP switches of SW4 on the motherboard, and deactivate S1 using the 1st and 2nd DIP switches. To disable access to the serial ports via USB-C, you can turn off all the switches of SW4.

The documentation says the RK3588 module uses S1. So it sounds like SW4-3 and SW4-4 should be off. Yet it sounds unlikely that those dip switches would be set incorrectly since the machine was put together by MNT.

What should I do?
Any help would be appreciated.

5

Well, if you want something done…

I went take a look at SW4, and all the switches are in fact off. So I switched on SW4-1 and SW4-2, and lo and behold, it works.

image
image1280×960 167 KB

untitled

Now all I have to do is figure out how to configure U-Boot to pass the kernel a console parameter without bricking the machine :slight_smile: I have never used U-Boot before…

1 Like
6

It’s probably not the right way to do this, but I couldn’t find any other that works. As expected, even the simplest things require a kajillion config files for no discernable reason nowadays…

So I edited /usr/share/u-boot-menu/conf.d/reform.conf and added console=ttyS2,1500000 to the end of the U_BOOT_PARAMETERS string.

Presumably I should be able to put this in /etc/default/u-boot but it’s not picked up when I do u-boot-update. So that’s the best I could do.

Additionally, I changed --keep-baud 115200,57600,38400,9600 to --keep-baud 1500000 in /lib/systemd/system/serial-getty@.service, so the getty process stays at the same baudrate no matter what.

7

if you want to overwrite settings in /usr/share/u-boot-menu/conf.d/reform.conf then you can put a copy with your custom settings in /etc/u-boot-menu/conf.d/reform.conf. Did you name your files like that? If you do not use that name, make sure that whatever name you choose sorts after reform.conf lexically or otherwise it will not overwrite settings in it. If this does not work then you found a bug and I’d like to fix it. I tried to document this at the top of /usr/share/u-boot-menu/conf.d/reform.conf. If something in there is not clear, I’d also appreciate wording improvements. Thanks!

1 Like
8

Oh… Somehow I missed the bit about the config files overwriting variables set by the previous ones in that order. Thus the U_BOOT_PARAMETERS I set in /etc/default/u-boot was always overwritten.

My bad. I didn’t RTFA. It works now:

root@reform# cat /etc/u-boot-menu/conf.d/reform.conf 
U_BOOT_PARAMETERS=$(echo $U_BOOT_PARAMETERS | sed -E s'/console=(\S+)/console=ttyS2,1500000 console=\1/')

root@reform# u-boot-update 
P: Checking for EXTLINUX directory... found.
P: Writing config for vmlinuz-6.14.6-mnt-reform-arm64...

root@reform# grep console /boot/extlinux/extlinux.conf 
	append   ro no_console_suspend cryptomgr.notests ${bootargs} console=tty1 console=ttyS2,1500000
	append   ro no_console_suspend cryptomgr.notests ${bootargs} console=tty1 console=ttyS2,1500000 single
2 Likes
9

One thing that would be nice is mention somewhere in the handbook that u-boot menu is used. It took me a while to realize modifying /etc/default/flash-kernel and reflashing the kernel wasn’t doing anything despite /boot/boot.scr being modified correctly.

11

So side question - as someone who doesn’t know much about USB-C: is there a way to do PD and data at the same time?

I’m looking around and I see USB-C splitter cables that purport to do that, but I know enough about electronics and stuff made in China to think they look super-sketchy…

12

The 2 splitter cables I bought on Amazon didn’t do the job for me (one was Hama and the other I don’t remember at the moment). What works reliably (until a working splitter is found) is feeding power from a lab or other power supply into the 2-pin power header behind the USB-C port.

13

It’s almost like a barrel jack would be useful :slight_smile:

2 Likes
14

I have a question regarding the UARTs on the RK3588 module:

Looking at the RK3588 module schematic, I find this:

image
image444×105 2.08 KB

and this:

image
image848×555 15.3 KB

So that explains why flipping SW4-1 and SW4-2 to connect UART1 to the USB-C serial thing exposes the console, but the console is on /dev/ttyS2.

But then the schematic also has this:

image
image625×150 3.52 KB

So I was hoping to talk to the LPC through /dev/ttyS0, yet…

image

How come?