Loading an OS on a CM4 on a Turing Pi 2
# │forum
s
Greetings All ... I've come a long way. I connected to the BMC with the USB / TTL cable, set the static IP and enabled SSH root access. Now it's time to load an OS on the CM4s. Note that I've done this a dozen times using a Raspberry Pi connected to a CM4 plugged into an IO Board. So I've got the gist of it. But the process of doing this on a Turing Pi 2 is a little confusing, particularly when I try to follow the online instructions. First question is, do I need an SD card installed on the Turing Pi 2 board to do this? The instructions are a little nebulous. All four of my CM4s have eMMC flash memory. But the instructions refer to the SD card a few times. Next, I have rpiboot installed on a PC, and the PC connected to the Turing Pi 2 via the USB A to USB A cable. I get a "Device not recognized" error from Windows when I establish the connection. But I wasn't really expecting Windows to understand what the Turing Pi 2 board was. I run rpiboot, it goes into wait state. I plug in the USB cables and connect the PC and the Turing Pi 2, then run the specified tpi command, and nothing happens. I recall there being a USB enable feature on the CM4 that was corrected by using a jumper. But I'm not sure if there's a software setting equivalent. Thoughts? Thanks ! Sincerely ... Stephen
u
There are some tips over in https://discord.com/channels/754950670175436841/1096118528811212820 - You can flash EMMC storage - Putting the Pi in slots 2-4 is more stable than flashing in slot 1 - The sequence took a bit of trial and error for me
t
Since your CM4s have eMMC flash, the microSD slot on the TPi adapters will not be connected.
s
So, pull the CM4 out of Node 1, plug it into Node 2, 3 or 4, and run through the described procedure?
t
To program the eMMC on your CM4s in the TPiv2, you must "connect" the USB 2.0 port to the node and put the node into "device" mode. These steps can be done via the BMC's web interface or the BMC's /bin/tpi utility. Power to the node should be off while you set up the USB port. Once the port is configured, power the node on. The web interface is best for this purpose as the syntax to do it with the tpi utility is undocumented.
s
OK, that all makes sense. When I did that, I was able to get a response out of Node 2 when I plugged the USB cable in. But the response from rpiboot was: Loading: .\msd/bootcode4.bin Over and over and over again.
t
Okay, that's the same behavior I experienced yesterday with ALL node sockets. My CM4s don't have eMMC, so I thought the issue was exclusive to lite CM4s. My Samsung microSDs came with full size SD card adapters so I used rpiimager directly on my Windows 10 laptop.
Unfortunately, the node-specific UART ports are not configured by default for serial console debugging.
s
Yeah, wonderful. And that's kind of all it does when I run rpiboot against any of the Nodes. Is there, dare I ask, a workaround? One that doesn't involve prying the CM4 out of the Turing Pi 2, plugging it into an IO board, etc etc.
There was a sequence spelled out in the referenced thread, but that didn't work either.
t
Unfortunately, I don't know of a workaround. I have a fairly long USB-A to USB-A 3.0 cable. Some have had success with a short cable. That would seem to indicate a connection timing issue with rpiboot. I'll search the net to determine whether there is a way to tune rpiboot connection timing. I sure hope the developer didn't use a hard coded, counter-based timing loop
s
Yeah, and I'm seeing a lot of talk about pulling the CM4s out of Slots 2 and 3, leaving them in Slots 1 and 4, and flashing Node 4
Wondering if I have to rub my stomach in a circular pattern and pat my head at the same time while I'm doing this
Here's something else that seems incongruous to me: How does the rpiboot know which OS image to flash the eMMC with? The instructions describe setting a Node to Device mode while it's powered off, then connecting cables, then powering the Node on and running rpiboot, then running the tpi command, etc etc. But I don't see any mention of how rpiboot is referencing an OS image.
I used this command when flashing a CM4 from a Raspberry Pi: sudo dd if=/home/pi/Downloads/kali-linux-2021.3-rpi4-nexmon-arm64.img of=/dev/sda bs=4MiB
And ... Would this be any easier if I connected a Raspberry Pi to the Turing Pi 2 and following the same procedure I followed when I flashed the eMMC on the CM4 by seating it in an IO board and connecting it to a Raspberry Pi?
I ask, because connect the Turing Pi 2 to a PC and trying to flash a CM4 is causing all sorts of weird responses. But the process of flashing the CM4 from a Raspberry Pi while connecting the CM4 to an IO board was pretty simple, once you did it wrong a few times. The Turing Pi 2 is essentially an IO board, with a ton of other capabilities brewed in. Not to diminish the product, of course. And I understand it does oh so much more. But it's still an IO board for the CM4. So would connecting a Raspberry Pi to the Turing Pi 2 allow me to see the CM4 plugged into the Turing Pi 2 as a device in /dev/sda, or something like that?
t
Here is my plan: test flashing with the same Windows 10 laptop and USB on a Waveshare carrier. If it works, those components are eliminated as sources of the issue. If it doesn't work, I'll need to debug them.
It's possible that the addition of the multiplexors on the TPiv2 have messed up timing, but I'm not pointing any fingers yet. rpiboot should be open source, so there might be a way to Turing on debugging output and, eventually, address the issue.
w
Here's how to flash eMMC: 1. Don't use slot 1. Slots 2-4 work fine (for me!). 2. Stick an eMMC CM4 in slot 2. Use the BMC web interface to power off if through some fluke it is powered on. Connect a USB-A to USB-A cable to the PC and the vertical USB slot on the TPi2. 3. Use the BMC web interface to set device mode on node 2. 4. Use the BMC web interface to power on node 2. 5. Run rpiboot on the PC (I use linux but guess it works the same on winbloze). You should get some output along the lines of
Copy code
mark (master) usbboot $ sudo ./rpiboot
[sudo] password for mark: 
RPIBOOT: build-date Apr 13 2023 version 20221215~105525 21ba5119
Waiting for BCM2835/6/7/2711...
Loading embedded: bootcode4.bin
Sending bootcode.bin
Successful read 4 bytes 
Waiting for BCM2835/6/7/2711...
Loading embedded: bootcode4.bin
Second stage boot server
Cannot open file config.txt
Cannot open file pieeprom.sig
Loading embedded: start4.elf
File read: start4.elf
Cannot open file fixup4.dat
Second stage boot server done
6. Now run rpi-imager. Choose the image you want to flash, for storage choose whatever looks like "RPi-MSD-0001". Set any additional options (SSH, locale etc) and tell it to write. It will (hopefully) write and verify. Depending on what you're writing it'll take a couple to a few minutes. 7. When it completes you might get a file explorer window or 2 open (depends on your PC settings). You can examine/tweak the contents of the boot and root partitions if you want/need to. 8. Close the explorers. 9. Use the BMC web interface to power off node 2, then set the USB mode to host on node 2, or any mode on any other node, then power back on node 2. 10. Give it half a minute to boot. SSH into your shiny new node.
Well, that's how it happens for me @StephenStrangeWare . YMMV.
Oh, and programming works in all/any slot 2/3/4. Just have to move things around for the module which will go in slot 1.
For completeness, this is using an X230 thinkpad with an external, powered USB3 hub connected and a USB2 USB-A to USB-A cable from the hub to the TPi2.
Oh, and rpi-imager v1.7.1 (later versions don't run on my machine)
s
I'm in the process of flashing the CM4 plugged into Slot 4 of the Turing Pi 2 by using a Raspberry Pi Model 2 as the Host for running rpiboot. It seems to be working exactly that way it worked when I was using a CM4 plugged into a garden variety IO board. I'll share the various commands I'm using once I've confirmed that it all worked. But basically, I'm following the documentation that describes how to flash a CM4 eMMC using a Raspberry Pi running rpiboot. Fire up rpiboot, and the see the CM4 plugged into the Turing Pi 2 as a device in /dev - in my case, /dev/sda. Download an OS image to the Raspberry Pi, then use dd to transfer the image to /dev/sda.
d
I think your issue possibly was you have to power on the module after you set it into the device mode, or it won't be set for flashing
Then, you can flash the the way you know (with Raspberry Pi). The difference only is you need to set the node into the device mode and power it on, the rest is the same
s
I'm learning that as we speak. Using a Raspberry Pi Model 2 as the rpiboot host is the way forward. I can do the same thing to Node 1 without any fuss.
More to come ...
I did have to CM4 powered off when I set the Node to Device Mode. But I powered it back on before I began the flashing endeavor. All I could get it to do in Windows was flash "Loading: .\msd/bootcode4.bin" over and over again.
d
In which node?
t
Okay, so I read the Waveshare carrier board documentation. It specifically says you must flash microSD cards elsewhere. The USB flashing method only works with eMMC-equipped CM4s. In basic terms, lack of USB flashing of microSD cards is not a TPiv2 bug.
d
They said all their modules are eMMC
t
Yup. USB flashing is the only option. I'm not certain whether this is relevant, but the Waveshare doc says that USB 2.0 functionality is disabled. I think this is only for host-mode use from Linux. See https://waveshare.com/wiki/Write_Image_for_Compute_Module_Boards_eMMC_version
d
This is actually interesting. This means we might need to do this change to make a use of the USB 2.0 port on the back in the host mode. If this is this USB port. Hmm. I flashed one module with Raspberry Pi OS today I might check that
If this is indeed the same USB controller, then nice find!
s
That happened in all the nodes.
So, this is weird: I copied the OS image to each of the CM4s in sequence. But they aren't there. /dev/sda is empty.
d
I connected a pendrive into the USB port, set it to host mode and Node 4: ``` Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 0951:1646 Kingston Technology DataTraveler 160 Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ```so it works withour any changes. Might mean the other USB hub. CM4 has another USB controller, but the other one is not connected to anything in Tpi2.
s
Never mind. I'm an idiot. I used the wrong filename. Collective "Duh" from everyone would be well deserved.
d
Naaah, that's ok
We're all learning 🙂
The best thing in all of this you make a progress 🙂
s
I inadvertently dd'd the zip file to /dev/sda, then rebooted and expected to see a living, breathing image. The process appeared to be transferring files. So what I'm wondering now is where the image ZIP file went.
d
I read this 3 times and I'm not sure what did you do
You dd-ed a zip file and not an extracted image? I don't know dd well, maybe it canunzip
Then, why /dev/sda? Is this how it sees the eMMC?
s
I had Operating Systems loaded on three of the four CM4s that I'm using in my Turing Pi 2. When I ran rpiboot from a Raspberry Pi Model 2, it saw those Operating Systems as sda1 and sda2 off of /dev/sda. So I killed the partitions with fdisk, with the intent of transferring the unzipped disk image to /dev/sda using dd. But I dd'd the compressed image file, and not the image file (.img). Naturally, that didn't quite work. But dd looked like it was doing something. And it returned a checksum value afterward. So where'd the zip file go?
Yeah, it works really, really, really well when you transfer the .img file rather than the .zip file. now /dev/sda/sda1 contains /media/pi/boot and /dev/sda/sda2 contains /media/pi/rootfs
d
I've had no luck flashing eMMC via USB from Windows 11. I don't know if it is because I have several mapped network drives. But I could never get the storage to show up in windows. I had to switch to a W10 laptop, where it worked right away.
d
You slashed zip file onto it instead of unzipped image. Bot are just binary files to dd and it just is doing what you told it to do - you put a zip file onto the eMMC and it was there, but of course it was not a valid filesystem so the device could not boot nor you could see any partitions from RPi
Great to hear you managed to flash the modules
d
Thank you everyone on this thread, especially @Terarex (Dan Donovan) and @walkjivefly , as I would not have sorted out the eMMC flashing process without your posts. I'm definitely a newbie, and still a lot of things yet to be sorted out and understood with this board. Your expertise and openness to share that expertise is appreciated. I do now have Raspbian installed on one CM4 module, and SSH accessible, so definitely a big step. Onward and upward, lol.
68 Views