Jetson TK1 - End of Life?

Autonomous Machines Jetson & Embedded Systems Jetson TK1
1

Thread-topic formerly: “Jetson TK1 collecting dust, let’s make it work…” now see this post for the true repurposing of my TK1 unit!
7/22/17 update: Thread-topic formerly: “Jetson TK1 as both an encoder and RTMP server” - scrapped

I bought the TK1 with the expectations that it was a modular powerhouse that was capable of doing anything you could come up with.

The sad realization came when Nvidia finished the hardware and moved on, seemingly leaving the community itself to come up with solutions to problems and limitations encountered when dealing with the software end of things.

My Jetson unit never filled the problem it was intended to solve (which the developer is now in the process of finally fixing anyway) and I no longer care about my Jetson TK1, so go ahead community. Give me the tools to build something bleeding-edge, risky, brick worthy to put on my TK1 to make it soar like an eagle or go out with a bang.

I’ll inspect the code of whatever you throw at me and as long as it isn’t intentionally trying to brick the unit, I will do anything to it you want me to software wise. Let me be your failsafe guinea pig.

Kind of really excited to see where this one goes, if this forum is even still alive.

2

Hi MrFreeman,

The latest release R21.5 for TK1 is here:
[url]https://developer.nvidia.com/linux-tegra-r215[/url]

And you may need to reflash it with JetPack2.3: [url]https://developer.nvidia.com/embedded/jetpack[/url]

Thanks

3

Thanks! However neither of these appear to be beta or alpha versions. Are there any nightly developer builds I can install?

4

R21.5 is the most recent L4T release. I have not heard of any official nightly build, but there is a publicly available repo which might be of interest (I think this is more for kernel, and is not necessarily just for the Jetson TK1):
[url]http://nv-tegra.nvidia.com/gitweb/?p=linux-3.10.git[/url]

5

I see that the latest commit occurred on 8/16, and up until then, the log shows a fairly consistent flow of updates. Is the development in hiatus or have the developers moved on to something bigger and better not yet publically available?

6

If I really must be more specific than “Let me test your bleeding edge software so you don’t have to damage your own board in the process”, then I would like to request my Jetson TK1 be turned into both an RTMP server as well as a remote x265 video encoder.

I will update everything else to the latest builds before I attempt this, however.

7

FYI, hardware encoding on a JTK1 is H.264. For hardware encoding of H.265 you’d need the JTX1 (though software encoding is still possible). This is just my opinion, but it seems that as multimedia heads towards higher resolutions H.264 will get used less and less, but everything done on H.264 will still be needed…H.265 should be able to handle that too though. The choice of H.264 or H.265 might depend on whether you’re supporting the latest and greatest of multimedia.

8

The encoder linked supports H.264, but it’s highlighted feature is it’s ability to encode in H.265. I would adjust the settings accordingly when I compile the software for use on the Jetson TK1.

And again, if a JTX1 unit is needed to do what I want, it really shows how unprepared nVida was to produce such hardware at the time of it’s release. “Micro supercomputer” eh?

Sidenote: Why is the forum software so broken? URLs have to be manually parsed into URL links and quotes do not correctly quote the original poster. smh

9

Hijacking my own thread because posting new threads here in the past have only lead to posts never appearing on the forum:

So I basically tripped over my TK1 box again and brought it out. Many of the Puget case parts are missing and are no longer sold on their site which links to an unpurchasable amazon link (TX1 case also unavailable from the same company), so I suppose the wiki should be updated.

I found the original Micro USB cable and PSU and fired it up with Jetpack 3.0 in Windows 10 and all went well until I realized there was no HID support in bash yet, so another temporary virtual machine it is.

Having never used Jetpack before, I was very disapointed. All I wanted to do was flash the board and there were many hoops to jump through on the local system before I could even get to that point, in which once flashing occured, no custom options were given for how the kernel should flash. I’m not quite sure I understand the logic there but sure. I prefered the old method where I could store the data on whichever medium I wanted. The Jetpack software really seems like it was designed for the TX1/2 and the old TK1 board just happened to lay the foundation, so support was lacklusterly thrown in.

That said, in the entire lifespan I have owned this device and the many dollars I’ve spent on parts, accessories, cables, and adapters… I have not actually processed a single byte of data that has been useful to me.

With almost every concievable idea I’ve ever had to use this device beeing solved by a simple solution using a Arduino parts and a few lines of code while the TK1 failed in expensive ways to reach impassible limitations, I must ask how much longer the TK1 will be supported? It felt like there was no support for it at launch and it still feels that there is still no support from nVidia save the fact that the board is an option in software for it’s higher end boards.

Even if I compare the prices of the TK1 currently on Amazon to how much I paid through nVidia (digital rivier at the time) the price hasn’t really come down either. For $400 more you can jump to the TX1/TX2, but the amature dev might be turned away from such high prices (and make the same mistakes I did?).

I am still trying to understand the point of the TK1’s “budget micro supercomputer” current purpose, as it seems most possiblities with the board create more limitations and challenges rather than solutions to the problems it has been tasked to do.

Sidenote: The board still has the same broken functions as before. smh

10

JetPack can only work under Linux. Much of the host side only under Ubuntu. The Java part of JetPack probably does display on Windows, but there is no chance the flash software and much of network setup can work. If you were using Windows this would guarantee failing…for JetPack use Ubuntu 14.04 (to some extent Ubuntu 16.04 will work).

VMs are also an issue, they tend to fail setting up USB correctly unless some USB settings are tweaked.

On the kernel side U-Boot makes it so you don’t actually need a lot of flash options. In most embedded systems the kernel will get its own partition, and probably the device tree as well (such as with fastboot). The Jetson just uses a file copy into “/boot”. There aren’t many options to a file copy.

FYI, the command line flash does not do work with packages in general, but it is very simple to use and does the flash itself from any x86_64 Linux using a native Linux file system type. When doing this you may discover the rootfs directory allows all kinds of customization if you prefer. For example, I set mine up with networking and ssh keys before flash.

Personally I use command line flash since my host is Fedora.

So far as bash and a mouse goes it was never bash which used or required a mouse interface…this is the gpm daemon for having mouse in console mode…when gpm runs you can use a mouse with bash, ksh, csh, tcsh…you name it, if it is text mode, gpm can copy and paste. Turning on gpm though is part of the operating system, and you need to install gpm then enable it.

A big difference for Jetson and many other embedded systems is that it really does run a full Linux distribution which isn’t cut down. It is a steep learning curve just to know all of the details for getting the most out of Linux, and then doing the same thing in an embedded world is even more difficult. A big part of the barrier to entry is just knowing which parts of problems are Jetson problems versus Linux problems…and whether it is really a problem or just complicated.

The place and reason for going through all that is if you need to mix GPU computation and graphics in an embedded system not consuming a lot of power. All kinds of small systems can do well if you don’t mind ten times the power consumption…or if you don’t use the GPU.

11


I don’t know what else to tell you other than this Jetson’s Micro-USB port has never touched a native Ubuntu system and has operated within normal specs.

EDIT: I must confess, to actually have the TK1 board do something, I did compile a PSP emulator which actually utilized the GPU, and it did run at a nice framerate. Compiling a Gameboy emulator which only utilized the CPU, however, yielded slowdowns and unlistenable sound. I suppose that is the only frame of reference for which I have experience with the board producing any kind of result from an input.

I also suppose if you’re trying to take embedded hardware with a full linux distro and throw it at a problem which can be solved for under $50 in Arduino parts and coding, perhaps such a complex board should not be used for those type of applications. Still mad about no native RTC though. That just never made sense. Was that changed in the TX line?

I suppose it really does come down to recognizing what is necessary to solve a problem. Just because you can go buy a mini tractor to dig a hole does not mean using a shovel will not get the job done more efficiently for small scale projects.

12

The actual flash executable is the part which can only run on desktop Linux (any x86_64 distribution)…the architecture of the executable file has no method of working on any other operating system (emulations don’t count…they are desktop Linux). The flash script itself relies on loopback to create a file system using ext4 and Linux tools…none of which are possible on Windows. The NTFS and VFAT file systems have no knowledge of ext4 features, e.g., permissions, group ownership, device special files…none can exist on Windows without changes which cause bad behavior when booting a Jetson. The JetPack GUI itself is not really flash software, it is only a front end.

I do run a JetPack GUI and extract package URLs that way for manual wget download, but until I can avoid wiping four hard drives and buying a new Windows license key to work around Ubuntu’s installer UEFI/BIOS mode detection bugs there is no option to install Ubuntu (Ubuntu installers have a bug where a UEFI-capable motherboard in BIOS legacy mode still tries to install for UEFI…but then does not have the UEFI partition for firmware…USB and other drivers fail with no workaround). Without this I could not have CUDA. JetPack has never touched my Jetsons because I would have to throw out several operating systems and rebuild from scratch using UEFI mode (or I’d have to figure out how to flash from Ubuntu without the firmware needed in USB and other drivers). I keep going back to try and figure out a way to do this, but so far no luck.

VMs can work, but there is a very large failure rate at using them to flash…those who do succeed often require tweaking USB features of the VM, e.g., buffer size. To say JetPack works on Windows when using a VM is cheating :P

Originally the Jetson TK1 was introduced only as a developer board where it was thought organizations would use this for testing and reference design, and then build their own board. I doubt the idea that people would use the board directly for problem solutions was in the original planning. The TK1 was the start of getting commercial industries interested in self-driving cars, battery-powered drones, so on…who would have imagined the board would end up being so popular for the average guy like an RPi instead of large companies? In the past (prior to Jetsons) NVIDIA had mostly created reference designs and manufacturers built the consumer products based on that design (e.g., you’d find many brands selling similar NVIDIA chipset video cards, but would not have bought one directly from NVIDIA). So the consumers are a new industry of smaller companies or individuals which did not exist before when the TK1 was introduced. The RTC is just one of those things where the interface was there for those wanting to test designs, but wasn’t really needed for who it was thought would use the board.

13

I think when the TK1 was due to launch a lot of people, myself included, were looking for a good alternative to Raspberry Pi, and I really wouldn’t consider Arduino a contender at the time. Many many news articles also used RPi as a comparison, so I can understand (pretty sure I’m one of them) why some flocked to the TK1. A promised supercomputer from NVIDIA that was reasonably priced and ran a full OS seemed like an ideal fit for my project (many components on the board of the TK1 were sold separately for the Pis) so I felt I was getting a deal. My personal, biggest miscalculation was where ARM fit into this equation. I knew RPi wasn’t going to run code from an x86/x64, and I did not think this board would either, but I had a misconception that Ubuntu was just a flavor of Linux and Linux can just run Linux things if ported to each other. Well, the amount of time and effort required to port code, which was not optimized for the system, did not go very well, as mentioned in my prior post with the emulation tests. I think at the time I realized that I wasn’t supposed to use the board as a system, but since then, have failed to find a purpose for it. Every time I think I do, however, I come to the conclusion that saving up for an FPGA would be the better investment.

At one point I had both Linux and Windows versions of Steam running on it. Games unplayable, because as you mention with JetPack it’s only a front end. I even managed to get the Windows version of TeamViewer working on it, but as we all know without the proper 3D viewing, VNC into the TK1 doesn’t serve too much of a purpose other than “you can”. As for the current state, however, freshly flashed and currently connected via SSH MobaXterm, it patiently awaits to do something once again.

I actually have another development board I purchased recently, but it’s for a much, much older processor (i960). The board comes complete with manuals, software EEPROMs, and source code in C and schematics on 5 1/4 diskettes. The idea of using the TK1 as a type of middle man to send/receive data to this old board using the knowledge gained from the manuals and the porting of the C code seems doable. However, each time I break this board out I end up becoming too frustrated to complete a task to finish. While I assume any of my projects theoretically could have seen completion given enough time and resources, I wonder if this current idea is more or less feasible than my previous projects.

Sidenote: I think a valuable lesson here though is to actually own a native Linux machine for this kind (ARM in general?) of development. Really I’ve owned this thing long enough there really shouldn’t be an excuse. =P

14

Just FYI, looks like MobaXterm is pretty nice to have on Windows.

A lot of people do assume the Jetsons are just RPi devices with GPU, but originally the JTK1 was really intended for professional developers to evaluate the the Tegra K1 so they could build their own board. NVIDIA got a market they didn’t expect when it turned out the board was directly useful for all kinds of things other than a large company evaluating for whether to purchase volumes of the chip and build their own board. RPi was designed to be compatible with a large array of low cost peripherals for learning, Jetson was designed for specialized CUDA and GPU applications…things GPU-centric.

I think the success of the JTK1 for use in final products (and not just as an evaluation platform) may have influenced the next generations coming out as modules on a carrier board instead of just integrated into a single board. Even so there is still an emphassis on some specialized end user markets (such as autonomous vehicles, drones, some multimedia processing, or fringe GPU processing in general), and not as a desktop replacement (though it can do desktop replacement if you are ok with some of the limitations you noted…it’s more of a light weight tablet device with advanced graphics which in turn is not a desktop replacement). The Shield TV is a unit which was designed as an end consumer product, the Jetsons are for developers…but a different set of developers versus RPi. You need those specialized GPU applications using low power consumption as a purpose before the Jetson really shines.

Despite having an extremely fast GPU versus anything else embedded, the ARM cores are still not a desktop replacement, so you do have issues with games which use a lot of CPU. Still, if you are streaming graphics or doing purely graphics processing, then the JTK1 can do things an RPi can’t touch. A desktop system requiring more watts per operation can do things a JTK1 never will do (at least not in a practical way).

I’m actually a fan of the i960, I have an old i860 sitting here somewhere. The i860 has the floating point, the i960 is purely integer. The i960 was a huge success in printer engines. For its day the power was astonishing. (I’m kind of a history fan of printers, I spent many years writing PostScript drivers and controllers for very large/fast printers).

The thing with making your JTK1 useful is that you have to concentrate on GPU tasks. I have some other purposes for this, but they all combine with GPU. An FPGA would be expensive, and I’d still need something like a Jetson even if I went that route. If you want to combine some ordinary things with things requiring GPU, then you’ll have a good use for the Jetson. As soon as you get into games and other software which require more CPU you’re out of luck (if the CPU can’t feed the GPU then the balance is not so good).

15

While I do want to discuss the i960 stuff, the recent JetPack 3.1 update seems very relevant to the currently changed title topic: The TK1’s end of life support.

While a change from 3.0 to 3.1 isn’t a huge leap, I still feel as though the TK1 has little useful lifespan left when new/enhanced features come to a newer product and nothing to the predecessor. I suppose this sort of thing isn’t all that uncommon in this kind of “tabletish” industy described in your last post. After all, we have a Nintendo Switch now I think in part thanks to the TK1’s success, but like upgrading from the previous generation of console to the next, the TX line is the direction NVIDIA is taking as it’s thriving much better than the aptly described “budget” variant. Will the budget line continue with information learned from the last 3 years into a TK2? That would be incredibly promising imho.

16

The issue with a follow-up of a TK1 is that it is 32-bit. It’s like in this modern age asking for someone to market a new 32-bit desktop system…the top was i686, and still is…would you buy an i786 32-bit for your PC? A low end 64-bit system would be faster and cost the same. Someone in the embedded world would have a use for this, but marketing would be problematic due to so few users. 64-bit will probably improve over time in other economic ways since the tools and skills are building there (both producers and consumers of the 64-bit variants are improving their skills and resources).

17

It’s true. Then again, the market of GPU power in AI/Auto-Car is also being called into question. With Intel now stepping down from it’s short stint with Arduino and Gigabyte with it’s own version of a single board computer which may or may not turn out to be more to my liking than the TK1, it just makes me wonder how the market will evolve from here.