I am trying to develop an operating system. I have finished the Barebones tutorial from OSDev but still have some issues with multiboot.
As I understand, when I create a multiboot image following the tutorial, I have an ELF format binary file. This ELF executable is loaded into memory by QEMU when I specify the -kernel option. So I have a single executable program in memory and it has an entry point. It has some functions and libraries alongside it. There is nothing else in the memory. There is also no floppy or disk image from which I can read or write sectors. This is mainly because I haven't specified anything to QEMU in that regard.
However, what I want to achieve is after QEMU loads my ELF executable, I want to have a disk or floppy architecture from which I can read or write sectors. I also want to load some user programs from it or maybe set up a file system on it. So far, what I'm think is this:
qemu-system-i386 -kernel myKernel.bin -fda myDisk.image
Or maybe, I should take my myKernel.bin file, pad it with zeros until it is aligned to 512 bytes, then append the rest of the disk image to it.
My question is how can I achieve this functionality with QEMU. I need to know whether a task like this is possible before diving into writing a disk driver. If not possible, I can take a different approach but these are the ideas I have right now. I have already looked into -initrd and it isn't quite what I want. I also don't want to have any files loaded into the RAM by QEMU. Instead, I want to manipulate the disk image myself. Any suggestions on how to do that?
You don't need both a floppy image and a multiboot kernel, unless you've written some kind of loader. The -kernel flag works similarly to grub and it's much faster than loading from virtual media. This is how many linux kernel and driver devs test their code rather than creating a virtual media image every time.
Related
I have a custom bios ( I actually have the image of the SPI Flash Bios, but in my opinion it should be the same ) and I would like to debug with GDB. Is it possible to run with GDB ? I know where there is the first executed instruction ( 0h3FFFF0 ) inside the file, and the files it should be a sequence of assembler instruction. Is there a way to follow the flow and run step by step the bios ?
First, it's incorrect to assume that SPI image will contain only BIOS executable. It usually much more then that (ie. ME, Setup parameters, flash descriptor). To investigate what is inside your image I suggest to use binwalk <spi_image>, if you will be lucky, it will detect layout of your image. Then you can extract image parts by binwalk -e <spi_image>.
Second, since I don't know if we talk about modern hardware or some obsolete I will try to be general. I don't think GDB is able to run BIOS binary because those binaries doesn't contain any debugging information that GDB can understand. GDB need to know what executable file it deals with, what is the ABI used and what is the physical architecture of target being debugged. Even if it will know all those information the code could be only disassembled because BIOS starts with low level hardware initialization, which cannot be recreated in GDB. On the other hand modern hardware BIOS (UEFI firmware) is typically signed.
What is the best thing you can do with extracted BIOS binary is to get datasheet of your hardware and use disassembler like IDA Pro or radare2 to investigate code flow.
We have built a simple instruction set simulator for the sparc v8 processor. The model consists of a v8 processor, a main memory and a character input and a character output device. Currently I am able to run simple user-level programs on this simulator which are built using a cross compiler and placed in the modeled main memory directly.
I am trying to get a linux kernel to run on this simulator by building a simplest bootloader. (I'm considering uClinux which is made for mmu-less systems). The uncompressed kernel and the filesystem are both assumed to be present in the main memory itself, and all that my bootloader has to do is pass the relevant information to the kernel and make a jump to the start of the kernel code. I have no experience in OS development or porting linux.
I have the following questions :
What is this bare minimum information that a bootloader has to supply to the kernel ?
How to pass this information?
How to point the kernel to use my custom input/output devices?
There is some documentation available for porting linux to ARM boards, and from this documentation, it seems that the bootloader passes information about the size of RAM etc
via a data structure called ATAGS. How is it done in the case of a Sparc processor? I could not find much documentation for Sparc on the internet. There exists a linux bootloader for the Leon3 implementation of Sparc v8, but I could not find the specific information I was looking for in its code.
I will be grateful for any links that explain the bare minimum information to be passed to a kernel and how to pass it.
Thanks,
-neha
How does the uboot gets loaded for a particular embedded linux device? Is there a program inside the chip that searches for uboot inside the sd card or it is some another concept?
You just need to do a bit of Google-ing to find this out. Take a look at http://www.linuxjournal.com/content/handy-u-boot-trick for example. Yes, in short, the ROM knows how to read a FAT32 partition, typically, and loads and executes uboot.
What is the difference between them?
I know that u-boot needs a kernel in uImage format.
The system I use first boots from stage 1 loader and then it calls u-boot. I want to discard u-boot and directly boot from stage 1 loader. Which type of kernel image do I have to use?
What is the difference between them?
Image: the generic Linux kernel binary image file.
zImage: a compressed version of the Linux kernel image that is self-extracting.
uImage: an image file that has a U-Boot wrapper (installed by the mkimage utility) that includes the OS type and loader information.
A very common practice (e.g. the typical Linux kernel Makefile) is to use a zImage file. Since a zImage file is self-extracting (i.e. needs no external decompressors), the wrapper would indicate that this kernel is "not compressed" even though it actually is.
Note that the author/maintainer of U-Boot considers the (widespread) use of using a zImage inside a uImage questionable:
Actually it's pretty stupid to use a zImage inside an uImage. It is
much better to use normal (uncompressed) kernel image, compress it
using just gzip, and use this as poayload for mkimage. This way
U-Boot does the uncompresiong instead of including yet another
uncompressor with each kernel image.
(quoted from https://lists.yoctoproject.org/pipermail/yocto/2013-October/016778.html)
Which type of kernel image do I have to use?
You could choose whatever you want to program for.
For economy of storage, you should probably chose a compressed image over the uncompressed one.
Beware that executing the kernel (presumably the Linux kernel) involves more than just loading the kernel image into memory. Depending on the architecture (e.g. ARM) and the Linux kernel version (e.g. with or without DTB), there are registers and memory buffers that may have to be prepared for the kernel. In one instance there was also hardware initialization that U-Boot performed that had to be replicated.
ADDENDUM
I know that u-boot needs a kernel in uImage format.
That is accurate for all versions of U-Boot which only have the bootm command.
But more recent versions of U-Boot could also have the bootz command that can boot a zImage.
I read the tutorials to make a mimalistic custom kernel from here and am able to boot it up as explained in the tutorial over a virtual machine using GRUB as the boot loader.
I think it would be more fun if I could do the same over bare hardware using a bootable pendrive.
Q1. I thought of using the normal procedure of making a bootable linux pendrive, but my kernel isnt really an iso image, its an elf format executable. Will the normal method work if I somehow convert it to iso format ?
Q2. Any other ideas / link to some resource how I should proceed ?
P.S. : Its absolutely minimal kernel. Just boots up, prints something on console and can handle keyboard events, thats it.
You can't really "convert" a linux kernel to iso format, it needs a boot loader to do all the booting.
If using GRUB is not a requirement, using SYSLINUX (for booting from VFAT) or its sibling ISOLINUX (for booting from isos) are likely a lot easier: http://www.syslinux.org/
From my impression that's what most distributions use for their installer images.