I'm trying to add a switch to send linux kernel log to the serial console on XenServer6.
The kernel command options can be edited on the EXTLinux config file ( /boot/extlinux.conf ).
Here is an excerpt:
serial 1 115200
default xe
prompt 1
timeout 50
label xe
# XenServer
kernel mboot.c32
append /boot/xen.gz mem=1024G dom0_max_vcpus=4 dom0_mem=752M lowmem_emergency_pool=1M crashkernel=64M#32M console= vga=mode-0x0311 --- /boot/vmlinuz-2.6-xen root=LABEL=root-tfnnfzfp ro xencons=hvc com2=115200,8n1 console=com2 console=hvc0 console=tty0 quiet vga=785 splash --- /boot/initrd-2.6-xen.img
label xe-serial
# XenServer (Serial)
kernel mboot.c32
append /boot/xen.gz com1=115200,8n1 console=com1,vga mem=1024G dom0_max_vcpus=4 dom0_mem=752M lowmem_emergency_pool=1M crashkernel=64M#32M --- /boot/vmlinuz-2.6-xen root=LABEL=root-tfnnfzfp ro console=tty0 xencons=hvc console=hvc0 --- /boot/initrd-2.6-xen.img
What is the meaning of the triple dashes ( --- )on the command line?
Is it loading 3 boot files?
TL;DR Yes, it is. ExtLinux must load both Xen and the Linux kernel. It uses mboot.c32 to do this. --- separates the Xen image path and its command line from the Linux image path and its command line.
This is just the way that ExtLinux (indeed, all boot loaders in the SysLinux family) implement multiboot, which is necessary to load Xen.
Most simple boot configurations will load just a kernel. There's a way that the boot loader writes the command line where you would expect it. In Syslinux style:
label Simple
kernel linux.c32
append <linux kernel filename> <linux command line>
Or in Grub:
title Simple Boot
root (hd0,0)
kernel <linux kernel filename> <linux command line>
More complex boot configurations might load boot Xen and the kernel. These use a system called "multiboot", which loads both and gives them each their own command line. That allows you to pass Xen its commands and Linux its commands. You can even pass in another stage to load something else, like an initial ramdisk. In SysLinux style:
label Complex
kernel mboot.32
append <xen kernel filename> <xen command line> --- <linux kernel filename> <kernel command line> --- <initrd filename>
Or in Grub:
label Complex Boot
kernel <xen kernel filename> <xen command line>
module <linux kernel filename> <linux command line>
module <initrd filename>
If you were using grub, it actually specifies these in their own stanzas. Grub acts as sort of a super-bootloader in that it can have tons of little modules loaded into it for functionality such as multiboot (or different filesystems, etc). In that case, Grub does most of it magically without you knowing.
Syslinux and family divide labor differently. Rather than having one giant boot loader that must handle all situations, they have two layers that have many different pieces. On the top, they have the core boot loader that knows the system its booting (i.e. syslinux knows BIOS booting with files on FAT filesystem, pxelinux knows loading things over then network, isolinux knows loading files from a CD-ROM, etc.). Extlinux is just the one that knows how to boot off of an Ext2, Ext3, Ext4, or BTRFS filesystem.
Other common functionality is implemented as "comboot" modules, which can plug into any of the boot loaders. For example:
multiboot (mboot.c32)
directly loading a Linux kernel (linux.c32)
menu support (menu.c32)
Lua Interpreter (lua.c32)
hardware detection tool (hdt.c32)
alternate boot based on CPU flags (ifcpu.c32)
In the case of multiboot, they load the mboot.c32 module, which implements multiboot. Unlike Grub and family (which know about the multiple command lines), syslinux must include all of the modules and their commandlines in a single commandline. Since -- is often used as an argument separator in other programs, they chose to use --- to delimit the modules.
In this case, Xen requires multiboot, which is requiring that syntax to separate the command lines for the Xen Hypervisor Kernel and the Linux Kernel that runs as its initial privileged guest.
Related
I want to make my own protocol driver for my custom made spi board. The platform on which I want to attach it is a raspberry Pi4 with arm32. I want to load it dynamically with an overlay device tree.
I can build the driver file but the following isn't clear:
Where should the driver exactly placed? I tried /lib/modules/5.4.79-v7, /lib/modules/5.4.79-v7/build
I made in the config.txt an entry dtoverlays= driver.ko and placed the dtbo under /boot/overlays. Is this correct?
Can the driver be loaded at runtime without a second reboot after I placed the overlay file in the right folder.
Is the driver first loaded if the function "spi_new_device" is called or can it be done in this way?
If I call sudo insmod .ko the driver is loaded with:
rpi4: loading out-of-tree module taints kernel.
The probe function isn't called yet.
Where should the driver exactly placed? I tried /lib/modules/5.4.79-v7, /lib/modules/5.4.79-v7/build
Answer: The driver is placed under /lib/modules/5.4.79-v7/extra if it is an extra module and build with.
make -C /lib/modules/`uname -r`/build M=$PWD modules_install
I made in the config.txt an entry dtoverlays= driver.ko and placed the dtbo under /boot/overlays. Is this correct?
Answer: It can be done in this way with rpi.
Can the driver be loaded at runtime without a second reboot after I placed the overlay file in the right folder.
Answer: If the driver is installed under extra it is not loaded. Also it is not loaded after reboot. The driver must be loaded with "modprobe" but without the extension ".ko". Modprobe search the driver under lib/modules.
I'm doing a university project on QNX RTOS (using an academic license). I'm following Building a BSP.
So far I've managed to build (using bios_mkusbimage script in the BSP archive) .img file for x86_64 target. Then I converted .img to .vdi file (VBoxManage convertdd input.img output.vdi) and finally loaded it. The result is:
Or, as text:
Loading IFS...decompressing...done
System page at phys:000000000010c000 user:ffff808000003000 kern 808000006000
Starting next program at vffff80000007388b MFLAGS=1 .11 ClockCycles offsets within tolerance elcome to Q. Neutrino SDP 7.0 on x8664 system
Starting slogger2 server ...
Starting PCI server ...
Set PCI device list ...
Starting EIDE block driver ...
unable to access /dev/hd0t179 'ot3Tt11:7.n:nele7i7la:TensleieCted
Starting USD host ...
Starting devb-umass o audio device has been detected
Starting input services ...
Starting serial driver ...
Starting consoles ...
Starting shells ...
#
The OS seems to boot successfully, but I'm unable to type anything.
I'm looking either for a way to fix the keyboard input, or get a SSH/telnet/... connection to the QNX shell.
I am working on microzed 7010 board, I have manualy compiled kernel, u-boot, fsbl, and .bit (vivado). Board is booting well with all setup (without using petalinux). But i have noticed that kernel is not Uncompressing kernel... with zImage nor uImage. whereas i can see bootlogs with that of petalinux's images.
INPUT :
1 . zImage env is
zImage=tftpboot 0x3000000 zImage && tftpboot 0x2A00000 system.dtb && bootz 0x3000000 - 0x2A00000
2 . Boot log is =>
Zynq> run zImage
[2017-10-25 15:57:11
ethernet#e000b000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
[2017-10-25 15:57:15
Zynq> run zImage
[2017-10-25 15:57:22
Using ethernet#e000b000 device
TFTP from server 172.16.9.187; our IP address is 172.16.9.25
Filename 'zImage'.
Load address: 0x3000000
Loading:#####################################################################################################################################################################################################################################
3.9 MiB/s
done
Bytes transferred = 3913840 (3bb870 hex)
Using ethernet#e000b000 device
TFTP from server 172.16.9.187; our IP address is 172.16.9.25
Filename 'system.dtb'.
Load address: 0x2a00000
Loading: #
3.3 MiB/s
done
Bytes transferred = 13644 (354c hex)
Kernel image # 0x3000000 [ 0x000000 - 0x3bb870 ]
## Flattened Device Tree blob at 02a00000
Booting using the fdt blob at 0x2a00000
Loading Device Tree to 1fff9000, end 1ffff54b ... OK
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 4.6.0-xilinx-00003-g2762bc9 (pritam#pritam) (gcc version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-2) ) #3 SMP PREEMPT Wed Oct 25 10:28:387
[2017-10-25 15:57:24
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
3 . In u-boot I have given bootz support
4 . uImage is formed by
mkimage -A arm -O linux -T kernel -C none -a 0x10000000 -e 0x10000000 -n "Linux kernel" -d arch/arm/boot/zImage uImage
What causing it not to uncompress kernel ? Is u-boot compressing the kernel and booting ?
Any help will be appreciated.
Thanks and regards,
Pritam
Board is booting well with all setup (without using petalinux). But i have noticed that kernel is not Uncompressing kernel... with zImage nor uImage.
Some kernels can perform this step silently. The fact that you load a zImage (or a zImage in a uImage), and then see the Linux kernel version line means that the kernel has been uncompressed successfully and is executing
What causing it not to uncompress kernel ?
Your presumption that the kernel is not being uncompressed is simply wrong.
The zImage or uImage files that you are using are compressed kernel images. Since the kernel is actually executing (as evidenced by the boot log that you posted), the kernel must have silently uncompressed and proceeded to boot.
If the kernel did not uncompress (as you assert), then the kernel could not boot successfully (as you reported).
Is u-boot compressing the kernel and booting ?
No, U-Boot is not involved in uncompressing a zImage file.
A zImage is a self-extracting compressed Image file.
Depending on how the kernel was configured, the uncompression of the zImage file can be silent or verbose.
I have cloned the source codes from petalinux downloads. The boot logs, I got from images built by petalinux, shows Uncompressing kernel .... message. " Starting kernel ... Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0x0 Linux version 4.6.0-xilinx (pritam#pritam) (gcc version 5.2.1" So i am expecting it to show "uncompressing kernel " message
Using the same source code is only one requisite for building a duplicate kernel.
You also need to build with the same configuration.
The silent or verbose uncompression is selected by kernel configuration.
From arch/arm/Kconfig.debug:
menu "Kernel hacking"
...
config DEBUG_LL
bool "Kernel low-level debugging functions (read help!)"
depends on DEBUG_KERNEL
help
Say Y here to include definitions of printascii, printch, printhex
in the kernel. This is helpful if you are debugging code that
executes before the console is initialized.
Note that selecting this option will limit the kernel to a single
UART definition, as specified below. Attempting to boot the kernel
image on a different platform *will not work*, so this option should
not be enabled for kernels that are intended to be portable.
...
prompt "Kernel low-level debugging port"
...
config DEBUG_ZYNQ_UART0
bool "Kernel low-level debugging on Xilinx Zynq using UART0"
depends on ARCH_ZYNQ
help
Say Y here if you want the debug print routines to direct
their output to UART0 on the Zynq platform.
config DEBUG_ZYNQ_UART1
bool "Kernel low-level debugging on Xilinx Zynq using UART1"
depends on ARCH_ZYNQ
help
Say Y here if you want the debug print routines to direct
their output to UART1 on the Zynq platform.
If you expect a verbose uncompression, then you need to select CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_LL, and an appropriate serial port.
ADDENDUM (response to comment)
Which one is better way to compress the kernel. zImage or gzipping arch/arm/Image ... are they same ... ???
What metric are you going to use to measure "better"?
In the end, the result is the same: a compressed kernel Image.
How many of these image files to you have to save?
How crucial is saving space and load times (if any) versus self-extraction?
In mkimage if I specified -C "gzip", I noticed that at time of loading image in ram, u-boot uncompresses the gzipped image ... !!!
As I already commented, that is a mislabeling of a zImage file, and therefore wrong. The zImage is self-extracting, and should be labeled as "uncompressed" so that U-Boot does not try to perform uncompression.
Interestingly I cannot duplicate your claim at the shell prompt. A zImage renamed to zImage.gz cannot be gunzip'd:
gzip: zImage.gz: not in gzip format.
More importantly, I cannot replicate the results that you claim you got.
=> bootm 20080000 - 22000000
## Booting kernel from Legacy Image at 20080000 ...
Image Name: Linux kernel
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 5774280 Bytes = 5.5 MiB
Load Address: 20008000
Entry Point: 20008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 22000000
Booting using the fdt blob at 0x22000000
Uncompressing Kernel Image ... Error: Bad gzipped data
gzip compressed: uncompress error -1
Must RESET board to recover
resetting ...
Does u-boot contains external decompresser ... ???
If you had bothered to read the link I had provided previously, the answer would be obvious.
U-Boot can be configured to have gzip, bzip2, lzma, and lzo compression algorithms.
However the Linux kernel supports compressing the Image file using gzip, lzo, lzma, xz, and lz4 compression algorithms, that is, a wider selection of size versus time tradeoffs.
Which one better compression method whether in u-boot or kernel (zImage).
Again, what metric are you going to use to measure "better"?
Of course Wolfgang Denk has his opinion.
Plz explain me with actual example (If any h/w requirement) ... !!!
Example of what?
I've already answered your question, and explained how you can configure your kernel to get the expected message.
The issue was with specifying the compression type "-C" as none.
mkimage -A arm -O linux -T kernel **-C none** -a 0x10000000 -e 0x10000000 -n "Linux kernel" -d arch/arm/boot/zImage uImage
So I tried with vmlinux. and converted it to gzip
mkimage -A arm -O linux -T kernel **-C gzip** -a 0x10008000 -e 0x10008000 -n 'Test' -d vmlinux.bin.gz uImage.
So I have noticed size of both images .
first one is of vmlinux and another of zImage
So please correct me if i am misunderstood .
I am trying to use GDB to debug a Linux kernel zImage before it is decompressed. The kernel is running on an ARM target and I have a JTAG debugger connected to it with a GDB server stub. The target has to load a boot loader. The boot loader reads the kernel image from flash and puts it in RAM at 0x20008000, then branches to that location.
I have started GDB and connected to the remote target, then I use GDB's add-symbol-file command like so:
add-symbol-file arch/arm/boot/compressed/vmlinux 0x20008000 -readnow
When I set a breakpoint for that address, it does trap at the correct place - right when it branches to the kernel. However, GDB shows the wrong line from the source of arch/arm/boot/compressed/head.S. It's 4 lines behind. How can I fix this?
I also have tried adding the -s section addr option to add-symbol-file with -s .start 0x20008000; this results in exactly the same problem.
There are assembler macros that print out stuff when compiling with low level debug. You have to make sure the macros are appropriate for your board.
linux-latest/arch/arm$ find . -name debug-macro.S | wc
56 56 2306
Find the file for your board and ensure the correct serial port registers are hit. You can instrument the code with out using JTAG. These macros are used in the decompress code. Of course configure with *CONFIG_DEBUG_LL*.
Most likely the ATAGs are not correct or one of the other requirements. Checkout Documentation/arm/Booting to make sure you have registers set properly. Note there is a new requirement with recent kernels to send a dt list.
I'm compiling a custom kernel under Ubuntu and I'm running into the problem that my kernel doesn't seem to know where to look for firmware. Under Ubuntu 8.04, firmware is tied to kernel version the same way driver modules are. For example, kernel 2.6.24-24-generic stores its kernel modules in:
/lib/modules/2.6.24-24-generic
and its firmware in:
/lib/firmware/2.6.24-24-generic
When I compile the 2.6.24-24-generic Ubuntu kernel according the "Alternate Build Method: The Old-Fashioned Debian Way" I get the appropriate modules directory and all my devices work except those requiring firmware such as my Intel wireless card (ipw2200 module).
The kernel log shows for example that when ipw2200 tries to load the firmware the kernel subsystem controlling the loading of firmware is unable to locate it:
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2
errno-base.h defines this as:
#define ENOENT 2 /* No such file or directory */
(The function returning ENOENT puts a minus in front of it.)
I tried creating a symlink in /lib/firmware where my kernel's name pointed to the 2.6.24-24-generic directory, however this resulted in the same error. This firmware is non-GPL, provided by Intel and packed by Ubuntu. I don't believe it has any actual tie to a particular kernel version. cmp shows that the versions in the various directories are identical.
So how does the kernel know where to look for firmware?
Update
I found this solution to the exact problem I'm having, however it no longer works as Ubuntu has eliminated /etc/hotplug.d and no longer stores its firmware in /usr/lib/hotplug/firmware.
Update2
Some more research turned up some more answers. Up until version 92 of udev, the program firmware_helper was the way firmware got loaded. Starting with udev 93 this program was replaced with a script named firmware.sh providing identical functionality as far as I can tell. Both of these hardcode the firmware path to /lib/firmware. Ubuntu still seems to be using the /lib/udev/firmware_helper binary.
The name of the firmware file is passed to firmware_helper in the environment variable $FIRMWARE which is concatenated to the path /lib/firmware and used to load the firmware.
The actual request to load the firmware is made by the driver (ipw2200 in my case) via the system call:
request_firmware(..., "ipw2200-bss.fw", ...);
Now somewhere in between the driver calling request_firmware and firmware_helper looking at the $FIRMWARE environment variable, the kernel package name is getting prepended to the firmware name.
So who's doing it?
From the kernel's perspective, see /usr/src/linux/Documentation/firmware_class/README:
kernel(driver): calls request_firmware(&fw_entry, $FIRMWARE, device)
userspace:
- /sys/class/firmware/xxx/{loading,data} appear.
- hotplug gets called with a firmware identifier in $FIRMWARE
and the usual hotplug environment.
- hotplug: echo 1 > /sys/class/firmware/xxx/loading
kernel: Discard any previous partial load.
userspace:
- hotplug: cat appropriate_firmware_image > \
/sys/class/firmware/xxx/data
kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
comes in.
userspace:
- hotplug: echo 0 > /sys/class/firmware/xxx/loading
kernel: request_firmware() returns and the driver has the firmware
image in fw_entry->{data,size}. If something went wrong
request_firmware() returns non-zero and fw_entry is set to
NULL.
kernel(driver): Driver code calls release_firmware(fw_entry) releasing
the firmware image and any related resource.
The kernel doesn't actually load any firmware at all. It simply informs userspace, "I want a firmware by the name of xxx", and waits for userspace to pipe the firmware image back to the kernel.
Now, on Ubuntu 8.04,
$ grep firmware /etc/udev/rules.d/80-program.rules
# Load firmware on demand
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware_helper"
so as you've discovered, udev is configured to run firmware_helper when the kernel asks for firmware.
$ apt-get source udev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 312kB of source archives.
Get:1 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (dsc) [716B]
Get:2 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (tar) [245kB]
Get:3 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (diff) [65.7kB]
Fetched 312kB in 1s (223kB/s)
gpg: Signature made Tue 14 Apr 2009 05:31:34 PM EDT using DSA key ID 17063E6D
gpg: Can't check signature: public key not found
dpkg-source: extracting udev in udev-117
dpkg-source: unpacking udev_117.orig.tar.gz
dpkg-source: applying ./udev_117-8ubuntu0.2.diff.gz
$ cd udev-117/
$ cat debian/patches/80-extras-firmware.patch
If you read the source, you'll find that Ubuntu wrote a firmware_helper which is hard-coded to first look for /lib/modules/$(uname -r)/$FIRMWARE, then /lib/modules/$FIRMWARE, and no other locations. Translating it to sh, it does approximately this:
echo -n 1 > /sys/$DEVPATH/loading
cat /lib/firmware/$(uname -r)/$FIRMWARE > /sys/$DEVPATH/data \
|| cat /lib/firmware/$FIRMWARE > /sys/$DEVPATH/data
if [ $? = 0 ]; then
echo -n 1 > /sys/$DEVPATH/loading
echo -n -1 > /sys/$DEVPATH/loading
fi
which is exactly the format the kernel expects.
To make a long story short: Ubuntu's udev package has customizations that always look in /lib/firmware/$(uname -r) first. This policy is being handled in userspace.
Wow this is very useful information and it led me to the solution for my problem when making a custom USB kernel module for a device requiring firmware.
Basically, every Ubuntu brings a new rehash of hal,sysfs,devfs,udev,and so on...and things just change. In fact I read they stopped using hal.
So let's reverse engineer this yet again so it's pertinent to the latest [Ubuntu] systems.
On Ubuntu Lucid (the latest at time of writing), /lib/udev/rules.d/50-firmware.rules is used. This file calls the binary /lib/udev/firmware, where magic happens.
Listing: /lib/udev/rules.d/50-firmware.rules
# firmware-class requests, copies files into the kernel
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
The magic should be something along these lines (source: Linux Device Drivers, 3rd Ed., Ch. 14: The Linux Device Model):
echo 1 to loading
copy firmware to data
on failure, echo -1 to loading and halt firmware loading process
echo 0 to loading (signal the kernel)
then, a specific kernel module receives the data and pushes it to the device
If you look at Lucid's source page for udev, in udev-151/extras/firmware/firmware.c, the source for that firmware /lib/udev/firmware binary, that's exactly what goes on.
Excerpt: Lucid source, udev-151/extras/firmware/firmware.c
util_strscpyl(datapath, sizeof(datapath), udev_get_sys_path(udev), devpath, "/data", NULL);
if (!copy_firmware(udev, fwpath, datapath, statbuf.st_size)) {
err(udev, "error sending firmware '%s' to device\n", firmware);
set_loading(udev, loadpath, "-1");
rc = 4;
goto exit;
};
set_loading(udev, loadpath, "0");
Additionally, many devices use an Intel HEX format (textish files containing checksum and other stuff) (wiki it i have no reputation and no ability to link). The kernel program ihex2fw (called from Makefile in kernel_source/lib/firmware on .HEX files) converts these HEX files to an arbitrary-designed binary format that the Linux kernel then picks up with request_ihex_firmware, because they thought reading text files in the kernel was silly (it would slow things down).
On current Linux systems, this is handled via udev and the firmware.agent.
Linux 3.5.7 Gentoo, I have the same issue.
SOLVED:
emerge ipw2200-firmware
Then go to /usr/src/linux
make menucofig
on device driver, remove all wirless drivers don't needed, set Intell 2200 as module and recompile.
make
make modules_install
cp arch/x86/boot/bzImage /boot/kernel-yourdefault