I have a Gdium Liberty 1000 laptop (Loongson 2F processor) on it's way to me. I will use it mainly to explore the MIPS assembly language. The inner architecture of the Loongson is supposed to be different from the MIPS CPUs. Does it in fact run MIPS assembly (MIPS64?) with no modification or are there any particular quirks to the Loongson 2F architecture? I realize that I can run SPIM (or MARS) as MIPS simulators on my Intel/AMD x86 processors, it just seemed like fun to try to run it natively.
Does it run MIPS assembly (MIPS64?) with no modification?
What tools are available on the Gdium (it runs a version of Mandriva Linux) for learning MIPS assembly?
Loongson 2F is MIPS III-compatible, so this means that you will be able to write MIPS III compatible assembly, compile it and run it. If available, native toolchain should be a better choice than any cross toolchain.
I would suggest reading a UserGuide which will tell you what instructions you have available. Note that the instruction set for this chip has been extended with number of different integer/fp/media instructions.
From wikipedia on Loongson:
The current Loongson instruction set is a MIPS64,
but the internal microarchitecture is independently developed by ICT.
Early implementations of the family lacked four instructions
patented by MIPS Technologies to avoid legal issues.
Yes, it is certainly fun to run MIPS assembly on the real hardware (actually, for similar reasons I've bought myself an old PowerPC Mac as this was a great option to get a decent PowerPC processor).
Regarding the problem with development, I would recommend:
Setup the remote access (run 'sshd' there) to this technical wonder
Download some precompiled gcc toolchain for MIPS
Compile binaries locally, deploy them using 'ssh' to the netbook.
Setup 'gdbserver' there (on the netbook) if you want remote debugging or stick to extensive logging
Related
Is there any way to run a MIPS binary on a Linux x86/x86-x64 machine? I got some applications for Enigma2 set-top-boxes (which is also based on Linux) that I want to run on a x86/x86-64 machine. These plugins are only available for MIPS processors.
The keyword is "emulator". The most famous emulator is qemu which can pretty much emulate any architectures out there, but there are also lots of MIPS emulators on Linux that you can find in the Linux-MIPS wiki:
Open Virtual Platforms (OVP) OVPsim
GXemul
SimOS
Sulima
MIPSsim
MipsSim
SPIM
VMIPS
Virtutech Simics
SandUPSim
MPS
YAMS
MAME/MESS
MISSE
Cisco 7200 Simulator
QEMU
VirtualMIPS
Miep
MARS
QtMips
Note that there are full-system emulation (which is heavier) and user-mode emulation which emulates a single process. Depending on which type you need you must choose one, but qemu supports both
Full-system emulation: Run operating systems for any machine, on any supported architecture
User-mode emulation: Run programs for another Linux/BSD target, on any supported architecture
However performance will be terrible so you'll never want to run an app that need to be fast like a video decoder in a set-top-box. If the source is available then just recompile it
See Decompile / Run MIPS executable under x86_64 Ubuntu
Qemu could be your Messiah this time. I use it personally and it really saves a lot of pain using an FPGA.
https://www.linux-mips.org/wiki/QEMU
Of course, this isn't natively executing the MIPS binary on your computer. But I suppose that if you can find plugin of your app coded for MIPS processors, the app itself can be found for MIPS.
We are porting a solution to ARM that was originally designed to run on x86/x64 Debian based systems.
So far so good however along with this solution we ship out a printer that is compatible and comes with drivers for Linux (x86 and x64), unfortunately the manufacturer does not have ARM drivers for it, nor is capable of compiling some from source code (don't know why).
I've installed the printer with CUPS and used the x86 binary. But of course, whenever I send a task to the printer, the ARM system cannot use the binary and naturally CUPS reports:
/usr/lib/cups/filter/rastertotg2460 failed
I would like to know how I can run x86 binaries on ARM v6 based systems?
The ARM operating system is Raspbian running on a Raspberry Pi B+ board and the binaries (if you want to take a look) are here.
EDIT:
I was also made aware of this proprietary solution that claims to make it possible running x86 binaries on ARM systems, but all demonstrations are for ARM v7 systems, not sure if it will work on Raspbian with a Raspberry Pi B+ board.
I think this is going to require some serious work, but I had it the wrong way around initially.
Since you want to drive the printer, you're going to have to do the x86 emulation "inside" the CUPS system. It's not enough with a stand-alone x86 emulator, since those aim to give you a full x86 system with peripheral hardware and stuff. You don't need that, you just need to drive the printer.
I can imagine using some kind of x86 emulation library inside a CUPS "virtual" driver, which in turn loads the x86 binary you have and feeds it into the emulator. It would then need to expose the expected CUPS environment to the x86 code inside the emulator.
Something like Soft86 might be a good starting-point.
I want to examine the Linux kernel source code using Visual Studio on Windows. But I don't know how to do that. Do I need a virtual machine to run or debug the kernel or is there any special way for me to do that ???
What does "kernel examination" means to you?
Why can't you more simply study the source code of the Linux kernel?
It is free software, you cant fetch its source code from kernel.org
it is extremely likely that your Linux vendor publishes either the source code of his variant of Linux kernel, or patches against vanilla kernel source code. The GPLv2 license of the Linux kernel nearly requires such a behavior.
And a Linux system gives you a lot of tools (objdump, ....) to study ELF executable image (like the Linux kernel mostly is....)
You probably won't be able to compile the Linux kernel with Visual Studio. You need GCC (or a very compatible compiler). Linux source code uses many GCC extensions.
My advice is to install a Linux system on your development machine (you can have a dual boot if you want to keep Windows for games....) and to learn it and to use Linux tools (including emacs, grep, etags etc....) to study the source code of Linux. Remember that Linux is the preferred platform to build the Linux kernel... (if your distribution is Debian or Ubuntu or similar, learn about make-kpkg)
Also read some good books about Advanced Linux Programming and about the Linux kernel (there are many of them).
BTW, you could even customize your GCC compiler, e.g. with a plugin or a MELT extension, to measure, search, or even refactor the source code of the kernel. See also cocinelle.
I want to learn it like developing some device driver etc and use QEMU for this because i have no hardware board for ARM like beagle board. What you guys suggest? Can i use Qemu simulator to learn Linux kernel on ARM targets? or any other option i should try ?
It depends on what you want to learn: hardware or software. If you really want to experiment with the different GPIO output to implement things like servo motor control, LED light blinking and display, a cheap board (eg, Raspberry Pi, about USD25) is much preferred.
But if you want to learn software in general, qemu is definitely much faster, and it lets you see the internal of what is happening. Experimenting with hardware will require oscilloscope etc. But experiment with software will depends on the error output of what others has implemented in their software.
As for drivers development, first version should be rapidly developed on QEMU. But testing which naturally involved hardware, should be done on the hardware.
Bottomline is: x86 is so much faster, that cross-crompilation is always done on x86 before it gets booted on the ARM board. Compiling on the board is too time consuming, and sometimes it may involved considerable amount of storage space for development libraries and source codes.
I used Qemu a while back to develop device drivers for an embedded programming class. It worked quite well. At the time we were learning device driver programming and then transitioning to Gumstix boards. I don't remember exactly what core we were using, but Qemu worked well.
I haven't done any ARM development, so I don't know if it is the best choice for learning ARM. But if you are new to drivers, it is probably a good place to start.
QEMU + Buildroot is great combination for ARM kernel development
Here is my setup that supports (mostly) both x86 and ARM: https://github.com/cirosantilli/linux-kernel-module-cheat
The kernel, toolchain, userland and QEMU are amazingly portable, that going from x86 to ARM is almost trivial.
Actually, you will seldom touch arch specifics, so you might as well start with x86.
I haven't played with ARM devices yet, only x86, but I bet it will be equally easy (i.e. not trivial due to lack of tutorials, but doable).
Although having a little experience, I am still confused with the question of whether it is necessary to install an application and/or build a C++ program or C++ library under Network File System shared by machines, which have different Linux version (e.g. CentOS release 4.7, Ubuntu 8.10), possibly different bit (e.g. 32-bit, 64-bit) and different versions of compiler (e.g. gcc/g++ 3.4.6 20060404 (Red Hat 3.4.6-10), gcc/g++ (Ubuntu 4.3.2-1ubuntu12) 4.3.2.), so that the executable or library files can be used under those different machines? What's the principles here?
For example, on a Network File System, I have an executable built from my C++ program under a machine with CentOS release 4.7, x86_64 ad gcc/g++ 3.4.6 20060404 (Red Hat 3.4.6-10). I surprisedly find that the executable can be used under another machine with Ubuntu 8.10, x86_64 and gcc/g++ (Ubuntu 4.3.2-1ubuntu12) 4.3.2. Also all the shared libraries I built on the first machine and used by my program do not complain error when the executable is running on the second machine. I am so worried if the running of the executable built on a different machine will give reliable results?
Another example, I remember a executable built on a 64-bit machine cannot run on a 32-bit machine. But how about the other way around, running on a 64-bit machine an executable built on 32-bit machine? How about C++ library files built and used across different bit machines?
If possible, could you point me to some reference, like some webpage, book,... that are related to my questions?
Thanks and regards!
You really need to test your program on each different configuration to be absolutely sure.
You can usually run 32 bit programs on 64 bit machines so you can probably get away with only a 32 bit version if you want.
You need to be a little careful about which version of gcc was used on each platform. Running a program built with gcc 4 on a machine whose OS and glibc were built with gcc 3 could cause you problems. So make sure that at least the major version numbers match.
Obviously, if you have different machine architectures, Sparc versus AMD64 for instance, you will need different versions. There are even some subtle differences between Intel and AMD so don't get over aggressive with the compiler optimizations and if you program uses SSE instructions (if you don't know what this is then you aren't using it), make sure the SSE set you use is supported by all the machines.
The key issues here are the machine architecture, the availability of the right libraries, and the "ABI" or Application Binary Interface. The ABI specifies how the OS should use machine registers and memory to pass information between different parts of the program, for example, how data is pushed onto the stack to pass arguments to a function. The ABI used by GCC has been known to change from time to time which is why using compatible versions is necessary.
I'm not aware of a book or web page that covers all these things. Start with the documentation for GCC and Binutils. And there is no substitute for good testing.