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

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

Since your CM4s have eMMC flash, the microSD slot on the TPi adapters will not be connected.

So, pull the CM4 out of Node 1, plug it into Node 2, 3 or 4, and run through the described procedure?

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.

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.

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.

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.

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

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

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.

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

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.

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.

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

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.

In which node?

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.

They said all their modules are eMMC

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

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

That happened in all the nodes.

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.

Never mind. I'm an idiot. I used the wrong filename. Collective "Duh" from everyone would be well deserved.

Naaah, that's ok

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.

I read this 3 times and I'm not sure what did you do

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?

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.

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

Thank you everyone on this thread, especially @terarex 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.