TK1 needs support improvements

[TechToyTinkerCompany]

I do realize the board is technically EOL, however it’s also supposed to be available until 2024. Needing to use Ubuntu 14 or 16 while at the same time not supporting a VM makes it incredibly difficult to reflash or work with this device. And most forum replies I see simply say it’s old and to use the nano. There are a couple of issues with this.

1. If the board is available for two more years, it should have proper support.
2. This install or set up process should have been updated over the years like the rest of the boards, not left behind on Ubuntu 16.
3. Sdk manager does not support the tk1 which forces users to use a .run file that may or may not work, and flat out errors on a VM, this forces downgrading an actual computer to Ubuntu 16 just to work with the device.
4. Telling customers to just use the nano is kind of insulting to all the tk1 users, if the board meets their needs they have no reason to upgrade to a nano.
5. Intentionally leaving out the K1 while including every model later is unfair to the community behind it.

With all of that being said, I do own Jetson nano devices, I’m the dev that supports the emulation build for it.
However, that doesn’t excuse the fact the TK1 should still have proper support, and as a dev, watching users be told to simply get a newer device feels wrong, the correct solution would be to include the TK1 in sdk manager or make a way for it to work in VM. Expecting people to install Ubuntu 16 is also a bit unfair.

I know it sounds like I’m being a bit blunt on this one, and it’s because I know Nvidia is capable of doing this and properly supporting the device, they made a choice not to as far as I can tell.

If there is a reason that Nvidia was not able to include later Ubuntu or VM support, please let me know.

If there isn’t a reason, Nvidia, please address this issue.
People don’t magically just stop using a device when a manufacturer decides it’s end of life. They stay in circulation and use for many years later for a variety of purposes, and those users deserve to have the proper updated tools to work on the device, especially because it’s still available for two years.

[prlawrence]

Welcome to the forum! Thanks for taking the time to write this, and I’ll try to give you a good reply.

Taking it from the top…

I do realize the board is technically EOL, however it’s also supposed to be available until 2024.

The hardware availability dates listed on our Lifecycle page are for production modules and SoCs, not for developer kits. Check out this FAQ,

Jetson TK1, Jetson TX1, and Jetson TX2 developer kits have all been EOL’d at this point. OEMs have long since finalized designs based on Tegra K1 and Jetson TX1, and more recently for Jetson TX2. We do still sell TK1 SoCs and TX2 modules for OEMs to use in their ongoing products.

Of course OEMs are not our only customers. Hobbyists, students, educators, and others have been Jetson customers from the beginning. (Scroll down through the Jetson Community Projects page!). I’ll address this below.

1. If the board is available for two more years, it should have proper support.

Right. We published software releases for Tegra K1 and the Jetson TK1 Developer Kit for 5 1/2 years, from mid 2014 until end 2019.

[points 2 and 3 and 5 about SDK Manager]

We moved to SDK Manager from a standalone JetPack installer with the introduction of Jetson AGX Xavier at the end of 2018. That first release only supported Jetson AGX Xavier, but we added Jetson TX2 and Jetson TX1 support subsequently (and of course others after that). But this was 4 years after the introduction of Tegra K1, and no more “feature” releases for it were planned. So it didn’t make sense to apply engineering effort to support TK1 via SDK Manager.

4. Telling customers to just use the nano is kind of insulting to all the tk1 users, if the board meets their needs they have no reason to upgrade to a nano.

Some people have no need to upgrade from TK1, and that’s great. OEMs of course, happy to manufacture products already designed around the Tegra K1 SoC, but also embedded hobbyists who already have the developer kit running various systems at home.

On the other hand, if you want to develop new projects it probably does make sense to pick a newer product. Then you can enjoy more “modern” things like containerization and pre-trained AI models on your Jetson, not to mention better performance and different form factors. Anyway, don’t be insulted; these forums aren’t like that. Everyone should pick the product that makes sense for them and expect friendly assistance here.

If there is a reason that Nvidia was not able to include later Ubuntu or VM support, please let me know.

Basically, there is no overstating the amount of work it takes to make new Jetson products. And we’re definitely going to make new products! There’s always a new GPU architecture around the corner, new accelerated SDKs, etc. Yet there are only so many of us, and continuously supporting all products forever is just not an option. So it comes down to judgement calls like the one we made not to spend engineering time adding TK1 support to SDK Manager.

HOWEVER, those judgement calls can also go the other way. Jetson TX1 is EOL (the production module as well as the developer kit), yet we were able to leverage work we had to do for Jetson Nano and keep on supporting it. And not just maintenance releases – Jetson TX1 has been getting the same new compute stack updates as TX2, AGX Xavier, etc., and I know we’ve got at least one more feature release planned before Nano, TX1, and the TX2 series go into maintenance mode.

I hope that helps explain things. Thanks for being a Jetson developer!

[TechToyTinkerCompany]

Yes, that pretty much explains it. Unfortunately I still have to run an ubuntu 16 PC as a few community members have asked us to expand support from the nano to the tk1, but, it is what it is. The nano emulators and retroarch cores also work on the Xavier. And we spent time on the emulator github pages pushing things, the jetson-nano flag is now included on their respective githubs directly. Thanks for the reply.