I'm building a custom image that uses the meta-intel layer (I'm targeting Intel boards, such as the Minnowboard Turbot, for instance), and I want to tweak the options for booting.
First problem
As far as I understand, meta-intel uses systemd-boot (via rmc-boot) as EFI_PROVIDER.
So I should be able to override the specific BOOT_TIMEOUT parameter by setting :
SYSTEMD_BOOT_TIMEOUT := "0"
in my custom image, as far as I can see in this file
Unfortunately, that doesn't work (the boot timeout is still 4 seconds). How come ?
Second problem
As well, I would like to append options to the boot.conf file (in /boot/loader/entries, loaded by /boot/loader/loader.conf), such as quiet, or vt.global_cursor_default=0 for instance.
I see in the Intel machine conf that there is an APPEND configuration, but overriding it or appending to it in my custom image doesn't work (it's still not written in the boot.conf file) :
APPEND += "quiet vt.global_cursor_default=0"
I've checked that the configuration is correctly read and it's the case :
$ bitbake my-custom-image -e | grep ^APPEND= -A1 -B1
# " quiet rootwait console=ttyS0,115200 console=tty0${#bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs", " ro", "", d)}"
APPEND=" quiet vt.global_cursor_default=0 rootwait console=ttyS0,115200 console=tty0"
#
But no matter what I do, the command line doesn't change on the built image.
What do I miss ? There should be a relatively easy way to achieve what I'm after I guess, but so far I have not managed to do it.
Thanks a lot !
I have been looking at the kernel command line parameters for intel platform in Yocto with the meta-intel.
I have noticed differences between the wic and hddimg yocto images.
The hddimg seems to use the rmc boot entry definition whereas the wic image uses the boot entry defined in the wks kickstart.
My machine conf has the following :
WKS_FILE ?= "${#bb.utils.contains_any("EFI_PROVIDER", "systemd-boot rmc-boot", "systemd-bootdisk.wks", "mkefidisk.wks", d)}"
In turns systemd-bootdisk.wks has the following boot entry "boot" :
bootloader --ptable gpt --timeout=5 --append="rootwait rootfstype=ext4 console=ttyS0,115200 console=tty0"
The RMC definition for my Minnowboard Max has 2 entry a boot and an install.
Minnow Max B3 boot
Minnow Max B3 install
I am using the pyro release for Yocto. Perhaps integration of RMC boot definition has been integrated into the wic images.
I am looking for a common place to add the kernel command line parameter. Any idea ?
Related
i am struggeling since couple of hours to disable the psplash image in yocto to produce an image for raspberry pi.
I created a bbappend file to remove the splash files, but only the splash.sh was removed correctly, the result like psplash_write is still kept at /usr/bin
The yocto docu states to disable it we need to pass psplash = false to the kernel command line, but how can i pass it .
your help is appreciated, thank you
To disable psplash, reliably, you have to remove "splash" (not psplash) from IMAGE_FEATURES. I was able to remove the psplash on Raspberry Pi 4 and Xavier NX by adding below to my local.conf
IMAGE_FEATURES_remove += "splash"
More reading on this here https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-features-image
You need to modify your image and add:
IMAGE_FEATURE_remove = "psplash"
It will remove psplash from the default IMAGE_FEATURE variable.
i found the solution for raspberrypi, in case somebody searches in future
inside meta-raspberrypi/recipes-bsp/rpi-u-boot-scr/files/boot.cmd
there is one line to be added before the last line as follows:
setenv bootargs psplash=false
the full file is as follows:
fdt addr ${fdt_addr} && fdt get value bootargs /chosen bootargs
fatload mmc 0:1 ${kernel_addr_r} uImage
setenv bootargs psplash=false
bootm ${kernel_addr_r} - ${fdt_addr}
-> there is no need to add any psplash recipies, but there is a drawback, i get in the log umount: can't unmount /mnt/.psplash: Invalid argument, which is another problem from the psplash.sh script.
This error comes from the following patch :enter link description here
this error comes from existance of /usr/bin/psplash-write by removing it manually, the error vanish, but removing it with a recipe edit was not sucessful
I'm trying to write a script to run commands automatically at U-boot.
I followed the instructions on the website [1].
Below is what I did.
I compiled the script on the NVIDIA Jetson board and put the compiled file into /boot/setenv.img
Now when I reboot the board, load the script image with the command:
ext2load mmc 0:1 100000 /boot/setenv.img
I got the following output:
1096 bytes read in 403 ms (2 KiB/s)
Note that when I run command imi, it reports "Command not found" on Jetson board.
I run the loaded image with the command:
source 100000
It gives me the following output (error message):
\## Executing script at 00100000
Wrong image format for "source" command
My question is:
Why is the image format incorrect for the source command?
Is there any method that I can debug the error?
Any help or advice about how to debug the error is really appreciated!
[1] http://www.denx.de/wiki/view/DULG/UBootScripts
Thank you very much!
As sawdust noted, the iminfo would be helpful for debugging - so make sure that's compiled in to U-Boot. You can also manually check the header info using the md command. Keep in mind that mkimage doesn't compile anything - it simply prepends 64 bytes of metadata to the beginning of the file.
So, if you load the script into DDR at 0x100000, you can look at that location in memory by entering md 0x100000.
The first four lines of output are bytes 0x0 - 0x40 of the file (the 64-byte U-Boot header). If your header is there, you should see something like this:
00100000: 56190527 030b131f eb439a57 de0d0000 '..V....W.C.....
00100010: 00000000 00000000 fc6de331 00060205 ........1.m.....
00100020: 6f747541 616d492d 676e6967 72635320 Auto-Imaging Scr
00100030: 00747069 00000000 00000000 00000000 ipt.............
This header contains a magic number, CRC checksums (one for the file, one for the header itself), timestamp, filesize, name, and a few other things. All iminfo does is parse the header. Beyond those 64 bytes should just be your plaintext ASCII script.
The source command is looking for a header that was generated with the -t script flag in mkimage. The error message you're getting is printed when an image at that address has the wrong type.
For future readers, CONFIG_LEGACY_IMAGE_FORMAT=y is required to load the boot.scr script or else you will get following error message:
Wrong image format for "source" command
Also, when CONFIG_FIT_SIGNATURE is enabled, then the above flag is disabled. From the Kconfig:
WARNING: When relying on signed FIT images with a required signature
check the legacy image format is disabled by default, so that
unsigned images cannot be loaded. If a board needs the legacy image
format support in this case, enable it using
CONFIG_LEGACY_IMAGE_FORMAT.
I'm trying to get the current Debian 8.4 SD card image onto my Beaglebone Black's eMMC. The flashing itself worked flawlessly by enabling (uncommenting) this line in the /boot/uEnv.txt file:
cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
Flashing completed successfully with blinking LED's as described in the HowTo. Next, I connected a serial-USB cable to the J1 connector in order to see the boot process in Putty's serial console. The system starts to boot but then stops with an error message:
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
[line above repeats multiple times]
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mmcblk1p1 does not exist. Dropping to a shell!
I then get an (initramfs) prompt. From there, I figured out that mmcblk1p1 is not the right partition, it should be mmcblk0p1 instead. I think this is because of a different enumeration when the SD card is removed.
Now the big question: How and where can I set the partition the system starts from? It must be defined somewhere. I can mount the root partition mmcblk0p1 and edit files from the prompt, so I hope that there's just a small config file I need to tweak. Do I need to add something to the /boot/uEnv.txt file? (I already commented out the flasher script after flashing, of course).
Thanks for your help!
It should be as easy as editing uEnv.txt.
There should be a line containing: root=/dev/mmcblk1p1 - just edit that to say /dev/mmcblk0p1.
The current version of the flasher script (Dec 2019) changes the boot designation to eMMC automagically upon successful completion of the flash.
I'm doing get simple trace file from QEMU.
I followed instructions docs/tracing.txt
with this command "qemu-system-x86_64 -m 2G -trace events=/tmp/events ../qemu/test.img"
i'd like to get just simple trace file.
i've got trace-pid file, however, it dosen't have anything in it.
Build with the 'simple' trace backend:
./configure --enable-trace-backends=simple
make
Create a file with the events you want to trace:
echo bdrv_aio_readv > /tmp/events
echo bdrv_aio_writev >> /tmp/events
Run the virtual machine to produce a trace file:
qemu -trace events=/tmp/events ... # your normal QEMU invocation
Pretty-print the binary trace file:
./scripts/simpletrace.py trace-events trace-* # Override * with QEMU
i followd this instructions.
please somebody give me some advise for this situation.
THANKS!
I got same problem by following the same document.
https://fossies.org/linux/qemu/docs/tracing.txt
got nothing because
bdrv_aio_readv and bdrv_aio_writev was not enabled by default, at least the version I complied, was not enabled. you need to open trace-events under source directory, looking for some line without disabled, e.g. I using:
echo "load_file" > /tmp/events
Then start qemu,
after a guest started, I run
./scripts/simpletrace.py trace-events trace-Pid
I got
load_file 1474.156 pid=5249 name=kvmvapic.bin path=qemu-2.8.0-rc0/pc-bios/kvmvapic.bin
load_file 22437.571 pid=5249 name=vgabios-stdvga.bin path=qemu-2.8.0-rc0/pc-bios/vgabios-stdvga.bin
load_file 10034.465 pid=5249 name=efi-e1000.rom
you can also add -monitor stdio to qemu command line, after it started, you can the following command in qemu CLI:
(qemu) info trace-events
load_file : state 1
vm_state_notify : state 1
balloon_event : state 0
cpu_out : state 0
cpu_in : state 0
1 means enabled events.
Modify the trace-events file in the source tree
As of v2.9.0 you also have to remove the disable from the lines you want to enable there, e.g.:
-disable exec_tb(void *tb, uintptr_t pc) "tb:%p pc=0x%"PRIxPTR
+exec_tb(void *tb, uintptr_t pc) "tb:%p pc=0x%"PRIxPTR
and recompile.
Here is a minimal fully automated runnable example that boots Linux and produces traces: https://github.com/cirosantilli/linux-kernel-module-cheat
For example, I used the traces to count how many boot instructions Linux has: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/c7bbc6029af7f4fab0a23a380d1607df0b2a3701/count-boot-instructions.md
I have a lightly patched QEMU as a submodule, the key commit is: https://github.com/cirosantilli/qemu/commit/e583d175e4cdfb12b4812a259e45c679743b32ad
I am trying to find a way to reserve physical memory for a proprietary memory type hardware as early as possible after system boots up (Linux CentOs with Intel Xeon server platform).
I did the following at setup_arch() in arch/x86/kernel/setup.c and it works, but found out that I am not allowed to patch the kernel. The requirement is no BIOS and kernel mod.
setup_arch()
{
....
// Calls a proprietary function that returns custom proprietary memory module's starting address and size.
memblock_reserve(mem_start_addr, mem_size);
.....
}
I cannot use memmap=xx/xx either at Grub, because the start and size of the device is unknown (it has to be "discovered" by software)
Is there any way to do this?
One idea is to write a custom grub module and set memmap=xx using it.
The following is how to do it.
Note that following method only works above CentOS 7 since CentOS 6.x or below uses grub 0.9x .
In that case, you may have to modify code of grub 0.9x and replace /boot/grub/stage1 or /boot/grub/stage2
$ git clone git://git.savannah.gnu.org/grub.git
$ cd grub
$ git checkout grub-2.02-beta2 # CentOS 7 currently uses grub-2.02-beta
$ vim grub-core/Makefile.core.def # add following row
module = {
name = my_custom_module;
common = lib/my_custom_module.c;
};
$ vim grub-core/lib/my_custom_module.c # create following file
#include <grub/dl.h>
#include <grub/env.h>
GRUB_MOD_LICENSE ("GPLv3+");
GRUB_MOD_INIT(my_custom_module){
// Calls a proprietary function that returns custom proprietary memory module's starting address and size.
const char *mem_size = "123";
grub_env_set("my_memsize",mem_size);
}
GRUB_MOD_FINI(my_custom_module){
}
$ ./autogen.sh
$ ./configure
$ make
Now you can find that grub-core/my_custom_module.mod is created.
so copy it to /boot/grub2/i386-pc/ (or whatever your *.mod file exists)
Edit the grub.conf and add something like
insmod my_custom_module
linux /boot/vmlinuz-3.10.el7.x86_64 root=UUID=1a3b5c7d9 ro memmap=${my_memsize}