First, I know that the documentation said that a USB-A to USB-A cable is recommended. But I do not have such a cable, and I also do not have a laptop with USB-A. So I tried a few different USB-A to USB-C cables, two different laptops and also different USB-C ports on the laptops and also turned the USB-C plug just in case it would matter. But so far, rpiboot does not find the CM4 eMMC. I'm now start thinking the USB-A port on my TuringPi2 is not working. Has anyone an idea? Unfortunately the BMC doesn't tell me if it should work or not. It just says "ok" when switching the mode.

Hi

ok. So in that case, I can't flash my CM4s without disassembling them again. And I'm probably not the only one not having USB-A ports anymore 🙂 Yes, I followed the steps. There aren't that many of them, and basically its very similar to the procedure of the "official" IO board. I checked out rpiboot, compiled and started it. I switched mode to device for a node (tried both tpi and web-ui) and then powered on the node (most of the time via web-ui, as tpi always boots all of them). rpiboot says "Waiting for BCM2835/6/7/2711..." and nothing happens.

Yes, you are not the only one who has this problem and I understand you, but then there's not this much we can help you with if you do not have the right cable or ports to flash the modules on Turing Pi 2.

Do you know if port replicators, docking stations and such would work to convert from USB-C to USB-A?

I can check. I'll be flashing CM4s today and I have this USB-C hub that gives you many ports including USB-A. I'll let you know later when I check this

thanks.

I understand. Maybe you have the right cable then because it really should not differ (the carrier board and the TPi2 just route USB to the module)

good to know, but unfortunately micro-USB doesn't fit into USB-A. 🙂 But I have a USB-C to USB-A cable from the same brand. I'll do again some tests with that. Can you confirm that I did the correct steps as written above? An I assume there is no way to check if the USB-A port ist defective, right?

One thing you might try is to not use Node 1 for flashing - I've heard people are having issues with Node 1 for fleshing and this is being investigated

hmm... "Second stage boot server done" 🙂

Sorry, what steps do you mean?

ok, I'm one step further. I successfully ran rpiboot on node2. Connection is now: TPI2 ----(USBA-USBC)-----> USB-C Y splitter -----> MacBook Pro.

Great to hear

the splitter made it. Not sure why. It wouln'd be necessary, but I think the splitter does only "USB", no USB-C power, videosignal and such stuff.

Which splitter do you have? Might help others

let me check

Thank you!

But me on the list of people having issues with node 1 for flashing

Ok, thank you for letting us know

The issue on Node1 I have is looping with "Failed to write correct length, returned 0" on rpiboot. I also had issues with other nodes, mostly that flashing stoped at 41% saying error writing. I eventually flashed the CM4 on the IO board (successfully), therefore I at least know the eMMC is ok. Anyway, thanks for your help @DhanOS

This is a bit odd. no one before have had issues like that (with other nodes)

hmm... maybe it's just my "special" cable combination. I was able to flash one, but failed on a few others.

Aren't the missing CC-Line Restistors the cause for not working solutions with USB-C to USB-A cables? If properly implemented, a USB-C port should only provide power and exchange data when it senses a device (device pulls down those lines via 5.1 kOhm resistors). Normaly, a USB-A to USB-C should be used this way around and not the other way (as the USB A Port is a host port and not a device port, as b types are or c could be). Therefore the A to C cable is missing the two resistors on the CC lines. I aassume that the reported cases, were a A to C cable worked, was with computers that "accepted" devices even if they did not sense them correctly. Also this should explain why the splitter worked. It would make sense, if the splitter has the resistors embedded and does not connect the cc lines to the devices (the resistance would be too low, if you connect two devices in parallel). A similar issue exists with the pitray cm4 carrier board. This just works with A to C cables (c port on the carrier board) and not with C to C cables, because it is missing the resistors.

Interesting. Thank you. And yeah, maybe, but we don't have enough examples to draw any conclusion yet. Interesting about the C-C cable on the Waveshare board.

Can confirm here that USB-A to USB-C cables do not work on a MacBook (macOS 13.2) here either... gonna have to go buy a new cable tomorrow

I have been successful with the following crazy combination (I didnt have a direct USB A to USB A cable to hand): Mac -> USB A to USB C adapter -> USB C M to F (USB C extender cable ) -> USB C to USB A Cable -> tpi2 The cable only works when used in the combination above, the reverse does not work.

Needs more adapters, that is crazy

Yeah, Node 1 is being problematic on some boards

Mac works too, if you follow the same instructions as for Windows. Maybe the instructions need updating? I had to specify

-d msd

for it to work with RPi Imager

I have the same problem here with Node 1, all other nodes work. As @DhanOS mentioned, I think some boards are problematic with that node. I wonder if its software or hadrware based issue 🤔

I already checked firmware sources and don't see a bug there

I was hoping it was software and would be fixed in a future update ☹️

FWIW - I learned today not to have "balena etcher" running on my mac while booting a CM4 in device mode. https://discord.com/channels/754950670175436841/1083173912306790510