I have PowerPC e5500 family based embedded board. I want to compile a linux kernel with Yocto. I want this kernel to be a little endian kernel. But when I try to enable little-endian option in kernel config (make menuconfig), there is only big endian option.
I made a little research. PowerPC arch mostly supporting big-endian. I want to ask this question, if is there any way to compile PPC kernel for little-endian, can anyone tell me ?
The Linux kernel only supports little-endian kernels on 64-bit Book3S processors (see CPU_LITTLE_ENDIAN in arch/powerpc/platforms/Kconfig.cputype), and it's only really supported for Power8 (ISA 2.07) onward. Embedded systems (Book3E-based, such as the e5500) are all big-endian only - at least as far as the kernel is concerned.
Related
I apologize if the answer to this question is apparent, but why are there two versions[1] of the vdso for 32-bit executables on linux systems, and what is the criteria used to select among them?
* as can be found in /lib/modules/KERNEL_NAME/vdso
x32 is a Linux ABI which is kind of a mix between x86 and x64. It uses 32-bit address size but runs in full 64-bit mode, including all 64-bit instructions and registers available.
My question is quite specific. I have to write a simple program which works with files and should be run on arm 32bit (android). The crucial point is that it MUST use the _llseek syscall. This syscall exists in a 32bit linux kernel but is absent in a 64bit one.
Technically I can write and run this program on the arm device (phone in my case) but I do things on a 64bit box which I would normally use for tests and debugs. In this case my program fails to compile and run on my 64bit box due to the lack of this syscall.
What can be a workaround? I need some friendly test/debug environment. Is installing a 32bit virtual linux the only option?
Thanks in advance, Alex
The -m32 flag worked and indeed the 64bit kernel accepted the bytecode. Stupid enough that I did not come to this simple option myself, thanks.
Or put it differently. I did not notice that the 64bit kernel implements all 32bit calls in parallel, even those absent in the native 64bit code.
You can install an entire Linux 32 bits (x86/32 i.e. ia32) system in a partition -or simply a subdirectory- and run it under chroot in a 64 bits x86-64 Linux kernel (because 64 bits kernels for x86-64 are generally configured to be able to run 32 bits x86 code, that is to execve(2) a 32 bits x86 ELF executable binary) The debootstrap command (on Debian & related) is documenting such a use, see also schroot (you might not need to install every package in 32 bits chroot, only the relevant ones).
You can also use gcc -m32 to compile to a 32 bits x86 ELF binary on a 64 bits x86-64 machine. You may need additional packages (often with multilib or ia32 or x86 in their name).
Of course you need to recompile the application since ARM is not the same as x86/32 bits
However, you cannot run an ARM 32 bits application (only a x86 32 bits one) on a 64 bits x86-64 Linux. To run an ARM application on x86, you need an ARM emulator (e.g. qemu....)
So, debug first your thing on x86/32 bits using a 32 bits chroot-ed environment on your 64 bits x86-64 Linux system.
Is there is a way to know dynamically Linux architecture, whether it x86-64 or x86?
The Posix standard uname function (implemented in the uname(2) syscall) is dynamically giving you the information about the CPU. You probably want the machine field.
Caution about x86-64 kernels running a 32 bit program (e.g. a 32 bits Debian distribution chroot-ed in a 64 bits Debian, or perhaps a 32 bits ELF binary running on a 64 bits system); I have no idea what they give in that situation; I would imagine some x86_64 in that case, since the kernel does not really know about the binaries and libc of the system.
See also the Linux specific personality(2) syscall.
Google is your friend: http://sourceforge.net/p/predef/wiki/Architectures/
You want to test for the macros __amd64__ and __i386__. Ideally, you don't test the macros at all and write correct, portable code.
You can use lscpu command to list characteristics about CPU.
I encountered this while trying to understand ELF (Executable and Linking Format).
Steps I followed
Wrote a simple application.
main.c containing
int main(int argc, char **argv){ return 0;}
Compiled in linux environment using gcc. (Done on intel laptop)
Simplest command possible
gcc main.c
Now when I run a.out, it runs without any issue. So build is fine.
I used readelf tool to retrieve the ELF information, where in machine field is put as Advanced Micro Devices X86-64.
This part puzzled me.
So I checked the file header of a.out, it was as per ELF-64 specification (Value 64 - EM_X86_64).
Would anyone care to explain, why does the executable, built in 64 bit mode on linux, show machine type as AMD x86 64?
The x86_64 platform was called the AMD64 platform back when AMD introduced it. Initially, it was far from clear that Intel would ever support it.
You notice how long after i386's ceases to exist, a lot of software had the architecture tag i386? It was because i386 CPUs introduced the instruction set that software uses. Similarly, AMD introduced the instruction set your program uses, so it has an architecture tag that reflects the first CPUs that supported its instruction set. (Modern 32-bit code is still often tagged i686 which refers to the Pentium Pro, circa 1995.)
For a while, the IA-64 (Intel Architecture 64-bit) or Itanium chips were Intel's 64-bit offering, and the Pentium-class chips were the IA-32 chips. The IA-64 chip instruction set was sufficiently different from the Pentium code set that people did not pick it up in large numbers. Meanwhile, AMD came out with a 64-bit extension to the Pentium code set - and that got a lot of support. After a while, Intel bowed to the inevitable and made its own chips that were compatible with the AMD x86/64 chips. But it was AMD that specified the architecture, so it gets the credit in the name.
why does the executable ... show machine type as AMD x86 64?
Because the ELF machine code, used by file, was registered by AMD. There is the official list of registered codes: http://www.sco.com/developers/gabi/latest/ch4.eheader.html (the table at second page):
e_machine
This member's value specifies the required architecture for an individual file.
Name Value Meaning
EM_NONE 0 No machine
...
EM_X86_64 62 AMD x86-64 architecture
I want to learn programming in assembler for PowerPC and ARM, but I'm unable to buy real hardware for this purpose. I'm thinking about using QEMU for that. However I'm not sure if it emulates both architectures enough well, that I'll compile and run my programs in native assembler on it?
QEMU works well for testing program correction (i.e. whether the code would properly run on an actual ARM or PowerPC) but it is not good for testing program efficiency: the emulation is not cycle accurate, and speed measured with QEMU cannot be reliably (or even unreliably) correlated with speed on true hardware.
Also, QEMU will not trap unaligned memory accesses, which is not a problem for PowerPC emulation (the PowerPC tolerates unaligned accesses) but may be for ARM (an unaligned access, e.g. reading a 32-bit word in RAM from an address which is not a multiple of 4, will work fine with QEMU but would trigger an exception on a true ARM processor).
Apart from these points, QEMU is fine for assembly development on ARM or MIPS (haven't tried PowerPC, because I found an old iBook on eBay for that; but I have done ARM and MIPS assembly with QEMU and then ran the resulting code on true hardware, and this worked). You can either emulate a whole system and run Debian in it (in which case the compiler, linker, text editor... will also run in emulation), or use the "user-mode emulation" where the ARM/MIPS executable is run directly, with a wrapper which converts system calls into those for the host PC (this assumes that the host is a PC running Linux). The latter is more convenient (you have access to your normal home directory, programming tools are native...) but requires installing cross-development tools. See buildroot for that (and link with -static, this will avoid many headaches).
Since I have found signs that Debian for PowerPC and for ARM can run on QEMU, I suppose this won't be a problem.