I am trying to load a new kernel image onto my raspberry pi. I've got u-boot-2018-11 and trying to have the kernel load automatically with uEnv.txt but there is not change in the out put with or without the text file. I have also tried boot.scr and boot.scr.uimg but nothing seems to work. I don't know for sure what to put into those files but uboot doesn't even recognize them.
For the uEnv.txt I put...
uenvcmd=fatload mmc 0:6 0x08000000 kernel8.img; fatload mmc 0:6 0x09000000 rpi-3b-plus.dtb;bootm 0x08000000 - 0x09000000;
So the u-boot I am using doesn't recognize uEnv.txt and I wasn't putting the correct stuff in the other two things. What I ended up doing was..
setenv bootcmd 'fatload mmc 0:6 0x08000000 kernel8.img; fatload mmc 0:6 0x09000000 rpi-3b-plus.dtb;bootm 0x08000000 - 0x09000000;'
saveenv
and that works
Related
I am unable to understand these commands like
fatload mmc 0 0x3000000 uImage
fatload mmc 0 0x2A00000 devicetree.dtb
bootm 0x3000000 - 0x2A00000
#fatload mmc 0 0x3000000 uImage.
What is it doing? Is it loading uImage as a fat partition and loading at the RAM address 0x3000000?
bootm 0x3000000 - 0x2A00000 - ?
Does it mean boot from the RAM address 0x3000000 to 0x2A00000?
U-Boot runs code placed in (processor's) RAM, although it can also read data from other media. The boot process normally takes place in two steps:
Reading the OS image from media (Ethernet, flash, USB, MMC) into RAM
Jumping to the first instruction of the image in RAM
uImage is the (most probably Linux) kernel.
xxx.dtb is your device tree in compiled form. It contains the hardware information, so that the information can be kept separately from the kernel.
Now, to read an image from an MMC card formatted in FAT, the command is:
fatload mmc <dev>[:partition] <loadAddress> <bootfilename>
So the 2 fatload commands are loading the 2 files from MMC card into the processor's memory/RAM.
Now, regarding the bootm : This command starts a kernel image running. The syntax is :
bootm <address of kernel> <address of ramdisk> <address of dtb>
Addresses of ramdisk and/or dtb can be omitted if the kernel is configured in such a away that it doesn't need it/them.
In your case you are not using ramdisk hence the dash - in the middle.
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 playing around with a Raspberry 3 and try to boot a Linux Kernel by using U-Boot.
I've built a Linux Kernel (from github.com/raspberrypi), and Busbox-Userland.
This Kernel boots and works just fine, when booting 'directly' (that means without U-Boot).
Now I've built U-Boot (Mainline, denx.de/u-boot.git), which also seems to work.
It boots and is accessible (both by HDMI/USB and [after adding pi3-disable-bt-Overlay]).
But now I am stuck; the Kernel won't start from within U-Boot.
I tried the following commands:
setenv fdtfile bcm2710-rpi-3-b.dtb
mmc dev 0
fatload mmc 0:1 ${kernel_addr_r} kernel7.img
fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
setenv bootargs earlyprintk console=tty0 console=ttyAMA0 root=/dev/mmcblk0p2 rootfstype=ext2 rootwait noinitrd
bootz ${kernel_addr_r} - ${fdt_addr_r}
U-Boot's output is then:
[...]
reading kernel7.img
[...]
Kernel image # 0x1000000 [ 0x000000 - 0x40e630 ]
## Flattened Device Tree blob at 0x000100
Booting using fdt blob at 0x000100
Using Device Tree in place at 0000100, end 00006b1a
Starting kernel...
And then the Monitor turns black and shows "no signal", also the serial console doesn't show any more information.
I've played around with the bootargs that are provided to the Kernel, but I didn't find a working scenario.
Does anybody have an idea?
As I said, both the U-Boot and the Kernel seem to work, but U-Boot can't boot the Kernel...
Thanks,
VanDahlen
I know this is a very old question but for me it helped to not manually load the device tree file and use ${fdt_addr} instead of ${fdt_addr_r} in bootz.
So...
mmc dev 0
fatload mmc 0:1 ${kernel_addr_r} kernel7.img
setenv bootargs earlyprintk console=tty0 console=ttyAMA0 root=/dev/mmcblk0p2 rootfstype=ext2 rootwait noinitrd
bootz ${kernel_addr_r} - ${fdt_addr}
...should work.
Have you tried loading the kernel at a different address? i.e. at $loadaddr instead of $kernel_addr_r. Make sure kernel is getting loaded at the right address.
I compiled a linux kernel for my Toshiba AC100 and want to boot it via uboot.
Problem: After displaying the message "Starting Kernel" nothing happens.
The flag CONFIG_DEBUG_LL was set but there is still no output after this message.
I have another precompiled kernel (but too old to use) which comes with its own dtb file and this one boots (same bootargs as the non-booting kernel).
Observation: If I change the dbt file for this kernel it shows the same behavior as the non-booting kernel, just displaying the "Starting kernel" line.
So I guess my problem is related to the dbt file I use for my kernel.
Are there any methods to check if the dbt file is right for my board?
What else could I do to get some information what the problem is?
The entry in the boot.scr:
setenv bootargs 'root=/dev/mmcblk0p7 rootfstype=ext4 earlyprintk=vga console=tty0 mem=448M#0'
setenv bootmenu_4 "Boot Arch Linux =ext2load mmc 0:7 0x1000000 /boot/zImage; ext2load mmc 0:7 0x2000000 /boot/tegra20-paz00.dtb; bootz 0x1000000 - 0x2000000"
And here's the output form u-boot:
2255488 bytes read in 116 ms (18.5 MiB/s)
14153 bytes read in 82 ms (168 KiB/s)
Kernel image # 0x1000000 [ 0x000000 - 0x226a80 ]
## Flattened Device Tree blob at 02000000
Booting using the fdt blob at 0x2000000
Loading Device Tree to 0fff9000, end 0ffff748 ... OK
Starting kernel ...
I tried also to extract the config from the working kernel and built a new kernel with this config, but this one does not work, too (does not matter which dtb file I use).
EDIT:
Finally I solved it by changing the kernel config from
CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA
to
CONFIG_TEGRA_DEBUG_UARTA
After this, the kernel boots fine.
I've a device on which I've a 3.10 linux kernel booting up to a busybox shell (initramfs)
When I extracted the busybox filesystem image on the SD card and when modified the root from root=/dev/ram to /dev/mmcblck0p1, it still boots up to the shell
So the busybox works fine but if I try to use any other FS the kernel would crash...
While I try to generate a rootfs using debootstrap (https://help.ubuntu.com/community/DebootstrapChroot) and have the new rootfs extracted on the SD card. I get an error saying "Failed to execute /sbin/init"
I did check if the file is present and also checked the permissions and it looks good to me.
What could be the problem?
W.R.T rootfs I'm particularly new. I was assuming that any FS on the SD card could be mounted but looks like its not the case. I'm guessing that whatever the /sbin/init will be doing is device dependent?
What I am trying to do? --->
I need to make a rootfs with a few packages and libraries (gcc python etc..) What would a normal approach? I've even tried buildroot but I couldn't get gcc on target. Is it not possible to have gcc in /bin/ within buildroot?
-- UPDATE --
I'm formatting the SD card to ext4 format and following is the output of fdisk
Disk /dev/sdb1: 7945 MB, 7945588224 bytes
255 heads, 63 sectors/track, 965 cylinders, total 15518727 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc2aa4908
Device Boot Start End Blocks Id System
And following are the kernel logs while I have a filesystem on the SD card. The memory card driver works fine I've verified that. If I have a busybox filesystem on the SD card, everything works fine. When I'm using any other file systems I get the following...
6EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
6VFS: Mounted root (ext4 filesystem) on device 179:1.
6Freeing unused kernel memory: 84K (c0f00000 - c0f15000)
3request_module: runaway loop modprobe binfmt-464c
4kworker/u2:4 (145) used greatest stack depth: 6132 bytes left
3Failed to execute /sbin/init. Attempting defaults...
3request_module: runaway loop modprobe binfmt-464c
3request_module: runaway loop modprobe binfmt-464c
0Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
When checked, there is /sbin/init with the appropriate permissions that too!
Consider this error: "request_module: runaway loop modprobe binfmt-464c"
In all probability you're trying to use 64b binaries (/sbin/init and the rest) with 32b only kernel. Either recompile your kernel to support 64b or install a 32b user space onto your sd card.
Other things to check:
Confirm that elf support is indeed enabled in your kernel (it normally is, but it is possible to disable it).
Google that error and see what sort of problems people were having with it.