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.
Related
I may have a couple assumptions of Linux incorrect about the Linux system, and for that I apologize.
I have been educating myself on the Android and Linux systems for a while now and I started looking into installing a custom boot loader and Linux system onto an older Samsung tablet. Immediately upon looking into the feasibility of this, most of the answers I could find were that it wasn't possible because you would need the drivers that are being used by the android kernel to communicate with the OEM hardware in whatever Linux kernel you are installing.
I have one of these tablets rooted and I believe I may have found the drivers I need (not sure on that yet), and so I guess my question is, is it possible to take the drivers and put them into a Linux kernel within a distribution install image and install Linux on the device (using also a custom boot loader)?
I presume because someone hasn't done this before there is a pretty good reason why, but I am basically looking to be able to use Linux on my old tablet without the resources being taken from Android, and personally in my opinion, if I don't need Android and can install Linux straight on to the machine, then why keep it?
In the long run I am looking into LFS to create a custom distribution that can be installed on these tablets, but the most important question to me right now is if I do create this distribution can I get the drivers that the hardware needs (and even then will my kernel be able to use them?).
I also understand that some of these drivers may be proprietary drivers provided by the manufacturer, but I am not looking to profit off of this but instead research the feasibility of a better personal on-the-go computing setup.
I may be terribly wrong on how I may have described some things, so here are some of my assumptions:
The .ko files in the Android /lib/modules/ directory are the static kernel drivers I am looking for for that device.
The drivers aren't written for specifically the Android system, but for all Linux variants and would be compatible with another distribution.
If the drivers were written for the Android system, then one would be able to edit or modify those drivers to work with a different distribution.
One could "put the drivers into an installation image", or if not, then one would have to compile the kernel from source with those static drivers.
TL:DR, If this all just amounts to rambling, here are my specific questions:
Is it possible to copy the static kernel drivers of a rooted Android device to something like the SDcard?
Is it then possible to "put" or "compile" those same static drivers into a Linux distribution before installing it onto said tablet using something like Odin, or the like?
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 developing a multi-core processor with RISCV architecture.
We had already ported Linux for single-core RISCV processor and it is working on our own FPGA based board with busybox rootfs.
I want to port Linux for multi-core RISCV processor now.
My doubts are:
Whether the gnu-riscv-gcc toolchain available now supports multi-core?
Whether spike available now supports multi-core?
Should I make any change to the bbl bootloader (Berkely bootloader) to support multi-core?
What are the changes I should make for my single-core Linux kernel to support multi-core?
The current RISC-V ecosystem already supports SMP Linux.
No changes to the compiler are required for multicore.
Spike can simulate multicore when using the '-p' flag.
BBL supports multicore.
Before building linux, configure it to support SMP.
Any hiccups, are probably due to the toolchain out of sync with the newest privileged spec changes. Last Fall, users successfully built and ran multicore Linux on RISC-V.
This is all expected to work out of the box. My standard testing flow for Linux and QEMU pull requests is to boot a Fedora root filesystem on QEMU via Linux+BBL. Instructions can be found on the QEMU Wiki Article about RISC-V. This will boot in our "virt" board, which uses VirtIO based devices. These devices have standard upstream Linux drivers that are very well supported, so there isn't really any platform-level work to be done.
In addition to the standard VirtIO-based devices, SiFive has devices that are part of the Freedom SOC platform. If you platform differs significantly from SiFive's Freedom platform then you'll need some additional drivers in both Linux and BBL.
We maintain an out-of-tree version of the drivers we haven't cleaned up for upstream yet in freedom-u-sdk, which should give you a rough idea of how much work it is. Running make qemu in that repository will boot Linux on QEMU via BBL, and running make will show you how to flash an SD card image for the HiFive Unleashed board.
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 have an ARM kit beside me and a Linux kernel source code patched with Xenomai on my machine. I understand I can send data to the kit through an USB cable and a (windows-based, of course) software, but I'm stumped as to exactly what I should be sending that would make the kit run Linux.
(clarifications from comments: It is an Atmel AT91SAM9260-EK kit. It uses SAM-BA and SAM-PROG for the loading and unloading of data through either a serial or USB cable.)
I'd start with the ATM91SAM9 Linux software package from Atmel and follow the instructions.
Linky:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4335
Otherwise, you need to get GCC setup with an ARM back end on a Linux box, build a Linux binary and then figure out how to load it on the devt board.
You might want to check out some cross compiler like OpenEmbedded which will help you compile the kernel for the ARM architecture.
i would suggest jtag and openOCD, then you just use the JTAG to place your filesystem and kernal image in the flash memory, in a place wear our bootloader can find it. you might have to change your bootloader.
another option is you might start up your micro, then insert a bootloading program into the RAM of the program then change the program counter to point at it.
that bootloading program can init the UART/USB then you have a host side program that transers the files. this method is very complicated and generally only good if you don't want to spend 100$ on a jtag (hint, buy a jtag they are useful)