I added meta-intel layer to build a hardware image.
After build ( bitbake xxxxxx ) I got output:
core-image-minimal-genericx86-64.wic
I dd copy this file to a USB, it can boot and login to yocto.
but it is EFI mode.
How to generate image to legacy mode?
Another problem, I found some machines can't boot ( no GRUB screen ) the same disk but some machines can.
Is it because the BIOS problem?
In this accepted solution they mention:
By default meta-intel .wic images only have an EFI bootloader, and
will not boot via legacy BIOS.
An hddimg will have both an EFI bootloader and the syslinux binaries
that let it boot from legacy BIOS.
So I guess one solution is to build an hddimage. Just change it in
IMAGE_FSTYPES = "wic"
for the one you need.
Old post, but hopefully it would help someone else.
Instead of using an hddimg, you can use a custom wks file and use the "bootimg-pcbios" source option.
In your local.conf
IMAGE_FSTYPES = "wic"
WKS_FILE = "custom.wks"
In custom.wks
part /boot --source bootimg-pcbios --ondisk sda --label boot --active --align 1024 --use-uuid
Related
I'm trying to enable boot in bios legacy mode with no success.
Just as test case I'm using an old Ubuntu server image (bionic-server-cloudimg-i386.img).
This what I did:
Under %simics%/simics-qsp-cpu-6.0.1/targets/qsp-x86 I modified qsp-client-core.simics file as below:
# In order to run this, the QSP-x86 (2096), QSP-CPU (8112) and
# QSP-Clear-Linux (4094) packages should be installed.
decl {
! Script that runs the Quick Start Platform (QSP) with a client processor core.
params from "%simics%/targets/qsp-x86/qsp-clear-linux.simics"
default cpu_comp_class = "x86-coffee-lake"
default num_cores = 4
default enable_efi = FALSE
}
$disk0_image="/home/peppe/Scrivania/bionic.craff"
#$disk0_image="/opt/simics/simics-qsp-clear-linux-6.0.9/targets/qsp-x86/images/cl-b28910-v2.craff"
run-command-file "%simics%/targets/qsp-x86/qsp-clear-linux.simics"
When I run this file, the boot gets stuck with "Start PXE over IPv4" message (i.e. Simics doesn't find the UEFI partition and try to boot from network).
If I run the same file with cl-b28910-v2.craff image all works fine.
Note when it comes to bionic image I tried both with the raw format and with the craff format.
Also note the same bionic image boots as expected in QEMU.
My question: is the param enable_efi = FALSE enough to force Simics to boot in legacy mode?
If no what else do I have to do ?
The QSP really only supports booting from UEFI, and only a UEFI binary is shipping with the platform. All modern operating systems boot from UEFI anyway, so this should not be a big deal.
Indeed QSP model is not shipped with legacy BIOS image, but this does not prevent you from creating such and enable it on QSP model yourself. In particular, microvm or regular bios.bin (SeaBIOS?) from QEMU might work with some changes (removing QEMU specifics).
I built a certain driver as module (m) for Linux, the spi-imx by NXP. Nontheless, Linux probes this driver when booting. I'm struggling to find out what process/other module/driver requests this spi-imx driver. A depmod does not show any dependencies between the spi-imx an other modules (except for the spidev as submodule).
After some research, I found out that Linux automatically (?) calls modprobe when it detects a new device. So does Linux actually call modprobe because the ecSPI'S status in the device tree as "okay"? If so, how can I prevent this? I would like to dynamically load the spi-imx from a user space application via modprobe. The story behind it: a coprocessor uses this SPI line in parallel to the Linux boot process. This interferes of course and interrupts the coprocessor's use of the SPI line. When the coprocessor has finished its transfer via SPI (a boot mechanism as well), it should hand over the SPI line to Linux.
I'm very thankful for any kind of tips, links, hints and comments on this.
Thanks a lot for the answers. As you guys mentioned, I also found out that Linux itself probes the device if present ("okay").
One possible solution is to complete cut off the modprobe call via an entry like "install spi-imx /bin/false" in the *.conf file. But that makes it impossible to load the driver via modprobe, for Linux and for user space.
"blacklist spi-imx" inside a *.conf located at /etc/modprobe.d/ is the way to prevent Linux from probing the driver when booting. After that, a modprobe from user space can successfully load the driver afterwards.
Thanks again & best regards
I am learning about u-boot and how this works in the Raspberry Pi system.
This is what I understood so far:
The first stage from the RPI cannot or should be modified. In this stage the BootROM simply loads the bootloader from the flash EEPROM.
In the second stage the EEPROM boot loader finds and loads start.elf, whose task is to load the kernel. It first reads "config.txt" which contains a kernel parameter. This is where u-boot is "injected".
kernel=u-boot.bin
U-boot can then in turn load the actual kernel. For a CM4 this would be "kernel7l.img".
I would be super satisfied with this knowledge, but in practice I have (possibly) seen other ways of integrating u-boot. I am here referring, for example, to Yocto recipes for the CM4 (meta-raspberrypi / u-boot). The boot directory of such an image contains: boot.scr, uboot.env, and uImage.
The readable part of boot.scr specifies that uImage will be loaded:
value bootargs /chosen bootargs
fatload mmc 0:1 ${kernel_addr_r} uImage
if test ! -e mmc 0:1 uboot.env; then saveenv; fi;
bootm ${kernel_addr_r} - ${fdt_addr}
config.txt does not contain a kernel parameter.
So here my questions for this boot process:
start.elf cannot be modified since it is proprietary. How can it load u-boot if there is no kernel parameter in config.txt pointing to a binary u-boot? boot.scr is supposed to run before u-boot.bin. Who reads and executes boot.scr?
is uImage just another name for u-boot.bin?
In this scheme how does u-boot know it must load "kernel7l.img"?
Are there other ways of integrating u-boot in a RaspberryPi? Is there any documentation which describes these different integration schemes?
Thank you very much for your help!
The boot.scr script is read by U-Boot.
fatload mmc 0:1 ${kernel_addr_r} uImage loads a kernel in deprecated U-Boot specific format which can be created with the mkimage command.
The bootm ${kernel_addr_r} - ${fdt_addr} command receives the addresses of uImage and the device tree. The address for the initrd is left out ('-'). bootm starts the kernel and passes the device tree address to it.
Adding kernel=u-boot.bin to config.txt is the correct way to invoke U-Boot on a Raspberry.
Distributions like Suse and Fedora prefer to boot Linux via GRUB on the Raspberry using U-Boot's bootefi command.
So here my questions for this boot process:
start.elf cannot be modified since it is proprietary. How can it load u-boot if there is no kernel parameter in config.txt pointing to a binary u-boot?
The kernel=... parameter in the config.txt is an optional parameter that specifies an alternate (kernel) filename to load by the EEPROM boot program.
The default filename to load from the boot partition depends on the RPI version.
According to RPi documentation, the default kernel filename on the Pi 1, Pi Zero, and Compute Module is kernel.img, on the Pi 2, Pi 3, and Compute Module 3 it is kernel7.img, and on the Pi4 it is kernel7l.img
If "there is no kernel parameter", then inspect the kernelx.img file; what are the contents?
boot.scr is supposed to run before u-boot.bin. Who reads and executes boot.scr?
Incorrect, boot.scr is not "run before u-boot.bin".
The file boot.scr contains script that can be interpreted by U-Boot.
(The executable image for U-Boot is the u-boot.bin file.)
is uImage just another name for u-boot.bin?
No, those are two distinct filenames with completely different uses.
The u-boot.bin file is the executable image for U-Boot.
A uImage file is a kernel image with the U-Boot wrapper for identification and verification. The U-Boot wrapper/header can be used for a variety of objects such a U-Boot script or a standalone executable besides a kernel image.
See Image vs zImage vs uImage
In this scheme how does u-boot know it must load "kernel7l.img"?
U-Boot does not have that directive (in this situation).
According to the boot.scr file that you posted, the booting sequence that U-Boot will perform is to load the uImage from the boot partition.
Are there other ways of integrating u-boot in a RaspberryPi? Is there any documentation which describes these different integration schemes?
As mentioned in your post and the other answer, an explicit kernel=u-boot.bin in the config.txt would be the obvious/preferred method to invoke U-Boot.
Otherwise, IDK. Today's alternative could be tomorrow's deprecated method.
I'm studying OS development and I use brokenthorn resource but with a little bit different tool, namely, I use CentOS, NASM and Qemu as a test/dev environment. I've been facing some issues while creating bootable img file with secondary loader.
I've got two files:
1. bootloader.bin which is first stage loader.
2. stage2.bin which is secondary loader.
In order to create bootable img file I do the following:
dd if=/dev/zero of=floppy.iso bs=1024 count=1440 -- Creating empty file
mkfs.vfat -F 12 floppy.iso --Creating file system in the file
dd if=../bin/bootloader.bin of=floppy.iso bs=512 count=1 conv=notrunc --Writing first loader to the boot sector
sudo mount -o loop floppy.iso /mnt/floppy/ -- Try to mount file system to write secondary loader using previously create FAT-12 files system.
In the last step I'm getting the following error:
mount: /dev/loop0 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
Can you please help me to understand what I'm doing wrong and what other ways I can use to accomplish creating bootable img with file system on board.
Thanks!
I once stumbled upon the similar problem and this answer may be of help to you.
However I would strongly recommend you switching to bootloader like Grub and spend time and effort developing the actual OS of yours. For that I would reccomend grub resque as it's simple to use and allows to to quickly create ISO that you can either burn or feed to virtual machine. Otherwise, you may just drown in all these minor things like enabling protected mode, loading your stages and so on.
I've recently been getting into bare metal development for the Raspberry Pi 2, and having some success. Admittedly I've hesitated to buy an actual physical device until I feel I can do something useful with it, for the time being I've been emulating the device using qemu 2.11.0.
So far I've developed multicore capabilities for my kernel, as well as simple Serial I/O, but I feel I'd like to get much further before working with a physical device.
My issue right now is that I'm trying to learn how to place my kernel onto an SD card image and boot qemu-system-arm from that SD card image, so I can properly emulate a kernel loaded from the raspberry pi 2 bootloader.
I've gotten as far as grabbing the SD card contents from https://github.com/raspberrypi/firmware ... aster/boot, and using the following script to create the image and load my kernel into it. I've seen that people have figured out how to load Raspbian from an emulated SD card, so I figure I can do the same.
#!/bin/bash
OUTPUT_IMG=os.img
OUTPUT_IMG_SIZE=40
TEMP_MOUNT_DIR="$(mktemp -d)"
# the SD card boot partition contents are in this folder...
OUTPUT_IMG_CONTENTS_DIR="./sd"
OS_DIR="${HOME}/os"
OS_BINARY="${OS_DIR}/kernel.bin"
dd if=/dev/null of=${OUTPUT_IMG} bs=1M seek=${OUTPUT_IMG_SIZE}
mkfs.fat -F 32 ${OUTPUT_IMG}
sudo mount -t vfat -o loop ${OUTPUT_IMG} ${TEMP_MOUNT_DIR}
make -C ${OS_DIR} clean
make -C ${OS_DIR}
sudo cp -r ${OUTPUT_IMG_CONTENTS_DIR} ${TEMP_MOUNT_DIR}
sudo cp ${OS_BINARY} "${TEMP_MOUNT_DIR}/kernel.img"
The only issue is that qemu doesn't seem to boot from this image using the following command:
qemu-system-arm -machine raspi2 -serial file:serial.log -sd ./dev/os.img
I've tried a few different combinations, but to no avail.
I can see from hooking GDB that the kernel is simply not booting from this card image. Loading the kernel directly into qemu with the -kernel argument works otherwise perfectly.
I was wondering if anyone here had any insight on how to accomplish this!
Any help here would be greatly appreciated!
Your command won't work because you haven't passed QEMU either a guest BIOS or a guest kernel to run. The QEMU arm boards aren't like the x86 PC machine, which always automatically runs a guest BIOS image. If you want to run a BIOS (probably UEFI?) you need to find a suitable BIOS blob and pass it to QEMU with the -bios argument. Then QEMU will run the BIOS code, which will hopefully include SD card drivers to load the kernel and so on off the SD card.
Just using -kernel is much simpler...
After doing a bit of reading and searching online, as well as a bit of help from other contributors such as Peter Maydell with his answer above, I think I've answered my own question. Unless I'm mistaken qemu-system-arm does not fully emulate the Raspberry Pi boot process, and instead just loads the kernel specified with the -kernel argument by loading the binary into the guest system's memory and jumping to the entry point. It doesn't look like any additional hardware bootloading is emualted for -M raspi2 unfortunately.
Can ARM qemu system emulator boot from card image without kernel param?
This question is similar and contains some more useful details on this issue, relating to qemu-system-arm as a whole..