I have a project in mind and for that I require the kernel to boot up and bring me to a console window so that I can start working. [later I'll automate the process].
How do I accomplish it?
Well, I have downloaded the latest stable kernel source from kernel.org and I have tried editing the init/main.c file. But I have no idea what in the world was going on in that file [noob ^n].
Hence, I post this question for an answer.
I require the kernel to boot up and bring me to a console window so that I can start working.
The kernel doesn't do much by itself. In fact, it's unlikely you want to alter "main" in the kernel.
If you want to "run" the kernel, you'll also need a root filesystem and some user-space programs. If you want a minimal userland, you can use "busybox". Even better, buildroot will help you create a minimal userland + kernel.
You can even combine your root filesystem plus the kernel into a single binary. At runtime, it will uncompress userland into a ramdisk and run entirely from RAM. See initramfs. This is super-helpful for embedded systems. A minimal kernel+root filesystem can be around 1MB.
Go through below link
http://balau82.wordpress.com/2010/03/27/busybox-for-arm-on-qemu/
Just black screen after running Qemu
Related
The title really says it all, but just in case, here's some context:
Each time you change your configuration in NixOS, you need to run nixos rebuild to create a new boot image, which will be listed in Grub when you start the computer. A new configuration might require a new kernel. If it does, and you build it, will your old configurations continue to work?
In Ubuntu it appears that one can indeed host multiple kernels on the same machine. And I read somewhere the linux kernel can be pretty small, like 60 MB. Those two facts lead me to expect NixOS will retain the old kernels. But I haven't found anything online that really makes that explicit.
I am currently building a configuration that uses Musnix. If you ask for it, Musnix will build you a realtime kernel. I'm currently building such a new configuration, and hoping I'll still be able to boot my computer after it. I worry because GIthub user #magnetophon, who is involved in Musnix's development, said the Musnix realtime kernel is borken.
This is one of the cool features of NixOS. When you run nixos-rebuild boot (or nixos-rebuild switch too for that matter), it will create new boot entries alongside the old ones. These entries have the right kernel and system configuration in them. So if your experimental kernel doesn't work, you can just reboot and start a previous version of your system, knowing that it will work, even if your kernel also came with userland changes.
The nixos-rebuild command is documented here in the NixOS manual: https://nixos.org/nixos/manual/#sec-changing-config
I would like to boot an U-boot image from RAM using another U-boot. I loaded the U-boot image in the RAM using tftp tftp 0x90000000 u-boot.img and tried to run it with go 0x90000000 but nothing happens. I guess there are some conflicts concerning the initializations. When I went to the U-boot code, I found in the file /arch/arm/cpu/armv7/start.S the following comment do important init only if we don't start from memory!. So I have some questions.
First of all, is it possible to do that?
Any Idea of what are those important init?
And is there anything else I need to remove from the u-boot code?
I spent a couple of days trying to do the same thing in order to avoid the hassle of burning each new image version to flash, after all, if I have a working bootloader why not load a new version from it. I think this section of U-Boot documentation page explains perfectly why this not impossible.
If you want to start U-Boot from another boot loader, you must disable a lot of code, i. e. all initialization parts that already have been performed by this other boot loader...
The code you have to disable contains the most critical parts in U-Boot, i. e. these are the areas where 99% or more of all errors are located when you port U-Boot to a new hardware. In the result, your RAM image may work, but in the end you will need a full image to program the flash memory with it, and then you will have to enable all this highly critical and completely untested code.
I was wondering if there was any way that I could debug a floppy disk emulation in Linux.
The main thing I want to be able to do is to see the values of registers and custom defined bytes and words as the emulation runs.
Another thing I would like to be able to do is to run the emulation one step at a time, and see what line of code my emulation is currently on.
I am currently just running my floppy disk image under qemu-system-x86_64 and letting it run without any feedback besides the emulation.
If anyone can supply me with something along the lines of command line statements that accomplish this sort of thing, and what programs I could either move to or install alongside to help me out, it would be much appreciated.
I don't have enough idea of qemu because I haven't used it much. But from your requirement perspective, I think you should try bochs emulator. It's quite easy to use and comes with a built-in debugger. Only thing is, you need to compile it from source (if on Linux) making sure the --enable-debug and --enable-disasm switches are enabled (alongwith any other options you might want to enable). (On Windows however, the debugger comes as a pre-built (separate) executable in the installation, but that's sort of irrelevant in your case I guess.)
I wanted to build my own custom kernel with a different syscall table. (same syscalls but in different position/numbers)
I was working on kernel 3.2.29.
Changing the kernel was quite easy:
1) changing the syscall position in arch/x86/kernel/syscall_table_32.S
2) changing the syscall macro number in arch/x86/include/asm/unistd_32.h
3) compiling and installing the new kernel
I switched the syscalls around: sys_open took the place and number of sys_read, and vice versa.
I figured that if I compile glibc with the modified kernel headers, I could have a running system, but unfortunately, it wasn't enough and my system won't boot.
Am I missing something? What else do I need to do in order to have a running system?
The steps I have taken are:
1) building and installing the kernel as described in my question
2) extracting the new kernel headers using make headers_install INSTALL_HDR_PATH=[path]
3) building glibc with the parameter --with-headers=[path/include]
4) I used a live cd to access the file system externally in order to install the new glibc, using the make install install_root=[the original file system] (so the system won't break during the install)
I hope that the new glibc was built properly, but I am not sure.
After that, when booting the system, the boot stops in the (initrafms) shell screen:
I guess I need to rebuild the initrd, but how do I compile it according to the new syscall table?
You will have to rebuild everything. Even if all your binaries are dynamically linked, it is possible that the old syscalls were inlined into the binary because many of the C functions are just return syscall(__NR_somecall,...).
You could do this manually, but it could be difficult to keep the toolchains straight unless you use a cross compilable toolchain like buildroot, aboriginal or similar. Pick whichever best suits you (I prefer Rob Landley's aboriginal - http://landley.net/aboriginal/ )
Then to make your initrd just expand the old one using {z,bz,xz}cat oldinit.rd |cpio -id; rm oldinit.rd. Replace the old kernel modules, libs and binaries with the new and cpio and compress it back (cpio needs the -H newc option) ... or now you can rebuild your kernel and point the initramfs to that directory, but wouldn't recommend that if your initrd may need changed frequently such as if for instance you were testing out a whole new syscall structure and having to debug a lot.
Scrambling the system call numbers is really going to hurt. You'll at least need to rebuild all of the statically linked binaries on your system and your initrd (if you use one).
You haven't said at what point the boot fails, but even if the kernel comes up it is likely that the critical programs contained in the initrd compressed ramdisk would fail because they have the original syscall numbers hard-coded. You will need to rebuild and repackage those as well.
You might consider first replacing init with a static hello-world type of program to verify that your kernel can support a userspace at all; then look into the details of making all the complexity of a modern linux userspace match.
you had to learn to reading the messsage of pansic dump and show us what kenrel panic. Without this information, people can hardly help you or provide you useful suggestion.
hi :
i was building kernel for my gentoo linux . when i start the kernel , i
got this message , and can't going on.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
non-volatile memory driver v1.3
i don't know how to solve this problem . and i need help . thanks .
Why don't you try to disable pci hotplug support in kernel (if I recall correctly is in main config menu / PCI support)? You probably don't need this.
I'm going to have to disagree with those voting to close, because I think there really is a question here, and the question is "How to debug this?"
I'm going to propose two approaches:
1) Studious approach: Learn about mechanisms intended for handling boot problems. See if you can increase the kernel debug message level. Disable un-needed drivers as Quizzo suggested.
2) Cowboy approach: grep the kernel sources for strings seen in the final messages, and start shotgunning all possibly relevant bits of code with your own "still alive at" printk messages. Once you know where it's hanging, figure out why and either remove that mechanism or fix it.
At an extreme there's also a tool for debugging the kernel - kgdb - which you could set up if you have a second machine available.
If you already have linux running on this box, see if there's a config.gz in /proc or in a boot folder which you can extract and compare to the configuration you are trying to compile. It might not be a bad idea to first recompile and test exactly the same version and configuration as you have running, and then make desired changes one by one.
Also you might see if there's odd hardware in your system you could temporarily remove. For example, an older PC I have has a bios that hangs during drive enumeration if I have a large USB external drive plugged in during boot.
i have solved the problem by enable all pci hotplug flag in kernel config file.
thinks all.