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.
Related
Problem
I'm looking for a way to flash an ESP32 module's memory without installing the whole IDF software suite.
Why
Because I want to integrate ESP32 onto a custom board along with a low-performance ARM-powered CPU which runs a tiny Linux distro (based on Debian), and I want to flash ESP32 from this tiny Linux distro.
I know I could use the bootloader, but who will upload the initial bootloader? I don't want to do extra steps, so my idea is to embed the ESP32 module onto my custom board, and let the Linux to flash it from factory-state (when it's flash is empty, ie. no preloaded bootloader). Or is the serial bootloader always preinstalled on all ESP32 modules (like on ESP-WROOM-32)?
Why I don't want to use IDF? Because I don't want to build or debug anything, I just want to flash myprogram.bin onto ESP32. Also, as the board is low-performance, it would take ages to download everything for running IDF.
Current state
The ESP32 module is now visible via UART (RX,TX,GND), and if I held low the GPIO0, it runs the bootloader (my current module is embedded onto a NodeMCU - but there is no USB connected, this is raw UART!):
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
Could I expect the same behavior (controlling GPIO0 for running the bootloader) for all ESP32 modules, or this works just because guys at NodeMCU preprogrammed already some bootloader onto it?
I'm looking for a way to flash this ESP32 preferrably without any python script.
The ESP32 has a first-stage bootloader in ROM capable of writing to Flash - that's what's printing your output. You can talk to it if you know the protocol - this is implemented by the Python scripts in ESP IDF. If you don't want to use the official implementation because it's too heavy, you'll have to write your own implementation of this protocol which scratches your specific itch. Fortunately it's more or less documented and you can likely reverse engineer any missing knowledge from official Python scripts.
Actually Espressif also provides a nice and small binary for flashing ESPs:
https://github.com/espressif/esp-serial-flasher
Serial flasher component provides portable library for flashing Espressif SoCs (ESP32, ESP32-S2, ESP8266) from other host microcontroller. Espressif SoCs are normally programmed via serial interface (UART). Port layer for given host microcontroller has to be implemented, if not available.
One more (but very important) addition:
You have to modify this repo to make it work correctly, and also you might have to upload not just your binary, but also bootloader and partition_table.
I am trying to read the LDD book by Jonathan Corbet, Greg Kroah-Hartman, Alessandro Rubini and implement the sample modules. So to begin with, I tried setting up a development system. Installed Ubuntu 16.04 Xenial. Now, I just created a directory and wrote the hello_world module with a Makefile. Got it built and run it, verified the dmesg logs.
Is that all the development setup? I searched online and found articles where they are asking to download and compile the kernel, use a VM to boot the kernel. What is the reason? Or what am I missing?
Is there any better article which clarifies this?
Thanks
hago
You can try one more way:
If you have native windows, install virtual machine software such as
Virtual box. Get your favourite Linux distribution (no bias, just
an example - Ubuntu) and install it through Virtual box.
Get the latest kernel (or of your choice) from kernel.org.
Choose the platform you want to build this kernel for. E.g arm64 or x86.
In case you do not have real boards (e.g RPi for arm variant), you can use qemu-arm64 or qemu-x86 to run your compiled kernel. This is also a good option when users do not have the boards.
Another good use case for using qemu for the newbie kernel developers is even they write some modules which crashes, then the qemu instance is crashed so no harm.
I think using qemu is a good option for people who starts to learn kernel programming and also want to try writing some of their modules and do not intend to purchase hardware at this point of time.
It depends on your target. For your case, you have made a kernel driver for your computer (it run Linux kernel).
But if you want to develop a Kernel driver for another target like Rasberry Pi, ARM board, X86-X64 board, ... you must learn to compile, edit Kernel config, boot Kernel image, ... because each target has different kernel versions.
You can refer to this training for more detail: https://bootlin.com/training/embedded-linux/
I am trying to understand how a kernel boots. I am currently trying to port a new kernel to hTC Incredible S VIVO (s710e) device, but I cannot get it to boot. So, I looked into the device's original kernel, and looked through some documentation, and found out that the device uses ATAGs. Now, I have several questions that I cannot find a clear answer for:
What are ATAGs?
What are they used for?
How does the kernel boot using ATAGs?
Do ATAGs play a vital role in booting a kernel?
ATAGS are ARM tags. They are used to carry information such as memory size from boot code to kernel. Some references (which in turn lead to other references): booting standards, customized ATAG.
This reference arm/Booting explains theory, but does not much tell a user what to do.
On my target I use the following in my U-Boot config: CONFIG_CMDLINE_TAG, CONFIG_SETUP_MEMORY_TAGS, and these in my kernel config: CONFIG_ATAGS=y, CONFIG_USE_OF is not set. Not sure if that is sufficient for you but it gives you clues to search on, good luck.
ATAGS are not only arm-related, at all. Look into other archs head.S. They are special parameters to be passed to the kernel through some registers and pointers.
I'm having a bit of a hard time fully understanding how the kernel starts in linux. I'm a wince developer and our company decided to run with linux instead now.
We outsourced all of the board bringup and the package I recieved is quit a bit different for the prototype board we have compared to the nitrogen6x we have been using.
Before i start listing the differences for the distro we created, the kernels are identical. The distro we have been using is a busybox system. The one we recieved from the vendor is sysvinit. I removed mdev from busybox and we are only using udev.
when I use the kernel on our busybox build the touch screen drivers breaks, or doesn' run, or does something totally magical. I'm not quit sure... there is a /dev/input/event0 device which when run on the sysvinit side is a touch device.. Is the kernel not the mechanism that binds the built-in drivers to a device node? I thought udev was for more dynamic events in the system.
On the other hand I can't really tell whats been loaded on my device. Is there a way to list running drivers that were built into the kernel? my touch pad is up? This is a fairly simple process of looking at the registry on wince to see which devices were loaded.
I guess what I'm really trying to discover, isn't so much how to add a driver to the kernel, its how the whole thing gets is plumbed together. I've found plenty of documents on createing kernel modules, but i haven't found a good resource on how to pull everything together from scratch so you can actually use said modules. Going back to the example of the touchscreen driver, its built into the kernel, how does that get plugged into /dev/input/event0??
I'm kind of having a difficult time finding good resources mostly because searching google for varations of linux/drivers/device nodes/ piles in tons of random crap from everywhere.
What you probably want to use now is evtest. It will allow you to know what are the input devices that are present and ready to use on your system.
To get more information on the input subsystem and more generic information on how the kernel is working, I can direct you to our training materials. The materials are free to download, use and redistribute.
The general answer is, there is no single, easy place to look to discover what drivers have been loaded by the kernel if they are compiled in. Of course, lsmod will display any drivers that were dynamically loaded after kernel boot.
The kernel does not create device nodes. That is, to quote your question, the kernel does not "bind" the driver to the device node. The association between kernel driver and device node is contained in the major and minor numbers registered when the driver is initialized. You can have a device node on your file system for which there is no corresponding driver (common especially in older devices where device nodes were statically created on the file system) and you can also have a driver installed for which there is no device node.
Modern Linux distros have dynamically created device nodes created on a mount point called /dev and this is usually a tmpfs file system, meaning it is volatile - it gets destroyed on every boot and recreated dynamically on each new boot.
udev is the magic that creates most device nodes based on events that it receives from the kernel when a new device is discovered (this can be after boot on device plugin, like a USB disk) or on startup when udev reads the queued events and acts on them. As you noted, busybox has a limited udev implementation called mdev.
Study udev and you will get a much better understanding of the process. Hope this helps a little.
I have been fooling around with different versions of Multiple boot softwares, trying to create a USB pin with my favorite PC tools and a folder with ISO's for which to boot after a normal boot into DOS (or something).
But a lot of ISO's don't work correctly, or at all (ie. Windows boot CD's etc.), so I got a new idea:
Would it be possible to create a bootable MS-DOS USB pin, and then after having booted, trigger the normal booting sequences of a CD-rom from the DOS prompt?
Like this:
Turn on PC.
Hit key to get boot sequence menu (in my case F12).
Select "Boot from USB".
Let the USB boot into DOS (... or whatever else could be used for this purpose?).
From DOS prompt start "some program/script" to trigger a bootable CD in the normal optical drive, as if it had been triggered directly from the BIOS boot sequence menu.
(if this was possible, I would then proceed to add a menu with the option to start virtual CD-drive software and mount ISO files to my USB pin)
Thanks for any advice and/or ideas and thoughts!
Theoretically, you can use Int13h/AH=4Ch to start a CD-ROM boot from code running under the BIOS. However, I seem to remember reading that most BIOS implementations don't actually implement this part of the El Torito standard. (That was a long time ago, so perhaps you won't have this problem on a modern BIOS, although I wouldn't count on it.)
It is important to note that (in my experience) this is unlikely to work once you've booted an operating system. DOS doesn't change the CPU mode (provided you don't install any extended memory drivers) but it does change the system context in other ways - for example, IIRC, it hooks several of the BIOS interrupts. As a result once DOS is running you can't overwrite it (in order to boot another OS from a CD) without things falling over.
So, in order to make this work (a) you have to run your code in the bare BIOS, with no operating system present; and (b) you need a BIOS that implements the boot function properly. The first part is just a matter of getting the hang of bare assembly and the BIOS functions, but the second part is pretty much out of your control.