Based upon my reading of posts elsewhere, at least three (including me) Turing Pi v2 owners intend to use this chassis. A separate forum seemed appropriate. Initially, my chassis/case will be used "open frame" for hardware experimentation and debugging. Once the board and build kinks are worked out, the glass and steel panels will be installed and software experimentation will begin.

Same case here patiently awaiting a TP2, which will be patiently waiting some CM4s.

I've made other changes to the chassis to accommodate easy access to the Turing Pi v2's underside (BMC MicroSD and M.2 sockets). I'll post photos and a description of those changes. I've also acquired replacement motherboard standoffs of varying lengths to allow an M.2 SSD (with and without a heatsink) in Node 4's slot. I don't expect the standard TPi v2 I/O shield to work with longer standoffs. I'll probably ask @DhanOS for his design and modify it appropriately.

So, I got my case today and have started the build. Mine is black though... 😀 Haven't built a PC in what, 30 years or so, so please forgive my n00b questions. First one out: I am planning to use the default fans that comes with the case, but... How do I connect the two default case fans to the TPI board? There is one, two-pin fan header for the board, and four four-pin headers for the riser boards. Also the doc says there is an onboard chip that can control four fans but I have no idea how that relates to the five fan headers... Should I... * Connect both fans to the board fan header through a split cable? * Connect the fans to the riser board fan headers? * Somehow use the GPIO to control the fans? Also, given the fact that the case fans have three cables and the board fan headers have two and four pins, how do I map them?

The headers near the nodes are controlled by nodes and are 5V headers, so you cannot really use them

Thanks - got the top fan running by connecting the cable to the board fan header. Fifty percent of getting it right the first time, so of course I got it wrong... 🤨

I'm confused - so is this running or you got it wrong? 🙂

Got it running on the second try

Oh, well, betetr not make the mistake here as you can fry the FAN

What about the ADT7470 chip mentioned in the documentation? How would you use it to control the fans?

I'm not sure. I though it's this way but today I learned from the Team the FANs are connected to the nodes.

Yeah, thank you. I'll confirm that and let you know once I know 🙂

Thanks for the help!

In my case, the node FAN does not spin when I connect it with 4 wires (because of 0% duty cycle on the FAN speed PWM signal) and I asked about the chip. I've seen on some other diagram it's hooked up by I2C so I though I'll query I2C and figure out how to set the speed, but it was not there. I could not find the chip on the board either. Got information nodes are controlling the FANs. So, possibly this is part of an older design that did not get updated.

@costa-al the specification page is closed for comments or I would ask you to update the spec there - I guess somebody in the Turing team will correct the error?

He's actually who I asked, so I guess the docs will get updated 😉

So, I finally got my fans sorted for real, so I got... * 2 x BeQuiet! Silent Wings 4, 140 mm PWM High Speed; and * 1 Noctura NA-FC1 to manually trim the speed I mounted the first fan on top using the default rubber feet with the plastic pins that pulls air out of the case. I mounted the new fan in the same way as the default fan, i.e. laying on top of the frame instead of hanging underneath it. Figured I wanted a small gap between the fan and the cover. The second fan I mounted with screws in the back plate as the plastic pins stuck out too much and prevented the magnetic filter from being mounted properly. The second fan on the back is pushing air into the case. The Thermaltake PSU has a third fan that is part of the PSU that draws air from the case and out on the back. It is hardly ever active given the low power draw and the fact that it is governed by a termostat internal to the PSU. When the PSU fan is active, this all means that two fans (top and bootom) pull air out of the case and the back fan pushes air into the case against the motherboard. What do you think, would it make more sense to have all fans pull air out of the case?

If the case has FAN filters, you want both FANs to put air into inside of the case - positive pressure will mean the only air getting into the case is filtered and no dusty air is getting sucked into the case. If it does not have FANs, I don't think it'll matter for TPi2

Well, there are filtered intakes both in front of the fans and on the sides of the case, so I think any air getting into the case is filtered regardless.

I was trying to determine how to use the USB-C port on the front of my Thermaltake Tower 100 Case. It has a specific connector pre-wired to it. Found this $10USD-ish part on Amazon. It fits. My plan is to use the TPiV2s node4 USB header for this purpose. I have a USB 3.0 mPCIe adapter to connect node1 to the front pair of USB A ports on the case. It will be an Orin NX 16GB.

Similar questions here: https://discord.com/channels/754950670175436841/754950670175436848/1096470570381611048 Can you say if your experiences can apply to other commonly available cases, including fans and front panel connectors?

My TPi2 will be delivered this afternoon. I'll have real vs theoretical information to post over the next few days. Went through the Tower 100 Case yesterday to confirm airflow (top: input; rear: input; lower: output). Will be using a Noctua fan controller with the included 3-pigtail adapter. Also looked at internal cable routing with the goal of keeping the area around the board itself as clutter-free as possible.

I've had a plan to make one that's parametrized so you can export one for any standoff size. I'll make one if you won't

Cool! Please do. Thank you very much.

I will then. Printing prototypes will probably get like a couple of days or so.

No worries. With this case the I/O shield is more for airflow than cosmetics.

Just to make sure - you know this USB controller wants some power through this SATA power connector, right?

Yes

Nice!

Three Noctua NF-A14 PMW case fans working using a Noctua NA-FC1 fan controller. At full blast maybe 50dba. Definitely has positive pressure. Two CM41008000s powered on (node2 and node3) and booted. Now to clean up the mess in back, button things up a bit more and get on with testing compute module USB-A to USB-A microSD flashing. Once I've got this stuff done, I'm going to put in my Jetson Xavier NX 16GB to test its functionality. The Jetson Orin reference heat sinks are on their way from China. Once they arrive, things get serious.

> compute module USB-A to USB-A microSD flashing I tested this multiple times and often does not work (verification fails). I found out it depends on a card too. Maybe you'll have more luck, though

That looks good. I am considering the same tower, as there is a used one available close. Watching your build with interest as I wait for CM4 and RK1 to come available!

Yeah. rpiboot detected one of my CM4s (node2). It's just looping on "Loading: .\msd/bootcode4.bin".

Btw, I put the CM4s in the adapter board into Xavier NX DevBoard, and was not able to flash an SD card this way either, but the eMMC CM4 flashed without issues.

Hum. I assume that CM4s with eMMC will flash fine in USB device mode on the TPiv2. If confirmed, that should be documented. It would be nice if there was a workaround. Oh well, that's why I have SD cards with microSD slots. rpiimager works just fine.

Made some progress on getting everything setup on my build. Next step is getting the modules flashed.

Cool. There is an issue with flashing CM4s in the TPiV2. rpiboot is looping. Looks like a timeout, but I need to investigate further.

As I mentioned earlier, I got mixed results with flashing SD cards through CM4s. This mostly did not work even if I have had a success a few times

I suspect RK1 might need BMC flashing support. We kind of already know that NVIDIA Jetson modules require a native carrier.

Why do you think so? I successfully flashed Orin NX and Orin Nano in TPi2. If I get the Original Jetson Nano, I'm sure I'll be able to flash it in TPi2 too

Okay. Didn't know that (Chat is really busy). Did you use the TPiv2's USB 2.0 port or something else?

Yes

Yeah. Since I didn't have the TPiv2 board yet, I flashed my Orin NX's M.2 SSD in the Waveshare Jetson carrier board. The Orin reference heatsink from Waveshare arrived at LAX this morning, so I'll probably have it on Friday/Saturday.

I believe both the CM4s I have are eMCC. Unfortunately I had to pack things up for about a month while we move so I will be picking this back up in May. Maybe the BMC flashing will be magically available then 🤞

What do you mean by "Maybe the BMC flashing will be magically available then"?

Very sloppy language on my part. I meant the ability to flash CM4s from the BMC, not flashing the BMC itself.

Oh,. so definitely not in a month. 🙂

Finally got around to testing this USB 3.0 header to USB-C 3.1 adapter (https://a.co/d/6eelDvb). I have it plugged into node4's dual USB 3.0 header. The Tower 100's front panel USB-C 3.1 cable plugs into this adapter. I believe it is keyed. What might you use this for? As an example, I have one of these from Plugable: https://a.co/d/hUUmf89 It's a gumstick M.2 NVMe to USB-C enclosure. I have a CM4 in node4. Plugged the USB-C cable from the Plugable into the Tower 100's front panel USB-C port, the Plugable's LED came on and node4 automatically found /dev/sda. I used fdisk to remove the DOS partition (/dev/sda1), then create a new Linux partition. Made an ext4 file system and mounted it successfully. Performance seems much better than when I tried the same Sabrent Rocket PCIe 4.0 512GB M.2 (2232) SSD with the same CM4 on a Waveshare carrier with an M.2 slot.

You won't get 10 Gb/s The chip used is VIA VL805, which supports 5Gb/s, but on top of that it is connected to CM4 via a single PCIe 2.0 lane which is 5GT/s (so, in practice, less than 5Gb/s)

Yeah, I'm unsure why mkfs seemed so much faster with this setup than on the Waveshare carrier where the SSD was directly attached. Regardless, this is a way to use an M.2 device on a CM4 in a Turing Pi V2.

I actually ordered one yesterday to replace the Xavier NX one on the Orin NX. How does it fit?

Perfectly. It has the NVIDIA logo on the fan and requires the short PWM extension cable included with the TPiv2

Cool, thank you!

Once I get the latest JetPack installed, I'll also install the Xavier 16GB that I have, including in node1. This module is part of a Seeed Studio dev kit that is destined to be sold on eBay and replaced with a second Orin NX 16GB at some point.

I did not have a time for this, yet. I indeed have a long TODO

No worries. Could you point me at your I/O shield thing?

I made this one before I even have had my board, based on the photos: https://www.thingiverse.com/thing:5811444. I never printed it on my own but a few people printed it and didn't leave any comments, so I guess it's ok

The Orin NX 16GB is working in node1. The nice, LG 4K monitor I bought doesn't display anything. It's going back today. A humble VGA monitor works fine with the appropriate HDMI-to-VGA adapter. Confirmed that the UART port works. I'm going to test the pictured, dual-port mPCIe USB 3.0 adapter next. If, for some reason, there are issues, I can debug them. Once I have functioning USB 3.0 ports on node1, I'll try to install the latest JetPack.

Look what has arrived today here 🙂

Mine didn't come with a cable either.

This is interesting. I did not see such behavior with teh otehr USB controlelr I have

Yes. SW1 is set correctly. I'm trying to determine what set of conditions cause the Orin NX's boot manager to not display on the HDMI port and display on the UART. They're mutually exclusive. Could be the relative immaturity of 35.2.1 or Orin's initialization firmware. Since I need to install the latest NVIDIA JetPack, I'm going to move on and revisit.

I have 35.2.1 on the Orin NX in slot 1 with a Mini PCIe USB controller and the HDMI works.

What USB port is hosting your keyboard and mouse? I had no issues with the TPi's switchable USB 2.0 port in host mode, but I'd like to keep that port available, particularly since node3 has no other USB option. I have a second mPCIe USB adapter: the quad port one based on the Renesis D720201. Not very keen on the potential to short this board on the standoff. I like the power connector on it better than the SATA power connector on the D720202-based adapter. I've already managed to break some of that connector, but it still works.

> What USB port is hosting your keyboard and mouse? Correct

When installed in the node1 socket, Orin NX never appears in lsusb on the x86_64 machine regardless of whether the TPi's switchable USB 2.0 port is in host or device mode. When in the node2 socket (USB 2.0 in device mode), Orin NX does appear in the lsusb list, but the OS flash operation fails. I pulled out my pre-Orin, Waveshare carrier board and installed using it. NVIDIA still has work to do, but at least the install finishes successfully. I've now installed everything on two, 1TB Samsung 970 Pro, M.2 NVMe SSDs. One on node1. The other on node2. Since they're identically configured, I can experiment with SDKmanager on Orin NX in node2, while still having a functioning boot disk in node1.

Did you follow my flashing instructions for Orin NX? You cannot use the SDK Manager with Turing Pi and the flashing procedure requires some file modification (because Nvidia only supports own carrier boards)

my case came today

Nice!

Yes. I tried, but I'll go back and try again later today.

Make sure you've applied a change to one of the firmware files as I'm mentioning in the docs. Yes, Nvidia indeed removed that in 5.1.1, but I can assure you 5.1.1 can be flashed on TPi2 (so also Waveshare board) - I flashed 5.1.1 onto Orin NX and Orin Nano with TPi2. Haven't tried with the Waveshare board, but should be the same. The configurations are there, but slightly updated. The command to use is:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" \
  --showlogs --network usb0 jetson-orin-nano-devkit internal

Okay. Will try again in node2. At least for node1 and Orin NX, device mode doesn't work. The NVIDIA device never appears in lsusb.

This is expected behavior - USB device mode also sets the foced recovery mode (required for flashing)

Got it.

Power in the USB connection is not needed for flashing. The module is powered through the power circuitry and only a data line is necessary to flash the module.

Initially, I was trying to use SDKmanager. Obviously, it didn't work. I fell back to using the flash script, as documented in your guide. When the Orin NX was plugged into node1 (TPi USB 2.0 port in device mode), lsusb on my Linux host machine never showed an NVIDIA device. Same setup with Orin NX in node2, lsusb showed an NVIDIA device. Installation failed almost immediately when attempting to transfer the first image over the USB connection with a MEMORY ERROR. I fell back to the Waveshare carrier board and was successful fully flashing two M.2 SSDs. I put everything back into the TPi and confirmed the Orin NX booted successfully off the two, different M.2 SSDs that I built on the Waveshare carrier in node1 and node2. Just to further investigate, I purchased a small, powered, 4-port USB 3.0 hub. The hub was connected to my host machine and then cabled to the TPi. In this scenario, when the Orin NX was in node1, lsusb on the host had an entry for NVIDIA, but the flash script failed almost immediately. When the Orin NX was in node2, I was able to flash the M.2 SSD successfully. I'd be happy to repeat any step you'd like, if you point me at the logs you would like to review. The USB-A to USB-A 3.0 cable I'm using is 6 feet long and is MONSTER branded. Came from Amazon.

I'm super glad to hear you managed to flash the Orin NX in the Turing Pi 2 board. I'm thinking if I should add an information about the powered USB hub for the flashing purposes. This is yet another instance when this helped.

Okay. I'll work on getting you some documentation.

Thank you!

@DhanOS I don't know how to DM a file with Discord. Anyway, the log files I promised are attached. I'll try a short USB-A cable just to see whether the issue is related to signal loss. Might also need to look into adding a PCIe USB 3.0 adapter to my increasingly ancient dual-socket Intel system.

Oh, there's a lot of logs to analyze. Thank you! It'll take me a few days since I'll be mostly off for a few days. I'll let you know once I find something

Take a look at the README I put in the "with_hub/20230428" directory. I finally attached a USB-to-TTL cable to node2 to watch the Orin console messages. The set of conditions might be hard to repeat. The flash process with a powered USB hub sometimes failed with an NFS error on the Orin module. This error doesn't seem to be recoverable. I tried "ls" on the mounted file system and the command just hung. You'll never see this on the host side. The script just seems to be hung. Removing the partitions from the SSD may effect timing between the device and the host, but I have no way to measure this without possibly resorting to wireshark.

@Dan D. Do you know if the M.2 SSD from Samsung with heatsink fit in the case? What screws should I buy to make enough space? https://www.digitec.ch/de/s1/product/samsung-980-pro-mit-heatsink-1000-gb-m2-2280-ssd-16632679 It looks like they are about 0.86 centimeter high which is 0.34 inch Thanks for your help

The length is a bit of trial and error. Initially, I was using shorter, 1/2" or 12.7mm motherboard standoffs (with a small, solid washer). This was adequate for my non-heatsink, Samsung 970 Pro 1TBs, but I found there wasn't enough clearance to work comfortably in the space (I have osteoarthritis). I installed 1" or 25.4mm standoffs. These provide ample clearance, while still making it possible to use a custom, 3D-printed I/O shield. Since the female threaded portion of the standoffs is the same as the ones included with the case, I used them.

Great thanks for the answer! So I'm good with using the standoffs from the case or do I have to buy any otger screws seperately?

Nope. Just buy #6-32 spacers (don't forget the solid washers) and you should be fine. I included a photo of the parts bag from DigiKey earlier in this thread.

thanks for the help! I just ordered storage. Now I just have to wait for the RK1s

For anyone with this case looking to install 2.5" SSDs. Note the SATA signal and power cable routing in the drive brackets. SATA signal cables should be 1 meter to allow hidden/visually clean routing. These SATA signal cables are 18" long.

Might be better to flash the Orin NX in Slot 2, and then move it to slot 1 for the HDMI access, however, it should be possible to access the XServer remotely right?

It's certainly possible to set up a remote XServer, but VNC might be easier.

Thank you

@Dan D. or @DhanOS are the offsets to work with the T100 part of this file or did they need to be added still? I'm getting a friend to print a pair for me to work with the t100 and wasn't sure what the status is.

Unknown. I haven't tried to modify the I/O shield "thing". Any change would depend upon the added length to the standoffs.

Okay. I was planning on following your directions here and use the same standoffs as you did. Are default standoffs 4mm and you used 32mm?

I used 1" (25.4mm) standoffs. A longer standoff might work, but I wanted to leave some space at the top of the shield for structural integrity. I don't have a printer, but a friend does. I probably should revisit. Note: the design will need more modification for the TPiv2.5 since the rear ports have changed.

Awesome. I'll try and take a whack at updating the file at some point. Will be my first attempt at making a file like this so it may take a while.