I have a self developed carrier board. When flashing jetson then everything works untill the part where i have to “Please complete system configuration setup on desktop to proceed”. I am using linux screen command. With my carrier board nothing happens. When using another carrier board like the RTSO6002 then commands appear in the terminal and i can finish the setup.
When changing back to my developed carrier board then i can ssh into it and everything works. Micro usb and recovery mode work and access works, only the screen command and finishing setup are being difficult. Any reason or explenation to why that can happen or how to solve?
When using minicom and jetson is connected via microusb then the terminal is empty, but when disconnected then it shows that the device is not connected.
I can’t help with details, but unless your carrier board is an exact electrical layout copy of the dev kit, then the device tree must be edited. Devices, such as those related to USB controllers and Ethernet, will not be found and will not function because the drivers are not looking in the right place.
There are many plug-n-play devices which can self-describe. There are many others which cannot, and it is the device tree which names the device, its physical address, the driver to use, so on. Failing to name the correct address, or failing to set GPIO pins correctly implies non-function. I suspect this is why, but I have no knowledge of the specific device tree content so someone else will have to complete the answer. Most likely you will be asked about what you changed in the layout and what device tree edits you made to match that change.
If the setup is done some other way then the microUSB and ssh works.
Electrically my schematic is the same as p3509_a1 NX carrierboard.
Isn’t the micro usb only possible to configure to those 3 pins? 109 (USB0_N), 111(USB0_P) and 87(GPIO0: USB_VBUS_EN). Does the setup use those 2 pins, or does it come from somewhere else? My computer detects that the ttyACM0 is visible but no output.
I do not know the details of the specific pins, someone else will have to answer that. A more important question might be if all traces related to this are the same as in the dev kit carrier board; if those traces are unchanged, then the device tree from NVIDIA should work (for those parts of the carrier board).
Something similar applies to UARTs as well since these are not plug-n-play, and there isn’t really any kind of “detecting”…either they have some output or not (even scrambled output is output for those purposes).
The version of Linux itself won’t really matter in the case of device trees. As mentioned, only self-describing devices will be found by detection. A USB root HUB sits at some physical address on a bus, and if the drivers are not specifically told where this is, and told that this driver is to service the device, then it won’t work. You will need to carefully look at every routing of every pin of the module which might be related to the given function and see if the device tree entry is correct (if the layout is the same as the dev kit, then likely the device tree too is correct).
Please note that if you are speaking of ttyACM0 for serial console output, then not only does the device tree have to be correct, but also the software itself must be told to log to that device. If the Linux itself has been altered, consider it possible even if the ttyACM0 works, perhaps the edits did not tell Linux to perform serial console output there.
Just for whoever does answer this you might want to attach your device tree to the forum for them to see. Any changes related to what has failed would also be important (keep in mind that power rails powering any of this also counts as “related”).