rpipico: configurable ttys

veremenko-y commented 3 months ago

Fixes: #1062

~~Because not everybody is able to connect UART as boot console for Pi Pico, I added the ability to reconfigure the order of tty's.~~

~~Amount of ifdefs has been growing a lot, so I added small mktty tool that parses config and generates devttyconf.c and devttyconf.h that maps devices appropriately. Format is very simple:~~

# Format: tty_dev tty_dev_number
usb 1
uart 1
usb 2

For now there's still a problem of USB ACM not connecting fast enough to get all boot messages printed. I could make it so it waits for any key before boot, but then unattended boot is broken. Should I add it as another option as well?

Version 2:

Stage 1: On startup devtty_init will wait for USB host connection, and if present before timeout expires, it will configure USB consoles first, UART second. So boot messages will be printed using detected device.

Stage 2: At root FS mount plt_param will get executed either from CMDLINE or from MBR. Boot arg in the format tty=[usb|uart]N,... will be parsed and tty's will get reconfigured once again.

For example, given tty=uart1,usb1,usb2 the following mapping will be configured

/dev/tty1 - uart1
/dev/tty2 - usb1
/dev/tty3 - usb2

EtchedPixels commented 3 months ago

That does create yet more things for the user to get wrong, and makes it ever harder to have a build that someone can just try.

It's been easier on the other ports that do this as they can probe hardware or you end up typing stuff at the boot: prompt (so you could print to several and declare whoever you type at console).

Is it reasonable to wait a couple of seconds at boot and see if there is a USB connect and if not boot with serial as the console ?

veremenko-y commented 3 months ago

Is it reasonable to wait a couple of seconds at boot and see if there is a USB connect and if not boot with serial as the console ?

It is reasonable. Unless you tell me to kill it, I'd like to keep the configuration of ttys. But I could instead set either default config that does detect usb1 fallback uart1 or use plt_param with default tty=detect or something. So in this case default build will pick up whatever active device is, but one can still configure whatever tty's (I'm also planning to add second hardware UART, that's why I hope you let mkconf stay)

EtchedPixels commented 3 months ago

plt_param is probably the best option. You can also then set the parameters you want to indicate if there is a usb console and how many tty ports are present. See "setboot".

I really don't like the make config stuff, it's just guaranteeing a load more bug/queries from everyone trying to figure out yet another layer of indirection on configuring the device.

So my preference is strongly

give USB a couple of seconds to connect, if it does it's the console
if not assume serial

Let the user specify the number of ports on the command line (or with setboot).

So you'd then boot with USB, log in "setboot whatever" and it's done and consistent with the other ports.

veremenko-y commented 3 months ago

I really don't like the make config stuff

You're the boss :) So current suggestion is:

By default and if #define CMDLINE NULL, wait DEV_USB_DETECT_TIMEOUT seconds, check if USB host is connected. If it is, put all USB devices first then UART devices into ttymap, otherwise the do the opposite and continue booting.
Alternatively parse boot parameter like this tty=uart1,usb1,usb2 which will fill in ttymap, and will not check for USB host
kputc will use UART before the devtty is initialized, in case something panics.

I just took a look at the code once more, and plt_param() is executed after device_init() and right before init is executed.

So I would have to initialize devtty with defaults as I described above, then do it again inside plt_param() which I hoped to avoid. And I don't want to change start.c without discussing it first.

I will prototype it the way I described it, but it'll likely need to change based on your response.

veremenko-y commented 2 months ago

I pushed the prototype for you to take a look at.

It's not fully functional yet, I still have few issues with USB console.

veremenko-y commented 2 months ago

Sorry for the delay, it does seem to work fine with default boot, but there are some issues with locking when changing the parameters in cmdline, and I've seen few Hard Faults running the system. I have a very busy week, but I hope to finish it the following week.