Can't get past sudo screen /dev/ttyUSB0 230400 with RaspPi 3 A+

[AlanSwenson]

Ive had not problems with any of the first 5 tutorials but on Tutorial 6 I can't get the screen part to work.

I get Cannot exec '/dev/ttyUSB0': No such file or directory

I have tried ls /dev/ttyUSB*
and it doesn't return any results.

Can it have anything to do with using a USB->Thunderbolt adapter?

Any ideas?

[AlanSwenson]

I figured it out, but I am not sure why it's called this instead.
this is the command that eventually worked
sudo screen /dev/tty.SLAB_USBtoUART 230400

[ryankurte]

I am not sure why it's called this instead

this is probably because macos names serial devices differently to linux (and windows, which is also different), it would perhaps be useful to update the docs to indicate you will need to find the respective serial device

[AlanSwenson]

I’ll submit a PR when I get through 7 to make sure other differences don’t come up with the chain loader.

…

On Mon, Apr 6, 2020 at 8:37 PM Ryan ***@***.***> wrote: I am not sure why it's called this instead this is probably because macos names serial devices differently to linux (and windows, which is also different), it would perhaps be useful to update the docs to indicate you will need to find the respective serial device — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAWOLH6GSVG5VTXLIOXMHLRLJ7W5ANCNFSM4MCWNXVQ> .

[AlanSwenson]

getting stuck on 7 as well.
tried this:

# Default to /dev/ttyUSB0
ifndef DEV_SERIAL
	#DEV_SERIAL = /dev/ttyUSB0
	DEV_SERIAL = /dev/tty.SLAB_USBtoUART
endif

and it just hangs at [MP] ⏳ Waiting for /dev/tty.SLAB_USBtoUART

I can see the docker image is loading, i can see tty.SLAB_USBtoUART being added and removed when I take out the USB or put it back in but nothing is seeming to change Minipush

Also tried it without editing the code, but I assumed that wouldn't work and of course it didn't.

Thoughts?

[ryankurte]

yep, you can see here it's trying to bind the usb device into the docker container.

unfortunately this is not supported on docker for mac, looking at what that command is actually doing, you may be able to install and execute minipush on your native system instead.

[andre-richter]

Hi,

some thoughts on that:
It's true that Mac support is only experimental at the moment, but even that is not documented right now.

The problem with device names on Linux and Mac is that you never know what you are getting. /dev/ttyUSB0 is a good bet on Linux, but even there you sometimes get other names. On Mac, I've seen /dev/tty.usbmodem* or /dev/ttyAMA0, among others.

For that reason the Makefile has the quoted section you've already modified:

# Default to /dev/ttyUSB0
ifndef DEV_SERIAL
	DEV_SERIAL = /dev/ttyUSB0
endif

The way this is written also allows you to override it from commandline: DEV_SERIAL=tty.SLAB_USBtoUART make chainboot.

About the Minipush issue: One of the main philosophies of the tutorials is that beginners should not have hassles with installing third party stuff on their machines apart from Docker, which handles all the rest. Hence the strategy to pack everything into Docker containers. That this falls apart for Mac because we can`t pass through the USB device is a bit unfortunate.

I agree with Ryan that there's a good chance you can run Minipush native, though, once you installed the dependencies on your Mac. It should be something like:

sudo gem install bundler
bundle install --path .vendor/bundle #From the root directory

And then:

$ ruby ../utils/minipush.rb /dev/tty.SLAB_USBtoUART kernel8.img

Let me know if that works.

I'll take an action item to add notes about Mac support. I will CC you for review once I've done that 👍

P.S.: Please not that tutorial 9 will be a stumble again, because it uses OpenOCD and GDB inside Docker, and those again expect the USB device. You can again try to install them locally.

[AlanSwenson]

@andre-richter the steps you laid out got me further. I can now get connected and the lights flash a bit on the Rpi but then I get stopped at[MP] ⚡ Protocol Error: Remove and insert the USB serial again now

[andre-richter]

I presume it never works regardless of how often you try?

1. You could see output in the console in the previous tutorial using sudo screen /dev/tty.SLAB_USBtoUART 230400 right?
2. You also exchanged the kernel8.img on the SD card for the one from tutorial 7?

Can you try with sudo, just to be sure:

$ sudo ruby ../utils/minipush.rb /dev/tty.SLAB_USBtoUART kernel8.img

[AlanSwenson]

@andre-richter Correct, replugging doesn't help. sudo screen /dev/tty.SLAB_USBtoUART 230400 does work and I just reverified it again to make sure. Yes I exchanged the kernel8.img in step 7, also did it again just incase. Tried with sudo same results.

[andre-richter]

I just had a look at the data sheets and realized that the A+ apparently has only 512 MiB of RAM. We are currently assuming 1 GiB.

Can you apply the following change, build the kernel using make, copy the resulting kernel8.img on the SD card and try again:

diff --git a/07_uart_chainloader/src/bsp/raspberrypi/link.ld b/07_uart_chainloader/src/bsp/raspberrypi/link.ld
index 8061183..14e7103 100644
--- a/07_uart_chainloader/src/bsp/raspberrypi/link.ld
+++ b/07_uart_chainloader/src/bsp/raspberrypi/link.ld
@@ -5,8 +5,8 @@
 
 SECTIONS
 {
-    /* Set the link address to the top-most 40 KiB of DRAM (assuming 1GiB) */
-    . = 0x3F000000 - 0x10000;
+    /* Set the link address to 256 MiB */
+    . = 0x10000000;
 
     __binary_start = .;
     .text :

[AlanSwenson]

Just tried your suggestion, same results.

[andre-richter]

Running out of ideas for now...

Will try on a Mac this weekend. Stay tuned.

[AlanSwenson]

Also tried updating Ruby just in case since I had 2.3 on my system, but that didn't help either.

[andre-richter]

I just tried Minipush on a Mac and it worked for me.

I suspect it has to do with you having an A+ device. I only have B devices, do can’t really debug further myself.

Can you try reducing the linker address of the chainloader that we changed earlier even more for a few times. Maybe halving it on every step.

[AlanSwenson]

@andre-richter tried:
0x8000000
0x4000000
and on 0x2000000 I get (but only sometimes?):

[MP] ✅ Connected
 __  __ _      _ _                 _ 
|  \/  (_)_ _ (_) |   ___  __ _ __| |
| |\/| | | ' \| | |__/ _ \/ _` / _` |
|_|  |_|_|_||_|_|____\___/\__,_\__,_|

           Raspberry Pi 3            

[ML] Requesting binary
[MP] ⏩ Pushing 7 KiB ==========================================🦀 100% 0 KiB/s Time: 00:00:00
[ML] Loaded! Executing the payload now

 __  __ _      _ _                 _ 
|  \/  (_)_ _ (_) |   ___  __ _ __| |
| |\/| | | ' \| | |__/ _ \/ _` / _` |
|_|  |_|_|_||_|_|____\___/\__,_\__,_|

           Raspberry Pi 3            

[ML] Requesting binary

Got it on the first try with that linker address, then couldn't replicate it for like 5 more tries, then it did it a second time, then couldn't get it to do it again. Tried refreshing the card with fresh files. I also tried 0x1000000 but that has not worked successfully yet (or even partially successful as above)

[andre-richter]

That’s something!

There was a slight error on my side. On the commandline it should not be kernel8.img (this would load the chainloader again), but the demo_payload_... file.

On any other tutorial than 7, kernel8.img would be correct, though.

[AlanSwenson]

That worked! Not every time... but it still worked, had to unplug replug when it prompted me.

[andre-richter]

Yeah that can always happen. Also does for me from time to time. It’s not the robustest of protocols. A tradeoff done to keep it simple.

I don’t understand yet why it only starts working as low as at 0x2000000 (that’s 32 MiB), since the A+ has 512 MiB of RAM. At least according to Wikipedia.
So the 256 MiB should have been a safe bet. Anyways, I might permanently change it to 0x2000000 to have compatibility for all Pi3 devices.

Thanks for bringing this up.

P.S.: will also push a change soon so that „make chainboot“ will natively call the ruby command on macOS and not attempt the dockerized version.