I'm writing a module that needs to read the MBR on the drive of the currently running kernel. But if I hard code /dev/sda it will read the wrong MBR if I install the module in /dev/sdb.
Is there a way to get the current drive path of the currently running kernel?
(I would use filp_open(), vfs_read() and filp_close() to read the first 512 bytes.)
There is no such thing. The kernel doesn't know where the bootloader that loaded it was itself loaded from. The bootloader might not have been loaded from a drive at all (eg. it could have been a PXE network boot, or loaded from ROM by coreboot), and the kernel might have been loaded by another kernel with kexec rather than from a bootloader.
You will need to have the user specify somehow what device to read the MBR from, perhaps with a module parameter.
Related
For context, I'm trying to make everything in flash as fault-tolerant as possible. Ideally, I'd like to just store the kernel image and initrd file as just BLOBs on MMC.
So as I understand, U-Boot looks for an extlinux.conf or boot.scr file, but as I said I'd rather not rely on the filesystem tables at all.
Would it be safe to just do everything in the main_loop function by just calling mmc read... to load in the kernel image, followed by the boot command? Do I need to do something with the initrd file too?
In short, yes, you would partition your MMC device such that you use mmc read ... to bring in the kernel, device tree, and if used by your system, initrd in to DDR and then use bootm to start the system. You'll also want to have the partition table on your device mark the area where you have the kernel, etc, as reserved in some manner.
I am trying to link my project for a custom embedded system where a RAM chip
is mounted at address 0x20000000.
I am changed my linker file to point data to this area and it compiles and maps the data properly as verified in map file.
But when I connect gdb to QEMU and try to load the executable it gives an error.
It seems as if, QEMU is protecting area below 0x40000000 as it is thinking area below this maybe used by some kernel?
If I change the address above 0x4XXX_XXXX for my RAM things work.
How to go about it?
It seems as if, QEMU is protecting area below 0x40000000 as it is
thinking area below this maybe used by some kernel?
Initial machine state in softmmu QEMU normally does not depend on the guest code. But the machine model that you use may not have physical memory at 0x20000000.
You can check that using gdb monitor info mtree command.
How to go about it?
You can add a model of your custom embedded system to QEMU and place physical memory at 0x20000000.
I want to write a simple bootloader for the Raspberry Pi. The main purpose of this bootloader is to enable a Raspberry Pi at a remote location, to recover from kernel updates that make the device unbootable as the result of a kernel panic. The procedure for updating the kernel should be like this:
The default Linux kernel is /boot/rpi-kernel.img and the string 'rpi-kernel.img' is written in /boot/default-kernel.txt. The kernel parameter 'panic=10' has been added to 'cmdline=' in /boot/config.txt.
Connect to the Raspberry Pi over SSH.
Copy /boot/rpi-kernel.img to /boot/rpi-kernel-fallback.img
Create empty file /boot/kernel_update
Download kernel update and move it to /boot/rpi-kernel.img
Reboot
This is the design for the bootloader I have thought up in pseudocode:
read kernel parameters passed from start.elf
if empty file '/boot/kernel_update' does not exists
boot kernel defined in '/boot/default-kernel.txt' with kernel parameters passed from start.elf
else
if empty file '/boot/boot_kernel_update' exists
write string 'rpi-kernel-fallback.img' to file '/boot/default-kernel.txt'
delete file '/boot/kernel_update'
delete file '/boot/boot_kernel_update'
create empty file '/boot/kernel_update_failed'
boot kernel 'rpi-kernel-fallback.img' with kernel parameters passed from start.elf
else
create empty file '/boot/boot_kernel_update'
boot kernel '/boot/rpi-kernel.img' with kernel parameters passed from start.elf
As a last step in the boot process, a shell script will check if the /boot/kernel_update exists and then if network is functional and the environment is sane, before removing /boot/kernel_update.
I want to make the bootloader as clean and simple as possible, with no support for HDMI, USB, Ethernet, serial etc. The problem is that I'm not sure how to get started with this.
The main challenges are to read from and write to the FAT32 filesystem on the SD card, and booting the Linux kernel. Everything has to happen from bare metal on the Raspberry Pi.
Any code examples, resources, suggestions ect. on doing this would be very helpful.
I have been given a general explanation of how a computer boots up.
However a very loose definition to the term 'boot file' was given.
Could someone explain 'boot file' to me in a very simple but concise manner?
I have read about the POST, the clearing of registers, BIOS in the CMOS, etc.
What I understand is that the boot file is different to the boot program.
the boot program gets the system ready to accept an OS while the boot file contains some of the parameters by which the system will operate.
The boot program is stored on ROM and the boot file isnt?
cheers,
jazz
It really depends on what they meant by "boot file".
First of all, there's the code in the first sector of the partition that locates the OS kernel, copies it into memory, and gets it running.
Then there's the file on disk that actually has the kernel code, including the stuff that controls the boot process once the boot sector stub has loaded it into memory.
Which one did you want to know about?
I have a CE 6.0 project on a PXA310 where I need to be able to download OS updates (nk.bin) via Wi-Fi and safely flash the new OS to my device. I'm open to other suggestions about how to do this, but I'm considering saving the nk.bin to my file system in NAND flash, then restarting and have the bootloader locate the file in the file system and flash it to the BINFS partition. Is this possible, and if so, can you give me an outline of what I'd need to do?
One caveat is that this needs to be very robust since the devices are deployed in the field and are not field serviceable. I need to be sure that if the OS flash fails (due to power failure, etc.) that upon reboot the bootloader can try again. That is why I'd like to store the downloaded image in persistent flash and avoid having to re-download the image.
Technically just about anything is possible. For this strategy what you would need is code for your bootloader to mount the NAND flash as a drive and have a FAT driver so that it can traverse that file system and find the image. That is a lot of work if you don't already have it.
THe other option is to just store it in flash outside of the file system in a known address location. That's a lot easier from the bootloader perspective as all you have to do is map to the address and copy. Of course it makes the writes more challenging because then you're doing it from the OS and you have to disable any other flash accesses completely while you do your write to prevent corruption by two threads sending flash commands to the chip at the same time.
In either case, if you have the space it's a good idea to store a "known-good" image elsewhere too, so that if the new image has a problem (fails a checksum or x number of load attempts fails) then you have a working OS that the bootloader can fall back to.
Clearly a lot depends on your hardware setup, but we've done this without making the Bootloader support the Flash Filesystem.
In our product, the OS image is loaded from Flash to execute from RAM -- I think most WinCE devices work this way nowadays. So to update the OS we use a special Flash driver which lets an application, running under WinCE, update the OS blocks in the Flash -- then all you need is a hard reboot and the Bootloader loads the new flash image into RAM in order to execute it. We've found this pretty reliable in the field (with some not-very-technical end-users!).
A special Flash driver was needed because the MS Flash Filesystem drivers have no access to the OS image sectors of the Flash, in order to prevent trashing the OS by accident.
You do need to load the NK.BIN into some memory which the OS programming application can read, normally the NAND Flash, but if you had enough RAM it could just go into the root of the filestore. However either way you can delete it when you've finished programming the OS sectors before the reboot so it's only a temporary requirement.