Neither miniterm nor minipush work for me

[simgar]

I have tried make miniterm in 05 and make chainboot in 06 and neither detects the USB serial device. I have two different USB serial devices and an RPi3 and an RPi4. I used miniterm in python3 and scip to test that both USB serial devices and both RPis will boot the kernel for 05, so I'm happy that everything should work.

I started with 05. I know nothing about Ruby so I resorted to the traditional approach of adding some print lines to see where it gets to. I added a puts line, here:

loop do
    sleep(1)
    puts '...serial still not connected'
    break if serial_connected?
end

Below, is my output. First, I ran the ls -l command and you can see that the USB Serial device is not plugged in/detected. Then I ran make miniterm and, after five loops, I plugged in the USB device . It's not detected. I cancel miniterm and re-run the ls -l and you can see the USB device is available on the host.

$ ls -l /dev/ttyUSB0
ls: cannot access '/dev/ttyUSB0': No such file or directory
$ make miniterm
DOCKER_MINITERM is docker run -t --rm -v /home/simgar/rust-projects/rust-raspberrypi-OS-tutorials/05_drivers_gpio_uart:/work/tutorial -w /work/tutorial -i --privileged -v /dev:/dev -v /home/simgar/rust-projects/rust-raspberrypi-OS-tutorials/05_drivers_gpio_uart/../common:/work/common rustembedded/osdev-utils:2021.12

Miniterm 1.0

Running...
[MT] ⏳ Waiting for /dev/ttyUSB0
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected     <---- USB Serial plugged in here
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
...serial still not connected
^C
[MT] Bye 👋
$ ls -l /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Dec 28 19:52 /dev/ttyUSB0

So, I wondered if it's possible to check if the USB device is available in the docker container session. [I figured I needed a different docker command line. I don't know anything about Docker or make, so I did a bit of trail-and-error.] To the makefile, after the section where you assemble the DOCKER_* command line components, I added:

$(info DOCKER_MINITERM is $(DOCKER_MINITERM))

so that I could see the command line, and

DOCKER_LS_USB = ls -l /dev/ttyUSB0

and then after the miniterm: section, I added:

##------------------------------------------------------------------------------
## Connect to the target's serial
##------------------------------------------------------------------------------
ttyusb:
    @$(DOCKER_MINITERM) $(DOCKER_LS_USB)

When I run make ttyusb, having left the USB Serial device plugged in from the previous tests, I get:

ls: cannot access '/dev/ttyUSB0': No such file or directory
make: *** [Makefile:200: ttyusb] Error 2

If I change it to:

DOCKER_LS_USB = ls -l /dev/ttyUSB*

I get

ls: cannot access '/dev/ttyUSB0': No such file or directory
make: *** [Makefile:200: ttyusb] Error 2

which is odd because I haven't told it to look for /dev/ttuUSB0.

Note: previously, the 200 has been 189 (and possibly other values).

When I run the same command on the host, I get:

crw-rw---- 1 root dialout 188, 0 Dec 30 11:05 /dev/ttyUSB0

To confirm this, I also added to the makefile:

DOCKER_DMESG_TAIL = dmesg -w | grep tty

and:

ttydmesg:
    @$(DOCKER_MINITERM) $(DOCKER_DMESG_TAIL)

and when I run make ttydmesg, I get:

[    0.000000] Command line: init=/init loglevel=1 root=/dev/vdb rootfstype=erofs ro vsyscall=emulate panic=0 eth0.dhcp eth1.dhcp linuxkit.unified_cgroup_hierarchy=1     vpnkit.connect=tcp+connect://192.168.65.2:34845 console=ttyS0
[    0.052173] Kernel command line: init=/init loglevel=1 root=/dev/vdb rootfstype=erofs ro vsyscall=emulate panic=0 eth0.dhcp eth1.dhcp linuxkit.unified_cgroup_hierarchy=1     vpnkit.connect=tcp+connect://192.168.65.2:34845 console=ttyS0
[    0.127565] printk: legacy console [ttyS0] enabled
[    0.500669] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A

Then I plug in the USB Serial device and there are no updates. At the same time, I was running sudo dmesg -w | grep tty in another terminal on the host and could see the USB device registering:

[13761.981312] usb 2-1: pl2303 converter now attached to ttyUSB0

As mentioned above, I have two different USB Serial devices (one USB, one USB-C) so I try the other one. I see no change on the container output but the host output shows:

[13901.182734] usb 6-1: cp210x converter now attached to ttyUSB0

Can you think of anything I can try?

I'm running Ubuntu VERSION="24.04.1 LTS (Noble Numbat)" on the host.

[BartMassey]

The Docker situation with serial ports is not great. To be honest, I haven't really tried to get this working: I just build directly in Linux without the Docker image and then use my fork of scip.

I was able to reproduce your issue. Sadly, I wasn't able to figure out how to fix it. Regardless of the arguments I give to Docker (--privileged, --device /dev/ttyUSB0:/dev/ttyUSB0) the device just doesn't appear in /dev in the container. I suspect the lack of any udev support in the container, but after an hour or so of messing around I've given up for now.

Perhaps someone who knows Docker better can help us out.

We will try to get this all fixed as soon as possible.

[simgar]

Thanks for investigating. At least I know it's not something obvious.

I noticed the Dockerfile was based on ubuntu 20.04 and I wondered if the original host was also 20.04, and maybe they've tightened some security since then, so I've built a bootable USB stick from 20.04. So far, I'm getting the same results but I haven't done a lot of playing with that one, yet.

[BartMassey]

miniterm uses an old Ruby that isn't available anymore, so we can't update the container to something more modern.

Like I say, it's a udev problem I think? Idk. I could have sworn that make chainload worked a few months ago, but it sure doesn't now.

[simgar]

You can close this ticket. I had two issues. The first was that I was using Docker Desktop. I'm not familiar with Docker. I already had it installed from another project. When I started these tutorials, I followed the Install Docker Engine link from the front page and clicking the Ubuntu link on there took me to the Install Docker Engine on Ubuntu page, which says:

so I made an assumption that I wouldn't need to do anything else and then forgot all about it.

Whilst I was digging, the day before yesterday, I came across a post where someone was working with some USB hardware in Docker Desktop and it wouldn't connect. Someone pointed out to him that Docker Desktop works differently from Docker Engine and didn't have as good hardware support, especially USB. Unfortuantely, that still didn't trigger my memory but I went through the process of uninstalling Docker Desktop and installing Docker Engine and then re-cloning the repo to get rid of all of my twiddling and 05 and 06 both now work for me.

The second was that my moulded blue-plug USB-Serial adapter works up to the point where [ML] Requesting binary is sent and then nothing happens, whereas my bare-circuit board USB-C Serial adapter works to completion.

Thanks for looking into this for me, earlier.

[BartMassey]

Ah. I am also using Docker Desktop, which explains why I was able to reproduce your problem. Thanks much: I'll try this myself!

Please share whatever detail you can about the serial adapters? I'd really like to understand what's going on there.

Thanks much for your patience as we figured stuff out. Glad you're working now.

[ZimboPro]

I had the same issue, thankfully this thread helped me to resolve it. Explicitly mentioning that is must be Docker Engine and Docker Desktop in the Readme would help