So I've been gifted 2x gen 1 Galileos that I want to try to do something with before I throw them in the garbage.
It's my understanding that they wont run most i386 kernels from most distros as they need to be Pentium II compile flags.
So this guy shared his kernel configs https://twitter.com/kerneldave/status/1359178557570732032 and I have compiled the kernels using a standard GCC stack on ubuntu.
I cannot get the resulting kernel to boot. After Grub loads the kernel there is no activity on the console (via the serial cable)
Will mainline kernels work on Gen 1?
Does it need to be compiled with some special toolchain or will gcc be fine?
Any special boot params need to be used, APIC/ACPI, console options?
Thanks
Related
I have multiple questions regarding debugging a Raspberry pi 3 from a linux x64 host using gdb-multiarch, as well as writing bare metal programs in general. We are currently facing a problem where our code appears to not be loaded into memory. When we begin debugging in GDB we start at address 0. 3 instructions down we jump into 0x10000. If I modify my linker script to put the Raspberry pi into either address I get the same result, we jump into 0x10000 and our code isn't loaded there. Instead we get this
We noticed also that GDB is using 32 bit register names here when we're supposed to be debugging 64 bit code.
Again a recap of what we're using:
QEMU with versatile-pb machine.
An aarch64 GCC cross-compiler.
GDB-multiarch.
We've tried on two different hosts: Ubuntu 16.04 x64 Host running in virtualbox. Mint x64 running natively.
We also tried the arm-none-eabi toolchain but were running into problems not having our code compiled as 64 bit.
Help is much appreciated! Thanks!
You don't give your command line, but "versatile-pb" is a 32-bit only board type, so trying to run 64-bit code on it is going to misbehave in confusing ways. You need to tell QEMU to emulate a 64-bit capable board that matches what your bare-metal code is expecting to run on.
In QEMU 2.12 there will be a "raspi3" QEMU board which may be helpful for you; you'd need to try building the latest 2.12 release candidate tarball at the moment if you wanted to experiment with that (2.12 release isn't due for another couple of weeks). Otherwise you could use the "virt" board if you made sure your bare metal code was built to be able to run on that board.
I am very new to linux and GCC. The price of raspberry pi lured me in. I am interested in using GCC to cross compile some C Code to target some embedded hardware, specifically a Cortex-M3 micro. I eventually want to have a full suite of compiler/programmer/debugger, but for now I'm starting with compiler.
So I did a quick non-cross compile test on the RP3, and all was well. Now I am researching how to cross compile and target my uc. The gcc documentation online seems to indicate that I can use the plain vanilla gcc, and just specify some command line options to perform cross compilation: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
But searching around, I find a lot of people mentioning building a gcc cross compiler. What does this mean?
Does gcc have options to double as a cross compiler? If so, why would one desire "building" a cross compiler?
A cross-compiler is one that is created on machine type A (combination of hardware and o/s) and either runs on a different machine type B or runs on type A but produces software to be run on a different machine type B.
Thus, if you have a Linux machine using an x86_64 CPU and running on some version of Linux, but you compile GCC so that it will run on an IBM PowerPC platform running some version of AIX, you would be creating a cross-compiler.
Another variant might be having a compiler on Linux using an x86_64 CPU that runs on the Linux machine but produces code for an embedded hardware chip. You'd then benefit from the CPU power of the Linux machine while deploying to a much smaller, less powerful system that maybe has no o/s of its own, or only a minimal o/s.
I have an (old) embedded system for which I want to compile programs. I don't have the toolchain, so I want to create one.
The embedded system has an "ARM926EJ-S rev 5 (v5l)" CPU and "cat /proc/version" says that it runs "Linux version 2.6.20.7" with GCC 4.0.2.
I have heard that I have to include the kernel headers in the build process. I download the Linux kernel version 2.6.20 from kernel.org, extract all files and run "make headers_install ARCH=arm INSTALL_HDR_PATH=~/headers". Is this the correct way or do I need the header files of the specific kernel?
untar the kernel.
make mrproper
make ARCH=${arch} headers_check
e.g make ARCH=arm headers_check
make ARCH=${CLFS_ARCH} INSTALL_HDR_PATH=dest headers_install
This are the steps to get headers from kernel.
The purpose of kernel headers is -->C library and compiled programs needs to interact with the kernel
i.e for Available system calls and their numbers, Constant definitions, Data structures, etc.
Therefore, compiling the C library requires kernel headers, and many applications also require them.
do I need the header files of the specific kernel?
The kernel-to-userspace ABI is backward compatible
--> 1)Binaries generated with a toolchain using kernel headers older
than the running kernel will work without problem, but won't
be able to use the new system calls, data structures, etc.
-->2)Binaries generated with a toolchain using kernel headers newer
than the running kernel might work on if they don't use the
recent features, otherwise they will break.
--->3)Using the latest kernel headers is not necessary, unless access
to the new kernel features is needed
So in your case kernel version is "Linux version 2.6.20.7"
You can use kernel headers of Linux kernel version 2.6.20 or 2.6.21 from kernel.org.
does not create any problem in this case.
That should be fine if you're using the headers to build a libc
You should probably run make ARCH=arm headers_check beforehand too.
I wonder, are there any ways to generate with the gcc some native x86 code (which can be booted without any OS)?
Yes, the Linux kernel is compiled with GCC and runs in ring 0 on x86.
The question isn't well-formed. Certainly not all of the instructions needed to initialize a modern CPU from scratch can be emitted by gcc alone, you'll need to use some assembly for that. But that's sort of academic because modern CPUs don't actually document all this stuff and instead expect your hardware manufacturer to ship firmware to do it. After firmware initialization, a modern PC leaves you either in an old-style 16 bit 8086 environment ("legacy" BIOS) or a fairly clean 32 or 64 bit (depending on your specific hardware platform) environment called "EFI Boot Services".
Operations in EFI mode are all done using C function pointers, and you can indeed build for this environment using gcc. See the gummiboot boot loader for an excellent example of working with EFI.
Is it possible for gcc, installed on fedora 16, to cross compile for a different CPU, say SPARC?
I have build a certain understanding, need some expert to correct me if I am wrong. Different operating systems differ by the system calls they use to access the kernel or entirely by the kernel they use. IS THIS CORRECT? different kernels understands different systems calls for accessing underlying hardware. binaries or executables or programs are nothing but a bunch of system calls only. therefore every OS has its own executable. an executable meant to run to on windows wound not run on linux. by cross compiling the source code of any windown's executable we can generate executable for other OSs. word PLATFORM means operating system. POSIX are certain design standards for UNIX-like OSs.
we usually cross compile for different OSs. BUT can we cross compile for different hardware too? for example, in case of a microcontroller which does not have an OS?
No. You can't use native machine (x86) gcc for compiling program files for a different architecture. For that you require a cross-compiler-gcc that is specific to that processor architecture.
Your understanding about system calls for OS is correct. Each OS has its own set of system call which is been used by library. These libraries at the end will be translated into machine language for the processor.
Each Processor Architecture has its own set of instruction know as Instruction Set Architecture(ISA). So when a program written in high-level-language (like C) is compiled, it should be converted into machine language from its ISA. This job is done by the compiler(gcc). A compiler will be specific to only one processor architecture. For example gcc is for x86 processor. So if you want a compiler for different processor in you x86 machine you should go for a cross-compiler of that processor.
You would have to build such a version. That's part of the process of porting gcc to a new platform. You build a version that cross-compiles, then you cross-compile that version, then you test that version on the new platform, debug, rinse, and repeat.