Basically I would like to know the difference between ARMv7l and ARMv7hl?
I got a arm processor with armv7l and there are a lot of rpm's for armv7hl.
I don't exactly know what I have to search for to get information about that.
What is this "suffix" called? Are there any other types? What are they doing differently?
I would assume that it's indicating packages compiled for little-endian and hard-float ABI as appropriate - i.e. it's a software thing and only tangentially related to the hardware.
In other words, you don't actually have an "armv7l" processor - you have an ARMv7 processor which may well have a hardware FPU (and can run big-endian if you really wanted to), but you happen to be running a soft-float userspace that doesn't rely on one being present - just like running an i686 distribution doesn't imply you're not on an x86_64 machine. Different Linux distributions have different names for their various ports but some trivial poking around suggests this case might be openSUSE's convention.
Related
For eg. arm-unknown-linux-gnueabi
Now, once the OS i.e Linux is fixed, the C Library will be fixed (GLibc) and hence the calling convention and ABI being followed will be fixed. What is the requirement of 4th field i.e. ABI separately? Can a toolchain use a different ABI from the one used by underlying OS and LIBC. In that case how will libraries compiled by the said toolchain run on the OS?
It's more or less a matter of historical reasons, a.k.a the holy wars about the sacred operating system's name. What you call the "toolchain name" is actually called the Target Triplet, and as it name imply, it has three fields, not either more or less. In your example case, the fields would be:
Machine/CPU: arm
Vendor: unknown
Operating System: linux-gnueabi
Take another reference example I've already faced: i686-elf-gcc, which is used for hobbyist operating system development:
Machine/CPU: i686-elf
Vendor: unknown (implicit)
Operating System: none (implicit; the compiler is actually a freestanding cross compiler, used for the development of operating system kernels, thus the code it outputs expects no underlying OS, as the output code is the OS itself!).
This is just a matter of confusion originating from the fact that the fields may (and do) use the - character, which is used to separate the fields, too. In your case, the OS is considered to be linux-gnueabi, otherwise known as the GNU operating system with the Linux kernel using the Embedded ARM ABI. The Linux Kernel has historically been one of the most portable pieces of software in the world, so it's expected to be portable to other ARM ABIs, although I'm only aware of the EABI...
i am searching for a linux cross reference for the first linux kernel 0.01,
many websites provide a LXR (Linux Cross Reference) for existing kernels starting from 2.x but not including old ones.
There is no cross-reference readily available for this version, because it is too old. If you want one, you will have to create it yourself. (Which should not be difficult; this version of the kernel is barely 10k lines of code. This is small enough that a cross-reference is hardly even necessary.)
Keep in mind that Linux 0.01 was a very early release. It represents the original "pre-alpha" version of the kernel that Linus Torvalds made available on his university's FTP server in 1991. At that point in time, the kernel had one developer (Linus himself) and no users.
Moreover, Linux 0.01 isn't even a very good resource for learning about the Linux kernel. It predates much of the modern organization of the kernel, and as such is significantly different from modern kernels. In particular:
Kconfig is not present. Linux 0.01 had no configuration options at all, and was built using hand-written Makefiles.
There is no arch directory yet. Linux 0.01 would only build and run on x86 systems.
There is no drivers directory either. The system only supported a few built-in system devices, such as the hard disk and keyboard, and those were essentially hard-coded into the kernel directory.
There is no support for SMP systems, nor any form of locking or kernel preemption. Multiprocessor x86 systems were extremely rare when Linux 0.01 was released, so Linus didn't have one to test on.
Many commonly used macros and structures in the modern Linux kernel, such as struct list, are not yet present. There wasn't a need for them yet.
Trying to use this extremely early version of Linux for learning purposes is not a good introduction to Linux kernel programming. If you want to learn, you should really work with a current version.
You don't need a cross-reference site. If you have a copy of the source code, download and use cscope. It's a great tool for searching C programs; I'm sure you'll find it useful.
Going thru the ARMv8 manual, I have the following questions to help understand the big picture.
Can legacy 32 bit app. (ARMv7 or earlier) run as is on the ARMv8 OS?
If the legacy applications need to be rebuilt for ARMv8 and assuming that I rebuild the application as 32 bit (Aarch32), does this need 32 bit OS underlying support? (It is interesting to know how the addressing mechanism works here.)
Please provide references wherever possible.
PS: I am targeting Linux OS with Aarch64 support (3.7 and later)
Aarch64 platform may run 32bit ARM but this compatibility is optional.
To run AArch32 binaries you need all libraries application would use in 32bit versions. Same as with i686 binaries on x86-64 systems.
There is also a Linux arm64 CONFIG_COMPAT at: https://github.com/torvalds/linux/blob/v4.17/arch/arm64/Kconfig#L1274 which says:
This option enables support for a 32-bit EL0 running under a 64-bit
kernel at EL1. AArch32-specific components such as system calls,
the user helper functions, VFP support and the ptrace interface are
handled appropriately by the kernel.
which will likely be required, and an ARM employee mentioned on this thread: https://community.arm.com/processors/f/discussions/5535/running-armv7-binaries-on-armv8 that userland instructions are basically the same with some exceptions:
For something like a Linux application, then yes. ARMv8-A includes AArch32, which provides backwards compatibility with ARMv7-A. There are some limitations, such as the SWP instruction no longer being supported. But these are types of things that applications are unlikely to be using (and were deprecated in ARMv7).
For baremetal, you have all the usual problems of using a binary from one platform on another. So you are going to need to do some degree of porting in most cases.
I then tried it for myself with this QEMU full system setup but my attempt failed: I compiled a C hello world with the armv7 compiler as:
arm-linux-gcc -static hello_world.c
and put the built file into the aarch64 target, but when I tried to run it it failed with:
a.out: line 1: syntax error: unexpected word (expecting ")")
even though /proc/config.gz says that CONFIG_COMPAT is set.
It seems that the Linux kernel is not identifying it as an ELF file but rather falling back to /bin/sh, I get the same error if I do:
sh /mnt/9p/a.out
is trying to use the shell binfmt instead of ELF.
In particular, I know that the Linux kernel can choose between archs from the binfmt signature because qemu-user does so: https://unix.stackexchange.com/questions/41889/how-can-i-chroot-into-a-filesystem-with-a-different-architechture
My question is somewhat weird but I will do my best to explain.
Looking at the languages the linux kernel has, I got C and assembly even though I read a text that said [quote] Second iteration of Unix is written completely in C [/quote]
I thought that was misleading but when I said that kernel has assembly code I got 2 questions of the start
What assembly files are in the kernel and what's their use?
Assembly is architecture dependant so how can linux be installed on more than one CPU architecture
And if linux kernel is truly written completely in C than how can it get GCC needed for compiling?
I did a complete find / -name *.s
and just got one assembly file (asm-offset.s) somewhere in the /usr/src/linux-headers-`uname -r/
Somehow I don't think that is helping with the GCC working, so how can linux work without assembly or if it uses assembly where is it and how can it be stable when it depends on the arch.
Thanks in advance
1. Why assembly is used?
Because there are certain things then can be done only in assembly and because assembly results in a faster code. For eg, "you can get access to unusual programming modes of your processor (e.g. 16 bit mode to interface startup, firmware, or legacy code on Intel PCs)".
Read here for more reasons.
2. What assembly file are used?
From: https://www.kernel.org/doc/Documentation/arm/README
"The initial entry into the kernel is via head.S, which uses machine
independent code. The machine is selected by the value of 'r1' on
entry, which must be kept unique."
From https://www.ibm.com/developerworks/library/l-linuxboot/
"When the bzImage (for an i386 image) is invoked, you begin at ./arch/i386/boot/head.S in the start assembly routine (see Figure 3 for the major flow). This routine does some basic hardware setup and invokes the startup_32 routine in ./arch/i386/boot/compressed/head.S. This routine sets up a basic environment (stack, etc.) and clears the Block Started by Symbol (BSS). The kernel is then decompressed through a call to a C function called decompress_kernel (located in ./arch/i386/boot/compressed/misc.c). When the kernel is decompressed into memory, it is called. This is yet another startup_32 function, but this function is in ./arch/i386/kernel/head.S."
Apart from these assembly files, lot of linux kernel code has usage of inline assembly.
3. Architecture dependence?
And you are right about it being architecture dependent, that's why the linux kernel code is ported to different architecture.
Linux porting guide
List of supported arch
Things written mainly in assembly in Linux:
Boot code: boots up the machine and sets it up in a state in which it can start executing C code (e.g: on some processors you may need to manually initialize caches and TLBs, on x86 you have to switch to protected mode, ...)
Interrupts/Exceptions/Traps entry points/returns: there you need to do very processor-specific things, e.g: saving registers and reenabling interrupts, and eventually restoring registers and properly returning to user mode. Some exceptions may be handled entirely in assembly.
Instruction emulation: some CPU models may not support certain instructions, may not support unaligned data access, or may not have an FPU. An option is using emulation when getting the corresponding exception.
VDSO: the VDSO is a virtual library that the kernel maps into userspace. It allows e.g: selecting the optimal syscall sequence for the current CPU (on x86 use sysenter/syscall instead of int 0x80 if available), and implementing certain system calls without requiring a context switch (e.g: gettimeofday()).
Atomic operations and locks: Maybe in a future some of these could be written using C11 support for atomic operations.
Copying memory from/to user mode: Besides using an optimized copy, these check for out-of-bounds access.
Optimized routines: the kernel has optimized version of some routines, e.g: crypto routines, memset, clear_page, csum_copy (checksum and copy to another place IP data in one pass), ...
Support for suspend/resume and other ACPI/EFI/firmware thingies
BPF JIT: newer kernels include a JIT compiler for BPF expressions (used for example by tcpdump, secmode mode 2, ...)
...
To support different architectures, Linux has assembly code (re-)written for each architecture it supports (and sometimes, there are several implementations of some code for different platforms using the same CPU architecture). Just look at all the subdirectories under arch/
Assembly is needed for a couple of reasons.
There are many instructions that are needed for the operation of an operating system that have no C equivalent, at least on most processors. A good example on Intel x86/64 processors is the iret instruciton, which returns from hardware/software interrupts. These interrupts are key to handling hardware events (like a keyboard press) and system calls from programs on older processors.
A computer does not start up in a state that is immediately ready for execution of C code. For an Intel example, when execution gets to the startup routine the processor may not be in 32-bit mode (or 64-bit mode), and the stack required by C also may not be ready. There are some other features present in some processors (like paging) which need to be turned on from assembly as well.
However, most of the Linux kernel is written in C, which interfaces with some platform specific C/assembly code through standardized interfaces. By separating the parts in this way, most of the logic of the Linux kernel can be shared between platforms. The build system simply compiles the platform independent and dependent parts together for specific platforms, which results in different executable kernel files for different platforms (and kernel configurations for that matter).
Assembly code in the kernel is generally used for low-level hardware interaction that can't be done directly from C. They're like a platform- specific foundation that's used by higher-level parts of the kernel that are written in C.
The kernel source tree contains assembly code for a variety of systems. When you compile a kernel for a particular type of system (such as an x86 PC), only the appropriate assembly code for that platform is included in the build process.
Linux is not the second version of Unix (or Unix in general). It is Unix compatible, but Unix and Linux have separate histories and, in terms of code base (of their kernels), are completely separate. Linus Torvald's idea was to write an open source Unix.
Some of the lower level things like some of the architecture dependent parts of memory management are done in assembly. The old (but still available) Linux kernel API for x86, int 0x80, is implemented in assembly. There are probably other places in the kernel that are implemented in assembly, but I don't know any others.
When you compile the kernel, you select an architecture to target. Depending on the target, the right assembly files for that architecture are included in the build.
The reason you don't find anything is because you're searching the headers, not the sources. Download a tar ball from kernel.org and search that.
NanoBSD is a script that makes light, small and in-memory FreeBSD copy. It is useful in embedded systems. Is there something similar to NanoBSD in Linux? Specially a feature like Everything is read-only at run-time as it mentioned here .
A lot of toolchain / system build systems build Linux root filesystems which are designed to run completely out of a ramdisc (rootfs / tmpfs). This means that everything is read/write at runtime, but it does not persist across reboots (a persistent FS can of course, be mounted as a non-root FS).
The most well known of these is Busybox (with or without uclibc), which ships with various scripts to build very small-footprint Linux-based embedded systems (root FS is typically a few Mb only; just add a kernel). Busybox/Linux is not the same as GNU/Linux, but it is fairly similar - most things are simpler or have fewer options; some features are entirely absent or can be disabled at compile-time.
Linux is NOT an Operating system like FreeBSD, rather it is a kernel. You can choose to layer either GNU C library and tools (which I think all major general-purpose distributions do) or something else - which is mostly used for smaller systems, including uclibc, Android etc.
There are literally hundreds of toolchains, build environments and embedded distros of Linux, some only a couple of megabytes in size. Many also support some or many of the different processors Linux runs on (i386 and friends, ARM, Power, ...).
To get you started a couple of projects I find interesting: OpenWrt and OpenEmbedded, and lpclinux, Linux for NXP LPC3xxx ARM processors but there are really hundreds of them.
Some other resources
A very good source that (also) touches a number of issues specific to embedded systems is Linux from scratch. And this pdf gives some insight in the different available filesystems for an embedded Linux system.
i would take a look at TinyCore-Linux.
which isn't really ro but nearly the same Concept and i think there is also a was to get the OS/Binary Part ro were the config part is writeable.