Wishbone
Clueless developer
Am afraid I'll have to build the chain myself. https://www6.software.ibm.com/developerworks/education/l-cross/l-cross-ltr.pdf
Project Linux MFD (Updated 120616)
- Thread starter Artlav
- Start date
Artlav
Aperiodic traveller
- Joined
- Jan 7, 2008
- Messages
- 5,814
- Reaction score
- 869
- Points
- 203
- Location
- Earth
- Website
- orbides.org
- Preferred Pronouns
- she/her
Sorry, i had the impression that it was a matter of quick googling.
For example, here are ones, for windows and linux:
http://code.google.com/p/uos-embedded/wiki/gcc_mipsel_ru
---------- Post added at 23:28 ---------- Previous post was at 23:26 ----------
To play Orbiter to simulate browsing the net from Mars?
You know you're addicted to Orbiter when...
Suspend means saving state, it keeps running after that.
Wishbone
Clueless developer
Re: cross-compiler - :facepalm:
Re: suspend feature - hmmm, I have definitely heard the fan slow down after I hit Suspend button. This could be called "SAVE", I'd reckon.
Re: browsing Internet from Mars - am not sure HTTP was designed with such delays in mind. Would guess there're still "browse by e-mail" proxies around.
Re: suspend feature - hmmm, I have definitely heard the fan slow down after I hit Suspend button. This could be called "SAVE", I'd reckon.
Re: browsing Internet from Mars - am not sure HTTP was designed with such delays in mind. Would guess there're still "browse by e-mail" proxies around.
Last edited:
I've got some SERIOUS ideas for this MFD... Haven't had time to open Orbiter for weeks, actually working on projects in Linux and Android, but here's a couple of ideas I want to throw in the Open ;P
- Implement an X client, for obvious graphical possibilities
- Implement SSHD, for communication purposes...
- Implement a /dev/sat, /dev/uhf, etc. as simulated radio network devices which would use the distance from closest vessel or surface base to focus vessel for speed of light delay, implemented as a transmission delay for transmission of TCP/IP packets and reception buffer of TCP/IP traffic. As bonus, introduce random bit flips if the sun is within the antenna lobe...
- Implement a /dev/eth0 device which could then either hook-up with the local computer via localhost, communicating with other applications on Windows or Cygwin, or communicate with other computers on the local network, emulating in a way the operation of larger computers (ie. HAL9000 on Discovery) for larger data processing and data crunching., bypassing the limits of resources of the LinuxMFD...
- Combining the aforementioned features which would then act kind of like the MEDS shuttle display. One local network linux computer could, for example, run a simulation of the IBM AP-101S while the LinuxMFD serves as an X client.
- Using a routing table, /dev/sat for internet traffic and /dev/eth0 for local network traffic, including the host Windows computer, it would then be transparent to the user that connecting to remote resources, whatever the application and protocol, would be impacted by the communication delay, whereas local would be as if happening inside the vessel. Are separate vessels running separate instances of the MFD? If so, maybe some neat things could also be implemented...
- Using some linux magic, it could also be possible to implement networked input devices, for example having a pipe of sort between a local Linux computer having USB joysticks plugged in (/dev/js0, /dev/js1, etc) and the LinuxMFD over the network (/dev/net-js0, /dev/net-js1), with some sort of configuration file (say, /etc/remote-js.conf) which would contain an easy text-based configuration file with input button/axis and vessel control API functions (ie. /dev/net-js0.button1 RCS_ROT; /dev/net-js1.axis0 HOVER_THROTTLE ... ), therefore enabling quick and dirty multi-computer control system, for the uber simulated cockpit setup...
I also like the idea of having spacecraft systems accessible thru /dev/ or /proc ... so that in a low level we could send stings such as echo 10100101 > /dev/rcs (binary) or echo d5 > /dev/rcs (hexa) would activate specific thruster groups,resulting for example in pitch up and translate left... It would kick ass to program autopilots, applications and control systems that way!
Can't wait to ssh into Orbiter !
- Implement an X client, for obvious graphical possibilities
- Implement SSHD, for communication purposes...
- Implement a /dev/sat, /dev/uhf, etc. as simulated radio network devices which would use the distance from closest vessel or surface base to focus vessel for speed of light delay, implemented as a transmission delay for transmission of TCP/IP packets and reception buffer of TCP/IP traffic. As bonus, introduce random bit flips if the sun is within the antenna lobe...
- Implement a /dev/eth0 device which could then either hook-up with the local computer via localhost, communicating with other applications on Windows or Cygwin, or communicate with other computers on the local network, emulating in a way the operation of larger computers (ie. HAL9000 on Discovery) for larger data processing and data crunching., bypassing the limits of resources of the LinuxMFD...
- Combining the aforementioned features which would then act kind of like the MEDS shuttle display. One local network linux computer could, for example, run a simulation of the IBM AP-101S while the LinuxMFD serves as an X client.
- Using a routing table, /dev/sat for internet traffic and /dev/eth0 for local network traffic, including the host Windows computer, it would then be transparent to the user that connecting to remote resources, whatever the application and protocol, would be impacted by the communication delay, whereas local would be as if happening inside the vessel. Are separate vessels running separate instances of the MFD? If so, maybe some neat things could also be implemented...
- Using some linux magic, it could also be possible to implement networked input devices, for example having a pipe of sort between a local Linux computer having USB joysticks plugged in (/dev/js0, /dev/js1, etc) and the LinuxMFD over the network (/dev/net-js0, /dev/net-js1), with some sort of configuration file (say, /etc/remote-js.conf) which would contain an easy text-based configuration file with input button/axis and vessel control API functions (ie. /dev/net-js0.button1 RCS_ROT; /dev/net-js1.axis0 HOVER_THROTTLE ... ), therefore enabling quick and dirty multi-computer control system, for the uber simulated cockpit setup...
I also like the idea of having spacecraft systems accessible thru /dev/ or /proc ... so that in a low level we could send stings such as echo 10100101 > /dev/rcs (binary) or echo d5 > /dev/rcs (hexa) would activate specific thruster groups,resulting for example in pitch up and translate left... It would kick ass to program autopilots, applications and control systems that way!
Can't wait to ssh into Orbiter !
Wishbone
Clueless developer
One question that I haven't yet put to experimental test: if there are 3 Linux MFDs open, will they have different VMs or different tty to a single VM or the same tty of the only VM?
Ah, and re: saving - does reopening the scenario reload a saved state?
I'd be wary of directly manipulating the vessels through the MFD in a traditional command-line way (or Lord forbid by sending bytes to obscure ports). We already have Lua console and very few users try that stuff. X Window interface also seems a waste of memory (probably it is my fondness for text speaking)...
Ah, and re: saving - does reopening the scenario reload a saved state?
I'd be wary of directly manipulating the vessels through the MFD in a traditional command-line way (or Lord forbid by sending bytes to obscure ports). We already have Lua console and very few users try that stuff. X Window interface also seems a waste of memory (probably it is my fondness for text speaking)...
Last edited:
Artlav
Aperiodic traveller
- Joined
- Jan 7, 2008
- Messages
- 5,814
- Reaction score
- 869
- Points
- 203
- Location
- Earth
- Website
- orbides.org
- Preferred Pronouns
- she/her
Single VM, same terminal (ttyS0).
No, neither is it saved on closing. Too resource-consuming.
I'm a heavy #/bin/bash head.
I have more ideas for it's use in orbiter than $(cat /dev/0) has characters.
[ "$(ls /obin/ | wc -l)" -gt "4" ] && call me
That said, what I am not is a 'linux OS' or VM expert. Initial checks into how to make this run shell scripts ended in dismay, as I realize there are no RW devices mounted, nor a way to use cifs/jffs2 to map RW to network share. Thus; any 'scripted' events would be 1 liners, painfully typed, not even able to paste. I can bust out a 1 liner like Rick James could bust out a rail, but that would only get me so far, (oddly, just like Rick James). This MFD currently reminds me of The Lawn-mower Man. So much power, caged inside an electrical box.
I need to either...
1) Figure out how to modify/rebuild initrd , using something other than cramfsck and mkcramfs that appears to fail no matter what opts i use. (win32 versions, i know , im lame).
update: http://www.ibm.com/developerworks/linux/library/l-initrd/index.html has good intel for me on initrd
2) Figure out how to mount another filesystem. Either my own local disks over cifs/jffs2/samba, or another cramfs. But it appears that /dev does not hold the proper mounting points for anything past what the image supports already.
3) What would be golden for me, is if the image had an sshd agent... So *I* could then ssh to *it*. Do they do that in mother russia? Or is it the other way around? I don't recall.
4) Re-watch lawn mower man and figure out how he got out.
Summary:
1) If only I could ssh like Richard Simmons...(both ways)
2) If only I could boot any one of the awesome WRT images out there that support 90% of what we're all attempting to do (i.e. OpenWRT)
At any rate, stellar job so far mate. I'm going to buff up on some dev skills and see what I can contribute as well.
- Z
I have more ideas for it's use in orbiter than $(cat /dev/0) has characters.
[ "$(ls /obin/ | wc -l)" -gt "4" ] && call me
That said, what I am not is a 'linux OS' or VM expert. Initial checks into how to make this run shell scripts ended in dismay, as I realize there are no RW devices mounted, nor a way to use cifs/jffs2 to map RW to network share. Thus; any 'scripted' events would be 1 liners, painfully typed, not even able to paste. I can bust out a 1 liner like Rick James could bust out a rail, but that would only get me so far, (oddly, just like Rick James). This MFD currently reminds me of The Lawn-mower Man. So much power, caged inside an electrical box.
I need to either...
1) Figure out how to modify/rebuild initrd , using something other than cramfsck and mkcramfs that appears to fail no matter what opts i use. (win32 versions, i know , im lame).
update: http://www.ibm.com/developerworks/linux/library/l-initrd/index.html has good intel for me on initrd
2) Figure out how to mount another filesystem. Either my own local disks over cifs/jffs2/samba, or another cramfs. But it appears that /dev does not hold the proper mounting points for anything past what the image supports already.
3) What would be golden for me, is if the image had an sshd agent... So *I* could then ssh to *it*. Do they do that in mother russia? Or is it the other way around? I don't recall.
4) Re-watch lawn mower man and figure out how he got out.
Summary:
1) If only I could ssh like Richard Simmons...(both ways)
2) If only I could boot any one of the awesome WRT images out there that support 90% of what we're all attempting to do (i.e. OpenWRT)
At any rate, stellar job so far mate. I'm going to buff up on some dev skills and see what I can contribute as well.
- Z
Turbinator
New member
Using this MFD, can we now create a mission control centre addon where you can upload remote commands to interplanetary probes, with the speed of light and all, then have the probes perform the actual actions and report back. Oh my God, imagine the possibility of this. Recreating the Juno, or New Horizons, or the Phobos-Grunt mission with 100% simulated reality.
The ol' "ORBITERRRRRRR!" enthusiast will tell you that this functionality has already been built in, but in the form of: LuaScript ,via the use of LuaMFD.
i.e. a pic of the Lua script generator.
I personally contest this, stating that *sh is by far superior , *IF* it's ability to interact with Orbiter (get data and send commands) is expanded.
*sh beats Lua, hands down, in the following areas.
- Working with dynamic objects:
*sh could easily work in any scenario thrown at it (or easily fail in a laughable manner), where as Lua would have to be customized for most any scenario.
- Text parsing:
Yeah, you hard core shell and Orbiter heads know what I'm talkin bout.
If Orbiter were to get proper *sh support, it could:
1) Send you an e-mail/text message when your ship finally reaches it's destination and touches down.
2) Accept commands from e-mail or text messages and execute them in game.
3) Order a pizza at the click of a button.
4) Look-up details of damn near anything on the net, based on script awesomeness and user input.
5) Synch your ipod for you, then start playing the song your ipod was last playing.
6) Remember your wifes birthday and automatically send her flowers.
7) Remember your birthday and automatically buy new PC upgrades.
The list goes on and on... You could even control a Rumba Vacuum cleaner, from Orbiter...
Lua can't possibly do all that... Not even close...
~Z
Wishbone
Clueless developer
The necessity of prefixing each line with Shift-I makes the MCC thing less usable. We need a real terminal that would accept clipboard input. As for commands, your wish may come true earlier than expected
Linguofreak
Well-known member
A feature proposal: Check to see if Orbiter is running under Wine, and, if so, ask the user if the MFD should act as a terminal to the host system rather than emulating its own system.
Artlav
Aperiodic traveller
- Joined
- Jan 7, 2008
- Messages
- 5,814
- Reaction score
- 869
- Points
- 203
- Location
- Earth
- Website
- orbides.org
- Preferred Pronouns
- she/her
Let's sum up the features to make this into something usable:
-RW disks, an MTD mapped onto a file on host with up to 256MB in it.
-Better input methods
-Network access
-Separate instances per vessel
Anything else?
Here is an update:
http://orbides.1gb.ru/orbf/linuxmfd-110824-upd.zip (8 Mb)
Install over previous.
Changes are:
MTD rw device (use SYN key to save image content to disk)
OpenWRT image (real bash, vi, some nice stuff like that, to disable select initrd params in boot.txt)
Untested!
For feature considerations only.
Got an OpenWRT image to run off that.
What i presented is not bash under Orbiter, it's much slower than that.
Kind of like running an elaborate rude goldberg machine to drop a bowling ball onto a mouse instead of using a mousetrap.
If so, an external terminal program is conceivable...
Is it really worth the bother?
Rationality not detected.
-RW disks, an MTD mapped onto a file on host with up to 256MB in it.
-Better input methods
-Network access
-Separate instances per vessel
Anything else?
Here is an update:
http://orbides.1gb.ru/orbf/linuxmfd-110824-upd.zip (8 Mb)
Install over previous.
Changes are:
MTD rw device (use SYN key to save image content to disk)
OpenWRT image (real bash, vi, some nice stuff like that, to disable select initrd params in boot.txt)
Untested!
For feature considerations only.
Windows filesystem is inferior to normal ones, so unpacking initrd collapses it.
MTD device with up to 256Mb of RW space on it is easy to add.
Got an OpenWRT image to run off that.
That would need network support. Which is tricky in both making and tapping into.
It could be slow.
What i presented is not bash under Orbiter, it's much slower than that.
Kind of like running an elaborate rude goldberg machine to drop a bowling ball onto a mouse instead of using a mousetrap.
Well, anybody else run Orbiter in a window?
If so, an external terminal program is conceivable...
Is it really worth the bother?
And make an entirely different add-on doing what could be done by alt-tab?
Rationality not detected.
Wishbone
Clueless developer
Re: terminal. Right now I use (in the NTR core stage) the one-line input box to enter commands, or issue a "LOAD COMMANDS filename" string to run a script. I have added (but not tested) programmatic interface via clbkGeneric, and as of now there's no feedback thrown to the user on any channel besides what's written in the HUD.
Command and data handling applications, am afraid, transcend the capabilities of simple terminals, so unsure if you should bother yourself with this. An ideal CD&H interface would allow, at least, tabular view of commands, control station(s) to xmit the command from, expected comms delays, and their ack status; tables and charts and gumdrop health piccies for telemetry and filtered data.
Command and data handling applications, am afraid, transcend the capabilities of simple terminals, so unsure if you should bother yourself with this. An ideal CD&H interface would allow, at least, tabular view of commands, control station(s) to xmit the command from, expected comms delays, and their ack status; tables and charts and gumdrop health piccies for telemetry and filtered data.
Artlav > Chuck Norris
What of libvirt? http://wiki.libvirt.org/page/FAQ
sshd would resolve that one, now wouldn't it?
Would also solve:
- The copy/paste issue
- The disk space issue
- The 'it could be slow' issue, as a lot of processing could be done on external linux nodes, leaving the Oinux (Orbiter Is Not Unix) ginstance free to process incoming command requests.
- The "I'm always late for meetings because im screwing around with Linux VM's at home that can't connect to linux VM's at work" issue. This is a big one in my household :thumbup:
I will take a few days to saturate myself with knowledge of VM's and your implementation of VM-MFD. Once back, I may have some goodies rather than suggestions.
Again, stellar job thus far Sir. I'm learning a lot in the little free time I have away from the ol work-TERM and more importantly, having fun doing it.
~Z
What of libvirt? http://wiki.libvirt.org/page/FAQ
sshd would resolve that one, now wouldn't it?
Would also solve:
- The copy/paste issue
- The disk space issue
- The 'it could be slow' issue, as a lot of processing could be done on external linux nodes, leaving the Oinux (Orbiter Is Not Unix) ginstance free to process incoming command requests.
- The "I'm always late for meetings because im screwing around with Linux VM's at home that can't connect to linux VM's at work" issue. This is a big one in my household :thumbup:
I will take a few days to saturate myself with knowledge of VM's and your implementation of VM-MFD. Once back, I may have some goodies rather than suggestions.
Again, stellar job thus far Sir. I'm learning a lot in the little free time I have away from the ol work-TERM and more importantly, having fun doing it.
~Z
Artlav
Aperiodic traveller
- Joined
- Jan 7, 2008
- Messages
- 5,814
- Reaction score
- 869
- Points
- 203
- Location
- Earth
- Website
- orbides.org
- Preferred Pronouns
- she/her
First, i tend not to use third-party stuff in my hobby projects unless i can't avoid it without significant wasted effort.
Second, i don't see how libvirt can help anyway - you need network interface being implemented in the VM first, so that Linux in it can see something.
Certainly.
Network support is likely to happen, so that would be ideal.
Well, you can always decouple the VM from Orbiter and put it onto a thumb drive:
http://orbides.1gb.ru/orbf/emips-110824.zip (48 Kb)
Put into Orbiter directory (only boot needs for work), run.
Commands - parameter key (between alt gr and ctrl, on the right side of keyboard), command, enter.
i.e. Parameter,s,a,v,e,Enter would save the state.
save, load - save, load (duh)
imgs - save image (SYN)
Artlav
Aperiodic traveller
- Joined
- Jan 7, 2008
- Messages
- 5,814
- Reaction score
- 869
- Points
- 203
- Location
- Earth
- Website
- orbides.org
- Preferred Pronouns
- she/her
So, i was passing by and decided to update this absurdity with the recent improvements.
Here it is:
http://orbides.1gb.ru/orbf/linuxmfd-120616.zip (9Mb)
Kernel 3.3.7, simple userspace.
Basic ideas are the same, but there are some important changes:
Networking support:
You'll need a TAP-WIN32 driver (openvpn, colinux, tunngle, qemu, etc).
The MFD will link to the first tap it finds.
By default it assumes IP of 192.168.2.10, and host being 192.168.2.1.
You can change these in /ubin/netset
The image is fully equipped - ssh, sshd, wget, links, nfs, etc.
So, now you can literally SSH into your Deltaglider.
File system:
Filesystem is on an MTD device - mtd.img file, there is no initrd now.
To keep the changes use SYN key.
It's an ext2 filesystem, easy to tweak if you have a linux box.
On the whole, modus operandi here would be to SSH into the MFD, and go on from here - the Shift+I input method is as bad as it was before, while over ssh you can easily have MC and like.
Sample code for both interfacing and userspace is provided as before.
There is an implementation of X server now, but i don't see how can this be of any use.
It takes minutes to boot into, the MFDs have neither mouse, nor touchscreen, not keyboard, and so on.
If you have any good ideas about how can an X-server-in-MFD be used, i'd like to hear them.
(Don't ask for Android and Angry Birds image, that was a joke).
Here it is:
http://orbides.1gb.ru/orbf/linuxmfd-120616.zip (9Mb)
Kernel 3.3.7, simple userspace.
Basic ideas are the same, but there are some important changes:
Networking support:
You'll need a TAP-WIN32 driver (openvpn, colinux, tunngle, qemu, etc).
The MFD will link to the first tap it finds.
By default it assumes IP of 192.168.2.10, and host being 192.168.2.1.
You can change these in /ubin/netset
The image is fully equipped - ssh, sshd, wget, links, nfs, etc.
So, now you can literally SSH into your Deltaglider.
File system:
Filesystem is on an MTD device - mtd.img file, there is no initrd now.
To keep the changes use SYN key.
It's an ext2 filesystem, easy to tweak if you have a linux box.
On the whole, modus operandi here would be to SSH into the MFD, and go on from here - the Shift+I input method is as bad as it was before, while over ssh you can easily have MC and like.
Sample code for both interfacing and userspace is provided as before.
There is an implementation of X server now, but i don't see how can this be of any use.
It takes minutes to boot into, the MFDs have neither mouse, nor touchscreen, not keyboard, and so on.
If you have any good ideas about how can an X-server-in-MFD be used, i'd like to hear them.
(Don't ask for Android and Angry Birds image, that was a joke).
Brilliant!
Giving this a whirl.
I went with the TAP-Win32 device/driver found at: http://openvpn.net
Giving this a whirl.
I went with the TAP-Win32 device/driver found at: http://openvpn.net
Linguofreak
Well-known member
They could possibly be used to implement remote MFD's: Keep the MFD screen as a command line (or maybe write a menu-driven text-mode shell that uses the MFD buttons for input), and only use X for remote X-over-SSH tunneled stuff. You can then write X programs that function as MFD's and X-tunnel into LinuxMFD from a remote machine to use them.