Serial port redirection on MacOs captures no output

[zmanian]

Expected behavior

$ COLD_BOOT=1 cargo run --example hello
Hello, world!
(device has reset)

Observed behavior

$ COLD_BOOT=1 cargo run --example hello
(device has reset)

Notes

• The device enumeration seems to be in an unpredictable order so DEVNO =2 points to different paths. But tried pretty much all the usb TTY devices and no joy.
• What is up with the BAUD_RATE of 4_000_000? It seems like we use 115200 in other places?

[zmanian]

There seems to be a fairly rich universe of try to debug usb to serial stuff on MacOs so much so that there are multiple apps that work debugging it.

https://www.mac-usb-serial.com/

[zmanian]

The drivers on https://www.ftdichip.com/Drivers/VCP.htm seem to have an invalid signature on OSX 10.15.4.

Otherwise it seems a lot like this problem.

https://www.revk.uk/2019/12/ftdi-usb-serial-macos-catalina-resource.html

Also I tried VirtualBox but wasn't able to get HelloWorld to output. This is a bit odd because we definitely had success with VirtualBox and minicom to the uboot terminal in the a little while ago but I believe this was before the OSX 10.15.3->10.15.4 update.

[tony-iqlusion]

With https://github.com/iqlusioninc/usbarmory.rs/pull/64 applied I now consistently get a little bit of garble (which is the same every time):

     Running `usd-runner target/armv7a-none-eabi/debug/examples/hello`
(device has reset)
l�v�%

(previously I was getting no output at all besides the (device has reset) message, same as @zmanian)

[zmanian]

With #64, I’m getting no output still.

[tony-iqlusion]

I tried installing the FTDI driver here, as several people suggest the stock Apple driver doesn't support 4 megabaud:

https://www.ftdichip.com/Drivers/VCP.htm

Namely:

https://www.ftdichip.com/Drivers/VCP/MacOSX/FTDIUSBSerialDriver_v2_4_2.dmg

No effect, although some threads I've read from people having similar problems (also this blog post) suggest I might still need to edit a .plist somewhere... (which may not be possible with a signed driver?)

[zmanian]

KEXT signature on the driver seems to fail for me

[tony-iqlusion]

(never mind, I get the same signature validation error as @zmanian)

[tony-iqlusion]

After reading a lot of threads on this, it seems the only ways people have managed to get this working are:

• disabling system integrity protection 😱
• get a codesigning certificate from Apple and sign the drivers yourself

I'm thinking for the short term it might be nice to have an option to turn the baud rate down to something supported by the Apple driver?

[tony-iqlusion]

I succeeded in getting it to work at a lower baud rate with the built-in Apple driver by tweaking UBMR:

https://github.com/iqlusioninc/usbarmory.rs/pull/65

It seems like we should probably experiment to figure out what the highest supported baud rate is for the Apple driver, and I guess have some API or other means of configuring the baud rate and using a lower one when launched from macOS.

[tony-iqlusion]

I was able to reproduce @zmanian's issue on a separate USB armory, on my laptop where everything else is working, which seems to narrow the issue down to the USB armory itself and its state.

I think it may be related to this step:

$ sudo dd if=blinky.bin of=/dev/sda bs=512 seek=2 conv=fsync

which on Mac we were attempting:

$ sudo dd if=blinky.bin of=/dev/rdiskN bs=512 seek=2 conv=sync

(notably conv=fsync isn't supported by the macOS dd utility)

To attempt to determine the above is a potential cause, I tried to repeat the exact steps I used to get my device into a working state, which were:

• Put Armory in uSD mode
• Use imx_usb to flash the same u-boot-dtb image I used originally
• Run ums 0 mmc 1 in U-Boot
• sudo dd if=/dev/zero of=/dev/sda bs=512 seek=2 count=8 conv=fsync from Linux host
• sync on Linux host
• Hit ^C in U-Boot
• Remove Armory, flip switch back to eMMC boot mode

However, now I'm running into something even stranger. When I do the initial COLD_BOOT of the device on the runner on my mac-serial-hax branch (which works reliably 100% of the time with Armory 1), I get the following 100% of the time on Armory 2 (to which I just applied the above procedure on Linux):

$ COLD_BOOT=1 cargo run --example hello
    Finished dev [optimized + debuginfo] target(s) in 0.05s
     Running `usd-runner target/armv7a-none-eabi/debug/examples/hello`
(device has reset)
$

However, on all subsequent warm boots, it works!

$ cargo run --example hello
    Finished dev [optimized + debuginfo] target(s) in 0.05s
     Running `usd-runner target/armv7a-none-eabi/debug/examples/hello`
Hello, world!
(device has reset)
$

tl;dr:

• I think both devices are in the same state (but maybe not?)
• On my side, Armory 1 works 100% of the time on COLD_BOOT and displays "Hello, world!"; Armory 2 fails 100% of the time and only displays (device has reset)
• On warm boot, both devices work successfully and display "Hello, world!" on repeated warm boot attempts

[japaric]

However, now I'm running into something even stranger.

I have observed this (no output w/ COLD_BOOT=1) on Linux too. What's happening is that the USB-C receptacle on the Armory (to which you connect the Armory debug accessory) is off on cold boot. We have some (I2C) code that turns on the I2C receptacle before main that becomes a no-op on warm resets (because the receptacle is already on). On cold boot, the receptacle takes several milliseconds to properly connect to the debug accessory to the serial interface of the Armory so we have a delay to avoid sending data while the receptacle is still down.

You can try doubling the delay (6554 -> 13108) and see if that fixes it. Probably the receptacle on the second board is taking longer to initialize (due to variance in components). It would be great to have the pre-main code to block until the receptacle is ready but I haven't yet found the right flag to poll.

[tony-iqlusion]

I think this is solved now that #65 and #66 have landed