Is it possible to compile some Linux Kernel and run it over QEMU, emulating some Big Endian ARM processor?
If QEMU is not capable of that, I'd love to hear about other system emulators than can.
My basic goal is to run and debug dedicated Big Endian ELFs in as much as possible native environment.
Every close solution or idea would help!
QEMU has support for big-endian ARM CPUs, but it does not currently have support for emulation of any specific machines (boards) which have big-endian ARM CPUs in them. ARM Linux kernels will generally only run on the hardware they're compiled for, so you can't just take a random big-endian ARM Linux kernel and run it on anything -- you'd need to model the hardware the kernel wanted to see first.
The underlying reason for this is that big-endian ARM systems are very rare -- almost everybody runs ARM CPUs in little-endian mode, and all the boards QEMU models today are little-endian.
Related
I am trying to fuzz a part of code written for big endian MIPS architecture using libfuzzer.
I have run libfuzzer under a Debian little endian machine and segmentation faults are issued. I think that the results are not a 100% trustworthy. How to use libfuzzer with an emulator for big endian architectures? Is this possible? Are there any other techniques for testing big endian code in little endian architectures by using fuzzing?
You could cross-compile your software to big-endian MIPS on your host machine, and then use QEMU user-mode emulation. In this mode, QEMU runs a single process on the emulated CPU, eliminating all the emulated hardware. Instead, it merely translates system calls to the host kernel, so the process accesses all the host files, networks, etc. -- just like if your host CPU would get the ability to execute MIPS instructions -- it now can mess with your host files etc. too, you have been warned. :)
I'm not familiar with specifically libfuzzer, but this setup should suffice to at least validate already found crashes (supposing one can trust that QEMU simulates MIPS CPU realistically enough). AFAIK libfuzzer is an in-process fuzzer, so unlike AFL, the fuzzed process should not face some problems with communicating to the separate fuzzer process using shared memory, etc.
I'm trying to boot a kernel (extracted from a firmware) using QEMU.
Qemu emulation seems to start at 0x0.
The problem is that the memory from 0x0 to 0x04000000 is only filled with 0.
How can i debug the bootloader?
You don't say what your command line is. The address where QEMU starts execution depends on many things:
the guest CPU architecture
which board model you are emulating
whether you passed QEMU a BIOS image file
the file format of any file passed to -kernel (ELF, plain kernel image, uImage, etc)
In general, though, you should not expect to be able to pull a random kernel image out of a firmware dump for a piece of Arm hardware and run it under QEMU. This is because every Arm board or machine is different -- RAM may be in different places, the devices such as the serial port are at different addresses, and so on -- and the kernel will only boot on systems which it has been compiled to support. The chances are very high that (a) QEMU does not have a specific emulation of the bit of hardware that the firmware dump is for and (b) the kernel from the firmware has not been built to also run on any of the board types that QEMU does support. So it will almost certainly simply crash very early on in bootup without producing any output.
If you want to debug what's going on in early bootup, the best approach is probably to use QEMU's built in gdbstub, and attach a guest-architecture-aware gdb to it. You may also find QEMU's internal logging via the '-d' option useful, though it requires some familiarity with how QEMU works to make sense of the output.
I have experience with Cortex-M controllers (LPC series from NXP) and Keil.
I want to move for cortex-A because my logic needs some better speed.
I found from internet that these processors will come with linux in it.
How can i use my code directly rather than using linux??
I don't need IO pins.
Where should i start?? What IDE should i use??
And i found debugging of Cortex-A controllers is tough because it is involving OS. is it true?
And is there any way without going for cortex A but achieving higher speeds (around Giga Hz)
By Cortex-M series, I suppose you have experience with M0 and M3. Right?
If you plan on using A-Series, you should know that they are more designed to run operating systems (than M-Series). (For example they have virtual memory management units...) That's why you may not find much bare-metal programming guides with these processors.
Also, these devices don't usually have on-board ROMs. So, you don't have an embedded flash... Therefore, you basically use an SD-Card or eMMC to boot them.
You may use Linux (Easier for you but won't be real-time), or an RTOS (also easier). If that doesn't suit you, you may use "UBoot" from SD-Card or eMMC and do a couple non-trivial steps (dependent on architecture) to run your bare-metal software (which is loaded from SD-Card or eMMC).
I suggest you buy a beagle bone and start from there.
You can still use Cortex-A for normal bare metal application adn with this way you will have something similair to what to what you had with application running on cortex-m
However it really depends from what you want:
if you want to understand how cortex-a is working or you are bringing
up a custom platform which is not that stable so bare metal coding is
your answer and with it you will be able learn a lot bout cortex-a
functionality
If you want to use Cortex-A from user point of view so you need to
compile your linux kernel for your cortex-a based board and start
using developing on top of your running kernel
In the case of x86 the same (real mode) bootloader works on virtually any x86 device.
Is that possible on ARM or do I need to create a specific bootloader for each 'cortex'?
x86 or lets say PC compatible systems are ... pc compatible. They support the ancient bios calls so that there is massive compatibility. by design, by the chip vendor (intel) the software vendors (bios, operating system) and the motherboard vendors.
ARM is in now way shape or form like that. There are instruction sets you can choose that work almost or all the way across, but remember ARM systems you buy an ARM core and add it to your special chip, you and your special/custom stuff, then that is put on one or more different boards. There is little to no compatibility. Instruction set and arm core is a small part of the whole picture most of the code is for the non-arm stuff.
u-boot and perhaps others are fairly massive bootloaders, pretty much an operating system themselves, and have to be ported just like an operating system to each chip/board combination. The chip vendor, if this is a linux compatible system, most likely has a reference design and a BSP including a u-boot port and/or some other solution (rasberry pi is a good example). it is fairly trivial to boot linux or used to be, there is no reason for the massively overcomplicated u-boot. without a DTB you setup a few memory locations a register or two and branch to the kernel, thats it (again look at the raspberry pi), I assume with DTB you build the dtb then put it somewhere, setup a few registers and branch to the linux kernel (raspberry pi? ntc chip?)
There is a Arm open source project that can cover Armv7/v8 Cortex-A processors bootloaders.
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
Another open source project for Cortex-M processors:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/
Which kernel config file is best to use ( and eventually modify ) for FreeBSD for arm versatile Cortex A9 platform ( vexpress-a9 in qemu ).
I need to compile and run kernel with SMP support.
It's intended to be run under qemu this way
qemu-system-arm -M vexpress-a9 -smp cores=4 (...other params...)
FreeBSD/arm and FreeBSD/armv6 support a large range of ARM CPUs and development boards. Not every peripheral is supported on every CPU or board, though work continues towards this and contributions are always welcome. Conversely, many CPUs and boards not listed may work with only minimal changes needed.
Listing all supported devices on all CPUs and boards is impractical here, however much information can be obtained from the mailing list and archives, the FreeBSD/arm Wiki pages, and also from the Kernel Configuration files
PS:
Versatile Express support in QEMU