VirtualBox with RT

[AhBi82]

I wanted to test my application which consist of a host PC and a LV-RT.

In max, there's a tool: "Creating Desktop PC Utility USB Drive".

I downloaded the files from NI website

and created an *.iso from the "image" folder.

However i wasn't able to boot that iso from VirtualBox.

Sorry that its off topic, just to check if anyone has the same experience.

I'm running LV2011, VB 4.1.4

Or, anyone has solution for this??

Many thanks!

[JamesMc86]

Hi,

I am not too sure about this but I think you will have a hard time getting this to work. LabVIEW RT has some quite specific hardware requirements on CPU, Network chipset etc . There is a list available on NI.com but I think virtual is likely to not be possible.

Cheers,

James

[pete_dunham]

Not exactly sure if I am understanding exactly what you are trying to do.

But, on an unrelated project with LabVIEW and Virtualbox, the only way I could get it to work was to have my Guest and Host operating system have the same version of MAX and DAQmx installed.

Seemingly this was needed for the host OS to pass information needed to the VB guest.

[BrentonLang]

I agree with JamesMc86. If I understand your question correctly, I don't believe it is possible due to the fact that LV-RT has a target of a cRIO, which contains a completely different processor than an Intel or AMD. The main problem will be allowing the cRIO real-time operating system to run on a different CPU.

I'm pretty sure that .iso image generator is purely for LV-RT devices.

[MCornwall]

I'm currently trying to do something similar.

I am using LV2011

I am attempting to put the LV RT OS on a Virtual Machine through VMWare.

I was able to burn the image to a USB thumb-drive but the VM couldn't see the thumb drive.

I'm trying to get an ISO output of that utility and point the VM at the ISO for boot purposes.

Thanks!

[OriginalP]

I'm currently trying to do something similar.

I am using LV2011

I am attempting to put the LV RT OS on a Virtual Machine through VMWare.

I was able to burn the image to a USB thumb-drive but the VM couldn't see the thumb drive.

I'm trying to get an ISO output of that utility and point the VM at the ISO for boot purposes.

Thanks!

Did you do that?

[austinman]

Without wishing to stray too far off topic, you should take a look at a utility called Plop Boot. It contains an ISO file that can be used to boot a virtual machine, that can then be used to boot from a USB stick. It works on VM Workstation, which does not support booting from a USB drive.

I don't think it will help you get an RT application running, but I find it useful for other occasions.

[AhBi82]

I'm currently trying to do something similar.

I am using LV2011

I am attempting to put the LV RT OS on a Virtual Machine through VMWare.

I was able to burn the image to a USB thumb-drive but the VM couldn't see the thumb drive.

I'm trying to get an ISO output of that utility and point the VM at the ISO for boot purposes.

Thanks!

Hi Mate,

Any progress? I was able to boot from the utility of Labview RT check via Virtualbox, but the LV RT couldn't support the virtual HW like ethernet card. Not sure if we can modify the virtual HW to suit LV RT specs, since inherent based hardware is supported.

However, the learning curve for this virtualization support is far too steep.

Cheers!

[Daniele Di Roberto]

It's actualli possible to install LabVIEW-RT on a VirtualBox machine as indicated here: http://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Provide-a-Virtual-Machine-VM-in-which-to-run-LV-RT-systems-on/idc-p/3234234#M486

 

Cheers

D.

[hooovahh]

Wow very neat stuff.  So I tried various things to get this to work in VMWare, which is my virtual machine of choice, but didn't have any luck.  The two sticky points for me was the network adapter options, and the booting the USB drive.  

 

VMWare supports EFI booting so I thought that might work for the USB, but it didn't.  I also tried converting the USB drive into a ISO with ImgBurn, and other tools but that didn't work either.  But even if you had RT LabVIEW booting, if you don't have a compatible network adapter, it won't run anyway.  And in the free version of VMWare I don't think there is a way to change the network adapter type that the guest OS sees.

 

But yes your instructions on using VirtualBox worked great.  I was able to make the VM with a SATA, and IDE, have the IDE be my USB drive, and have the network device be an Intel Pro/1000 which is supported.  After this I was able to install the OS, and connect with MAX and install other various software, very cool stuff.

 

I haven't played around with it much, but the prospect of being able to develop some code without the actual hardware is fantastic.  Things like web services, console output, and the whole RT deployment process can be done in simulation.

 

As for performing actual work I'm not so sure yet what it will be capable of.  I know that in some enterprise VM software you can dedicate cores of a CPU in the host to a guest, which would make real-time applications a bit closer to the real thing.  But not being an expert I can't say for sure, but having a deterministic OS, as a VM inside a non-deterministic OS makes me think that the guest OS wouldn't be 100% deterministic anymore.

 

Then there is also the licensing side of things.  I suspect NI would consider a VM installation of their RT software just as real as any other install, and would require a deployment license of RT.

[PJS]

I have gotten a VM working in virtualbox using the PC utility from MAX.  My issue is that I really want to be running NI-Linux Real-Time (Intel x64-based) and not pharlap.  If I read this right,  That is for a real time cdaq chassis.  I am developing software remotely from the hardware and would like to do some things and test within the linux environment connected to my pc.

[Rolf Kalbermatter]

I believe that it should be possible to do, but likely will require to crosscompile the entire NI Linux RT kernel sources in order to configure them for a standard PC rather than the NI specific hardware. Other than that it should be less critical about needing specific hardware (virtualization) than the Pharlap system, since the Linux kernel was and still largely is originally developed on and for the PC.

 

It's been more than 15 years that I compiled my own Linux kernels from scratch and installed them onto a second boot partition so it will be taking some time for sure to figure out all the details. If I ever happen to get some spare time, I'm probably going to try that, but don't hold your breath for it. 

[hooovahh]

Yes I too would reeeeeeeelly want this.  If there were an RT Linux version of a PXI chassis, I feel like just making a hard drive image, and putting that into a VM might be a good start.  But since there isn't, the other methods of getting this to work are outside of my skill set.  

 

I also thought about using some of NI's deployment tools, and if I could get my hands on hardware running RT Linux I could perform a back up, then restore it to a VM, but even with some trickery it won't let an image from a different hardware set be restored.  I have a PXI chassis running RT and I made and image, but wasn't able to restore that image to my VM RT.

 

For now I feel like I have to be content with the non-Linux RT in a VM, or hope for some new hardware that is running RT Linux, that I might be able to pull the OS from the hard drive.  If you do come up with any other possible solution be sure and post back your results.

[JimPanse]

Hi Experts,

 has someone brought the NI Linux RT kernel with a desktop PC to work? Similar to the PharLab operating system. Or is there a how to create the NI Linux RT operating system itself? Otherwise, I would be very interested in a working group that developed the NI Linux RT operating System  for Desktop PC´s.

a pleasant start to the week

Jim

[hooovahh]

Other than the discussion mentioned, where you can load the LabVIEW OS (Pharlap?) in VirtualBox, there has been no new progress.  This would be a very cool thing to have, but my I wouldn't know where to start.  If you make any progress on this be sure and update this thread, or the one linked to the following thread.

[hooovahh]

So there was some discussion of the Linux RT running in a VM and I figured I would try a few things.  I have a cDAQ 9134 which is an atom based target running the Linux RT OS.  I thought I might be able to perform an image of the hard drive, then boot that image in a VM but I wasn't successful.  Here is what I tried.

I logged in with SSH and performed this...

dd if=/dev/zero of=0bits bs=20M; rm 0bits

To zero out the drive, this makes compressing the image better since the dd will image the drive bit for bit, and will be unnecessarily big.  Then I ran this command...

dd if=/dev/sda | gzip > /media/sdb1/image.gz

To make the hard drive image and put it on an SD card.  I then copied the image over to my Windows PC, extracted the gz which gave me a single file named "image" (no extension).  I then used this command to turn the hard drive image into a vmdk...

VBoxManage convertdd "C:\<Path>\image" vmdkname.vmdk --format VMDK

But this drive wouldn't boot in Virtual Box using the IDE or SATA controller.  I also tried extracting the "image" file which extracted a single file named "0.img".  Turning that into a vmdk using the same command from earlier created an image that also wouldn't boot.  In both cases Virtual Box complained about not having a bootable device.  Any suggestions are appreciated, but as I said in an earlier thread I don't know about if I would be able to share a virtual machine if I do get it working.

[ShaunR]

Good idea to move. Thanks. Maybe move the other responses here too? I really don't want to pollute the other thread.

The problem is that if you do manage to get an image from a device, it probably won't be compatible with a VM. It may be ok to put on another identical platform, though. When you compile Linux stuff, there is a whole tool-chain dedicated to figuring out what system you are compiling on and then setting a shedload of compiler switches and includes (which never work out-of-the-box, in my experience). Cross compiling is even worse. Linux is the worst platform to maintain..

Of course. NI could supply us with one then licencing, obnoxious build tools et. al. wouldn't be a problem and we can get on with the proper programming instead of sorting out 1980s build systems..

As far as licencing is concerned. Linux doesn't make it easy. The onus is on us to identify all the different licences and then comply. Since distros are an amalgam of software written by a multitude of crazy militants; each have different ideas about who can and can't use their software; it is a minefield. The Linux kernel on it's own is a known quantity (GPL) and if they have produced a custom kernel, that is sticky. But who knows what what NI libraries and support binaries from 3rd parties have been added (well. NI do).

Edited November 29, 2016 by ShaunR

[Rolf Kalbermatter]

3 hours ago, ShaunR said:

As far as licencing is concerned. Linux doesn't make it easy. The onus is on us to identify all the different licences and then comply. Since distros are an amalgam of software written by a multitude of crazy militants; each have different ideas about who can and can't use their software; it is a minefield. The Linux kernel on it's own is a known quantity (GPL) and if they have produced a custom kernel, that is sticky. But who knows what what NI libraries and support binaries from 3rd parties have been added (well. NI do).

The problem isn't even Linux. Even if you get NI Linux RT compiled and running you aren't even halfway. That is the OS kernel but it does not include LabVIEW Runtime, NI-VISA, NI-DAQmx, NI-this and NI-that. Basically a nice target with promises of additional real-time capabilities to run all your favorite Open Source tools like Python etc. on.

Yes you have all the other libraries like libcurl, libssl, libz, libthisandthat, with each having their own license again, but they are completely irrelevant when you want to look at this as a LabVIEW realtime target. Without the LabVEW runtime library, and at least a dozen other NI libraries, such a target remains simply another embedded Linux system, even if you manage to install onto it every possibly open source library that exists on this planet. 

Technically it may be possible to then take all that additional stuff from an existing x86 NI Linux target and copy it over to your new NI Linux bare target. But there are likely pitfalls with some of these components requiring specific hardware drivers in the system to work properly. And in terms of licensing, when you go beyond the GPL covered Linux kernel that NI Linux in itself is, and other open source libraries, you are definitely outside any legal borders without a specific written agreement with the NI legal department.

Edited November 29, 2016 by rolfk

[ShaunR]

2 hours ago, rolfk said:

The problem isn't even Linux. Even if you get NI Linux RT compiled and running you aren't even halfway. That is the OS kernel but it does not include LabVIEW Runtime, NI-VISA, NI-DAQmx, NI-this and NI-that. Basically a nice target with promises of additional real-time capabilities to run all your favorite Open Source tools like Python etc. on.

Yes you have all the other libraries like libcurl, libssl, libz, libthisandthat, with each having their own license again, but they are completely irrelevant when you want to look at this as a LabVIEW realtime target. Without the LabVEW runtime library, and at least a dozen other NI libraries, such a target remains simply another embedded Linux system, even if you manage to install onto it every possibly open source library that exists on this planet. 

Technically it may be possible to then take all that additional stuff from an existing x86 NI Linux target and copy it over to your new NI Linux bare target. But there are likely pitfalls with some of these components requiring specific hardware drivers in the system to work properly. And in terms of licensing, when you go beyond the GPL covered Linux kernel that NI Linux in itself is, and other open source libraries, you are definitely outside any legal borders without a specific written agreement with the NI legal department.

Ahh. But I am all the way  

I need enough to merely debug SQLite, OpenSSH and OpenSSL on some semblance of the NI-RT target. I care not for DAQ, VISA, Vision or anything else.

Since this is for internal debug. I don't really have any open source obligations either, unless I distribute the VM. The aforesaid binaries I use have already been researched and I comply with the licences for the end products. The new plethora of licences of the RT-Target will cause me to research each individually for compliance. The risk of overlooking a clause that predatory licence practices rub their hands with glee at, means I would probably not if it is more than some arbitrary number of hours or days. That effort would also have to be replicated every time there is a new release and I would probably end up spending time writing tools and systems to catch changes.The Linux community seem happy with this arrangement (even though Linus Torvalds isn't). I would therefore rather just not use it and have not used it prior to windows 10 for these exact same reasons to the extent that I withdrew Linux support even though most products work with it. Thus  I will be prevented from sharing the fruits of that [VM] labour before it has even begun.  That is the tragedy of the commons of open source.

Of course. I could just install the old-ass version of Yocto and decimate  my version 2.2 which took 3 days of pursuing rabbits down very deep holes to set up and get working . That wouldn't help me preventing others from the same pain of getting hold of a VM, though.

Edited November 29, 2016 by ShaunR

[hooovahh]

Yeah clearly the major benefit of this is not deploying and testing DAQmx code.  It is more writing and debugging code that has a UI on this platform (testing and seeing the limitations), any 3rd party tool kits, or packages (related to LabVIEW or Linux), and anything network related (network streams, TCP, web servers, etc).  

I'm might not be fully informed, but assuming I was able to make a hard drive image, and boot that in a VM, I was hoping that MAX would just see that PC as a remote target, and allow me to install software to it just like any other target.  Sure it is a different processor, but it is in the same family (Intel x64) and I'd hope that all the libraries made for the x64 platform would install through opkg using the NI package repository or any other found on the internet.  Which includes all the tool chains NI already has compiled.  NI already has some package groups made for the common development tools, which I've used on the actual hardware successfully.

[Rolf Kalbermatter]

23 minutes ago, hooovahh said:

Yeah clearly the major benefit of this is not deploying and testing DAQmx code.  It is more writing and debugging code that has a UI on this platform (testing and seeing the limitations), any 3rd party tool kits, or packages (related to LabVIEW or Linux), and anything network related (network streams, TCP, web servers, etc).  

The first problem here is that a cRIO application on most platforms has by definition no UI . Even on the few cRIO that support a display output, it is far from a fully featured GUI.

Quote

I'm might not be fully informed, but assuming I was able to make a hard drive image, and boot that in a VM, I was hoping that MAX would just see that PC as a remote target, and allow me to install software to it just like any other target.  Sure it is a different processor, but it is in the same family (Intel x64) and I'd hope that all the libraries made for the x64 platform would install through opkg using the NI package repository or any other found on the internet.  Which includes all the tool chains NI already has compiled.  NI already has some package groups made for the common development tools, which I've used on the actual hardware successfully.

What you describe is true for most libraries (.so files) but definitely not the Linux kernel image. Chances that the zimage or whatever file the NI Linux kernel uses on a cRIO will run on a VM are pretty small. The kernel uses many conditional compile statements that include and exclude specific hardware components. The according conditional compile defines are made in a specific configuration file, that needs to be setup according to the target hardware the compiled image is supposed to run on. This configuration file is then read by the make script that you use when compiling the kernel and will cause the make script to invoke the gcc compiler with a shed-load of compiler defines in the command line for every c module file that needs to be compiled.

It's not just things like the CPU architecture that are hardcompiled into the kernel but also things about additional peripheral devices including memory management unit, floating point support and umptien other things. While Linux also supports a dynamic module loader for kernel module drivers and can use them extensively for things like USB, network, SATA and similar things, there needs to be a minimum basic set of drivers that is available very early on during the boot process, in order to provide the necessary infrastructure for the Linux kernel to lift itself out of the swamp on its own hairs. This hardware drivers need to be statically linked into the kernel. But a Linux kernel compiler can decide to also compile additional modules statically into the kernel, supposedly for faster performance but it just as well works for tying a kernel more tightly to a specific hardware platform.

So most likely even if you can retrieve the bootable image of a cDAQ or cRIO device, and install it in a VM, the loading of the actual Linux kernel will very likely fail during the initial boot procedure of the kernel itself. If you get a kernel panic on the terminal output you know at least that it did attempt to load the kernel but it just as well could already fail before the kernel even got any chance to initialize the terminal, if the bootloader even found the kernel image at all. I seem to remember that NI uses busybox as initial bootloader, so that would be the first thing one would need to get into, in order to try to debug the actual loading of the real kernel image.

[hooovahh]

2 minutes ago, rolfk said:

Even on the few cRIO that support a display output, it is far from a fully featured GUI.

All the more reason I'd like to have the ability to develop and test for it without needing the hardware.  Thanks for all the other information you gave.

[ShaunR]

57 minutes ago, hooovahh said:

All the more reason I'd like to have the ability to develop and test for it without needing the hardware.  Thanks for all the other information you gave.

If you use Yocto then one of the formats for output is a VM image aside from the more usual *.img and *.iso. The NI repository has a Yocto recipe for building NI-RT. After 3 days of fighting with Python and compiler toolchains, I popped my cherry with a Raspberry PI and custom Image (which are included in Yocto and all worked fine). Onwards and upwards to NI-RT.

I got to the stage of finding out that everything turned to crud because Yocto isn't backwards compatible (I had 2.2 and NI use 1.8)  so rage-quit at that point and posted on here after seeing Daklus comment  If you want to really be depressed. Follow the link in the readme.md of meta-nilrt for "Building the Layer" where all your questions will be answered.

Edited November 29, 2016 by ShaunR

[CraigC]

I have wanted to try this for sometime, hence I have one of these ZYBO

I know Zedboard do other alternatives from avnet.  Being as it is the same target family it seems to be a path of least resistence.  It was just supposed to be a means of getting my head around building linux sources and cross compiling.  I am familiar with linux desktops and a few commands but not much else.  I am however quite well versed in Verilog HDL.

[CraigC]

I also note that Digilent is a National Instruments company...  Interesting!