Thermaltake Tower 100 Case Configuration Tips
# │forum
t
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.
I'm using a fully modular, Silverstone Nightjar 450W SFX-L power supply. The PSU mounting plate included with the Thermaltake Tower 100 is designed for an ATX PSU. To address this issue, I ordered this mounting plate from Amazon: https://www.amazon.com/dp/B0BFJZ16JK?ref=ppx_pop_mob_ap_share The Thermaltake and Silverstone mounting plates are combined here.
Since the PSU I'm using is passively cooled, I decided to add a 140mm Noctua exhaust fan to the space above it. The case includes four long screws that work perfectly for fan mounting. The Noctua silicone isolation mounts cannot be used here. While it isn't specifically documented by Thermaltake, the perforated plate being used for this fan can also accommodate two 2.5" or, possibly, two 3.5" storage devices within the motherboard space (above the PSU mounting area).
k
Same case here patiently awaiting a TP2, which will be patiently waiting some CM4s.
t
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.
The rear, 2x2.5"/2x3.5"/fan perforated mounting plate can be removed entirely (thumb screws) to provide easy access to the MicroSD and M.2 sockets.
After removing the perforated rear panel, 2x2.5" SSDs can still be mounted on the side of the chassis. These could be SATA, or with an M.2 to U.2 adapter and cable, NVMe SSDs. There are advantages to using U.2 SSDs. Most notably, higher capacity points. U.2 SSDs should be available in several endurance variations (1/3/5+ DWPD), while all M.2 SSDs are intended for very read intensive use (1 DWPD or less). M.2 endurance is quoted in Tera Bytes Written (TBW). This endurance spec does not consider NAND "grooming" or TRIM activity.
I mounted a 140mm exhaust fan to the back cover. This fan will provide maximum airflow for the M.2 NVMe SSDs. I shouldn't need heatsinks, but we'll see.
r
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?
d
The headers near the nodes are controlled by nodes and are 5V headers, so you cannot really use them
Yes, you can use Y-split cable or connect them to any other header like SATA power - will do the same
Keep in mind that this will power the FANs with 12V so they'll spin with their max speed - unnecessary and noisy
If you want to connect them to the onboard 2-pin port, there's going to be only one valid way - the size with (usually) black and red cables, the other side won't let you connect because of the notch and you do not connect at 2 middle pind either
You might want: - get external FAN controller - get an extension cable that slows the FAN down (Noctua adds these to their FANs, for example) - connect FANs to 7V (between 12V and 5V) or to 5V on the power connector (SATA, MOLEX, etc)
Not sure which case will suit you best
r
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... 🤨
d
I'm confused - so is this running or you got it wrong? 🙂
r
Got it running on the second try
d
Oh, well, betetr not make the mistake here as you can fry the FAN
r
What about the ADT7470 chip mentioned in the documentation? How would you use it to control the fans?
d
I'm not sure. I though it's this way but today I learned from the Team the FANs are connected to the nodes.
I'll ask, though
Which docs page is this?
At the very bottom.
d
Yeah, thank you. I'll confirm that and let you know once I know 🙂
r
Thanks for the help!
d
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.
If the FANs are too loud, I can guide you about how to slow them down but really the easy way is only to buy a controller of one of these cables with a resistor that slow them down. Other ways are more of a hack
@rubberduck Got confirmation that this chip is absent on the board and was a part of an older design, indeed
r
@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?
d
He's actually who I asked, so I guess the docs will get updated 😉
r
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?
--- So far the case fans operate independently of the motherboard and the CM4. I am thinking that I might want to get the first CM4 module govern the fan speed as this unit gets hotter than the rest; it routes traffic over its WIFI interface, acting as a gateway between the cluster and the home network.
d
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
r
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.
Passive cooling of the RPIs are probably enough provided that fresh air reaches the PIs.
Putting the PIs in a closed glass and metal box, even with generous filter intakes like for the Thermaltake Tower 100, I am not so sure I can do without case fans as heat will build up inside the box.
Case comes with two fans, where the top one pulls air out. Not sure how the rear one was mounted per default, should have checked before replacing it.
t
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.
s
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?
t
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.
Underside clearance with 1/2" standoffs. There is sufficient clearance for either a Samsung 990 Pro or WD Black SN850X M.2 SSD with factory heatsink. Forget using Sabient's Rocket tall heat sink on node4. No standoff is going to be viable with it. It's still pretty tight to work with. I'll try 5/8" and 3/4" today. Obviously, the TPi2's I/O shield doesn't fit. Once I feel like I have workable clearance, I'll either modify @DhanOS (Daniel Kukiela) 's I/O shield thing or ask him to do it.
d
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
t
Cool! Please do. Thank you very much.
d
I will then. Printing prototypes will probably get like a couple of days or so.
t
No worries. With this case the I/O shield is more for airflow than cosmetics.
Since I tend to be a control and monitoring freak, I got the front panel lights and buttons working in a logical way.
The LED sequence: - both LEDs off: BMC powered off or [re]booting. Nodes powered off. - Blue LED on, red LED off: BMC active (accessible from UART and ssh). Nodes powered off. - Blue LED on, red LED on: BMC active. At least one node powered on. Sorry, there doesn't seem to be additional granularity. Maybe the BMC could change brightness depending upon how many nodes are active. I'll accept its function is to be the equivalent of an automobile "idiot light".
Button settings: - "Power" has functionality identical to "Key1" - "Reset" has functionality identical to "BMC Reset"
Cabling of the LEDs and switches seems different than the documentation. I'll try to create a simple diagram of what plugs in where and +/- polarity (LEDs won't light with polarity reversed. They are diodes.🤓)
Photos are sometimes better than diagrams. Plus: I'm lazy. First photo is inward from the board edge. Second photo is outward, toward board edge.
On to testing of different standoff lengths.
I thought these, 1" #6-32 standoffs might be too long. Note: these thin (I believe #2) washers are required. The standoffs are not fully threaded. Without the washers, the standoffs become loose when fully screwed in because of the unthreaded area. With the washers, everything is good.
Plenty of clearance now and a custom, 3D-printed, I/O shield should work.
Recalled and running as before.
On to cable dressing and tie down. Then to tackle fan power and control.
d
Just to make sure - you know this USB controller wants some power through this SATA power connector, right?
t
Yes
The advantage of not having a PicoPSU. There is no lack of power and power options.
Much easier when the lower panel is removed (6 screws)
d
Nice!
I like the look
t
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.
d
> 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
So I'm flashing the SD cards in a SD card reader now
r
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!
t
Yeah. rpiboot detected one of my CM4s (node2). It's just looping on "Loading: .\msd/bootcode4.bin".
Confirmed node2 is in device mode. I'll try a different node slot.
d
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.
t
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.
k
Made some progress on getting everything setup on my build. Next step is getting the modules flashed.
Thanks for the photos, they definitely saved me some time.
t
Cool. There is an issue with flashing CM4s in the TPiV2. rpiboot is looping. Looks like a timeout, but I need to investigate further.
I've looked through Waveshare's instructions for flashing an OS using their CM4 carrier. USB flashing is only supported with eMMC-equipped CM4s. For lite models they say you must flash the microSD directly (not in the carrier). This is not a TPiv2 issue.
d
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
Oh, and yes, in general, flashing the SD cards this was is not supported, although can work. I've heard of people having much bigger success in flashing the module this way. I'm curious if anything can be done to make this working reliably (since the BMC is going to get an ability to flash the nodes at some point)
t
I suspect RK1 might need BMC flashing support. We kind of already know that NVIDIA Jetson modules require a native carrier.
d
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
t
Okay. Didn't know that (Chat is really busy). Did you use the TPiv2's USB 2.0 port or something else?
d
Yes
I'm in the process of updating it now, will include a way to flash using a VM (so you won't need native/bare metal Ubuntu 20.04)
t
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.
k
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 🤞
d
What do you mean by "Maybe the BMC flashing will be magically available then"?
k
Very sloppy language on my part. I meant the ability to flash CM4s from the BMC, not flashing the BMC itself.
d
Oh,. so definitely not in a month. 🙂
But I am going to try to add this for CM into the CE version of the firmware, maybe in a month? Who knows
t
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.
I don't know whether I'm getting 10Gbps performance. I'll see whether I can compile "fio" for aarch64. If so, I'll get some synthetic benchmark data. USB-C is hot-pluggable. However, you need to safely eject/power off the drive after unmounting the file system. There is a utility for this purpose, "udisksctl". It's part of the "udisks2" package. The syntax is "udisksctl power-off -b /dev/sda" on my Orin NX (L4T). The syntax might be slightly different on Ubuntu for Raspberry Pi.
d
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)
t
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.
The Orin heatsink arrived today from Waveshare. Its shipping path was similar to the Turing Pi V2, but a little faster. For US shipment, Waveshare uses Yanwen, International Bridge and USPS. It did take a little while for me to find my jewelers torx tools.
d
I actually ordered one yesterday to replace the Xavier NX one on the Orin NX. How does it fit?
t
Perfectly. It has the NVIDIA logo on the fan and requires the short PWM extension cable included with the TPiv2
d
Cool, thank you!
t
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.
Did you have time to parameterize the I/O shield thing? I can tell you're dealing with a very, very long TODO list.
d
I did not have a time for this, yet. I indeed have a long TODO
t
No worries. Could you point me at your I/O shield thing?
d
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
t
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.
d
Look what has arrived today here 🙂
This one did not have any USB cable added to it, but I have a spare
t
Mine didn't come with a cable either.
lspci shows the board is recognized. I tried moving the wireless USB keyboard/mouse adapter from the switchable USB 2.0 port on the TPi to a USB 3.0 port on the mPCIe USB card. Result was no HDMI output. Put the USB adapter back on the 2.0 port and there is HDMI output. I'm guessing this behavior is related to L4T and not the TPi. The boot manager prompt scrolled by on the UART connection when the keyboard/mouse dongle was plugged into the USB 3.0 port. I don't remember seeing it when using the USB 2.0 port. Will verify.
I plugged an M.2 NMVe to USB 3.0 device into one of the ports on the mPCIe card. The kernel sees the M.2 device and the disk partitions. I'll dig around a bit more with moving the USB 2.0 port to another node to see what happens.
Moved the TPi's USB 2.0 port to node2 and plugged the keyboard/mouse USB interface into a port on the mPCIe card. Now, HDMI output is present and the USB keyboard/mouse works fine.
d
This is interesting. I did not see such behavior with teh otehr USB controlelr I have
This one is based on the Reneseas D720202
The other one I have (and tested) is based on the reneseas D720201
The issue with the HDMI is a bit odd, but I'll try to check it
Just to make sure - you did set the SW1 correctly, right?
t
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.
d
I have 35.2.1 on the Orin NX in slot 1 with a Mini PCIe USB controller and the HDMI works.
I hope you can figure it out, though
If not, but you can write a set of condition for when the issue happens and when it does not, I can try to help with this or even ask some questions and try to figure it out with you
t
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.
d
> What USB port is hosting your keyboard and mouse? Correct
> I had no issues with the TPi's switchable USB 2.0 port in host mode But not with the Jetson Devices? They cannot put this port into the host mode
> Not very keen on the potential to short this board on the standoff I removed the standoff on one of my boards, but not on the other and I got with this janky temporary solution:
I used some paper and did not screw the module fully, just "enough"
Might work for the testing purposes
t
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.
I ordered a second, dual-port, mPCIe USB card. It arrived today, so I may not bother with the quad-port card.
d
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)
j
my case came today
d
Nice!
t
Yes. I tried, but I'll go back and try again later today.
d
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:
Copy code
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
Also, are you on Ubuntu 20.04 (this exact version)?
I'm working on updating the flashing instruction and they should be finished today so out today or tomorrow
t
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.
Note that when Orin is in node1 and the USB 2.0 port is set to device mode, Orin acts like it is in forced reset. Yes, node1 was powered off before USB 2.0 was put into device mode. USB power may be an issue on that port. Both of my CM4s are lite (no eMMC). I'll eventually try Xavier NX.
d
This is expected behavior - USB device mode also sets the foced recovery mode (required for flashing)
t
Got it.
I gave up on trying to flash the Orin NX in the Turing Pi node2 slot. Every time I tried, the script would fail on a memory error. The error message occured in the initial target device flash phase. It obliquely suggests an issue with the USB 2.0 connection between the machines. On the possibility that the Turing Pi's switchable USB 2.0 port is borderline on powering the circuit, I'll find a powered USB 3.0 hub and try that. When attached to node1 and in device mode, the USB 2.0 port either isn't powered or receives so little power, that the Linux system hosting the NVIDIA JetPack tools never sees the device. I fell back to my Waveshare Xavier/Nano carrier board. Everything there worked fine.
d
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.
I've heard that some people use USB 2.0 hubs and that helps
What I am not sure about why have you had issues even in the Waveshare board
Could I see the log, please? I went through so many things to make the flashing work that I might recognize the issue from the logs
t
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.
d
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.
Since you managed to flash the module with the help of the USB hub, there's probably nothing we can do about the MEMOEY ERROR but if possible, if you can retry flashing in node 2 without the USB hub to get the MEMOEY ERROR, I'd like to see an analyze a full log for this - might yield some additional information in the updated flashing instructions. Thank you!
t
Okay. I'll work on getting you some documentation.
d
Thank you!
In the meantime, I just finished probably the last pass on the flashing instructions. Now i have to shape it into an article, or probably a set of articles
t
@DhanOS (Daniel Kukiela) 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.
d
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
t
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.
j
@Terarex (Dan Donovan) 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
t
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.
BTW, I'm now using WD SN850X, double sided, 4TB SSDs. These require a heatsink, but WD doesn't sell one. The 1" standoffs still provide sufficient clearance. These heatsinks are difficult to get screwed into place. I'm researching different female-female, threaded barrel spacers to replace the surface mount ones. Not looking for longer, but I need a larger diameter screw head and screw shaft.
j
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?
t
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.

https://media.discordapp.net/attachments/1071828898343559269/1096874077257474068/PXL_20230415_185823949.MP.jpg

j
thanks for the help! I just ordered storage. Now I just have to wait for the RK1s
t
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.
b
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?
t
It's certainly possible to set up a remote XServer, but VNC might be easier.
b
Thank you
t
@Terarex (Dan Donovan) or @DhanOS (Daniel Kukiela) 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.
t
Unknown. I haven't tried to modify the I/O shield "thing". Any change would depend upon the added length to the standoffs.
t
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?
t
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.
t
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.
60 Views