Targetting Raspberry PI

[metux]

---

@BradM

If you wanted to build the kernel and OS userspace components using the NI-provided GitHub repos, you can certainly build the components using a toolchain/configuration to ensure that the resulting code is executable on a ARMv6 processor. 

Actually, the "NI Linux RT" is just a plain embedded Linux, w/ some extra patches. Most of the RT stuff already is in mainline for quite some time (not sure about the ipipe stuff, but the extra branches are ontop of quite recent mainline, so it's not a big deal to rebase and merge them to mainline).

The really specific stuff in here is some board setup (devicetree, etc), which doesn't apply to your own board, anyways. (standard SoMs are usually supported by mainline anyways).

But now comes the funny part: on cRIO, there aren't any Linux drivers for backplane and cards - that's all done in some labview vodoo (userland code as well as fpga). You don't need that here, but you need to make sure, the lv vodoo doesn't try to access some devices that aren't there - essentially that part needs to be shut off.

Perhaps the best place to start is trying to run the userland part in qemu and check whether you can do something useful w/ it. (or whether it somehow runs at all).

The main problem here is that everything's a fat monolith, made for some very specific environments - not modular at all.

Actually, I belive that NI is quite happy w/ that, as they wanna force their existing LV userbase to buy there really expensive controllers. There're not at all opensource friendly.

[metux]

---

@BradM

Just to dispell all sources of ambiguity, when you ask for the effort to port NI RT Linux, I take that to mean the kernel and distribution of non-NI software (read: open-source software) to the target. This effort would be non-trivial and would likely include stripping some of the changes from the kernel that are specific to our board/SoC and instead pulling in changes that are specific to your SoC. 

Actually, that part would be rather trivial, as it already has been done by the community for aeons. The main difference between "NI RT Linux" kernel and mainline is just the cRIO specific hw adaptions (which aren't needed in that case). Maybe plus some extra RT patches, that haven't gone to mainline yet. (but these can be pulled from the tglx'es repo).

The problem would be NI's proprietary stuff, which we just can't fix due to lack of the source code.

Yes: that's the primary problem of proprietary software - we can't fix it. (and yes: in last 25 years I've rarely seen any proprietary software that hasn't been really broken)

If, instead, as I suspect you're actually asking, what the effort would be to get NI software running on another non-NI target, this is something that we can't support and would likely be violating some of the terms of use in the LabVIEW RT/RIO driver EULA.

You (NI) could easily fix that - it's just a matter of your license terms.

But obviously, NI isn't interested in anything but their proprietary, heavily closed ecosystem, and just abusing FOSS as a cheap code base.

BTW: this unfriendly and uncooperative behaviour towards FOSS is the reason why we'll continue w/ full disclosure of security vulnerabilities. Let's see what the stock rate impact will be next time ...

[Bas.v.E]

I just wanted to open up this discussion because I've seen that there is source code on the NI Linux RT available through the NI github at https://github.com/ni/nilrt, and was wondering if it's possible to build it for the raspberry pi 3 or 4? I'm a total noob when it comes to building linux for specific targets, just wondering with the source on github is it possible? for non-commercial purposes ofcourse.

I've seen and played with the LINX library but I rather have a device that is recognized by labview without the LINX library.