Discussions

Although I can access my Turing Pi using a USB cable, I can’t seem to access the webpage interface using a browser or PuTTY (See Below). Using PuTTY: “Unable to open connection to turing.local Host does not exist” Using Firefox: [[email protected]](mailto:[email protected]):22 “This address is restricted This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection.” Using Firefox: [[email protected]](mailto:[email protected]) “Hmm. We’re having trouble finding that site. We can’t connect to the server at turing.local. If you entered the right address, you can: Try again later Check your network connection Check that Firefox has permission to access the web (you might be connected but behind a firewall)” Since my current BMC firmware version is not up to date (V1.0.0.7), I decided to update it, hoping the current version would address these issues. However, since I can’t access the webpage, I can’t perform an update OTA. But when I tried updating using the Phoenix Suit software, I ran into another problem. Phoenix Suit doesn’t recognize the USB connection. The message is: “No Device Attached Yet”. I thought that maybe I needed to reset the ADB daemon on the Turing board, so I logged in over the USB connection and tried the following commands; # adb kill-server - server not running \* # adb start-server # adb devices error: device offline I am guessing that my inability to connect to Phoenix Suit has something to do with ADB, but I can’t figure out how to resolve it. I would appreciate advice on any or all of the above. Thanks!

Hi!

I'm having trouble getting my CM4 Module in the node 2 slot to recognize the mini PCIe connection. I have 4 Raspberry Pi CM4 modules on turingpi carrier boards running DietPi in my turingpi 2 board. All four modules boot. I've been able to get docker swarm and portainer working. I want to add a glusterfs cluster, using nodes 1,2&3 to my Swarm for presistant storage. I have two SATA drives connected to the board SATA ports attached to Node 3 both of which are recognized. I'm using the recipe in the Swarm tab in the Docs but can't get node 2 to recognize its drive. I'm using two mini PCIe SATA adaptors. Both adaptors work in the Node 1 mini PCI slot but nieither is recognized in the node 2 slot. I've checked to be sure that all my drives and cables work by connecting them to node 1. I've double checked seating on all the boards. I believe I have enough power with a 430 Watt ATX power Supply. All 4 Sata Drives are recognized when I have two connected to node 1 and two connected to node 3. Only thing I didn't try is swaping CM4's between nodes, which I didn't really want to do because of node naming and IP addresses. I've tired the DietPi-drive_manager program in Node 2 the SSD does not show up, while when run on nodes 1 or 3 all attached dirves do showup. fdisk -l recognizes the drives attached to nodes 1 and 3 but not 2. Is there anything else I'm missing? Is there a BMC or other OS setting I need to change for node 2 to recognize the mini pcie slot?

[block:image] { "images": [ { "image": [ "https://i.imgur.com/4c937q7.jpg", "", "" ], "align": "center", "sizing": "360px" } ] } [/block] [block:image] { "images": [ { "image": [ "https://i.imgur.com/4Z503Vg.jpg", "", "" ], "align": "center", "sizing": "360px" } ] } [/block] Here is a simple 20x20mm aluminum extrusion carrier base, with some AliExpress standoff mounting brackets for the MiniITX board. An aluminum mesh provided protection against falling screwdrivers and such (when on or near the desk). Pricewise between a Dimas Tech (cheaper than my solution!) and an openbenchtable. But who knows how this evolves. For the moment I am happy that about every other month I seem to got hold of another CM4. How are _you_ mounting your TuringPi?

I have some Raspberry Pi cm4s. Can I connect m.2 SSDs after installing them on the turing pi clusterboard?

ssh connection to Turing pi 2 BMC prompts for credentials but the username and pwd in the documentation does not work. Is ssh enabled be default & what are the credentials?

For use on a Turing Pi, today I prepared a Jetson Nano Development Kit B.01 that I had laying around for some time. The whole procedure took almost 6 hours, and I encountered many surprises along the way. Please share your "gotchas" here, as this will give a more complete picture. 1. **Requirement of Ubuntu 18.04 LTS**: While I anticipated using a recent version of Ubuntu, the Jetson Nano's dependency on Ubuntu 18.04 LTS <https://ubuntu.com/18-04> took me by surprise. In an era dominated by frequent updates, reverting to an older OS was an unexpected requirement. The necessity stems from compatibility issues with the `sdkmanager`. 2. **Persistent Live USB**: Here's a twist: creating a regular live USB with Ubuntu 18 (image file available at <https://releases.ubuntu.com/bionic/> ) won't cut it for the Jetson Nano installation. I learned the hard way that standard live USBs don't provide enough filesystem space to retain the vast amount of data, such as downloadable and interim files, generated during the setup. Hence, the need for a persistent live USB, which ensures that these critical files are storable (and remain accessible across reboots). Seems that anything less than 32 GB is not not enough, although I managed to mount on the fly another additional SSD and pointed `sdkmanager` to that (has 2 configurable paths). However, without the live system having >8GB free on / (that is / as in root of a Linux OS) I could not successfully complete the installation. 3. **NVIDIA Account Dependency**: Diving into the installation, it wasn't immediately apparent that an NVIDIA account would be pivotal. Needing an account to access critical software components is one thing, but keeping an email tab open for a confirmation from NVIDIA was another unexpected step in this technical dance. 4. **Multiple Boot Modes**: While I've tinkered with several devices in my time, the Jetson Nano's array of boot modes was something special. The recovery mode, in particular, is not just a failsafe. It's instrumental for tasks like flashing and debugging. Fortunately I had this little jumper thingy at hand. 5. **Two-Phase Installation with sdkmanager**: Typically, installation processes are fairly linear. However, the Jetson Nano introduced a unique two-step dance. First, there's the sdkmanager setup on the host machine. Following that, it guides you in installing the Jetson Linux OS and JetPack SDK. This duality provided a window into the layered nature of the Jetson platform. And yes, `sdkmanager` checks if requirements for both host and target are fulfilled. 6. **Multiple Options for First Login**: Nearing the culmination of the setup, I was presented with choices for the first login. It wasn't as simple as keying in credentials. Would it be a headless setup, or should I go the traditional route with a monitor and keyboard? Plus, for those revisiting the Nano, there's the possibility of a re-flash. Choices, choices! What are your gotchas when it comes to the Jetson Nano? If we collect info here this might be turned into pullrequests for the documentation… :)

i am trying to understand if CM4 adator can be plugged into jetson developer kit so can you provide datasheet for CM4 adaptor

How to connect USB3 to node1?

I finally received 2 CM4 modules after a long time and used them to start up my Turing Pi2 board for the first time today and promptly have the following problem: Node2 does not seem to work, it does not get a DHCP IP address. The CM4 module #1 works in all other slots without problems. If I take the CM4 module #2 for comparison, I get the same error: Slot 1,3,4 no problem, the CM4 gets a DHCP address. Only slot2 does not work, with both CM4 modules. Unfortunately slot2 does not use HDMI video output to check if it is only a network issue or if slot2 refuses to work at all. Any hints?