Support Elroy Carrier for NVIDIA TX2 about meta-tegra

[ElioDream]

Hey :-)
Been working with @BarbareBzhdev to integrate ConnectTech BSP's with linux-tegra. It requires some more testing (and my carrier, ofc), but basically we did this :

• fork linux-tegra
• put every directory except kernel-4.4 from the BSP in linux-tegra/nvidia
• rsync -ca the kernel-4.4 to linux-tegra, in order to copy and replace only the files that were different
• Change all the files containing "../" and similar patterns, pointing outside of linux-tegra, to make them point to /nvidia/. Basically, it's what you did here

I think that I could have been in less trouble if I had copied only the nvidia files, because the rest seems to have been doing again what you did, @madisongh ... But nevermind, I learned some things today !
I'll tell you as soon as I can try my new Carrier :-D

EDIT : oh, and I created a machine conf file requiring jetson-tx1.conf and overriding the DTB address, to put the one corresponding to my carrier

[ElioDream]

Hi,
I'm also quite interested in this. I just extracted the BSP given by ConnectTech, and there are DTB files in addition to other files (Image, kernel headers...). Is it enough to just change the DTB ? Otherwise, what would be the way to go ?

[madisongh]

Does Connect Tech supply the DTS source files in their BSP? If so, and assuming they're open source, we could import them into the linux-tegra fork here and add a machine configuration to meta-tegra (e.g., elroy-tx2.conf) that uses that device tree.

If other kernel or U-Boot changes are required to support that carrier, we'd also need to import those into the repos here, too.

[ElioDream]

Hi,
Here is the link to their BSP. I quickly looked into it, but it seems like there are only .dtb files. In addition, there are kernel_headers and supplements, an Image, and conf files. I'm only a beginner in embedded linux distributions, so I do not know exactly what all these files are for. By comparing the conf file for the jetson-tx1 and for elroy, I noticed that the only difference is the dtb file, that's why I was supposing that exchanging them was enough...

BTW, thx for the amazing work ;-)

[madisongh]

Yeah, that BSP only has pre-built binaries, not too useful here. They do provide a kernel image as well as the compiled device tree (dtb) files, so I expect they've added patches to the kernel as well. It's all set up to work only within NVIDIA's JetPack/L4T setup, though. Unless they provide the source code, there isn't much anyone can do to get those carriers working for OE builds.

[ElioDream]

If i really have to use that carrier, i guess i'll ask them...
I think I've seen in the Orbitty carrier manual, that almost everything on it should run with the default L4T build. Using meta-tegra could work in this case, couldn't it ?
Otherwise, do you know of carrier boards that can work with OE builds ?

[madisongh]

If that carrier doesn't require any kernel patches or device tree changes from the stock configuration provided by NVIDIA, then yes, it should work OK.

I don't really know about other carriers; I think NVIDIA has an 'ecosystem' page on their web site that lists various partners. I expect they all base off of NVIDIA's L4T/JetPack releases, though, and no matter what, it will take some effort to get any modifications to support them integrated into OE-based builds.

[BARBARIN-Michael]

Hi guys, to get connecttech sources go here :
http://connecttech.com/ftp/dropbox/cti-l4t-src-v113.tgz

I'm also interesting to merge their dtb into your repo linux-tegra :)
Edit: they are few patches into archi

[ElioDream]

Nice !
How did you know where to look for them ?
I sent an email to their support this morning to get them, but you were quicker ^^

[ElioDream]

I just want to point out that they provide different files for TX1 and TX2 !
Their v113 is for TX2 L4T r28.2
Their v112 is for TX2 L4T r28.1
Their v018 is for TX1 L4T r28.1

Funny thing, I'm using TX1 L4T r28.2...

[BARBARIN-Michael]

I work into Spacely board since 3 week and I'm quick struggling :)
At this time, i merged their patches into linux-tegra repo of matthew to integrate our OS into Spacely with Yocto. But I cannot use CSI camera into it with their dtb...

[ElioDream]

I'm discussing with Connect Tech's support team, apparently they are gonna release a BSP for L4T r28.2 on TX1 within the next few weeks.
@madisongh do you intend on merging the sources that they provide with your repository ? Otherwise, could you tell us the nice way to do it locally ?

[madisongh]

I'd be happy to take a pull request. :) Seriously, I'd rather not blindly apply changes without some testing, so it would help if someone who can test them could take this on.

[ElioDream]

And I'd be happy to do one :-)
I have ordered a new TX1 and an Orbitty carrier, they should arrive next week.
But, as I said earlier, I'm only a beginner and I would like to check exactly what's needed.
My guess for the moment is to fork linux-tegra, patch it, and make the linux-tegra_4.4 recipe point to my fork ?
One of my questions would be : how do you make it so that the patches depend on the machine configuration (cf "... add a machine configuration to meta-tegra (e.g., elroy-tx2.conf) that uses that device tree.").
Is it possible to write some patch files (like in bitbake recipes) that would then be applied only if that specific configuration is chosen ?

[madisongh]

For testing, yes, you would fork linux-tegra and point the recipe at your copy.

Hopefully, the patches are such that new .dts/.dtsi files for the carrier(s) are in the kernel source tree, with an entry in the appropriate Makefile to build the corresponding .dtb(s). In the machine configuration file, you could then set the KERNEL_DEVICETREE variable to point to the correct one for the particular TX2+carrier combination.

But if Connect Tech just modified the existing device tree files used for the Jetson-TX2, it will get more complicated -- comparing the changes against the original NVIDIA kernel sources (use the source_sync.sh script in L4T to get their sources) to start, then adding new .dts/.dtsi files would be best, so we can build any/all of the dtb files from the same source, without having to introduce additional machine-specific patches.

[ElioDream]

It seems that all the dts/dtsi files are here. Didn't try building anything yet, just snooping around.
What about the changes to the kernel files ? Integrate them using a patch recipe ?

[madisongh]

If there are other kernel changes besides the device tree files, we could apply them in the git repository also. Again, though, it depends on how general the patches are - if they don't break anything for other platforms, that would be OK, but if they only work for the specific carrier(s), it would take some analysis to figure out the right approach.

[lfdmn]

Hi!

Interesting stuff :-) I need to do the same for TX2 and Astro carrier.

I still need to figure out the base R&D image on jetson boards, then I can help. Until I get there let me know if I can be of any help with testing.

[lfdmn]

Hi!

I have gone back to this. My setup is astro rev G + TX2.

I have gone through the same steps as @ElioDream.

The board boots. HDMI display, USB2 and 3, both NIC, mSATA, fan work fine. CUDA drivers too.

What doesn't work for me is the mPCIe slot. I have an acquisition card connected to it. I can see from dmesg that the kernel tries to detect the card on slot 2 3 times and then ignores it.

Has anyone seen similar issue?

[splendido]

Hi all,
I'm working with a Jetson TX2 + Orbitty Carrier.
Could anyone advise on the status of things?

I see @ElioDream have a branch about Orbitty stuff: is this in working conditions? Would it work with TX2?
@lfdmn what about your work?

[ElioDream]

Hey :-) My branch works for Orbitty with l4t r28.1 and the jetson TX1. The guidelines that I gave should give you a working kernel, just be aware that you'll spend some time debugging ^^ Do you have ConnectTech's BSP for the L4T, board and carrier that you want ? Le lun. 16 juil. 2018 à 16:23, Luca Mussi <[email protected]> a écrit :

…

Hi all, I'm working with a Jetson TX2 + Orbitty Carrier. Could anyone advise on the status of things? I see @ElioDream <https://github.com/ElioDream> have a branch about Orbitty stuff: is this in working conditions? Would it work with TX2? @lfdmn <https://github.com/lfdmn> what about your work? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARAG4aUp1fsWQRBf0lGDy7R1zcYFOTmjks5uHKHlgaJpZM4TDXGe> .

[splendido]

Thanks @ElioDream!

I've just downloaded CT's BSP and sources for the latest versions from the following links:

• http://connecttech.com/ftp/dropbox/cti-l4t-src-v119.tgz
• http://www.connecttech.com/ftp/Drivers/CTI-L4T-V119.tgz

I'll have a look and try go through your gidelines, then let you know!

[ElioDream]

Hey @splendido, how is it going ?

[splendido]

@ElioDream, I'll be back on the project from tomorrow and let you know asap!

[lfdmn]

@splendido and others, I got everything working for TX2 + Astro carrier. I had wrong ODMDATA key value set in machine config file (astro-tx2.conf). This prevented the the PCIe detection from working on the mPCIe port.

If you want to use what I've done, I've created this layer https://github.com/lfdmn/meta-cti which depends on madisongh/meta-tegra.

I also forked madisongh/linux-tegra to add a branch with ConnectTech BSP patches https://github.com/lfdmn/linux-tegra/tree/patches-l4t-r28.2-cti.

If you need a different L4T version than 28.2, I've made a script to ease the merging job due to different folder structures. You'll still have to verify everything manually but I hope it'll be a good starting point when I need to update some days.

[splendido]

many thanks @lfdmn! This was a great news!
...I'm now in the process of building a core-image-minimal for the CTI Orbitty Carrier + Jetson TX2 combo.
Will update everyone on the outcomes!

[splendido]

@lfdmn it looks like applying CTI's patches directly onto branch patches-l4t-r28.2 overrides a number of patches by @madisongh, some of which are necessary to build with recent version of GCC.

See for example this diff wich actually reverts this commit.

I'm currently trying to create a branch l4t/l4t-r28.2-cti-119 on top of wich apply @madisongh 's patches found in his patches-l4t-r28.2 branch to get a another new patches-l4t-r28.2-cti-119 branch.
Does this look reasonable? Or could it be a nightmare?

I'm taking the occasion to also use latest BSP sources from CTI, version 119

[madisongh]

Yes, applying CTI's patches on top of the base L4T branch, then rebasing my patches on top of that, might work out better.

[lfdmn]

Yes. @splendido regarding the GCC version: I needed to set it to 5.4 to be able to build OpenCV and Arrayfire because of CUDA if I recall right. I have not seen any side effects of using older GCC version.

…

On Fri, Aug 3, 2018 at 8:43 PM, Matt Madison ***@***.***> wrote: Yes, applying CTI's patches on top of the base L4T branch, then rebasing my patches on top of that, might work out better. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQY2a5w1hKpGlhkCqOIwqwITDqTcni5jks5uNIvFgaJpZM4TDXGe> .

[splendido]

Guys, it looks like I now have a linux-tegra/l4t-r28.2-cti-192 and a linux-tegra/patches-l4t-r28.2-cti-192 working branches!

...still working on finishing meta-tegra/morty-l4t-r28.2up to date with the master branch (I need morty at work...) plus a few additions to meta-cti by @lfdmn.

I would like to share this work if of any interest but, if you agree, I'd prefer to contribute to your repos rather than creating new forks...
What are your thoughts about this?

[madisongh]

I'd be happy to have everything together in one place. I haven't had a chance to look over the kernel differences in detail yet... how hard do you think it would be to merge them into the patches-l4t-r28.2 branch so we don't have to have different branches for different carriers?

[splendido]

@madisongh, differences (new files apart...) are not that many but I cannot tell about their possible implications...
Perhaps you can have a quick look at them and get an idea?

See patch file (again, about modified files only...): patches-l4t-r28.2-cti-119.patch.txt

[madisongh]

As far as the changes go...

• pci-tegra driver changes look a bit hacky. The don't-power-down behavior should be configured through a device tree entry or something.
• The ASoC machine driver should have been implemented as a separate driver (with 'sgtl5000' in the name), rather than just hacking NVIDIA's sample driver.

The other changes look more or less OK to me.

I'm more concerned about the additions not shown in the patch - the Lumenera camera drivers in particular, since they don't appear to be openly available anywhere (certainly not upstream) and aren't clearly labeled as GPL, at least in the source files I looked at.

Just thinking about how maintainable this will be going forward. If we resolve the issues with the changed files (and possibly omitting the Lumenera drivers), I think we could have a branch that supports both the NVIDIA and CTI carriers... but when the next kernel update comes from NVIDIA, or CTI updates their patches, there will be a bunch of work to pick things apart and put them back together again.

So maybe we should keep the CTI stuff separate for now. If NVIDIA works with their partners to let them upstream changes into the L4T kernel, maybe we'll have an easier time of it later.

[graugans]

I have a question, maybe one of you guys can answer me. I did basically the same and added support to the CTI Rudi system on my side. I flashed the image and it is booting. What I am wondering is the fact I do not see any boot message from the boot loader nor the u-boot. The output starts ~4 Seconds after the kernel started booting. Is this configured by the ODMDATA magic?

[splendido]

@graugans with the orbitty carrier the default behaviour is to have the serial console on the GPIO connector.
This means, after flashing, the OTG port act as a USB port only.
I have tested the serial console from the GPIO connector and it indeed shows all logs from the very beginning.
I guess it is the same for Ruby carrier...

Unfortunately I don't know how to change this, so I'm not of much help

[graugans]

@splendido of-course the USB OTG is only for flashing. I have connected a USB <-> Serial adapter to the GPIO header. What I can see is that there are Messages after a few seconds after the kernel is loaded but I do not see any messages from the bootloader. I'll dig deeper into this.

[lfdmn]

Hi @splendido and others. Sorry for late reply I was away from work for some months.

I'm now back in business and try to build a sumo branch.

Did you publish your patched version of CTI source? Did everything workout for you?

[madisongh]

As there's been no activity on this for quite some time, I'm going to close this.