Bootterm – a developer-friendly serial terminal program


There are plenty of terminal programs to access the serial console from minicom or screen to Putty. But Willy Tarreau was not quite happy with those tools, so he decided to write his own: Bootterm.

I was terribly fed up with the current state of serial terminals, which either don’t cope well with errors, or take ages to start, making you lose the first characters, or don’t support non-standard speeds etc. I finally wrote mine to address all that at once, plus support for automatic port detection (the last registered one is the good one by default), waiting for the port to be ready, and also support fixed or timed captures. And a few environment variables make it possible not to type any argument at all yet have the expected behavior. If that’s something of interest to you, you can check it there:

It’s still young (no support for automatic speed switching nor macros yet) but pretty usable, and I already switched to it

I happen to have BBC Doctor Who HiFive inventor coding kit connected to my laptop right now, so I gave it a try in Ubuntu 20.04:

Usually, I check the serial interface by running dmesg, right after connecting the device:

Bootterm allows you to list all serial devices connected to your host:

The * in the list means it’s the last connected USB device which in most cases means the serial console you’d want to access. It will be selected by default if you don’t type the device in the command line. That means you don’t need to even check the device use, simply run bt to connect to the board:

Cool! It just works out of the box! No need to check for device, nor baud rate.

You’ve probably found yourselves wanting to check the output from the bootloader, as soon as you connect the device. If you’re using a USB to TTL debug board that’s fine, but if you’re using one of those boards with built-in serial like the HiFive board I’m using now, this normally involves plugging the board to the USB board, finding out the device name, connect to serial, and then rebooting the board. But with bootterm you can simply use the n parameter which stands for “New”:

This will wait for a new USB device, and then automatically connect to the serial console. Let’s try it with the HiFive Inventor board.

This connects automatically to the serial console from the ESP32 module on my board. Pretty neat. But there’s also a serial console for the SiFive Freedom E310 microcontroller which we can access by specifying the device:

If I press the reset button and the board I can get the boot log from the RISC-V MCU:

It’s much easier to use compared to minicom where I’ve had to enter setup mode, type the serial board, select the baud rate and disable hardware flow control before accessing the serial console. Let’s not forget how easy it is to forget the command to exit the program too. But wait… how do we exit bootterm? We are informed about the command each time we start the program:

So it’s not too hard to access the help:

Hopefully, the use of the right-square-bracket ‘]’ will not cause issues with some keyboard layouts. But Willy must have already thought about this potential problem, and provided a method to change the escape character as well…

You can adjust the escape character with bt -exx command with options listed on the table on the right.

The program will use 115,200 bps baud rate by default, but you’ll find an option to change that:

Bootterm could also be used as a serial port detector in conjunction with other scripts, as the following command line report the last connected USB device without  any extraneous strings:

Bootterm C program is still under development, and Willy plans to implement automatic speed switching and macros. He invites anybody to try it out and report issues on Github.

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

16 Replies to “Bootterm – a developer-friendly serial terminal program”

  1. Thank you Jean-Luc!

    FWIW I’m now finding it convenient to ignore the ports I don’t use by default, and to wait for any other port to show up. Here’s what I’m setting in my PC’s .profile for this:

    I’m now working on adding support for macros. The idea is to allow to define some based on matching rules for the terminal (i.e. enable some for some chips that you know correspond to a specific board). I’d really want to have long “setenv bootargs” and “tftpboot” commands supporting environment variables by just pressing F1 or F2!

    I’ve also started to have a look at FreeBSD and with the help from a friend, figured how to auto-detect ports there as well. Not implemented yet 🙂

    1. One thing I thought of that might be neat is integration with micropython. From what I remember you get a standard python looking REPL and then you can use some tools that switch to a special mode to push and pull files. Having to switch back and forth between minicom and the tools was a pain.

      1. In my opinion that would fall into the “file transfer” category. I initially wanted to implement xmodem as it works basically everywhere, and a few extras like injecting Lua code to send or receive files. Micropython very likely works in a similar way, so we should likely plan a generic approach to file transfer and support various methods. Maybe we should think about a simple API to list remote files, receive and send them.

        1. >In my opinion that would fall into the “file transfer” category.
          >I initially wanted to implement xmodem as it works basically everywhere

          xmodem would be nice. xmodem + some macro magic to tell u-boot to load via xmodem with a higher than normal baud rate doing the switch to/from the higher baud rate automatically would be super handy for boards where ethernet doesn’t work in u-boot but you need to get a kernel into memory to recover it.

          >Maybe we should think about a simple API to list remote files,
          >receive and send them.

          That sounds good.

          I just remembered how bad minicoms file selection thing is. I still don’t know how to get it to navigate directories properly.. 😉

  2. BTW regarding Ctrl-] it should not pose any issue as it’s been successfully used by the venerable telnet for about 40 years now! That’s also why I reused it by default, figuring telnet is rarely used nowadays, and we shouldn’t expect to see it and bt chained too often. Alternately kwboot’s Ctrl-\ looks good as well (and we should even less commonly chain kwboot and bootterm :-))

  3. Tried it out, it works nicely. I’m perhaps too used to picocom, though 🙂 It seems like most of the missing functionality can fairly easily be implemented using a short bash snippet or alias, e.g.

    to wait for a device to enumerate.
    Would definitely want to include exclusion rules for my built-in WWAN (GSM modems), now that I can see how to do that. Perhaps it might be an option to blocklist specific drivers too? e.g. qcserial is unlikely to ever be an external device, so setting an environment variable to ignore those would be handy.

    1. This is written on the paper that lies on my desk 🙂 But that’s a good example indeed! I also want to support matching/excluding descriptions. When they are filled they tend to be more precise than the driver alone.

    2. Finally I just did it, it was trivial. Just export “BT_SCAN_EXCLUDE_DRIVERS=qcserial” and it will do the job.

  4. Looklike awesome and litle C code source!
    I like to use gtkterm but i want to try the great “Waiting for a new serial port”

  5. I think a terminal emulator you could directly boot into from grub would be interesting and useful for testing, i.e. no OS required

    1. Not that much because it would require an unused machine with a keyboard and screen. For most people using SBCs, it’s easier to find an already running machine and open a window on it than to find a spare set of keyboard+screen+motherboard+bootable device.

Leave a Reply

Your email address will not be published. Required fields are marked *