Hot answers tagged

33

mkimage -l uImage Will dump the information in the header. tail -c+65 < uImage > out Will get the content. tail -c+65 < uImage | gunzip > out will get it uncompressed if it was gzip-compressed. If that was an initramfs, you can do cpio -t < out or pax < out to list the content. If it's a ramdisk image, you can try and mount it with: ...


13

The ext4 feature (400) is the new metadata_csum feature. If this feature is enabled and old tools are used to mount the filesystem they will only be able to mount read-only. https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums To create a ext4 filesystem without this feature: sudo mke2fs /dev/sdb1 -O ^metadata_csum Or turn it off on an already ...


9

U-Boot brings its own dumpimage tool (find it in the tools directory of your U-Boot tree) Of course it works with simple images, but it also supports the old-style multi images $ ~2/tools/dumpimage -l uMulti Image Name: Created: Thu Aug 31 19:54:29 2017 Image Type: ARM Linux Multi-File Image (uncompressed) Data Size: 5678650 Bytes = 5545.56 ...


9

I think you should convert it to u-boot file like this and give it a try: mkimage -n 'Ramdisk Image' -A arm -O linux -T ramdisk -C gzip -d initramfs.cpio.gz initramfs.uImage This might be a valid format for u-boot.


8

When U-Boot executes the boot command, it provides a memory address for the kernel and a memory address for the device tree blob. Therefore, prior to this command, it must load these files into memory. Based on the messages you provided we see that two files failed to be loaded from the eMMC/SD card: /boot/boot.ub /boot/imx6dl-ts4900-13.dtb Its possible ...


7

From a page on U-Boot images here, the command you're looking for is : mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux kernel" -d arch/arm/boot/zImage uImage The mkimage utility comes with the u-boot-tools package in Ubuntu (if that's what you're using), and it can be installed with the command sudo apt-get install u-boot-...


7

As far as I know, U-Boot cannot directly boot a “raw” ELF image (vmlinux). You need to turn it into the uImage format, which contains the compressed vmlinux plus a few extra bytes of metadata that describe the kernel load address. U-Boot FAQ 2.19 explains how to generate uImage; it's fairly straightforward, using the mkimage utility in the U-Boot source tree:...


7

I'm way late on this, but I implemented this script and I'll address this for anyone who finds this using an internet search engine. This computer on module can be put on almost any off the shelf TS or custom baseboard, and we wanted it to automatically work without users having to adjust the device tree used. We have an 8-input shift register on any given ...


6

“vmlinuz” as a format name does mean “gzipped vmlinux file which got stripped of all its symbols”. However, as a file name, vmlinuz is often used for any kernel image which is in a compressed format that a bootloader supports, such as the zimage format or the bzimage format. The name vmlinuz is popular on x86 distributions, regardless of the actual format of ...


6

The error "EXT4-fs : couldn't mount RDWR because of unsupported optional features (400)" is due to different versions between the partition formatter (mkfs.ext4) and the mounter. You have two options: a) Either you have to upgrade the mounter program using a newer distro inside the SD-card. b) or you have to backup the files, reformat the SD-card with the ...


6

The short answer to burning u-boot to the mmc is probably tftp ${loadaddr} u-boot.bin mmc partconf 0 ${emmc_boot_ack} ${emmc_boot_part} 1 mmc write ${fileaddr} 0 800 mmc partconf 0 ${emmc_boot_ack} ${emmc_boot_part} 0 but it depends on how you've setup the mmc. This command will write 1048576 (0x800 * 512) bytes from ${fileaddr} to the mmc starting at ...


4

To add detail to David Schwartz's answer, by specifying the kernel boot parameter to set the amount and start address used by the kernel, you can do what you want. For example, add the following command to your kernel boot args: mem=256M@0x80000000 Will indicate the kernel should use 256M starting at 0x80000000, which is what you require. You should ...


4

In case there are several images inside here is a quick bash script to extract them all into the files image_0, image_1, …: #!/bin/bash src_file=uImage declare -ia sizes=( $(mkimage -l "$src_file" | awk '/^ +Image [0-9]+/ { print $3 }') ) declare -i offset="68+4*${#sizes[@]}" declare -i size for i in "${!sizes[@]}"; do size=${sizes[$i]} echo "...


4

In recent versions of U-Boot, you can simply enable the bootz command, which boots a raw zImage. And in order to enable the bootz command, you need to add: #define CONFIG_CMD_BOOTZ in your board config file (include/configs/) Source http://u-boot.10912.n7.nabble.com/Booting-zImage-from-UBOOT-td150140.html


4

I am guessing here, as I have no Kobo Glo (I wish my Bookeen HD was reprogrammable). You seem to have a 2Gb SD memory internally ( 60352 cylinders of 32K each) The dd does skip 2048 blocks of 512 (1048576), which is less than the 305 cylinder offset (9994240). In fact have to write more than 8Mb to reach the /dev/mmcblk0p1 partition that way. How the ...


4

This seems like the memory at which fdt is getting corrupted (usually due to overwrite) when kernel image starts to un-compress. Try loading fdt at a higher address e.g. 0xe00000.


4

The latest release 11 of FreeBSD added support for BCM2836 making it compatible for Pi2. https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi


3

mkimage -A arm -O linux -T kernel -C gzip … -d vmlinux uImage Change gzip in the above example to none, and you'll create a u-Boot compatible uncompressed image.


3

Yes you're correct about the middle values. Those are the data values and their ASCII representations are printed to the far most right. The addresses are in hex as well so you're seeing 16 values per row, 0000000c to 0000001c, for example. There is also a base command (type help base) which specifies what the base addresses is for the relative addresses you'...


3

I think you're going to have to do it the other way around, and leave the top 256MB unused. CONFIG_PHYSICAL_START doesn't do what you seem to think it does. It controls where the kernel is loaded, not which physical pages the kernel uses.


3

I think you've missed bootloader. U-Boot has to be present on your SD. Take a look at how the SD layout should be for the Banana Pi / Pro: http://wiki.lemaker.org/BananaPro/Pi:Setting_up_the_bootable_SD_card#SD_Card_Layout


3

If you have python and: install libarchive-c (e.g. using pip install libarchive-c) have all your files under directory root in the current directory ( I used mkdir -p root/xyz ; echo 1 > root/abc.txt ; echo 2> root/xyz/def.txt ) save the following as abscpio and make it executable (chmod 755 abscpio) #! /usr/bin/env python import os import sys from ...


3

There are two ways to pass arguments to kernel: 1. Compile them inside. 2. Use bootloader So first check if your arguments are not compiled into kernel. Second setenv command you've found in not a bash command but boot loader command. It depends on how particular device made, but usually there is a partition in some internal storage (flash memory of your ...


3

I guess you need to Follow the Third stage of U-boot. The third stage is the loading of the Linux kernel. However, before the Linux kernel takes control, u-boot passes a command line to the kernel containing essential parameters. These parameters can be viewed after the operating system has booted by typing the following into a Terminal window: $ cat /proc/...


3

I am assuming that you are calling this at the u-boot command line. bootcmd tftpboot 0x80800000 192.168.2.2:uImage2; bootm The important note here is that the semicolon is a command separator. A simple fix (untested) would to add the command saveenv before the bootm command. bootcmd tftpboot 0x80800000 192.168.2.2:uImage2; saveenv; bootm This would set ...


3

The answer to this exact problem comes from understanding that U-Boot tries to be extremely flexible and this can lead to some confusion at times. Looking at the provided environment we can see that we have the bootcmd (which is executed when the boot delay runs out) boils down to: bootm ${loadaddr} - ${fdtaddr} And this means that we look at ${loadaddr} ...


3

add load in fdt node fdt@1 { description = "Flattened Device Tree blob"; data = /incbin/("arch/arm/boot/dts/tx6.dtb"); type = "flat_dt"; arch = "arm"; load = <0x18000000> compression = "none"; hash@1 { algo = "sha1"; }; };


3

Since I did not receive any answers/suggestions I finally decided to go through a painful git bisect operation (~13 iterations) in between the two tags: v4.10.1 (good) & v4.11.1 (bad). This lead me to: % git bisect good 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 is the first bad commit commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 Author: Marcin ...


2

The DULG DebuggingUBoot page has this to say (the "relocation" it speaks of is copying itself from flash to RAM). For debugging U-Boot after relocation we need to know the address to which U-Boot relocates itself to. When no exotic features like PRAM are used, this address usually is - CONFIG_SYS_MONITOR_LEN. In our example with 16MB RAM and ...


2

Have a look at the Uboot manual, especially section 5. It should also be possible to show additional information in the cli itself via help COMMAND


Only top voted, non community-wiki answers of a minimum length are eligible